[Openswan Users] Controlling XFRM policies to prevent spoofing
paul at xelerance.com
Thu Jan 11 15:58:44 EST 2007
On Thu, 11 Jan 2007, Michael Smith wrote:
> I'm using openswan 2.4.7 and netkey (kernel 126.96.36.199). I am trying to
> figure out how to create IPsec policies to require that inbound traffic
> from certain IP ranges can only be forwarded if it came in over IPsec.
If you have a tunnel definition, then all plaintext packets for those IP's
will always be dropped. KLIPS does this for sure. If NETKEY does not, it
> This is a little dangerous, because although 10.20.1-101 will be protected
> by kernel IPsec policies, 10.20.101-255 would be wide open. Someone on the
> Internet could inject packets claiming to come from 10.20.101.1, and
> if they controlled the ISP's routers, they could even get replies.
All your border gateways to your ISP should be dropping
all 10/8 incoming packets from the ISP routers. Once they are inside your
network, irt becomes much harder to judge if they were spoofed or not.
> conn dummy
> leftid="/CN=not going to work"
> rightid="/CN=also not going to work"
> This actually works, and creates XFRM policies preventing the main office
> subnet (10.10.1.0/24) from sending replies to unused satellite
> subnets (10.20.101-255).
> # ip xfrm policy show
> src 10.20.1.0/24 dst 10.20.0.0/16
> dir out priority 2348
> tmpl src 0.0.0.0 dst 0.0.0.0
> proto esp reqid 0 mode transport
> But it still allows spoofed packets from 10.20.101-255 to be forwarded to
> 10.10.1.0/24. Is there a way to trick Openswan into creating dummy
> policies that would block those inbound packets? I could create the XFRM
> rules by hand, but I think Openswan might delete them at any time, right?
It should only delete those it creates. But how is openswan to know whether
a packet was spoofed or wether it was genuine? The basic method for this is
to drop all 10/8 packets coming in on any router you control in plaintext,
except for the network that has the particular 10/24 network. Packets coming
in through ipsec already passed the proper tunnel checks, so you shouldn't
be relaying spoofed packets within your network.
More information about the Users