Transcript UNIX Technical Auit

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…)
Unix Files and Directories (Cont.)
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 - 4
write - 2
execute - 1
Unix Files and Directories (Cont.)
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: 666
umask : 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).
Unix Files and Directories (Cont.)
 Default File Permissions: umask







Umask
Umask
Umask
Umask
Umask
Umask
Umask
022
003
022
023
027
037
077
>>>
>>>
>>>
>>>
>>>
>>>
>>>
-rwxrwxr-x
-rwxrwxr—
-rwxr-xr-x
-rwxr-xr—
-rwxr-x--- good
-rwxr----better
-rwx-----best
Sample umask Values and File Creation
Permissions
If umask
value set to
User
permission
Group
permission
Others
permission
000
all
all
all
007
all
all
none
027
all
read / execute
none
umask value
Security level
Effective
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
Common Network Services (cont.)
 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)
Common Network Services (cont.)
 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)
Common Network Services (cont.)
 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
Common Network Services (cont.)
 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!