Putting It All Together

Let's take all the examples given in this chapter so far, and build a complete /etc/hosts.allow to protect a hypothetical system on a network. We must first inventory the network resources this system offers, the IP addresses we have on the network, and the users we wish to allow to connect:

∙Our IP range is 192.168.0.0/16. On our network, we are running telnet, ftpd, and portmap(8).

∙We have a competitor who we do not want to access our system,[3] whose IP address range is 10.5.4.0/23.

∙We make the somewhat paranoid decision that hosts with incorrect information on their DNS servers might be attackers, and reject connections from them.[4]

∙Hosts on our network may use the portmap daemon, but hosts on other networks cannot. Anyone on the Internet may attempt to access our FTP and telnet servers. (They will still need a username and password to get anywhere, of course!)

While these requirements are fairly complicated, they boil down to a very simple set of rules:

...............................................................................................

#reject all connections from our competitor, and hosts with invalid DNS ALL : PARANOID 10.5.4.0/23 : deny

#allow our network to use portmap, but deny all others portmap : ALL EXCEPT 192.168.0.0/16 : deny

#now that portmap is safe & competition blocked, allow telnet & FTP ALL : ALL : allow

...............................................................................................

You can find many more commented−out examples in the /etc/hosts.allow file on your FreeBSD system or the hosts_allow(5) man page.

[1]If your goal is to log all attempted connections to your system, on any port, this is more reliably done with the net.inet.tcp.log_in_vain and net.inet.udp.log_in_vain sysctls (see the Appendix). These sysctls will log all attempts to contact any port on your system, not just wrapped daemons. [2]Strictly speaking, this is not true. But remember from Chapter 5 that UDP is connectionless; there is no connection to return the response over, so you have to jump through some very sophisticated and annoying hoops to make twist work with UDP. Also, programs that transmit UDP generally don't expect a response in such a manner and are not usually equipped to receive or interpret it. Twisting UDP isn't worth the trouble.

[3]Specifically blocking a competitor from using services you provide to the rest of the world is not a good idea. They can get those services easily enough by using a dial−up connection, and it just makes you look bad.

[4]This is a very careful stance. Hosts with an incorrect DNS entry are most probably on a network with neglected nameservers or incompetent/overworked administrators. But of all attacking hosts, attackers are more likely to deliberately misconfigure their DNS.

165