Date: Mon, 8 Jul 2002 08:03:04 +0200 (MET DST) From: Helge Oldach <helge.oldach@atosorigin.com> To: fb-stable@psconsult.nl (Paul Schenkeveld) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: IPsec and IPfilter interaction Message-ID: <200207080603.IAA22096@galaxy.de.cp.philips.com> In-Reply-To: <20020707222803.A57511@psconsult.nl> from Paul Schenkeveld at "Jul 7, 2002 10:28: 3 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Schenkeveld: >On Sun, Jul 07, 2002 at 10:16:19PM +0200, Helge Oldach wrote: >> Paul Schenkeveld: >> >(Not sure if this is the right list to discuss this, point me to a >> >better list please if I'm wrong.) >> >> -questions? >> >> > The configuration of the SPD for tunnel mode is very similar to that >> > of transport mode. The major change that is done is the use of the >> > gif(4) device to get the routing correct. Note that traffic is *not* >> > transported through the gif(4) tunnel! Instead the IPsec code in the >> > kernel grabs the packets according to the specified policy and wraps >> > them with the correct IP addresses for the IPsec tunnel. >> >> Oops. I think I wrote this. :-) >> >> >Tunnel traffic coming in on the external interface (fxp1) all looks >> >like "proto ah" to IPfilter. It looks like I cannot access the TCP, >> >UDP or ICP payload at this point, which makes sense to me. >> > >> >Does this mean that I can only filter TCP, UDP, ICMP traffic coming out of >> >the tunnel when it leaves the firewall thru the internal interface (fxp0)? >> > >> >So all listening sockets inside the firewall are completely open to >> >traffice coming from the tunnel? >> >> Actually you can (and want to!) filter for AH (or, if you're using >> tunnel mode, ESP) protocols and drop any TCP, UDP and ICMP traffic. >> Dropping ICMP completely is probably not wise - at least you want to >> allow ICMP from the peers you are talking AH (or ESP) to. Further, >> allowing a tcp/telnet resp. tcp/ssh to and from the remote site would >> probably be reasonable. > >I know that I can filter on AH or ESP protocols but my issue is that >every daemon on the firewall (by default, sometimes tunable) listens >on every available interface, including the gif0 interface. > >So from the inside LAN at one location (behind firewall1) one can connect >to e.g. sendmail running on firewall2 at the other location. How can I >(on firewall2) block incoming connections coming in thru the tunnel to a >particular TCP or UDP port of firewall2? For sendmail (and actually most other daemons, which is very important if you run jails on your machine) you can specify which interface to bind to. Secondly you have the option to play with the IP addresses of the gif interfaces at either side. As I wrote, the interface is not actually used, it's more a placeholder to get routing straight. Hence the remote address of the interface (not the local address!) is irrelevant, as long as you have a route at either side pointing to the remote side via this remote route. By using an address that is not reachable from the other side you can effectively disable access to gif from remote. BTW, you can achieve the same effect without gif: You need to set up a static arp entry using the MAC address of your default gateway with some arbirary address. Then set up a route to the remote side via this address, and again all packets matching the policy will be taken by IPsec. >> >Or am I wrong here and is there a way to completely screen all tunnel >> >traffic after the IPsec encapsulation is peeled off? >> >> AFAIK not. I'd say this wouldn't be very sensible anyway. By setting up >> a security association with the peer you are basically trusting him. > >So you mean that if one site gets compromised it's acceptable that the >other sites get compromised as well? IPsec's paradigm is that you either trust the remote side (according to the specified policy) or you don't. There is conceptually no such thing as a "maybe trust". >> You can still do filtering on the inside interface of course. > >Except for traffic terminating at the firewall. Correct, but this is a problem of ipfilter. Commercial IPsec gateways (say Cisco routers running IPsec) will do fine. In fact they can even filter traffic before encryption and after decryption on the external interface. Helge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207080603.IAA22096>