RE: [cobalt-users] PortSentry works !

[Rodolfo Paiz <rpaiz@xxxxxxxxxxxxxx>]

> But how effectively *does* portsentry lock them out?
> I see them still banging away and portsentry says it's
> ignoring them. That worries me because as a newbie I'm
> not sure what *exactly* is going on here.

Kinda depends on what you asked it to do. ;) Don't take this too much to
heart, since I haven't even managed to find the time to install the darn
thing as of yet, but here is what I understand:

* PortSentry will "block" (KILL_ROUTE) based on what you tell it to do.
So if you ask for hosts.deny, it blocks via tcp_wrappers. If you ask for
ipchains, it blocks via ipchains.

* PortSentry blocks at the first touch. Touch the server on port 892
where no services are offered, and *boom!* you're blocked.

Now...

* PortSentry does not listen on or block ports you use. It is meant to
protect you from people scanning systems for vulnerabilities, and thus
listens for "the noise of someone trying to break in." However, if
someone is trying for an FTP exploit and you run an FTP server,
PortSentry does nothing... it doesn't touch ports you listen to. This is
why it doesn't protect you from hacks... it protects you from people
scanning systems. Just one of the many layers of protection you must
have.

* If you asked PortSentry to block via ipchains, you should never ever
see a packet from that IP again (unless you reboot and your rules are
cleaned out). If, however, you blocked via hosts.deny, then only those
services that run using tcp_wrappers (those run from inetd or xinetd)
are protected; the rest are not. So you might still see them "banging
away."

> The FTP exploit was to overrun the buffer so that in effect,
> FTP "ignored" what else was coming through. And then the hacker
> had carte blanche to do whatever he wanted to do.

Not even addressed by PortSentry, who leaves ports you're using alone.
PortSentry's author made it perfectly clear on the mailing list just
this week that the point of PortSentry is to be useful and to provide a
heads-up in some cases, but that it's objective is to provide as few
false alarms as possible rather than the most comprehensive intrusion
detection possible. (This is also one of the reasons why comparisons
between PortSentry and Snort are N/A; PortSentry doesn't *want* or *try*
to be a comprehensive IDS [Intrusion Detection System].)

> I've also seen people posting this week saying "don't rely on
> portsentry to solve your problems or protect your box, it
> should just be a heads up as to what's going on". So that
> worries me too. If portsentry isn't effectively
> blocking these portscanners, which we could rely on to
> protect ourselves, then what is it doing?

Two things here: PortSentry effectively blocks portscanners, since the
moment they hit an unused port they get blocked.

However, PortSentry does not protect against an FTP exploit, or a BIND
exploit, or an rpc.statd exploit, specifically in any way. And if you
run any of those services and have daemons listen on those ports, the
armies and legions of Hell could come pouring in and PortSentry just
wouldn't give a damn... it leaves the ports you use alone.

Portscanning is blocked.
Used ports are not touched; hence no protection against exploits.

> It drops them into the hosts.deny file. Okay. Exactly what
> does this do?

inetd and xinetd first check the hosts.allow and hosts.deny files before
granting access to a service. First, if the IP is somehow listed in
hosts.allow, it is immediately allowed with no further checks. Then, if
the IP is not listed in hosts.allow but *is* listed in hosts.deny, then
it is immediately denied. If the IP is not listed in either file, then
the connection is allowed.

This only protects those services run from one of these two daemons.
FTP, BIND, and sendmail just to name a few, are *not* protected in any
way by tcp_wrappers. Useful, but only partial.

> It adds them to the /sbin/route yadda yadda table in memory.
> Exactly what does that do?

Creates a route *from your host* and *to that host* which is immediately
rejected, and whose packets get dropped. The point here is that packets
may get to your machine, but they won't be able to get back because your
server will route them to Hades. Note that this provides "asymmetric"
protection, since packets do get to your machine and the cracker *can*
crack your machine. Packets won't get back out to him, but if he's good
enough to type in commands blind he can still cause damage. He can also
DoS you... again, packets come in but don't go out. Not the best way.

You didn't specifically ask about ipchains, but...

ipchains is AFAICT the single best way to do this. The moment a packet
touches your Ethernet interface, the *very first* thing is does is go
through the packet filter (ipchains) and its input rules. If a rule says
to discard it (DENY), it's gone. Dead. History. The rest of your machine
never even sees it.

Hope this is plain-speak. And I'll give you a hand with your ipchains as
soon as I install mine. :)

However, one thought occurs... if PortSentry only listens on the ports I
*don't* use... and if I tell ipchains to only let packets through to the
server on ports I *do* use... then PortSentry is automatically useless
to me. At that point I do have to go to something like Snort for
Intrusion Detection (which *does* try to stop specific exploits but
*does* cause many more false alarms... which *is* something I'm prepared
to live with.)

Penny for your thoughts... don't make me write this much and then leave
me hanging. ;)

--
Rodolfo J. Paiz
rpaiz@xxxxxxxxxxxxxx <mailto:rpaiz@xxxxxxxxxxxxxx>