You put the line `ALL: ALL` in /etc/hosts.deny expecting the host to refuse everything, yet the Apache web server keeps serving pages to any client. Why is the rule ignored?
LPIC-1 Exam 102-500, objective 110. Security easy
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Correct The web server is not linked against libwrap, so it never consults /etc/hosts.allow or /etc/hosts.deny at all.
Correct. The access-control tables are read by library code inside the daemon, or by the tcpd wrapper in front of it. A program that does not call that library has no reason to look at the files.
Not correct The tables are only consulted for services started by inetd or xinetd, never for standalone daemons.
Wrong. Any standalone daemon that is linked against libwrap, historically vsftpd and many others, checks the tables on each connection. Being started by a superdaemon is not what makes the rules apply.
Not correct ALL: ALL is only valid in /etc/hosts.allow; in /etc/hosts.deny the daemon list must name a real program.
Wrong. The wildcard ALL is valid in the daemon field and the client field of either file. The syntax in the question is correct; it is simply never read by this daemon.
Not correct /etc/hosts.deny is consulted only for connections arriving from outside the server's own subnet.
Wrong. There is no locality exemption. For a wrapped service the rules are evaluated for every connection, including one from the same subnet or from 127.0.0.1.
Why
TCP wrappers are not a kernel-level filter: /etc/hosts.allow and /etc/hosts.deny only bind services that call the libwrap access-control routines, either directly or through tcpd. Anything else, including modern OpenSSH, which dropped libwrap support in 2014, ignores them entirely. Real host-wide filtering belongs in a packet filter such as nftables or iptables, or in the daemon's own configuration.
Where this comes from
- Cited
- manual page hosts_access(5)
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 110 and space the ones you get wrong.
More questions on this objective
- During an audit you must list every file under /usr that has the set-user-ID bit set, regardless of what its other permission bits are. Which command does that? machine-checked
- You locked the password of the account `intern` and confirmed that its hash in /etc/shadow now begins with an exclamation mark. The intern nevertheless still reaches a shell on the host over SSH, without being prompted for anything. What is going on, and what actually stops it? machine-checked
- You have just been added to a sudo rule on a host and want sudo itself to report which commands you are allowed to run there, without running any of them. Type the complete command. machine-checked
- A daemon started from your bash session keeps hitting a 'too many open files' error. Which command raises the limit on open file descriptors for the current shell and the processes it starts to 4096? machine-checked
- You are about to take a server down for maintenance and want ordinary users refused at login for the next hour, with an explanatory message, while root can still get in. On a system using PAM's pam_nologin, creating which file achieves this? machine-checked
- Which two commands report the users who are logged in right now, rather than a history of past logins? (Choose two.) machine-checked