LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 04-22-2012, 02:12 AM   #1
johnnygear
LQ Newbie
 
Registered: Apr 2012
Posts: 6

Rep: Reputation: Disabled
iptables question: default DROP policy and TCP Three Way Handshake


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
 
Old 04-22-2012, 06:43 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966
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.
 
Old 04-22-2012, 06:59 AM   #3
johnnygear
LQ Newbie
 
Registered: Apr 2012
Posts: 6

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by acid_kewpie View Post
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

Last edited by johnnygear; 04-22-2012 at 07:00 AM.
 
Old 04-22-2012, 09:28 AM   #4
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966
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?
 
Old 04-22-2012, 03:18 PM   #5
es0teric
Member
 
Registered: Apr 2007
Distribution: Ubuntu
Posts: 105

Rep: Reputation: 19
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.
 
Old 04-22-2012, 08:38 PM   #6
johnnygear
LQ Newbie
 
Registered: Apr 2012
Posts: 6

Original Poster
Rep: Reputation: Disabled
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.

Last edited by johnnygear; 04-22-2012 at 08:43 PM. Reason: new info
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
tcpdump shows packages even if iptables policy is set to DROP paliga Linux - Networking 7 06-05-2011 11:37 AM
iptables / output *drop* policy reverse Linux - Security 3 11-22-2007 10:39 AM
not work: iptables -I INPUT 5 -m state --state NEW -m tcp -p tcp --dport 3306 -j DROP abefroman Linux - Security 1 07-18-2007 08:19 AM
Iptables drop policy problem Dakkar Linux - General 5 10-18-2006 02:38 PM
WU-FTPD and IPTABLES DROP Policy Cpare Linux - Networking 0 10-23-2001 09:19 PM


All times are GMT -5. The time now is 06:28 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration