better to use state firewall or explicitly define what comes back in?

dividingbyzero · 06-02-2008, 10:54 AM

Hi.

Below is by no means a complete firewall, just wondering which approach
is more secure or better to use,

state tracking type firewall:

Code:

iptables -P INPUT DROP
iptables -P OUTPUT DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

or something like this

Code:

iptables -P INPUT DROP
iptables -P OUTPUT DROP

iptables -A INPUT -p tcp ! --syn --source-port 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

thanks

anomie · 06-02-2008, 12:23 PM

[ side note: Don't forget to allow loopback traffic. ]

Short answer is I am not sure it matters much with your tiny ruleset. For a more thorough analysis of some of the pros of a stateful firewall, I refer you to our friend wikipedia.

http://en.wikipedia.org/wiki/Stateful_firewall

win32sux · 06-02-2008, 04:58 PM

Quote:

Originally Posted by dividingbyzero

Below is by no means a complete firewall, just wondering which approach
is more secure or better to use,

state tracking type firewall:

Code:

iptables -P INPUT DROP
iptables -P OUTPUT DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

or something like this

Code:

iptables -P INPUT DROP
iptables -P OUTPUT DROP

iptables -A INPUT -p tcp ! --syn --source-port 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

In your first example, only packets which are part of an already established connection (or related to one) will be sent to ACCEPT. In your second example, all packets with a source port of 80 which are not SYN packets will be sent to ACCEPT (really bad idea). The first example is clearly much tighter than the second. And it's also more functional, as your second example doesn't have any way to deal with ICMP error message packets that the HTTP server might throw back at you (RELATED state). BTW, it's a good idea to use stateful filtering for outbound packets too.

dividingbyzero · 06-02-2008, 09:13 PM

thanks guys! And the state on OUTBOUND was gonna be a new question but you beat me to it.

So if I have a tcp connection, there isn't a need to explicitly allow icmp on the INPUT like destination-unreachable, etc., since the state check on the inbound will also allow related icmp errors?

Also my firewall will allow in icmp echo-reply, destination-unreachable, and time-exceeded and on the OUTPUT allow echo-request, is this good icmp rules?

thanks

win32sux · 06-02-2008, 09:36 PM

Quote:

Originally Posted by dividingbyzero

thanks guys! And the state on OUTBOUND was gonna be a new question but you beat me to it.

Well, the general idea is pretty much the same.

Quote:

So if I have a tcp connection, there isn't a need to explicitly allow icmp on the INPUT like destination-unreachable, etc., since the state check on the inbound will also allow related icmp errors?

Correct, the RELATED match in your INPUT chain will match any received ICMP errors which are, ummm, related to an outgoing TCP/UDP connection.

Quote:

Also my firewall will allow in icmp echo-reply, destination-unreachable, and time-exceeded and on the OUTPUT allow echo-request, is this good icmp rules?

For incoming ICMP errors related to outgoing TCP/UDP connections you just need to make sure you have a rule for packets in state RELATED in your INPUT chain. To allow your box to respond to pings, you just need to make sure you have a rule in your INPUT chain allowing ICMP echo requests, and the generic ESTABLISHED match in your OUTPUT chain will take care of the echo reply.

dividingbyzero · 06-03-2008, 09:18 PM

Thanks, but I read alot that allowing someone to ping you
isn't a good idea. Can you elaborate on this? And if it's a
good idea, what are the benefits of allowing someone to ping
my home machine that isn't a server or anything?

Thanks again

win32sux · 06-04-2008, 12:34 AM

Quote:

Originally Posted by dividingbyzero

Thanks, but I read alot that allowing someone to ping you
isn't a good idea. Can you elaborate on this? And if it's a
good idea, what are the benefits of allowing someone to ping
my home machine that isn't a server or anything?

When you read that it wasn't a good idea, what were the reasons they provided?

If you don't have any need to have your box respond to ICMP echo requests then don't do it. That's kind of the point of a packet firewall, it lets you allow only the packets which you need. Any other packets represent an unnecessary risk. It's a concept applicable not just to packet filtering, but anything security-related.

Personally, neither my laptop nor desktop respond to ICMP echo requests (or, most of the time, to anything else for that matter). However, I don't believe I've ever installed a server in which I didn't have it respond to ICMP echo requests. Mainly because the convenience outweighed the risk in those cases. But having my desktop/laptop respond to ICMP echo requests does nothing for me regarding convenience.

If you do have a need to respond to ICMP echo requests I would suggest you use the limit or recent matches, as they can help prevent certain types of abuse. Also, specify that you only want to allow ICMP packets which aren't fragmented. There's plenty of examples on the Web.

unixfool · 06-04-2008, 02:09 PM

Where I work, we rely on using pings to troubleshoot. What we do is either tell the client to allow pings when troubleshooting is needed (which sometimes slows down the troubleshooting process, as they have to submit a change request to allow pings at the firewall), or create a rule that blocks all but certain types of pings (there are 18 types).

You can also only allow pings to/from certain trusted hosts.

And, as win32sux states, you can threshold icmp and still have certain types allowed. It all depends on your needs.