[strongSwan] Avoid leakage of packets addressed to/from private IP space

[Vitaly Repin]

Hello,

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[1]
> 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[2].
> 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
ebtables-restore scripts.
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
--log-prefix "IPTABLES-BLKO"
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