On Sat, Jul 16, 2011 at 3:23 PM, Loui Chang 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
Hello list,
I've been using tcp_wrappers on Linux for more than 10 years, and on
Archlinux for 6 years.
FWIW I'm not happy about this change. Even though I know that the same
functionality is provided by iptables, I consider tcp_wrappers the Unix
Way.
Anyway there is no value in fighting a
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/
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 = wh
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 Sat 16 Jul 2011 15:47 -0500, Peggy Wilkins wrote:
> 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 t
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 i
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
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 o
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.
signature.asc
Description: OpenPGP digital signat
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.
signature.asc
Description: This is a digitally signed message part
Am 16.07.2011 21:51, schrieb Peggy Wilkins:
> 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
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 : A
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
On 07/16/2011 08: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 m
On Sat, Jul 16, 2011 at 8:42 PM, Thomas S Hatch wrote:
> Mind if I try to clear a few things up here?
Thanks for the very understandable explanation!
Cheers,
Tom
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 i
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 i
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
Am 16.07.2011 19:41, schrieb Andrea Scarpino:
> 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,
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.
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 ACC
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
On 07/16/2011 07:09 PM, 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.
But it's not the same as iptables. If you're running a server, you would
like to use iptables.
Anyway if you really want to
On Saturday 16 July 2011 12:06:34 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
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.
--
v...@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
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 "
>
>
> I would say the same, but a todo list isn't a to-done list, so keep
> that in mind. He also pointed out that I got little to no feedback
> when I asked about this both a year and six months ago, so
> expectations are pretty low this time around. I'm sure if there were
> serious objections peo
28 matches
Mail list logo
