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 <[email protected]>: > 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 _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
