Failed Attempts

Home » CentOS » Failed Attempts
CentOS 19 Comments

hi All,

I happened to login to one of my servers today and saw 96000 failed login attempts. shown below is the address its coming from. I added it to my firewall to drop.

Failed password for root from 123.183.209.135 port 14299 ssh2

FYI – others might be seeing it also.

Jerry

19 thoughts on - Failed Attempts

  • I can confirm that this IP had been actively and repeatedly hitting honeypots in the community honeypot network I’m a part of.

  • It happens all the time on all UNIX and Linux machines during last over 2
    decades. This is why some of us, sysadmins, use various ways to protect our users (we all realize that out of 100 users there always are at least
    5 who have very weak passwords and whose passwords can be cracked in brute force attack like that). Some of the tools are: fail2ban, sshguard. The last one I use on my FreeBSD servers. On Linux workstations I usually use just firewall rule that restricts similar attempts to some number. And I
    run server under assumption that bad guys are already in. Which (in addition to other security measures) means: update, update, update…

    Good luck! Use strong passwords (passphrase I call it when I talk to my users), especially for root account.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • As others have said, it’s normal: dictionary based brute forcing of root; and no surprise that that IP is based in China. Welcome to the Internet.

    Primarily you need to make sure your root password is strong so it isn’t vulnerable to this sort of attack. If it is, then the most nasty thing about this sort of thing is that your logs fill up.

    For your sanity then you can do the following:

    – disallow SSH root logins by password (login as an unprivileged user or use keys)

    – run something like fail2ban which will block a host for a predetermined amount of time after a number of failures.

    – don’t run SSH on 22, use a different port. (Things get a lot quieter when you do that, but it comes with it’s own problems and don’t get complacent because someone will find the port eventually.)

    – if you only have a limited number of hosts or subnets logging in to your machine, adjust the firewall so that only they are allowed through.

    P.

  • And if you’re really security conscious consider using port knocking (knock server – amazingly easy to set up. Or use fwknop, a little more difficult to set up but not much. Finally, for the hard core who really like pain – write the iptables rules yourself).

    —– Original Message —

  • Here is quite trivial (but effective!) one:

    :SSHSCAN – [0:0]

    ….

    -A INPUT -p tcp –dport 22 -m state –state NEW -j SSHSCAN
    -A SSHSCAN -m recent –set –name SSH
    -A SSHSCAN -m recent –update –seconds 300 –hitcount 10 –name SSH -j DROP
    -A INPUT -p tcp –dport 22 -j ACCEPT

    ….

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Pete Biggs wrote:
    to my

    As opposed to, say, Brazil (yes, for some reason, a lot hit us from there).

    If you’re not doing the above, you should start doing that… about 10
    years ago. Disallow root login except via keys this very minute, and do it everywhere.

    We’ve been running fail2ban at work for a good bunch of years, and I run it at home. It’s good, and std. repo.

    I consider that pointless security-through-obscurity.

    Yep. And iptables rules are not that big a deal to write.

    mark

  • 22 open to the world.  All the linux boxes I have internet accessible have a couple of things setup to prevent a lot of that:

    Lock down SSH to accept only login requests from one IP (or a range, but I prefer a single IP most of the time if I can manage it). Use a non-standard SSH port (and not a variation like 2222 or some such, just make sure you remember what it is). Fail2ban is your friend.

    Seriously though, Fail2Ban is simply amazing.  It will block IPs using IPtables without needing to write your own rules.  Will email you a log if you like.  And will generally help you sleep better at night.  I’ve got a couple of web servers that I have running Fail2Ban with a maximum of 3 failed logins and once that’s reached, the IP is blocked for a week.  An hour just won’t cut it nowadays, IMHO.  It’s pretty trivial to setup and uses very little in resources.


    Mark Haney Network Engineer at NeoNova
    919-460-3330 option 1
    mark.haney@neonova.net http://www.neonova.net

  • (In addition to what others mentioned) I see a lot originating from Russia, Romania, India, Japan. (one might be surprised about the Japan, but I figure, they do not use much of professional sysadmins, as people on average are very smart there… hence the net result ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • All ports above 1023 on UNIX and Linux systems can be opened by regular user, without requiring root access to the machine. Therefore, this always was considered potential security risk.

    One more comment about obscuring SSH service by running it on non-standard port (e.g. any port but 22). In my book this constitutes “security by obscurity”, which all my sysadmin colleagues were considering “windows –
    like” way of dealing with problems. (Think about pushing the trash on the floor under carpet).

    Exactly. And some other measures already mentioned in this thread
    (sshguard, iptables rulesets, …)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • That wasn’t meant as a “security” thing – that’s why it was under the heading “For your sanity …”. All these things do is to make it so that your machine is no longer the low-hanging-fruit!

    P.

  • Hi Valeri,

    if possible: Do not use passwords at all. Disable password login, and replace by SSH private/public key authentication, and, again if possible, with OTP (two factor authentication) on top.

    All the other hints (disallow root access via SSH, use strong passwords, port knocking, different ports etc.) just put the hurdle a bit higher but do not solve the underlying problem: Password authentication is weak by design, as it relies on the well-behaviour of users. Don’t restrict their passwords and they’ll use simple ore easily-guessible ones. Restrict them and they will write them down.

    Cheers,

    Pete.

  • Security through obscurity it may be, but it isn’t pointless. Tarpits are in a similar class; they don’t help with security in the absolute sense, but they slow the attacker down, and that might be enough to prevent the attack from continuing.

  • Pointless? I think not. Using (and locking down, which is implicit in my post) a non-standard port isn’t pointless. I dare say, it’s as valid as using fail2ban or iptables.

    Let me ask, since you’re against pointless changes, do you also advertise the SSHd version you’re running on your standard port? If not, isn’t that the same thing? Besides, the idea is to /not be low hanging fruit/, is it not?

    The idea is to make the system as secure as possible. Security is something everyone should take seriously, and sometimes hiding the padlock is probably a better deterrent than just having it in plain sight. The harder you make it for someone to attack you, the better off you will be.

    Scoff if you will, I’ve been at this 20 years, I’d rather OVER secure than under if the circumstances require it.

  • are in a similar class; they don’t help with security in the absolute sense, but they slow the attacker down, and that might be enough to prevent the attack from continuing.

  • There’s the old saying to the effect that if you’re a gazelle being chased by a lion, you don’t have to be the fastest in the herd, just faster than the one running next to you. ;)


    Scott Robbins PGP keyID EB3467D6
    ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
    gpg –keyserver pgp.mit.edu –recv-keys EB3467D6

  • You’re welcome.

    The best way to make an unpickable lock is to make the tolerances of the pins and the cylinder bore as tight as possible, since picking relies on part tolerances to work.

  • Lamar Owen wrote:

    Whenever I get a CAT scan, I point out to the techs that half the warning label is missing: all I see is “Do not start into laser”, and not the rest that reads “with remaining eye”.

    Don’t mind me: I just spent *far* too long doing my “mid-year performance checkin” for my employer, in Workday (the sooner that dies, the better), and it was designed by idiots, and is not suitable for what 90% of the company does…. And I’m *really* aggravated.

    mark

  • On 11/28/2017 11:04 AM, Valeri Galtsev wrote:> I was always unimpressed with> persistence of attempts to make more secure (less pickable) cylinder cased> locks (precision, multi-level, pins at a weird locations/angles). Whereas> there exists “disk based design” (should I say Abloy?), which with my> knowledge of mechanics I can not figure the way to pick. So I consider> them un-pickable. Why aren’t they widely used [in US]? Because there may> be the reason for powers there be to have locks everywhere pickable. On> the other hand, I do not have Abloy locks, as they do keep records that> link my particular lock to key that opens it. So, there is viable vector> of attack ;-)
    A quick YouTube search for “abloy lock picking” might change your opinion. It takes a special tool, but those are available and not all that hard to make.

  • I actually have SSH running on port 22 – however, I stipulate a different port in a PREROUTING/DNAT rule for external access for those hotels that block VPN access (yes, there are still some out there).

LEAVE A COMMENT