hosts.deny/host.allow. WhatTheFudging?

So I'm reading my book (I've been more than slacking on this!) and I got to a part saying:

/etc/hosts.deny | vsftpd: ALL
/etc/hosts.allow | vsftpd: 192.168.1.10, 192.168.1.102

"Be aware that hosts.deny is read and applied first, followed by hosts.allow. That means any directive in hosts.allow trumps any conflicting directive in hosts.deny. If an unauthorized host tries to connect, the request fails."

It's probably because I've been around other filtering methods but the context seems wrong to me.
1) If hosts.deny is read first AND the /etc/hosts.deny is written to deny everything - wouldn't everything be denied?

So in theory:
A packet comes from 192.168.1.10. It's read by hosts.deny (Afterall, It's read first). The packet is dropped (It's filter marks ALL). That's it. /etc/hosts.allow will never get a chance to say "Whoa boy, simmer down!"

With that said:

"Any directive in hosts.allow trumps any conflicting directive in hosts.deny"
Hosts.allow will overrule hosts.deny checking.

My Question:
Am I reading this correctly?
If yes: Why is /etc/hosts.deny read first prior allowing service access?

It seems inefficient to not use /etc/hosts.allow first, and then have /etc/hosts.deny read second.

Find more posts tagged with

Comments

log32

AFAIK, allow is the first one and then the deny.
so in reality, 192.168.1.10 and 192.168.1.102 will have access to the vsftp daemon, and then the rest will all be denied access.

if it was the other way around, those IP will not have access no matter what. since the deny will be read first and deny access to all stations.

e.g.
/etc/hosts.allow ---> in.telnetd : 192.168.47.0/255.255.255.0
/etc/hosts.deny ---> in.telnetd : ALL

will permit network 192.168.47.0 subnet 255.255.255.0 to login with telnet and any other network will get an access denied msg.

Roguetadhg

That's what I was assuming, dealing with the implicit deny for ACLs - that made sense to have the Allow to be read first. It didn't make any sense to me how it was written

log32

Testing in on a real system always provides the best answer to dilemmas.

Roguetadhg

I agree that labbing with the book helps to retain, as well as solves it's own issue.

The way I have my current lab, I have a lot of trouble doing it. I'm going to plop down the cash for a new nic soon. Trying to decide Dual or Quad (Lack of expansion slots in my dying motherboard!)

W Stewart

I'm not sure about which one is read first but it is possible for it to read host.deny first and then host.allow and not necessarily drop the packet immediately upon reading host.deny. It would depend on the type of access list it is. I think the term might be last match or something like that which is probably a less common type of firewall these days. If you ever use the freebsd firewall then you would have to specify the word quick for it to drop the packet immediately upon finding a match. Without that word it would go down the entire list. Not necessarily saying this is how host.deny/host.allow works but it is possible for an access list to operate that way.

Edit ipfilter is the firewall I was referring to. Basically the last matching rule applies. From what I've read that seems to be a fairly old way of doing things. It's also normally stateless without adding a specific flag.

marco71

Roguetadhg wrote: »

So I'm reading my book (I've been more than slacking on this!) and I got to a part saying:

/etc/hosts.deny | vsftpd: ALL
/etc/hosts.allow | vsftpd: 192.168.1.10, 192.168.1.102

"Be aware that hosts.deny is read and applied first, followed by hosts.allow. That means any directive in hosts.allow trumps any conflicting directive in hosts.deny. If an unauthorized host tries to connect, the request fails."

It's probably because I've been around other filtering methods but the context seems wrong to me.
1) If hosts.deny is read first AND the /etc/hosts.deny is written to deny everything - wouldn't everything be denied?

So in theory:
A packet comes from 192.168.1.10. It's read by hosts.deny (Afterall, It's read first). The packet is dropped (It's filter marks ALL). That's it. /etc/hosts.allow will never get a chance to say "Whoa boy, simmer down!"

With that said:

"Any directive in hosts.allow trumps any conflicting directive in hosts.deny"
Hosts.allow will overrule hosts.deny checking.

My Question:
Am I reading this correctly?
If yes: Why is /etc/hosts.deny read first prior allowing service access?

It seems inefficient to not use /etc/hosts.allow first, and then have /etc/hosts.deny read second.

The book is WRONG !!!
Actually, both /etc/hosts.allow, /etc/hosts.deny are read, but when construct the access control table (a sort of ACL), first occurrence in hosts.allow is considered, access is granted and no more (similar to Cisco ACLs) entries are processed; if no matching entries in hosts.allow, but in hosts.deny, then access is forbiden, otherwise access is granted if no match for any /etc/hosts.* (implicit is grant all, the opposite to Cisco deny all)
More details: man hosts_access; man hosts_options

ACCESS CONTROL FILES
       The access control software consults two files. The  search  stops  at
       the first match:

       &#65533;      Access  will  be granted when a (daemon,client) pair matches an
              entry in the /etc/hosts.allow file.

       &#65533;      Otherwise, access will be denied when  a  (daemon,client)  pair
              matches an entry in the /etc/hosts.deny file.

       &#65533;      Otherwise, access will be granted.

Note: if same entry is specified in both files, then access is allowed; for ex. if both files contain:
vsftpd: 192.168.1.10
OR even:
vsftpd: ALL
then host 192.168.1.10 can access ftp server

ChooseLife

When in doubt, read the man page

$man hosts.allow

ACCESS CONTROL FILES
       The access control software consults two files. The search stops at the first match:

       ·      Access will be granted when a (daemon,client) pair matches an entry in the /etc/hosts.allow file.

       ·      Otherwise, access will be denied when a (daemon,client) pair matches an entry in the /etc/hosts.deny file.

       ·      Otherwise, access will be granted.

       A non-existing access control file is treated as if it were an empty file. Thus, access control can be turned off by providing no access control files.