Security: Physical and Service (1 of 3)
8 - 15 min read
Nov 12, 2002
This article is very much useful for those who are interested in developing some web based aplications using PHP as frontend and MySQL as backend with Apache web server On Linux OS.
Security in itself is a vast field which is not possible to illustrate in depth here. But here in this article i have made an attempt to cover the basic level of security which must be implemented by one who is keen in security aspects
First of all let us know how to secure Linux(here i have considered Red Hat)
This involves securing the various servers like FTP,default services like telnet,ftp.
BIOS Security
Remember always to set a password on BIOS to disallow booting from floppy by changing the BIOS settings. This will block undesired people from trying to boot your Linux system with a special boot disk and will protect you from people trying to change BIOS feature like allowing boot from floppy drive or booting the server without password prompt.
All default users and group accounts that you don't use on your system like lp, sync, shutdown, halt, news, uucp, operator, games, gopher etc must be deleted using the command userdel and groupdel:
To delete a user account : [root@aquarius /# userdel lp To delete a group: [root@aquarius /# groupdel lp |
Remember that the minimum length of password by default when you install your Linux system is 5. Its better to have at least 8 characters. You can set this by editing the configuration file for the login program called login.defs. It is located in /etc:
/etc/login.defs: PASS_MIN_LEN 8 |
Enabling shadow password feature is very important. You can use the "/usr/sbin/authconfig" utility to enable the shadow password feature on your system. If you want to convert the existing passwords and group on your system to shadow passwords and groups then you can use the commands pwconv, grpconv respectively.
The "root" account is the most privileged account on a Unix system. When the administrator forgets to logout from the system root prompt before leaving the system, then the system should automatically logout from the shell. To do that, you must set the special variable named "TMOUT" to the time in seconds. Edit your profile file "vi /etc/profile" and add the following line somewhere after the line that to read:
/etc/profile: TMOUT=3600 |
The value we enter for the variable "TMOUT=" is in second and represent 1 hours (60 * 60 = 3600 seconds). If you put this line in your "/etc/profile" file, then the automatic logout after one hour of inactivity will apply for all users on the system. You can set this variable in user's individual ".bashrc " file to automatically logout them after a certain time.
After this parameter has been set on your system, you must logout and login again (as root) for the change to take effect.
You should disable all console-equivalent access to programs like shutdown, reboot, and halt for regular users on your server. To do this, run the following command:
[root@aquarius /# rm -f /etc/security/console.apps/ |
Where
Securing Services
Internet and network services are among the most vulnerable parts of your system. Whether you're planning a new installation or reviewing security on an existing system, your file servers, e-mail services, Web servers, FTP, and other network services should be among the first things you check for security holes.
Some services will obey the /etc/hosts.accept and /etc/hosts.deny configurations if they've been compiled with the TCP Wrapper library, but not all will. Use the firewall code along with the TCP Wrapper configurations to secure your services.
You should disable and uninstall all services that you do not use so that you have one less thing to worry about. Look at your "/etc/inetd.conf" file and disable what you do not need by commenting them out (by adding a # at the beginning of the line), and then sending your inetd process a SIGHUP command to update it to the current "inetd.conf" file. To do this:
- Change the permissions on "/etc/inetd.conf" file to 600, so that only root can read or write to it.
[root@aquarius /# chmod 600 /etc/inetd.conf
- ENSURE that the owner of the file "/etc/inetd.conf" is root.
- Edit the inetd.conf file (vi /etc/inetd.conf) and disable the services like: ftp, telnet, shell, login, exec, talk, ntalk, imap, pop-2, pop-3, finger, auth, etc unless you plan to use it. If it's turned off it's much less of a risk.
- Send a HUP signal to your inetd process
[root@aquarius /# killall -HUP inetd
- Set "/etc/inetd.conf" file immutable, using the chattr command so that nobody can modify that file
- To set the file immutable simply, execute the following command:
[root@aquarius /# chattr +i /etc/inetd.conf
This will prevent any changes (accidental or otherwise) to the "inetd.conf" file. The only person that can set or clear this attribute is the super-user root. To modify the inetd.conf file you will need to unset the immutable flag:
- To unset the immutable simply, execute the following command:
[root@aquarius /# chattr -i /etc/inetd.conf |
or You can type the command linuxconf at the prompt and then select system services which will list all the services running and u can select the required ones and deselect the unnecessary services.
Set up your basic security mechanisms to deny everything unless you explicitly configure it to be allowed. Set the /etc/hosts.allow file to allow localhost only, and set the /etc/hosts.deny file to deny everything else. With that as a starting point, you can decide who and what will be granted which access, and everything else will be blocked. The default should always be "No!"
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. The first file it parses is the /etc/hosts.allow file. If it doesn't find a match, then it proceeds to the a /etc/hosts.deny file.
- Edit the hosts.deny file (vi /etc/hosts.deny) and add the following lines:
Which means all services, all locations is blocked, unless they are permitted access by entries in the allow file.# Deny access to everyone. ALL: ALL@ALL, PARANOID
- Edit the hosts.allow file (vi /etc/hosts.allow) and add for example, the following line:
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.
- 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@aquarius /# tcpdchk
Telnet and Finger
Running telnet, rlogin, or rsh to access your system remotely is not secure as they allow passwords and userids to be "sniffed."
For remote access, use secure shell (ssh) connections and disable all non-encrypted remote access to the server. The ssh package can be downloaded and installed very easily. ssh isn't available on any Linux distribution originating in the United States due to US export restrictions on cryptography. Some distributions from outside of the US do include cryptography modules and applications such as ssh and PGP in the base distributions and installations.
finger is often configured and available on default installations. Unless you have a specific need for this service, disable it or restrict network access to it. finger provides far too much information about your users to would-be intruders. It is also instrumental in certain advanced forms of denial-of-service attacks such as "nisnuke" on large networks.
Type the command finger and see the output.
Finger command gives info on who is currently logged in at what terminals and the timings of login too which is enough for any intruder to attack.
Secure Web services
If you're running a Web server, check and recheck your CGI scripts. Do not allow other users to install arbitrary CGI scripts. Do not use unrestricted server-side includes (SSIs).
IRC is one common example of a chat system -- many other chat systems also work with Web servers. If you have any kind of chat server running on your system, make sure common users can't insert arbitrary HTML (hostile JavaScript anyone?) into pages where your Web server can serve them up.
FTP Security
If you're operating an anonymous FTP service, watch your permissions closely! Don't allow any directories to be both readable and writable by anonymous users. If you want to permit anonymous uploads to your system, provide a write-only directory and prohibit directory creation underneath it. If you permit a location to be both readable and writable, you not only allow your system to be a "warez" (pirateware) repository, but you also open up your system to being used for "FTP bounce" attacks against other systems.
If you're not running anonymous FTP -- make sure you're not. A lot of distributions enable anonymous FTP by default.
Secure file serving
If you're exporting any filesystems via NFS, SMB, Samba, or anything else, make sure your access permissions are carefully checked. Never run NFS, SMB, or NIS over the Internet. The risk is just too great.
NFS in particular uses UDP and depends on peer addresses for authentication and authorization. But peer addresses are trivial to spoof for UDP!
E-mail Security
If you're running POP or IMAP for remote downloading of e-mail, switch to an SSL-encrypted version. You can use stunnel or edssl to set up SSL-enabled mail servers. Several e-mail clients support SSL POP and/or SSL IMAP, including Netscape and Microsoft Outlook. SSL-enabled fetchmail is available from the North American Cryptographic Archives.
If you aren't intending to run POP or IMAP, make sure you really aren't running them.
Some distributions enable these by default. Some of the "bad guys" out on the Net are now engaged in massive parallel-port scanning for IMAP servers. If you leave the backdoor open for one of them to get your number, the next time a major root compromise is discovered in IMAP (for example) he or she could promptly come knocking. If you don't know you're running IMAP, you'll have no reason to know when security patches or updates to it become available. Without these upgrades, an intruder could be root on your system before you know what hit you.
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.
- 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.
- 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:
Which mean, the "bash_history" file in each users home directory can store 20 old commands and no more.HISTFILESIZE=30 HISTSIZE=30
- 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@aquarius /# /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@aquarius/# 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.
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@aquarius /# chattr +i /etc/services |
- 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
- Then, remove the following files: "issue.net" and "issue" under "/etc" directory:
[root@aquarius /# rm -f /etc/issue [root@aquarius /# rm -f /etc/issue.net
Disable Unused SUID/SGID Programs
A regular user will be able to run a program as root if it is set to SUID root. A system administrator should minimize the use of these SUID/GUID programs and disable the programs which are not needed.
- To find all files with the `s' bits from root-owned programs, use the command:
[root@aquarius]# find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls lg {} \; - To disable the suid bits on selected programs above, type the following commands:
[root@aquarius /# chmod a-s [program]
This email address is being protected from spambots. You need JavaScript enabled to view it.
Roopa has been in the IT field in Karnataka, India for about three plus years. Her interests include Linux Security and Networking and she has been at them for a while.
