Description of problem: It is ironic, or more probably, a consequence, just after libwrap is removed by default from rpcbind, a massive amplification attack using rpcbind is storming the world. Please make rpcbind honour tcpwrapper again. All it needs is a change to the rpcbind.spec file. --enable-libwrap in the configure area of rpcbind.spec and BuildRequires: libwrap-devel I am getting my machine hammered on as an amplifier for one of these attacks. It is not nice. This is a security critical situation which is why I have labelled it as a critical bug. How reproducible: Always Steps to Reproduce: Put your system on the web. Run gkrellm with the ethernet report active. Watch the steady 5 min traffic, which is steady rpcbind info requests with a spoofed return address. Run tcpdump to see the port 111 requests. The amplification on my machine is a factor of 10. On others it is even higher. 2. 3. Reproducible: Steps to Reproduce:
Patching rpcbind as above does not stop the external queries, but does seem to block the responses. Of course that means that your system has to handle the queries and go through libwrap and parse the hosts.allow file on each query. libwrap needs to cache its reading so it needs to parse only once, and make a vary quickly scannable table. But that is a whole other can of worms. (The reason given by the developer to removing tcpwrapper as the default was concern about the time taken.)
Thanks for the report. rpcbind has no registered maintainer in our database, so adding some packagers who appear in the changelog (to packagers: if you are maintaining it or intend to, please add yourself).
CC: (none) => guillomovitch, luigiwalser, mageiaComponent: RPM Packages => Security
TCP wrappers has never been a reliable security measure. Please use an appropriate firewall.
Component: Security => RPM PackagesSeverity: critical => enhancement
I just enabled tcpwrapper support in cauldron, as it is straightforward. I don't think it's worth the effort to push a security update in stable just for this, tough. As said in other comment, the security issue is not the lack of tcpwrapper support, it is the exposition of the service to the outside.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
Yes, it certainly is straightforward. The problem is that portmap/rpcbind has supported tcpwrappers for 20 years, and suddenly it is remove. And while I agree that firewalls are a more efficient mechanism, setting up a firewall is a far from trivial task unless your system is a single computer which actually does not use rpcbind anyway. If it is a more complex setup, the firewall setup in MCC is useless, and trying to figure ones way, for the first time, through shorewall is an exercise in frustration. I spent at least 5 hours on it, and still am not sure I have it right. My situation is one in which various computers, all connected to the net, nfs mount from a server. They MUST have rpcbind access, but the rest of the world does not. And they connect to each other by the web, not via a private lan. Ie, rpcbind MUST be exposed to the outside for the system to work. To use a firewall, one must learn the whole panalopy of nested zones, policies, rules, ... with no guidance. Is it worth pushing a security update? I would think so, precisely because so many people think that they are protected because then have portmap/rpcbind in hosts.allow, and it has worked until recently. Ie, breaking well established security on systems IS a security issue. And while hosts.allow is not the ideal protection, it is sure a LOT better than nothing. Because my system was unprotected for the past few months, I now get over a million rpcbind packets a day trying to use my (now protected) system. And of course because it is udp, the attacker gets no feedback that the amplification is not working. He just sells my IP to others and I get more and more packets. Ie, this removal of a level of protection which has been there for a long time has resulted in a effective DDOS attack on me. That is a security issue.
Status: RESOLVED => REOPENEDResolution: WONTFIX => (none)
I agree with Guillaume's resolution here. TCP Wrappers has a history of problems, such as ones like this bug, as well as various ways of bypassing it. It was invented a long time ago in a much different environment where the general level of trust of the participants on the network was a lot higher than ended up being the case on the Internet. Even when I started using Linux in 1999, it was a recommended best practice to not rely on TCP Wrappers to protect network services on the public Internet, but to use a proper firewall for that instead. TCP Wrappers is only still useful for simple access control within a LAN with a trust level more like what was the case when TCP Wrappers was invented. It is system administrator's responsibility to protect network services exposed to the Internet with a proper firewall. Just to address more specific points of your message, it was not just suddenly disabled, the MCC firewall does a fine job of blocking access to port 111, so shorewall's complexity is irrelevant, and it's not a bug in the package that you haven't appropriately configured your hosts for the security properties that they need. You may want to investigate the use of a VPN if those hosts need to access each other via RPC over the Internet. Changing the Mageia 5 rpcbind package would not be a "security update," but just an enhancement, enabling a feature. TCP Wrappers does not provide the security you are assuming that it does. As for the traffic amplification, that is an unfortunate property of the design of the RPC portmapper, and a reason that it should not be exposed on the Internet without being protected by a firewall.
Status: REOPENED => RESOLVEDResolution: (none) => WONTFIX