Re: idea for improving security
Hi.
There are two serious problems to this security scheme, either of which
would be enough to make it not worthwhile to implement.
1) Ease of implementation. To implement this security measure for, let's
say, ssh, every legitimate user would need special ssh client software, or
a software wrapper, that implemented the scheme. The reason why ssh
exists is to provide a standard protocol for one computer to securely
access data on another. Adding this scheme to the protocol at any point
downstream of the ssh devel. team breaks this standard. In fact every
service you wanted to provide would need extra client software. This is
not feasable.
2) Security by obscurity. If this scheme is implemented with every user
using the same port ping sequence, you have merely added a layer of
obfuscation, not a layer of security. This is a HUGE no-no. It would not
take long for black hats to figure out what is going on, by simply
searching online for debian security measures. A series of
targeted pingsweeps could then determine the correct sequence of ports in
a matter of minutes. If, alternatively, each of your users had a separate
"passport" (I just tradmarked that, if you use it you have to pay me ;),
then you have essentially created a second password that would be
guessable using the above method, as well as tying up dozens if not
hundreds of ports.
Cheers,
nate
On Tue, 6 May 2003, 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
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
_______________________________________________________
"A man can't just *sit around*."
--"Lawnchair" Larry Walters
www.darwinawards.com/stupid1997-11.html
nathan@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Reply to: