** Changed in: tcp-wrappers (Ubuntu)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tcp-wrappers in Ubuntu.
https://bugs.launchpad.net/bugs/1839598
Title:
tcp_wrappers does not whitelisting of domains, vs IPs
Status in tcp-wrappers package in Ubuntu:
Won't Fix
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tcp-wrappers/+bug/1839598/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
