How to Prevent SSH Attacks ?

A

annaconda

[H]F Junkie
Joined
Apr 13, 2005
Messages
9,925
I have setup my Server for SSH. I am using SSH for file transfering over WLAN, so i noticed since i setup the SSH, there are millions of attempts to log in.

The Event viewer is full of these attempts. How can i prevent these attacks ?
 
a basic network diagram showing the topology would be useful in helping us to advise of the steps that can be taken at each point in your network to try and offer better security.
 
It is a basic Home Network.

2003Server -> Fios Router -> WLAN.

I have setup my Actiontec M1424WR router's Firewall on Highest, and using Access-List, with port forwarding for my Exchange 2003 server, DNS + SSH, etc.
 
let me get this straight...

your running an ssh server on your windows server...

so that you can transfer files from your windows server, over ssh, over the wlan...

but your also port forwarding ssh from the internet across your nat router to the windows server...
 
atomiser said:
let me get this straight...

your running an ssh server on your windows server...

so that you can transfer files from your windows server, over ssh, over the wlan...

but your also port forwarding ssh from the internet across your nat router to the windows server...
Click to expand...

Yes, you got that right. Sorry i should have cleared that out. I am using OPENSSH in windows 2003.
 
are you actually using the ssh connection from outside? if so, what specific task are you doing?
 
You could use the built-in firewall or use Comodo Firewall Pro 2.4 to restrict what IP addresses the Windows 2003 server will allow to connect.
 
are you tunelling rdp over the ssh connection? if so, ditch that configuration and just use logmein free instead.

and why are you bothering with ssh for file transfer over wifi? just use wpa2 and a decent encryption key.
 
I believe he intended to use WAN instead of WLAN.

2003 Server<->FIOS<->WAN

If he was simply connecting via his WiFi he would not have needed to use port forwarding.
 
if indeed you do mean wan, then the *bare minimum* you should do is:

in the firewall policy on the router for inbound nat connection, limit the source ip to known addresses. (n.b. this will affect the flexibility of where you can connect from)

if you don't have a firewall installed/enabled on the server, get one! as above, limit the source ip to known addresses. (n.b. this too will affect the flexibility of where you can connect from)

ensure that the ssh server has an appropriate banner and a very strict username and password policy - e.g. authorised users only, minimum 10 character upper lower alpha numerical punctuation, 15 minute lockout after 3 failed authentications.
 
I too had this problem on a linux box. Looked and tried all kinds of IDS/IPS and didn't come to find one that worked really well without uber-customizing it. I was going to have to parse the sshd log file and actively block attempts after a certain number of misses, and I ran out of frustration.

Changed the port to something in the 20,000's. Fixed. Have yet to see a single attempt on it since.

Sometimes KISS is the way to go. I know security by obscurity is not by any means safe, BUT, so far it has worked like a charm. And please make sure you have a very secure password and do all the other smart stuff (no root/administrator and such).
 
c.d.e said:
Noone has mention Non-Default Port?
Click to expand...
Yea, about 3 posts back
SpaceHonkey said:
I too had this problem on a linux box. Looked and tried all kinds of IDS/IPS and didn't come to find one that worked really well without uber-customizing it. I was going to have to parse the sshd log file and actively block attempts after a certain number of misses, and I ran out of frustration.

Changed the port to something in the 20,000's. Fixed. Have yet to see a single attempt on it since.

Sometimes KISS is the way to go. I know security by obscurity is not by any means safe, BUT, so far it has worked like a charm. And please make sure you have a very secure password and do all the other smart stuff (no root/administrator and such).
Click to expand...
 
I run my SSH access to home on a non-standard port + port knocking, deters the casual port-22 / common port sniffing jackass.
 
Sorry guys i was busy on work. Alright, sorry one more time for not clearing this up, because i come to this forum from work (always in hurry).

Alright i meant to say WAN. The reason i use SSH is because i thought it is secure, and use it to transfer big files e.g Person Movies, Documents, Pictures etc.

Using different port will be a good idea.

I am using username and password to login to the server. Password contains Uper case letter + Lower Case letters + Numbers. As i see in the log, all the attempts fail but i am just kind of worried. There is also a key has been set by OpenSSH, which is really really long and complicated.

I cannot restrict specific IPs, because most of my family member has DSL and there IP changes quite frequently.

I know i can use free LogmeIn VPN, but then there is no fun of learning.
 
I tried to change the port. It did not work, any one know the commands to change the port OPENSSH.

I edit the SSH_CONFIG & SSH_CONFIGD file in ETC folder, and changed the ports to 58, 8085, etc and none of them work. When i switch back to 22 it worked fine.

I use winscp as a client to connect and i change the ports in their too, but nothing. Firewall setting has been set to allow 58 port, etc.
 
just change the sshd_config file to specify port XXX, then restart the service (it is running as a service right?) Then you should be able to connect on the port specified.
 
where were you trying to connect from? locally? or across the wan? remember that whatever port you change it to on the server, you will need to update your port forward record on your router. that is, of course, unless your router can be configured to port address translate... in which case, leave your server alone and just connect to the router via an obscure port and set that to translate to 22 on the local resource.

it's still a good idea to set a banner, and to try to implement a 3 attempt lockout.
 
I've had reasonably good luck with DenyHosts for dealing with dictionary attacks (MacOS X, Linux, and FreeBSD), and have found it easy to configure. That said, it works pretty well as is with most RedHat/SuSE/Debian distros as configured in the package.

http://en.wikipedia.org/wiki/DenyHosts
http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts
http://denyhosts.sourceforge.net/

Fail2ban does pretty much the same, but I did not find as easy to configure, nor was it as functional out of the box or as well documented. (Those judgments are a matter of personal taste. It's easy to try them both, and see which one you prefer.)

http://en.wikipedia.org/wiki/Fail2ban
http://www.fail2ban.org/wiki/index.php/Main_Page
http://www.howtoforge.com/fail2ban_debian_etch

If you don't want to exclude "family members' IP's", you should be able to easily predict which IP blocks they come from and put them in the "don't ban" section. (e.g. 4.2.2.0/24)


As another layer of security, configure your sshd to disallow root logins, and restrict which users are allowed to initiate ssh sessions.
PermitRootLogin no
AllowUsers Allowed_User1 Allowed_User2 [email protected]

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/s1-wstation-privileges.html
http://www.faqs.org/docs/securing/chap15sec122.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/openssh.html

A more sophisticated approach would involve issuing public keys to your "family members", and only allowing key-based authentication for ssh sessions. That's quite a bit more involved than I can explain easily here, and frankly, if you don't have the research skills to find out how to do it on your own (hint: follow the links above), you should probably leave it alone for the time being. (I don't mean that to sound snotty, it's just easy to implement improperly and allow open access to the world.)

Whatver you choose to do, try to use as many security layers as possible. No one strategy will work well on its own, always treat security as a process and use defense in depth.
 
atomiser: Yes i have correctly forwarded the ports also.

Fri2219: Thanx a lot man for all that info, i will see what i can do.
 
You must log in or register to reply here.
Back
Top