unix technical audit. unix architecture multi-user, multi-processing system kernel: primary...

UNIX Technical Audit

UNIX Architecture

Multi-user, multi-processing system Kernel: Primary control program Daemons: System control processes

Manages system resources Shared by multiple users Run with Kernel authority

UNIX Architecture (Cont.)

User processes: no special privileges unless specifically defined

Root directory: /

UNIX Users and Groups

User name and password required (pay attention to ‘open’ accounts: user IDs with no passwords)

Each user will have its own home directory

Shell: a program assigned to user Super-user (login name: root): super

user can do ANYTHING

UNIX Users and Groups (Cont.) Administrators should access root via ‘su’

Maintain an audit trail to identify who become root (sulog)

Establish the user’s audit ID which is logged along with their current user ID when running the extended audit facilities

Force administrators to perform functions that could be performed in their personal accounts

Disable ‘root’ is possible but not recommended, but should restrict ‘root’ login via Console only.

UNIX Users and Groups (Cont.)

SVRx vs. BSD version handle group in a different way

Users can only be in one group at a time

User activities are identified by user ID rather than user name

Multiple user with the same UID maybe logged in at the same time

‘Passwd’ file ‘Passwd’ file format:

User:pword:UID:GID:GECOS:home:program Passwd field should be encrypted and stored in

shadow file) (For AIX and Solaris, Shadow is enabled by default, for HP-UX, shadow password is not enabled by default)

All system accounts should be disabled Identify all ‘Open accounts’, accounts with no

passwords Identify users with UID = ‘0’, ‘root’ with UID = ‘0’

UID< 100 system; UID 500 – 1000 application GECOS field should contain NO information

‘Passwd’ file (Cont.)

Application users should not have access to shell (identified from ‘program’ field.)

Shadow Password File

Never located in the world readable /ect/passwd file, owned by root for read/write owner only

Ensure no ‘Open accounts’ Format: lisa:x(*):1000:1000:Lisa

M.:/home/lisa/bin/sh

Password Aging and Other Password Settings

No facility is provided in standard Unix

Most Unix versions provide some methods

May be vendor dependent

Group File Path: etc/group Format: /etc/group: group:pword:GID:user,

user, user,… Anyone knew ‘pword’ can become a

member of the group, THIS SHOULD BE KEPT DISABLED

Only put users in groups created on site. Do not put individual users in groups that came with the system (e.g SAs put themselves into Sys group…)

Unix Documents Sources

System Reference Manuals Vendor Documentatuion Unix Books Manual Commends Format:

uname, whami, mesg, $ man

Unix Files and Directories Each file and directory is assigned one inode:

file type, file size…last modify time (mtime), last inode modified time (ctime), etc.

Ctime: related to permission change Mtime: related to data change Ctime vs. mtime: ‘Except for installation

executables, which typically retain the vendor’s modification date, when ctime is greater than mtime, it probably indicates that a change was made to either the permissions or ownership fields.

Unix Files and Directories (cont.) File and Directories should avoid to start

with certain special characters, such as: space, tab, new line, ‘, ;, \,>,<, |,&, ?, [], *

SUID /SGID Executables Program will execute with the effective UID of

the program owner instead of UID of caller Program will execute with the effective GID of

the program’s group instead of GID of a caller. List all the plain files that have wither SUID or

SGID permission flag set: $ find / \ ( -perm -4000 –o –perm -2000 \) \ -type

f –ls

SUID & SGID (Cont.) Verify that all executables are provided by

a trusted source. Any changes to these executables should

be authenticated (check mtime dates) Verify that no capital S or T flags exist on

executables – usually indicates bad permissions. (capital T will display is no ‘x’ is specified; S specified “mandatory locking”)

No Group or world write permissions. Possible DoS attack.

SUID & SGID (Cont.)

Investigate any user owned executables

Verify that all executables are binary files. SUID shell scripts are very dangerous. Be suspicious of small files or test with the file or type commands

Unix Files and Directories (Cont.)

“File write permission is not required to delete a file. Directory write and execute is all that is needed”

Be careful with ‘wx’ permission at directory level: back door issue. (delete a file, replace file with the same name, change owner…)


umask, as the man page says, stands for User file creation mask which is used for determining the default permission for a new file creation. The new file creation could either be a file creation through a normal process or a file copy. umask command is a shell built-in meaning it is an internal command. The three file permission attributes are read, write and execute. These 3 are mapped to octal values as shown below:

read - 4write - 2

execute - 1


