Server Archives • Linux Tips

Prevent Brute-Force SSH Attacks With fail2ban

Today’s article is one I could have already written and it’s about how to prevent brute-force SSH attacks with fail2ban. The reason I haven’t written it yet is because it either has too much substance or too little substance. I think I can strike a middle-of-the-road here and write an article with just enough substance.

See, and we’ll get to this later in the article, most folks won’t need to do a whole lot more than just install it. You can configure it a great deal, but the defaults are just fine for most people. On top of that, you can even make fail2ban send you email reports but we won’t be covering that in this article. Instead, we’ll largely have directions for installing fail2ban so that you can “prevent” brute-force attacks via SSH. I put the “prevent” in quotes because a diligent attacker could time things, use varied IP addresses, and try brute forcing your login credentials.

I think we need to start at the beginning.

What is SSH:

SSH stands for “Secure Shell” and is a tool to connect to a server remotely. If you check the man page for SSH it is defined as:

ssh — OpenSSH remote login client

This allows you to connect two computers over the terminal. It also comes with SFTP so that you can securely transfer files. You can do a whole lot more with SSH, including forwarding the graphical environment.

Here are a few SSH articles:

Install SSH to Remotely Control Your Linux Computers
Check Your SSH Server Configuration
Show Failed SSH Login Attempts

Then, there are a whole lot more SSH articles. I love SSH, so there have been quite a few articles on the subject. It’s a tool that I use quite often. I encourage familiarity with SSH as it’s sometimes a useful tool to effect a repair on a computer that is otherwise unresponsive to local inputs.

Servers are typically managed with SSH. As you can imagine, servers are a juicy target for malicious people. This means that SSH is a means with which malicious people will use to attack servers. One of the ways they do that is with ‘brute-force’.

What is Brute-Force:

There are many ways that one can try brute-forcing something. The name is as it implies. Rather than knowing the login credentials, they try to brute force them. That means they’ll try one combination of username and password and then keep trying various combinations until they eventually crack the system and figure out the login information.

That is the goal. Their goal is to find the login credentials. Instead of finesse, they use brute force.

This can include a dictionary attack. This can include a progressive attack where they start at the letter a, then try aa, then try aaa, etc. until they find the login credentials. They may also have a list of commonly used usernames and passwords and will systemically work their way through this until they find their way in.

This is one of many attacks and a modern computer can make many attempts in a short amount of time. Add to this modern bandwidth speeds and you can get thousands of attacks in just a short amount of time. It goes even faster if they know one part of the data, such as the username of a privileged account.

Enter fail2ban:

If you’re using a major distro, you have fail2ban available, one way or another. It’s usually easily installed and in your default repositories. When you do install it, you can check the man page. However, fail2ban is described as:

fail2ban – a set of server and client programs to limit brute force authentication attempts.

So, as you can see, fail2ban is the correct tool for the job. After all, and as the headline suggests, we’re trying to prevent brute-force SSH attacks with fail2ban.

Installing fail2ban:

We’ll be using a terminal to install fail2ban. You may also need to remotely connect to the server on which you want to install fail2ban. That too will require a terminal (or some SSH application like PuTTY). Simply press CTRL + ALT and your default terminal should open. If not, you can open a terminal from your application menu.

With your terminal now open, we can install fail2ban.

Debian/Ubuntu/etc:

sudo apt install fail2ban

1	sudo apt install fail2ban

RHEL/CentOS/etc:

sudo yum install epel-release -y
sudo yum install fail2ban

1 2	sudo yum install epel-release -y sudo yum install fail2ban

Fedora with dnf:

dnf install fail2ban

1	dnf install fail2ban

I believe those are correct. That’s what is in my notes. If they’re not correct, please leave a comment and I’ll update the article. Other distros will have fail2ban available, just search your default repositories and you’ll likely find fail2ban available for installation.

Using fail2ban:

Now that you’ve installed fail2ban, you’re pretty much done. The default configuration is pretty much all you need – but you can customize it. There are a bunch of options available, so you can configure fail2ban in many ways. There are so many ways that we won’t be covering them. They’re reasonably obvious.

Once installed, fail2ban should start automatically. If it doesn’t, run this command to start it:

sudo systemctl start fail2ban

1	sudo systemctl start fail2ban

Next, we’ll make sure to enable fail2ban to start at boot time. That’s this command:

sudo systemctl enable fail2ban

1	sudo systemctl enable fail2ban

I assume that you’ll want to at least examine the configuration files and I’ll get you started with that. The first thing you want to do is cd to the right directory.

cd /etc/fail2ban/

