Set Up ufw and fail2ban on Arch Linux

June 25, 2015

I recently set up ufw and fail2ban on my Arch Linux home server. It’s fairly simple, but I found that most of the guides I followed left a few things out or didn’t quite work with Arch. There are lots firewall options for Arch, but I went with ufw, as I had recently set it up on my droplet, according to this guide: How To Setup a Firewall with UFW on an Ubuntu and Debian Cloud Server and enjoyed the simple syntax.

ufw: Uncomplicated Firewall

Uncomplicated Firewall serves as a simple front end to iptables and makes it easier to set up a firewall. It’s available in the Arch repos, so let’s start by installing it:

# pacman -S ufw

Now that it’s installed, let’s configure it:

$ sudo ufw enable
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

These commands will turn on ufw and deny all incoming and allow all outgoing traffic. These rules won’t take effect until you restart ufw, but to be safe, the first incoming traffic we’re going to allow is our sshd port. That way, we won’t accidentally lock ourselves out once we restart ufw

$ sudo ufw allow 2222/tcp

This assumes that your sshd listening port is 2222. It’s important to change the listening port from the default 22 to help discourage brute force attacks. Since you’re reading a guide on setting up ufw and fail2ban, you probably already have your sshd configured to be safer, but if not then read up on how to on the Arch wiki.

Now open up any other ports your server might need:

$ sudo ufw allow 4040/tcp
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

These commands opened up the ports for the Subsonic music streamer and for http/https for Owncloud. If you have other services that need special ports open, allow them in the same fashion as above. Now that we’ve got all of the ports open that you will need (and double checked that you opened your sshd listening port), let’s get ufw going.

$ sudo ufw disable
$ sudo ufw enable
$ sudo systemctl enable ufw.service
$ sudo ufw status

The first two commands will restart ufw. Then we enable it to start on boot using systemd. Finally, we check to see if all of our efforts have worked. If it did, you should see something like this:

└─[09:11]$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
4040/udp                   ALLOW       Anywhere


Fail2ban watches for incoming ssh requests and takes note of IPs that fail too many times to log in, and automatically bans them. This is a great way to stop trivial attacks, but doesn’t provide full protection. If you haven’t already, please set up SSH keys.

First, let’s install fail2ban:

# pacman -S fail2ban

Now we’ll need to create some custom rules and definitions for it, so it can play nice with ufw. Create a jail file for ssh: sudo nano /etc/fail2ban/jail.d/sshd.conf and insert the following:

enabled = true
banaction = ufw-ssh
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

Be sure to change the port number to whatever port sshd listens to on your machine. Save it and let’s move on. Create another file: sudo nano /etc/fail2ban/action.d/ufw-ssh.conf and insert the following:

actionstart =
actionstop =
actioncheck =
actionban = ufw insert 1 deny from  to any app OpenSSH
actionunban = ufw delete deny from  to any app OpenSSH

Now we simply start the service, enable it to load at boot, and check its status to make sure it’s working:

$ sudo systemctl start fail2ban
$ sudo systemctl enable fail2ban
$ sudo systemctl status fail2ban

And that’s it! We now have ufw protecting us with a firewall and fail2ban banning stupid script kiddies and bots from bugging us.


Convert a Debian 7 Digital Ocean Droplet into Arch Linux

June 10, 2015

I love Digital Ocean. It’s the cheapest, fastest, easiest way to get a Linux virtual server up and running. They’ve got a great interface too:

Hmm, something seems to be missing here ...

Hmm, something seems to be missing here …

There are some great choices here, no doubt, but where’s Arch Linux? Well, DO dropped their support for Arch Linux as it was apparently too difficult to support a rolling release for them. Fair enough, I guess, but but what about those of us who want Arch anyway? Experienced Arch users aren’t exactly the type to balk at a lack of official support though. Besides, who needs support when you’ve got the Arch Wiki?

I was content to stick with my Ubuntu and CentOS droplets, until I came across this github project: digitalocean-debian-to-arch. Basically, it’s a script that will turn a Debian 7 digital ocean droplet into a super lightweight Arch droplet.


Just spin up a new Debian 7 droplet (32 or 64 bit) and once you get it up and running, ssh in (or use Digital Ocean’s console access from their Web UI) and run the following command as root:

wget && bash

Answer yes when prompted and then just wait! In a few minutes you’ll have a fully up to date Arch Linux droplet.

Warning: Always be wary of running random commands you find on the internet. You can view their script here and see that it checks out. It worked great for me, but it’s best practice to be wary of this type of thing in general. There’s not much at stake here though, since you’re running it on a virtual machine you just created and can easily delete.

Set up your new Arch Linux Droplet

Once the script finishes and the droplet reboots, log back in and let’s get Arch set up:

Look at the RAM usage, a measly 24MB! Obviously that will change as we set up services, but for now this droplet is blazing fast.

Look at the RAM usage, a measly 24MB! Obviously that will change as we set up services, but for now this droplet is blazing fast.

A great place to start is the General Recommendations Arch wiki page. It is a must read for new users. For now though, let’s just do a few basics.

User Accounts

It is considered best practice not to log in as root, but to use su or sudo to perform necessary system tasks. Let’s create a new user, jay, and set a password for it:

# useradd -m -G wheel -s /bin/bash jay
# passwd jay

Now we need to grant our user sudo access:

# pacman -S sudo
# EDITOR=nano visudo

This will open the sudoers file, which lists which users and groups have sudo access. This command will open it in nano, but you could substitute your editor of choice or use the default vi. Scroll down to this line and uncomment it by removing the # at the beginning of the line:

%wheel      ALL=(ALL) ALL

This will let any members of the group wheel have sudo access. Hit ctrl-x and then y to save.

