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 itto 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 at 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 at 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/27/2017 02:02 PM, m.roth at 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/0398070792
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. -- Mark Haney Network Engineer at NeoNova 919-460-3330 option 1 mark.haney at neonova.net www.neonova.net
On Tue, November 28, 2017 9:21 am, Lamar Owen wrote:> On 11/27/2017 02:02 PM, m.roth at 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. Tarpitsare 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 variationsof 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 attackerout 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 copyof "OPEN IN THIRTY SECONDS" from Amazon [6].? That and the key> reference, Marc Weber Tobias' LSS (Locks, Safes, and Security [7]) arefascinating (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/0398070792 >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 28/11/17 06:02, m.roth at 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...