Ssh brute force attacks [SOLVED]

Hardly the same thing to compare with ftp server is it?

most likely it´s only you that are sshing into the box, does it really matter if you move it to another port?

out of my personal experience regarding exposing ports to the internet is that less ports open(easy to find) the better

or like i said, use fw rules allowing port 22 only from certain hosts/nets

I´d rather be unprofesional then have a bruteforced box, but hey…such a thing would only a profesional know

uzzi

@fredde:

I´d rather be unprofesional then have a bruteforced box, but hey…such a thing would only a profesional know

did u think that i sad that YOU are unprefesional?? i only sad that its a unprofesional SOLUTION.ok so this is clear now but what if i connect to my box from a dynamic host? i travel alot so probably i will never have the same ip when connecting remote to my ssh

edited: and u did not answer my question…is such a scrip/plugin for ssh or not

Cry Havok

Options:

Install denyhosts (or similar), currently there's no package for this so you're on your own
Do what a lot of professionals do - move SSH to a different port, if it's not providing a public service you don't need to run it on the well known port

This isn't a pfSense problem BTW - it isn't an application layer firewall. If you want to protect services at the application layer (that is, stop things like brute force attacks etc) you need to research appropriate solutions.

Of course, a Google for "ssh brute force" would have given you (1) on the first hit ;)

uzzi

and how about the odher problem?? i changed the webgui username and password and i can still login using the admin or root username and my current password?

this ain`t no pf.sense problem?

Kris.J

"Best Practice" in general has your solution!

1. Change your SSH port, as has been already stated.
2. Setup OpenVPN - if you cannot predict your source IP addresses and write Firewall Rules appropriately, then you need to be VPN'ing in. Period.
Setup your OpenVPN connection, and turn off the WebGUI access from the WAN side entirely.

You seem concerned about security - but you need to implement best practice before calling out what you think might be problems with pfSense. ;)

kpa

@uzzi:

and how about the odher problem?? i changed the webgui username and password and i can still login using the admin or root username and my current password?

this ain`t no pf.sense problem?

I guess you have to reboot for the changes to be applied properly to the ssh configuration. There are few other things as well in pfsense where changing something in the webgui doesn't really change the runtime settings until you reboot, the openvpn configuration for example.

mhab12

Am I wrong in assuming that Snort could detect these repeated connection attempts and block the IP?

Slam

@mhab12:

Am I wrong in assuming that Snort could detect these repeated connection attempts and block the IP?

Configured the right way, yes it should work, although I havent used Snort in a while.

I've also seen a handy perl script that detects such port scans and then emails abuse@provider, all automated, but unfortunetly I cant recall what site I saw that in, its been a while.

jahonix

Why not use the obvious and deny ssh login with user/password.
Go to System: Advanced functions and check this box: Disable Password login for Secure Shell (KEY only)
after you entered your key.
Noone will be able to lock in with a brute force attack then.

uzzi

@jahonix:

Why not use the obvious and deny ssh login with user/password.
Go to System: Advanced functions and check this box: Disable Password login for Secure Shell (KEY only)
after you entered your key.
Noone will be able to lock in with a brute force attack then.

this is the best solution i think…..now all i need to do is generate a strong key

and lol i did rebooted after i changed the password and username but it aperas that somehow the user root and the user admin are still valid

abbiz

@uzzi:

all day (and nigt) i recive this messages on my pfSense box

