Unix security

Unix security, maintaining a secure environment on Unix and Unix-like operating systems is dependent on design concepts of these operating systems, but vigilance through user and administrative techniques is important to maintain security also.

This entry is currently in a scratch pad form - has lots of bones but no meat - im working on it - feel free to join in.

Design concepts

Permissions

A core security feature in these systems is the permissions system. All files in a typical Unix-style filesystem have permissions set enabling different access to a file.

Permissions on a file are commonly seen through the ls command. For example:

-r-xr-xr-x  1 root  wheel  745720 Sep  8  2002 /bin/sh

Unix permissions permit different users access to a file. Different user groups have different permissions on a file.

User groups

Users under Unix style operating systems often belong to managed groups with specific access permissions. This enables users to be grouped by the level of access they have to this system

Issues

Most Unix style systems have an account or group which enables a user to exact complete control over the system, often known as a root account. If access to this account is gained by an unwanted user, this results in a complete breach of the system. A root account however is necessary for administrative purposes, and for the above security reasons the root account is seldom used for day to day purposes, so further vigilance is able to be taken to root account usage

User and administrative techniques

Passwords 1. Patching 2. Users and accounts 3. Services 4. File system security

Passwords

In Unix systems passwords are usually stored under the file /etc/passwd. Actually this file stores more rather than just passwds, it keeps track of the users registered in the system and their main definitions. The entries in /etc/passwd are like this:

nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin

An example would be: xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:1000:100:José Carlos D. S. Saraiva:/home/xfze:/bin/bash

But as all users must have access to this file in order to the system compare the password given at the login prompt with the one stored in the file, one security issue was raised: anyone could have acess to the file and retrieve other users' password hash. To solve this problem the protected file /etc/shadow was created to store the passwords, this way in the /etc/passwd the 2nd field (password hash) is replaced by an 'x' which tells the system to retrieve the corresponding user's password via the shadow file.

The shadow file usually only contains the first two fields:

xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:::::

users

delete old accounts su, sudo, wheel on bsd, /etc/securetty, ssh only, no root logins

Patching

source rpm based deb based freebsd ports and packages meta - apt, rhn, red carpet

add gentoo, slack, net + openbsd solaris + propriety (sco? who cares)

Services

only run what is needed remove the rest (even better do this at install - only choose necessary packages)

Identify what services are running netstat -na lsof nmap

on *bsd sockstat -4

inetd xinetd

turning off unnecessary services

using chkconfig on rh using /etc/rc.conf and /usr/local/etc/rc.d on freebsd (mention /etc/rc.local)

File system

rwe set-uid set-gid sticky

General

crypto layer 7 gpg/pgp layer 4 ssl/tsl/ssh/stunnel/smime layer 3 ipsec (pptp?)

sniffers + plaintext tcpdump, ethereal

attacks monkey in the middle land ping of death xmas DoS et al.

Advanced

rootkits, kernel modules, chkrootkit exploit details, buffer overflows, local vs remote

Service details

banners smtp - spam sendmail - banners help header version etc. dns - reverse mapping dnssec