Port knocking [LWN.net]

Port knocking

Posted Mar 19, 2004 1:24 UTC (Fri) by AnswerGuy (guest, #1256)
In reply to: A new Adore root kit by mikeraz
Parent article: A new Adore root kit

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 ...)

(Log in to post comments)

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