[Firehol-support] dmesg and logging overflowing

Wed Dec 30 21:34:23 CET 2015

Also, which FireHOL version are you using?

  FIREHOL_LOG_DROP_INVALID

only appears in 3.0.0-rc2 and later.

On Wed, Dec 30, 2015 at 09:12:46PM +0100, rider wrote:
> Thanks again. But yes, I've seen that, the top of my firehol file is now;
> 
> version 6
> 
> FIREHOL_LOG_MODE = "NFLOG"
> FIREHOL_LOG_LEVEL = 6
> 
> FIREHOL_DROP_ORPHAN_TCP_ACK_FIN=1
> FIREHOL_LOG_DROP_INVALID=0
> 
> And still I get these in dmesg
> 
> [Wed Dec 30 21:02:56 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=31640 PROTO=TCP SPT=443
> DPT=56805 WINDOW=0 RES=0x00 RST URGP=0
> [Wed Dec 30 21:02:56 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=31641 PROTO=TCP SPT=443
> DPT=56805 WINDOW=0 RES=0x00 RST URGP=0
> 
> So it doesn't seem to work...
> 
> And I have little to no idea why.
> 
> Phil Whineray schreef op 2015-12-30 19:13:
> >Have you seen this?
> >
> >https://firehol.org/guides/firehol-welcome/#the-log
> >On 30 Dec 2015 17:19, "rider" <rider at ridersoft.net> wrote:
> >
> >>Hi, thanks, that gives some insights.
> >>
> >>But I can't control the clients connecting to me. And I have quite a
> >>bit of portscanning and other loging attemps, could that be the
> >>cause?
> >>
> >>Right now dmesg and syslog are all but unusable, is there a way to
> >>just turn this logging off?
> >>
> >>Phil Whineray schreef op 2015-12-30 14:54:
> >>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