Tips to Secure Linux Workstation

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

Table of Contents [hide]

Linux Core
Linux Daemons
1. OpenSSH
2. MySQL
3. Samba
General Tips

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

(change the port number)
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

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

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

79146 reads
Printer-friendly version

Tags:

Submitted by Ayman on Sun, 2006/03/05 - 4:44pm

Interesting, thanks.

Great Tutorial and very helpful for Gentoo Linux users.

pretty sure it works on most distros, not just gentoo

These are some very good tips that everyone should follow.
One thing I don't recommend doing, though is using vi to look at /var/log/messages.

Use cat or tail instead.

Port 21 is it????? I don't think so.

Ah, sorry, this is a typo, fixed now, thanks :)

yes port 21 exists....the port 21 is used by ftp.....

I don't know whether LSB requires /tmp to be writable, but I know programs such as gzexe that require an executable /tmp. nodev and nosuid are better settings as executables can most often be placed elsewhere too. The suggestions mentioned above are mostly paranoid.

Dugg :)

http://digg.com/linux_unix/Tips_to_Secure_Linux_Workstation

Port 21 is for FTP, port 22 is for ssh by default...

If you need to open MySQL for remote access, consider running MySQL on another port. There are numerous exploits (mainly brute force) which look for MySQL on it's default port (3306). If you use port forwarding on your incoming router, you won't even have to change your MySQL installation. Forward a different port on your external interface to 3306 internal.

Also, there is no reason in the world why the 'root' user in MySQL needs to exist (in the 'mysql' database). Clone this user to another username and remove the 'root' username account from MySQL. Most brute force kits look for the default 'root' account.

setting /tmp to noexec won't stop the script kiddies, they just download perl scrips and execute them from somewhere else, if fact I've found it caused more problems then it solved in the past due to applications falsely assuming they could exec temp stuff in /tmp

I said that in the article, script kiddies with some Linux knowledge would move scripts to another folder, however, if there is not other folder they have write access to, or the attack is automated, they will fail.

Instead of using netfilter/iptables, which even you admit has configuration headaches, I'd suggest investing in a separate fireall device.

You get to stop all incoming traffic *before* it reaches and attempts to swamp your machine, and in general it's easier to manage.

Do you really want to have to worry about your firewall during an upgrade<->downgrade<->upgrade problem with portage because one of the devs (bless their little hearts) got something slightly wrong?

I've been running Gentoo on my workstation and one server for 3 years very successfully but I'd rather have my fireall be an appliance while I'm upgrading and changing configurations.

My firewall only cost 60$ 3 or 4 years ago and has worked flawlessly ever since.

the default port is 22, telnet uses port 21...

i would also suggest this added to the sshd_config

StrictModes yes
X11Forwarding no
UsePrivilegeSeparation yes

and this option is not even valid for ssh
MaxAuthTries 6

--T

Thanks for your additions.

BTW:

$ man sshd_config
[...]
MaxAuthTries
Specifies the maximum number of authentication attempts permitted
per connection. Once the number of failures reaches half this
value, additional failures are logged. The default is 6.
[...]

telnet does NOT use port 21, it uses tcp port 23

FTP uses tcp ports 20 and 21, though might only use 21 in some cases if passive ftp is possible.

I also find AllowUsers to be helpful in allowing specific users the ability to log in using SSH

AllowUsers [username] [username 2] ... [username n]

i persnally use the command netstat -luntp to show all open ports and programms listening on the ports. on bsd one can use sockstat -4 -l and see the same.

greetings

As you suggested dropping incoming conn at the firewall is a really good idea.

If you do login to the server using ssh from a remote location, it is always safe to configure iptables to allow incoming conn to sshd only from a particular IP addrs. (you can allow conn to port 22 from the ip xxx.xxx.xxx.xxx)

In case the client uses DHCP, and the IP changes regularly, u can configure iptables on the server to allow incoming conn only from ur clients MAC addrs. This is better than using IP addrs bcoz someone might be able to use ur client IP address when ur client is not using it.
(you can allow conn to port 22 from MAC addrs xx-xx-xx-xx-xx-xx)

