Re: how to harden iptables rules?

[Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>]

[-- Attachment #1: Type: text/plain, Size: 5167 bytes --]

Hi.

On Wed, 2010-03-03 at 18:41 +0100, Pascal Hambourg wrote:
> > #accept outgoing packets by default
> > :OUTPUT ACCEPT [0:0]
> ACCEPT as a default policy is not so much hardening IMHO.
Yeah I know ^^,... but unfortunately software is used on my systems
which uses random source ports and not even a portrange is
configurable...
So I don't see a way to handle this except accepting output per
default :(


> > -A INPUT	-m state  --state ESTABLISHED,RELATED	-j ACCEPT
> Mostly agree, although I would drop some ICMP types such as redirect or
> source quench that may be harmful.
Why would ICMP packets match this rule? Are they (well at least errors
in response to some IP traffic) counted as RELATED?
But probably not things like echo-request, right? What should it relate
to?


> --reject-with-tcp-reset is more appropriate for TCP packets. DROP is
> more appropriate for ICMP packets.
good point,...
Well I accpeted ICMP before so that should never happen, but as you've
adviced I'll probably change this and then it makes sense to drop them.
Well,.. does it really? I've always thought no ICMP error messages would
be generated on errors with ICMP packets?


> > if I block it completely (except echo-request) I also dont't get any  
> > ICMP error messages,
> 
> No, valid ICMP error messages have the ESTABLISHED state.
Ah :-) Great!


> > net.ipv6.bindv6only = 1
> This has not much to do with iptables and packet filtering.
Oh yes,.. it just slipped in when grepping all net stuff :D

btw: Now that I generally block ICMP (except echo-request and
ESTABLISHED),... would I still need things like:
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
?

And does someone know whether the log_martians setting only affects
whether martians are logged or also whether they're really discarded?


> > 3) What I never clearly understood: Do I have to handle (drop)  
> > "external packets" with:
> > -a source address of 127.x.x.x or :1
> > -a destination address of 127.x.x.x or :1
> > -a source address that matches one of the addresses of my other  
> > interfaces (e.g. 88.88.88.88 if that is the address of eth0)
> This is not critical, because the IP stack already discards such packets.
Great great,... and I again assumes that this happens "before" netfilter
comes in place?


> > And how would I block these things cleanly? Using addrtype?
> Possibly. Or by specifying addresses explicitly.
Well but what I've understood from what you've wrote, this kind of stuff
is discarded automatically by the kernel anyway,... so no need to take
manual actions, right?


> > 4) Should I generally drop packets with state=INVALID or perhaps not  
> > for packets from/to lo?
> Generally, yes. However you may make an exception on lo.
Yeah,.. I already thought about whether it makes sense to have
exceptions for lo on this...


> > 5) Is it necessary to do this or is it done automatically?
> > -p tcp ! --syn -m state   --state NEW	-j DROP
> > and (!) vice versa:
> > -p tcp   --syn -m state ! --state NEW	-j DROP
> 
> The behaviour of TCP conntrack depends on the kernel version and some
> kernel parameters (mainly net.netfilter.nf_conntrack_tcp_be_liberal).
> --state NEW may not imply --syn and vice versa.
Uhm... well now I don't know what I should do here ^^
I tried to find some documentation on nf_conntrack_tcp_be_liberal but
was not really able to do so... :(
I use always one of the recent kernel versions..


> > 6) When I accept packets for dedicated services (e.g. ssh) I can do  
> > one of those:
> > a) -A INPUT	--destination 88.88.88.88 --protocol tcp -m tcp  
> > --destination-port ssh --syn	-j ACCEPT
> > (if 88.88.88.88 is the address of eth0)
> > b) -A INPUT	--in-interface eth0 --protocol tcp -m tcp  
> > --destination-port ssh --syn	-j ACCEPT
> > c)  -A INPUT	--protocol tcp -m tcp --destination-port ssh --syn	-j ACCEPT
> > 
> > (c) Is probably a bad idea as it would allow ssh also on other interfaces
> > But is there (from a security point of view) and advantage between (a)  
> > and (b)?
> 
> (b) also allow connecting on another interface because Linux enforces
> the so-called "weak host model". It all depends on your needs. Do you
> want to filter by interface, address, none or both ?
Well in principle,.. filtering by interface would be totally ok for
me,... I just wanna prevent things like this (if they're possible at
all?!):
my interface has e.g. again the address 88.88.88.88
someone sends packets with destination address 88.88.88.11 to that
interface (which should be not handled by it)...

Again,.. if such evil is automatically dropped my the kernel I'm totally
fine with filtering by interface,.. if not I'd guess filtering by
address would be more secure...

uhm.... Rethinking this scenario, I'd guess that packets with
dest=88.88.88.11 would be considered as packets to be forwarded, right?
So they should be either dropped because of my:
:FORWARD DROP
policy or my:
net.ipv4.ip_forward=0
right?



Again,... lots of thanks for your answers :)
Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]