Re: letting traffic flow through a SG by default

-----BEGIN PGP SIGNED MESSAGE-----


On Wed, 12 Mar 2003, Michael Richardson wrote:

>   a) it only affects outbound.
>   b) even were it not to be set, the attack you detail would still occur.

Point taken; the existance of "disablearrivalcheck" should have provided a
clue. 

>   The only defense against this scenario is to have a properly configured
> firewall so that packets with the wrong source IP do not get in.

Don't we already attempt to combat this possibility? The hint from 
ipsec.conf's man page:

    whether KLIPS's normal tunnel-exit check (that a
    packet emerging from a tunnel has plausible addresses in its header) 
    should be disabled; acceptable values are yes and no (the default).  
    Tunnel-exit checks improve security and do not break any normal
    configuration.  Relevant only locally, other end need not agree on it.

>   Now, since the attacker can be malicious, and put the wrong packet in
> the tunnel, the attacker can also spoof things with the right source.
>
>   This is a one way attack (no replies will be seen). Of course, there are
> lots of one-way attacks on Winblows.

Tangent:

One well crafted (exploit-driven, of course) packet can freeze a machine; 
perhaps someone more enlightened by hackish ways could show us a series of 
packets that can remote-root (or the equivalent) a vulnerable system. The 
system could be determined ahead of time by a corporate hacker's intel.

Many sysadmins don't audit traffic exiting a network nearly as closely as
INPUT. All you'd need to do is direct the Winblows box to reply to another IP
address, one not already covered/blocked by the ipsecN machinery from the
existing host-to-host OE eroute, or rely on a time-delay, etc. to get you 
through the firewall via the ESTABLISHED rule many sysadmins also exempt.

Then again, simply compromising a Roadwarrior's laptop, or infiltrating a 
remote office's lax security, might do the same. And if your data is that 
crucial, it should take more than privileged access to a server... 
whatever.

>   The solution to above is to make sure that packets emerging from KLIPS
> are marked in some way with the tunnel that they came from. This is currently
> done in 2.xx by setting the nfmark bits with the SAref value. (Mind you,
> there is no convincing test for this yet, so it might not work)
> 
>   To get completed, we need to have pluto express the SAref that it got
> from KLIPS to the updown and firewall scripts, so that they can configure
> things. This is partially dependant upon the advanced routing _updown script.

I'm all with you here. We need to provide a robust way to distinguish between
OE and VPN traffic. If we plan to encourage the two to co-exist on the same
machine.

- -- 
Sam Sgro
[email protected]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: For the matching public key, finger the Reply-To: address.

iQCVAwUBPnBSIUOSC4btEQUtAQHu9QP8DTUJ2iW63SQEEP10LJoqljvBDepyhsRa
Af4eZf1kW5YE1sHdg66a57Ps0XRZefYrC/4zbrN9sxIkp+GazojYnRVUMtFDl8OP
H7d8lFnitSfUwETcRx+oRbutQwuK4zsU7q2P8r4ZWWTTxcvXm6zGI34d4YYlKfcF
VOdZLFBEFTE=
=Vbjn
-----END PGP SIGNATURE-----