Also note that if for some reason if ur network card fails, there is no way you can do a remote login to the machine. Someone shld change the settings by physically being at the terminal.

Good article, wish I had something similar when I was starting out.

Instead of your proposed vi /var/log/messages use some scripts like Logcheck http://logcheck.org/ which runs through your logs and emails you things that are out of place. It's easy to modify the conf files to train it to ignore things that come up often that you're not worried about. I have it set to run nightly, and it's amazing what it's able to help out with. It easily cuts out the cruft (regular events) allowing me to focus on things that are unexpected.

Also, aside from sub'ing to your distro's security mailling list, sub to things like Security Focus, or other apps that are 'live' to the world. I found out about and fixed some Drupal vulns before my distro (freebsd) did since I was on the Drupal list.

Thanks
fak3r

i tried changing the default port and it didn't work...i was using putty to connect to a different ssh port, could that be the problem or maybe the port i chose to use...do you recommend another port outside of 22?

great article by the way...i implented most of you ideas for ssh...was getting multiple hacking attempts

Any unused port above 1024 should do the trick.

Did you restart sshd after changing the config file? You can see what port sshd is listening to by running the command:
netstat -lunpt | grep sshd

In PuTTY, just change the port number, you don't need to do anything else.

Just passing through when I saw your thread, great tips I also have a few that people may find useful. If you add this to the end of your /etc/profile file, it will alert you when an account is created. Unfortuntely I haven't been able to verify if this works just yet

if "$UID" > 1000 ; then
echo 'ALERT - New Account Created (MachineName) on:' `date` `who` | mail -s "New Account Created on (MachineName) `who | cut -d'(' -f2 | cut -d')' -f1`" you@yourdomain.com
fi

Now just modify it a bit to alert you if someone creates an acount that is part of the root group:

if "$GID" == 0 ; then
echo 'ALERT - New Account Created With Root Group Privileges (MachineName) on:' `date` `who` | mail -s "New Account Created With Root Group Privileges on (MachineName) `who | cut -d'(' -f2 | cut -d')' -f1`" you@yourdomain.com
fi

Add this line to your /etc/hosts.deny file and it will email you if there is a refused connection from the Inetd daemon ( TCP Wrappers):

ALL:ALL:/bin/mail -s %s connection attempt from %c you@yourdomain.com

m0n0wall is not a netfilter/iptables frontend. It's an embedded "firewall distribution" based on FreeBSD.

Hello there,
Well, what a great guide on security basics, some very interesting stuff too, Thanks for the interesting read, It's proved useful to me, with some of the debian machines I run,

Thanks again

Adam

> Also which distro has out-of-the-box support for SATA hard drives.
> Any suggestions?

Have you tried Ubuntu. It's a gr8 distro and has very good support for a variety of vendors. You need to have a good connection for downloading necessary packages.

I have tried FC5 too and it seems to contain good support in a single DVD (5 CDs).

The following /proc manipulation is minimal to secure linux for networking:

# don't answer to broadcast pings
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# don't answer to bogus ICMP messages
echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# enable source validation and kick the ip spoofing shit
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
# change default TTL (default in Linux is 64)
echo 61 > /proc/sys/net/ipv4/ip_default_ttl
# send RST packages if buffer is full
echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
# wait max. 30 seconds for FIN/ACK
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
# max 3  SYN packages for one connection attempt
echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
# max 3 SYN/ACK packages for one connection attempt
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

you would have to be insane or very inexperienced to allow password access to any machine running SSH, especially in the wild. any sysadmin with any clue whatsoever disables password authentication and uses keyfiles. keep them with you on an encrypted usb stick: if you use freeOFTE and luks then you have windows + linux compatibility for accessing your keys.
additionally, SELinux is very useful for protecting the system against your legitimate users and rogue programs.

Ayman Hourieh's Blog