iptables question: default DROP policy and TCP Three Way Handshake

johnnygear · 04-22-2012, 02:12 AM

Hi All,

My default policy for an iptables config I am working on is as follows:

Code:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

I understand that in most cases, because the OUTPUT chain default policy is DROP, 2 rules are required so traffic can flow both ways (INPUT and OUTPUT) - basically, everything that is requires throughfare must be whitelisted.

My question is regarding the TCP Three Way Handshake - currently the only rule I have for it is:

Code:

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

I believe I need an OUTPUT rule to allow the initial SYN packet out and also one to allow the final ACK packet. I was wondering if someone could help me to craft the most restrictive rules possible to allow this.

Here is what I have so far:

This is the conventional example I have seen:

Code:

iptables -A OUTPUT -p tcp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Can I get away with just this? If not, why not?

Code:

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

Is something like this possible in place of the above?
(not sure if I have the right flags - advice is welcome)

Code:

iptables -A OUTPUT -p tcp -m tcp --tcp-flags SYN SYN -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT

Thanks in advance.

Regards,

Johnny

acid_kewpie · 04-22-2012, 06:43 AM

RELATED status is for inspected protocols, like FTP. where a new connection comes into the system but is expected based on inspected data in another connection. If you don't think you are going to use those protocols, then you should be OK, although that does include ICMP error responses, which are very common and useful.

johnnygear · 04-22-2012, 06:59 AM

Quote:

Originally Posted by acid_kewpie

RELATED status is for inspected protocols, like FTP. where a new connection comes into the system but is expected based on inspected data in another connection. If you don't think you are going to use those protocols, then you should be OK, although that does include ICMP error responses, which are very common and useful.

Thanks for your response.

I think I may then need to use the RELATED state as well in that case.

If I add the RELATED state to my rule, will that open me up to anything other than 3 way handshakes?

Thanks again,

Johnny

acid_kewpie · 04-22-2012, 09:28 AM

related has nothing to do with three way handshakes, and I really don't know why you're specifically interested the handshake phase in the first place. You permit new, established and related connections... what's wrong with just leaving it at that? state tracking is a fundamental part of TCP/IP security, so why not use it properly?

es0teric · 04-22-2012, 03:18 PM

Unless you're super paranoid, you can just have a default DROP policy on the INPUT chain, but not the others. In terms of IP network layer security, that usually does the trick. If you can't trust connections originating from your system, then there are bigger problems with better solutions other than iptables.

johnnygear · 04-22-2012, 08:38 PM

Thanks for the responses everyone.

I am not paranoid(well, maybe just a little). I am just interested in security and all its implementations.

There are a few ways to look at this; For instance, if there is a vulnerability in the application layer, which leads to malicious code being executed on the system, then the right OUTPUT restrictions can potentially counter the attack. This example might not be the best case scenario, but it is most definitely not the worst. Security is about risk management; What attacks are possible, what attacks can be countered or disabled, and how one can best achieve that optimal state in the most efficient way.

Now personally, I am not going to go and re-write OpenSSH, Apache or any other common web facing application as it is an inefficient way to achieve security(and probably in vain as my coding skills are not that great); And we all know that these and many other applications have had exploitable vulnerabilities in the past(some more recently and for all intesive purposes zero day exploits may available for the right price/technically adept mind). A common response to this argument may be, if the data is too valuable to store on a box with web facing applications, don't store it there, but, in all honesty, that is a very prudish way of handling things. I think there can be a happy medium.

After saying all that, the point of my original post, was to try and better understand the way in which I can let the minimal requirements through. I am basically looking for a very strict base configuration. Furthermore, I currently have a limited knowledge of iptables and TCP/IP security and was just hoping to get a better understanding of state tracking and the three way handshake.

Thanks again for all the help.

Regards,

Johnny

EDIT:

From what I have read here: http://www.5dollarwhitebox.org/wiki/...Basic_IPTables

The rule below would more or less be the same as having a default ACCEPT policy for the OUTPUT chain. Is that correct?

iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

That is specifically what I am trying to avoid as per the default OUTPUT policy being DROP.