hosts.allow hosts.deny
Hosts:
/etc/hosts is used to resolve hostnames for machines behind the firewall, on the 192.168.1. LAN. If an entry is found in /etc/hosts, there is no need to go to the DNS to resolve either hostname or ip address. Here is an example
# Do not remove the following line, or various programs
# that require loopback on 127.0.0.1 or name resolved will fail.
127.0.0.1 localhost.localdomain localhost oururl oururl.net www.oururl.net
192.168.1.10 ourappserver
192.168.1.101 ibookg3
192.168.1.102 w95notebook
192.168.1.103 visiting machine
Hosts to allow & those to deny:
Since about RedHat 7 xinted’s ‘TCP Wrappers’ have been included in the OS, making it easier than ever to be selective about who gets to do what with the services your machine offers via the web. I’ve been told that this software & text-file-on-a-disk reading approach is not as efficient as a more hardware & RAM approach used in hardware routers & firewalls. But I’ve also been told it can keep up with all that can be thrown at the server via a T1.
/etc/hosts.allow and hosts.deny work as a pair to control access to your server. If both files are empty there are no limits and anybody at any ip address can, for example, try guessing userids & passwords all day long. Hosts.allow is read first and if the packet just received matches one of its rules it is let to pass. If no ‘allow rule’ is found the TCP Wrapper continues on to hosts.deny and looks there. If the packet’s ip address, or other criterion, is found there the service is instantly denied. Someone using putty to log into info465.net from anywhere in 200. or another banned network will see their putty window blip out without have the opportunity to enter a password or userid. Xinetd logs attempts, acceptances, and denials so this is easy to police.
Here are hosts.allow & hosts.deny for info465.net. It is an active mail server, hosts http & https web pages, and needs to be relatively ‘open’ for students using its ssh. It must run telnet to provide connectivity for applications that run behind the firewall, but it restricts telnet access to the LAN 192.168.1. If I want to get to it from somewhere else via telnet for some reason I can uncomment the line in hosts.allow and edit it.
Hosts.allow:
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
#in.telnetd: 192.168.1., 128.172.188.201, 64.83.20.139, 64.83.20.138, \
# 128.172.189.
in.telnetd: 192.168.1.
sshd: 70.16., 207.228.
ipop3d: ALL
sendmail: ALL
Hosts.deny:
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
in.telnetd: all
sshd: 61., 62., 64.179., 65., 67.18., 69.198., 80.53., 81., 82., 83., 84., \
128.171., 128.123., 128.146., 128.233., \
130., 134., 137., 139., 140., 142., 143., 147., 148., 155., 168., 193., 195., 196., 199., \
200., 201., 202., 203., 205., 206., 207., 209., 210., 211., 212., 213., 217., 218., 219., 220., 221., 222.
Here are hosts.allow & hosts.deny for a more restrictive firewall/mailserver where nobody is expected to ssh in except its administrator, and that is only from a few places outside & anywhere in the LAN. The hosts.deny script says ALL: ALL, meaning that everybody not found in hosts.allow is denied services.
Hosts.allow:
# hosts.allow
ipop3d: 192.168.1.
sendmail: ALL
sshd: 128.372.188.267, 67.679.1.379, 192.168.1.
Hosts.deny:
# hosts.deny
ALL: ALL
Decide which way your server’s TCP needs to be wrappered, most likely to be restrictive…
