Alternative to /etc/hosts/allow on CentOS8

Hi all,

What's the alternative to using /etc/hosts.allow under RHEL/CentOS 8?

A little research indicates that hosts.{allow,denied} files are obsolete. The same articles seem to suggest using firewalld instead.

My issue is that we don't run firewalld on any of our RHEL/CentOS systems, so am unable to use that. Is there a simpler alternative, similar to how hosts.allow worked?

Thank you!

One alternative for filtering is iptables, or its front-end UFW.

What were you trying to do with TCPwrappers anyway? It has been made redundant since the 1990s, except for a few weird use-cases which also expired shortly thereafter.

Hi, I just wanted to ensure only SSH connections from 10.x.x.x are accepted.

For instance, our /etc/hosts.allow on all our applicable servers contains:

"
sshd : 10. : allow
sshd : ALL : deny
"

This has been working as expected. So just wanted a quick easy alternative for CentOS8.

Cheers

Ok. You can, and probably should, do that with iptables.

Alternatively you could take a look at adding Match blocks in /etc/ssh/sshd_config and set up something for Match Address. See "man sshd_config" for that.

Forgive my noobness, but is iptables the spirutual/direct predecessor to firewalld? Or is there still a use case for both?

I suppose what I wish to clarify is whether I should indeed use iptables, or just move straight to firewalld.

Thank you for your time

Originally Posted by elliot01 Forgive my noobness, but is iptables the spirutual/direct predecessor to firewalld? Or is there still a use case for both? I suppose what I wish to clarify is whether I should indeed use iptables, or just move straight to firewalld. Thank you for your time

iptables is more the parent of forewalld. Either would serve your purpose.

Okay, thank you

I'm certainly no expert, but it is my understanding that firewalld (which I'm learning) is a "front-end" to iptables (about which I have absolutely no clue), and that the "rules" entered in firewalld became entries in iptables.

Do I have that right?

Actual packet filtering is conducted by the Linux kernel using the Netfilter framework.
iptables (formerly ipchains) is the traditional user space tool (amongst others) used to manipulate Netfilter.
firewalld is a front end to iptables.

The kernel Netfilter framework has been re-engineered to a new framework nftables with a new user space tool, nft, that helps with handling newer networking technologies.

The officially supported method of configuring your CentOS or RHEL firewall, is by using firewalld. Some people like to strip out Network Manager and bypass firewalld in favor of iptables/ip6tables, but I do not recommend doing so if your goal is to learn CentOS. Stick to the design.

The RHEL8 documentation on firewalld should cover all the basic configuration.

https://access.redhat.com/documentat...uring-networks

Originally Posted by mralk3 The officially supported method of configuring your CentOS or RHEL firewall, is by using firewalld. Some people like to strip out Network Manager and bypass firewalld in favor of iptables/ip6tables, but I do not recommend doing so if your goal is to learn CentOS. Stick to the design. The RHEL8 documentation on firewalld should cover all the basic configuration. https://access.redhat.com/documentat...uring-networks

"Stick to the design" is certainly valid advice, but I presume that if one already knows iptables, it would still be valid to use it instead. (I didn't, so I am learning firewalld -- 'tho I've not yet moved to CentOS 8).
Otherwise, I agree with you. Bite the bullet and learn the new way (systemd, anyone? -- not that there's much of an option there )

Thank you for posting that link...Much easier to work with than the man pages.

Originally Posted by scasey "Stick to the design" is certainly valid advice, but I presume that if one already knows iptables, it would still be valid to use it instead. (I didn't, so I am learning firewalld -- 'tho I've not yet moved to CentOS 8). Otherwise, I agree with you. Bite the bullet and learn the new way (systemd, anyone? -- not that there's much of an option there ) Thank you for posting that link...Much easier to work with than the man pages.

The default network packet filter in RHEL 8 is nftables-NOT iptables. Red hat is making a big push toward firewalld.

Hi

I would love still to use tcp-wrapper as it has features what firewall is not capable of doing.
Like - it can not filter port by remote host name. So it's kind of MFA protection to your TCP services.

Like on /etc/hosts.allow you could have:
ALL: 192.168.* # allow your local network
sshd: *.cc *.myisp.net # for SSH, allow only from your country cc and from your own ISP (or mobile operator)

/etc/hosts.deny should have:
ALL: ALL # Deny everything else

But because tcpwrappers are not supported on "modern" Linux systems - there should be systemd/socket option for it. Or compile your own tcpd -program to be called for each TCP based service which then would launch actual process.

On old days there was inetd services which were launched when something connected to port being listened. And first it launched tcpd (tcpwrapper) and if connection was accepted then actual process (like telnetd or sshd).

Br, Tobler

Hi

I would love still to use tcp-wrapper as it has features what firewall is not capable of doing.
Like - it can not filter port by remote host name. So it's kind of MFA protection to your TCP services.

Like on /etc/hosts.allow you could have:
ALL: 192.168.* # allow your local network
sshd: *.cc *.myisp.net # for SSH, allow only from your country cc and from your own ISP (or mobile operator)

/etc/hosts.deny should have:
ALL: ALL # Deny everything else

But because tcpwrappers are not supported on "modern" Linux systems - there should be systemd/socket option for it. Or compile your own tcpd -program to be called for each TCP based service which then would launch actual process.

On old days there was inetd services which were launched when something connected to port being listened. And first it launched tcpd (tcpwrapper) and if connection was accepted then actual process (like telnetd or sshd).

Br, Tobler