Mind if I try to clear a few things up here? 1. Yes Andrea, your iptables rules will most likely not achieve the desired effect, as placing the REJECT on the top will REJECT traffic before it gets to the ACCEPT. 2. tcp_wrappers is old and logically %100 redundant with a subset of the features of iptables 3. tcp_wrappers is made to operate on a per application layer, this means that the ALL:ALL in allow.deny only blocks applications that are linked with the libwrap librairy. This means that tcp_wrappers denial only protects against a small subset of applications and can create a false sens of security. 4. Fewer and fewer applications make use of tcp_wrappers, this means that updates to packages can open up security holes because of easily unnoticed upstream changes. A good example of this is when vsftpd dropped default support for tcp_wrappers a few years ago and an update could transparently remove the security layer. 5. tcp_wrappers is a slow solution, it creates many checks for every application connection which iptables does inside kernel space in a fraction of the time. 6. tcp_wrappers was made to be (and still is) a discretionary access system (DAC) back in the 80s before OS level firewalls were readily available. DAC security systems logically unwise to trust and are outdated, reflecting the days of the "safe internet". In the end, I tell people that using tcp_wrappers is unnecessary and unwise, iptables is VERY powerful, and once you understand how rules are constructed and parsed it is an easy and manageable solution. Thanks to the Arch devs for taking this out, this was the right move and I will argue that it has made Arch more secure by not supporting outdated security constructs. -Thomas S Hatch
