LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
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 08-16-2012, 06:26 AM   #1
mojorisin
LQ Newbie
 
Registered: Aug 2012
Posts: 6

Rep: Reputation: Disabled
iptable rules recommended?


Hey,

I'v got some questions regarding iptables. I'm running a centos machine as a webserver.

I'm using the following rules right now. Can this setup be considered somehow secure or do you have any recommendations/suggestions/feedback?

Code:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             127.0.0.0/8         reject-with icmp-port-unreachable 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ftp 
ACCEPT     tcp  --  anywhere             anywhere            multiport dports vcom-tunnel,teradataordbms,8003,8004,8005,8006,8007,http-alt,8009,8010 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ndmp 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:3127
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere
Is iptables useful to prevent ddos, syn, pod etc. attacks? I discovered some very interesting examples on the internet where somebody is using like a ton of rules to prevent attacks of any kind. E.g. http://forum.ovh.de/showpost.php?p=58125&postcount=18 Does such a huge set of rules make any sense to you or does it more harm than good?

Thanks in advance
 
Old 08-16-2012, 03:40 PM   #2
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,896

Rep: Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774
I can't really comment on all of the questions that you ask, and i'm always a bit suspicious about my ability to read through other people's iptables rulesets sensibily, but...

Quote:
Originally Posted by mojorisin View Post
I discovered some very interesting examples on the internet where somebody is using like a ton of rules to prevent attacks of any kind. E.g. http://forum.ovh.de/showpost.php?p=58125&postcount=18 Does such a huge set of rules make any sense to you or does it more harm than good?
ddos attacks are hard to do anything about in iptables. At some point, if the attacker(s) are prepared to go that far, the attack can deliver enough packets to be more than your system and the infrastructure feeding it can handle. At that point, you are in trouble, but maybe your upstream can do something to help, maybe with sensible measures in iptables you can avoid making matters worse...

I wouldn't really regard the example that you have given as a totally unrealistic number of rules. The anti-portscan measures are a bit over the top, and there is some stuff done in iptables that would, imho, be better done in setting up kernel parameters using sysconfig.
The section described as conn tracking doesn't really seem to do the thing that I'd expected a conntrack section to do (it uses a handful of rules to allow port 1024 traffic). The ssh section rate limits to the ssh port; having a 'blacklist' via something like fail2ban would make me feel happier, but then I don't really know how ssh is set up in this case (and there are multiple options).

There are a few sections starting '#maximal 20 verbindungen in einer minute erlauben' that look as if they may be useful against plain DoS attacks, but I have doubts how much they do against DDoS.

Quote:
Originally Posted by mojorisin View Post
Does such a huge set of rules make any sense to you or does it more harm than good?
Well, it is not really the size of the ruleset, per se, but the amount of processing that is involved. The argument is made here that a large set of chains, each chain being short and stubby, is an efficient way of writing a ruleset. Of course, you also have to take into account that some packet flows have more traffic in them than others and you have to be particularly careful with the flows with the most packets in them, particularly if they are the ones which the suspected evildoers are trying to pump up in order to overload your system.
 
Old 08-18-2012, 08:53 AM   #3
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,782
Blog Entries: 1

Rep: Reputation: 413Reputation: 413Reputation: 413Reputation: 413Reputation: 413
Can you post the iptables commands you're using to generate this? It looks awfully open to me, but I may be misinterpreting the output.

In general, the idea is to set your policies to drop absolutely everything and then add rules to allow only the traffic you KNOW you want to allow.
 
Old 08-18-2012, 10:02 AM   #4
KinnowGrower
Member
 
Registered: May 2008
Location: Toronto
Distribution: Centos && Debian
Posts: 341

Rep: Reputation: 34
Quote:
Originally Posted by mojorisin View Post
Is iptables useful to prevent ddos, syn, pod etc. attacks? I discovered some very interesting examples on the internet where somebody is using like a ton of rules to prevent attacks of any kind. E.g. http://forum.ovh.de/showpost.php?p=58125&postcount=18 Does such a huge set of rules make any sense to you or does it more harm than good?

Thanks in advance
Default firewall policy is ACCEPT for your firewall. It means any packet that did not match any rules in any one of the chains (INPUT, FORWARD, OUTPUT) will be accepted. So that is NOT what you want. The best practice is make default firewall policy DROP and then allow only the required traffic. The link you referred in your post also tell how to achieve that. Here are the excerpts from that link
Code:
# Default-Policies setzen
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT DROP
sudo iptables -P FORWARD DROP
The default ACCEPT policy can be seen on first line in the output in your post
Code:
Chain INPUT (policy ACCEPT)
 
