Looks like a good idea. I am not sure it has been implemented but it has
some problems though..
About the case if someone is connected to your "secret sequence" ports,
you can configure your machine so that there will be a server that is
always listening to those ports and not allowing any connection to be
made: such that it would accept connection requests (i.e. client's
punches) to those ports but it won't reply. Thus, no one will indeed be
connected to those ports, but you can still "punch-in" your connection
trigger sequence. Indeed that server should be your inetd daemon that
keeps track of "trigger sequences".
But, if I can intercept your "trigger sequence messages" as an attacker
on your subnet, or even on the Net, I can replicate the same sequence
quite easily!
-dce.
Mark Edgington wrote:
Hi,
I'm not sure whether this idea has been considered or implemented
anywhere, but I have been thinking about it, and believe it would
provide a fairly high-level of security for systems which only run a
few public services. The gist of it is this:
incorporate functionality into inetd/xinetd/rinetd which listens for a
predefined sequence of connection attempts on certain ports. Upon
noticing the correct sequence (as specified somewhere in the config
file), it opens up certain ports (i.e. SSH) for a specified amount of
time or for the next connection attempt only. The parameters which
could be set in the config file would be:
1) the "trigger" sequence (an ordered list of port numbers)
2) the port(s) to make available upon receiving this trigger sequence
3) whether the ports to be made available are available for a) the
next n connections only, and/or b) the next n minutes
3) how long to disable watching for the sequence after an invalid
sequence has been detected.
So, for example, lets say I'm a hacker wanting to see if port 22 is
open. I attempt to make a connection, and the port appears closed.
However, now the owner of the machine is interested in remotely
ssh'ing into the machine. He connects to ports 20452, 19421, 9642,
7143, and 4385 in order (it doesn't matter if others are connecting to
port 80, etc. while he is doing these connections, as long as no-one
else is trying to connect to any of the ports in the trigger-sequence
list -- this is the only thing which will invalidate the
sequence-recognition; i.e. if the owner has made connection-attempts
to 20452 and 19421, and somebody else for some reason makes a
connection to 4385, this would invalidate the sequence) -- if these
trigger-sequence ports are all connected to in order (and the
disable-sequence-listen timeout has elapsed), then port 22 becomes
open to connect to.
Unless the hacker is on the same subnet that you (or your gateway) are
on, it would seem a very difficult task for him/her to determine what
the magic port-connection sequence is, and with appropriately chosen
disable-sequence-listen timeouts, brute force techniques would seem
pretty impractical.
This is of course no substitute for basic security measures such as
patching vulnerabilities in services, but I think it would provide an
extra layer of security for systems on which certain services are only
to be made available to a select few.
Let me know if you have comments on this. I'm also interested to know
if this has already being implemented anywhere.
-Mark
