http://www.linuxsecurity.com/feature_stories/feature_story-128.html (1 of 3)
http://www.linuxsecurity.com/feature_stories/feature_story-129.html (2 of 3)

Security: Physical and Service (1 of 3)

By Roopa Rannorey
11/12/2002

The first installation of a 3 part article covering everything from physical security and service security to LAMP security (Linux Apache MySQL PHP).

Nothing is perfectly secure in this world.But all that one could do is reduce the degree of intrusions by intruders and thereby minimising the security risks . In this article we shall discuss how to secure 'LAMP' LAMP stands for "Linux Apache MySQL PHP"

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 RedHat)

 

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 is the name of the program to which you wish to disable console-equivalent access.

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:

     

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

     

  2. ENSURE that the owner of the file "/etc/inetd.conf" is root.

     

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

     

  4. Send a HUP signal to your inetd process
    [root@aquarius /]# killall -HUP inetd

     

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

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

  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.

     

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

     

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

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.

     

  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.

     

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

[root@aquarius /]# chattr +i /etc/services

     

  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
    

     

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


 

 

 

 

Security: Apache (2 of 3)

By Roopa Rannorey
11/12/2002

This is the second installation of a 3 part article on LAMP (Linux Apache MySQL PHP). Apache is the most widely used HTTP-server in the world today.

It is also the most used web server for a Linux system. A web server like Apache, in its simplest fun ction, is software that displays and serves HTML pages hosted on a server to a client browser that understands the HTML code.

You must always be careful in knowing the web services that run. Run:

[root@aquarius /]# netstat -a | grep LISTEN

 

to scan your ports. A secure site should have only ports 22 (SSH), 80 (HTTP) and 443 (SSL) exposed.

Log files are another useful utility for monitoring attacks on your server. One must set up a centarlised secure log server so that hackers will not be able to remov e traces of their intrusion so easily. Various logfile analyzers like analog, webaliser help in keeping track of the web server access by people. By installing and configuring a good logfile analyser one can know details about the total traffic across the network and the various files and directories accessed,mod ified,deleted or any such activity. It will also tell you the pages that were visited and by whom. In addition to that are all the resources that are busy with respect to apache.

Maintaining Logfiels is such an important task that one must follow in order to keep track of his system's activities.Apache web server logfiles are httpd.log,error _log and access_log These files log all the attempts by a user in order to perform a task,it can be an attempt for compromising the system The daemon syslog must be enabled which is responsible for logging activity. Care must be taken that logging is on for mail and auth privileges in /etc/syslog.conf

In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command th at root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writeable only by root, but so mu st the directories, and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

    mkdir /usr/local/apache
    cd /usr/local/apache
    mkdir bin conf logs
    chown 0 . bin conf logs
    chgrp 0 . bin conf logs
    chmod 755 . bin conf logs

 

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected:

    cp httpd /usr/local/apache/bin
    chown 0 /usr/local/apache/bin/httpd
    chgrp 0 /usr/local/apache/bin/httpd
    chmod 511 /usr/local/apache/bin/httpd

 

You can create an htdocs subdirectory which is modifiable by other users -- since root never executes any files out of there, and shouldn't be creating files in there.

If you allow non-root users to modify any files that root either executes or writes on then you open your system to rootcompromises. For example, someone could repla ce the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could repl ace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a no n-root user), then someone may be able to overwrite the log itself with bogus data.

Server Side Includes

Server Side Includes (SSI) present a server administrator with several potential security risks. The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the f iles. While this load increase is minor, in a shared server environment it can become significant.SSI files also pose the same risks that are associated with CGI script s in general. Using the "exec cmd" element,SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as config ured in httpd.conf. That should definitely give server administrators pause.

There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide. To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec as described in the CGI in General section. Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files shoul d have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk.

Another solution is to disable the ability to run scripts and programs from SSI pages. To do this replace Includes with IncludesNOEXEC in the Options directive. Note that users may still use <--#include virtual="..." --> to execute CGI scripts if these scripts are in directories desginated by a ScriptAlias directive.

Non Script Aliased CGI

Allowing users to execute CGI scripts in any directory should only be considered if:

Script Aliased CGI

Limiting CGI to special directories gives the admin control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but only if users with write access to the directories are trusted or the admin is willing to test each new CGI script/program for potential security holes. Most sites choose this option over the non script aliased CGI approach.

CGI in General

Always remember that you must trust the writers of the CGI script/programs or your ability to spot potential security holes in CGI, whether they were deliberate or accidental.

All the CGI scripts will run as the same user, so they have potential to conflict (accidentally or deliberately) with other scripts e.g. User A hates User B, so he writes a script to trash User B's CGI database. One program which can be used to allow scripts to run as different users is suEXEC which is included with Apache as of 1. 2 and is called from special hooks in the Apache server code. Another popular way of doing this is with CGIWrap.

Protecting System Settings

To run a really tight ship, you'll want to stop users from setting up .htaccess files which can override security features you've configured. Here's one way to do it.

In the server configuration file, put


AllowOverride None

 

This prevents the use of .htaccess files in all directories apart from those specifically enabled.

Protect Server Files by Default

One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its wa y to a file through normal URL mapping rules, it can serve it to clients.

For instance, consider the following example:

# cd /; ln -s / public_html

 

If a client accessed http://localhost/~root/, this would allow them to walk through the entire filesystem. To work around this, add the following block to your serve r's configuration:

 
     Order Deny,Allow
     Deny from all
  

 

This will forbid default access to filesystem locations. Add appropriate blocks to allow access only in those areas you wish. For example,

 
     Order Deny,Allow
     Allow from all
 
 
     Order Deny,Allow
     Allow from all
 

 

Pay particular attention to the interactions of and directives; for instance, even if denies access, a directive might overturn it.

htpasswd authentication

With apache,you can secure your files and directories in a more simplest way by using any of the authentication methods like basic,digest etc. By using htpasswd one can allow only specific users to access a particular file or a directory like this.

     

  1. Create a file called users and list all the names of the users u want to give access and place it in a location like /etc/httpd/

     

  2. Use the following command:
    root# htpasswd -cm /etc/httpd/users username
    
    • -c is only used the first time
    • For other users you need not use the -c option

     

  3. type the password on prompt

You can notice the file users containing the passwords encrypted

Now add this in httpd.conf file at the end o fthe file


AuthType "Basic"
AuthUserFile /etc/httpd/users
AuthName "Authorisation Required"
require valid-user

 

Whenever a user tries to access /var/www/html/test directory he will be prompted for the username and password and if he is allowed to access only then he will be pe rmitted to enter into the directory and access fiels otherwise he will not be allowed. This is just one way of securing your files with apache.


Roopa Rannorey

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.