Dropping tcp_wrappers support - functional implications to users

graysky · 2011-07-16 14:35:12

Dan McGee wrote:
tcp_wrappers support is being dropped frrom all packages and the package removed from [core]. This is due to upstream not having released a new version since April 1997. Additionally, newer daemons and applications are inconsistent in their support for libwrap, leading to confusion as to whether an application supports the library.
If you currently use /etc/hosts.allow or /etc/hosts.deny for security or logging purposes, you will need to adjust accordingly and use another tool such as iptables.

If I'm reading that correctly, does it mean that the syntax taught in the beginners guide as well as numerous other wiki articles is wrong from here on out?

syntax example:

#
# /etc/hosts.allow
#
# End of file

distccd:    192.168.0.
tcp:        192.168.0.
sshd:        192.168.0. 127.0.0.1
cupsd:    192.168.0.
nfsd:        192.168.0.
rpcbind:    192.168.0.
mountd:        192.168.0.

EDIT: the answer to my question is, yes. A great alternative is ufw. For an example, see this thread.

Last edited by graysky (2011-07-17 02:02:41)

cybertorture · 2011-07-16 14:54:59

It seems that way, but i am not tested it yet .
Anyway iptables is defenatly better way to do this IMO .

Evilandi666 · 2011-07-16 15:17:44

Not sure what to do now, normalle hosts.deny blocks all and hosts.allow allows for some services some IPs. How to translate that to iptables? Do I even need to do that? (On Ubuntu for example every ip can connect to sshd)

cybertorture · 2011-07-16 15:36:05

Not sure what to do now

- do not panic

hosts.deny blocks all and hosts.allow allows for some services some IPs. How to translate that to iptables?

- try community/gufw for an instance

Do I even need to do that? (On Ubuntu for example every ip can connect to sshd)

- ubuntu way , arch way .. see teh difference ?

toofishes · 2011-07-16 15:40:09

I uninstalled tcp_wrappers after finishing the rebuild, which contains the /etc/hosts.allow and /etc/hosts.deny files. So the syntax changes are really simple- they don't even exist anymore.

As far as iptables rules, @graysky, you can write near equivalents. I do REJECT as my default on the INPUT chain, and then add rules like this:

iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport ssh -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport nfs -j ACCEPT
iptables -A INPUT -p udp -s 192.168.0.0/24 --dport nfs -j ACCEPT

And similar for the rest of the services.

graysky · 2011-07-16 17:59:00

@toofishes - If my current /etc/hosts.allow just defines allowing anything from 192.168.0. would it be more simplistic and "safe" to simply use this line as the sole rule in the ufw or am I missing something...

# ufw allow from 192.168.0.0/16

ilpianista · 2011-07-16 18:00:08

Talking in the ML, the easiest way is to copy /etc/iptables/simple_firewall.rules to iptables.rules and add those rules.

tesjo · 2011-07-16 18:33:41

I did not see it in the ML, so I'll bring it up here. I am not doing an install/reinstall anytime soon, so I will make the necessary changes this is no problem. But I think that iptables should be running as daemon by default installation ( arch initial installation not package installation ) with reject/deny all, in the same way that it was default with tcp_wrappers.

student975 · 2011-07-16 18:52:56

tesjo wrote:

But I think that iptables should be running as daemon by default installation

I'm not sure making this service default is useful at such common case as home router using (and last one has all needed filtering capabilities). Probably I'm wrong and the case isn't such widespreaded as I think.

toofishes · 2011-07-16 18:53:52

We don't run many daemons at all by default (DAEMONS=(hwclock syslog-ng network netfs crond) is the default), so out of the box as far as I know there are no real network security issues. You need to add sshd, and that explicit action should make one think about what needs to be done to firewall or restrict it.

Remember that we don't like to force configuration on anyone.

Tea2 · 2011-07-17 01:17:10

I'm not sure if this is really the right thread for this, but I guess it's better than creating a new one.

Can we please spend a little more time considering this move? I just looked on the mailing list and the decision to remove this package looks incredibly rushed. I don't think the devs have really considered the full implications of removing this package.

iptables is not a sufficient replacement. Its usage is a lot more complex and anyone who's used to using hosts.{allow,deny} might be taken aback by this. Myself included.

