I also use the hosts.allow and hosts.deny files. It's a shame that support for them will be removed. It's easier than iptables. -- vic@demuzere.be :: http://vic.demuzere.be :: PGP: 0x6690CF94 My software never contains bugs, it just develops random features. Sent from my phone, please excuse my brevity. On Jul 16, 2011 7:06 PM, "Peggy Wilkins" wrote:

I am an end user who is very unhappy about the removal of this option. I didn't even know dropping tcp_wrappers was under consideration; had I known that I would have spoken up with my vote against removing support.

The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed.

IMO for users who want to use this feature, the burden is on the end user to find which services support tcp wrappers and which don't. A default "allow" policy makes this simple.

Surely I'm not the only tcp wrappers user out there. I will sorely miss this option and strongly wish it to remain.

On Saturday 16 July 2011 19:09:47 Vic Demuzere wrote:

I also use the hosts.allow and hosts.deny files. It's a shame that support for them will be removed. It's easier than iptables. I find iptables more easier, and intuitive.

old hosts.allow: sshd: 192. ntfs: 192. iptables: -A INPUT -j REJECT -A INPUT -p tcp -s 192.168.0.0/24 --dport ssh -j ACCEPT -A INPUT -p tcp -s 192.168.0.0/24 --dport nfs -j ACCEPT -A INPUT -p udp -s 192.168.0.0/24 --dport nfs -j ACCEPT -- Andrea

On 16 July 2011 19:32, Vic Demuzere wrote:

So, you're saying that those 4 lines are easier than the 2 short ones in hosts.allow? Ah well, I'll have to learn to write iptables scripts then, I suppose. I mean its more intuitive in that way, you've more power on what is accepted and what isn't.; e.g. you can apply filters only to one interface.

Why you should write an iptables script? BTW, sorry "-A INPUT -j REJECT" blocks everything then have to be at the last line, and not at first! -- Andrea

Mind if I try to clear a few things up here? 1. Yes Andrea, your iptables rules will most likely not achieve the desired effect, as placing the REJECT on the top will REJECT traffic before it gets to the ACCEPT. 2. tcp_wrappers is old and logically %100 redundant with a subset of the features of iptables 3. tcp_wrappers is made to operate on a per application layer, this means that the ALL:ALL in allow.deny only blocks applications that are linked with the libwrap librairy. This means that tcp_wrappers denial only protects against a small subset of applications and can create a false sens of security. 4. Fewer and fewer applications make use of tcp_wrappers, this means that updates to packages can open up security holes because of easily unnoticed upstream changes. A good example of this is when vsftpd dropped default support for tcp_wrappers a few years ago and an update could transparently remove the security layer. 5. tcp_wrappers is a slow solution, it creates many checks for every application connection which iptables does inside kernel space in a fraction of the time. 6. tcp_wrappers was made to be (and still is) a discretionary access system (DAC) back in the 80s before OS level firewalls were readily available. DAC security systems logically unwise to trust and are outdated, reflecting the days of the "safe internet". In the end, I tell people that using tcp_wrappers is unnecessary and unwise, iptables is VERY powerful, and once you understand how rules are constructed and parsed it is an easy and manageable solution. Thanks to the Arch devs for taking this out, this was the right move and I will argue that it has made Arch more secure by not supporting outdated security constructs. -Thomas S Hatch

On 07/16/2011 09:51 PM, Peggy Wilkins wrote:

On Sat, Jul 16, 2011 at 1:42 PM, Thomas S Hatch wrote:

...

In the end, I tell people that using tcp_wrappers is unnecessary and unwise, iptables is VERY powerful, and once you understand how rules are constructed and parsed it is an easy and manageable solution. I have nothing to say against iptables and other full firewall solutions. However, for my part running a number of desktops for other people at work with only sshd as a service, tcp wrappers plus denyhosts (plus disabling password authentication for good measure) already does exactly what I want. Performance doesn't enter into this issue for us, we have so many spare CPU cycles it's comical.

...

Thanks to the Arch devs for taking this out, this was the right move and I will argue that it has made Arch more secure by not supporting outdated security constructs. I view it as taking away my freedom to choose to run what I want in

Everyone doesn't have the same circusmstances and needs. I just would like this option to continue because I'm using it now and I find it useful and it meets my immediate needs. I also don't need my time at work diverted into a sudden project to write firewall rules that work for every desktop. You're better of blocking unwanted attempts at ssh with iptables or use sshgaurd. Or you could try http://smarden.org/ipsvd/ the simplest possible way. This is a major change. A large part of the reason I chose Arch is because it is straightforward to configure, hence doesn't require a lot of my time (which is properly spent running servers, not desktops) -- an easy way to get Linux on the desktop for our site which is otherwise all Windows desktops. I already know the limitations of my choice (and I use full firewalls in other situations).

Surely there is a good compromise possible... There

