[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] PortSentry ain't impotent
- Subject: Re: [cobalt-users] PortSentry ain't impotent
- From: Elmer Fuddpucker <elmer@xxxxxxxxxxxxxx>
- Date: Thu May 24 22:52:51 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
On Thu, 24 May 2001, Carrie Bartkowiak wrote:
} I don't wanna hear anyone else tell me about how
Okay, I won't say it....
} Don't know why, but putting myself into hosts.allow
} didn't help anything.
tcp wrappers and portsentry are two different things. The
hosts.allow file works with tcp wrappers. On a certain level, tcp
wrappers and portsentry do much the same thing but they are
seperate. In other words, if you have rules in your hosts.allow
and/or hosts.deny files and tcp wrappers itself is triggered then
those rules will govern the operation of tcp wrappers.
portsentry, however, works independently of tcp wrappers. If
configured to add rule sets to hosts.deny then portsentry will do
just that, when triggered, independently of the existing rule sets
in your hosts.allow and/or hosts.deny files.
Quite simply, one has to think of them as the seperate tools
they are in order to configure them properly.
Adding your IP address to the hosts.allow files on your
servers will insure that that IP address is not blocked by tcp
wrappers. But that won't prevent portsentry from triggering and
adding the very same IP address to the hosts.deny file. Fortunately
tcp wrappers reads the hosts.allow file first (man 5 hosts_access)
and that would save you if not for the fact that portsentry has it's
own "access" files.
Confusing.... not really, just stop thinking of tcp wrappers
having anything to do with portsentry - it really doesn't. All it is
doing, in this case, is adding hosts to the hosts.deny file. As far
as tcp wrappers is concerned, portsentry is not an issue. And from
portsentry's point of view tcp wrappers does not enter into the
equation either.
The thing is that if indeed you have your IP address in the
hosts.allow file on the server(s) then you'd always be able to
access the server(s) even if the very same IP address was added to
the hosts.deny file. That is, of course, only if you are not running
portsentry. Since portsentry does not read either the hosts.allow or
hosts.deny if triggered it simply does it's job and deny's you
access.
But portsentry also contains something along the lines of a
hosts.allow file. Where it is depends upon where you installed it,
but if you add your IP address to your portsentry.ignore file then
portsentry will no longer trigger when you do questionable stuff
from your fixed IP address.
I promised I wouldn't say it so I won't, but you might want
to do a bit of reading on tcp wrappers. Make no mistake about it,
tcp wrappers is an entirely different animal than portsentry is. But
you can do many of the same things with it and a whole lot more -
there's actually a feature rich scripting language with which you
can do all kinds of nifty things with tcp wrappers.
brent
Elmer Fuddpucker's WWW Directory
http://www.fuddpucker.com/