In UNIX, the default file creation value is 666. 6 is 4+2(read + write). Permission 666 means 6 for the User, 6 for the group and 6 for others. Hence, a new file creation by default is meant to have read and write permission for User, group and others. And the default settings for directories is 777. 7 is 4+2+1 (read + write + execute). This is the place where the umask comes into the picture. It is a kind of filter wherein we can choose to retain or block some of the default permissions from being applied on the file.

Say, the umask value is 0022. umask is by default displayed in Octal form, and hence the first 0 in the umask value is the indication for octal value. So, the actual umask is 022. This value together with the default file value(666) decides the final permission to be given to the file.

Default: 666umask : 022---------------

Permission:644

644 is the permission to be given on the sample file. 644 means read and write for the User(644), read only for the group(644) and others(644).


Default File Permissions: umask Umask 022 >>> -rwxrwxr-x Umask 003 >>> -rwxrwxr— Umask 022 >>> -rwxr-xr-x Umask 023 >>> -rwxr-xr— Umask 027 >>> -rwxr-x--- good Umask 037 >>> -rwxr----- better Umask 077 >>> -rwx------ best

If umask value set to

User permission

Group permission

Others permission

000 all all all

007 all all none

027 all read / execute none

Sample umask Values and File Creation Permissions

umask value Security levelEffective permission (directory)

022 Permissive 755

026 Moderate 751

027 Moderate 750

077 Severe 700

Unix Files and Directories (cont.)

Device Files: type code ‘b’ or ‘c’ and located in ‘/dev’ or ‘devices’ firectory

Important System Directories: /etc, /bin, /usr/bin, /sbin/, /dev, /tmp,

/lib, /usr/adm, /var/adm, /usr/ect, /var/etc, /usr/man, /usr/spool

Baseline “A baseline is database of information

about important system files and directories that is compared frequently against the existing system for unauthorized changes.”

“Without a properly maintained baseline and associated change control mechanism, it is impossible to assure that the system has not been compromised.” How change happened? Who made such change? Comparison should be performed on daily basis.

Permission Risk Evaluation System Integrity (root)

Can be compromised if the superuser execute a program or script that can be modified or rejected by another user

Account Integrity (e.g Oracle Database) Can be compromised if user executed program or

program script can be modified or replaced by another user

Data Integrity: Data file can be modified or replaced by another user

Data Confidentiality: Data file can be read by another user

Shells and Processes Verify that the PATH does not contain

a dot or any public directories Verify that all PATH directories are

owned by the user, root or a disabled system account

Exam alias statements for alisaes to an unprotected command

Check any executed commands for proper protection

Processing Scheduling Exam Crontab file:

$1s /var/spool/cron/crontabs Cron.allow & cron.deny files At.allow & at.deny files E.g 0 2 * * * /prod/payroll/daily.backup1 Obtain a list of root’s crontab and the crontabs

of any other critical user No group or world write permissions No user owned executables If the executable is a script – check the script

for the permissions & ownerships of the programs it executes

System Initialization The /ect/inittab file is read and processed in

sequence order by init during initialization and run level changes. Id:rrr:action:command – options parameters /ect/rc2.d (ensure no user owned executables,

should be all owned by root) Plan to exam any script that was modified or

added since installation for the correct permission & ownerships of the programs it executes.

Unix System Logs Login Logs

/var/adm/lastlog /etc/utmp /etc/wtmp

Su Logs E.g Su 12/10 08:30 + tty0 Lisa-root

Syslog Daemon Systlog daemon records messages from many

parts of the system. System log daemon will route the message it

receives according to instructions specified in the /etc/syslog.conf file.

Unix Networking /etc/services: assignment of service to port

& protocol is done with this file. The internet daemon (inetd) initiates

network services on an ‘as needed basis’, when loaded, inetd will read its list of services to manage from /etc/inetd.conf and match these services to the port number in the /etc/services file.

Unix Networking (cont.)

Remote Procedure Call Via ‘rpcinfo’ command

External Data Representation protocol Key control files:

/etc/hosts: /etc/services: (port & protocol) /etc/inetd.conf (Service – Daemon to

start)

Unix Networking (cont.) Key Files (hosts, services, inetd)

Verity that these files are protected and have not been corrupted

Verify that each host listed in /etc/hosts has the correct IP address and does EXIST in the network