-- Jelle van der Waa

On Sat, Jul 16, 2011 at 3:58 PM, Thomas Bächler wrote:

Anyway, sshd can be configured to deny connections depending on the host, you don't need tcp_wrappers for that.

The cost of that solution is requiring sshd restart every time one wanted to modify access. Not the end of the world though it's susceptible to human error if you forget to do it.

On Sat, Jul 16, 2011 at 7:32 PM, Vic Demuzere wrote:

On 16 July 2011 19:22, Andrea Scarpino wrote:

...

old hosts.allow: sshd: 192. ntfs: 192.

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

So, you're saying that those 4 lines are easier than the 2 short ones in hosts.allow? Ah well, I'll have to learn to write iptables scripts then, I suppose.

It's a shame that you doesn't know how to write iptables scripts. (joke) tcp_wrappers are so old and so limited. I'm proud that archlinux drop this. Regards, -- Sébastien Luttringer www.seblu.net

On 16-07-2011 18:13, Andrea Scarpino wrote:

Technically this is what we did: without tcp_wrappers every input is accepted now.

I'd say that if not using iptables most input was already being accepted anyway so not supporting tcp_wrappers at all will make users more aware of what is allowed in.

You've to setup iptables to deny all input and accept only what you need. I never used iptables before, but now I find its syntax really simple, and powerful.

And while you are at it you might want to consider restricting the allowed outbound ip/ports for good measure ;) -- Mauro Santos

On Sat, Jul 16, 2011 at 3:23 PM, Ionut Biru wrote:

On 07/16/2011 08:06 PM, Peggy Wilkins wrote:

...

The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users.  An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW"  out of the box.  Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed.

i read the news entry couples of times and I don't get it how you reach this conclusion. Really, this is not the reason and I found your comment hilarious.

I was referring to this: "Additionally, newer daemons and applications are inconsistent in their support for libwrap, leading to confusion as to whether an application supports the library." This is true, it is confusing. My response was to say, well, change the default config then, and that criticism won't carry the same impact. (To be honest I have no idea what Arch's default config is for /etc/hosts.{allow|deny} because I edit it within minutes of a new install, but it seems that if it were default allow for ALL then it wouldn't cause as much trouble for people who wonder why sshd or whatever isn't working...)

users who want this feature can as well recompile the desire services with this support.

I will again say I chose Arch because I don't have to spend my time doing that (for a desktop OS); I very much appreciate the people who put the time into compiling things so I don't have to. I spend a fair amount of time compiling software at work, and I don't want a larger list of things to recompile regularly. I am not intending on continuing to bore everyone with my opinion here... I still wish support would stay, but it's not my decision, I just wanted to speak up in case anyone but me cared (and apparently I really am the only one...).

I mentioned that I consider tcp_wrappers to be a DAC, someone asked me to clarify on MAC and DAC systems, so I put up a blog post: http://red45.wordpress.com/2011/07/17/mac-and-dac-core-security-concepts/

On Sun, Jul 17, 2011 at 2:18 PM, Fons Adriaensen wrote:

On Sun, Jul 17, 2011 at 01:56:58PM -0600, Thomas S Hatch wrote:

...

I mentioned that I consider tcp_wrappers to be a DAC, someone asked me to clarify on MAC and DAC systems, so I put up a blog post:

http://red45.wordpress.com/2011/07/17/mac-and-dac-core-security-concepts/

You equate

MAC = whitelist DAC = blacklist

Used as such they are redundant, you could just say white/blacklist instead. I've seen other definitions:

MAC: imposed on all applications, they can't opt out and it doesn't require their support. According to this, iptables is a MAC even if can be configured either in whitelist or blacklist style as you show in your blog.

DAC: voluntary, only applies to those apps that have been compiled or set up to use it. In this sense tcp_wrappers is a DAC.

So we reach the same conclusion, but from different definitions.

Ciao,

-- FA

I like it, I think that we agree, iptables is a MAC that can be configured logically to act as a DAC, whereas tcp_wrappers is just a DAC. I should clarify in my blog post that I am trying to show the concept of what MAC and DAC are, rather than the implementation classification. Thanks for the clarity :)

What do the devs intend to do with packages that depend on tcp_wrapper such as syslog-ng, xinetd and esound which is a dependency of gstreamer? Richard.

On Sat, Jul 16, 2011 at 3:04 PM, Thomas Bächler wrote:

Am 16.07.2011 23:00, schrieb Richard Ullger:

...

What do the devs intend to do with packages that depend on tcp_wrapper such as syslog-ng, xinetd and esound which is a dependency of gstreamer?

Richard.

None of those depends on tcp_wrappers.

For those packages that have tcp_wrappers listed as deps, they can all be built without tcp_wrapper support. the tcp_wrapper package provides NO additional functionality required by any application. It can be removed cleanly.