Cryptographically and Constantly Changing Port Opening(jgc.org)
jgc.org
Cryptographically and Constantly Changing Port Opening
http://www.jgc.org/blog/2007/11/cryptographicallt-changing-port-opening.html
A little layer of security I use for my servers.
16 comments
I'd like to get expert advice on this (cperciva or rtm?)
I guess we can agree that it doesn't fix any security problem; it's just redundancy, right? In this case, it's not another link in a chain but an additional layer of security. But is it "defense in depth" or just plain paranoia? Defense in depth is believed to be a good security principle; paranoia is not, because you don't use the rational part of your mind anymore so you don't focus where it's important and you're blind to some attacks.
So, the question is, do you think this trick actually:
- makes the system more secure;
- makes the system less secure;
- is irrelevant to security.
edit: jgrahamc, I didn't notice you were both the author of the trick and the submitter; can you provide some rationale backround?
I guess we can agree that it doesn't fix any security problem; it's just redundancy, right? In this case, it's not another link in a chain but an additional layer of security. But is it "defense in depth" or just plain paranoia? Defense in depth is believed to be a good security principle; paranoia is not, because you don't use the rational part of your mind anymore so you don't focus where it's important and you're blind to some attacks.
So, the question is, do you think this trick actually:
- makes the system more secure;
- makes the system less secure;
- is irrelevant to security.
edit: jgrahamc, I didn't notice you were both the author of the trick and the submitter; can you provide some rationale backround?
Well, it depends how you look at the problem. Brute force attacks against SSH are a real threat, but this can be mitigated in different ways.
I didn't have a chance to post a more elaborate response earlier but I'll give it a shot now. The problem that needs to be addressed is the ability of attackers to brute force the SSH service. In order to mitigate this one should
1) Use only public key authorization for SSH or 2) Use VERY STRONG passwords 3) Have a long limit between password attempts or 4) Have the computer blacklist any IP that tries to log in unsuccessfully more than X times (where X ~ 10) 5) Have SSH running on a non-standard port. This will deflect the majority of automated attacks but will not stop a dedicated attacker. 6) Use port knocking or the technique described to allow only users with some knowledge of the system to be able to talk to the SSH service 7) MONITOR YOUR LOG FILES. An attacker should not EVER be able to brute force passwords for a few days without YOU noticing.
Now you are free to layer as many of these as you need and each will reduce the probability of a successful attack, but you need to take into consideration the cost vs risk. For example the technique described in this article offers added security but places limitations on connecting to the machine (from a client that has the right algorithm, with synchronized clocks, and also make sure not to make a mistake otherwise you'll get locked out for 15 minutes which can HURT if you're dealing with a critical matter).
Personally I like the concept but I think the added costs are too great and compared with using some of the other security mechanisms.
1) Use only public key authorization for SSH or 2) Use VERY STRONG passwords 3) Have a long limit between password attempts or 4) Have the computer blacklist any IP that tries to log in unsuccessfully more than X times (where X ~ 10) 5) Have SSH running on a non-standard port. This will deflect the majority of automated attacks but will not stop a dedicated attacker. 6) Use port knocking or the technique described to allow only users with some knowledge of the system to be able to talk to the SSH service 7) MONITOR YOUR LOG FILES. An attacker should not EVER be able to brute force passwords for a few days without YOU noticing.
Now you are free to layer as many of these as you need and each will reduce the probability of a successful attack, but you need to take into consideration the cost vs risk. For example the technique described in this article offers added security but places limitations on connecting to the machine (from a client that has the right algorithm, with synchronized clocks, and also make sure not to make a mistake otherwise you'll get locked out for 15 minutes which can HURT if you're dealing with a critical matter).
Personally I like the concept but I think the added costs are too great and compared with using some of the other security mechanisms.
It's a way of deflecting a brute force attack on my SSH server. I think it makes things more, not less, secure, but I'm certainly open to comments.
John.
John.
From a purely technical point of view, I agree that it's more secure.
But from a psychological point of view, isn't this system somewhat similar to security through obscurity? That is, isn't it an incentive to not care about the rest (keeping the software up to date, monitoring the logs, etc.) because you now think that your SSH server is in a safe place, out of reach? Because, now, you may tend to think that nobody will seriously attack it (whereas you just filtered out the harmless, mass-scanning attackers).
I know you wrote "Of course, this doesn't replace making sure that the SSH server is up to date [...]" at the end of the article; but, well, most programmers will also tell you "you must document and test your software, brush your teeth three times a day, etc." :)
I know you wrote "Of course, this doesn't replace making sure that the SSH server is up to date [...]" at the end of the article; but, well, most programmers will also tell you "you must document and test your software, brush your teeth three times a day, etc." :)
I share the concern about security through obscurity. But this isn't intended to be obscure (it's not like I change the port to 12222 and hope no one finds it). It's a technique like port knocking which relies on the algorithm being totally open but the underlying hash being unpredictable. All the security here comes from the passphrase + hashing combination which is designed to make the actual port difficult to determine.
John
John
How do you make sure the times are synchronized?
Why don't you just have your server broadcast a bunch of bits that change every minute and use them instead of a timestamp to hash with your secret?
Your protocol seems vulnerable to eavesdropping, technically couldn't someone sniff any client's packets to find out which port to connect to?
Also, I suppose you have some kind of tolerance for when you send a packet to the server at minute x and 59 sec and it arrives at minute (x+1) and 01 sec?
Why don't you just have your server broadcast a bunch of bits that change every minute and use them instead of a timestamp to hash with your secret?
Your protocol seems vulnerable to eavesdropping, technically couldn't someone sniff any client's packets to find out which port to connect to?
Also, I suppose you have some kind of tolerance for when you send a packet to the server at minute x and 59 sec and it arrives at minute (x+1) and 01 sec?
Yes, you are correct this approach would be vulnerable to a simple man-in-the-middle attack. Just sniff packet headers to find out what port the server is accepting indicated by packets sent back with an ACK flag set. Headers with that flag set will be the currently valid port at that instant, since all other packets will be sent back with RST set (blocked).
And yes you could have potentially very frustrating synchronization problems. With TCP you wont be able to control certain things such if a connection request is going through exponential back-off due to network congestion. For example, lets say you could make a connection request within your alloted tolerance, but if there is network congestion and your NIC is not getting either RST or ACK packets back, it will continue to send connection requests at continuously increasing intervals which you cannot easily control since its done at the transport layer. Then one of your connection request packets finally reaches the server late, and you are blocked from connecting again for 15 minutes.
If you could work around the second issue though it could work. I think its a great idea in general, nice creative work!!
And yes you could have potentially very frustrating synchronization problems. With TCP you wont be able to control certain things such if a connection request is going through exponential back-off due to network congestion. For example, lets say you could make a connection request within your alloted tolerance, but if there is network congestion and your NIC is not getting either RST or ACK packets back, it will continue to send connection requests at continuously increasing intervals which you cannot easily control since its done at the transport layer. Then one of your connection request packets finally reaches the server late, and you are blocked from connecting again for 15 minutes.
If you could work around the second issue though it could work. I think its a great idea in general, nice creative work!!
So the way I currently have it the man-in-the-middle is useless because once a client connects to the SSH server all other IP addresses are locked out from that port.
I agree about congestion, but IIRC the TCP connection timeout defaults to 75s so since I'm tolerant to connections across two windows (i.e. two minutes) then I think I'm safe.
John.
I agree about congestion, but IIRC the TCP connection timeout defaults to 75s so since I'm tolerant to connections across two windows (i.e. two minutes) then I think I'm safe.
John.
Ah, so your server only accepts 1 connection at a time on a given listening port? That is good protection.
I didnt realize there was a TCP standard for the max acceptable amount of retransmissions. But yeah if you can account for this with a pad then you should always be safe.
If you ever opensource your network code I'd love to see it.
I didnt realize there was a TCP standard for the max acceptable amount of retransmissions. But yeah if you can account for this with a pad then you should always be safe.
If you ever opensource your network code I'd love to see it.
I plan to open source it once I get it a little cleaned up :-) It's on my TODO list.
John.
John.
I only need sync. to the nearest minute. NTP does that fine for me.
John.
John.
Why am I reminded of the poison scene from The Princess Bride?
I just use non-dictionary-based passwords and denyhosts.