RE: Gauntlet & NTLM

[Linwood Ferguson <ferguson () uvii mag aramark com>]

First, let me say that I am far from a security or firewall expert (nor
do I play one on TV), so I walk out on this ledge with a bit of trepidation
but ....

> Craig Brozefsky <craig () onshore com> wrote:

> On Mon, 13 Oct 1997, Linwood Ferguson wrote:

> > I'm not familiar with NTLM, but we did get PPTP running through Gauntlet.
> > That should carry most anything through, and its free if you're running
> > NT4 on both side (NT server is not even required), so simple to give a 
> > test.  My expectation is that their net extender would do basically the
> > same things (though with added security features perhaps). 

> I was asked to investigate the same setup recently by my managers.  We are
> not deploying it for any clients at the time because my investigation
> concluded that it was not suitable and violates the integrity of our
> firewall perimeter.

I'm looking for just such information, since we have yet to deploy it 
but are considering it.  Thank you for your input so far.

Let me put it in perspective however.  Our alternative to this is people
who come in via dialup NT RAS (to the inside of the firewall), or people
who telnet through the TIS tn gateway and then log into some internal 
system with clear text passwords.  I don't offer either of these as 
examples of great security, just what-is; so what I'm looking for is 
something that is somehow better: either cheaper, more secure, better
performance, or ideally all three.  I'm also looking for something 
implementable in our situation -- which is stapped for resources and time.

Anyway...

> > Plug port 1723 from any outside address and to your inside pptp server.
> > (If you have specific addresses out side of course you could use those).
> > Set force_source_address to true.
> >
> > Create forwarding rules for:
> >
> > - permit inside protocol 47 source <pptp server> destination any all ports
> > - permit outside protocol 47 source any destination <pptp server> all ports
> > - absorb outside protocol 47 source any destination <pptp server> all ports
> > - absorb outside tcp source any port any destination <pptp serer> port 1723

> Is that first absorb on the protocol 47 (GRE/RFC1701-RFC1702) neccesarry?
> It is after the permit, so I don't think it would ever be seen.

I did this without a manual, with lots of trial and error, and with 
help from TIS support that was like pulling teeth.  They made it quite clear
they didn't "support" this idea.  Whether it was because it was unsafe,
whether because it competed with their for-fee addon, or whether they were
just rushed, I cannot say.  So I'm more than open to knowing there is a 
better way.

However, I tried almost every combination of these and only with all three 
(two permits and an absorb) could I get packets across.  And the absorb
for the TCP packets was also definitely needed, though frankly I do not 
undestand why since all the other plug-gw's we used did not have it (I'm
guessing it was to allow the force_source_address?).

TIS support recommended that the last two rules be consolidated, quote:

    The only thing I would have changed would have been to consolidate the
    two absorb-forward rules into one rule absorbing all protocols on all
    ports, but it doesn't really matter and your way may actually be more
    secure.

> I dislike opening up access to an internal machine like that, even if it's
> only for those packets marked as being GRE packets.  Not only does this
> open you up to so many tunneling exploits in and out of your trusted
> network, but it also opens you up to IP layer exploits which NT has been
> known to have.  I am not familiar with NT's handling of GRE encapsulated
> packets, but the GRE draft RFC 1701 specifies that the receiver of a GRE
> encapuslated payload should check the Routing bit and the Address Family
> field to determine how to interpret the SRE and then forward the payload
> packet as normal.  Now what happens on NT, or other systems that support
> GRE when I send them a packet that is another IP packet encapsulated and I
> set it to be forwarded to another internal host?  I don't think I'de be
> able to setup a connection that way without some other twiddling, but this
> hole in your firewall gives me a wide open shot at tunneling other data in
> and out of your system from the exposed NT server.

Here's how we were looking at it, I guess.  Microsoft offers this as 
"secure" and says it is safe to connect directly.  TIS says there are no
additional vulnerabilities introduced by opening this hole, only whatever
ones might be in the NT server that it connects to.  Is NT as secure as a
TIS customized BSD?  No, probably not.  Does it introduce new
vulnerabilities by allowing it inside?  Probably.  But does it introduce
more than allowing RAS dialup inside?  Than our current internet access
over telnet?  I do not know, but it _seems_ a step up, if not a step
all the way to the top of the "secure" ladder.

