LinuxQuestions.org
Visit the LQ Articles and Editorials section
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 10-11-2013, 10:03 PM   #1
jddancks
LQ Newbie
 
Registered: Jan 2013
Location: Central NY
Distribution: Mac, debian
Posts: 21

Rep: Reputation: Disabled
Attempting to block all non-used ports with iptables.


Here's what I figured with the help of a few articles from NixCraft:

Quote:
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -A INPUT -i eth0 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --destination-port 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --destination-port 443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -j DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
I just tested it, and it seems to be doing what I need, I'm curious if maybe the rules are either too lenient, or too restrictive, as a user I only need internet and SSH open, IDK about any necessary services other than ICMP for testing and stuff. I'm curious if there are any necessary service that I'm blocking.
 
Old 10-12-2013, 05:58 AM   #2
Shadow_7
Senior Member
 
Registered: Feb 2003
Distribution: debian
Posts: 1,506

Rep: Reputation: 233Reputation: 233Reputation: 233
The 127.0.0.1 would normally be the loopback device (lo) and not eth0.

If you're doing any network file systems you're likely blocking them. If you do any IRC stuff you're probably blocking ident and other things that "chat" things seem to "require" these days. Along with FTP, PING, and other things you might use from outside your machine. But if you don't use any of that stuff, you're good (in theory). Of course you're only blocking incoming things for the most part. Your system is still free to broadcast any and all things OUT of your network.

In debian the netbase package has a /etc/services file that lists a lot of ports for various things. And one should note that iptables has -t ??? things beyond just nat and mangle. Like filter, and a couple others I don't recall of the top of my head. Not that they get used much by default, but they exist and you're not clearing them.

And of course tcp is only one packet type. According to /etc/services, it implies that ssh (20), http(80), and https(443) use both tcp and udp packets. Or I could be wrong, I am by no means a network guru.
 
1 members found this post helpful.
Old 10-12-2013, 02:25 PM   #3
jddancks
LQ Newbie
 
Registered: Jan 2013
Location: Central NY
Distribution: Mac, debian
Posts: 21

Original Poster
Rep: Reputation: Disabled
I can gaurantee that the only user-level applications I'll be using (for now) will be Apache and SSL. For security I only want the essential applications to be able to listen. Its bad enough I need apache. PING, traceroute, and other utilities, I believe are ICMP, so `iptables -A INPUT -i eth0 -p icmp -s 0.0.0.0/0 -m state --state ESTABLISHED,RELATED -j ACCEPT` will allow return ACK packets for those services. However my machine won't respond to any of them on the outside, which is what I intend.

I didn't know about the other tables thanks for pointing that out.

And the loopback socket. Oops. Thank you.
 
Old 10-12-2013, 02:42 PM   #4
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,888

Rep: Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774Reputation: 774
Err

ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol

while

ftp-data 20/tcp # File Transfer [Default Data]
ftp-data 20/udp # File Transfer [Default Data]
ftp-data 20/sctp # FTP

http could also be on 8080 or 3128 (squid caching) or some anagram (8123?, polipo). And ssh is often put on another port as a 'security' measure (which it isn't really, on its own, but that's drifting in a direction firmly signposted as 'Off Topic'). But, at least you should know if you've done it and allow the correct port, whichever that is.

Here endeth todays reading from /etc/services

Anyway, egress (that which gets out) filtering is more difficult....actually, that's a bad statement, as it isn't so much difficult, just a bit fussy, compared to stateful filtering of what comes in.
 
Old 10-12-2013, 06:44 PM   #5
Robhogg
Member
 
Registered: Sep 2004
Location: Old York, North Yorks.
Distribution: Debian 7 (mainly)
Posts: 653

Rep: Reputation: 85
If you're using Debian...

One of the things I do on a fresh install is to stop and disable any unnecessary services. A basic install will have exim4, nfs-common and rpcbind running - I've not found any problems with disabling these on most systems.

Code:
sudo netstat -anp -Ainet,inet6 | grep LISTEN # show what's listening
sudo service exim4 stop
sudo service nfs-common stop # has to be stopped before rpcbind
sudo service rpcbind stop
sudo update-rc.d exim4 remove
sudo update-rc.d nfs-common remove
sudo update-rc.d rpcbind remove
# and any others
If there's nothing listening on a port, nothing will be able to connect to it...

Last edited by Robhogg; 10-12-2013 at 06:49 PM.
 
Old 10-13-2013, 03:54 AM   #6
yzT!
Member
 
Registered: Jan 2013
Distribution: Debian
Posts: 113

Rep: Reputation: 2
I'd add rules for outgoing traffic and setting the chain to DROP by default.

