[strongSwan] Avoid leakage of packets addressed to/from private IP space
vitaly_repin at fsfe.org
Mon Sep 7 16:54:10 CEST 2015
Thanks a lot for your criticisms. I am rewriting an article now and
have some questions about your points.
2015-07-31 16:49 GMT+03:00 Noel Kuntze <noel at familie-kuntze.de>:
> You should drop all packets with no matching IPsec policy,
> if their target is an RFC1918 address space and the interface
> the packet goes out of is attached to the WAN.
> The reason I used an ipset and not -s -d in the email
> you referenced under "IPsec: dropping packets without a matched policy"
> is, that you can easily change the content of the IPset without
> having to touch your iptables rules. ipsets have distinct advantages
> to pure iptables based approach to listing networks and ports.
Do you mean that it's not enough to have just one rule:
iptables -A FORWARD -d 10.57.0.0/16 -m policy --pol none --dir out -j DROP
But I need to have similar rules for other RFC1918 networks? I thought
that one rule is enough
if IPsec-based VPN network is known.
> Also, several arguments to -s and -d in iptables expand to several rules with all
> combinations of listed networks and hosts. This means that if you have a rule with
> two arguments to -s and two arguments to -d, those will result in 4 rules in iptables.
Agree with your. But shall I have also rule iptables -A FORWARD -s
10.57.0.0/16 -m policy --pol none --dir out -j DROP ?
> Also, you're mixing the use of iproute2 and bridge-utils, you even ask
> the user to install the latter. iproute2 can create bridge devices just fine.
> The current only use cases I know of, for which brctl
> is really needed, is to enable stp or show information
> about the stp state of the bridge, but you're not using that functionality.
> As you already use custom ifup and ifdown hooks in the interfaces
> file, you can just continue using that to script the creation of the bridge.
> There's no need to use the native syntax of the file, as it uses the old net-tools, which
> is quite bad, but Debian-esque.
Yep. This was a clear mistake. Removed it. No need in brctl.
> Furthermore, you're scripting around ebtables.This is bad for many reasons.
> There are ebtables-save and -restore, which work exactly the same way
> as iptables-save and -restore. There is no reason to script around ebtables.
The distribution which I have used did not have ebtables-svae and
Strange enough: http://packages.ubuntu.com/precise/amd64/ebtables/filelist
I agree with your points. I think my script can be useful to
initialize the ebtables tables.
And after that ebtables-save and ebtables-restore shall be used.
> Additionally, you don't even /need/ ebtables. You can filter everything
> in *filter FORWARD.
By means of iptables -A FORWARD -d 10.57.0.0/16 -m policy --pol none
--dir out -j DROP ?
Surprisely enough I still see the messages from ebtables rules which
are dropping unwanted packets.
It means I miss something in iptables rules. (rule with -s ?)
> Adding a bridge device and ebtables rules add unnecessary complexity on top.
> Using ebtables to filter and log packets, that the writer of the rule set forgot to
> take care of, does not except him from duty to take care of his rule set. A good
> way to filter packets destined for RFC1918 address space is to simply put the blocking rules on
> top of the rule chain of *filter FORWARD and use an ipset to store the different networks. You can even add
> explicit non matching entries to the list, so you can except certain networks or hosts from the rule.
Something like this (but of course with ipsets) :
iptables -A FORWARD -d 10.0.0.0/8 -j LOG --log-level info
iptables -A FORWARD -d 10.0.0.0/8 -j DROP
Have not had opportunity to test this idea yet.
Thanks a lot!
WBR & WBW, Vitaly
More information about the Users