[Firehol-support] dmesg and logging overflowing

[Phil Whineray]

Hi Mark

This isn't a complete answer but hopefully will increase your
understanding enough to help you move forward.

On Wed, Dec 30, 2015 at 01:14:12PM +0100, Mark de Ruijter wrote:
> Hi,
> 
> I've asked this on numerous places on the web, but couldn't get any solid
> answers. So now I turn to developers and users of Firehol. I've used Firehol
> for many years and was very happy with it. But, ever since the update, I
> can't get rid of the logs;
> 
> I've been running a firehol firewall for many years, but since I upgraded to
> Ubuntu 15.10 my dmesg and syslog are filling to the brim with these;
> 
> [Tue Dec 29 11:52:40 2015] IN-InetZiggo:IN=eth4 OUT=
> MAC=bc:5f:f4:1c:90:b4:00:01:5c:6c:7c:46:08:00 SRC=95.101.203.240
> DST=83.84.30.242 LEN=40 TOS=0x08 PREC=0x40 TTL=60 ID=10038 DF PROTO=TCP
> SPT=80 DPT=57036 WINDOW=0 RES=0x00 RST URGP=0
> [Tue Dec 29 11:53:02 2015] IN-InetZiggo:IN=eth4 OUT=
> MAC=bc:5f:f4:1c:90:b4:00:01:5c:6c:7c:46:08:00 SRC=74.125.136.156
> DST=83.84.30.242 LEN=40 TOS=0x08 PREC=0x40 TTL=50 ID=49737 PROTO=TCP SPT=443
> DPT=49443 WINDOW=0 RES=0x00 RST URGP=0
> [Tue Dec 29 11:53:14 2015] IN-InetZiggo:IN=eth4 OUT=
> MAC=bc:5f:f4:1c:90:b4:00:01:5c:6c:7c:46:08:00 SRC=74.125.136.17
> DST=83.84.30.242 LEN=40 TOS=0x08 PREC=0x40 TTL=50 ID=64713 PROTO=TCP SPT=443
> DPT=54200 WINDOW=0 RES=0x00 RST URGP=0
> [Tue Dec 29 11:53:14 2015] IN-InetZiggo:IN=eth4 OUT=
> MAC=bc:5f:f4:1c:90:b4:00:01:5c:6c:7c:46:08:00 SRC=74.125.136.17
> DST=83.84.30.242 LEN=40 TOS=0x08 PREC=0x40 TTL=50 ID=64714 PROTO=TCP SPT=443
> DPT=54200 WINDOW=0 RES=0x00 RST URGP=0
> [Tue Dec 29 11:53:59 2015] IN-InetZiggo:IN=eth4 OUT=
> MAC=bc:5f:f4:1c:90:b4:00:01:5c:6c:7c:46:08:00 SRC=74.125.136.139
> DST=83.84.30.242 LEN=40 TOS=0x08 PREC=0x40 TTL=50 ID=33101 PROTO=TCP SPT=443
> DPT=49439 WINDOW=0 RES=0x00 RST URGP=0
> [Tue Dec 29 11:54:49 2015] IN-InetZiggo:IN=eth4 OUT=
> MAC=bc:5f:f4:1c:90:b4:00:01:5c:6c:7c:46:08:00 SRC=74.125.136.102
> DST=83.84.30.242 LEN=40 TOS=0x08 PREC=0x40 TTL=50 ID=30637 PROTO=TCP SPT=443
> DPT=49501 WINDOW=0 RES=0x00 RST URGP=0
> [Tue Dec 29 11:54:49 2015] IN-InetZiggo:IN=eth4 OUT=
> MAC=bc:5f:f4:1c:90:b4:00:01:5c:6c:7c:46:08:00 SRC=74.125.136.102
> DST=83.84.30.242 LEN=40 TOS=0x08 PREC=0x40 TTL=50 ID=30638 PROTO=TCP SPT=443
> DPT=49501 WINDOW=0 RES=0x00 RST URGP=0
> 
> And I don't know why.
> Take for instance this;
> 
> PASS-unknown:IN=br0 OUT=eth4 MAC=00:1b:21:09:ef:5a:64:27:37:19:66:42:08:00
> SRC=192.168.40.54 DST=54.230.13.39 LEN=40 TOS=0x00 PREC=0x00 TTL=127
> ID=21253 DF PROTO=TCP SPT=49419 DPT=443 WINDOW=0 RES=0x00 ACK RST URGP=0

All of the packets above, including this one are TCP RST [1] (reset)
packets. These are not run-of-the-mill connection packets.

> 
> This seems to be a packet for a HTTPS site at 52.230.13.39, from the bridge
> br0 on the LAN, going via eth4 to the internet. Why would that show up in
> dmesg?

The PASS-unknown: prefix means that no rule matched the packet at all.

How can this happen when you have:

>     client all      accept
>     server all      accept

In your config? Because firehol sets up a stateful firewall: unless
a packet is starting a connection (TCP SYN) it must already belong to
an existing connection to be allowed.

This "belonging" is determined by the Linux kernel connection tracker.
It seems either it is losing track of the connection before the RST is
sent or that they were not part of a valid connection to start with.

If it were me, at this point I would try to capture tcpdump of a
complete connection finishing with a RST (so dump from the LAN side)
to check there was a proper connection to start with. If so, the
next thing to check will be whether the connection tracker timeout [2]
is happening before the client side.

Are you seeing this? [3]

Phil

[1] http://stackoverflow.com/questions/7735618/tcp-rst-packet-details
[2] https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt
[3] https://ask.wireshark.org/questions/13986/why-tcp-reset-sent-after-receive-finack-packet