Denyhosts vs Fail2ban aka tcp_wrappers vs iptables
Posted 07-22-2010 at 03:58 AM by unSpawn
Tags fail2ban, hosts.allow, hosts.deny, iptables
At times denyhosts is being recommended over fail2ban. The common misconception being these applications are equal. They're not, OK in more than one way, but focusing on method of filtering denyhosts uses tcp_wrappers by default where Fail2ban uses iptables by default.
Using tcp_wrappers means a packet has to be delivered to that service. The serving application is responsible for reading /etc/hosts.{deny,allow} to determine itself if a connection is allowed or not. Requiring a network connection being set up exposes the application to for instance malformed packets and it requires disk I/O for having to write /etc/hosts.deny entries. Also tcp_wrappers does not work if an application was not compiled with libwrap (as in 'ldd /path/to/application|grep libwrap').
In contrast the active part of the Netfilter framework resides in memory completely. Sure blocking an IP address in the firewall means CPU cycles but not for a userland application and if logging is disabled no disk I/O is needed. More importantly the service does not get exposed as no packet is delivered to it.
That's not to say tcp_wrappers is without use. In a layered security approach having a /etc/hosts.deny "ALL: ALL" entry and carefully opening up holes in /etc/hosts.allow (and using access restrictions applications like say Xinetd services or web servers can be configured with) can help prevent the firewall from becoming a single point of failure.
Using tcp_wrappers means a packet has to be delivered to that service. The serving application is responsible for reading /etc/hosts.{deny,allow} to determine itself if a connection is allowed or not. Requiring a network connection being set up exposes the application to for instance malformed packets and it requires disk I/O for having to write /etc/hosts.deny entries. Also tcp_wrappers does not work if an application was not compiled with libwrap (as in 'ldd /path/to/application|grep libwrap').
In contrast the active part of the Netfilter framework resides in memory completely. Sure blocking an IP address in the firewall means CPU cycles but not for a userland application and if logging is disabled no disk I/O is needed. More importantly the service does not get exposed as no packet is delivered to it.
That's not to say tcp_wrappers is without use. In a layered security approach having a /etc/hosts.deny "ALL: ALL" entry and carefully opening up holes in /etc/hosts.allow (and using access restrictions applications like say Xinetd services or web servers can be configured with) can help prevent the firewall from becoming a single point of failure.