1	cd /etc/fail2ban/

If you run ls you’ll see that there’s a file called jail.conf and you do not want to edit this file itself. Instead, fail2ban will look for configurations in a file called jail.local first. To make that file, you run the following command:

sudo cp jail.conf jail.local

Next, you might want to make a backup of that jail.local file.

sudo cp jail.local jail.local.backup

1	sudo cp jail.local jail.local.backup

You can now use Nano to edit your fail2ban configurations:

sudo nano jail.local

1	sudo nano jail.local

As you can now see, there are a bunch of options available. They’re far too many to explain here but they’re fairly well described. If any of the options confuse you, you can get help on the man page (man fail2ban ).

After you’ve set fail2ban’s configuration files the way you want them, you’ll need to restart the service for the changes to take effect. That’s done like this:

sudo systemctl restart fail2ban

1	sudo systemctl restart fail2ban

If you screw up the configuration, just remove the jail.local with this command:

sudo rm jail.local

1	sudo rm jail.local

Then restore from your backup like this:

sudo cp jail.local.backup jail.local

1	sudo cp jail.local.backup jail.local

Then, of course, restart the service with this command:

sudo systemctl restart fail2ban

1	sudo systemctl restart fail2ban

There are a lot of options with this application. You can explore them at your leisure, though I find the defaults to be adequate for most of my needs. As mentioned above, you can install sendmail and have the system send you notification emails. There are many other options as well.

Closure:

Like I said in the beginning, there’s a lot of substance with fail2ban. There’s a lot to it. If I added more to the article, it’d end up quite long. I may write a bit more about this application, but I don’t want to end up with a 2500-word article that will make your eyes gloss over. That doesn’t do me any good and it doesn’t do most people any good. Most folks are going to be fine with the basics before they explore the configuration options on their own.

If you do have a server (or even a personal computer) that’s running SSH, it’s worth your time to install fail2ban. If there’s any chance that someone can try to brute-force your system, they will.

Some bots crawl the ‘net looking for servers that respond on the default SSH ports. They can and will find you. You can also change the port SSH uses for some added obscurity (but remember that obscurity isn’t really security). So, it’s a good idea to prevent brute-force SSH attacks with fail2ban. Yes, it’s a good idea even for us ‘little guys’ who aren’t running servers with valuable information on them.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Smash a button!

[Total: 6 Average: 5]

How To: Boot An SSH User

Today’s article will be pretty simple, though it will have a limited scope, as we discuss how to boot an SSH user. The vast majority of my regular readers are ‘simple’ desktop users. This article shouldn’t apply to them; if it does, something may have gone terribly wrong.

I need to point out that if you’re doing this for security reasons, you’ve done something wrong – or you’re getting ready to fire someone and want to ensure any logged-in accounts have been disconnected.

What is this article about?

Well, let’s say you have a server and people are logged in via SSH. Let’s also say you want to disconnect one of them. That is, you want to boot an SSH user. If you want to boot an SSH user, it’s remarkably similar to sending that SSH user a message. You might want to read that article:

Send A Message To Another Logged In User

We’ll be using similar tools, though we’ll also be using tools from this article:

How To: Kill Processes By Their PID (Process ID)

I strongly suggest that you read both of the two links. That will save you some time and I’m going to gloss over some details because one of the great things about previous articles is that it means I don’t have to duplicate work. The onus is yours to read those articles so that you’re familiar with the subject.

In case you haven’t put two and two together, we’re going to boot an SSH user by killing their process ID (PID). It’s a lovely way to do so, perfectly graceful ideally, and will accomplish the goal of booting said SSH user.

This might be something you do when you take a privileged user down to HR to fire them. When they head to HR (and are then led out of the building by security), you can kill any processes they have ownership of, including any SSH sessions they have open. In this case, we’re just going to learn how to boot an SSH user.

So, put on your steel-toed boots ’cause we’re going to boot an SSH user!

(I do… I crack me up!)

Boot An SSH User:

You’re going to need an open terminal and you’re going to need to be connected to the same SSH server(s) as the user. As this is a bit of an advanced article, I’m going to assume you know what those things mean. If you don’t know what those things mean, you probably shouldn’t be operating a server, and definitely shouldn’t be operating a server that has multiple people connected to it.

If you remember (or clicked to read) the previous article, we are going to start with the ‘who’ command. You can simply try this command:

who -u

who -u

That has all the information you need and you’re looking for the PID as that’s what we’re going to be using to boot the SSH user. We’ll be killing their PID and logging them out immediately. You only need the first field to identify them by username and the sixth field to know the PID. So, you can just use this command:

