-
New idea - Port Knocking
Over at /. I found this:
http://slashdot.org/articles/04/02/0...id=126&tid=172
Some of the slashdotters haven't quite grasped the concept of it being the first defence rather than the only defence, but I like the idea.
I intend to read the article and try it out this weekend.
-
Yeah I liked this. Some of the /. arguments were really poor though. It's simply another level on top of whatever security you currently have, and I dont see anything wrong with that...
-
Interesting, but it kind of falls into a middle ground between "good" and "very good" security IMO.
The issue with the packets arriving out of sequence I think would not be fixed with TCP sequencing as the first packet would be a straightforward SYN, so there is no sequence established at that point, plus it would be silly to build a system using a 2-way protocol and deliberately break the protocol standards by not issuing (or expecting) a response.
Packets would have to be UDP methinks.
I say it falls into the middle ground security-wise, as anyone who is serious about security to that kind of degree would use token or biometric authentication if they really needed roaming users, or for SSH they could use PKI and rely on the user having a certificate which the admins issued, requiring a passphrase to authenticate.
Ultimately the "password" sequence would have to be coded into an application or client somewhere, and be static, thus it could be picked up by a trojan.
The alternative is to use a rolling sequence but then you'd have to have the users authenticating somehow to be able to get the authentication data... back to square 1.
The bit which did sound interesting, though, was the potential for different "knock" sequences to temporarily map a public port to an internal service for that source IP alone - that would be a very neat way of being able to dynamically NAT a whole bunch of machines on a LAN to the outside world, for virtually any service you wanted.
Though in reality this could be achieved by a single encoded packet one a user has authenticated to the firewall, rather than sending UDP packets to a sequence of ports.
Nice concept, and an interesting thread, thanks :)
-
I saw this and thought it was quite a clever idea , I dont know how practical it would be but Im sure some boffin can find a way :D
-
in an ideal ( but evil) world , we'd use secureID one only passwords for everything , though could this proove a reasonable cost effective alternative ?