Netfilter/Ipchains best practices -- the stealthing debate.

Anyone who's familiar with Netfilter could probably skip the first paragraph or two.



Those who aren't familiar with Netfilter and/or Ipchains, I'll try and give you a brief description. Ipchains is a packet-level firewall included with most, if not all, linux distributions. It offers COMPLETE port-based firewalling, such as you might want on a border router for a company's network. Netfilter is an expanded version of ipchains that allows for quite a bit more functionality. It is port-based, but is also a 'stateful firewall', which basically means that it can examine the 'state' of any packets, and then respond in a variety of ways depending on how your firewall is configured.



Ipchains and Netfilter are something that I think EVERYONE who's running a linux distribution at home should know inside out. It's really what can lock down your system and make things quite a bit more secure.

I would suggest anyone interested in a more complete answer to what Netfilter and ipchains are should take a look at the following two pages:

For Netfilter: http://netfilter.samba.org/netfilter-faq.html

For Ipchains: http://www.niemueller.de/webmin/modu...ains-faq.shtml



Now, onto my question. ;)



Those of you who are familiar with ipchans/netfilter will no doubt have certain policies regarding whether you REJECT a packet or whether you DROP/DENY a packet.

My question is: What do you guys prefer and why?
DROP or REJECT, and why?

Does anybody care for this kind of discussion?

I prefer to drop packets, this ties up the scanner and doesn't prove that there's aport listenining.
Deny & Reject allow the (potential) attacker to know your there.

Anybody else have any input?
:confused:

Personally I drop strangely ported packets, because im for some reason prone to portscans. Hopefully whoevers scanning me gets tired of waiting for all his pings to timeout and leaves me alone.

Quote:

---

Originally posted by jcdux
I prefer to drop packets, this ties up the scanner and doesn't prove that there's aport listenining.
Deny & Reject allow the (potential) attacker to know your there.

Anybody else have any input?
:confused:

---

Actually, DROP and DENY are one and the same (just a different term used between ipchains and iptables).

You're right in that it shows a 'port' isn't listening, but so does REJECT. DENY/DROP CAN be used to determine if a machine is there at all unfortunately.

DROP is the way to go. Deny is not really a bad sign to a hacker, if there is some script O' nastie that he has for `well known port' such and such then he can go about beating up your firewall.

Netfilter and Iptables (Ipchans) are great. I like ipfilter a bit better (non glibc systems only at the moment) because the rules are essentially plain text and you can get *very* specific when accompanied by nat and tun.

Cool post, love to see that security related stuff on AO.

Not sure how i missed this thread when it was originally posted.
Chsh - i /nearly/ always use drop, it may not be completely invisible to everyone but it does go some way to hiding your boxen. It may be better to use reject for some udp broadcast traffic though (like ident) as this will help prevent lag.
If your writing a firewall for an internal network though, and want to block certain services to people, it would probably be better manners to use the reject switch, better to let people know straight away they can't get through then having them sitting waiting for the connection to time out.

Just my half a denari.

What I'm seeing is a trend to try and protect yourselves from script kiddies. Basically you're setting up defenses that deal with the generic portscan, and the occassional attmempted break-in.

Is that accurate?

Being as that would be the most prevalent form of attack, yes, that would be accurate - do i detect from the tone of your post you're operating on some higher level, where script kiddie attacks are of no concern?
Maybe instead of assuming some intellectual high ground without any evidence to back it up, you could enlighten us as to what is your firewall does.

There is a chance that i'm being presumptous about your intellectual high ground - i'm in a stinkin mood - if i'm wrong - i apologise.

imho it is a *very bad idea* to discount the script kid O's. A real hacker may root your box and have a look around or whatever. Script Kiddies are a lot more likely to rm -rf your box or other general mean things. Besides the world is full of lamers and kiddies, and that is reasson enough for me to take their actions/attempts seriously.

Quote:

---

Petemcevoy said:
There is a chance that i'm being presumptous about your intellectual high ground - i'm in a stinkin mood - if i'm wrong - i apologise.

---

No apology needed, and no, I wasn't being condescending. ;) It was an honest question, I'm honestly curious as to how other people approach the subject.

Quote:

---

psi0nic said:
imho it is a *very bad idea* to discount the script kid O's. A real hacker may root your box and have a look around or whatever. Script Kiddies are a lot more likely to rm -rf your box or other general mean things. Besides the world is full of lamers and kiddies, and that is reasson enough for me to take their actions/attempts seriously.

---

Don't get me wrong, I'm not discounting them. Indeed, my firewalls rules are set up in a very similar way when it comes to pings, blatant portscans, etc.. I agree that they represent a major percentage (probably 80-90%) of all malicious traffic on the web, and that that alone is why you should do what you can to stop them.

The real question I'm asking here is does drop/deny do anything more than reject does?

I mean, to a point I think a script kiddie would see a drop/deny response and think nothing's there, but a real cracker/hacker could tell that there's a PC there based on the response (or lack thereof).

REJECT, on the other hand, will tell you that there's definitely a PC there, but that the port isn't open.

From a strict networking point of view, it's better to simply reject packets than to drop/deny them, but drop/deny will delay a portscan.

It's a fairly trade-offish issue, which is why I'm curious as to what you guys think. ;)