If iptables default policy is DROP, does that stop all traffic?
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 Code:
# Generated by iptables-save v1.4.7 on Wed Nov 18 09:48:32 2015 I'm not understand the recommendation to change to DROP. |
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." |
Quote:
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. |
Quote:
... 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.) |
I think I understand, as now my default policy was changed with the following:
Code:
Further reading on IPTables default policy http://linuxtopia.org/Linux_Firewall...EFAULTPOLICIES Quote:
Some websites said to edit /etc/sysconfig/iptables directly, which doesn't look like a good idea to me... |
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.
|
Quote:
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. |
Quote:
|
Quote:
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. |
More likely they have a checklist that says default policy should be 'DROP' and no further thought is expended on it.
|
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.
|
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 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.
|
Quote:
|
Quote:
|
All times are GMT -5. The time now is 09:59 PM. |