All of lore.kernel.org
 help / color / mirror / Atom feed
* how to harden iptables rules?
@ 2010-03-03 16:20 Christoph Anton Mitterer
  2010-03-03 17:41 ` Pascal Hambourg
  0 siblings, 1 reply; 7+ messages in thread
From: Christoph Anton Mitterer @ 2010-03-03 16:20 UTC (permalink / raw)
  To: netfilter

Hi.

I'm playing around with hardening my iptables setups at the institue  
and I'd have some questions on this.

First of all, the systems should have these default policies:
#drop incoming packets by default
:INPUT DROP [0:0]
#drop forwarded packets by default
:FORWARD DROP [0:0]
#accept outgoing packets by default
:OUTPUT ACCEPT [0:0]

So non of them is itself a "firewall" or a router.


What I always did until now was:
#basic rules
-A INPUT	--in-interface lo			-j ACCEPT
-A INPUT	-m state  --state ESTABLISHED,RELATED	-j ACCEPT
-A INPUT	--protocol icmp				-j ACCEPT

#rules for some services, e.g. allowing ssh, dns, etc.

#reject all other incomming packets
-A INPUT						-j REJECT  --reject-with icmp-port-unreachable
(I know that rejecting might be too friendly when I speak about  
hardening,.. but droping or tarpit gives the source no error  
information, which is at least a bad idea within the institute.)




1) Is there anything obvious that I should block in addition?


2) Regarding ICMP, I must admit that I'm not that IP geek to know  
which of ICMP I should block. I want however have ping allowed. I mean  
if I block it completely (except echo-request) I also dont't get any  
ICMP error messages, which is probably a bad thing, right?
btw: in sysctl I do this:
net.ipv4.conf.all.rp_filter=1
net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv6.bindv6only = 1


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)
-what about other bogus addresses like 0.0.0.0 or 255.255.255.255 or so?

Or does the kernel block such crap automatically? If so how?

And how would I block these things cleanly? Using addrtype? And how do  
I make sure that any "internal traffic" still comes through?


4) Should I generally drop packets with state=INVALID or perhaps not  
for packets from/to lo?


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


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)?



Lots of thanks,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: how to harden iptables rules?
  2010-03-03 16:20 how to harden iptables rules? Christoph Anton Mitterer
@ 2010-03-03 17:41 ` Pascal Hambourg
  2010-03-04 11:47   ` Christoph Anton Mitterer
  2010-03-04 12:34   ` how to harden iptables rules? Mart Frauenlob
  0 siblings, 2 replies; 7+ messages in thread
From: Pascal Hambourg @ 2010-03-03 17:41 UTC (permalink / raw)
  To: netfilter

Hello,

Christoph Anton Mitterer a écrit :
> 
> I'm playing around with hardening my iptables setups at the institue  
> and I'd have some questions on this.
> 
> First of all, the systems should have these default policies:
> #drop incoming packets by default
> :INPUT DROP [0:0]
> #drop forwarded packets by default
> :FORWARD DROP [0:0]
> #accept outgoing packets by default
> :OUTPUT ACCEPT [0:0]

ACCEPT as a default policy is not so much hardening IMHO.

> So non of them is itself a "firewall" or a router.

Huh ?

> What I always did until now was:
> #basic rules
> -A INPUT	--in-interface lo			-j ACCEPT

Agree.

> -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.

> -A INPUT	--protocol icmp				-j ACCEPT
> 
> #rules for some services, e.g. allowing ssh, dns, etc.
> 
> #reject all other incomming packets
> -A INPUT -j REJECT  --reject-with icmp-port-unreachable

--reject-with-tcp-reset is more appropriate for TCP packets. DROP is
more appropriate for ICMP packets.

> 2) Regarding ICMP, I must admit that I'm not that IP geek to know  
> which of ICMP I should block. I want however have ping allowed.

Accept "-p icmp --icmp-types echo".

> 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.

> net.ipv6.bindv6only = 1

This has not much to do with iptables and packet filtering.

> 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.

> -what about other bogus addresses like 0.0.0.0 or 255.255.255.255 or so?
> 
> Or does the kernel block such crap automatically? If so how?

This is done at the input and output routing decision, after PREROUTING
and before OUTPUT.

> And how would I block these things cleanly? Using addrtype?

Possibly. Or by specifying addresses explicitly.

> And how do  
> I make sure that any "internal traffic" still comes through?

Your first rule (-i lo) handles it.

> 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.

> 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.

> 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 ?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: how to harden iptables rules?
  2010-03-03 17:41 ` Pascal Hambourg
@ 2010-03-04 11:47   ` Christoph Anton Mitterer
  2010-03-05  0:00     ` Pascal Hambourg
  2010-03-04 12:34   ` how to harden iptables rules? Mart Frauenlob
  1 sibling, 1 reply; 7+ messages in thread
