iptables vs hosts.deny
 

Im sorry if this is too basic of a question but can some quickly and simply tell me the difference between the two? I know the hosts.deny stops the host from using a local service, but assuming you want to block ALL services from that host, why not just block them at the firewall? Is one way prefered over another?

Being a n00b I find it much easier to use hosts.deny but now is as good of a time to learn as any.

Also, after adding an entry to the hosts.deny file, does any service need to be restarted?

Thank you,

iptables
 

Yes, IPTables block the immediate connection to the service, while hosts.deny does the same.

For a good situation, I did the following:

hosts.deny contained:

ALL : ALL

SSH <--(I forgot the correct syntax) : DENY EXCEPT 1.2.3.4 2.3.5.6 5.2.3.6

I believe that how I did it. And in my IPTables, port 22 [ssh] was shut down and only open to the IPs: 1.2.3.4 2.3.5.6 5.2.3.6

Do I prefer one? I use both "just-in-case"--They both work effectively, but IPTables seems to be MUCH more flexible because it can also block pings, fin, syn, xmas, smurf & other attacks and probes.

If your looking for a quick and dirty way to learn practical IPtables, take a look at http://iptablesrocks.org/

I hope this helps,

--Gian

PS- I don't remember the exact syntax I used in hosts.deny (it has been awhile :)), so make sure to check out the man pages before putting up the production server.

Also, it's very important to remember that not all applications include tcp wrappers (hosts.allow/deny) support by default. Certain services like sshd usually have it in the default install, but others like Apache do not in a number of distros, so make sure to check the docs first.

You can run most of them through inetd/xinetd using tcpd so that they use tcp wrappers, otherwise they'll need to be compiled with tcp wrappers support. Unfortunately no errors will be generated if you try and put a non-supported application in hosts.allow/deny, leading many to think that they are secure when they're really not.