Re: dmesg and logging overflowing

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" <[email protected]> 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
_______________________________________________
Firehol-support mailing list
[email protected]
http://lists.firehol.org/mailman/listinfo/firehol-support