Linux Security Measures

1. chmod 400 /etc/shadow
2. chmod 400 /etc/gshadow
3. Modify /etc/ssh/sshd_config to mark 'PermitRootLogin' as 'no'
4. Modify /etc/securetty file to limit the number of shells that the root user can use for login.
5. chmod 644 /etc/profile (ensure owner is root)
6. chmod 644 /etc/environment (ensure owner is root)
7. Modify /etc/shells to keep only /bin/bash shell
8. Modify /etc/passwd for users default shell

Linux Security 101

Partitions:
- Mount "/" (root) partition read only and make symbolic links to other trees that are read-write
- Enable read only (ro) on selected file systems such as /boot (which does not change much),
  that way even the root user cannot modify the files without remounting the file system as rw
- Set partitions like (/tmp, /usr, /home) as no SUID or GUID partitions
  This also allows to restore parts of the filesystem without affecting the other parts.
- Allow users to work on system and access files on system and use applications on system,
  but never have access to the core operating system partitions and assoiciated file system within it.
- Edit /etc/fstab file to secure mounted file systems
- Ensure that file system uses a journaling system, such as ext3/reiserfs
- Avoid auto-mounting file systems if not needed.
 - Hackers might mount a floppy drive/usb/jazz drive on the system
 - Users might remount the ro (read-only) file systems into rw (read-write)
 - Lock down users mounting capabilities by controlling the /etc/fstab file
- Do not allow all users to mount file systems
- Disable running of executables in some filesystems, such as /home or publicly available filesystems.

Software:
- Install only what is required.
- By default Linux is going to install that will make it as usable as possible.
- Dont install development tools unless you plan to develop software
  - These include compilers, kernel source files, scripting engines, etc.
  - Installing a program from source will require compiler, kernel source files, etc which will be required to build that software.
    In such case, one should make it a standard practice to build the software on another system and upload the binaries.
    Keeping the production system free from all the development software.
  - Hackers can hack into the system write a malicious software and compile a binary if dev tools exist!
- Install packages from trusted binaries only.

* NO DEVELOPMENT SOFTWARE ON PRODUCTION SYSTEM!

Installation Security Configuration:
- Configure system to start in text only (Runlevel 3) mode instead of GUI
- Configure linux firewall options

Post Install Actions:
- Patch the system with latest vendor security patches and updates.
  - If you have kernel updates on the system that need to be installed, its important to wait till after the system successfully boots once to a user session
    before you install that particular upgrade or it could cause some issues with the bootloader or some of the configurations there.
  - So, if you want to update a kernel, do it before you install the OS or after a successful boot into a user session.
- Virus scan box before connecting to production network
- Do not have the system connected to the network until it has virus scanning capabilities
- Install other system protection suits
- Baseline the system after all the installations are done. This will include doing backups, verifying config and finally running Tripwire.
  After the baseline, Tripwire can monitor the system for changes.

Securing GRUB:
-Unsecured GRUB can allow unauthenticated users to run commands at boot time.
-GRUB allows bootloader password to be set and encrypted using MD5 hash
-/boot/grub/grub.conf

