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 Prodthis 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:
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
Made some good points
apart from
PermitRootLogin yes
cheers for that
Post a Comment