who -u | awk '{print $1, $6}'

1	who -u \| awk '{print $1, $6}'

This will give you an output similar to this:

$ who -u | awk '{print $1, $6}'
kgiii 2253
test_user 174676

$ who -u | awk '{print $1, $6}'

kgiii 2253

test_user 174676

Using the first field to identify the user, you can see their PID. You can kill their process with the following command:

sudo kill -HUP <PID>

1	sudo kill -HUP <PID>

Or, for example:

sudo kill -HUP 174676

1	sudo kill -HUP 174676

If that doesn’t work, and sometimes a process can’t be killed, you can bring out the hammer and tell the kernel to drop the process. You should try the first way as it’s more graceful and using a hammer may result in a zombie process. But, if you want to bring out the hammer, you would use this command:

sudo kill -9 <PID>

1	sudo kill -9 <PID>

If the user is logged in more than once, you can boot the SSH user by adding the rest of their PIDs. You just simply add them to either of the two commands. For example:

sudo kill -HUP <PID> <PID> <PID>

1	sudo kill -HUP <PID> <PID> <PID>

And that’s how you boot multiple SSH users in one command.

Again, if you’re relying on this for security you’re doing it wrong. This should just be a part of the security process, such as when you’re letting someone go while they were still at their desk. You bring them to HR while security cleans their desk and IT make sure they’re logged out of any and every system. You then escort them out of the building.

Of course, there are probably other reasons why you might want to boot an SSH user. It’s your system, you can decide what to do. You shouldn’t be using this to boot an adversarial SSH connection because if it has reached that point you’re doing security very, very wrong.

Closure:

So, why not? We might as well have an article about how you boot an SSH user. It does not apply to much of my readership, but it’s certainly something worth knowing. It was also tied into a couple of earlier articles, including one from yesterday, so I figured I’d cover this subject while it was still fresh in my memory.

That memory ain’t what it once was! Welcome to old age!

Smash a button!

[Total: 2 Average: 5]

Geolocate A Website

Today’s article probably will be more about amusement than it is about education, as we learn to geolocate a website. This will not have a lot of uses for many of you, and the uses I can think of are a bit contrived. So, stand back and watch as we do some science!

Wait, no… No, there will be no science.

What I should have done is write this article ahead of time. Instead, it’s the 4th of July, and will probably be just about the 5th of July before I finish this. Let’s just all agree that I’ve been celebrating.

Anyhow, have you ever wanted to know where a website is located? Have you ever wanted to know where an IP address is located? Well, that’s what geolocation does and let me tell you that it is not excellent. No, it is not.

First, the tool we’ll be using is only going to give you the country. It doesn’t narrow it down very far.

Second, in the world of CDNs (Content Delivery Networks), a server may appear closer to you (or in this case the geolocation server) than it is.

Relying on this data for anything important is just plain silly.

But, you could log in to a remote server by name, get the local IP address, and then check the IP address to see what country the server is in. Yeah, see? I told you that any usefulness would be contrived.

Anyhow, you can geolocate by domain name or by IP address. With any luck, you’ll be able to tell which country the server is in. The previously mentioned caveats should make sure you know to not use these results for anything useful.

Geolocate A Website:

You could almost certainly find an online tool that would do a much better job. Installing software for this is not necessary, but that’s exactly what we’re going to do. So, press CTRL + ALT + T and let’s get this party started.

First, we need to install a piece of software called Geoip. It’s available for all the major distros and describes itself as:

geoiplookup – look up country using IP Address or hostname

To install the software, you’ll enter one of the following commands into your terminal of choice:

RHEL, CentOS, Fedora, etc:

sudo dnf install geoip

1	sudo dnf install geoip

Arch, EndeavourOS, Manjaro, etc:

sudo pacman -S geoip

1	sudo pacman -S geoip

Debian, Ubuntu, Mint, etc:

sudo apt install geoip-bin

1	sudo apt install geoip-bin

When you’re done with that, it’s pretty easy to use. If you want to geolocate a website, the format follows:

geoiplookup <domain_name>

1	geoiplookup <domain_name>

And, if you want to geolocate an IP address, the syntax is similar:

geoiplookup <ip_address>

1	geoiplookup <ip_address>

An example output follows:

kgiii@kgiii-laptop:~$ geoiplookup linux-tips.us
GeoIP Country Edition: US, United States

1 2	kgiii@kgiii-laptop:~$ geoiplookup linux-tips.us GeoIP Country Edition: US, United States

Which, you know, isn’t all that helpful. You can check the man page, but that’s also not all that helpful. To do that, it’s just this command:

