Re: letting traffic flow through a SG by default

On Tue, 11 Mar 2003, Sam Sgro wrote:

>    Imagine this scenario: I've got a gateway running FreeS/WAN, configured
> with a few VPN conns. If that gateway were configured to do OE only for
> itself, a malicious hacker could negotiate an OE connection with it, and then
> pass packets intended for the subnet behind down the tunnel.

Add to the manual: A security gateway is NOT A FIREWALL. Use excessive large font.

This problem isn't different from any nonOE setup, eg an extruded subnet, or a
classic private space VPN tunnel.


>    With packetdefault=pass, those packets would be readily passed to the
> subnet behind.

IMHO, it should. (then again, I do have packetdefault=yes on my machines :)

>  You could have packets with any source or destination address
> flying back and forth; ipsec.conf's man page even mentions you shouldn't have
> packetdefault=pass "unless you really know what you are doing". 

Perhaps we can add a section on why it is unwise to combine classic VPN's and
hostOE on the same box. After all, who do you want to knock at your firewall
to begin with. If you're doing OE for a subnet, then we should point out to
people that they need to put the firewall rules on the inside interface, not
the outside one.

>    I believe the security concerns raised in employing packetdefault=pass by
> default nix this as a solution.

Not having it will break most setups. I think the loss of deployment would be
worse.
 
>    Most modern kernels have the "iproute2" suite of routing tools available,
> which allow for greater precision in defining routes. Updating our _updown
> script to take advantage of these features would allow us to redirect all
> packets originating from ipsec0's IP to ipsec0 (and into our machinery). The
> %pass eroute would not be necessary because those packets from the protected
> subnet would never be captured, and would thus escape unscathed.

iproute gives many new good options indeed.
 
>    We have been in the midst of exploring iproute2 as it pertains to
> FreeS/WAN, and this would seem an ideal time to employ its feature set to help
> solve this problem.

This would however, make more sense for a 3.x freeswan. Adding a dependancy on 
iproute would break 2.0/2.2 kernels

>    The solution I prefer by far is not to enable any Policy Group or
> Opportunistic based connection unless KEY data for our own side exists. In
> short, we need to evaluate ourselves as a potential OE client. If we fail this
> evaluation, no packets need be captured. In short, don't --add, or at least
> don't --route, the policy group conns when no KEY/TXT data can be found.

But this is dangerous. What if I fire up my laptop without pcmcia card plugged
in. I want OE to start but at the time pluto can't check for a KEY in my FQDN.
Having said that, I'v never had pluto successfully catch a changed situation,
and start. I've always had to restart it, getting the 'not started but will restart'
warning.

>    Solution 2 has its own concerns - a malicious user could insert KEY/TXT
> records for the public IP of their gateway, and magically turn it on,
> theoretically allowing for privileged access to the gateway (and the gateway
> only). This may be something we need to think on further.

Wouldn't this be caught by having rules in the INPUT (not FORWARD) table? This
is were rules belong which have the host as destinatin anyway. (on 2.4)

Paul
-- 
God devised pigeons as a means of punishment for man. Probably after
the destruction of Sodom and Gomorrha he wanted to make sure that people
would never again feel comfortable enough in a city to repeat the sins
committed there, and he created the pigeons as a means to make the city
dwellers' lives more miserable, as a constant reminder of their past sins.