Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Wow...
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.

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.

«13

Comments

  • J1021J1021 Member

    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...

    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.

  • rds100rds100 Member

    Welcome to the internet.

  • wheezywheezy Member
    edited June 2015

    Report it to GoDaddy not lowendtalk.

    Thanked by 2jar inthecloudblog
  • jarjar Patron Provider, Top Host, Veteran

    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.

    Thanked by 1inthecloudblog
  • J1021J1021 Member

    Jar said: Reporting to abuse@ the relevant service is the right thing to do

    Serious question: Do you report to abuse@ for each log entry you find?

  • jarjar Patron Provider, Top Host, Veteran

    @kcaj said:
    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.

    Thanked by 1perennate
  • TrafficTraffic Member
    edited June 2015

    kcaj said: Serious question: Do you report to abuse@ for each log entry you find?

    For production services, an automated approach is much better and efficient for sure. Wouldn't be hard to do it @Jar

  • @kcaj said:
    Thank you. I will keep a look out for this IP amongst the possible ~4 billion other addresses that could show up.

    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.

    Thanked by 2Gadelhas netomx
  • NekkiNekki Veteran

    @KwiceroLTD said:
    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.

  • @Nekki said:
    Racism.

    I don't have a problem with the colored IP's, I swear. The guy who made 'em simply burnt a few.

    Thanked by 2Mark_R netomx
  • NekkiNekki Veteran

    WTF?

  • LeeLee Veteran

    @Nekki said:
    Racism.

    Don't say it like it's wrong.

  • joepie91joepie91 Member, Patron Provider

    Set up an SSH key and disable password authentication. Problem solved.

    Thanked by 1netomx
  • KwiceroLTD said: @kcaj said: Thank you. I will keep a look out for this IP amongst the possible ~4 billion other addresses that could show up.

    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.

    Unplugging the Ethernet cable*

    Thanked by 1netomx
  • @Quinten said:

    How would you connect to it then? After all, in order to SSH the VPS, a internet connection is required :p

  • 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.

    Thanked by 1TheKiller
  • @mikeyur said:
    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.

  • joepie91joepie91 Member, Patron Provider

    @cnbeining said:
    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.

    Thanked by 3J1021 MCHPhil Chuck
  • ZappieZappie Member, Host Rep, LIR

    @joepie91 said:
    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.

  • FritzFritz Veteran

    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.

    Thanked by 2vimalware Chuck
  • @joepie91 said:
    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.

    At least save you some CPU usage. Also prevent some particular DDoS attacker from finding your real IP.

  • DillybobDillybob Member
    edited June 2015

    # 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.

  • tommytommy Member

    use ovh/online.net you'll surpise :D

    12586 failed login attempts since the last successful login

  • MaouniqueMaounique Host Rep, Veteran
    edited June 2015

    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.

    Thanked by 1vimalware
  • vimalwarevimalware Member
    edited June 2015

    @joepie91 said:
    Just leave it on 22.

    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'.

  • classyclassy Member

    Why change SSH port? Why not use a sudo account and disable root login? Or just use root with pass auth disabled..

Sign In or Register to comment.