LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (http://www.linuxquestions.org/questions/linux-networking-3/)
-   -   iptable rules recommended? (http://www.linuxquestions.org/questions/linux-networking-3/iptable-rules-recommended-4175422382/)

mojorisin 08-16-2012 06:26 AM

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

salasi 08-16-2012 03:40 PM

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 (Post 4755483)
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 (Post 4755483)
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.

Hangdog42 08-18-2012 08:53 AM

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.

KinnowGrower 08-18-2012 10:02 AM

Quote:

Originally Posted by mojorisin (Post 4755483)
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)

mojorisin 08-20-2012 04:30 AM

Thanks to all of you guys for the huge feedback!!!

Quote:

Originally Posted by Hangdog42 (Post 4757582)
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/

Hangdog42 08-25-2012 08:31 AM

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.

iamwilliam 08-27-2012 06:52 AM

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.

salasi 08-28-2012 01:32 AM

Quote:

Originally Posted by iamwilliam (Post 4765317)
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.


All times are GMT -5. The time now is 07:10 AM.