Mar 31 23:59:00 sshd[16222]: Failed password for invalid user bot from 59.95.41.27 port 57134 ssh2
Mar 31 23:59:00 sshd[16222]: Invalid user bot from 59.95.41.27
Mar 31 23:58:57 sshd[16219]: Failed password for invalid user nice from 59.95.41.27 port 56299 ssh2
Mar 31 23:58:57 sshd[16219]: Invalid user nice from 59.95.41.27
Mar 31 23:58:54 sshd[16216]: Failed password for invalid user nologin from 59.95.41.27 port 55462 ssh2
Mar 31 23:58:54 sshd[16216]: Invalid user nologin from 59.95.41.27
Mar 31 23:58:51 sshd[16214]: Failed password for invalid user user from 59.95.41.27 port 54612 ssh2
Mar 31 23:58:51 sshd[16214]: Invalid user user from 59.95.41.27
Mar 31 23:58:47 sshd[16211]: Failed password for invalid user ferari from 59.95.41.27 port 54578 ssh2
Mar 31 23:58:47 sshd[16211]: Invalid user ferari from 59.95.41.27
Mar 31 23:58:44 sshd[16208]: Failed password for root from 59.95.41.27 port 54539 ssh2
Mar 31 23:58:41 sshd[16206]: Failed password for invalid user rootkit from 59.95.41.27 port 54512 ssh2
Mar 31 23:58:41 sshd[16206]: Invalid user rootkit from 59.95.41.27
Mar 31 23:58:38 sshd[16203]: Failed password for invalid user rk from 59.95.41.27 port 54467 ssh2
Mar 31 23:58:38 sshd[16203]: Invalid user rk from 59.95.41.27
Mar 31 23:58:35 sshd[16201]: Failed password for invalid user xvf from 59.95.41.27 port 54364 ssh2
Mar 31 23:58:35 sshd[16201]: Invalid user xvf from 59.95.41.27
Mar 31 23:58:32 sshd[16198]: Failed password for invalid user zxvf from 59.95.41.27 port 53569 ssh2
Mar 31 23:58:32 sshd[16198]: Invalid user zxvf from 59.95.41.27
Mar 31 23:58:29 sshd[16195]: Failed password for invalid user tar from 59.95.41.27 port 53502 ssh2
Mar 31 23:58:29 sshd[16195]: Invalid user tar from 59.95.41.27
Mar 31 23:58:26 sshd[16193]: Failed password for invalid user tgz from 59.95.41.27 port 52688 ssh2
Mar 31 23:58:26 sshd[16193]: Invalid user tgz from 59.95.41.27
Mar 31 23:58:23 sshd[16190]: Failed password for invalid user edit from 59.95.41.27 port 51893 ssh2
Mar 31 23:58:23 sshd[16190]: Invalid user edit from 59.95.41.27
Mar 31 23:58:20 sshd[16188]: Failed password for invalid user mcedit from 59.95.41.27 port 51859 ssh2
Mar 31 23:58:20 sshd[16188]: Invalid user mcedit from 59.95.41.27
Mar 31 23:58:18 sshd[16137]: Failed password for invalid user pico from 59.95.41.27 port 51045 ssh2
Mar 31 23:58:18 sshd[16137]: Invalid user pico from 59.95.41.27
Mar 31 23:58:14 sshd[16106]: Failed password for invalid user work from 59.95.41.27 port 50224 ssh2
Mar 31 23:58:14 sshd[16106]: Invalid user work from 59.95.41.27
Mar 31 23:58:11 sshd[16104]: Failed password for invalid user ircop from 59.95.41.27 port 49436 ssh2

this is a brute force atack.

My question is this: 1. Can i automatic block this atacks? whithout manualy adding the ip to the block list in the firewall rules?? i mean some kind of ssh plugin or something like this

2.I changed the default password and username fot the webGui but i still can login with the root username….why?

tnx in advance

try to install fail2ban. It analyses the log and blocks automaticly with a firewall rule after five failed ssh logon attempts. I have installed it on Fedora and it works pefectly. I don´t know if it is possible to install it with pfsense
/Albin

GruensFroeschli

fedora = linux
pfSense = FreeBSD

fail2ban is a linux software.
You "might" be able to port it to FreeBSD but that would bring you nothing.
@fail2ban:

Uses Netfilter/Iptables by default but can also use TCP Wrapper

pfSense uses as Firewall PacketFilter or short (you guessed it) "pf".

@abbiz: try to familiarize yourself with a firewall before giving advice about it.

GoldServe

Use the advanced option under rules. Works for me in limiting the SSH connections per host.

Advanced Options

Simultaneous client connection limit
Maximum state entries per host
Maximum new connections / per second
State Timeout in seconds

NOTE: Leave these fields blank to disable this feature.

Kris.J

@GoldServe:

Use the advanced option under rules. Works for me in limiting the SSH connections per host.

Advanced Options

Simultaneous client connection limit
Maximum state entries per host
Maximum new connections / per second
State Timeout in seconds

NOTE: Leave these fields blank to disable this feature.

Sure that'll work - but best security practice dictates that:

if you are only using SSH for yourself and not "the public" in general, you should be running it to listen on a non-standard port.

GoldServe

Yupp. I just get a kick watching people attack…3 connections made and then they die for the hour. Must boggle their minds =p

uzzi

@GoldServe:

Use the advanced option under rules. Works for me in limiting the SSH connections per host.

Advanced Options

Simultaneous client connection limit
Maximum state entries per host
Maximum new connections / per second
State Timeout in seconds

NOTE: Leave these fields blank to disable this feature.

ok, now this helped me alot so now my problem is solved tnx GoldServe

GoldServe

Just realized that my method of blocking doesn't work if the other side uses the same connection port. Their brute force will be quite slow but none the less, does not totally work.

For those of you not already doing so:

Limit the Source IPs in your external SSH rules
Install SSH keys and do not allow logins without keys
Rate limit connections as indicated in the forum.

All the tools to limit your exposure to SSH bruteforcing are in place, its up to you to use them.