If your PC gets compromised you would like to limit the actions an attacker might perform, wouldn't you?
 
Old 10-13-2013, 06:48 AM   #7
Turbocapitalist
Member
 
Registered: Apr 2005
Distribution: Ubuntu, Debian, OS X (bsd)
Posts: 144

Rep: Reputation: 27
Quote:
Originally Posted by yzT! View Post
I'd add rules for outgoing traffic and setting the chain to DROP by default.
DROP is not the wisest choice for blocking outgoing traffic. In 99.99% or more of the cases any outgoing traffic is going to be coming from you. In that case you don't want to waste your time waiting for timeouts which DROP will cause. For outgoing traffic, at least, use REJECT instead of DROP.
 
Old 10-13-2013, 07:04 AM   #8
yzT!
Member
 
Registered: Jan 2013
Distribution: Debian
Posts: 113

Rep: Reputation: 2
I don't understand your point.

If the traffic is legitimate, it is not going to be dropped, so why would you have to wait for DROP timeout?
 
Old 10-13-2013, 07:07 AM   #9
Turbocapitalist
Member
 
Registered: Apr 2005
Distribution: Ubuntu, Debian, OS X (bsd)
Posts: 144

Rep: Reputation: 27
Here are two examples, of many. You can have a legitimate application sending traffic on a port other than you expected. Or you can add a new application and need to update the packet filter.

DROP is not any "extra" help on the external connections either. Try reading the link I provided or try this one instead:

http://www.chiark.greenend.org.uk/~p...drop-vs-reject

There are a lot more similar articles.
 
Old 10-13-2013, 07:24 AM   #10
yzT!
Member
 
Registered: Jan 2013
Distribution: Debian
Posts: 113

Rep: Reputation: 2
So the best approach is to let INPUT as DROP but OUTPUT as REJECT? Or do you use REJECT on INPUT chain as well?
 
Old 10-13-2013, 07:48 AM   #11
Turbocapitalist
Member
 
Registered: Apr 2005
Distribution: Ubuntu, Debian, OS X (bsd)
Posts: 144

Rep: Reputation: 27
Both can benefit from REJECT over DROP. For me, the point is to keep you from spending your time unnecessarily while configuring, debugging or using your own services. That is also by extension your legitimate users and customers. There are other points in the two links above.

There are exceptions. Say you have a --limit set for a particular port, it probably does not matter if you use DROP there. If you are really interested in that or think it's fun you can look at compiling in the TARPIT target. But I don't know if that is uptodate or even usable. It's probably not in the regular iptables for a reason and your return for the effort will likely be low.
 
1 members found this post helpful.
Old 10-18-2013, 05:38 PM   #12
jddancks
LQ Newbie
 
Registered: Jan 2013
Location: Central NY
Distribution: Mac, debian
Posts: 21

Original Poster
Rep: Reputation: Disabled
I know this is old. I don't mean to bump old threads. whatever.

So the reject vs drop policy is:
they both work the same
at least reject is TCP compliant

I didn't understand the SYN attack argument, he seems to be saying that drop stays in the buffer longer. Why is it in the buffer at all? why wouldn't the packet memory be marked free immediately when drop rule is reached?

I also don't see the point in controlling output if my input rules are solid. If my server is compromised, how hard would it be to change the netfilter rules. They're being read by a regular system file.
 
Old 10-19-2013, 04:24 PM   #13
Shadow_7
Senior Member
 
Registered: Feb 2003
Distribution: debian
Posts: 1,506

Rep: Reputation: 233Reputation: 233Reputation: 233
It's not that old. A compromised system might change your executables, and otherwise go undetected. Like swapping out your bash for a version that keylogs. There's basically nothing in place to prevent E.T. from phoning home if you don't filter your OUTPUT packets.

And then there's workplace issues where you need the network up for downloads / updates, but don't want to broadcast anything until you've finished configuring the machine(s). And other workplace issues where you need to block users from inside the network from using sites and services. Or family issues where you need more of the same.
 
  


Reply


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
Block all the ports excpet 80 on iptables (eth2) webboy105 Linux - Security 11 02-04-2010 03:17 PM
iptables firewall script to block all and open only selected ports jomy Linux - Security 24 01-14-2009 07:50 AM
How to block high ports in iptables? sparc86 Linux - Security 1 12-01-2008 07:55 PM
block m$ related ports using iptables carboncopy Linux - Security 8 01-28-2005 12:30 PM
iptables: block ports and RELATED, ESTABLISHED Klaus Pforte Linux - Security 6 07-17-2003 10:00 AM


All times are GMT -5. The time now is 08:38 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