Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Mon, 29 Jan 2001, Tim Haynes wrote:
> On Mon, Jan 29, 2001 at 12:33:03PM +0000, thomas lakofski wrote:
>
> > bah. all this talk about portsentry being dangerous forgets that you can
> > also run it so it only triggers after a full TCP connect. while not
> > un-spoofable, it's very hard for an attacker to spoof as they have to be
> > in-line between your host and the host they're trying to spoof. plus,
> > they'll have a task guessing sequence numbers.
>
> Hard? Heard of determination, as well as skr1pt k1dd1es?
Please tell me what you mean here. A cracker determined enough to break in
between a host and mine in order to deny me access to it might as well take
more effective direct action given the effort involved.
Script kiddies generally don't know what's happened to them when portsentry
triggers, and go looking for easier fodder -- if they even notice; most scans
of that sort are automated, and the majority of noise these days is the
activity of worms; cf. your logs.
> > portsentry has been protecting my host without a firewall in front of it for
> > three years now; it has always worked exactly as it said it would.
>
> Who says someone's going to go through a full SYN connect, anyway? Sounds like
> you need a stateful firewall to be somewhat safer.
If they're not doing a full connect, portsentry won't trip. I'll see the SYN
in the logs. If they're actually out to exploit the hole and not scan you,
they have to do a full connect, so I only worry about these.
> I, for one, am decidedly not fond of anything that works by dangling bells on
> a wire and hoping someone will trip them, not protecting valid listeners
> against either bad content or non-SYN packets, not taking into account that
> ports on which there are already listeners are possibly the results of a
> default install that hasn't been reconfigured, and then goes ahead and messes
> with my firewall rules as well.
When using software like this it's assumed that you have a good idea of what is
happening on the box. If you're dealing with an out-of-the-box install you
have much more to worry about possibly than your portsentry configuration.
Portsentry is just a single part of a complete security policy with many more
elements to it than a portscan detector.
Portsentry doesn't mess with firewall rules.
> And what about UDP packets? It won't take as much effort to spoof one of
> those, and you're susceptible to more IP#s than just your own being spoofed:
> what if someone impersonates your upstream nameserver, webcache or router and
> your portsentry or equivalent trips & blocks it? That's not just damned
> annoying, it'd cost me valid business.
I don't configure portsentry to listen for UDP connections, for the same reason
I don't have it trigger as a result of anything other than a full TCP connect.
What's more likely to cost you valid business is not understanding the
technology fully.
> I suppose it's horses for courses, anyway. If you like portsentry, go ahead,
> see what happens, it might well suit you for a mostly-open scenario. (We do
> this question on comp.os.linux.security every so often, btw.)
I have a default-deny firewall with portsentry. There are only around 5 valid
services on the box, and about 30 fake ports wired up to portsentry. People
who have valid business on the box never run into trouble, people poking around
to see what there is usually step on a fake service.
> > all this stuff is in the documentation anyway. does anyone read
> > documentation anymore? it's more productive than guessing in public.
>
> Docs, what're they? ;8^)
...suggest you read them before commenting further.
-thomas
> ~Tim
>
--
who's watching your watchmen?
gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=>p.nu/d
2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43
Reply to: