Attempting to block all non-used ports with iptables.
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.