*I* deas » Secure Your Linux ….

Secure Your Linux ….

Posted on 14th March 2006 by Taggy

While waiting for ADSL to be enabled in my area, which (I’ve been told) will happen soon, I did some tinkering with my Debian Linux workstation to make it more protected against remote attacks, and I thought of compiling a list of security measures against the dangers of full-time Internet connection. Obviously the list is not complete, but it has tips that can surely help.
Linux Core
Configure and Enable Firewall

The firewall is the front-line defense against remote attacks, it’s highly recommended that you enable and configure it, Linux firewall infrastructure is called netfilter/iptables, unfortunately it is quite complicated, the details can’t be covered here, so check out this howto, or use configuration frontends like m0n0wall (CLI), shorewall (CLI), and FireStarter (GUI).

I suggest you drop all incoming connections, and then open the ports you need, like SSH or Bittorrent.
Avoid Easy-to-compromise User Accounts

The machine must not have user accounts with easy-to-guess passwords, especially accounts like test/test or guest/guest, many Linux worms try to exploit such accounts over SSH. open /etc/passwd and make sure there are no such accounts, if you do have an account like that, delete it:
# userdel username

If you really need such an account for some odd reason, change its shell to /bin/false,so an attacker won’t be able to login to it:
# chsh -s /bin/false username
Mount /tmp as noexec

Many exploits and script kiddies rely on downloading scripts to /tmp and executing them, by mounting /tmp as noexec, scripts located in /tmp will not be executable, effectively disabling exploits that rely on /tmp, and stumping many script kiddies, here is the /tmp config line from my /etc/fstab:
/dev/hda5 /tmp ext2 noatime,noexec 0 0
Protect against Fork Bombs

Fork bombs are programs that keep creating child processes until system resources are all used, they actually aren’t remote exploits because they require a local user to execute the bomb, however, users may be tricked into running a fork bomb, for example the following example may look innocent, but running it on an unprotected system may take the whole system down:
:(){ :|:& }; :
WARNING: do NOT run the above code on an unprotected system!

The above shell script will actually keep forking at an exponential rate until system resources are exhausted.

To protect a system against such attacks, there is a file for limiting the number of processes for each user, it is /etc/security/limits.conf, add the following two lines to it:
@users soft nproc 100
@users hard nproc 150

The lines prevent anyone in the users group from having more than 150 processes, and issue a warning at 100 processes.

Your system may not have a users group, so you may need to edit the lines to suit your needs.
Limit Usage of su/sudo

su lets normal users switch to the root account, and sudo enables root to grant more privileges to users, it’s always better to grant only the absolutely necessary privileges to specific users, and limit the usage of su to a specific group, in Gentoo Linux, only users in the wheel group can use su.

When the usage of su/sudo is limited, even if the system was compromised through a dummy account (like test as username and password), the attacker will have less options to play with.
Linux Daemons
OpenSSH

Users of machines with broadband connections usually need to remotely connect to their machines through SSH, so even if the workstation is protected by a firewall, SSH’s port need to be open for inbound connections, as a result, SSH is a common target for remote attacks.

Here is a list of OpenSSH configuration settings that make it more secure against attacks, SSH settings are usually at /etc/ssh/sshd_config

Port 22 (change the port number)
SSH default port is 22, change it through the above line, this will stop many automated attacks. Notice that when remotely connecting to the workstation, the new port number needs to be specified to the SSH client, for example:
$ ssh -p new port username@host.domain

Protocol 2
Make sure the protocol is set to 2, it’s more secure than the 1st version.

LoginGraceTime 2m
MaxAuthTries 6
These config lines protect against brute force attacks.

PermitRootLogin no
Random attackers will usually try random usernames when trying to break through SSH, and since the root account exists on every machine, it will be on the attack list, the above config line disables root login over SSH, and stops those attackers, if root access to a remote machine is needed, login using your regular account, then su to root.

PermitEmptyPasswords no
A username with blank password may be added accidentally, the above config line makes it not possible to login with such accounts.

In addition, to the configuration lines I listed, and in case you login to your machine from the same IP address or range, limit IP addresses that can connect to SSH using /etc/hosts.allow, use the following format:
sshd : 127.0.0.1 : allow
sshd : IP address here : allow
sshd : IP address here : allow
sshd : ALL : deny
MySQL

if you use MySQL for local development, then it’s safer to limit its connections to localhost (among the other things), to do so, run the mysql_secure_installation script, and it will take care of things for you.
Samba

Many need Samba for sharing files over the local network, here is a list of config lines to secure it, the configuration file is usually located at /etc/samba/smb.conf or /etc/smb.conf:

hosts allow = 127.0.0.1 192.168.0.0/24
hosts deny = 0.0.0.0/0
This config line limits hosts that can connect to Samba to localhost and local IP ranges, modify to suit your needs.

security = user
Set security to user, in this case, users connecting to Samba will need to login before continuing, to add Samba user accounts, use the following command:
# smbpasswd -a username
And then you will be asked to provide a password for the new account.

By the way, if you login to your Samba share from a MS Windows machine, you may set your Samba username/password to match those on Windows, and avoid having to enter them every time you connect to the share.

As a final Samba tip, do NOT share your home folder, if you do so, you are just asking for trouble, create a folder for sharing, and drop files there as necessary.
General Tips

* Keep your system up-to-date, especially when security vulnerabilities appear in packages you use, all major Linux distos have security mailing lists, subscribe to your distro’s.
* Disable services you don’t need, every open service makes your system more open to attacks.
* Regularly monitor the output of the following command for odd entries:
# vi /var/log/messages (system log)
# ps aux (running processes)
# netstat -anp (active connections)
* Update your system
* Don’t rely on security through obscurity as the only measure, it can be another defense line, but full dependence on it can only lead to trouble.
* Did I mention keeping the system up-to-date? ;)

Hope this helps, will try to keep the list up-to-date, and add more entries whenever I come across something new.

Responses to.. Secure Your Linux ….