Comments on: Five Easy Ways to Secure Your Linux System

By: voyance gratuite

voyance gratuite — Mon, 24 Jun 2013 11:35:45 +0000

Truly when someone doesn’t understand afterward its up to other users that they will help, so here it occurs.

By: Cameron

Cameron — Sat, 27 Apr 2013 09:17:21 +0000

Appreciating the persistence you put into your site and detailed information you provide.

It’s awesome to come across a blog every once in a while that isn’t the same
unwanted rehashed material. Excellent read! I’ve bookmarked your site and I’m including your RSS feeds to my
Google account.

By: Black Friday Security System

Black Friday Security System — Sun, 13 Nov 2011 21:08:30 +0000

Hi there, I found your blog by the use of Google even as looking for a comparable topic, your website came up, it appears great. I have bookmarked it in my google bookmarks.

By: bouhg

bouhg — Tue, 08 Nov 2011 07:04:22 +0000

Good riddance to Flash. wood chipper I am sick and tired to google web sites that tell, me how to install Flash Player on my Distribution X or Y.

By: grdetil

grdetil — Wed, 30 Nov -0001 00:00:00 +0000

\”On multiuser systems, you should restrict cron and at to root only.\” You don\’t elaborate on the reason for this, as though the security risk in allowing non-root users access to cron or at is common knowledge. This is news to me. Could you provide more info or a relevant reference?

By: dragonwisard

dragonwisard — Wed, 30 Nov -0001 00:00:00 +0000

I think he\'s going for the \"disabled by default\" approach. Although cron and at are relatively mundane to make such a fuss about. If a user even knows they exist, they probably meet the criteria for \"based upon the user’s knowledge and responsibility levels.\"

If you allow long-running background process (screen) they can achieve the same results with some trivial shell coding.

By: sandholm

sandholm — Wed, 30 Nov -0001 00:00:00 +0000

I don\’t agree with the root ssh lockout suggestion. During a crisis situation you need to be able to get into a system as root very quickly. Support can\’t fumble around with su & looking up passwords for the root account. We manage a medium sized data center (approx 150 to 200 systems), and have exchanged root public keys from the bastion to all the remote systems. To improve security and reduce risk, we use the /etc/security/access.conf file and limit root ssh login to just a couple of machines; only systems the support staff have access to (the bastion). Our current monitoring scripts rely on remote root access, and by locking out root ssh, that would break all our monitoring. It\’s not perfect, but to manage a few hundred systems in batch, it\’s necessary.

By: jpforte

jpforte — Wed, 30 Nov -0001 00:00:00 +0000

Ha Ha, three strike. I had a junior admin who tried that once. We just kept trying to login to his account until it locked for days. Then he decided that 99 was a better number. A DOS attack on a system could be done by just attempting logins a few times.

By: khess

khess — Wed, 30 Nov -0001 00:00:00 +0000

If you work in a large environment, like I do (thousands of servers), account lockout after 6 tries and no root SSH is the norm. So is disabled CRON and AT for normal users.

By: ffej01

ffej01 — Wed, 30 Nov -0001 00:00:00 +0000

I left my ssh port open for just a few days, to see what traffic I would get...what a mistake !!! 84 pages of security log in violations recorded. Most were from China, Brazil, and Hungary....Oh and a middle school in Japan. It was amazing to see the user names that they tried.

I use Denyhost since then, and think that my server is bored now. hehehehe.

By: jobst

jobst — Wed, 30 Nov -0001 00:00:00 +0000

Saying \”don\’t login as root\” is silly and useless paranoid. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased the chance an attacker would see the root pw, and decreased the chance you got spoofed as to your telnet host target. You\’d get your password spoofed but not root\’s pw. Gimme a break …. this is 2010 – We have ssh 4.8, used properly it\’s secure. Used improperly NONE of the OTHER security settings of the machine will make a damn bit of difference.
Use \”Protocol 2\”, \”AllowUsers root blah1 blah2\”, \”ClientAliveInterval 300\”, \”IgnoreRhosts yes\”, \”HostbasedAuthentication no\”, use TCPWRAPPERS, use Public Key Based Authentication ONLY, \”PermitEmptyPasswords no\”, limit access from a small range of IP addresses ONLY and a few more things and ssh is secure and you can enjoy simple access to other machines and do your job, simply.
I do not want to create another \”windows X\” environment where it is difficult to do things quickly … using ssh properly I can even be ssh\’ed into a machine, do a \”yum update sshd\”, then initiate a delayed \”sshd restart\”, logout, wait a bit and login again and run the latest ssh version on a machine that is 2000km away!

By: wrdieter

wrdieter — Wed, 30 Nov -0001 00:00:00 +0000

On blocking out users after three bad login attempts, I have to agree with jpforte that it is a great way for someone to launch a denial of service attack. DenyHosts is a better alternative because only the attacking IP is blocked. There are definitely people out there probing. At last count my /etc/hosts.deny had 883 hosts, all put there by DenyHosts.

On root logins, I prefer to disallow root ssh logins if only for audit purposes when more than one person needs to have root privileges. If someone logs in directly as root you have no idea who it was. If someone logs in as a regular user then does su or sudo, you know who it was (or at least whose remote account has been compromised). The audit is not always because you suspect someone of being malicious. It can help recover from mistakes, too.