Security with User Accounts and Groups:
- Root UID = 0
- System UIDs: 1-100 (or 1-500 is some distros)
- User IDs upto 65536 possible
- Root group: GID = 0
- Secure the /etc/shadow files by assigning permissions of 400 to file - root is owner by default
shell > la /etc/*shad*
-r-------- 1 root shadow 656 May 23 11:51 /etc/gshadow
-r-------- 1 root shadow 993 May 23 11:57 /etc/shadow

-Force users to change passwords during first logons and then regularly within certain time intervals

Password Guidelines:
- Minimum 8 characters because anything less than 7 can be pattern identifiable.
- Minimum 14 characters for privileged accounts, this can push brute force attacks into years to crack them.
- Must not contain username in any shape or form and it should not contain any dictionary or guessable words (like P@$$w0rd)
- Must contain at least one each of the following types of characters: lowercase letter, uppercase letter, number and special character.
- Should not contain more of same character 3 times in succession.
- Passwords should be changed frequently (90 days)
- Do not allow users to change passwords again immediately after a password change
  - force a delay between changes (say 5 days) so that they just cannot cycle back through all of their previous passwords.
- Dont allow reuse of same password (hackers can wait for the same password pattern to reappear to attack)
- All the above complex requirements can be enforced using PAM (Pluggable Authentication Modules)

Use of Privileged Accounts:
- Practice 'principle of least privilege'
- Users should only have enough privileges to do a job - nothing more than that
- Limit remote login of root and other privileged accounts because we dont want to pass the password over the network.
  It could be sniffed.
- Limit direct login of privileged accounts.
  - Because there could be auto startup processes which are probably going to be executed under that user's privileges and rights.
    So, if we login with root, we open ourselves up to a lot of automatic startup issues that could affect the system.
  - We want to stick to the principle of least privilege
  - On an average work week sys admins do not require root privileges for a lot of things.
- Use 'su' or 'sudo' commands; sudo is preferred due to tighter security.
  - Using this we can temporarily gain privileged access to complete one or more tasks and then drop back.
  - This prevents unauthorized use / abuse of a privileged account.
- Authorized users and tasks for sudo are located in /etc/sudoers file
- Use of sudo is logged for accountability in syslog file
- Users should 'su' or 'sudo' to root or other privileged account, perform task, and then switch back to non-privileged account.
  - The syslog file is protected in a secure links configuration
- Restrict /etc/securetty to prevent unauthorized use of root account. We can limit the number of terminals available to be logged in by root.
  - Remove unwanted virtual consoles from /etc/securetty file. By default there are many.
  - tty = teletypewriter - it refers to the terminal that is running the process. (man tty)
  - pts = pseudo terminal - similar to above. (man pts)
  - When someone telnets into your system, linux sets up a pair of terminals - a master and a slave.
    The terminals live in the directory /dev/pts/ of the appropriate host and is named for the terminal number. i.e. /dev/pts/0

Securing Shells and Profiles:
- There are a lot of profile settings enabled by default for default users that are probably not necessary.
  Remove all the unnecessary things and only provide whats needed.
- Change /etc/skel as first step as it contains default settings for new users; will not affect previously created users.
- Global configuration settings can be stored in /etc/profile and /etc/environment.
  - Restrict permissions on these files to 644
- Local (user) initialization files usually located in user's home directory. They are responsible for cranking up components.
  Make sure to restrict them so that users are not going to startup software or other malicious components.
  - .login, .profile, .cshrc, .bashrc, .bash_profile, .bash_aliases, etc
   - These things control the shell settings, the path to the startup shell, any startup options associated with that as well as command aliases
     that might be used by that user. This is something that can greatly affect the security of your system because of the large scope of effect it
     can have when that user session is activated.
   - We should keep tight control over this and be aware what is contained in these files.
   - Files should be owned by user or root, and permissions set as no more than 740 to prevent unauthorized modifications of those files
     and to ensure that we can maintain them as root.
  - Path variables should not include a '.' or '::' to prevent executing commands in root directory.
    - The '.' or '::' generally indicate jumping over to a different directory. We should lock them down to the associated pass with the user and not allow
      to traverse as directories into less secure areas.
- Restrict use of unnecessary shells.
  - Users dont need access to several different shells, bash is sufficient.
  - Modify /etc/shells file to only contain authorized shells (ex: /bin/bash)
  - We should not have installed any additional shells in the first place! So, we should restrict those software packages.
  - We can also restrict certain users from logging in by specifying /bin/false as default shell

Network Security

    
Attacks:
1. TCP/IP Attacks
2. Denial-of-Service Attacks
3. Spoofing attacks
4. Man-in-the-middle data interception and modification attacks

Checklist:
- Place webserver in network separate from production network (DMZ or perimeter network)
- Use separate address space/subnet
- Use secure border devices (firewall, external filtering router) to stop unauthorized access
- Limit inbound/outbound ports and protocols through firewall directed at web server
- Filter IP source addresses allowed to access servers ('blacklist' IPs)
- Whitelist IPs
- Filter applications allowed through firewall to server - limit to http, ssh, etc
- Don't run extraneous apps on server if not necessary(eg: SMTP, ftp, etc...)
- Encrypt authentication data and sensitive data to/from webserver by using SSL, ssh, IPSec, etc to prevent man-in-the-middle attacks
- Keep webserver/application server/database server on separate boxes if possible - use multi-tiered configuration

  

Tomcat Security

  
Checklist:
1. Create custom account for Tomcat/Mongrel (app servers) with minimal system privileges (does not require root privileges to run)
2. Define users (configured realms) who can access Tomcat services in web.xml file and secure the file.
3. Configure passwords in tomcat-users.xml file and protect file with proper permissions.
4. Ensure the Java Security Manager is running to control Tomcat security aspects
5. Security configuration file is catalina.policy file and can be used to configure settings for permissions to application objects

 

MySQL DB Security

  
Checklist:
- Remove anonymous access to database
- Create a secure complex root password
- Execute in chroot-ed environment
- Remove sample databases and tables
- Set proper permissions and roles to database objects
- Protect databases from SQL injection by limiting input and bounds checking (restrict datatypes and length, check for illegal characters)
- Disable direct remote access to database server - DB administration should be local
- Apply all vendor security patches

  

 

chroot (application sandboxing)

    
A chroot jail presents a dramatically restricted view of the filesystem to an application, and usually far fewer system privileges, and this all intends to limit the damage should the application go awry or be subverted by the bad guy.

Background:
The chroot system call changes the root directory of the current and all child processes to the given path, and this is nearly always some restricted subdirectory below the real root of the filesystem. This new path is seen entirely as "/" by the process, and we refer to this restricted environment as the "jail". It's not possible to escape this jail except in very limited circumstances.
The chroot system call is found in all versions of UNIX that we know of, and it serves to create a temporary root directory for a running process, and it's a way of taking a limited hierarchy of a filesystem (say, /chroot/named) and making this the top of the directory tree as seen by the application.

References: http://unixwiz.net/techtips/chroot-practices.html

 

apache2 security

  
Checklist:
1. Protect/Lock down configuration files to prevent modifications
2. Restrict access to key directories and files (chroot Apache's environment)
3. Validate all user input through field-size limitations, check for illegal characters, limit input range
4. Use only server-side validated data - dont rely on user-supplied input
5. Use name-based virtual hosting whenever possible - limit use of IP addresses
6. Log all requests and review logs daily
7. Limit other services (FTP)
8. Set owner of Apache directories to root - ensure permissions are no greater than 755
9. Create unique account (with unique UID/GID) for Apache - don't use other accounts and groups
10. No shell programs should be present in Apache's chroot-ed environment
11. Backup apache2.conf file and other files and alter for more secure settings
11. Use only those modules that are absolutely necessary for the server to function:
eg) http_core, mod_access, mod_auth, mod_dir, mod_log_config, mod_mine
12. Use other mods if necessary
13. Install apache to its own partition if possible

 
 

inetd

What is inetd?

In traditional Unix scenarios, one server (daemon) process watches for connections on a particular port, and handles incoming requests. Now if a machine offers many services, many daemon processes would be needed, mostly running idle but still wasting resources like memory. The internet super server, inetd, is an approach to this problem. It listens on a number of ports, and when it receives a request it then determines which program to run to handle the request and starts an instance of that program.
Following is a very simple diagram to illustrate inetd(8):

  pop3  ------    |
                      |
  ftpd -------     | INETD | ---- Internet / DMZ / Switch / Whatever . . .
                      |
 cvsupserver -  |

In the above diagram you can see the general idea. The inetd process receives a request and then starts the appropriate server process. What inetd is doing is software multiplexing. An important note here, regarding security: On many other UNIX-like systems, a package called tcpwrappers is used as a security enhancement for inetd.

Configuring inetd - /etc/inetd.conf

The operation of inetd(8) is controlled by its own config file, named /etc/inetd.conf, see inetd.conf(5). The inetd.conf file basically provides enabling and mapping of services the systems administrator would like to have multiplexed through inetd(8), indicating which program should be started for incoming requests on which port.
inetd.conf(5) is an ascii file containing one service per line, and several fields per line.
The basic field layout is:

service-name socket-type protocol wait/nowait user:group server-program arguments

Services - /etc/services

The next file to consider is the service name data base that can be found in /etc/services. This file basically contains information mapping a service name to a port number.
The format of the /etc/services file is:

service-name port-number/protocol-name [aliases]

"service-name" is the name of the service, "port-number" is the port number assigned to the service, "protocol-name" is either "tcp" or "udp", and if alias names for a port are needed, they can be added as "aliases", separated by white spaces.

Let's take a look at the "ssh" entries as an example:

ssh             22/tcp           # Secure Shell
ssh             22/udp

As we can see, from the left, the service name is "ssh", the port number is "22", the protocols are both "tcp" and "udp". Notice that there is a separate entry for every protocol a service can use (even on the same port).

Protocols - /etc/protocols

Another file read by inetd(8) is /etc/protocols. This file has the information pertaining to DARPA Internet protocols. The format of the protocols name data base is:

protocol-name number [aliases]

where "protocol-name" describes the payload of an IP packet, e.g. "tcp" or "udp". "number" is the official protocol number assigned by IANA, and optional alias names can be added after that. Let's look at the seventh entry in the /etc/protocols db as an example:

tcp     6       TCP             # transmission control protocol

Remote Procedure Calls (RPC) - /etc/rpc

The rpc program number data base used by services with the "rpc" protocol type in inetd.conf(5) is kept in /etc/rpc and contains name mappings to rpc program numbers.
The format of the file is:

server-name program-number aliases

For example, here is the nfs entry:

nfs             100003  nfsprog

Allowing and denying hosts - /etc/hosts.{allow,deny}

NetBSD's inetd(8) has the tcpwrapper package built in via the libwrap library. As such, inetd(8) can allow or deny access to each service on a more fine-grained base than just allowing a service to everyone, or not enabling it at all. The access control is defined in the files /etc/hosts.allow and /etc/hosts.deny


Securing the configuration files - 
 1.  Change the permissions on this file to 600
root shell > chmod 600 /etc/inetd.conf

2.  Ensure that the owner is root.
root shell > stat /etc/inetd.conf
3.  Edit the inetd.conf file vi /etc/inetd.conf and disable 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

root shell > killall  -HUP inetd

4. One more security measure you can take to secure the inetd.conf file is to set it immutable, using the chattr command. To set the file immutable simply, execute the following command:

root shell > chattr  +i /etc/inetd.conf

This will prevent any changes accidental or otherwise to the inetd.conf file. A file with the immutable attribute set i cannot be modified, deleted or renamed, no link can be created to this file and no data can be written to it. The only person that can set or clear this attribute is the super-user root. If you wish later to modify the inetd.conf file you will need to unset the immutable flag: To unset the immutable flag, simply execute the following command:

root shell > chattr  -i /etc/inetd.conf

References: 
http://www.netbsd.org/docs/guide/en/chap-inetd.html
http://www.faqs.org/docs/securing/chap5sec36.html


  

Saas Application Security

    
Whom to Secure?
1. Server Operating System
2. Web application
3. Apache webserver and its applications
4. Databases
5. Attached Network

Attacks:

1. DOS (Denial of Service) Attacks

2. Directory or file permissions

3. Site Defacements

4. DNS Poisoning (indirect attack)

5. Exposure of internal servers from website entry point

6. Replay Attacks (prevent by timestamp usage)

7. Relay Attacks.

8. AJAX requests security

9. CSRF (Cross Site Request Forgery)

10. SQL Injection Attacks

11. File Security

Testing Tools:

1. Banner grabbing to determine webserver software

2. Use of Nikto, Whisker, N-Stealth, Metaspoilt, or other security testing tools.

3. Web Inspect

4. Black Widow

5. Web Sleuth

6. Input field manipulation

7. Cross Site Scripting (XSS)

Check Lists:

- Search for lax permissions on directories and files

- Look for insecure scripts and applications on server

- Applications running under higher-level privileges than necessary - often 'root'!

- CGI, Java or other script vulnerabilities

- Lack of input validation checking

- Improper permissions set on application files - allows remote user to browse,

execute or modify files

- Buffer Overflows

- Lock down application files and directories

- Only run applications with minimum permissions required to perform functions

- Database access to all users?

- Sanitize user inputs before storing to database and sanitize objects before displaying on GUI
- Ensure all unnecessary services are turned off through inetd and/or TCP_WRAPPERS

- Mount publicly accessible partitions as read-only
- Restrict use of suid to trusted processes and users
- Restrict remote management/connections to ssh only no XDMCP or telnet
- Block incoming 'ping', Ping storms are a common DOS attack.

Do's and Dont's:
1. Always use sftp to transfer files (do not use ftp, rlogin, and other unencrypted protocols). The user/pwd information in non-secure protocols are sent as clear text and anyone can sniff them using various network sniffing tools.
2. Use ssh to login to remote machines.
3. Never login to your root account directly unless really required. Login to another account and then switch to root user whenever necessary (shell > su root)

Other Tools:
1. Bastille (hardening program) to provide automated, secure configuration for linux based servers

List of Ethical Hackers / Pen(etration) Testers:

Nikto2

N-Stalker The Web Security Specialists

Web Application Security Testing - Netcraft

wiretrip.net - rain forest puppy

Penetration Testing | The Metasploit Project

Top 10 Web Vulnerability Scanners