Preventing break-ins on your Linux system

No readers like this yet.
Can government agencies be innovative?

Opensource.com

All too often we hear about breaches in security where usernames and passwords were obtained and published online. Most of the time, what's revealed is that most passwords are very simple or iterative of a previous version (e.g., 12345 followed by 123456 on the next change). Implementing password requirements can help keep weak passwords out of your environment. These forced changes have their pros and cons, but when it comes down to it there are still flaws in authentication.

Managing password and security related issues in Linux is important, but there are some simple steps you can take to make your system more secure. Here is a look at a few options to consider. Let's look first at managing those passwords and accounts and then move on to just how often people are trying to access those accounts. Lastly, we'll cover some of the things we can do to limit those attempts.

Linux password management

Changing a user's password using the passwd command is pretty straightforward, but there's a lot more it can do. Did you know you can also use it to lock and unlock an account? What about passing in a password via stdin?

Change a password

passwd [username]

Change a password via stdin

echo “Some_STRONG_PASSWORD” | passwd —stdin root

Lock and unlock a password

passwd -l [username] passwd -u [username]

Files

When you work with passwords, both the /etc/passwd and /etc/shadow files are updated. The passwd file contains a lot of information, but ironically enough not the actual password hash. The hash is contained in the /etc/shadow file.

Why the /etc/shadow file?

In the early days, the hashed password was stored in the /etc/password file, but there was a problem—this file needed to be able to be read by everybody. Your password's hash being available to everybody is not a good thing. So the actual hash was moved to the /etc/shadow file, which is only readable by a privileged user.

How often are break-ins attempted?

Ever wonder how many times somebody has tried to log on to your publicly accessible server? The last command shows us the number of successful attempts. The lastb command shows us the number of unsuccessful attempts. As an example, my server has had 7,464 unsuccessful attempts in the past 12 hours.

Extra tip: The last and lastb commands write to the /var/log/wtmp and /var/log/btmp files, respectively. If you ever see these files zeroed out, you might have a problem.

What else can we do?

We've seen that there can be a large number of attempts to log on to a publicly accessible system. So, what can we do? There are a few things we can to do either limit or mitigate the number of attempts.

Change the port

The first thing we can do is change the port that SSH listens on. This can mitigate some of the attempts, but there are also tools like nmap that can scan for open ports.

Firewalls

Firewalls (iptables, UFC, and firewalld) are great. Their goal is to limit access to SSH to a smaller set of servers. The drawback is that you can, at times, lock yourself out if your IP changes or if you are attempting to log in from a new place.

Fail2Ban

Knowing what we know from the lastb command, we can look to tools like Fail2Ban to automatically block IPs after a certain number of unsuccessful attempts.

I hope this helps give some insight into passwords on your server and some direction in limiting attack vectors.

User profile image.
Alex Juarez is a Principal Engineer at Rackspace, touting 11 years with the company. Alex enjoys all things open-source as well as training and mentoring others, and is incredibly qualified to do so as an RHCA/RHCI. Alex has spoken at a number regional and nationwide open source conferences sharing knowledge and encouraging people to learn more.

14 Comments

Thanks for the great article. I have learned some good stuff from it. You also reminded me of the lastb command which I had completely forgotten.

I get far fewer hack attempts recorded by wtmp than you do, primarily because I use Fail2Ban on my firewalls. I have had as many as 300 or so IP addresses blocked by Fail2Ban at one time. Usually the number is more like a dozen or so, but attacks seem to come in waves.

Thanks again for sharing your expertise.

Great article! Network and machine security are just as important with Linux as any other system. With Linux gaining popularity with small businesses for server applications, it is still important that we take they extra steps in making sure that the likely hood of a breach is lessened.

Good tips. I take it a bit further and not only change the port, but I use something like fail2ban to monitor the logs and any IP that attempts to connect on port 22 get a complete ban for our subnet for 2 weeks. Keeps out most of the script-kiddies. So if you scan me with nmap as soon as you touch the normal SSH port you're gone.

Under What else can we do?, you never bothered to mentioned the knock daemon (knockd). This is absolutely the easiest way to stop attacks on your systems as the port isn't even open until you give the correct knock.

Also, nowhere on any of my servers will you find files or subdir containing passwd or user or home or admin (as in wp-admin) or several other words. So when someone http's to mysite.com/../../../../../../etc/passwd my 403.php adds their IP to my htaccess file with a deny from ...

99% of third party packages (ie. Zencart) install using the subdir "admin". I have to mv admin nancy then find all refs to "admin" and edit them - can be a real pain at times.

echo “Some_STRONG_PASSWORD” | passwd -stdin root

Never use this command. The cleartext password may be recorded in the shell's history file, and if echo isn't a built-in in your shell, the password could briefly be visible to other processes.

Ugh. Don't change the port. That's an operational nightmare as then you have to always configure everything that speaks ssh to use the new port. And from experience, those new ports get found anyway. What you want to do instead of changing the port is to require public key auth which removes the issue of passwords (and that's the real problem here) from the equation completely.

Nice article. I would also like to put out that changing a port (for ssh) should not be an end all for security. It can thwart the less intelligent automated scanners, but nowadays, these changes can be easily found out. You can confuse port scanners by adding a REJECT rule to your iptables for the port specified. This may confuse the scanner into thinking that the port being scanned is a closed and unused port.

Also, using the passwd command through stdin is not recommended for inputting in the command line. This may be stored in your shell's history file.

In my opinion, any public ssh server must have fail2ban.

I own several servers, witch are all day long under brute-force attempts. Without fail2ban, one day someone find de root pass. In near future I will definitly ban some ISP from china and russia because they are the source of 95% of that.

I would like to know if using keys for ssh is better for security, because if the key is stolen, it could be the same.

Banning single IP has it limits, because of the cloud: It's possible to automate the use of an temporary machine to scan, until it's banned, and use another machine, and so on.
The "Abuse" service in some cloud providers will have a lot of work...

One problem could come from IPv6, if it's not well managed. Sometimes it's activated by default without the fail2ban mecanism : dangerous.

I'm asking myself why fail2ban isn't integrated natively in sshd ?

in /etc/ssh/ssd_config

PermitRootLogin no
AllowUsers username1 username2

over 90% of brute force login attempts try root - remove it as an option

I am surprised that two-factor authentication is not mentioned. My home server can only be accessed from known IP addresses, does not allow a root login, only uses key-pair authentication and finally two factor authentication. That is a system that generates a six digit key every minute in a synchronized manner so only you can know it at any given moment. Search for "Google authenticator with Linux" for easy to follow instructions.

I use "fail2ban" extensively too.
I also have configured SSH to disallow all interactive authentication. In other words, if you don't have an SSH key, you don't get in.
All accounts that don't require a shell have their shell field set to /usr/sbin/nologin or /usr/bin/false.

Might be worth noting that /var/log/btmp is used for console login. If you're interested in failed ssh attempts to login you may want to look in the /var/log/auth.log file as that I believe is the default under Debian and Debian-like systems.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.