Tag: linux

bookmark_borderNotes to Self for Future Debian Installation

Posted on by Yari

It hurt my heart to see my old PC gathering dust in my parent’s closet so I decided it would be good idea to turn it into a Linux workstation because my main PC has become clunky after installing new software for work. I know very little about Linux but I enjoy a challenge and tinkering with things. Plus, running a VM with Oracle VirtualBox gets old once you actually really start working. I know I could have started with a more user friendly OS like Ubuntu but I wanted to play around with an OS I would more likely encounter in a professional space. I’m also lazy about updating software so Debian sounded right.

I read the first few sentences off the main Debian installation page and decided to try the net install. I cleared my 4GB USB from 2010 and used the portable version of Rufus to make my USB bootable.

I opened my old PC’s UEFI and made my USB the main boot device and began the installation process. It was all going well until we reached the network part. Debian could detect my devices but couldn’t make use of them since the firmware was not installed (brcm/bcm43xx-0.fw and rtl_nic/rtl8168e-2.fw). It turns out, Debian does not ship with support for non-free firm/software and I was doing a net install so I couldn’t continue with the installation until I got my internet connection setup.

After scouring around for another spare USB, I downloaded the firmware off Debian’s site, enabled the command line tools on the Mac laptop and extracted them into the USB. I later found out those last two items were probably unnecessary since we have access to a terminal during our installation. After a while of searching, I found this beautiful post perfectly outlining all the necessary steps to get Debian to find the firmware for my network adapter.

After setting up the firmware the rest of the installation was almost pain free except I received a “Debootstrap error Failed to determine the codename for the release” error after having the wizard partition my hard drive. After following the instructions from this StackOverflow thread I was able to continue with the “Install the base system” step and finish my installation.

After the installation completed, I attempted to boot into my new system. However, now I needed firmware for my graphic card (Error encountered read: ” Radeon kernel modesetting requires firmware”) so I was only able to use the tttyl terminal. Since I had provided the firmware for my network adapter during installation, I thought I could get the missing firmware with apt-get however, none of the network things that had been configured during installation were there! So there I was again, with no internet connection and the firmware I had loaded in previously was gone. I stepped through the process again mounting the same USB with the firmware files into a temporary folder in lib/firmware and moving the necessary files into lib/firmware. The missing firmware error cleared. However, I was still unable to connect to the internet.

The remaining process was actually quite backwards. My internet search led to a variety of different possible causes but as a newbie, I had trouble discerning what even applied to my case. Even though my network adapter was now being recognized, I needed to set it up as a network. After setting up the network, I was still unable to connect to the internet. I came across this article that said I need to provide my WPA password and network name. The question had previously popped into my mind: how can I log into a network that is locked behind a password? But ignored my gut feeling, believing I would get an error that would say specify the network name. After setting up my network, entering the username and password into /etc/network/interfaces and rebooting my system, I was able to connect to the internet! My routes table was no longer empty and a default gateway had been automatically entered by the system. There was no need to edit anything in my resolvd.config table as many of the threads recommended.

Finally, I could go back and continue with the package I wanted to install through apt-get. The package included firmware for my graphics card so I could use the GUI. After making some small changes to /sources.list to allow non-free package installation, I was able to install the firmware-amd-linux package. After another reboot, I was finally booted into my chosen DE and could also see the Wicd Network Manager.

In retrospect, the experience brought me to appreciate what more user friendly OS’s have done to allow computers and the internet become more accessible.

Lastly, this one is a given, but I kind of dived into this without reading any documentation. I believe the experience would have been smoother would I have at least skimmed through the Debian installation guide. In other words, the “errors” I encountered would have been expected as they are documented.

bookmark_border4 Ways to Secure Your Linux Server

Posted on by Yari

Every minute, every few seconds, your server is receiving a number of malicious connections; from an IP address in Moldava checking to see if a far out port is open, to someone in Iran trying to login into your server with a random username. It’s a bit unsettling but rest assured these connections are likely stemming from autonomous crawlers scanning the web and you are not being personally targeted.

The attacks seem to take on two different forms; 1) The port is accessed via SSH protocol (i.e. accessible through the use of specialized software or browser extensions), or 2) The port can be accessed via HTTP (i.e. accessible via a fresh browser install). Depending on your setup, you will likely spot attempts of type one in your system authentication log files. Attempts of type two should be visible on any firewall or web server logs you may have setup.

The rest of this post is written with a Debian based OS in mind, so commands may be slightly different depending on your distro. Below are a few basic items to begin securing your Linux server.

  1. SSH Keys
  2. Uncomplicated Firewall (UFW)
  3. Apache Web Server
  4. Fail2Ban