man geoiplookup

1	man geoiplookup

The data isn’t entirely useless, for example, you can try this command:

kgiii@kgiii-laptop:~$ geoiplookup canada.ca
GeoIP Country Edition: CA, Canada

1 2	kgiii@kgiii-laptop:~$ geoiplookup canada.ca GeoIP Country Edition: CA, Canada

Which, as you can see, appears to accurately geolocate the domain name to Canada, which is where I’d expect the server to be.

Closure:

So, yeah… If you want to geolocate a website then you can more or less do so. You’ll not get a whole lot of useful information and there are better tools for this online, but it can be done. You can indeed geolocate a domain name or an IP address all from the comfort of your terminal.

Just, you know, don’t use this information for anything too important. I use MaxMind for this sort of stuff online. It’s useful for getting meaningful statistics regarding the site’s traffic and is much more accurate, but still not accurate enough to pinpoint a house or anything. It can usually narrow things down to the nearest city, which is more than enough for my needs.

Smash a button!

[Total: 1 Average: 5]

Disable Inactive SSH Sessions

Today’s article can be used by anyone that has started using SSH on their computers, as we learn to disable inactive SSH sessions. It’s not going to be a very complicated article. This is easy enough for anybody to do, and there aren’t too many ways to permanently mess things up.

What is SSH?

My regular readers will know that I’ve written quite a few articles about SSH. Basically, SSH stands for “Secure Shell” and is a tool you use to remotely control other devices through the terminal. The tool is ancient but still valuable. I use SSH regularly, and that’s not even counting the stuff I do online.

Indeed, I’ve written some SSH articles before:

Install SSH to Remotely Control Your Linux Computers
How To: Restart SSH
Show Failed SSH Login Attempts
(And many more.)

By default, your server/device may not close inactive or idle sessions. It will let you maintain your connection until you tell it to exit. This can be a security issue and it may be worth setting your SSH to disable inactive SSH services.

In this article, we’ll be using Nano and you’ll need to be able to use an SSH connection. If you don’t default to using Nano, you can install Nano or just use the default text editor that you’re more accustomed to. In theory, if you’re just practicing, you could set this up on your computer and then tell SSH to connect to ‘user@localhost’.

Disable Inactive SSH Sessions:

Up above I said, “SSH stands for “Secure Shell” and is a tool you use to remotely control other devices through the terminal.” If you were paying attention, you’d notice the last word is “terminal”. So, you’ll need an open terminal. For most distros, you can open a terminal easily, you press CTRL + ALT + T and you’re all good.

With your terminal now open, you’ll need to connect to the device that’s running the SSH server and enter the following command:

sudo nano /etc/ssh/ssh_config

1	sudo nano /etc/ssh/ssh_config

Next, you’ll add a couple of new lines. The syntax is straightforward and easy enough for anyone to understand. There’s a little bit of math, but you can do that math in your head. The syntax looks like this:

ClientAliveInterval <seconds>
ClientAliveCountMax <number_of_checks>

1 2	ClientAliveInterval <seconds> ClientAliveCountMax <number_of_checks>

The first entry is how long you want to wait to check for an idle connection.

The second entry is how many times you want (set by the first entry) to check for an idle connection.

For example, look at this:

ClientAliveInterval 300
ClientAliveCountMax 5

1 2	ClientAliveInterval 300 ClientAliveCountMax 5

With the above, it’d check for an idle state every 300 seconds (five minutes). It will perform this check 5 times. If the connection is idle for all of those checks, the system will disconnect the SSH user. That’s allowing for 25 minutes of idle time before disconnecting the inactive user. That seems reasonable to me.

You can set those values to anything you’d like, perhaps shorter for an open office and longer if you’re using your home computer and connected to your own devices. The math doesn’t change. It’s just the number of seconds between text multiplied by the number of times the system will perform those checks. If you regularly have many users connected via SSH, you can save some resources by disconnecting them after a reasonable period of inactivity.

As we edited this with Nano, you’ll need to save the file. To do that, you simply press CTRL + X, then Y, and then ENTER and Nano will save the ‘ssh_config’ file.

After you have saved the file, you’ll need to restart SSH for the changes to take effect. That’s easy enough. Assuming you’re using Systemd, you restart SSH with this command:

systemctl restart sshd

1	systemctl restart sshd

If you’re still using SysV, the command would be this:

service sshd restart

1	service sshd restart

(I don’t bother with that often, I just assume you’re using Systemd. After all, according to the stats I can get, most of us are in fact using distros that use Systemd.)

Closure:

