New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Wow...
Just logged in to my testing box after a weekend vacation to find this...
Last failed login: Sun Jun 7 13:28:10 EDT 2015 from ip-72-167-166->46.ip.secureserver.net on ssh:notty
There were 4279 failed login attempts since the last successful login.
Okay so from what I can find out is that SecureServer is GoDaddy, with the particular VPS' plan including cPanel... so running CentOS with Apache 2.2.23 . This same IP has also tried to spam my mail servers numerous times. Just a warning for those out there.
Comments
Thank you. I will keep a look out for this IP amongst the possible ~4 billion other addresses that could show up.
you done well. 4.2k isnt much these days.
Just logged in to my testing box after a weekend vacation to find this...
Okay so from what I can find out is that SecureServer is GoDaddy, with the particular VPS' plan including cPanel... so running CentOS with Apache 2.2.23 . This same IP has also tried to spam my mail servers numerous times. Just a warning for those out there.
Welcome to the internet.
Report it to GoDaddy not lowendtalk.
Pretty common, yeah. You get used to it after a while. Reporting to abuse@ the relevant service is the right thing to do, using fail2ban and/or non-standard ports should shave off a lot of the excess of this stuff.
Serious question: Do you report to abuse@ for each log entry you find?
Nope. It's the right thing to do but who has the time these days.
For production services, an automated approach is much better and efficient for sure. Wouldn't be hard to do it @Jar
I've solved the issue, I've banned every IP from 1.0.0.0 to 255.255.255.255 from connecting to my server.
Racism.
I don't have a problem with the colored IP's, I swear. The guy who made 'em simply burnt a few.
WTF?
Don't say it like it's wrong.
Set up an SSH key and disable password authentication. Problem solved.
Unplugging the Ethernet cable*
How would you connect to it then? After all, in order to SSH the VPS, a internet connection is required
Firewall + fail2ban + no password auth (only ssh keys) = no issues. On really important stuff I limit who can access SSH (ranges for my other boxes, home & office IP, VPN boxes, etc). Switching up port number is also easy enough to do.
Plus non-standard SSH port.
Completely unnecessary if you've disabled password authentication, and just a form of security through obscurity (that is going to come back to bite you when you try to use tools that either don't support non-22 ports, or are really awkward to use with them). Just leave it on 22.
I dont agree. Most, if not all, of brute force attempts are due to just generic scans on default ports (21, 22 etc etc) If someone is specifically targeting your servers then sure, its a different story. But in most cases you can lower the risk (not eliminate) by changing the SSH port.
If X software does not have the ability to be used on a non standard ssh port, then the software shouldn't be used to begin with. Says something (in my eyes) about the developers.
That being said, disable password auth and using key is a must also.
People attempting to brute force on 22 can cause a bit of load. If I leave stuff on 22 I only allow connections through my VPNs or another server of mine and drop every other connection. UFW is super easy to install, apply a few simple rules and you're done.
Ssh keys, fail2ban, firewall are useless if the attacker has access to your provider control panel. Solusvm, Virtualizor, etc.
It has no fail2ban or captcha thing. Why should they attack a secured box. The easiest thing is to attack master host solusvm.
At least save you some CPU usage. Also prevent some particular DDoS attacker from finding your real IP.
# Allows SSH connections (only 3 attempts by an IP every minute, drop the rest to prevent SSH attacks) ~ iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name DEFAULT --rsource -j DROP iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
DOS protection for that port (change 22 to w/e), not DDOS bruteforce, but should help. But Joepie's ssh key is the best solution ~
As others have mentioned above, this is not a targeted attack but rather dumb bots. I notice that most are attempted root logins, though a few are for some short dumb name user. I think that by not allowing root login and having a longer username (both trivial adjustments) these bot attempts have no chance. Of course the other things like using fail2ban should be done as well. And one must never neglect the possibility of a targeted attack, though I don't think it would generally be worth someone's effort on a LEB.
use ovh/online.net you'll surpise
12586 failed login attempts since the last successful login
Changing ssh from port 22 can reduce a bit of load. Also makes firewall rate-limiting unnecessary, which itself causes some load.
For really low powered boxes it matters, but, otherwise, bot login attempts will not work with any serious password, while, if someone is after you, no port will hide your SSH unless you disable it altogether or put it to listen on loopback only.
Using keys is good, if something is borked, you can always use the provider's console.
I change it to give me some breathing time to patch against any future zero days for OpenSSH.
Of course, using it as the only counter-measure would be pure 'security by obscurity'.
Why change SSH port? Why not use a sudo account and disable root login? Or just use root with pass auth disabled..