On 8/20/19 12:39 PM, Timo Sigurdsson wrote: > Hi again, > > Matt Darfeuille schrieb am 22.07.2019 14:00: > >> On 7/22/2019 12:39 PM, Timo Sigurdsson wrote: >>> Hi, >>> >>> some of you may be aware of the new default firewall backend in Debian 10 >>> alias Buster, i.e. Buster defaults to nftables and all of xtables programs >>> (iptables, ip6tables, etc.) are merely symlinks to iptables-nft, >>> ip6tables-nft, etc. This means you can use the iptables syntax, but will >>> actually get nftables rules. As I am planning to upgrade my router machine >>> to >>> Debian 10 in the near future, I was wondering whether I should take any >>> precautions prior or during the upgrade with regards to shorewall. I use >>> shorewall in a dual-stack setup with one WAN interface and several LAN-side >>> interfaces and zones. >>> >> >> To air on the side of caution, I would test Shorewall and the desired >> configuration using a VM or a chroot when moving away from Iptables and >> report back any issues you might encounter. > > As I mentioned before, I migrated one system to Debian Buster, using the new > default firewall backend nftables. Now, after a few weeks of use, I can see > one difference of behavior that I have no explanation for at this point. I > see traffic dropped, that I haven't seen being dropped before. > > I have a service listening on port 443 and for that I have this rule in my > rules file: > ACCEPT net $FW tcp,udp 443 - > - 5/min > > After upgrading to Debian Buster, I found a couple of log entries which look > like this: > net-fw DROP IN=eth0 OUT= MAC=[SNIP] SRC=[PUBLIC IP ADDR] DST=[IP OF $FW] > LEN=44 TOS=0x00 PREC=0x00 TTL=63 ID=28969 DF PROTO=TCP SPT=41498 DPT=443 > WINDOW=29200 RES=0x00 SYN URGP=0 > > Now, the first thing that comes to mind is that the packets are dropped due > to rate limiting. But for various reasons, I don't think that's the case here: > 1) My service listening on port 443 hasn't logged any connections coming from > the source addresses dropped by Shorewall prior to the log entry. > 2) The particular machine is actually in a DMZ behind another firewall which > forwards port 443 but applies the same rate limiting. So, the machine should > usually not see more connections anyway. > 3) Most importantly, I went through the log files of that machine for a > period of 6 months prior to the upgrade to Buster and couldn't find a single > instance in which packets to port 443 were dropped. But now I see 3-5 such > log entries per week. > > Please note, though, that the service itself doesn't seem to be impacted. > Whenever I try to connect to that service myself (externally and internally), > it works just fine. > > So, by now I'm suspecting that the dropped packets must be some form of > illegitimate traffic, like a wrong combination of tcp flags or so. The > interface in question has the following options set in the interfaces file: > tcpflags,nosmurfs,rpfilter,logmartians,sourceroute=0,arp_filter=1,arp_ignore > > Plaese also note, I didn't change the firewall rules after the update. I > merely updated the shorewall.conf file for the new Shorewall version. But > other than the new format of the DROP_DEFAULT directive (which was "DROP" > before and is now "Broadcast(DROP),Multicast(DROP)"), I see nothing that > would warrant a different behavior for dropping packets or logging dropped > packets. > > Is there any simple way of figuring out why these packets are dropped (other > than using a packet sniffer or so)? >
Your rule is limited to 5 connections per minute *from all sources*. If you want a per-source-ip limit, you must change the rule to: ACCEPT net $FW tcp,udp 443 - - s:5/min -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