Now that we’ve got our user created, let’s create an authorized_keys file for our user. If you don’t know about ssh keys, then check the Arch wiki before proceeding: SSH keys. Once you have an ssh public key ready to go, then just add to your .ssh/authorized_keys file.

$ su - jay
$ mkdir .ssh
$ nano .ssh/authorized_keys

Paste in your public key here, and save it with ctrl+x, then y. Setting the correct file permissions is our next step:

$ chmod g-w /home/jay
$ chmod 700 /home/jay/.ssh
$ chmod 600 /home/jay/.ssh/authorized_keys

Now it’s time to lock down ssh and make it more secure.

$ sudo nano /etc/ssh/sshd_config

Open up the sshd config file and change Port 22 to some other number. Security through obfuscation, the default port is 22 and just by changing it to another number you can prevent a lot of automated attempts to gain access to your server. You should also set PermitRootLogin to no, PubkeyAuthentication to yes, and PasswordAuthentication to no. Ctrl + x, then y to save.

Where to go from here?

I’ve only just set this up today, so I haven’t really done anything other than what’s shown here. I’m very excited to start playing with it now. I might set up Owncloud and ditch my Ubuntu droplet. Or I could set up a VPN server that I could turn off and on whenever I’m stuck with an unsafe wifi connection. With Arch, there’s not much you can’t do. Whenever I find a use for this thing, I’ll do a post on it.

Arch Linux: The Ultimate Home Server Distro

June 9, 2015
Archey output on my home server, affectionately known as hal.

Archey output on my home server, affectionately known as hal.

Arch Linux may not be most people’s first choice for a home server, or even a workstation, but if you can get past the learning curve it’s one of the best options. After trying Ubuntu, Debian, Linux Mint, and Elementary on my HTPC/home server I finally settled on Arch Linux. Why? That’s what I’ll try to convince you of in this post.

The distros I listed are great and certainly have their uses, but for my needs they just couldn’t cut it. Yes, I realize that they are all basically Debian/Ubuntu derivatives and that I never tried OpenELEC, or say, PCLinuxOS, but after trying Ubuntu and friends I had learned enough about what I needed in an OS, to know that I needed Arch.


Arch Linux doesn’t come with much, just a small base system from which you can add whatever you want to create the ultimate, customized OS of your dreams. For beginner’s, this can seem daunting. The installer doesn’t even come with a GUI. If you have experience with Linux, then it’s not that bad. If you’re brand new to Linux, then Arch might not be for you. Then again, Arch was my first Linux experience and I survived it somehow (after 5-6 attempts to install it ;). It can seem a bit tedious to install things which are there by default on other OS’s, but you’ll learn a lot about Linux and your set up specifically. This way, if something breaks later you’ll have a better understanding of where to look to fix it.

One does not simply install arch linux correctly the first try ...

If you follow the Beginner’s Guide closely then your install should work just fine. Despite the above meme, it is definitely possible to install Arch Linux correctly the first time. If you simply don’t have the time for an Arch install, then check out Antegros. It’s basically Arch, but with some defaults already configured for you and a nice installer. You’ll end up with a full Arch system, but without all of the hassle.

The small base system may make set up a bit tedious, but it also means that when you’re done you’ll have an OS that is perfectly tailored to your needs. It will have only the packages you need and nothing you don’t.

Keep rollin’

With a rolling release, all of your software (including the core system components, like the Linux kernel) is updated shortly after upstream. This means that you will always have the latest and greatest improvements, security updates, and bug fixes. There is no need to upgrade to a newer version of the OS, because you’re always at the newest version of everything.

When your favorite software announces a new feature or security fix, you’ll get it right away


A rolling release? Stable?! I know, how can your system be stable when it’s always changing? It’s true, occasionally riding the bleeding edge can sometimes result in things breaking. But after using Ubuntu for a year and a half and Arch for 1, I spent way more time fixing Ubuntu than I ever have Arch.

 .--.                  Pacman v4.2.1 - libalpm v9.0.1
/ _.-' .-.  .-.  .-.   Copyright (C) 2006-2014 Pacman Development Team
\  '-. '-'  '-'  '-'   Copyright (C) 2002-2006 Judd Vinet

If you stay on top of your updates (at least weekly or every other week) and pay attention to what pacman says during those updates then you should be fine. It may just be anecdotal evidence on my part, but I have had so few problems using Arch compared to other distros. Pacman, Arch’s package manager, is amazing. It is easily my favorite out of all the distros I’ve tried (yum comes in second for me).

AUR you kidding me?

The Arch User Repository is, in a lot of ways, what makes Arch shine. The AUR contains packages not officially supported by Arch, submitted by users. It can seem a little shady running code from some random person on the internet, but each package has a comments section and if you’re unsure about something, the comments should clear it up. One should always be careful when installing unsupported software, but the same is true of PPAs or other similar systems.

The AUR has everything. Just about any software you might want to install is already there. With an AUR helper like packer or yaourt, it becomes extremely easy to install almost any Linux software you can think of.

Arch Wiki to the rescue

Back when I used Ubuntu and her derivatives, when something broke or I couldn’t quite understand the man pages, I turned to Google. Most issues I was having, had solutions on the Arch Wiki, which is what tops the results of Google searches about specific Linux packages. Hands down, the Arch wiki represents some of the best Linux documentation on the interwebs. And if you can’t find the solution to your problem there, then the forums are active and filled with people who know their stuff. Ubuntu forum members may be friendlier, but Arch forum members definitely are more knowledgeable. Sure, they can seem a bit ornery to newbies, but that only because you probably didn’t check the wiki or search the forums first …

My setup

So here’s what I have my home server set up to do: