[SOLVED] If iptables default policy is DROP, does that stop all traffic?

JockVSJock · 03-30-2016, 01:07 PM

An audit has determined that iptables isn't setup correctly on all of my Linux servers.

I'm being told that the default policy for INPUT chain must be:

Code:

iptables -policy INPUT DROP

My current rules for one of the servers looks like this:

Code:

# Generated by iptables-save v1.4.7 on Wed Nov 18 09:48:32 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [166:19244]
-A INPUT -p tcp -m tcp --dport 65252 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 11443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 14242 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10443 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -p udp -m udp --sport 123 -j ACCEPT
COMMIT
# Completed on Wed Nov 18 09:48:32 2015

If I change the default policy, no traffic will be allowed to the INPUT, correct?

I'm not understand the recommendation to change to DROP.

sundialsvcs · 03-30-2016, 02:47 PM

What the auditors are saying is that your present set of rules ACCEPT ten specific cases, then REJECT two specific cases ...

... then leave every other(!) case to be dealt-with by an all-encompassing "default rule," which, at the moment, is ... ACCEPT.

Obviously, "you must force every bit of the traffic on the road to pass through your toll-gate, otherwise your toll-gate simply doesn't matter."

rknichols · 03-30-2016, 03:02 PM

Quote:

Originally Posted by sundialsvcs

... then leave every other(!) case to be dealt-with by an all-encompassing "default rule," which, at the moment, is ... ACCEPT.

Not really. The last rule in the INPUT chain is a REJECT rule for all packets that make it that far in the chain.

Go ahead and set the default policy to DROP. It will make no difference since no packets ever fall through the chain, but it will keep the auditors happy.

sundialsvcs · 03-30-2016, 03:24 PM

Quote:

Originally Posted by rknichols

Not really. The last rule in the INPUT chain is a REJECT rule for all packets that make it that far in the chain.

Go ahead and set the default policy to DROP. It will make no difference since no packets ever fall through the chain, but it will keep the auditors happy.

Without(!) publicly confronting your assessment in this case, "I'm not sure that I interpret these rules in the same way that you do," and I'm also not so sure why the auditors would be saying the things that they are, if that were true.

... freely acknowledging(!!) that perhaps I do not fully understand the meaning of --reject-with icmp-host-prohibited.

Therefore, I anxiously await your clarification (and enlightenment) on this matter. (And I graciously yield whatever statements I may have made heretofore, as having obviously been wrong.)

JockVSJock · 03-30-2016, 03:30 PM

I think I understand, as now my default policy was changed with the following:

Code:

iptables -P INPUT DROP

http://gr8idea.info/os/tutorials/sec...iptables4.html

Further reading on IPTables default policy

http://linuxtopia.org/Linux_Firewall...EFAULTPOLICIES

Quote:

13.2.5. Setting up default policies

Quite early on in the process of creating our rule-set, we set up the default policies. We set up the default policies on the different chains with a fairly simple command, as described below.

iptables [-P {chain} {policy}]

The default policy is used every time the packets do not match a rule in the chain. For example, let's say we get a packet that matches no single rule in our whole rule-set. If this happens, we must decide what should happen to the packet in question, and this is where the default policy comes into the picture. The default policy is used on all packets that does not match with any other

Do be cautious with what default policy you set on chains in other tables since they are simply not made for filtering, and it may lead to very strange behaviors.

Some websites said to edit /etc/sysconfig/iptables directly, which doesn't look like a good idea to me...

geesh · 03-30-2016, 03:31 PM

reject sends feedback that it has been rejected and shows a fingerprint the server exists whereas drop is silent and no reason is sent so no server exists. At least thats the simple answer between reject and drop.

rknichols · 03-30-2016, 04:16 PM

Quote:

Originally Posted by sundialsvcs

Without(!) publicly confronting your assessment in this case, "I'm not sure that I interpret these rules in the same way that you do," and I'm also not so sure why the auditors would be saying the things that they are, if that were true.

