On Wednesday 07 May 2003 13:54, Jay Kline wrote: > This is still prety complex, if the end result is just to allow access to > port 22. > > SSH is pretty secure, there have been very few problems with ssh that allow > someone without an account to gain access to the system its on. If you > take all other precautions, your risk is pretty low. If your data is so > valuble that you still cant afford the risk, then you need to take measures > farther by having a that box on a private network where only specific hosts > can log in, and set up a secondary host just to authenticate in.
I agree - this "security by obscurity" approach will most likely end up making it less secure than it was originally. Remember the most likely way the cracker will get in in the first place is through a vulnerability in a service you do need to have open unconditionally, e.g. in your http server. Let's say the cracker did get in with something like that, gets unprivileged access but enough that he is able to see that you have configured your ssh to use a "port locking" sequence as described. Now suddenly a very simple DoS attack becomes available, as a way to prevent the rightful admin to get into the box once it's been cracked, leaving the attacker time to get root. Don't do it. Either trust sshd (disable most of its features by tweaking its config, then it should be pretty secure!), or don't allow remote logins at all. If you do want some extra security there are other ways that would be more effective, e.g. you can delete /bin/sh and /bin/bash etc. in your rc script after your Apache and other services are started (so long as they don't depend on them), and have your proper SSH call a secret copy (/bin/secretshell or something) when you log in. This prevents many attacks where the attacker relies on spawning a shell on your system from whatever program he's using a vulnerability in. // Thomas
