Re: tcp wrapper
On 27 Oct 2004, Mike Mestnik wrote:
> --- Daniel Pittman <firstname.lastname@example.org> wrote:
>> On 27 Oct 2004, Mike Mestnik wrote:
>>> --- Daniel Pittman <email@example.com> wrote:
>>>> On 25 Oct 2004, michal wrote:
>>>>> What's the difference between firewall and TCP wrapper?
>>>> You can't use iptables to do the DNS reverse lookup stuff that
>>>> TCPwrappers can do at connection time, but then, you don't do that if
>>>> you want security anyway. :)
>>> A special note for the pre ssh days. When telineting into a box it may
>>> appere to be unresponice for upto a minuet!
>> Only if the site you were talking to had broken reverse DNS. Many years
>> ago, when telnet was the common way of making these connections, broken
>> reverse DNS was the exception rather than the rule, really.
>>> This is due to a *REVERSE* dns lookup done by the *SERVER*. It's not
>>> posible to bypass this by using the IP for your telnet client(it's not
>>> the same thing).
>>> This lookup is a great *tool* for client authentication
>> No, it isn't. It is a completely useless tool for client
>> authentication, as it relies on an insecure tools completely controlled
>> by the client connection site.
> Your correct, but by tool I mean like a rock where a hammer is needed.
If you meant to say that this is a security tool with significant
limitations, the phrase "great *tool*" is /not/ the one to use.
Really. People will read that and think "hey, this guy - he thinks that
reverse DNS lookups are a great security tool."
The will not thing "hey, this guy - he thinks that reverse DNS lookups
are an inefficient and not very useful way of defending a network."
>>> (provided the connection is not spoofed),
>> ...or that the attacker has not pushed false information into your local
>> DNS server.
> DNS spoof.
Correct. An operation that can be carried out, according to a number of
studies, without great difficulty against the vast majority of deployed
>> ...or that the attacker has not simply put false information in their
>> reverse DNS entries.
> This is less likely to happen, now that some DNS and Domain admins are
> getting vary picky about these things. Microsoft even has a solution
> using deligation of sorts, but that's about all I know about it.
In a large number of situations, attackers have sufficient control over
the IP space to publish whatever information they feel like publishing
in the DNS namespace.
The number of servers that offer improperly configured dynamic updates
does not help, either.
Sure, in some cases it would involve taking some degree of control over
the ISP reverse name server block, but that is /hardly/ out of scope for
Also, many larger groups control enough address space to have their own
reverse block; any penetration there allows the attacker full control
of the reverse DNS responses.
>> Heck, even in the presence of DNSSEC signed data the reverse entries are
>> still under the complete control of the attacker. Security? I don't
>> think so.
> Your assuming that every one has access to change there revers DNS. Lets
> say you wanted to block all attbb users.
...then you use whois or the local rNIC to obtain details of their IP
allocations, then blackhole those at the firewall.
Recommending that anyone use reverse DNS resolution as a security
measure is ... risky. It may work in some situations, for some people,
but relying on it fails too easily.
What if, in your hypothetical situation, one of the "attbb" users
violates another host on the same network segment - a host owned by a
business who pay enough to have reverse DNS say what they want?
All of a sudden you are exposed to this hypothetical class of unfriendly
Worse, what if that business shuts down and their IP allocation returns
to a dynamic address allocation pool, but the reverse DNS is not
updated? /That/ happens often enough. :)
If I had to deal with you professionally, I would have told you to
hold the onions and give me large fries.
-- Erik Naggum