Old 08-20-2012, 04:30 AM   #5
mojorisin
LQ Newbie
 
Registered: Aug 2012
Posts: 6

Original Poster
Rep: Reputation: Disabled
Thanks to all of you guys for the huge feedback!!!

Quote:
Originally Posted by Hangdog42 View Post
Can you post the iptables commands you're using to generate this? It looks awfully open to me, but I may be misinterpreting the output.

In general, the idea is to set your policies to drop absolutely everything and then add rules to allow only the traffic you KNOW you want to allow.
Code:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 3127 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 8001,8002,8003,8004,8005,8006,8007,8008,8009,8010 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -j REJECT
iptables -A FORWARD -j REJECT
Since you all gave a broad hint that the current applied rules are totally messed up I'm looking for a tutorial I can start with/base my settings on. The link I posted in my first post is just to much for me to start with because I don't really know what all these rules are doing. I found these two links and I would really appreciate if you could tell me if this is something straight I can start with (or if you have other tutorials, which are recommended):

http://www.pettingers.org/code/firewall.html
http://www.cyberciti.biz/faq/rhel-fe...tion-tutorial/

Last edited by mojorisin; 08-20-2012 at 05:09 AM.
 
Old 08-25-2012, 08:31 AM   #6
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,782
Blog Entries: 1

Rep: Reputation: 413Reputation: 413Reputation: 413Reputation: 413Reputation: 413
Sorry, but I need to be a bit blunt. You don't really have a firewall. Kinnogrower is right, you need to set all your policies to DROP, which will stop everything until you add some other rules. Once you do that, most of your other rules will probably start working the way you intend since they are almost all ACCEPT. That said, you've got a few rules that are REALLY unclear as to their purpose:

Quote:
iptables -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
I can't for the life of me figure out what this rule is intended to do. I mean I know that this is trying to stop external access to lo, but if that is actually happening, you've got bigger problems.

Quote:
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
What are you trying to allow with this? I think that question needs to be answered for all the rules. If you know what you're trying to allow, that should help figure out what rules you need.
 
Old 08-27-2012, 06:52 AM   #7
iamwilliam
Member
 
Registered: Apr 2006
Location: Nairobi
Distribution: CentOS
Posts: 78

Rep: Reputation: 21
Guys,

Correct me if I'm wrong. His default policy is ACCEPT. However, he does have an explicit REJECT rule for all traffic at the end of his INPUT and FORWARD chains.

Having said that, I agree it is safer to have the default policy as DROP . . . just in case the final REJECT rule is removed accidentally.
 
Old 08-28-2012, 01:32 AM   #8
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,896

Rep: Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774
Quote:
Originally Posted by iamwilliam View Post
Guys,

Correct me if I'm wrong. His default policy is ACCEPT. However, he does have an explicit REJECT rule for all traffic at the end of his INPUT and FORWARD chains.

Having said that, I agree it is safer to have the default policy as DROP . . . just in case the final REJECT rule is removed accidentally.
Safer? We could have an argument just about that word.

The usual advice is to make the policies for the pre-existing chains DROP. The argument for this is that if, in deciding how to arrange your rules you make an oversight, it is better if you drop the associated packets, rather than let them through.

On the other hand, if you make a mistake editing the firewall ruleset, such as flushing the rules prior to making some other change, and in doing so lock yourself out of the firewall box, you might reasonably argue that safer would be 'not locked out', and so you would conclude that it is safer to have an explicit DROP rule at the end of the chains.

(You could 'kind of' design a way around this problem and have a backup ruleset that gets loaded if certain things don't happen in a certain timescale, but that again could be fraught and you have to ensure that this scheme itself is not susceptible to attack. Probably not desirable, if you don't have to do it.)

Note that this does not apply to any user-defined chains, as they don't have policies, so you have no choice but to use the explicit DROP instruction for them.

To an extent, which risk you are more concerned about can be a function of geography; if the firewall box that you are concerned about is in a different time zone, getting locked out because you are now dropping all ssh packets is probably more of a concern than if you can just walk upstairs to get to it and log on locally.
 
  


Reply

Tags
ddos, iptables


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
iptable rules, your opinions linuxcbon Linux - Security 7 08-16-2008 05:54 PM
IPTable rules RecoilUK Linux - Security 1 05-27-2005 07:25 PM
Help with IPtable Rules aqoliveira Linux - Security 3 12-10-2003 10:00 AM
iptable-rules for eDonkey? grubjo Linux - Networking 2 08-01-2002 06:38 AM
Iptable rules for Gnutella al_erola Linux - Security 5 03-06-2002 03:21 AM


All times are GMT -5. The time now is 10:45 PM.

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