TCP Wrappers (also known as tcp_wrappers) is a host-based networking ACL system, used to filter network access to Internet Protocol servers. It allows host or subnetwork IP addresses, names and/or ident query replies, to be used as tokens on which to filter for access control purposes. The original code was written by Wietse Venema in 1990 He maintained it until 1995, and on June 1, 2001, released it under its own BSD-style license. The tarball includes a library named Libwrap that implements the actual functionality. I had an email conversation with him that lead to nowhere. He does not agree with my request for a redesign.
Very concisely, there is no way as of now to whitelist a domain, vs an IP address. You need to know the IP address to which the domain resolves to beforehand, which makes domain updates impossible to process. This causes tremendous operational problems when the person you need to give access to has an IP address that changes often.
But I need to digress. Every foreign worker is a potential hacker, for there is no way to perform a security check on her/him. Many companies use them nevertheless because of the low cost. I know a company that hires North Korean engineers working out of mainland China. They log in for legitimate purposes to American corporate servers. They actually live in North Korea and are forced to back home every 3 weeks. They only have access to dynamic IP addresses, where a PTR record does not exist, thus, no reverse-hostname is possible. As a fact: no dynamic IP address has a corresponding PTR record.
The question is how to whitelist a remote worker’s IP automatically. This issue cannot be easily solved since commercial VPNs do not guarantee that the same IP will be offered on the next connection. Many small companies that hire foreign workers end up creating fence servers, but that is exponentially more insecure since now you have a potential hacker sitting comfortably inside your firewall, behind your line of defense. Your network may have access to other companies networks, all the way up to a power station or a government facility, maybe a nuclear facility. A very somber scenario.
Since Libwrap is the ultimate defense to keep hackers from controlling your servers, it should ONLY verify if an incoming connection resolves to a domain listed in /etc/hosts.allow. It does not. Prior, it performs a hostname check that invariably fails unless the pair IP address/ domain exists in /etc/hosts, but of course that information changes sometimes hourly. As a result of this problem, you cannot use it as a gatekeeper for remote access from dynamic IP addresses, increasing your level of insecurity.
As I said, I explained all these ideas to the author, Wietse, without success. He insisted that using a public key was how you protect servers. I disagree. Without Libwrap, which means IP whitelisting, a simple public key mechanism is suicidal. It is very easy to see why. In a first step, a hacker steals the pair public-private key from a box which has legitimate access to your network. Then he uses the pair in another box located in his country, from which he will access your network as if he were the legitimate client or worker. It happened to me already. Libwrap applied to a domain plus public key will perform infinitely better than a public key alone. In fact, public key alone should not be used at all. This is obvious since by using it, you are delegating your security to the box you are allowing to connect, so your entire network is now as secure as your client or worker’s home network, which you don’t control. You just opened the doors of your company wide-open.
What I suggest is to modify Libwrap so a domain listed in /etc/hosts.allow would work for real, just performing a simple DNS lookup to will match the IP address to the domain. Right now, this is impossible.
Hello Federico,
Wietse is correct. You will not get security benefits from your proposed changes.
Public key authentication, combined with a 2FA mechanism such as TOTP for interactive users, is the current best practice.
IP filtering is a useful tool; you can already have good benefits from allowing the /16 or /24 or whatever address ranges your contractors are expected to be using. That will drastically reduce the number of compromised hosts on the internet that can contact your server and perform password brute-force authentication attempts.
The single best security improvement you can make is disable password authentication in openssh-server and require authorized_keys to log in.
We will not make drastic changes to the design and implementation of tcp-wrappers.
Thanks for your interest in making Ubuntu more secure