Monday, September 14, 2009

Linux Security Checklist

Disabling Unnecessary Services

ps –ax :will list all currently running processes

ls –l /etc/rc.d/rc3.d/S* :will show all start-up scripts (if you boot into
graphics mode, replace rc3.d with rc5.d)

netstat –a :will list all open ports


Check for Security on Key Files

/etc/fstab: make sure the owner & group are set to root:root and the
permissions are set to 0644 (-rw-r--r--)
• verify that /etc/passwd, /etc/shadow & /etc/group are all owned by 'root'
• verify that permissions on /etc/passwd & /etc/group are rw-r--r-- (644)
• verify that permissions on /etc/shadow are r-------- (400)

Limit root access using SUDO

/etc/sudoers


Only allow root to access CRON


To enhance security of the cron scheduler, you can establish the cron.deny and
cron.allow files to control use of the crontab. The following commands will
establish root as the only user with permission to add cron jobs:

cd /etc/bin/rm -f cron.deny at.deny
echo root >cron.allow
echo root >at.allow
/bin/chown root:root cron.allow at.allow
/bin/chmod 400 cron.allow at.allow


Remote Access and SSH Basic Settings


Telnet is not recommended for remote access. Secure Shell (SSH) provides
encrypted telnet-like access and is considered a secure alternative to telnet.
However, older versions of SSH have vulnerabilities and should not be used.
To disable SSH version 1 and enhance the overall security of SSH, consider
making the following changes to your sshd_config file:

Protocol 2
PermitRootLogin yes
PermitEmptyPasswords no
Banner /etc/issue
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
HostbasedAuthentication no
LoginGraceTime 1m (or less – default is 2 minutes)
SyslogFacility AUTH (provides logging under syslog AUTH)
AllowUser [list of users allowed access]
DenyUser [list of system accounts and others not allowed]
MaxStartups 10 (or less – use 1/3 the total number of remote users)

Note: MaxStartups refers to the max number of simultaneous
unauthenticated connections. This setting can be helpful against a brute-
force script that performs forking.

Apache Security

Verify that your apache subdirectories are all owned by root and have a
mod of 755:

ls -l /etc/apache2



To prevent users from setting up .htaccess files that can override security
features, change the server configuration file to include:

AllowOverride None

To prevent users from accessing the entire filesystem (starting with the root
directory), add the following to your server configuration file:

Order Deny,Allow
Deny from all

To provide access into individual directories, add the following:

Order Deny,Allow
Allow from all

Apache Configuration File

In Apache, the ServerTokens directive allow the system administrator to set different type of Server HTTP response header:

ServerTokens Prod
this is the most restrictive, in our example, apache will respond Server: Apache

ServerTokens Major
responds -> Server: Apache/2

ServerTokens Minor
responds -> Server: Apache/2.0

ServerTokens Min
responds -> Server: Apache/2.0.55

ServerTokens Os
responds -> Server: Apache/2.0.55 (Ubuntu)

ServerTokens Full
responds -> Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2 mymod1/X.Y mymod2/W.Z

By default, ServerTokens is set to Full. To change that value, edit /etc/apache2/apache2.conf and look for the line containing ServerTokens.

ServerSignature Off


Securing FTP

If you really have to use FTP (without wrapping it with sslwrap or inside a SSL or SSH tunnel), you should chroot ftp into the ftp users' home directory, so that the user is unable to see anything else than their own directory. Otherwise they could traverse your root file system just like if they had a shell in it. You can add the following line in your proftpd.conf in your global section to enable this chroot feature:

     DefaultRoot ~

Restart ProFTPd by /etc/init.d/proftpd restart and check whether you can escape from your homedir now.

To prevent ProFTPd DoS attacks using ../../.., add the following line in /etc/proftpd.conf: DenyFilter \*.*/

2 comments:

Unknown said...

PermitRootLogin yes

This isn't a very good idea. What this means is that if ssh has any sort of bug/buffer overflow, and god knows *that* has never happened, then they own the box.

People should ssh as a user account then sudo. That way you have a chance to catch them b4 they can own u.

Cheers

Anonymous said...

Made some good points
apart from
PermitRootLogin yes

cheers for that