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