Remove every network service listed I the /etc/inetd.conf that is not required, (it is generally acceptable to leave the services in /etc/services alone as this is primary a reference file

Examine the system start-up scripts for network services and remove those that are not required.

Common Network Services Ftp Services:

$HOME/ .netrc: client control file for automatic login from the client to the named server, question the need fot .netrc files that contain passwords, even with owner-only read permission, they are very dangous

Recommend creating a ‘ftp only’ account by giving this account a program to run like ‘/bin/false’ and then adding /bin/false to the /etc/shells files (make it not a valid shell), if .netrc is required because of the automated file transfer.

List all users that should not be ‘ftp’ed to ‘ftpusers’ file, root should be included!

Start the daemon with the –l option to log each login to syslog (daemon.info)

Common Network Services Ftp (cont.)

Anonymous ftp Change /ftp/pub/ directory permissions to d

—x—x—x and then name files and directories inside ‘pub’ to ‘password’ like names that only an authorized user would know

Verify that the ---/ftp/etc/passwd file does not contain any real users or passwords

Isolate the ftp home to its own file system

Common Network Services (cont.)

TFTP (Trival File Transfer Protocol) No authentication of the user, ‘get and send

functions only’ Verity the service is required or ‘disabled’ Must stay in its restricted directory

Test: $ tftp hostname tftp > get /etc/passwd If hangs, tftp is disabled Access denied, runs restricted Xxx bytes transferred : WARNING!

Verify tftp runs as ‘nobody’ – check /etc/inetd.conf file

Common Network Services (cont.) Smtp

/ect/sendmail.cf – sendmail control file /ect/aliases – Mail redirection file $HOME/ .forward – User forwarding file Smtp socket must run as root, the risk is that some

one can take over smtp and run as root Unless it is required, smtp should be disabled If outbound mail is all that is required, remove the –

bd options from the sendmail start-up command by checking system start-up script. This will allow outbound mail but disables the daemon mode.

If daemon mode is required, verify that sendmail is current to all patches


Remote Execution with Telnet Telnet client .telnetrc files can be used to

trace all keystrokes – Caution!

Common Network Services (cont.) Remote Execution with rlogin and rsh

Be careful with concept of ‘trusted’ Trust host System wide trusted user /etc/hosts.equiv and .rhost files

Security Considerations: Ban trusted users in /etc/host.equiv Any trusted hosts in /etc/host.equiv requires that user

names be consistent on client and server and that all disabled accounts be doubly disabled with /dev/null

Strongly consider banning all .rhosts files Strongly consider replacing rlogin & rsh services with

Open Secure Shell (sshd)


rlogin & rsh (cont.) If it is verified that a root .rhosts file is

required, it is mandatory that trusted host(s) listed in the .rhosts file be INCLUDED in the audit because the security of the system is only as good as the security of the trusted host(s)


Remote Execution with ssh & scp Designed to replace the Berkeley “r” commands Prevent sniffing by encrypting the data

exchange Assure the server contacted is the correct server Prevent ‘man in the middle’ attack Restrict account activity to a specific command

by using the ‘forced command’ public key option Provide a secure channel using ‘sftp’ Provide for port forwarding which allows for

better security of normal insecure data transfers such as ‘X’ windows, mail and others


SSH (cont.) Protect users’ private key Using agent may create an opportunity

for ‘impersonating’ from users’ systems Disable rlogin and rcp if ssh has been

implemented (e.g delete /etc/hosts.equiv file and replace with /ect/shosts.equiv file)

Network File Sharing (NFS)

Control files: Server: /etc/exports or /etc/dfs/dfstab

(several control files listing the directories and restrictions)

Client: /etc/fstab or /etc/vfstab or /etc/filesystms (client control file listing the directories and mount options)

Network File Sharing (NFS) (Cont.)

Security Considerations: The client must mount the directory as ‘nosuid’

to prevent possible server attack Consistent network wide UIDs and GIDs Servers must export the directory to only

authorized clients to prevent unauthorized mount. (always use ‘access = option’ in /etc/exports file

Avoid client root access unless read-only (anon = or root = value in the server control file)

Avoid exporting system or critical directories unless read-only

Unix Based System Comparison

Using of restrict shell AIX: /usr/bin/Rsh Solaris: /usr/bin/rksh HP-UX: /usr/bin/rksh Tru64: /usr/bin/Rsh Linux**: /usr/bin/bash –r Others: check manual for ksh

Unix Based System Comparison (Cont.)

Access Control List AIX: $ acledit myfile HP-UX: chacl Tru64: setacl Solaris + Linux: setfacl

Unix Based System Comparison (Cont.)

Unix System Comparison

Q? Thank You!