Please do not remove the package from [core]. If you're really concerned about it being a little bit old, you can just take it out of the default installation. Removing it completely from the official repositories is no way helpful or necessary. Please think again.

graysky · 2011-07-17 01:21:25

@Tea2 - I think it's due to the staleness of the package as well as the need for the devs to provide extra work just to keep the rest of the packages functional working around it. I think ufw is a pretty good alternative.

Tea2 · 2011-07-17 01:39:26

graysky wrote:

@Tea2 - I think it's due to the staleness of the package as well as the need for the devs to provide extra work just to keep the rest of the packages functional working around it. I think ufw is a pretty good alternative.

Forgive my ignorance but what sort of work are you talking about? Surely, the work needed to keep a package working with another is upstream work, with the package maintainers ensuring that the dependencies are in order?

On the issue of alternatives, personally I hate iptables. It's more complex than it needs to be; the process of adding a single rule is a little bit tricky. Then there's no assurance it actually worked, since the syntax of a single command is a little bit confusing. I have no real issue with iptables other than it's ugly. Since Arch is based on the KISS philosophy, should we not keep the hosts files based on their simplicity? I have not used ufw, but I've checked it out in the wiki and it actually looks pretty good and I think I'll get it installed on my VPS asap so I can start experimenting with it.

I can understand removing tcp_wrappers from the default installation stack, but completely removing the option is going too far. I'm sure it can be quite comfortable in [extra] or something.

graysky · 2011-07-17 01:42:44

@Tea2 - again, I think the issue is with the dev's time to patch it and/or other packages that don't have native support for it since it's been over 14 years since it was last updated. See the ML for more, I thought I read a post about that.

Last edited by graysky (2011-07-17 01:43:15)

Tea2 · 2011-07-17 01:43:52

I will do, thanks for the information.

skottish · 2011-07-17 01:45:29

Tea2 wrote:

graysky wrote:
@Tea2 - I think it's due to the staleness of the package as well as the need for the devs to provide extra work just to keep the rest of the packages functional working around it. I think ufw is a pretty good alternative.
Forgive my ignorance but what sort of work are you talking about? Surely, the work needed to keep a package working with another is upstream work, with the package maintainers ensuring that the dependencies are in order?
On the issue of alternatives, personally I hate iptables. It's more complex than it needs to be; the process of adding a single rule is a little bit tricky. Then there's no assurance it actually worked, since the syntax of a single command is a little bit confusing. I have no real issue with iptables other than it's ugly. Since Arch is based on the KISS philosophy, should we not keep the hosts files based on their simplicity? I have not used ufw, but I've checked it out in the wiki and it actually looks pretty good and I think I'll get it installed on my VPS asap so I can start experimenting with it.
I can understand removing tcp_wrappers from the default installation stack, but completely removing the option is going too far. I'm sure it can be quite comfortable in [extra] or something.

I imagine that there are many users that feel the same way that you do, so I recommend putting it into the AUR.

maff · 2011-07-17 01:53:24

I agree. While I can understand that some people are concerned that tcp_wrappers is an old package, it still works perfectly, and a lot of people I know who use Arch depend on hosts.allow/hosts.deny to some degree.
That, and the announcement also states that denyhosts is being removed, too. fail2ban is an alternative, yes, but it's an alternative with a confusing configuration file. Denyhosts is simple and extremely effective.
I don't see any proper, real reason why tcp_wrappers should be removed, when it still works perfectly.

toofishes · 2011-07-17 02:16:15

You can't just "remove it from the default installation stack". It is a compile time option in every package that uses it and requires explicit code to call, use, and abide by your rules in /etc/hosts.{allow,deny}. Removing it from your system would cause every package to not run. If by "rushed", you mean I proposed it once 11 months ago, once 7 months ago, and it came up again last week. That doesn't sound too damn rushed to me, but to each his own.

Finally, we're not here to please users and bow down to the 30 people using tcp_wrappers, however disappointing that sounds. As developers we are here to enjoy the work we put into the distro, and shedding dead weight, 14-year-old software is somewhat entertaining so we took it on.

Mr.Elendig · 2011-07-17 02:23:57

This is a perfect time to bring up a couple of old quotes. "If you don't like how the packager/developer did it, do it yourself" and "abs/aur exists for a reason"