SSH Keys

You don’t need to use SSH keys to log into your server but it would make it a lot more secure than having a generic root account with a password.

SSH keys utilize public-key cryptography where a public key is used for encryption and a private key is used for decryption. Your public key can be shared openly without compromising your server’s security. However, you will need to make sure your private key is never disclosed.

Your private key is a file that you will use every time you need to make a connection to your server. This means in order to connect to your server the individual must physically (or would it be digitally) have this file. This communication occurs over port 22 and also known as Secure Shell (SSH).

This document over at Digital Ocean is extremely informative on how SSH works, how to setup SSH for your server and even walks you through disabling root login.

If you happen to have multiple servers, you will need to consider trade-offs between security and convenience. The issue is explained beautifully by tylerl and YaOzl at Stack Overflow and I highly recommend reading through the thread. In summary, you must make a choice between using the same key for all of your servers or generating different keys for each server (potentially, inconvenient). Moreover, since it is recommend you add a passphrase to your key-pair, you have the option of using the same passphrase or using a different one for each key-pair.

Last but definitely not least, make sure to back up your private keys in a secure location and produce an additional external backup in case of an emergency. Your private key is only as secure as you make it.

Uncomplicated Firewall (UFW)

While you could directly use iptables to manage your server’s firewall, a simpler alternative is to use Uncomplicated Firewall (UFW). UFW is a front-end to iptables that is easier to learn.

UFW is disabled by default so you will want to enable it as soon as possible. You will also want to make your first rule so that you can SSH back into your system. It is a good idea to set this rule to LIMIT to prevent brute force attacks on your server.

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw logging on

If your home IP happens to be static (unlikely, but worth a look), you could limit your rule even further by specifying your home IP.

If you are using your server to serve a website you will need to write additional rules to allow connections to port 80. If your site makes use of SSL certificates you will also need to open port 443. Since you want to make your site available to everyone make sure to use ALLOW instead of LIMIT here.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

If you are using multiple servers, you can be write even more specific rules for your firewall (i.e. having your web server’s port 80 only listen to your load balancer’s IP).

You can view your current UFW configuration with the command below.

sudo ufw status verbose

Apache Web Server

If you have installed Apache web server, it might be a good idea to turn off some of the default settings. When Apache runs into a problem it displays an error page that shows a little too much information for our visitors including our OS and web server version. To remove this information, head over to your Apache folder and into your conf-available folder. Locate the file security.conf and look for the following blocks to change your settings.

cat conf-available/security.conf | grep -in "ServerTokens"
cat conf-available/security.conf | grep -in "ServerSignature"

You will want to turn off your ServerSignature and change your ServerTokens value to what is most appropriate for you.

A second setting we may want to change is the directory listing that is enabled by default in the absence of an index.html file. This option can be overridden by a virtual host file so if the configuration below appears to have no effect consider looking into your virtual host configurations.

Lastly, if your website accepts uploads it is a good idea to limit your request size. By default, the request size is unlimited which can cause issues with your site or perhaps be abused in a malicious way.

Head over to your main Apache configuration file, apache2.conf and locate the directory tags near the bottom of the file.

<Directory /var/www/>
        Options -Indexes #Remove directory listing, note the -
        AllowOverride None
        Require all granted
        LimitRequestBody 512000 #Set request size in bytes
</Directory>

Make sure to restart your Apache web server to save these changes.

sudo systemctl restart apache2

Fail2ban

Consider installing Fail2ban to prevent brute force attacks. This will allow you to ban malicious IP addresses for a variable amount of time. The application comes with an SQLITE database so you can preserve long-term bans over server resets. 

sudo apt-get install fail2ban

Fail2ban is ready to use as soon as you install it but I would recommend increasing the ban time and double checking the default settings correspond with your setup.

After installing Fail2ban, create a copy of the jail.conf file and name it jail.local. (Fail2ban is configured to read the settings off your .local file). Next, locate the default bantime variable and set it to something higher. This variable will be towards the top under default settings. You can configure different ban times for different Fail2ban “jails”. If you would like to permanently ban these IP’s enter a value of -1. 

cd /etc/fail2ban
cp jail.conf jail.local
cat jail.local | grep -in "bantime"

Now, restart Fail2ban to save your changes.

sudo fail2ban-client reload

If you would like to further configure Fail2ban, I recommend this article which provides more background information and instructions.

Remember to routinely monitor your system for malicious activity. This is probably best done through specialized software or probably writing your own scripts!