Table of Contents
Let’s login to our new machine and take some initial steps to secure our system. For this article I’m going to assume your username is
If you need to, setup your sudoers file by adding the following lines:
~/.ssh/authorized_keys and put your public key inside it. Make sure you can login without a password now once your key is in place.
/etc/ssh/sshd_config and make sure these lines exist to secure SSH:
1 2 3 4 5 6 7 8 9 10
Keep your current session open and restart sshd:
Make sure you can login from another terminal. If you can, move on.
Now we need to update and upgrade to make sure all of our packages are up to date and install two pre-requisites for later in the article: build-essential and ntp.
1 2 3 4
Setting up iptables and Fail2Ban
Open up the fail2ban config and change the ban time, destemail, and maxretry:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Now restart fail2ban.
If you try and login from another machine and fail, you should see the ip in iptables.
1 2 3 4 5
Here are my default iptables rules, it opens up port 80 and 443 for HTTP/HTTPS communication, and allows port 22. We also allow ping and then log all denied calls and then reject everything else. If you have other services you need to run, such as a game server or something else, you’ll have to add the rules to open up the ports in the iptables config.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
We can load that up into iptables:
Make sure it loads on boot by putting it into the if-up scripts:
Now make it executable:
Rebooting here is optional, I usually reboot after major changes to make sure everything boots up properly.
If you’re getting hit by scanners or brute-force attacks, you’ll see a line similar to this in your
Read only shared memory
A common exploit vector is going through shared memory (which can let you change the UID of running programs and other malicious actions). It can also be used as a place to drop files once an initial breakin has been made. An example of one such exploit is available here.
Once you do this you need to reboot.
Setting up Bastille Linux
The Bastille Hardening program “locks down” an operating system, proactively configuring the system for increased security and decreasing its susceptibility to compromise. Bastille can also assess a system’s current state of hardening, granularly reporting on each of the security settings with which it works.
1 2 3
After you run that command you’ll be prompted to configure your system, here are the options I chose:
- File permissions module: Yes (suid)
- Disable SUID for mount/umount: Yes
- Disable SUID on ping: Yes
- Disable clear-text r-protocols that use IP-based authentication? Yes
- Enforce password aging? No (situation dependent, I have no users accessing my machines except me, and I only allow ssh keys)
- Default umask: Yes
- Umask: 077
- Disable root login on tty’s 1-6: No
- Password protect GRUB prompt: No (situation dependent, I’m on a VPS and would like to get support in case I need it)
- Password protect su mode: Yes
- default-deny on tcp-wrappers and xinetd? No
- Ensure telnet doesn’t run? Yes
- Ensure FTP does not run? Yes
- display authorized use message? No (situation dependent, if you had other users, Yes)
- Put limits on system resource usage? Yes
- Restrict console access to group of users? Yes (then choose root)
- Add additional logging? Yes
- Setup remote logging if you have a remote log host, I don’t so I answered No
- Setup process accounting? Yes
- Disable acpid? Yes
- Deactivate nfs + samba? Yes (situation dependent)
- Stop sendmail from running in daemon mode? No (I have this firewalled off, so I’m not concerned)
- Deactivate apache? Yes
- Disable printing? Yes
- TMPDIR/TMP scripts? No (if a multi-user system, yes)
- Packet filtering script? No (we configured the firewall previously)
- Finished? YES! & reboot
You can verify some of these changes by testing them out, for instance, the SUID change on ping:
1 2 3 4 5 6 7 8 9
Since our machine isn’t running as a router and is going to be running as an application/web server, there are additional steps we can take to secure the machine. Many of these are from the NSA’s security guide, which you can read in its entirety here.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
After making these changes you should reboot.
Setting up a chroot environment
We’ll be setting up a chroot environment to run our web server and applications in. Chroot’s provide isolation from the rest of the operating system, so even in the event of a application compromise, damage can be mitigated.
Now add this to your
/etc/schroot/schroot.conf file, precise is the release of Ubuntu I’m using, so change it if you need to:
1 2 3 4 5 6 7
Now bootstrap the chroot with a minimal Ubuntu installation:
1 2 3 4 5 6
Add the following to
/etc/apt/sources.list inside the chroot:
1 2 3 4 5
Let’s test out our chroot and install nginx inside of it:
Securing nginx inside the chroot
First thing we will do is add a www user for nginx to run under:
1 2 3 4
/etc/nginx/nginx.conf and make sure you change user to www inside the chroot:
We can now start nginx inside the chroot:
Now if you go to http://your_vm_ip/ you should see “Welcome to nginx!” running inside your fancy new chroot.
We also need to setup ssh to run inside the chroot so we can deploy our applications more easily.
Since we already have SSH for the main host running on 22, we’re going to run SSH for the chroot on port 2222. We’ll copy over our config from outside the chroot to the chroot.
Now open the config and change the bind port to 2222.
We also need to add the rules to our firewall script:
Now make a startup script for chroot-precise in `/etc/init.d/chroot-precise:
1 2 3 4 5 6
Set it to executable and to start at boot:
Next is to put your public key inside the
.ssh/authorized_keys file for the www user inside the chroot so you can ssh and deploy your applications.
If you want, you can test your server and reboot it now to ensure nginx and ssh boot up properly. If it’s not running right now, you start it:
You should now be able to ssh into your chroot and main server without a password.
I would like to also mention the GRSecurity kernel patch. I had tried several times to install this (two different versions were released while I was writing this) and both make the kernel unable to compile. Hopefully they’ll fix these bugs and I’ll be able to update this article with notes on setting GRSecurity up as well.
I hope this article proved useful to anyone trying to secure a Ubuntu system, and if you liked it please share it!