What would help greatly in our understanding of this is someone who could
say "here is a specific example of how this breaks", like a known way to 
attack it (+/- encryption key lenth, see below).  Do I trust Microsoft
completely?  Of course not.  But it seems a step up, and 
saves lots of money to boot, and gets rid of lots of modem issues as 
icing on the cake (let the ISP's worry about that).  So it is very 
attractive. 

> > Your pptp call is to the outside nic address on the firewall, the pptp
> > server is inside the firewall.  We chose not to follow Microsoft's 
> > suggestion of putting the pptp server with a nic outside and a nic inside,
> > so interpret their setup instructions with a gain of salt - no extra hardware
> > is needed, you can just have it connected to the inside NIC as usual, and 
> > it can be a workstation (at least for some small number of connections for
> > testing -- I don't recall if there's a limit).

> But you also just opened up a sizable hole in your firewall.

OK, I have lots of them.  Web traffic, telnet, ftp.... all have some 
vulnerabilities to them that have to be weighed against their benefit.
The most secure situation is to pull the plug.

I don't mean to sound argumentative, but as a non-expert, I have had 
several people tell me I've opened a hole, but not one showed me that 
anything could drive through it.  Can it?

BTW, I'm not totally ignoring their advice either -- we have NOT opened
the hole yet, I am still playing with it and still reading everything I
can find.  So please, by all means, tell me I'm nuts (but show me why at
the same time).

> > We are hoping to use this for work-from-home folks, so any comments on the
> > general use of PPTP welcomed.

> The people at home are going to need WinNT4.0 with all the service packs I
> beleive, or an ISP with a proper FEP.  It also does not IMO give you
> adequate security.  See below.

Thats not a problem, we standardized on NT long ago.

> > PS. TIS is rather reluctant to help with this, giving lots of warnings that
> > they cannot vouce for its safety, etc., though without a lot of specifics.
> > So consider their vague warnings relayed equally vaguely.  :-)

> They have some valid concerns I am sure.

> 1. Opening up the hole in the firewall for protocol 47 allows covert
> channel tunneling in and out of your network to the NT server, and
> possibly depending on GRE implementations to other hosts on your internal
> network.

OK, help me out here.  The last part sounds much more of a concern.
Assuming we "trust" the NT, that does not mean we trust all other inside
systems, in fact those systems are rather light in their defenses on some
fronts.  Does this mean there is someway to send GRE packets through the
firewall to another system (despite the forwarding directing it
specifically to the NT?).  Or that the NT might forward the packets 
elsewhere?

How could that compromise another system?

> 2. Protocol specific access controls are now handled by yet another
> machine on your internal network which was not designed to provide the
> advanced access control mechanisms that Gauntlet is.

Well, we have that already by RAS.  RAS might not be as bad as internet
access, but I'm  not sure sometimes.  With all the hype over the last few
years, it seems many people  have forgotten about modems as being a
serious risk as well.  I've got a ton of auditing of internet access
(including PPTP tunnels) at my disposal, but the folks in charge of dialup
access for our group have nothing.  This might be a BIG step up.

> 3.  The encryption is laughable 40 bit RSA WITHOUT EVER RENEGOTIATING
> KEYS!!!!!  This means I now have tons of data encrypted with the same lame
> 40 but key, and because of all the encapsulation a good percentage of that
> is known plaintext from the packet headers (IP/GRE/PPP/IP/TCP).  40 bit is
> bad enough but without key negotiation over the lifetime of the connection
> it's severly degraded.

Help me out here.  Let's assume someone does actually intercept the
stream, and cares to take the trouble to decrypt it.  Is there something 
they can do with that data to compromise our network?

Or have they simply intercepted a terminal session from one of our  remote
users?  If the latter -- I don't want to say 'who cares', but anyone going
to that much trouble can get it much easier.  We're not a bank or NSA, and 
the lamest attempts at a bit of social engineering would get them much
further and more interesting stuff than seeing some e-mail from home.

Now I am much worried if something in that stream gives ready access
to IP connectivity to the inside.

However -- my understanding (which I have not pursued) is that Mircosoft
offers USA users a 128 bit version.  Do they not?


> And to top it all off, it's a modified GRE, but still used the GRE
> protocol number (47).  When will Microsoft and Ascend get their heads out
> of their ass?  I'm sure a connections from an Ascend FEP to my PNS NT 4.0
> machine is way secure from IP spoofing when Ascend sequence numbers ina nd
> out of their Maxs are utterly insanely predictable (see BUGTRAQ), and NT
> sequence numbers are only marginally better and still worse than RFC
> reccomended seq number generation algorithms.

> Also PPTP is far from ontrack when it comes to the IETF backed IPSEC
> draft.


Thanks again for your feedback.  I hope you don't mind my questioning 
specifics of why you think it is more vulnerable. 

    - Linwood

-----------------------------------------------------------------------
Linwood Ferguson                  e-mail: ferguson () mag aramark com
Director, Software Engineering    Voice:  (US) 540/967-0087
ARAMARK Mag & Book Services