You are free to build tcp_wrappers and rebuild anything that you want to use it yourself if you really need it.

Allan · 2011-07-17 02:28:01

maff wrote:

I don't see any proper, real reason why tcp_wrappers should be removed, when it still works perfectly.

I'll add here that it did not work perfectly. We had to patch the shit out of the source to get it somewhat functional.

Another key point is that there was never really a clear indication of which software used its functionality and which did not. So, being are real bastard... we could just continue on a compile all software as we are now (without tcp_wrappers) and just leave tcp_wrappers in the repo... Then people could naively assume their hosts.{allow,deny} are working fine. The only difference to now is that we would know it does nothing for _all_ software rather than _some_ software.

jaco · 2011-07-17 10:16:33

Frankly, i was first upset too... Yesterday inetd, today hosts.allow, tomorrow ifconfig, what then? Where are my good'ol Unix simple tools going ?

Then i've installed ufw and i've found it's as easy than configuring tcp_wrappers (in fact, i've found it's even easier).

wonder · 2011-07-17 10:32:46

jaco wrote:

Frankly, i was first upset too... Yesterday inetd, today hosts.allow, tomorrow ifconfig, what then? Where are my good'ol Unix simple tools going ?
Then i've installed ufw and i've found it's as easy than configuring tcp_wrappers (in fact, i've found it's even easier).

tomorrow esound

cybertorture · 2011-07-17 11:48:16

ifconfig ? wasnt this thing in net-tools ( depricated ) ?

@wonder esound ! yes finally

litemotiv · 2011-07-17 11:57:06

The decision has been made and background information from the developers has been provided. Any further technical questions about how to replace tcp_wrappers with iptables or ufw may take place in dedicated threads in Networking, Server & Protection.

Closing up.

Arch Linux

#1 2011-07-16 14:35:12

Dropping tcp_wrappers support - functional implications to users

#2 2011-07-16 14:54:59

Re: Dropping tcp_wrappers support - functional implications to users

#3 2011-07-16 15:17:44

Re: Dropping tcp_wrappers support - functional implications to users

#4 2011-07-16 15:36:05

Re: Dropping tcp_wrappers support - functional implications to users

#5 2011-07-16 15:40:09

Re: Dropping tcp_wrappers support - functional implications to users

#6 2011-07-16 17:59:00

Re: Dropping tcp_wrappers support - functional implications to users

#7 2011-07-16 18:00:08

Re: Dropping tcp_wrappers support - functional implications to users

#8 2011-07-16 18:33:41

Re: Dropping tcp_wrappers support - functional implications to users

#9 2011-07-16 18:52:56

Re: Dropping tcp_wrappers support - functional implications to users

#10 2011-07-16 18:53:52

Re: Dropping tcp_wrappers support - functional implications to users

#11 2011-07-17 01:17:10

Re: Dropping tcp_wrappers support - functional implications to users

#12 2011-07-17 01:21:25

Re: Dropping tcp_wrappers support - functional implications to users

#13 2011-07-17 01:39:26

Re: Dropping tcp_wrappers support - functional implications to users

#14 2011-07-17 01:42:44

Re: Dropping tcp_wrappers support - functional implications to users

#15 2011-07-17 01:43:52

Re: Dropping tcp_wrappers support - functional implications to users

#16 2011-07-17 01:45:29

Re: Dropping tcp_wrappers support - functional implications to users

#17 2011-07-17 01:53:24

Re: Dropping tcp_wrappers support - functional implications to users

#18 2011-07-17 02:16:15

Re: Dropping tcp_wrappers support - functional implications to users

#19 2011-07-17 02:23:57

Re: Dropping tcp_wrappers support - functional implications to users

#20 2011-07-17 02:28:01

Re: Dropping tcp_wrappers support - functional implications to users

#21 2011-07-17 10:16:33

Re: Dropping tcp_wrappers support - functional implications to users

#22 2011-07-17 10:32:46

Re: Dropping tcp_wrappers support - functional implications to users

#23 2011-07-17 11:48:16

Re: Dropping tcp_wrappers support - functional implications to users

#24 2011-07-17 11:57:06

Re: Dropping tcp_wrappers support - functional implications to users

Board footer