On Wed, 23 Mar 2016 14:53:37 -0500
Robert Nichols <rnicholsNOSPAM@xxxxxxxxxxx> wrote:
> On 03/22/2016 01:55 PM, Christian Robottom Reis wrote:
> > Hello there,
> >
> > In periodically looking at my firewall logs I've always noticed that
> > from time to time a certain pattern will show up in my logs which
> > indicates that a legitimate stream which should have been marked
> > RELATED/ESTABLISHED isn't. I have the following rules set up to allow
> > related incoming traffic:
> >
> > -A INPUT -i eth3 -p tcp -m tcp --dport 10000:65535
> > -m state --state RELATED,ESTABLISHED -j ACCEPT
> > -A INPUT -i eth3 -p tcp -m tcp --sport 10000:65535
> > -m state --state RELATED,ESTABLISHED -j ACCEPT
> >
> > AIUI this is what allows the response from a website request to be
> > targeted ACCEPT in the INPUT chain. However, my logs show that sometimes
> > this doesn't work. Here's a recent example:
> >
> > [89003.161127] IN=eth3 OUT= MAC=XXX SRC=104.73.89.127 DST=XXX
> > LEN=1472 TOS=0x00 PREC=0x00 TTL=53 ID=10958 DF PROTO=TCP SPT=80
> > DPT=44709 WINDOW=3775 RES=0x00 ACK URGP=0
> >
> > [89003.497964] IN=eth3 OUT= MAC=XXX SRC=104.73.89.127 DST=XXX
> > LEN=1472 TOS=0x00 PREC=0x00 TTL=53 ID=17058 DF PROTO=TCP SPT=80
> > DPT=44710 WINDOW=3385 RES=0x00 ACK URGP=0
> >
> > [89049.561143] IN=eth3 OUT= MAC=XXX SRC=104.73.89.127 DST=XXX
> > LEN=1472 TOS=0x00 PREC=0x00 TTL=53 ID=26347 DF PROTO=TCP SPT=80
> > DPT=44932 WINDOW=1062 RES=0x00 ACK URGP=0
>
> I see those too. When I look back at the packet captures for those times
> I never see any other traffic to or from that IP address, so of course
> they don't match the RELATED/ESTABLISHED rule. Just part of the noise.
>
> I routinely capture packets passing through my router, filtering out
> ARP noise, Netflix video streaming, Skype calls, and the like. When
> something unusual happens, it's very useful to see what was going on
> at that time. I keep the most recent ~1 Gigabyte of that in a rotating
> buffer. In a case like this, I can see what was _not_ going on.
Such packets are often called 'spurious'. They are actually 'INVALID': packets for which netfilter has no clue why they arrived and no clue where to send them; they're obviously for ESTABLISHED conns, but netfilter has no record of them.. There are a lot of INVALID packets that float around. Most (or many) are for conns that have already been reset or closed; some may be DoS or DDoS attacks.
Handle them as early as possible: in mangle:PREROUTING. LOG them if you want. DROP them because they aren't going anywhere anyway. There's no sense in wasting CPU cycles processing INVALID packets.
Try:
iptables -t mangle -I 1 PREROUTING -m state --state INVALID \
-j LOG --log-prefix "Denied:mangle:INVALID "
iptables -t mangle -I 2 PREROUTING -m state --state INVALID -j DROP
The log prefix identifies the invalid packets as such in the log file.
N
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
