Prev: Character encoding in text console
Next: Installing without the Slackware setup script
From: William Hunt on 20 Apr 2010 22:32

Seems like most firewalling documentation suggests DROP'ing
all --state INVALID packets. eg.,

iptables -A INPUT -m state --state INVALID -j DROP

so I hook that up with a -j LOG to see what it catches.
About half of that is HTTP which otherwise seem legitimate.
What am I missing ? I don't want to miss legitimate hits
but i don't want security holes, either.

Thanks in advance,
--
William Hunt, Portland Oregon USA
From: Grant on 20 Apr 2010 23:37
On Tue, 20 Apr 2010 19:32:20 -0700, William Hunt <wjh(a)prv8.net> wrote:

>
>Seems like most firewalling documentation suggests DROP'ing
>all --state INVALID packets. eg.,
>
> iptables -A INPUT -m state --state INVALID -j DROP
>
>so I hook that up with a -j LOG to see what it catches.
>About half of that is HTTP which otherwise seem legitimate.
>What am I missing ? I don't want to miss legitimate hits
>but i don't want security holes, either.

I've found state INVALID to be not useful, seems to catch the wrong stuff.

Basically disallow uninvited traffic in to system, unless you're running
a server.

Invited traffic is the return stuff for outgoing requests.

Exception to this is local DHCP both ways and perhaps DNS replies that
are slow and arrive after the UDP pseudo-connection times out.

Grant.
--
http://bugs.id.au/
From: Sylvain Robitaille on 23 Apr 2010 13:21
William Hunt wrote:

> ...
> iptables -A INPUT -m state --state INVALID -j DROP
>
> so I hook that up with a -j LOG to see what it catches.
> About half of that is HTTP which otherwise seem legitimate.
> What am I missing ? I don't want to miss legitimate hits
> but i don't want security holes, either.

Perhaps "man iptables" could help?

state
This module, when combined with connection tracking, allows
access to the connection tracking state for this packet.

--state state
.... Possible states are INVALID meaning that the
packet could not be identified for some reason ...

--
----------------------------------------------------------------------
Sylvain Robitaille syl(a)encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
From: William Hunt on 25 Apr 2010 18:27
On Wed, 21 Apr 2010, Grant wrote:
> On Tue, 20 Apr 2010 19:32:20 -0700, William Hunt <wjh(a)prv8.net> wrote:
>>Seems like most firewalling documentation suggests DROP'ing
>>all --state INVALID packets. eg.,
>> iptables -A INPUT -m state --state INVALID -j DROP
>>so I hook that up with a -j LOG to see what it catches.
>>About half of that is HTTP which otherwise seem legitimate.
>>What am I missing ? I don't want to miss legitimate hits
>>but i don't want security holes, either.
>
> I've found state INVALID to be not useful, seems to catch the wrong stuff.

I've been slogging thru netfilter.org and googling all kinds of
variations of "iptables netfilter --state INVALID", but all i find
is advice to simply drop all incoming INVALID - anything not NEW,
ESTABLISHED or RELATED. I haven't (yet) found any discussion of
--state INVALID being unreliable or quirky. I found some guy's
rc.firewall :^) which i read and meditated on at some length.
That has lots of good stuff in it but nada INVALID.
I remain befuddled.


> Basically disallow uninvited traffic in to system, unless you're running
> a server. Invited traffic is the return stuff for outgoing requests.
> Exception to this is local DHCP both ways and perhaps DNS replies that
> are slow and arrive after the UDP pseudo-connection times out.
> Grant.

Right. But this box is a cheap virtual server with only a single
(public) interface, plenty of bandwidth, and no LAN's. so your
rc.firewall isn't appropriate w/o mod.

Current filter basically DROP's all incoming NEW connections except
ssh, smtp+imap, http, and ping. Also some address filters, rate limits,
and paranoia stuff. all outbound is allowed. all incoming ESTABLISHED
and RELATED is accepted. That leaves incoming INVALID, which get
DROP'd.

I'm just curious that so many of these INVALID (50%) are DPT=80,
(and 25% DPT=25), and not wanting to miss any legitimate traffic.

I'm afraid I'll have to crack open some CS101 Network Fundamentals
before I will be able to wrap my puny primate brain around this.
and now your rc.firewall shows me that i will need to cover
/proc/sys/net/ipv4/yadayada too. oh well.

Thanks for helping, Grant.

--
William Hunt, Portland Oregon USA
From: William Hunt on 25 Apr 2010 18:44
On Fri, 23 Apr 2010, Sylvain Robitaille wrote:
> William Hunt wrote:
[...]
>
> Perhaps "man iptables" could help?
>
> state
> This module, when combined with connection tracking, allows
> access to the connection tracking state for this packet.
>
> --state state
> .... Possible states are INVALID meaning that the
> packet could not be identified for some reason ...

Thanks Sylvain. I have RTFM and I have STFW but haven't yet GAFC.
I will make appropraite sacrifice before Bob.
The Ritual of the Refreshing Beverage should do.
Maybe twice.

--
William Hunt, Portland Oregon USA
 |  Next  |  Last
Pages: 1 2
Prev: Character encoding in text console
Next: Installing without the Slackware setup script