[arm-allstar] General Internet Security --was: General Observation

[dan at ozment.net]

Well said, David.  I agree 100%.  I also have experience with some of 
the ne'er do wells and actually had a successful attack cost me a fair 
chunk of money one time.  Fail2ban is a great tool but may not be the 
easiest thing in the world.  And, as you said, it can be resource 
intensive.  Best solution for nodes is to keep them off of the internet. 
  Don't allow access via SSH from the internet.  Still, I always shut 
down root login just to remove that one, known user account from their 
hands.



On 2017-05-17 13:48, David McGough wrote:
> Hi Dan,
> 
> Where sudo really wins is on a multiuser Linux box where you have 
> multiple
> people who need to do various "root" activities and in this case 
> managing
> a single root password becomes a chore....What frequently ends up
> happening is the root password doesn't get changed very frequently, 
> since
> many people must be informed, etc. Another side effect is that there 
> isn't
> nearly as clear a root access trail--sudo actions can be logged 
> remotely,
> so if a compromise occurred, the user where the problem happened can be
> clearly found.
> 
> In a scenario where sudo gives the single non-privileged user full
> access, those benefits are diminished. And, as a negative side effect,
> sudo adds an order-of-magnitude more complexity for Linux users who 
> lack
> administration experience.
> 
> I could send you megabytes of logs showing various creative attacks
> against SSH which happen constantly on any major Internet host! ...And, 
> if
> I didn't have fail2bin installed, my "big box" server logs would be
> scrolling with attacks faster than you could read them, right this 
> minute.
> As an example, I just looked on one of my public-facing servers and see
> more than 400 banned hosts, 27 were banned since I started writing this
> message! Also, in the last two hours, one of my server logs show 1345
> unique, invalid usernames attempted, including root!!!  SCARY!
> 
> BTW, the hamvoip V1.5 release includes all the tools to setup sudo,
> non-privileged users, etc. I encourage experienced Linux admins to
> implement whatever security policies they consider desirable.
> 
> The best policy is never to allow a would-be attacker any means to
> directly reach a service (like ssh) to try and hack on.
> 
> 
> 73, David KB4FXC
> 
> 
> On Wed, 17 May 2017, "Dan Ozment via arm-allstar" wrote:
> 
>> Really good discussion in this thread.
>> 
>> If I can I would like to offer another thought to the "run as root" 
>> part
>> of it.  When I set up linux machines I normally disallow root login
>> after creating a non-root account. I allow my non-root account to use
>> sudo to run apps and even (sometimes) "sudo to root".  From what I've
>> seen a lot of the bots that are trying to compromise these systems 
>> first
>> start with attacking the root user account.  If root cannot log in 
>> they
>> won't get far.  With root login disabled you have to first guess the
>> user account, then you have to guess the password.
>> 
>> If the set up script could have the user create a personal user 
>> account,
>> give that account sudo access, and disable root login in sshd.conf I
>> think it would lock the nodes down a little better.
>> 
>> ...my 1.25 cents!
>> 
>> 73
>> Dan
>> W4DTO
>> _______________________________________________
>> 
>> arm-allstar mailing list
>> arm-allstar at hamvoip.org
>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>> 
>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>