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
I can confirm that this IP had been actively and repeatedly hitting honeypots in the community honeypot network I'm a part of.
On Mon, Nov 27, 2017 at 11:10 AM, Jerry Geis jerry.geis@gmail.com wrote:
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 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Mon, November 27, 2017 11:10 am, Jerry Geis wrote:
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.
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
Jerry _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Hi Valeri,
Good luck! Use strong passwords (passphrase I call it when I talk to my users), especially for root account.
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.
On Mon, 2017-11-27 at 12:10 -0500, Jerry Geis wrote:
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.
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 ----- From: "Pete Biggs" pete@biggs.org.uk To: "centos" centos@centos.org Sent: Monday, November 27, 2017 11:53:30 AM Subject: Re: [CentOS] Failed attempts
On Mon, 2017-11-27 at 12:10 -0500, Jerry Geis wrote:
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.
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.
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Mon, November 27, 2017 12:13 pm, Leroy Tennison wrote:
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).
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
----- Original Message ----- From: "Pete Biggs" pete@biggs.org.uk To: "centos" centos@centos.org Sent: Monday, November 27, 2017 11:53:30 AM Subject: Re: [CentOS] Failed attempts
On Mon, 2017-11-27 at 12:10 -0500, Jerry Geis wrote:
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.
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.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ 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:
On Mon, 2017-11-27 at 12:10 -0500, Jerry Geis wrote:
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.
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.
As opposed to, say, Brazil (yes, for some reason, a lot hit us from there).
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)
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.
- run something like fail2ban which will block a host for a
predetermined amount of time after a number of failures.
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.
- 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.)
I consider that pointless security-through-obscurity.
- 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.
Yep. And iptables rules are not that big a deal to write.
mark
On Mon, November 27, 2017 1:02 pm, m.roth@5-cent.us wrote:
Pete Biggs wrote:
On Mon, 2017-11-27 at 12:10 -0500, Jerry Geis wrote:
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.
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.
As opposed to, say, Brazil (yes, for some reason, a lot hit us from there).
(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
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)
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.
- run something like fail2ban which will block a host for a
predetermined amount of time after a number of failures.
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.
- 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.)
I consider that pointless security-through-obscurity.
- 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.
Yep. And iptables rules are not that big a deal to write.
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
- 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.)
I consider that pointless security-through-obscurity.
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.
On 11/28/2017 04:09 AM, Pete Biggs wrote:
- 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.)
I consider that pointless security-through-obscurity.
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!
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.
On 11/27/2017 02:02 PM, m.roth@5-cent.us wrote:
Pete Biggs wrote:
- don't run ssh on 22, use a different port.
I consider that pointless security-through-obscurity.
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. (that is, put a tarpit on port 22 and run the real ssh elsewhere!) Any and all stumblingblocks you can put in the attacker's way, whether they're 'real' security or not, are worth at least looking at and evaluating their usefulness. Port knocking is an extreme form of security through obscurity, in reality, and falls into this class of tools. Likewise fail2ban; all it really does is slow down the attacker.
No, obscurity-increasing tools will not stop the determined attacker, but, it is very true that these sorts of measures can and do increase the signal-to-noise ratio in your logs; what does get logged will likely be much more useful and indicative of a more determined attacker. Anything that substantially increases the log's signal to noise is useful and not pointless, in my opinion. Anything that slows down the attack is even more useful.
I actually have training as a locksmith, with a specialty in masterkeying systems like rotating-constant and some obscure variations of RCM (this is one of the two masterkey systems explored in the infamous (in locksmith circles) paper "Cryptology and Physical Security: Rights Amplification in Master-Keyed Mechanical Locks" by Matt Blaze [1] [2]).
In physical security all security is, in reality, through obscurity [3] (page 2, first paragraph): things like keeping the drill points secret (example: in a pin-tumbler lock, if you can drill the shear line, you are in; but what if you have extra pins and hidden shear lines?), keeping secret what materials are used for the hardplate and their interactions with commonly-available drill-bit materials [4], having a strategically placed and hidden tear gas vial [5], etc (all of this information is publicly available; I'm not spilling any real locksmith secrets here).
The real key to effective physical security is not keeping the attacker out in an absolute, 'can't possibly break in' sense, but buying time for response to the attack; as the attack continues to eat time, the attacker will have increasing incentive to leave the premises.
Now, if you want a real eye-opener about physical security, grab a copy of "OPEN IN THIRTY SECONDS" from Amazon [6]. That and the key reference, Marc Weber Tobias' LSS (Locks, Safes, and Security [7]) are fascinating (if expensive) reading and great resources for the syadmin who wants to dig into what is really meant by a security mindset.
[1]: http://www.crypto.com/papers/mk.pdf [2]: http://www.crypto.com/masterkey.html [3]: http://www.crypto.com/papers/safelocks.pdf [4]: https://reassembler.wordpress.com/2008/02/04/drilling-into-a-modern-safe/ [5]: http://www.lockpicking101.com/viewtopic.php?f=8&t=16891 [6]: https://www.amazon.com/OPEN-THIRTY-SECONDS-Cracking-America/dp/0975947923 [7]: https://www.amazon.com/Locks-Safes-Security-International-Reference/dp/03980...
On Tue, November 28, 2017 9:21 am, Lamar Owen wrote:
On 11/27/2017 02:02 PM, m.roth@5-cent.us wrote:
Pete Biggs wrote:
- don't run ssh on 22, use a different port.
I consider that pointless security-through-obscurity.
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. (that is, put a tarpit on port 22 and run the real ssh elsewhere!) Any and all stumblingblocks you can put in the attacker's way, whether they're 'real' security or not, are worth at least looking at and evaluating their usefulness. Port knocking is an extreme form of security through obscurity, in reality, and falls into this class of tools. Likewise fail2ban; all it really does is slow down the attacker.
No, obscurity-increasing tools will not stop the determined attacker,
but, it is very true that these sorts of measures can and do increase the signal-to-noise ratio in your logs; what does get logged will likely be much more useful and indicative of a more determined attacker. Anything that substantially increases the log's signal to noise is useful and not pointless, in my opinion. Anything that slows down the attack is even more useful.
I actually have training as a locksmith, with a specialty in masterkeying systems like rotating-constant and some obscure variations
of RCM (this is one of the two masterkey systems explored in the infamous (in locksmith circles) paper "Cryptology and Physical Security: Rights Amplification in Master-Keyed Mechanical Locks" by Matt Blaze [1] [2]).
In physical security all security is, in reality, through obscurity [3]
(page 2, first paragraph): things like keeping the drill points secret (example: in a pin-tumbler lock, if you can drill the shear line, you are in; but what if you have extra pins and hidden shear lines?), keeping secret what materials are used for the hardplate and their interactions with commonly-available drill-bit materials [4], having a strategically placed and hidden tear gas vial [5], etc (all of this information is publicly available; I'm not spilling any real locksmith secrets here).
The real key to effective physical security is not keeping the attacker
out in an absolute, 'can't possibly break in' sense, but buying time for response to the attack; as the attack continues to eat time, the attacker will have increasing incentive to leave the premises.
Now, if you want a real eye-opener about physical security, grab a copy
of "OPEN IN THIRTY SECONDS" from Amazon [6]. That and the key
reference, Marc Weber Tobias' LSS (Locks, Safes, and Security [7]) are
fascinating (if expensive) reading and great resources for the syadmin who wants to dig into what is really meant by a security mindset.
[5]: http://www.lockpicking101.com/viewtopic.php?f=8&t=16891
[7]:
https://www.amazon.com/Locks-Safes-Security-International-Reference/dp/03980...
Thanks, Lamar! that is very instructive.
Physical security [of the machine] was first point in the security list, which we often fail to mention.
I like the [physical] lock intro you gave. 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 ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, Nov 28, 2017 at 11:04:14AM -0600, Valeri Galtsev wrote:
On Tue, November 28, 2017 9:21 am, Lamar Owen wrote:
On 11/27/2017 02:02 PM, m.roth@5-cent.us wrote:
Pete Biggs wrote:
- don't run ssh on 22, use a different port.
I consider that pointless security-through-obscurity.
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.
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. ;)
On 11/28/2017 12:04 PM, Valeri Galtsev wrote:
Thanks, Lamar! that is very instructive.
You're welcome.
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).
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. But several sidebar designs are out there that are pretty hard to pick, including Schlage Primus, the various Medeco styles, and others, such as the Kaba dimple locks used on Cisco Metro 1500 DWDM gear for power switches (the lasers are powerful enough to permanently damage your eyes in short order in those).
Whereas there exists "disk based design" (should I say Abloy?), ...
I had an old Bell System payphone with Abloy locks. Very difficult to bypass or pick, and requiring very different techniques than are used with pin-tumbler locks. There were two locks: one on the coin door (activated four large rectangular bolts, one on each side, with the only common point that could be successfully drilled being the lock cylinder itself), and one on the door to the circuitry (which included the programming port to set the per-call rate for use with a standard subscriber line, instead of the dedicated pay lines, as well as the coin-counter electronics). They were used on many payphones twenty years ago or so.
Lamar Owen wrote:
On 11/28/2017 12:04 PM, Valeri Galtsev wrote:
Thanks, Lamar! that is very instructive.
You're welcome.
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).
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. But several sidebar designs are out there that are pretty hard to pick, including Schlage Primus, the various Medeco styles, and others, such as the Kaba dimple locks used on Cisco Metro 1500 DWDM gear for power switches (the lasers are powerful enough to permanently damage your eyes in short order in those).
<snip> 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 Tue, Nov 28, 2017 at 03:52:36PM -0500, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 11/28/2017 12:04 PM, Valeri Galtsev wrote:
Thanks, Lamar! that is very instructive.
You're welcome.
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).
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. But several sidebar designs are out there that are pretty hard to pick, including Schlage Primus, the various Medeco styles, and others, such as the Kaba dimple locks used on Cisco Metro 1500 DWDM gear for power switches (the lasers are powerful enough to permanently damage your eyes in short order in those).
<snip> 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.
Hah! I'm now being forced to use it to record my hours. And I thought I hated the abomination at elabor.com!
I may retire sooner because of it.
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.
On 28/11/17 06:02, m.roth@5-cent.us wrote:
Pete Biggs wrote:
On Mon, 2017-11-27 at 12:10 -0500, Jerry Geis wrote:
- 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.)
I consider that pointless security-through-obscurity.
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). Internal users need not change their habits. In addition, this helps keep my logs clean...
On 11/27/2017 12:10 PM, Jerry Geis wrote:
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.
You're going to see this probably quite a lot on a server that has port 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.
On Mon, November 27, 2017 1:22 pm, Mark Haney wrote:
On 11/27/2017 12:10 PM, Jerry Geis wrote:
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.
You're going to see this probably quite a lot on a server that has port 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
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).
or some such, just make sure you remember what it is). Fail2ban is your friend.
Seriously though, Fail2Ban is simply amazing.
Exactly. And some other measures already mentioned in this thread (sshguard, iptables rulesets, ...)
Valeri
 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 www.neonova.net
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
-
Anthony K -
Fred Smith -
Jerry Geis -
Jon Pruente -
Lamar Owen -
Leroy Tennison -
m.roth＠5-cent.us -
Mark Haney -
Pete Biggs -
Peter Eckel -
Robert Nichols -
Scott Robbins -
Valeri Galtsev