Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am trying to configure the box I am using as a gateway/proxy/firewall to allow IP masquerading and finally switch over from using a proxy. It's a debian squeeze system.

Currently, my hosts.allow file is empty (and hosts.deny says ALL: PARANOID), because squid allows requests on the required ports anyway (and also, I can ssh to the box just fine).

Does iptables work the same way, i.e. can the hosts.allow file remain empty when iptables is set up properly?

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

The hosts.* files are not required when using iptables. Both have the ability to deny/allow access but work in very different ways.

       Network
          |
       IPTables
         /  \  
TCPWrapper  Squid/Daemon
  Daemon

Iptables is a kernel base packet filtering framework operating at a layer below tcpwrappers. If you DROP or REJECT something with iptables the packet will never reach userspace. It doesn't matter what the program is or how it is written, the packet will never exist from it's point of view.

Programs that use TCPwrappers and it's hosts.* functionality run in user space and have to be built with libwrap to make use of the files, or emulate it by reading the hosts files and closing connections they receive from denied clients.

Squid doesn't read the hosts.deny|allow files. It has it's own implementation for access control specified with acl's in squid.conf. In the same way you can configure squids access control on top of iptables, you can use hosts.deny/allow on top of iptables. Those rules only come into play if iptables has let's the traffic through. Not that many programs support tcp_wrappers these days either, inetd, the super server, was the main one bit is slowly disappearing.

share|improve this answer
    
iptables runs on the host, so even if you DROP or REJECT a packet it has reached the system. It's a somewhat minor detail, but it is important sometimes. –  Michael Kjörling Feb 23 '13 at 13:48
    
corrected, cheers –  mtm Feb 23 '13 at 14:13
add comment

The reason you are still able to connect to SSH with an empty hosts.allow is probably because by default tcpwrappers allows all connections unless you explicitly deny them.

One way to get the opposite (default deny) behaviour is to add the following line to /etc/hosts.deny (carefull not to shut yourself out!)

ALL: ALL


Tcpwrappers (hosts.allow and hosts.deny) doesn't work for every network service, like iptables does.

You can often see if a daemon supports tcpwrappers by checking if it is linked against libwrap, like this:

$ ldd /usr/sbin/sshd | grep libwrap
    libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f389b5a2000)

If there is no output, tcpwrappers is likely not supported by that daemon.

On a final note, I think a very common setup is to only use iptables and leave tcpwrappers unconfigured.

share|improve this answer
    
My hosts.deny is a one-liner saying ALL: PARANOID. I believe that ssh is yet another service that doesn't look at hosts.allow|deny. –  zebonaut Feb 23 '13 at 15:57
    
@zebonaut: But paranoid doesn't block everything. It only blocks, quoting man hosts_access, Matches any host whose name does not match its address. –  0xC0000022L Feb 23 '13 at 17:00
    
As you can see from my ldd example, sshd can in fact support tcpwrappers. –  foo Feb 24 '13 at 10:45
add comment

Short answer: yes. TCPwrappers (which is what consults hosts.allow and hosts.deny) is a separate access control method from iptables, using one does not require or impede the use of the other. The only concern will be to ensure required access is allowed through both, if they are both active on the system.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.