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)? Thanks and regards, Timo _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