From: Christoph Anton Mitterer @ 2010-03-04 11:47 UTC (permalink / raw)
  To: netfilter

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: how to harden iptables rules?
  2010-03-03 17:41 ` Pascal Hambourg
  2010-03-04 11:47   ` Christoph Anton Mitterer
@ 2010-03-04 12:34   ` Mart Frauenlob
  2010-03-04 16:56     ` Pascal Hambourg
  1 sibling, 1 reply; 7+ messages in thread
From: Mart Frauenlob @ 2010-03-04 12:34 UTC (permalink / raw)
  To: netfilter

On 03.03.2010 18:41, Pascal Hambourg wrote:

> Christoph Anton Mitterer a écrit :

>> 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.

http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#ICMPCONNECTIONS
and the man page say different.

They don't talk about an icmp error message as a reply to a icmp
message, but just guessing, where's the differenece? why should
netfilter suddenly switch to ESTABLISHED for a icmp error reply?

Best regards

Mart

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: how to harden iptables rules?
  2010-03-04 12:34   ` how to harden iptables rules? Mart Frauenlob
@ 2010-03-04 16:56     ` Pascal Hambourg
  0 siblings, 0 replies; 7+ messages in thread
From: Pascal Hambourg @ 2010-03-04 16:56 UTC (permalink / raw)
  To: netfilter

Mart Frauenlob a écrit :
> On 03.03.2010 18:41, Pascal Hambourg wrote:
> 
>> No, valid ICMP error messages have the ESTABLISHED state.
> 
> http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#ICMPCONNECTIONS
> and the man page say different.

My mistake, I meant RELATED of course.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: how to harden iptables rules?
  2010-03-04 11:47   ` Christoph Anton Mitterer
@ 2010-03-05  0:00     ` Pascal Hambourg
  2010-03-05  2:48       ` IP-in-IP matching Andrew Kraslavsky
  0 siblings, 1 reply; 7+ messages in thread
From: Pascal Hambourg @ 2010-03-05  0:00 UTC (permalink / raw)
  To: netfilter

Christoph Anton Mitterer a écrit :
> 
>>> -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?

Yes, "valid" ICMP error messages are RELATED (not ESTABLISHED as I
wrongly stated).

> But probably not things like echo-request, right? What should it relate
> to?

ICMP echo requests are NEW, and "valid" (for conntrack) ICMP echo
requests are ESTABLISHED.

> Well,.. does it really? I've always thought no ICMP error messages would
> be generated on errors with ICMP packets?

An ICMP error message must not be sent in reply to an ICMP error
message, but may be sent in reply to an ICMP message that is not an
error type, such as echo.

> 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

Yes, because valid ICMP redirect messages are RELATED.

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

Martians are discarded anyway.

>>> 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?

This happens at the input routing decision between PREROUTING and INPUT
or FORWARD.

> 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?

Well, you're never too sure...

> 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)...

An interface should handle any local address, i.e. any address assigned
to itself or to any other interface of the system. Only packets with a
local destination go through the INPUT chains. Otherwise, it depend
whether forwarding is enabled or not : if yes, the packet is forwarded,
if not it is discarded at the input routing decision.

The question is : when a host has multiple interfarce, do you want to
allow packets on an interface but to the address of another interface ?
If yes (weak host model), just filter by interface. If no (strong host
model), filter by interface and by address.

> uhm.... Rethinking this scenario, I'd guess that packets with
> dest=88.88.88.11 would be considered as packets to be forwarded, right?

Yes if this address is not local.

> So they should be either dropped because of my:
> :FORWARD DROP
> policy or my:
> net.ipv4.ip_forward=0
> right?

Right.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* IP-in-IP matching
  2010-03-05  0:00     ` Pascal Hambourg
@ 2010-03-05  2:48       ` Andrew Kraslavsky
  0 siblings, 0 replies; 7+ messages in thread
From: Andrew Kraslavsky @ 2010-03-05  2:48 UTC (permalink / raw)
  To: netfilter


For IP-in-IP tunneling (4-in-4, 6-in-6, 4-in-6 and 6-in-4) traffic, is there way to conduct packet filtering on the inner IP packet when the traffic is being forwarded?

 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-03-05  2:48 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-03 16:20 how to harden iptables rules? Christoph Anton Mitterer
2010-03-03 17:41 ` Pascal Hambourg
2010-03-04 11:47   ` Christoph Anton Mitterer
2010-03-05  0:00     ` Pascal Hambourg
2010-03-05  2:48       ` IP-in-IP matching Andrew Kraslavsky
2010-03-04 12:34   ` how to harden iptables rules? Mart Frauenlob
2010-03-04 16:56     ` Pascal Hambourg

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.