On 9/14/19 12:45 AM, Timo Sigurdsson wrote: > Hi, > > after upgrading two machines from Debian Stretch to Debian Buster (shorewall > 5.0.15.6 to 5.2.3.2), I noticed some dropped or rejected packet that I > haven't seen before with the same rules. It seems to me that conntrack > doesn't work the same as before. Some packets are treated as new while they > aren't. Please note, it doesn't seem to make a difference whether I use the > iptables-nft or iptables-legacy backend. I can see the messages in both cases. > > A few examples from both machines: > fw-dmz REJECT IN= OUT=enp3s0 SRC=2001:22b8:3498:9504:a9c3:4bd0:d4e9:6641 > DST=2001:22b8:3498:9504:80ff:5dff:fe20:4937 LEN=60 TC=0 HOPLIMIT=64 > FLOWLBL=602349 PROTO=UDP SPT=53 DPT=8077 LEN=20 > > The machine runs a DNS server and internal networks are allowed to access it. > Once a day, the machine reconnects its PPPoE WAN connection and shorewall, > shorewall6 as well as the DNS server are reloaded. Every time this happens, I > get log messages such as this with the destination address of a particular > client. It looks to me as if this packet is a reply to a legitimate packet > from the dmz zone, but it is treated as a new connection from the firewall. > Occasionally I can also see such rejected packets on port 53 with other > destination addresses, but these are much less frequent and I can't make out > a pattern in them. > > On a different machine which accepts connections to port 443 I also see > replies being treated as new from time to time: > fw-net ACCEPT IN= OUT=eth0 SRC=192.168.226.19 DST=82.179.95.16 LEN=138 > TOS=0x00 PREC=0x00 TTL=64 ID=61910 DF PROTO=TCP SPT=443 DPT=8897 WINDOW=673 > RES=0x00 ACK PSH FIN URGP=0 > > Please note: For debugging purposes I changed the default policy of fw-net to > ACCEPT with logging enabled on this machine. Otherwise this packet would have > been rejected while it is in fact a reply to a previous connection that I can > see in my servers logs. > > One last example is with traffic passing through the firewall machine: > lan-int REJECT IN=enp1s0 OUT=enp4s0 MAC=00:0d:***:08:00 SRC=192.168.131.30 > DST=192.168.55.25 LEN=142 TOS=0x00 PREC=0x00 TTL=63 ID=59812 DF PROTO=TCP > SPT=3483 DPT=49894 WINDOW=235 RES=0x00 ACK PSH FIN URGP=0 > > In this case the zone int is allowed to access port 3483 on zone lan. Here > again the reply is being rejected, but this example here is actually the one > that makes the most sense to me. I can only see these packets being rejected > shortly after the firewall machine has been rebooted. Now it is logical that > after a reboot the firewall doesn't know about previous connections anymore. > But I'm wondering why I haven't seen such log messages before the upgrade to > Debian Buster. > > There are a couple of areas that might have possibly changed: > > 1) shorewall's logging behavior: > Maybe these packets were dropped all along but I never saw them in the logs? > When I upgraded the machine I updated the configuration accordingly. I didn't > change the log levels but I did update the default actions/macros like this: > -DROP_DEFAULT=Drop > -REJECT_DEFAULT=Reject > +BLACKLIST_DEFAULT="Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL" > +DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)" > +REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP)" >
That is the cause. The deprecated Drop and Reject actions silently dropped these "late DNS reply" packets. To avoid masking a DDOS attack using such packets, they are now logged (such a DDOS attack has actually been observed). When seen in small numbers, they can be safely ignored. -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
