How about adding a portknocker that would dynamically expose port 22 when the correct combination is sent by the client, and then later close the port to incoming connections?
Just an idea?
http://www.portknocking.org/
I Want My $2!!
How about adding a portknocker that would dynamically expose port 22 when the correct combination is sent by the client, and then later close the port to incoming connections?
Just an idea?
http://www.portknocking.org/
Iced Blended Vanilla Crème Ubuntu
On the contrary, my argument relies on your using strong passwords. What's the maths? 62 alphanumeric characters; a 12 character password; so something like 62^12 combinations at the very least to check. Then estimate how long that will take.Originally Posted by rickyjones
There is more chance of winning top prize in a national lottery five weeks on the run than guessing a strong password or rsa key.No matter how strong your key, if someone does guess the correct key and is ONLY looking at port 22 then you would be better off using a non-standard port to throw people off.
It does but, as I've remarked earlier, people who use weak passwords have no contribution to make here.Altering the port WITHOUT using strong password security DOES increase security, albeit it is still only as strong as your password.
Strong passwords are sufficient.Hence why I am advocating port changes AND strong passwords.
Let them try. Their chance of success is effectively zero. Please see above.If port 22 is scanned and attacked 100 times per hour then you have a two issues: more people trying to attack means more chances for success;
From my limited experience the impact of ssh probes on bandwidth or service availability is vastly overrated. Maybe it is different in the corporate world. I'd hazard a guess that the impact of spam is many orders of magnitude greater in respect of bandwidth etc.more people trying to get in ties up your bandwidth slowing down critical functions (like when you try to connect to your SSH server. If it is too busy dealing with unauthorized requests then this impacts your productivity).
However if port 22222 is only scanned and attacked once per hour then you reduced your risk by almost 100%. Less attempts against your server will result in the use of less bandwidth, along with leaving your service open to accept your login attempts. This will maintain your productivity levels.
Those who advise that you should or must move port seem to subscribe to the view that the internet is unsafe when with normal precautions it is not. Blacklist the offending IPs or move port by all means but sshd is secure on port 22.
You're probably right but it is an interesting discussion. What is also interesting is that the originator of this thread, wrjhee77, isn't offering a ssh service open to the outside but was still advised to move it to a different port.Theoretically the more we talk about this the more we may end up disagreeing. However here is something that you might agree with. Probably one of the best ways to secure your server that has OpenSSH access would be to set it up so that only authorized IP addresses are allowed to even attempt a connection. That, or else configure your server to only be accessed via VPN tunnel.
Once upon a time I did restrict IPs which were allowed to connect here. Then one day I happened to be in Madrid. And guess what I had forgotten to do? So never again. sshd is designed to be securely accessible from anywhere so that's the way I use it now.
Brian.
Tea Glorious Tea!
Very interesting idea! I wonder if a man in the middle attack could compromise the knock-order?How about adding a portknocker that would dynamically expose port 22 when the correct combination is sent by the client, and then later close the port to incoming connections?
Just an idea?
http://www.portknocking.org/
Chocolate-Covered Ubuntu Beans
I have to agree with the above. From what I have seen in our firewall logs, and from past traffic analysis, there is negligible impact from refused ssh connections. I have definitely never seen enough to overwhelm a server and make it unusable. Its not like you have to transfer much data to refuse an invalid connection attempt. They don't even rise above the background noise from probes to other ports.
Attachments from a few spam messages in a single day will utilize far more bandwidth than all the ssh connection attempts for that same time period.
I Want My $2!!
MIM attack -- Im not an expert but I don't think this would work.
Let me make sure we are both on the same page. And I am going to be speaking specifically of fwknop -- which is one instance of a port knocking program. For other less sophisticated clients, yes Im sure a MIM attack could be possible.
fwknop - http://www.cipherdyne.org/fwknop/
The client sends an encrypted port knocking request. Inside the port knock is the original senders IP address, a hash that would guarantee authenticity of the port knock if it were somehow decoded and changed. In addition the port knock is encrypted -- and the MIM would need to know the password to decrypt the packet. If the packet were simply sent along to the server, the MIM would not have access since the IP address of the firewall is only modified to allow access to the client's IP address. The packet could also not be held and later replayed, since each packet has a unique random number to prevent packet replay. An additional optional feature is that the packet could be gpg encrypted -- meaning its signed with the clients key and encrypted with the servers key. Even if this packet were intercepted -- in this scenario with asymmetric encryption, I would believe it nearly impossible to decode the packet.
I've recently writen a How-To for setting up fwknop with Ubuntu:
http://ubuntuforums.org/showthread.php?t=812573
5 Cups of Ubuntu
I'll admit, I haven't read the whole thread in detail, but the first question would be: what is the threat model? If you are worried about someone breaking into the DMZ host and being able to get through to the LAN over SSH by ordinary means, a strong password or other authentication measure by itself won't do much good, since rsync probably needs to run unattended. When someone has broken into a system, it is safest to assume that they have root access and thus can read/write any file on the system as well as inspect the contents of the system memory. So any protection would have to be on the server (LAN) side.
Set up the SSH server to only allow one specific login, which has the minimum required privileges required to carry out the task. Use for example public key authentication and set it up to only accept the passphrase-less key from the one IP of the DMZ host and to only allow execution of rsync when said key is used. Run the SSH server on a non-standard port if possible. Make sure both the SSH server and the rsync server are up to date at all times and properly configured. And do your best to secure the DMZ host (which should be done anyway).
Banned
well, you initiate rsync from the backup server... you will not rsync into the backup server
I Want My $2!!
dakal
Your method you propose is excellent. However if you lock your iptables to be so restrictive, this could potentially run into problems if you using ssh to access the server from different networks or different IP addresses.
Again its a tradeoff between stringency and flexibility. I'm not saying its the end-all-be-all, however port knocking allows use of a very restrictive firewall, but also allows for dynamic flexibility. Depending on the setup of the port knocker, this level of flexibility can definitely be modified to one's need.
Again fail2ban is another option, as well as a using the recent iptables module to limit repeated connection attempts.
There is no ideal solution, just the amount of flexibility you would like to introduce.
5 Cups of Ubuntu
Yes, higher security generally means less convenience. It's always a tradeoff, whether it's a server host firewall or nuclear ICBM launch procedures.
However, when the usage scenario is very narrow, you can usually go with relatively tight security without it causing an inconvenience. It's not very likely that you are going to need to backup to/from a system with a different IP address without knowing in advance. A more likely scenario would be that you would need to restore the backup without knowing one of the IP addresses involved beforehand, but that would involve some planning anyway.
Tea Glorious Tea!
+1 dood, that's some cool stuff
Posting Permissions
Adv Reply
Bookmarks