A new Adore root kit [LWN.net]

A new Adore root kit

Posted Mar 18, 2004 2:13 UTC (Thu) by mikeraz (guest, #155)
Parent article: A new Adore root kit

What can we look forward to? It seems the only way to detect an Adore compromised system would be through a Nessus, or other port scanning tool, port scan detecting open ports. But if the Adore designers were to implement port knocking they could hide from that detection method also. Detection of a compromise would be very difficult then.

(Log in to post comments)

A new Adore root kit

Posted Mar 18, 2004 17:28 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

I loved your idea so much, I whipped up just such a thing as a quick Perl script: http://www.magrathea.com/~ras/misc/rpscan... ;-)

Perl isn't my strongest language (I usually write pure C code), but it seemed like the best bet for such a quick and dirty task... But, any strong Perl coders, forgive any obvious mistakes on my part... ;-)

A new Adore root kit

Posted Mar 19, 2004 4:00 UTC (Fri) by xorbe (subscriber, #3165) [Link]

Not if the module doesn't bind to the port until it sees the secret knock goes by. That's the whole point...

A new Adore root kit

Posted Mar 24, 2004 6:38 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]

Won't it at least have to bind to the first port of the "knocking" sequence?

A new Adore root kit

Posted Apr 3, 2004 0:30 UTC (Sat) by alterself (guest, #1746) [Link]

The idea is not that you bind to the port... but that you log attempts to open the port.

On a normal tcp/ip stack... the stack sends a request denied on attempts to open closed ports. I would imagine that if the module tied into the tcp/ip stack, it could monitor for attempts to open a specific set of ports...

Port knocking

Posted Mar 19, 2004 1:24 UTC (Fri) by AnswerGuy (guest, #1256) [Link]

If the attacker wants to run a custom service (not some commodity like a warez FTP or IRC node) then he can use a "port knocker" to obscure it from scanning. Basically the ports appear closed but some magic sequence of packets (could be anything that the port knocker module will see, including DNS response packets from a magic source address, think of an ipchains rule that logs such packets and a tail -f script that monitors the logs for them, then opens the port for a limited time and possibly to a limited address. --- now just hide that a little better. Presto! port knocker!)

Of course they can run any service on any port using this technique, it's
just that the clients have to have the right "knocker client" script (generally just something for netcat, socat, or perl's net libraries). They have to know the "secret knock" (Shave and a haircut ...)

SNORT or Prelude NIDS

Posted Mar 19, 2004 1:42 UTC (Fri) by AnswerGuy (guest, #1256) [Link]

I hate to respond to my own post but I forgot something that I'd
intended to say (hit the preview/submit buttons a little too quick)

This is one of the best reasons to run a tight SNORT Prelude
configuration. The default NIDS code is sort of like virus scanners
in that they only tell you about KNOWN attack signatures. However,
you can make a SNORT configuration that's more like a checksum
integrity tool (like Tripwire, AIDE or Samhain, only for net traffic).

Basically you have to be able to characterize, in detail the proper
and expected behavior of the protected system(s). A profile
of everything it should be allowed to do on the net. For example a
web server might need:

Inbound:
dst port 80 or 443 from anywhere,
dst port NTP from (list of three to give NTP peers),
dst port SSH from (list of two or three sysadmin workstations
and/or staging servers)
dst port SNMP from (list of NMS systems)
Outbound:
dst port any from port 80 or 443 (http and https)
dst port CVS (perhap for automated checkout of new changes
which are checked in by webmasters, web authors, programmers, etc.
dst port DNS to (list of internal name servers) (for reverse lookup?)

... and so on.

Once done properly ANY traffic that doesn't fit these rules will
be an alert on the NIDS (network intrusion detection system).
(Unless it also exploits a bug in your NIDS, which is hopefully
pretty hard to do these days).

Of course this sort of Draconian/totalitarian configuration is only
suitable for highly specialized servers. The more services running
on a machine the harder it is to characterize it's traffic. For most
client systems (workstations) ... FORGET IT!

I hope its clear why this works better than looking for bad traffic.
Here we look for "not good traffic." (Similarly one of the first
rules of secure and robust programming for parsers is that it's better
to suppy a list of known innocuous characters, tokens whatever, then
to attempt to filter out a list of "suspects").

JimD