While waiting for ADSL to be enabled in my area, which (I've been told) will happen soon, I did some tinkering with my Gentoo Linux [1] 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 [14]. Unfortunately it is quite complicated, the details can't be covered here, so check out this howto [15], or use configuration frontends like m0n0wall [16] (CLI), shorewall [17] (CLI), and FireStarter [18] (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:

:(){ :|:& }; :

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. Therefore, 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 located in /etc/ssh/sshd_config:
SSH default port is 22, change it through the line below. This will stop many automated attacks.

Port 22

$ ssh -p [new port] username@host.domain

Make sure the protocol is set to 2. It's more secure than the 1st version.

Protocol 2

The following config lines protect against brute force attacks.

LoginGraceTime 2m
MaxAuthTries 6

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 following 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.

PermitRootLogin no

A username with blank password may be added accidentally. The following config line makes it not possible to login with such accounts.

PermitEmptyPasswords no

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

   security = user

# smbpasswd -a username

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 distros 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.