I recently set up
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.
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
$ 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
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
$ 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:
┌─[jay@hal]─(~) └─[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
# 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:
[ssh] 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:
[Definition] 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.
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:
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 https://raw.githubusercontent.com/gh2o/digitalocean-debian-to-arch/master/install7.sh && bash install7.sh
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.
Once the script finishes and the droplet reboots, log back in and let’s get Arch set up:
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.
It is considered best practice not to log in as root, but to use
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
$ 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.
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 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.
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.
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).
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.
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 …
So here’s what I have my home server set up to do: