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.
| Contents |
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 set using the chmod command and 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
Unix has many tools that can impore security if used properly by users and administrators.
Passwords
Selecting a strong password and guarding it properly is probably the most important things a user can do to improve Unix security. 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. See: password shadowing
The shadow file usually only contains the first two fields:
xfze:$1$zuW2nX3sslp3qJm9MYDdglEApAc36r/:::::
Users and accounts
Administrators should delete old accounts promptly.
- 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?)
Services
Only run the services that are 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
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 security
rwe set-uid set-gid sticky
General
sniffers + plaintext
- tcpdump, ethereal
attacks
- man in the middle attack
- land ping of death xmas DoS et al.
Advanced
- rootkits, kernel modules, chkrootkit
- exploit details, buffer overflows, local vs remote
- Security-Enhanced Linux
Service details
- banners
- smtp - spam
- sendmail - banners help header version etc.
- domain name system - reverse mapping dnssec