Hi Tom, Tom Eastep schrieb am 20.08.2019 22:38:
> 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 > You're right, I forgot about that even though that was an intentional decision when I configured the rules. Nevertheless, I still don't think that this is the issue here. I just checked my server logs again for the times around the dropped packets. There were *no* connections around these times. In the case of the log entry that I've shown above, the last connection seen by the daemon listening on port 443 was about 5.5 hours before the dropped packet and the next one was almost 2 hours after the dropped packet (obviously not a busy server ;)). The shortest timespan between a connection and a dropped packet in the last two weeks was 30 minutes. And again, rate limiting as the cause of the issue would not explain why I haven't seens such dropped packets before with the same configuration. Thanks and regards, Timo _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