So, if you want to disable inactive SSH sessions, you can use the above as a template. You’ll need to figure out how long you want to wait between checks and you’ll want to decide how many times you’re going to make those checks. It’s simple math that anyone can do. It’s also probably not a bad step to take if you’re dealing with something public or sensitive.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

Smash a button!

[Total: 2 Average: 5]

How To: Find Local Network Devices

Today’s article will be a bit of a weird one, as I share with you one way to find local network devices using the Linux terminal. I suppose network device discovery is typically seen as a dark art, something a malicious hacker might do, but it’s completely harmless (in and of itself). So, if you want to find local network devices, this article just might be for you!

What we’ll actually be doing is scanning a block of IP addresses to see what responds to our prodding. This is sometimes called IP Scanning or IP Sweeping. It’s also sometimes called Port Scanning, but we won’t be doing any real port scanning. I assure you, I am not secretly trying to turn you into a big bad hacker – but this is a pretty neat ‘hack’ (in the traditional sense of the word).

We will be learning just a single command (with a bit of explanation) with a single flag. It’s a very complicated tool and trying to cover it all would take a giant article or many smaller articles. You can guess which one we’re going to do!

The tool we’re going to use for this is called ‘nmap’. This is available in every major distro. It might be installed by default. It’s just the tool for the task at hand, so you need to install it before you can use it as this article will suggest. (I trust you to know how to do so at this point.)

Did you install nmap? If so, please continue. If not, read the last paragraph.

With nmap installed, you can check the man page to see that it’s described as:

nmap – Network exploration tool and security / port scanner

Now you’re ready…

Find Local Network Devices:

Picture this…

So, for some reason, one of my laptops has stopped answering on the .local domain when I want to connect to it with SSH. I have choices at this point. I could fire up Team Viewer and then connect to the laptop to find the IP address belonging to the said laptop. Another choice would be to get off my lazy butt and walk to the device, but that defeats the point of remotely controlling the device.

I suppose the best choice would be to just figure out why it’s stopped responding on the .local domain. Wouldn’t that be novel?

But, I have another tool! I have a tool that’s reasonably fast, very easy, and likely effective! That tool is, as suggested earlier, nmap.

The first thing I do is crack open a terminal to find my local IP address. That’s easy enough and the link will show you how to find your private (or local) IP address. Though it needn’t be private. Security by obscurity is not security – and it’s trivial to learn. But, that’s an article for another day.

I was able to quickly learn that my local IP address is 192.168.215.88. From this, I realize that the most common configuration will be for everyone to be on the same subnet and so my laptop likely falls within the 192.168.215.1 to 192.168.215.255 range.

We can use the asterisk to represent any of those numbers, as it’s a wildcard. This means the next command is obvious and will be simply:

nmap -sn 192.168.215.*

1	nmap -sn 192.168.215.*

The -sn flag would mean ‘do not do a port scan’, so it’s checking only for devices that return a ping. Make sense? (It’s a pretty speedy command when not also scanning ports.)

A Picture Of nmap:

I think that this is one of those instances where my text isn’t quite clear enough. So, what I’m going to do is show you a picture.

The nmap command I ran showed me a list of local network devices. As I already know the IP address of the device I’m using, I can exclude that from the list. The device I’m looking for (my laptop) is then a different IP address.

The process looks something like this (trimmed down to just have one device for simplicity’s sake):

using nmap to find local network devices — As I know my device’s IP address, I can exclude that from the list of possible IP addresses.

As you can see, I first tried to connect with the .local domain and found that it did not work. So, I ran the nmap command and used a wildcard to scan the entire IP address range (1 to 255).

Sure enough, the IP sweep with nmap found another device and showed the IP address. It showed the gateway, which I could also exclude. The process of elimination meant there was one IP address to try (it could have contained more devices). I tried to use SSH with that IP address and, sure enough, that’s my laptop!

See? I saved a trip across the room! I saved opening up a bulky application and waiting for it to do its thing before I could even try using it to connect to the laptop. In fact, I suppose I also saved the effort I could have spent just randomly guessing IP addresses and hoping I got the right one for my laptop eventually!

Closure:

I figure there’s a lesson in nmap in there somewhere. You never know when you’re going to need to find local network devices! Now, when you do need to do so you will know how.

I figured I’d try writing this one in a way that showed you how I benefit from knowing how to do this. I figured that it’d be interesting to show you how the command solves a real problem. There have been a few articles similar to this and they’re fun articles to write. They are articles that come from the real me, the me that is actively using and appreciating Linux (often in the terminal) in my day-to-day life.

Smash a button!

[Total: 4 Average: 5]