... freely acknowledging(!!) that perhaps I do not fully understand the meaning of --reject-with icmp-host-prohibited.

The important part of that rule is "-j REJECT", which causes the packet to be rejected. The "--reject-with icmp-host-prohibited" just causes the icmp reject packet to have a code other than the default "port-unreachable".

REJECT is a terminating target. Once a rule with a terminating target (ACCEPT and DROP are others) triggers, no further processing occurs in that step. Since this rule has no match conditions, it matches every packet that reaches it. No packet will ever fall through to the DROP policy.

rknichols · 03-30-2016, 04:23 PM

Quote:

Originally Posted by geesh

drop is silent and no reason is sent so no server exists.

That "so no server exists" is a common misconception. The lack of response means that the server does exist and is trying not to be seen. If the server truly did not exist, then the upstream router would have sent back a "No route to host" response.

sundialsvcs · 03-30-2016, 07:02 PM

Quote:

Originally Posted by rknichols

The important part of that rule is "-j REJECT", which causes the packet to be rejected. The "--reject-with icmp-host-prohibited" just causes the icmp reject packet to have a code other than the default "port-unreachable".

REJECT is a terminating target. Once a rule with a terminating target (ACCEPT and DROP are others) triggers, no further processing occurs in that step. Since this rule has no match conditions, it matches every packet that reaches it. No packet will ever fall through to the DROP policy.

Interesting. Thank you.

Therefore, I wonder if the auditors specifically wished for the packets to be dropped, with no explanation being offered to the sender, rather than rejected.

descendant_command · 03-30-2016, 07:11 PM

More likely they have a checklist that says default policy should be 'DROP' and no further thought is expended on it.

rknichols · 03-30-2016, 07:50 PM

Exactly. I'd be willing to make a small wager that you could put a "-j ACCEPT" rule at the end of the chain to accept all packets not explicitly dropped or rejected, and the auditors would still be happy as long as the (meaningless) default policy was DROP.

sundialsvcs · 03-31-2016, 07:53 AM

It strikes me ... and, it strikes me as quite sensible ... that the auditors would not wish for an intruder a script-kiddie's "bot" to even be aware that a computer even existed at that IP-address. (Drop the packet, and there is no clue. Reject it, and there is.) For much the same reason, many computers are rigged-up not to respond to a "ping."

The first thing that any "bot" will do is to scan a wide range of IP's looking for targets. A little bit of camouflage works well in avoiding bombs.

rknichols · 03-31-2016, 08:40 AM

It does cut down on the noise a bit, and the ICMP REJECT packets do reveal something about the nature of the machine that sends them. There are some advantages to DROP vs. REJECT. It's just not as "stealthy" as many people believe -- more like "hiding" something by painting it flat black.

Turbocapitalist · 03-31-2016, 09:36 AM

Quote:

Originally Posted by sundialsvcs

It strikes me ... and, it strikes me as quite sensible ... that the auditors would not wish for an intruder a script-kiddie's "bot" to even be aware that a computer even existed at that IP-address. (Drop the packet, and there is no clue. Reject it, and there is.) For much the same reason, many computers are rigged-up not to respond to a "ping."

The first thing that any "bot" will do is to scan a wide range of IP's looking for targets. A little bit of camouflage works well in avoiding bombs.

It's not really camouflage at all and it does penalize legitimate users. If you do have an axe to grind over a specific IP address then you can always tarpit it with the iptables extension of the same name. Otherwise, it is better to use REJECT than DROP. The original poster seems to have it right and the auditors not so much. I think rknichols would probably win the small wager offered.

sundialsvcs · 03-31-2016, 11:01 AM

Quote:

Originally Posted by Turbocapitalist

Otherwise, it is better to use REJECT than DROP.

Thank you for sharing that most interesting link, which makes a very good case in support of your position.