LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 03-30-2016, 01:07 PM   #1
JockVSJock
Senior Member
 
Registered: Jan 2004
Location: DC
Distribution: RHEL/CentOS
Posts: 1,386
Blog Entries: 4

Rep: Reputation: 164Reputation: 164
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
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.
 
Old 03-30-2016, 02:47 PM   #2
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
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."
 
1 members found this post helpful.
Old 03-30-2016, 03:02 PM   #3
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
Originally Posted by sundialsvcs View Post
... 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.
 
1 members found this post helpful.
Old 03-30-2016, 03:24 PM   #4
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
Quote:
Originally Posted by rknichols View Post
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.)
 
Old 03-30-2016, 03:30 PM   #5
JockVSJock
Senior Member
 
Registered: Jan 2004
Location: DC
Distribution: RHEL/CentOS
Posts: 1,386

Original Poster
Blog Entries: 4

Rep: Reputation: 164Reputation: 164
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...
 
Old 03-30-2016, 03:31 PM   #6
geesh
Member
 
Registered: Feb 2004
Posts: 53

Rep: Reputation: 16
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.
 
Old 03-30-2016, 04:16 PM   #7
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
Originally Posted by sundialsvcs View Post
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.
 
Old 03-30-2016, 04:23 PM   #8
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
Quote:
Originally Posted by geesh View Post
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.
 
Old 03-30-2016, 07:02 PM   #9
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
Quote:
Originally Posted by rknichols View Post
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.
 
Old 03-30-2016, 07:11 PM   #10
descendant_command
Senior Member
 
Registered: Mar 2012
Posts: 1,766

Rep: Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577
More likely they have a checklist that says default policy should be 'DROP' and no further thought is expended on it.
 
Old 03-30-2016, 07:50 PM   #11
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
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.
 
Old 03-31-2016, 07:53 AM   #12
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
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.

Last edited by sundialsvcs; 03-31-2016 at 07:54 AM.
 
Old 03-31-2016, 08:40 AM   #13
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,535

Rep: Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077Reputation: 2077
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.
 
Old 03-31-2016, 09:36 AM   #14
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 5,524
Blog Entries: 3

Rep: Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786Reputation: 2786
Quote:
Originally Posted by sundialsvcs View Post
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.
 
Old 03-31-2016, 11:01 AM   #15
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187Reputation: 3187
Quote:
Originally Posted by Turbocapitalist View Post
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.
 
  


Reply

Tags
default policy, drop, 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
"iptables Default Policy DROP - can't browsing.." budi.mulyana Slackware 6 02-05-2016 05:37 AM
Is it necessary to drop specific flags in IPTABLES with an INPUT DROP policy? rootaccess Linux - Networking 5 08-22-2012 08:10 PM
iptables question: default DROP policy and TCP Three Way Handshake johnnygear Linux - Networking 5 04-22-2012 08:38 PM
iptables / output *drop* policy reverse Linux - Security 3 11-22-2007 10:39 AM
Iptables drop policy problem Dakkar Linux - General 5 10-18-2006 02:38 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 09:18 PM.

Main Menu
Advertisement
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
Open Source Consulting | Domain Registration