[SOLVED] hosts.allow and hosts.deny moved to .rpmsave, why?
FedoraForum.org - Fedora Support Forums and Community
Results 1 to 10 of 10
  1. #1
    Join Date
    Aug 2011
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question hosts.allow and hosts.deny moved to .rpmsave, why?

    I just noticed that hosts.allow and hosts.deny were missing on my system; both renamed out out of the way to .rpmsave files. Does anyone know why this happened?

    I mean, I know that RPM did it on upgrade of some package, and I assume it was the tcp_wrappers package. But, does anyone know why a recent update of that package included the instructions to remove these files? Where they deprecated? The man page doesn't say anything about that. Why would this be necessary?

    I noticed this after upgrading to Fedora30, as I was reviewing /etc files. I am assuming this did not compromise my system, in the meantime, but I forgot to check the file timestamps, so I'm not quite sure how long I had been running without those limits, and I cannot be 100 % sure it happened with the system-upgrade process. But, according the dnf.log files, the last time tcp_wraper RPM was updated was during the system upgrade.

    Also, 'rpmconf -a' did *not* catch these changes. I know that it does find and alert on other .rpmsave files, but it did not alert me to these files that were deleted without my knowledge. I'm assuming that is because these files are not officially owned by any package??? I guess that makes sense, but is certain to cause these errors as it does not conform to expected behavior.

  2. #2
    Join Date
    Aug 2011
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    Well, this is clearly part of it:

    https://fedoraproject.org/wiki/Chang...e_TCP_wrappers

    Geeze, I usually read the release notes and I don't remember reading that. The worst part is that is says "use another access control" method, but I'm not aware of a way to control the firewall so easily. Hmm, I'm not sure what to do. Does anyone know how to get dynamic block lists into fedora desktop firewall? Hell, how do you use fail2ban without tcpd? I mean, saying tcpd is 20 years old is all well and good, but am not aware of an equivalent replacement. Is there one?

  3. #3
    Join Date
    Aug 2011
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    There was an obscure reference to eBPF in the deprecation annoucement, but the link was to the original RFP for this feature and it didn't make clear how to use it, in production, as a replacement for tcpd. I found this, however, and I think it is getting there.

    http://0pointer.net/blog/ip-accounti...h-systemd.html

  4. #4
    Join Date
    Oct 2007
    Posts
    430
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    Another example of removing something that's very USEFUL, RELIABLE and UNIVERSAL.
    Naturally making many sites vulnerable.
    Sad indeed.

  5. #5
    Join Date
    Mar 2017
    Location
    USA
    Posts
    199
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    @tkalfaoglu - Agreed.

  6. #6
    Join Date
    Aug 2011
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    I ended up redesigning the implementation of my automated, nearly real-time ip blocking scripts based entirely on Fedora firewall-cmd. It was not easy because the interface is very different, but what I was recreating was exactly the same logic. I tried to just translate from tcpd to firewall-cmd, but it didn't work. I had to learn firewall-cmd pretty deeply just to be able to do what I considered very simple with tcpd. But, I'm pretty happy with it, now that I finally got it working.

    I would rather have learned eBPF, but scripting firewall-cmd seemed easier.

  7. #7
    Join Date
    Jan 2009
    Location
    New Zealand
    Posts
    190
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    Pherhaps those files were renamed due to changes that made the old syntax obsolete ?. Or simply as they were not part of the package and were moved aside as a way of getting attention that action was required ?
    The tcp_wrappers still exist on F32. And while the files hosts.allow and hosts.deny are user created (and not part of a package as they are user created and not installed by a package as you noted) a little checking shows the packages to support those files exist.
    "man hosts.allow" works and refers to tcpd(8) and "man -s8 tcpd" still works, as does "man hosts_access", so following those back we get

    [mark@vmhost3 ~]$ ls -laR /usr/share/man | grep -i hosts.allow
    lrwxrwxrwx. 1 root root 17 Jan 31 16:42 hosts.allow.5.gz -> hosts_access.5.gz
    [mark@vmhost3 ~]$ find /usr/share/man -type f -name hosts_access.5.gz
    /usr/share/man/man5/hosts_access.5.gz
    [mark@vmhost3 ~]$ rpm -qf /usr/share/man/man5/hosts_access.5.gz
    tcp_wrappers-libs-7.6-95.fc32.x86_64

    Many will say that using firewall-cmd in your scripts is the way forward anyway. Although I personally disagree for the following reason.

    The biggest issue with Fedora is mis-information/mis-direction; for example quite a while back now there was a rumour firewalld would replace iptables.
    I am no guru on firewalld as can be seen by my lack of knowledge on why it is a permanently running process when as far as I can see it just passes commands through to iptables (anyone who thinks they are using just firewalld should try "iptables -L"). I personally use both together, firewall-cmd for named services and zones as its a lazy way of doing so, and on the same machine iptables for custom chains, dynamic blacklisting and anything complicated; works perfectly using both. One day firewalld may replace iptables and everything I am doing will break.

    Learning how to create your required scripting rules using firewall-cmd is useful for your scripting going forward on the assumption firewalld will not be replaced with another frontend to iptables; and I will continue to use the iptables command in the hope it will never be replaced regardless of what front-ends are wrapped around it.

    As a complete aside a quick "man firewall-cmd" shows it may at one time have been intended as a user friendly command line interface for managing firewall rules, but it now has so many options available that iptables/ip6tables is actually the simpler method to manage complicated firewall rules.

    The point is when Fedora says "A is being replaced by B" such statements must be totally ignored until the user personally determines that statement is true or not.
    The tcp wrappers package still exists on F32, as do man pages for hosts.allow should you wish to check the syntax of the files that were renamed out to revert to your origional solution.

    If you were using hosts.allow and hosts.deny to tightly limit access to a machine switching to firewall-cmd could cause you issues if anyone does a "firewall-cmd --add-service xx", unless you audit the services available regularly, as of course users with edit access to the directory /usr/lib/firewalld/services can create their own services to open tcp/udp ports zero to infinity. Of course those same users would have edit access to hosts,allow and hosts.deny but a firewalld service is a much more efficient way of opening a server wide up.

    There are many access points into a server, firewalld certainly does not replace the tcp wrappers and hosts.allow and hosts.deny. However hosts.allow and hosts.deny are still supported by F32 (if man pages are to be believed) so continue using them, in parallel with firewalld in case one of them does disappear in future.

  8. #8
    Join Date
    Aug 2011
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    Well, i don't have tcp_wrappers anymore so I cannot check, but I'm pretty confident the file format didn't change.

    In any case, it was announced recently that iptables was also being replaced with a newer system; I forget the name...nftables. Yeah, now in F32, firewalld uses nftables. (At least hat's what is implied by what I read prior to release, but I didn't check the release notes after F32 was announced.) So, I have to say that I think I made a good choice to switch to firewall-cmd. I was hoping, and it appears to be the case, that the transition to nftables would be seamless. So, at least in this case, I was doubly rewarded for my effort.

    I don't know. Maybe, if tcp wrappers is still an optional rpm, then I jumped the gun. But I'm pretty sure it got uninstalled automatically during some upgrade, because I don't remember doing it.

    I'm certainly not the kind of person who conforms for the sake of it, or just likes to have the new thing. But, I can sometimes be a bit of a rule follower; if Fedora says something is deprecated, that's a red flag for me and I don't like to be caught aware. I guess that's just another thing about Linux that I think is so great: even the way you administer your system can be a personal choice.

  9. #9
    Join Date
    Oct 2007
    Posts
    430
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    The main problem is that many servers that come with RH are now built without the wrappers support.
    So, you can do a yum/dnf update and lose the protection instantly - and without being aware.
    In fact, the only reliable way is to do an "ldd" to find out if it has wrappers support.

    That's what makes it dangerous IMHO.

  10. #10
    Join Date
    Aug 2011
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: hosts.allow and hosts.deny moved to .rpmsave, why?

    Yes, good point. That is the real issue. Installing the package does not restore functionality.

    In a way, this is a return to the original implementation, i.e. inetd passes connections to tcpd who applies your rules and then passed the connection to the real daemon. To use tcp wrappers now, you would need to convert all your (nice?) systemd service files to run with tcpd as the port answering daemon. Ugh. Most of those services files, I assume, are maintained by Fedora, so you'd be editing files that get updated regularly. I'd say that is a completely unworkable system. It's much harder than when tcpd was originally invented. Back then, inetd was the master daemon and answered connections on behave of nearly all services, and it was easily configured in one master file.

Similar Threads

  1. [SOLVED]
    SSh - denyhosts - hosts.deny & hosts.allow
    By SteveT in forum Using Fedora
    Replies: 7
    Last Post: 27th January 2017, 12:08 AM
  2. /etc/hosts.allow and hosts.deny
    By bigmacbb63 in forum Security and Privacy
    Replies: 9
    Last Post: 19th March 2010, 10:22 PM
  3. how to configure hosts.allow and hosts.deny
    By nkjha in forum Security and Privacy
    Replies: 4
    Last Post: 19th January 2009, 04:10 PM
  4. hosts.deny vs iptables
    By cbrenchley in forum Using Fedora
    Replies: 3
    Last Post: 15th April 2008, 12:38 AM
  5. hosts deny file
    By quacked in forum Security and Privacy
    Replies: 15
    Last Post: 15th January 2008, 01:52 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •