Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I recently did the Shields up and probe ports test, and i got that my almost all my ports where closed, but none of them had stealth condition.
What should i add to my current ruleset to make it stealth?? Or is this out of reach for iptables alone?
BTW, I'm running slack 8 with a recompiled 2.4.5 kernel with iptables 1.2.4, with eth0 as the externel if (using dhcpcd ) and eth1 as the internal if with ip 192.168.0.1, and a second winblows box with static ip 192.168.0.2.
I've already found what i was looking for, the example ruleset rc.firewal-2.4-stronger of the IP-Masquerade HOWTO, works perfectly and gives me stealth status in all ports.
btw; 'sheilds up' is rudimentary at best, and there is some controversy regarding the site author.... but anyway;
you can also go to sygate's scanner for more comprehnsive tests....
The easiest way to stealth is to drop all non-established and non-related traffick; ie
Code:
iptables -P INPUT DROP
iptables -F INPUT
iptables -N inbound
iptables -A INPUT -i eth0 -j inbound
iptables -A INPUT -i lo -j ACCEPT
iptables -A inbound -m state --state ESTABLISHED -j ACCEPT
iptables -A inbound -m state --state RELATED -j ACCEPT
This allows all desired traffick outward (provided your OUTPUT chain is set up correctly), but only packets that are part of a connection or related to one (ftp, for example) are allowed back in.
The reason I have the new chain (inbound) if for local box testing. Do the following:
Code:
iptables -R INPUT 2 -i lo -j inbound
and you can run nmap against yourself. I am not positive that this will give you the same results as using nmap from a remote box, but I hav had good consistant results with it. And to re-allow local traffick:
Code:
iptables -R INPUT 2 -i lo -j ACCEPT
hope this helps.
-t.
ps: you should see my firewall managing script now....
2909 lines.... 21 files (give or take).
I am new to working with IP tables. Do you know of a few good references to get up to speed with Netfilter Iptables
And do you know where all of the default config files are for iptables.
I am running Red Hat 9, first time using linux as a firewall. Red H
Hat does some initiall configuration at the setup. And the file it reads in is /etc/sysconfig/iptables.
What is defined in that file, and what is actually being passed through the firewall do not line up. So I was wondering if you could point me to the rest of the iptables config.
Actually, a quick and dirty way I've found is to drop all tcp syn packets. This way you're virtually undetectable to portscanners. Basically, you're dropping all TCP packets that weren't initiated by your local computer/network.
iptables -A INPUT -i eth0 -p tcp --syn -j DROP
I've noticed that this doesn't kill port 0 & 1 for some reason, so those have to be turned off as well
iptables -A INPUT -i eth0 -p tcp --dport 0 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 1 -j DROP
Actually, a quick and dirty way I've found is to drop all tcp syn packets. This way you're virtually undetectable to portscanners. Basically, you're dropping all TCP packets that weren't initiated by your local computer/network.
iptables -A INPUT -i eth0 -p tcp --syn -j DROP
I've noticed that this doesn't kill port 0 & 1 for some reason, so those have to be turned off as well
iptables -A INPUT -i eth0 -p tcp --dport 0 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 1 -j DROP
Does it also fool port scanner software like nmap, which in normal conditions will "see" your machine's port status even if those ShieldsUp-type scanners don't? I used to believe nmap-kind software is pretty difficult to cheat on. And to have your machine "stealth" isn't really "secure", it's just 'what you can't see you can't touch' ideology. I would still consume more time on hardening the machine itself, rather than trying to hide it from candy port scanners. And usually if you just go on denying some packets and drop traffic to some ports results in you being unable to do something. If you don't really need the ports open it's a wise thing to do, and if you think you never need to accept any syn packets (for example) it's again a wise thing to do. But when you do need them, you'll have to open your setup. A completely "stealth" setup, along with a 'secure' one, is ok if you have a personal desktop machine that you never use to any communication, but in normal conditions I'd recommend not necessarily spending hours to get your machine stealth (surely there always is something that can reveal your ports' status) but spend enough time to make it difficult to breach despite of somebody seeing what ports you have closed and what not.
I also suggest you to run nmap (and possibly some other similar) scans to your machine (note: they won't work from inside your own machine well, you should run them from another machine, for example on inside your ethernet) to see what they reveal. A thing to know is that not all ISPs like people doing port scans in their networks, so that's why it'd be a good idea to run nmap scans (etc.) in a local ethernet rather than over internet from your pal's computer.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.