Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
I bring this up because we are discussing dropping it from Fedora. This would be far enough in the future that it wouldn't impact RHEL 7, and therefore won't affect anyone here for Quite Some Time*, but here in the new world order of CentOS, I thought it might be useful to check with some actual downstream users.
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
Your feedback appreciated. Thanks!
* and the standard caveats that Fedora doesn't necessarily determine the path for RHEL apply, of course.
On 2014-03-20, Matthew Miller mattdm@mattdm.org wrote:
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
I currently use it in conjunction with denyhosts, but have been considering moving to something like sshguard with iptables instead. If hosts.deny support disappeared then I would simply go that route when necessary.
May I ask what the reason is for considering dropping tcp wrappers support?
--keith
Various government entities may use it extensively. I don't recall if tcp_wrappers is in the USGCB baselines for RHEL, but I do believe its in several CIS benchmarks.
On 03/20/2014 03:55 PM, Keith Keller wrote:
On 2014-03-20, Matthew Miller mattdm@mattdm.org wrote:
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
I currently use it in conjunction with denyhosts, but have been considering moving to something like sshguard with iptables instead. If hosts.deny support disappeared then I would simply go that route when necessary.
May I ask what the reason is for considering dropping tcp wrappers support?
--keith
On Thu, Mar 20, 2014 at 04:00:49PM -0400, John Jasen wrote:
Various government entities may use it extensively. I don't recall if tcp_wrappers is in the USGCB baselines for RHEL, but I do believe its in several CIS benchmarks.
Good question. I checked with both that and the DoD National Checklist Program, and neither mention it. Also, unless I missed something else, the USGCB covers RHEL 5, so there won't be any impact there.
Are the CIS benchmarks something you could point me to?
On 03/20/2014 04:13 PM, Matthew Miller wrote:
On Thu, Mar 20, 2014 at 04:00:49PM -0400, John Jasen wrote:
Various government entities may use it extensively. I don't recall if tcp_wrappers is in the USGCB baselines for RHEL, but I do believe its in several CIS benchmarks.
Good question. I checked with both that and the DoD National Checklist Program, and neither mention it. Also, unless I missed something else, the USGCB covers RHEL 5, so there won't be any impact there.
Are the CIS benchmarks something you could point me to?
https://benchmarks.cisecurity.org/tools2/linux/CIS_RHEL5_Benchmark_v1.1.pdf
Also note, agencies or groups required to implement CIS or better who maintain a mixed environment may also use tcp_wrappers on all their platforms, as from a cursory glance, ever UNIX benchmark lists it.
I would recommend against dropping tcp wrappers.
On Fri, Mar 21, 2014 at 09:29:01AM -0400, John Jasen wrote:
https://benchmarks.cisecurity.org/tools2/linux/CIS_RHEL5_Benchmark_v1.1.pdf Also note, agencies or groups required to implement CIS or better who maintain a mixed environment may also use tcp_wrappers on all their platforms, as from a cursory glance, ever UNIX benchmark lists it. I would recommend against dropping tcp wrappers.
Thanks, that is helpful. Cross-platform compatibility is a strong argument. I think this points towards the updated "libwrap2" idea, although that does require someone who actually wants to do it.
On Thu, Mar 20, 2014 at 12:55:56PM -0700, Keith Keller wrote:
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
I currently use it in conjunction with denyhosts, but have been considering moving to something like sshguard with iptables instead. If hosts.deny support disappeared then I would simply go that route when necessary. May I ask what the reason is for considering dropping tcp wrappers support?
I think the main reasons are: upstream library isn't actually maintained since June 2001. The API is somewhat ugly and crufty. Possibly also one more place to check, making systems administration harder.
On Thu, Mar 20, 2014 at 4:05 PM, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Mar 20, 2014 at 12:55:56PM -0700, Keith Keller wrote:
What do you think? Do you rely on hosts.allow/hosts.deny a primary
security
mechanism? As defense-in-depth? Do you have policies which mandate it?
I currently use it in conjunction with denyhosts, but have been
considering moving to something like sshguard with iptables instead. If hosts.deny support disappeared then I would simply go that route when necessary. May I ask what the reason is for considering dropping tcp wrappers support?
I think the main reasons are: upstream library isn't actually maintained since June 2001. The API is somewhat ugly and crufty. Possibly also one more place to check, making systems administration harder.
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/
The reasoning here seems to ignore one of the main tenets of open source -- people contribute with the purpose of scratching their own itch. If there is such a time when tcp wrappers stops working due to bug or other changes, it's going to break a LOT of stuff. At that point, many people will have a huge itch to scratch, and there will be a spontaneous coalescense of support and code from the people who need it.
Why does there need to be a dedicated maintainer for something to be included/useful? That seems like a bureaucratic requirement that doesn't take into account the nature of open source. The project (tcp wrappers) exists as its own entity and will have a maintainer at the time when it needs one.
The only improvement that could be made is figuring out where a canonical code repository should exist for it.
Where is this discussion taking place in the Fedora community?
❧ Brian Mathis
P.S. Is this somehow related to your Next proposal and trying to make Fedora "exciting"?
On Mon, Mar 24, 2014 at 11:15:04AM -0400, Brian Mathis wrote:
P.S. Is this somehow related to your Next proposal and trying to make Fedora "exciting"?
Is it working? Got a pretty good thread going here.... :)
But in seriousness, no.
However, me asking here _is_ related to one of the things I've mentioned as a factor feeding into Fedora.next -- more direct communication lines to downstream distributions.
On Thu, Mar 20, 2014 at 4:48 PM, Matthew Miller mattdm@mattdm.org wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
Please don't remove it. Why this sudden idea in software circles that stuff that works properly needs to be removed for no reason whatsoever other than "it's old and we think nobody uses it". How do you know?. IF IT AIN'T BROKEN, DON'T FIX IT. You might have heard of it.
Fail2ban is one piece of software which interfaces with tcp wrappers. v0.9.0 just out http://www.fail2ban.org/wiki/index.php/Main_Page
FC
Fernando Cassia wrote:
On Thu, Mar 20, 2014 at 4:48 PM, Matthew Miller mattdm@mattdm.org wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
Please don't remove it. Why this sudden idea in software circles that stuff that works properly needs to be removed for no reason whatsoever other than "it's old and we think nobody uses it". How do you know?. IF IT AIN'T BROKEN, DON'T FIX IT. You might have heard of it.
Fail2ban is one piece of software which interfaces with tcp wrappers. v0.9.0 just out http://www.fail2ban.org/wiki/index.php/Main_Page
On the other hand, what justifiable reason was there for the massively increased complexity of grub2? And why do all configuration files suddenly *desperately* need to be xml?
mark
On Thu, Mar 20, 2014 at 05:18:42PM -0400, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2?
Probably none, but legacy grub didn't have support for booting on UEFI platforms, and no one wanted to add that support, let alone maintain it.
In recent Fedora, I added rudimentary support for extlinux as a bootloader when you want to avoid the grub2 complexity. (This is a great example, though, of something that may not trickle down from Fedora, unless someone wants to step up to make the feature more robust.)
And why do all configuration files suddenly *desperately* need to be xml?
If only the grub2 config files were xml! Instead, they're shell scripts which generate shell scripts which generate the actual configuration. (Sadly, I'm not making that up. I think those might even source other shells scripts.)
XML configruation happens when GUI developers write config files, mostly. But fortunately it is not a universal disease -- systemd, for example, for all its controvery, uses lovely sysadmin-friendly key=value config files.
Matthew Miller wrote:
On Thu, Mar 20, 2014 at 05:18:42PM -0400, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2?
Probably none, but legacy grub didn't have support for booting on UEFI platforms, and no one wanted to add that support, let alone maintain it.
Yeah, and a lot of us are unfriendly to UEFI....
In recent Fedora, I added rudimentary support for extlinux as a bootloader when you want to avoid the grub2 complexity. (This is a great example, though, of something that may not trickle down from Fedora, unless someone wants to step up to make the feature more robust.)
And why do all configuration files suddenly *desperately* need to be xml?
If only the grub2 config files were xml! Instead, they're shell scripts which generate shell scripts which generate the actual configuration.
*gag* That's the impression I got from my netbook (Ubuntu netbook remix).
I get *real* tired of people who are clever, and bit themselves in the back doing it. I'm a firm believer in elegance... and simplicity is usually elegant.
(Sadly, I'm not making that up. I think those might even source other shells scripts.)
XML configruation happens when GUI developers write config files, mostly. But fortunately it is not a universal disease -- systemd, for example, for all its controvery, uses lovely sysadmin-friendly key=value config files.
I have one thing to say about that: to quote a friend: "ah, your mother dresses you funny, and you need a mouse to delete files" (M. Pins)
mark
On Thu, Mar 20, 2014 at 05:42:43PM -0400, m.roth@5-cent.us wrote:
Matthew Miller wrote:
On Thu, Mar 20, 2014 at 05:18:42PM -0400, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2?
Probably none, but legacy grub didn't have support for booting on UEFI platforms, and no one wanted to add that support, let alone maintain it.
Yeah, and a lot of us are unfriendly to UEFI....
In recent Fedora, I added rudimentary support for extlinux as a bootloader when you want to avoid the grub2 complexity. (This is a great example, though, of something that may not trickle down from Fedora, unless someone wants to step up to make the feature more robust.)
And why do all configuration files suddenly *desperately* need to be xml?
If only the grub2 config files were xml! Instead, they're shell scripts which generate shell scripts which generate the actual configuration.
*gag* That's the impression I got from my netbook (Ubuntu netbook remix).
I get *real* tired of people who are clever, and bit themselves in the back doing it. I'm a firm believer in elegance... and simplicity is usually elegant.
I've read that Brian Kernighan said something like this, once upon a time:
"Debugging code is at least twice as hard as writing it. Therefore, if you write code a cleverly as you possibly can, you are then, by definition, not smart enough to be able to debug it."
Seems like that would apply to a pile of kludges as described above.
On 3/20/2014 2:18 PM, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2? And why do all configuration files suddenly *desperately* need to be xml?
dont worry, in another year or 3, they'll all be JSON instead of XML.
John R Pierce wrote:
On 3/20/2014 2:18 PM, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2? And why do all configuration files suddenly *desperately* need to be xml?
dont worry, in another year or 3, they'll all be JSON instead of XML.
Interesting related thought - just saw this today.
Excerpt: What happened to the vision in open source?
First, grand schemes have been replaced by little ones, thanks to the rise of crowdfunding. In supporting all the campaigns in play at any one time, perhaps the FOSS community has become jaded and short-sighted. Faced with thousands of dreams, seeing the importance of bigger dreams has perhaps become harder. In the crowd of dreams that need support, one no doubt seems much like the other.
To make matters worse, most of the crowdfunding campaigns are highly personal ones. "Help me finish my movie, my book" is the general request. "Help me make a living writing code for cool stuff." What you hear far less often is, "Help me finish this project for the greater good."
Don't get me wrong - I appreciate the rise of crowdfunding, and I am a frequent contributor to causes that catch my imagination. Unquestionably, the concept has encouraged thousands to try to live out their dreams, and the creative return has been rich.
All the same, I can see how, amid so many worthy causes, larger scale ones look less important than they are, and how causes that go beyond the personal might be hard to see as anything special. After the first half dozen causes or so, many people lose the ability to distinguish one from the other, much less rate their importance. --- end excerpt ---
http://www.datamation.com/open-source/what-happened-to-the-vision-in-open-source-1.html
mark
On Thu, Mar 20, 2014 at 4:47 PM, m.roth@5-cent.us wrote:
Excerpt: What happened to the vision in open source?
The idea that there ever was a unified vision for open source seems like a utopian rewrite of history. At least outside of the BSD project... Even the commercial side of unix was wildly fragmented into different flavors and open source fragmented itself with licenses that prohibit best-of-breed components from being combined. And nobody likes to debug someone else's mistakes.
On Thu, 2014-03-20 at 17:18 -0400, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2? And why do all configuration files suddenly *desperately* need to be xml?
Because misguided fools believe XML is wundervol and they don't want simplicity of use.
On Fri, Mar 21, 2014 at 10:36 AM, Always Learning centos@u62.u22.netwrote:
On Thu, 2014-03-20 at 17:18 -0400, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2? And why do all configuration files
suddenly
*desperately* need to be xml?
Because misguided fools believe XML is wundervol and they don't want simplicity of use.
The advantages of XML are that it is a common, mature standard, it is
easily parseable by humans and computers.
Cheers,
Cliff
On Thu, 2014-03-20 at 17:18 -0400, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the massively increased complexity of grub2? And why do all configuration files suddenly *desperately* need to be xml?
On Fri, Mar 21, 2014 at 10:36 AM, Always Learning wrote:
Because misguided fools believe XML is wundervol and they don't want simplicity of use.
On Sat, 2014-03-22 at 13:54 +1300, Cliff Pratt wrote:
The advantages of XML are that it is a common, mature standard, it is easily parseable by humans and computers.
Nothing is easier and simpler than
[any-section] parameter1=value1 parameter2=value2
Compare to XML (= the WEB PAGE 'new idea'), plain text is common, well established and a significantly more mature standard. Plain text is easier to read with vastly improve clarity, compared to XML, and no line indentations or angular brackets required.
I note your reference to XML being "common, mature standard" omits any praise for XML and also omits calling it "good" :-)
On Sat, Mar 22, 2014 at 2:05 PM, Always Learning centos@u62.u22.net wrote:
On Thu, 2014-03-20 at 17:18 -0400, m.roth@5-cent.us wrote:
On the other hand, what justifiable reason was there for the
massively
increased complexity of grub2? And why do all configuration files suddenly *desperately* need to be xml?
On Fri, Mar 21, 2014 at 10:36 AM, Always Learning wrote:
Because misguided fools believe XML is wundervol and they don't want simplicity of use.
On Sat, 2014-03-22 at 13:54 +1300, Cliff Pratt wrote:
The advantages of XML are that it is a common, mature standard, it is easily parseable by humans and computers.
Nothing is easier and simpler than
[any-section] parameter1=value1 parameter2=value2
Compare to XML (= the WEB PAGE 'new idea'), plain text is common, well established and a significantly more mature standard. Plain text is easier to read with vastly improve clarity, compared to XML, and no line indentations or angular brackets required.
I note your reference to XML being "common, mature standard" omits any praise for XML and also omits calling it "good" :-) http://lists.centos.org/mailman/listinfo/centos
That text format is simple. Too simple. If you have multiple similar sub-sections you have to use some ad-hoc construction. For example if you require sub entries with eg a default sub-section and a per-user sub-section then the simple example doesn't work, or at least it is rendered a lot less readable. It doesn't nest.
YAML is quite a good if you insist on a text type format, without the complexity of JSON.
But back to XML. It is parseable using all sorts of libraries and on lots of platforms. We have a number of apps that use XML for configuration data. It is easy for the programmers to knock up a page to edit this and the app itself can easily parse the results.
But I'm sorry, I must admit that there was an element of tongue in cheek in my reference to XML's advantages. I've been reading and writing it for years, so I speak it fluently, at least in the possibly limited set of usages that we have.
Cheers,
Cliff
On Sat, Mar 22, 2014 at 2:05 PM, Always Learning centos@u62.u22.net wrote:
Nothing is easier and simpler than
[any-section] parameter1=value1 parameter2=value2
On Sat, 2014-03-22 at 18:24 +1300, Cliff Pratt wrote:
That text format is simple. Too simple. If you have multiple similar sub-sections you have to use some ad-hoc construction. For example if you require sub entries with eg a default sub-section and a per-user sub-section then the simple example doesn't work, or at least it is rendered a lot less readable. It doesn't nest.
Whoops your M$ heritage is showing.
On Linux "per-user" values are usually stored in individual configuration files located in their users' ~ (/home/) directories - not in a single, fragile and all-embracing nightmare called The Windoze Registry.
Linux is much more logical and user-friendly. Hence the existence of simple configuration files capable of containing copious configuration hints and explanations - something omitted from the XML monstrosity.
:-)
Centos is like a hot sunny day - a true joy to experience.
On Sun, Mar 23, 2014 at 2:02 AM, Always Learning centos@u62.u22.net wrote:
On Sat, Mar 22, 2014 at 2:05 PM, Always Learning centos@u62.u22.net
wrote:
Nothing is easier and simpler than
[any-section] parameter1=value1 parameter2=value2
On Sat, 2014-03-22 at 18:24 +1300, Cliff Pratt wrote:
That text format is simple. Too simple. If you have multiple similar sub-sections you have to use some ad-hoc construction. For example if you require sub entries with eg a default sub-section and a per-user sub-section then the simple example doesn't work, or at least it is rendered a lot less readable. It doesn't nest.
Whoops your M$ heritage is showing.
Hmm, I don't deny that I moved to Linux from the Dark Side...
On Linux "per-user" values are usually stored in individual configuration files located in their users' ~ (/home/) directories - not in a single, fragile and all-embracing nightmare called The Windoze Registry.
The Windoze Registry eh? Well, I don't have CentOS/RHEL to try this on
here, but when I type "gconf-editor" at the command line, I get something much like Windows Registry Editor.
WRT user configurations, I only used users as an example. Your configuration file format is not useful in an application that requires a nested configuration.
Linux is much more logical and user-friendly. Hence the existence of
simple configuration files capable of containing copious configuration hints and explanations - something omitted from the XML monstrosity.
:-)
Yeah right. Each and every configuration has its own format of
configuration file (eg sudoers) which you have to learn.
XML is a monstrocity, I agree. But it's useful across the board monstrosity.
Centos is like a hot sunny day - a true joy to experience.
And we are stll waaaaaay off topic!
Cheers,
Cliff
On Thu, Mar 20, 2014 at 4:18 PM, m.roth@5-cent.us wrote:
And why do all configuration files suddenly *desperately* need to be xml?
xml isn't intended for humans - it is supposed to be parsed and verified by machines. The bigger question is why the machines aren't managing the config files themselves yet?
On Thu, Mar 20, 2014 at 06:14:56PM -0300, Fernando Cassia wrote:
Please don't remove it. Why this sudden idea in software circles that stuff that works properly needs to be removed for no reason whatsoever other than "it's old and we think nobody uses it". How do you know?.
Well, that's why I'm asking.
IF IT AIN'T BROKEN, DON'T FIX IT. You might have heard of it.
Yes, I have heard of that.
But, are you actually using it? Do you need to?
There are real downsides to carrying unmaintained code forward.
Someone put forth the possibility of developing and maintaining a maintaining a modern library implementing the same config files but with a an updated codebase and better API, but no one has actually volunteered to do that work. If you'd like to be that person, awesome.
Fail2ban is one piece of software which interfaces with tcp wrappers. v0.9.0 just out http://www.fail2ban.org/wiki/index.php/Main_Page
Yes, and know for sure people use that -- I do, for example. But I use it to manipulate IP tables, which is more secure and less fragile than the hosts.deny action (it's always a bit scary when configuration files are edited by a program!). Because it is actively maintained upstream, there's even support for new things like firewalld.
On the other hand, people using unmaintained solutions like DenyHosts would have to migrate.
Matthew Miller wrote:
On Thu, Mar 20, 2014 at 06:14:56PM -0300, Fernando Cassia wrote:
<snip>
Fail2ban is one piece of software which interfaces with tcp wrappers. v0.9.0 just out http://www.fail2ban.org/wiki/index.php/Main_Page
Yes, and know for sure people use that -- I do, for example. But I use it to manipulate IP tables, which is more secure and less fragile than the hosts.deny action (it's always a bit scary when configuration files are edited by a program!). Because it is actively maintained upstream, there's even support for new things like firewalld.
<snip>
Yup - that's what we do here, use fail2ban to manipulate iptables.
mark
On Thu, Mar 20, 2014 at 4:39 PM, m.roth@5-cent.us wrote:
Matthew Miller wrote:
On Thu, Mar 20, 2014 at 06:14:56PM -0300, Fernando Cassia wrote:
<snip> >> Fail2ban is one piece of software which interfaces with tcp wrappers. >> v0.9.0 just out >> http://www.fail2ban.org/wiki/index.php/Main_Page > > Yes, and know for sure people use that -- I do, for example. But I use it > to manipulate IP tables, which is more secure and less fragile than the > hosts.deny action (it's always a bit scary when configuration files are > edited by a program!). Because it is actively maintained upstream, there's > even support for new things like firewalld. <snip>
Yup - that's what we do here, use fail2ban to manipulate iptables.
Not sure there's a one-to-one mapping or even a conceptual overlap in what tcpwrappers and iptables do. Applications can be configured to use different ports than someone setting up iptables might expect - and how would you handle portmapper?
On Thu, Mar 20, 2014 at 05:23:24PM -0500, Les Mikesell wrote:
Yup - that's what we do here, use fail2ban to manipulate iptables.
Not sure there's a one-to-one mapping or even a conceptual overlap in what tcpwrappers and iptables do. Applications can be configured to use different ports than someone setting up iptables might expect - and how would you handle portmapper?
Reasonable question. :) Ideally, you'd handle portmapper by using NFSv4 so it's not required. Or recommend using rpcbind and fixed port numbers. (See for example https://www.centos.org/docs/5/html/5.2/Deployment_Guide/s2-sysconfig-nfs.html)
But I think the proposal would leave the library there for legacy programs which really want to use it, just not link core components to it anymore.
On 03/20/2014 06:23 PM, Les Mikesell wrote:
Not sure there's a one-to-one mapping or even a conceptual overlap in what tcpwrappers and iptables do. Applications can be configured to use different ports than someone setting up iptables might expect - and how would you handle portmapper?
As another case, read some of the extended use cases for vsftpd. They require tcpd to pass an environmental variable telling vsftpd which configuration file to use.
Am 20.03.2014 um 22:22 schrieb Matthew Miller mattdm@mattdm.org:
On Thu, Mar 20, 2014 at 06:14:56PM -0300, Fernando Cassia wrote:
Please don't remove it. Why this sudden idea in software circles that stuff that works properly needs to be removed for no reason whatsoever other than "it's old and we think nobody uses it". How do you know?.
Well, that's why I'm asking.
IF IT AIN'T BROKEN, DON'T FIX IT. You might have heard of it.
Yes, I have heard of that.
But, are you actually using it? Do you need to?
we do and we also compile tcp wrappers support into service if the distro have't done it (e.g. mysql). its just used in a multiple layer protection / security model.
There are real downsides to carrying unmaintained code forward.
Someone put forth the possibility of developing and maintaining a maintaining a modern library implementing the same config files but with a an updated codebase and better API, but no one has actually volunteered to do that work. If you'd like to be that person, awesome.
Fail2ban is one piece of software which interfaces with tcp wrappers. v0.9.0 just out http://www.fail2ban.org/wiki/index.php/Main_Page
Yes, and know for sure people use that -- I do, for example. But I use it to manipulate IP tables, which is more secure and less fragile than the
why is iptables more secure? its just on an other level and the attack vector persists. and by the way; you do not really want to run a "firewall" on the _same_ system, think about that.
hosts.deny action (it's always a bit scary when configuration files are edited by a program!). Because it is actively maintained upstream, there's even support for new things like firewalld.
well i would say its more scary when humans are editing configuration files :-)
one think that i like on tcp_wrappers is the use of domain names. Even possible with iptables but not a good idea as with tcp_wrappers.
-- LF
On Fri, 21 Mar 2014, Leon Fauster wrote:
its just used in a multiple layer protection / security model.
Bingo! Same here. And it works well!
well i would say its more scary when humans are editing configuration files :-)
I can speak for nearly 20 years of experience on this, including blowing it myself and locking myself remotely out of my own system once. For what it is supposed to do...it does extremely well.
Gilbert
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Thu, 2014-03-20 at 18:14 -0300, Fernando Cassia wrote:
On Thu, Mar 20, 2014 at 4:48 PM, Matthew Miller mattdm@mattdm.org wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore?
Please don't remove it. Why this sudden idea in software circles that stuff that works properly needs to be removed for no reason whatsoever other than "it's old and we think nobody uses it". How do you know?. IF IT AIN'T BROKEN, DON'T FIX IT. You might have heard of it.
Fail2ban is one piece of software which interfaces with tcp wrappers. v0.9.0 just out http://www.fail2ban.org/wiki/index.php/Main_Page
Everyone appreciates the importance of keeping machines, and their contents, safe and secure.
Does "tcp wrappers (hosts.allow/hosts.deny)" provide a currently useful facility - which is actually used in production systems - or has it been superseded by better security facilities?
Nothing remains static. Software evolves into usually superior products. Sentimentally longing for the past hampers the introduction of new and better replacements. Losing tcp wrappers when Centos 8 is introduced gives everyone ample time to implement changes.
On Thu, Mar 20, 2014, Fernando Cassia wrote:
On Thu, Mar 20, 2014 at 4:48 PM, Matthew Miller mattdm@mattdm.org wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
Please don't remove it. Why this sudden idea in software circles that stuff that works properly needs to be removed for no reason whatsoever other than "it's old and we think nobody uses it". How do you know?. IF IT AIN'T BROKEN, DON'T FIX IT. You might have heard of it.
This has been a problem with various open source projects for decades, not so much removing something, but more often changing options and behaviours that break existing uses.
It wouldn't matter to me if it were dropped from CentOS or the upstream as we build our own, hacked to allow use of RBLs.
Bill
Date: Thu, 20 Mar 2014 18:14:56 -0300
On Thu, Mar 20, 2014 at 4:48 PM, Matthew Miller mattdm@mattdm.org wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
Please don't remove it. Why this sudden idea in software circles that stuff that works properly needs to be removed for no reason whatsoever other than "it's old and we think nobody uses it". How do you know?. IF IT AIN'T BROKEN, DON'T FIX IT. You might have heard of it.
Fail2ban is one piece of software which interfaces with tcp wrappers. v0.9.0 just out http://www.fail2ban.org/wiki/index.php/Main_Page
FC -------------------------------------------------------------------
I will have to add my 2 cent request with FC. Please do not remove it!!!!
Greg Ennis
On Mar 20, 2014, at 3:48 PM, Matthew Miller mattdm@mattdm.org wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
I bring this up because we are discussing dropping it from Fedora. This would be far enough in the future that it wouldn't impact RHEL 7, and therefore won't affect anyone here for Quite Some Time*, but here in the new world order of CentOS, I thought it might be useful to check with some actual downstream users.
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
Your feedback appreciated. Thanks!
- and the standard caveats that Fedora doesn't necessarily determine the
path for RHEL apply, of course.
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/
I know a .gov which exclusively uses tcp wrappers instead of iptables. 1) tcp wrappers is consistent across Unix'ses (Solaris/AIX/Linux) 2) if it ain't broke / resistance to change / etc 3) political / layer 8 issues. Iptables is a firewall and firewalls are handled by the security group not the sysadmin group.
I know a .edu which uses tcp wrappers instead of iptables in a containers environment. With 250+ containers on a 40GB hardware node, iptables used too much RAM since it's resident 100% of the time. Tried using a "fail2ban" equivalent inserting iptables rules and after some number of rules iptables wouldn't take any more. Tcp wrappers scaled much much higher using less RAM.
Political reasons shouldn't prevent removing tcp wrappers, but some technical reasons still exist.
Steven Tardy
On Thu, Mar 20, 2014 at 8:36 PM, Steven Tardy sjt5atra@gmail.com wrote:
Political reasons shouldn't prevent removing tcp wrappers, but some technical reasons still exist.
Interesting double negative. Implies that once the "technical barriers" are removed, then it's OK to remove old features for change's sake. ;)
Aren't political reasons the reason they are thinking of removing ' em?. Certainly I see no technical problem with tcp wrappers.
The Unix tradition was to build upon existing tools. As of late, the Linux approach seems to be "hey this is old, I could add a few medals to my professional resume and escalate a few positions up the corporate ladder if I reinvent the wheel and redo this old working code in a totally different way that breaks backwards compatibility and some third party code, so let's do it, let's 'move things forward'. Those that oppose it are slowing the progress of the distro".
Well DUH :-/ Pardon me if I don't cheer such moves.
FC
On 2014-03-21, Fernando Cassia fcassia@gmail.com wrote:
Interesting double negative. Implies that once the "technical barriers" are removed, then it's OK to remove old features for change's sake. ;)
If, as Matthew says, the codebase hasn't been maintained since 2001, then we should have concerns about unfound security issues, as well as concerns that, if others find security problems, nobody is responsible for fixing them. If tcpwrappers had a current maintainer this wouldn't be an issue.
There's certainly at least one technical reason to prefer other options like iptables over tcpwrappers. I've had instances where an attacker made dozens of ssh probes per second; tcpwrappers was able to reject these, but sshd was so overwhelmed that it was unable to exchange host keys with legitimate clients. iptables would have blocked these attacks more effectively, letting sshd handle the legitimate client sessions properly.
Certainly others have posted legitimate reasons to prefer tcpwrappers over iptables in this thread, too. Your sole position seems to be "it's old so it should be kept", which is just as illegitimate a position as "it's old so it should be discarded". If you have valid technical arguments justifying keeping tcpwrappers you should make them, as others have.
Aren't political reasons the reason they are thinking of removing ' em?.
Matthew cited an old and unwieldy API, its status as being unmaintained, and its existence as an extra place to check for sysadmins (I'm dubious about this last). None of these strike me as being political.
Certainly I see no technical problem with tcp wrappers.
The technical problem is that there's no maintainer. Are you volunteering (and capable)?
On Thu, Mar 20, 2014 at 11:13 PM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
The technical problem is that there's no maintainer. Are you volunteering (and capable)?
Then, for crying out loud... :) this discussion should have been started with a different subject line: "Looking for a new tcp wrappers maintainer".
That is much more constructive than calling the bulldozer early.
FC
On Fri, Mar 21, 2014 at 8:58 AM, Fernando Cassia fcassia@gmail.com wrote:
The technical problem is that there's no maintainer. Are you volunteering (and capable)?
Then, for crying out loud... :) this discussion should have been started with a different subject line: "Looking for a new tcp wrappers maintainer".
That is much more constructive than calling the bulldozer early.
Even more to the point, why is this a fedora/RHEL or even linux specific issue? I'd expect to matter to OpenBSD. Do they maintain their copy?
On Thu, Mar 20, 2014, Keith Keller wrote:
On 2014-03-21, Fernando Cassia fcassia@gmail.com wrote:
Interesting double negative. Implies that once the "technical barriers" are removed, then it's OK to remove old features for change's sake. ;)
If, as Matthew says, the codebase hasn't been maintained since 2001, then we should have concerns about unfound security issues, as well as concerns that, if others find security problems, nobody is responsible for fixing them. If tcpwrappers had a current maintainer this wouldn't be an issue.
There's certainly at least one technical reason to prefer other options like iptables over tcpwrappers. I've had instances where an attacker made dozens of ssh probes per second; tcpwrappers was able to reject these, but sshd was so overwhelmed that it was unable to exchange host keys with legitimate clients. iptables would have blocked these attacks more effectively, letting sshd handle the legitimate client sessions properly.
My solution to this is to have swatch watching the tcp_wrappers ssh, imap, and pop3 logs and blocking with iptables any IP address that has more than N (5 by default) failed connection attempts in a minute or that is listed in our blacklist DNSRBL. A postgresql database is used on each machine with a history of IPs blocked which is used to automatically expire blocks and to add them if a system is rebooted.
We maintain a couple of DNSRBLs for whitelisting and blacklisting IP addresses and net blocks that are largely fed by the reports generated. The /etc/hosts.allow files on all the systems we monitor use these DNSRBLs on critical services (e.g. sshd) to ALLOW/DENY access.
The net result of this has been that it's rare when a particular IP gets more than a few failed attempts before being blocked the first time, and one or two if it's in our blacklist DNSRBL whether it's on the first machine attacked or any of the other machines we monitor.
FWIW, the the majority of the attacks seem to be password guessing attempts using IMAP, not ssh. The successful cracks on Linux machines I've seen were done via weak user accounts on ISPs that were then accessed via php to the user's writeable public html directory.
As somebody already pointed out, no one tool is sufficient to limit access.
Bill
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
Your feedback appreciated. Thanks!
- and the standard caveats that Fedora doesn't necessarily determine the
path for RHEL apply, of course.
I'll try to keep my response as free from whining and gnashing of teeth as that seems to be well covered by many others. where I work uses it now, I've been at places that while I can't recall there being a specific mandate for tcp wrappers, they had really stupid 'must have' requirements (like root's home has to be mode 700. which while fine, good, great even on standard linux systems is less than helpful on standard older releases of solaris where root has / as a home dir), so I can imagine they could have that. I like the notion of keeping it around and having someone take over the maint work would be great, but I can understand why it might be good to retire, and I'm pretty sure I'd adapt (possibly moving to the route of building my own from source if I -really- decided I had to have it, although life is much easier when the libs are blown into the daemons directly)
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Matthew Miller Sent: den 20 mars 2014 20:49 To: centos@centos.org Subject: [CentOS] Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore?
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
I do use them both, together with some iptables-rules.
As for caring of they disappear, well, maybe not to much, as most everything can be set in iptables as well. It will take an effort to redo our standard iptables rule list though, in order to cover up for the missing hosts.deny and hosts.allow files. -- //Sorin
On Thu, Mar 20, 2014 at 3:48 PM, Matthew Miller mattdm@mattdm.org wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
I bring this up because we are discussing dropping it from Fedora. This would be far enough in the future that it wouldn't impact RHEL 7, and therefore won't affect anyone here for Quite Some Time*, but here in the new world order of CentOS, I thought it might be useful to check with some actual downstream users.
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
Your feedback appreciated. Thanks!
- and the standard caveats that Fedora doesn't necessarily determine the
path for RHEL apply, of course.
-- Matthew Miller mattdm@mattdm.org http://mattdm.org/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
We still use tcpwrappers extensively behind our firewalls to control many things. We still have a mixed CentOS 5/6 and older Solaris environment, so it would be big hassle to switch to something else.
Of course, if it left Fedora today, it would still be in CentOS for years to come, and even then we could probably build our own pretty easily, but we'd rather not have to!
On 03/20/2014 12:48 PM, Matthew Miller wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, would you care strongly if it went away (or would you just migrate to something else)?
I bring this up because we are discussing dropping it from Fedora. This would be far enough in the future that it wouldn't impact RHEL 7, and therefore won't affect anyone here for Quite Some Time*, but here in the new world order of CentOS, I thought it might be useful to check with some actual downstream users.
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
Your feedback appreciated. Thanks!
- and the standard caveats that Fedora doesn't necessarily determine the
path for RHEL apply, of course.
I use it in conjunction with other utilities... They modify the hosts.deny in response to log parsing.
Please keep in mind, security in layers.
----- Original Message ----- | Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore? And, | would | you care strongly if it went away (or would you just migrate to | something | else)? |
Yes, we do use TCP Wrappers. We also use IPTables, edge gateway firewalls, VPNs and other tools. The reason that we use them is to support additional security.
The case is being made to remove a tool that is considered to be legacy. While it is understood that legacy = old/unmaintained/crap, it does remove an additional layer of security that can be applied for a base system. So the question then is, what can be used as a suitable replacement? If so what is that suitable replacement? If one doesn't exist, how long until we can get one?
Security is about layering technology. IPTables doesn't solve all of the problems out there. People mentioned NFSv3 and moving to NFSv4 and while this may be suitable for some people it doesn't apply to others. To simply remove a tool because it's code hasn't been modified in X number of days,months,years,decades is really in many cases what I like to call "version envy".
I'd love to hear about the "old and unmaintainable code". It's open source code. If somethings broken you can fix it right!?! That's the open source mantra! Either provide a set of reasons why it should be removed and the alternatives that cover all the use cases of TCP Wrappers or let the code, that obviously works remain there undisturbed. It's an extra layer of security that administrators can use to secure their systems and it's dead simple to understand!
On Fri, Mar 21, 2014 at 3:54 PM, James A. Peltier jpeltier@sfu.ca wrote:
I'd love to hear about the "old and unmaintainable code". It's open source code. If somethings broken you can fix it right!?! That's the open source mantra! Either provide a set of reasons why it should be removed and the alternatives that cover all the use cases of TCP Wrappers or let the code, that obviously works remain there undisturbed. It's an extra layer of security that administrators can use to secure their systems and it's dead simple to understand!
+1 If it works, it works. Period. It doesn't matter if it was coded by an ancient civilization carved in stone, or that it hasn't been updated in centuries.
Perhaps it hasn't been updated in centuries precisely because it work,s so there's no need to update it!
FC
On Fri, 21 Mar 2014, Fernando Cassia wrote:
On Fri, Mar 21, 2014 at 3:54 PM, James A. Peltier jpeltier@sfu.ca wrote:
I'd love to hear about the "old and unmaintainable code". It's open source code. If somethings broken you can fix it right!?! That's the open source mantra! Either provide a set of reasons why it should be removed and the alternatives that cover all the use cases of TCP Wrappers or let the code, that obviously works remain there undisturbed. It's an extra layer of security that administrators can use to secure their systems and it's dead simple to understand!
+1
+1
If it works, it works. Period. It doesn't matter if it was coded by an ancient civilization carved in stone, or that it hasn't been updated in centuries.
Perhaps it hasn't been updated in centuries precisely because it work,s so there's no need to update it!
FC
MP
On Fri, Mar 21, 2014 at 1:54 PM, James A. Peltier jpeltier@sfu.ca wrote:
The case is being made to remove a tool that is considered to be legacy. While it is understood that legacy = old/unmaintained/crap,
No, legacy = the foundation everything else builds on. Change it at the risk of forcing everyone who uses your product to rebuild everything from scratch. In my opinion, a new version of something isn't better unless it is also completely backwards compatible. It's not a fashion show - things aren't better just because they are different.
As others have mentioned in this thread, yes I use it as part of a defence in depth strategy, and it's a suitable tool for what it is intended to do. I would not be happy with it going away, especially if doing so broke various tools or introduced a dependancy on a non-base RPM.
Devin
On Thu, 2014-03-20 at 15:48 -0400, Matthew Miller wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore?
A very late reply - yes we use it in conjunction with iptables (on CentOS 5/6 and Fedora). Tcp_wrappers allows filtering based on DNS name, which (as far as I am aware) iptables does not. It is very easy to configure, and takes immediate effect (no restarting of processes required).
And, would you care strongly if it went away (or would you just migrate to something else)?
Since we use it I would obviously rather it did not go away :-) If we had to we would probably build our own from source, but initially may well just look to see if iptables could do all of what we wanted.
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
No policies as such, but we include its installation as part of our standard server build process. It is part of the security used on our servers, and, as others have mentioned, multiple layers is the way to go rather than relying on just one tool.
John.
On 04/20/2014 06:48 PM, John Horne wrote:
On Thu, 2014-03-20 at 15:48 -0400, Matthew Miller wrote:
Does anyone use tcp wrappers (hosts.allow/hosts.deny) anymore?
A very late reply - yes we use it in conjunction with iptables (on CentOS 5/6 and Fedora). Tcp_wrappers allows filtering based on DNS name, which (as far as I am aware) iptables does not. It is very easy to configure, and takes immediate effect (no restarting of processes required).
And, would you care strongly if it went away (or would you just migrate to something else)?
Since we use it I would obviously rather it did not go away :-) If we had to we would probably build our own from source, but initially may well just look to see if iptables could do all of what we wanted.
The problem here wouldn't be so much building it from source. You'd have to rebuild everything that would make use of it as well. For example sshd is linked against it. ->
[jperrin@monster localbuild]$ ldd /usr/sbin/sshd | grep wrap libwrap.so.0 => /lib64/libwrap.so.0
What do you think? Do you rely on hosts.allow/hosts.deny a primary security mechanism? As defense-in-depth? Do you have policies which mandate it?
No policies as such, but we include its installation as part of our standard server build process. It is part of the security used on our servers, and, as others have mentioned, multiple layers is the way to go rather than relying on just one tool.
John.
On Sun, 2014-04-20 at 19:27 -0500, Jim Perrin wrote:
The problem here wouldn't be so much building it from source. You'd have to rebuild everything that would make use of it as well. For example sshd is linked against it. ->
Why ?
If the guy wants to use TCP Wrappers with one other specific application / bit of system software (= IP Tables) and wishes to build it from source, why should he have to worry about SSHD compatibility if he does not want to use TCP Wrappers with SSHD ?
Best regards,
On 2014-04-21, Always Learning centos@u62.u22.net wrote:
On Sun, 2014-04-20 at 19:27 -0500, Jim Perrin wrote:
The problem here wouldn't be so much building it from source. You'd have to rebuild everything that would make use of it as well. For example sshd is linked against it. ->
Why ?
If the guy wants to use TCP Wrappers with one other specific application / bit of system software (= IP Tables) and wishes to build it from source, why should he have to worry about SSHD compatibility if he does not want to use TCP Wrappers with SSHD ?
That's not how I read Jim's response. I read it as, if you wished to use tcpwrappers with sshd, you'd have to rebuild sshd. If you only have one app you need to rebuild that's not so bad, but if you have a half dozen it could be annoying.
--keith
And, would you care strongly if it went away (or would you just migrate to something else)?
I would care strongly as I use it at home to limit inbound ssh to just the IP addresses of my work machine. Setting up IPtables is more complicated which can be read as "easier to get it wrong".
The question become, "Why get rid of it?" It is small works well and works the same across many flavors of UNIX. I have not looked recently, but I would guess that the source code does not change very often.
Just my 2cents.
Bob - Phoenix, AZ
-
Always Learning -
Bill Campbell -
Brian Mathis -
Bruce Ferrell -
Cliff Pratt -
Devin Reade -
Fernando Cassia -
Fred Smith -
Gilbert Sebenste -
Gregory P. Ennis -
James A. Peltier -
Jim Perrin -
John Horne -
John Jasen -
John R Pierce -
Keith Keller -
Leon Fauster -
Les Mikesell -
m.roth＠5-cent.us -
Matthew Miller -
Max Pyziur -
Phelps, Matt -
Sorin Srbu -
Steven Tardy -
Styma, Robert E (Robert) -
zGreenfelder