Security Basics mailing list archives
RE: Linux auditing checklist, documents
From: "Gurpreet Singh" <gurpreetsl () gmail com>
Date: Wed, 20 Dec 2006 10:57:49 +0530
Here are some tips and tricks. TCP_WRAPPERS By using TCP_WRAPPERS you can make your server secure against outside intrusion . The best policy is to deny all hosts by putting "ALL: ALL@ALL, PARANOID" in the "/etc/hosts.deny" file and then explicitly list trusted hosts who are allowed to your machine in the "/etc/hosts.allow" file. TCP_WRAPPERS is controlled from two files and the search stops at the first match. /etc/hosts.allow /etc/hosts.deny Step 1 Edit the hosts.deny file (vi /etc/hosts.deny) and add the following lines: # Deny access to everyone. ALL: ALL@ALL, PARANOID Which means all services, all locations is blocked, unless they are permitted access by entries in the allow file. Step 2 Edit the hosts.allow file (vi /etc/hosts.allow) and add for example, the following line: As an example: ftp: 202.54.15.99 foo.com For your client machine: 202.54.15.99 is the IP address and foo.com the host name of one of your client allowed using ftp. Step 3 The tcpdchk program is the tcpd wrapper configuration checker. It examines your tcp wrapper configuration and reports all potential and real problems it can find. * After your configuration is done, run the program tcpdchk. [Root@kapil /]# tcpdchk Don't let system issue file to be displayed You should not display your system issue file when people log in remotely . To do this, you can change the telnet option in your "/etc/inetd.conf". To do this change the line in "/etc/inetd.conf": telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd to look like: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd -h Adding the "-h" flag on the end will cause the daemon to not display any system information and just hit the user with a login: prompt. I will recommend to use sshd instead. Change the "/etc/host.conf" file The "/etc/host.conf" file specifies how names are resolved. Edit the host.conf file (vi /etc/host.conf) and add the following lines: # Lookup names via DNS first then fall back to /etc/hosts. order bind,hosts # We have machines with multiple IP addresses. multi on # Check for IP address spoofing. nospoof on The first option is to resolve the host name through DNS first and then hosts file.The multi option determines whether a host in the "/etc/hosts" file can have multiple IP addresses (multiple interface ethN). The nospoof option indicates to take care of not permitting spoofing on this machine. Immunize the "/etc/services" file You must immunize the "/etc/services" file to prevent unauthorized deletion or addition of services. * To immunize the "/etc/services" file, use the command: [root@kapil /]# chattr +i /etc/services Disallow root login from different consoles The "/etc/securetty" file allows you to specify which TTY devices the "root" user is allowed to login . Edit the "/etc/securetty" file to disable any tty that you do not need by commenting them out (# at the beginning of the line). Blocking anyone to su to root The su (Substitute User) command allows you to become other existing users on the system. If you don't want anyone to su to root or restrict "su" command to certain users then add the following two lines to the top of your "su" configuration file in the "/etc/pam.d/" directory. Step 1 Edit the su file (vi /etc/pam.d/su) and add the following two lines to the top of the file: auth sufficient /lib/security/pam_rootok.so debug auth required /lib/security/Pam_wheel.so group=wheel Which means only members of the "wheel" group can su to root; it also includes logging. You can add the users to the group wheel so that only those users will be allowed to su as root. Shell logging The bash shell stores up to 500 old commands in the "~/.bash_history" file (where "~/" is your home directory) to make it easy for you to repeat long commands. Each user that has an account on the system will have this file "Bash_history" in their home directory. The bash shell should store less number of commands and delete it on logout of the user. Step 1 The HISTFILESIZE and HISTSIZE lines in the "/etc/profile" file determine the size of old commands the "Bash_history" file for all users on your system can hold. I would highly recommend setting the HISTFILESIZE and HISTSIZE in "/etc/profile" file to a low value such as 30. Edit the profile file (vi /etc/profile) and change the lines to: HISTFILESIZE=30 HISTSIZE=30 Which mean, the "Bash_history" file in each users home directory can store 20 old commands and no more. Step 2 The administrator should also add into the "/etc/skel/Bash_logout" file the "rm -f $HOME/Bash_history" line, so that each time a user logs out, its "Bash_history" file will be deleted. Edit the Bash_logout file (vi /etc/skel/Bash_logout) and add the following line: rm -f $HOME/Bash_history Disable the Control-Alt-Delete keyboard shutdown command To do this comment out the line (with a "#") listed below in your "/etc/inittab" file . To do this, edit the inittab file (vi /etc/inittab) and change the line: ca::ctrlaltdel:/sbin/shutdown -t3 -r now To read: #ca::ctrlaltdel:/sbin/shutdown -t3 -r now Now, for the change to take effect type in the following at a prompt: [root@kapil /]# /sbin/init q Fix the permissions under "/etc/rc.d/init.d" directory for script files Fix the permissions of the script files that are responsible for starting and stopping all your normal processes that need to run at boot time. To do this: [root@kapil/]# chmod -R 700 /etc/rc.d/init.d/* Which means only root is allowed to Read, Write, and Execute scripts files on this directory. Hide your system information By default, when you login to a Linux box, it tells you the Linux distribution name, version, kernel version, and the name of the server. This is sufficient information for a crackers to get information about your server. You should just prompt users with a "Login:" prompt. Step 1 To do this, Edit the "/etc/rc.d/rc.local" file and Place "#" in front of the following lines as shown: # This will overwrite /etc/issue at every boot. So, make any changes you # want to make to /etc/issue here or you will lose them when you reboot. #echo "" > /etc/issue #echo "$R" >> /etc/issue #echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue # #cp -f /etc/issue /etc/issue.net #echo >> /etc/issue Step 2 Then, remove the following files: "issue.net" and "issue" under "/etc" directory: [root@kapil /]# rm -f /etc/issue [root@kapil /]# rm -f /etc/issue.net -----Original Message----- From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of urandom character special device Sent: Sunday, December 17, 2006 3:56 PM To: security-basics () securityfocus com Subject: Linux auditing checklist, documents I am Linux System Administrator at a telecom provider. Our customer inform us to send soon independent security auditors to have a look at our Linux systems. They will have a root password and make an in deep analysis of the systems. I wish to prepare. What "commands" and "config files" they will look? Are there Linux Security Guidelines? They wont use automated tools. --------------------------------------------------------------------------- This list is sponsored by: ByteCrusher Detect Malicious Web Content and Exploits in Real-Time. Anti-Virus engines can't detect unknown or new threats. LinkScanner can. Web surfing just became a whole lot safer. http://www.explabs.com/staging/promotions/xern_lspro.asp?loc=sfmaildetect ---------------------------------------------------------------------------
Current thread:
- Linux auditing checklist, documents urandom character special device (Dec 18)
- Re: Linux auditing checklist, documents Saqib Ali (Dec 19)
- RE: Linux auditing checklist, documents Clement Dupuis (Dec 19)
- RE: Linux auditing checklist, documents Simmons, James (Dec 21)
- RE: Linux auditing checklist, documents Gurpreet Singh (Dec 19)
- Re: Linux auditing checklist, documents jm (Dec 21)
- Re: Linux auditing checklist, documents Devdas Bhagat (Dec 19)
- <Possible follow-ups>
- RE: Linux auditing checklist, documents Hayes, Bill (Dec 19)
- Re: Linux auditing checklist, documents barcajax (Dec 19)
- RE: Linux auditing checklist, documents Gurpreet Singh (Dec 21)
- Re: Linux auditing checklist, documents jsimmons (Dec 21)