RE: Gauntlet & NTLM

[Craig Brozefsky <craig () onshore com>]

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.

> 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 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.

> 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.

> 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.

> 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.

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.

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.

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.