Auditing Networks, Perimeters and Systems

Copyright 2001 Marchany 1

Auditing Networks, Perimeters and Systems

Unit 5: Audit Checklist using CIS Rulers: Procedural, Perimeter, and UNIXThe SANS Institute


Applying TBS to the real world! Top Ten Vulnerabilities, the vulnerabilities

responsible for most hacks Apply TBS as an approach to an effective

understandable security policy– Basics– Perimeter– Unix– NT– Windows 2000


The TBS Audit Layers A complete IT audit is a set of component

audits. You should be able to measure E, D and R times for each layer of the security architecture.

Components– Procedural: E = D+R– Perimeter(Firewall): E = D+R– UNIX: E = D+R– NT/Windows 2000: E =D+R


CIS Rulers Rulers list a set of minimal actions that need to be

done on a host system. This is a consensus list derived from security

checklists provided by CIS charter members (VISA, IIA, ISACA, First Union, Pitney Bowes, Allstate Insurance, DOJ, Chevron, Shell Oil, VA Tech, Stanford, Catepillar, Pacific Gas & Electric, RCMP, DOD CIRT, Lucent, Edu Testing Services and others)

Can’t develop your own set? Use these! http://www.cisecurity.org


CIS Rulers: A Security and Audit Checklist Level 1

– Mandatory Actions required regardless of the host’s location or function.

Level 2– Dependent on your network topology– Different for switched nets vs. shared nets vs.

wireless nets, etc.


CIS Rulers: Security Checklist & Audit Plan Level 3

– Application Specific (WWW, FTP, DB, Auth) Procedural

– Examines the policies in place.– This is the policy review checklist.

FTP WWW DB MailSwitched Wireless Non Switched

LEVEL 1

Level 3Level 2


CIS Rulers: Procedural General Administration Policies Key security tool installed User Accounts and environment System Logs Network File sharing General Email Issues This review is done during the Audit

Planning Phase of the audit process


CIS Ruler: Procedural General Administration Policies

– Acceptable Use Policy– Backup Policy– Security Administrator duties– Whois Contact Information (Tech/Admin)– System changelogs (Source Revision Control)– Incident Response– Minimum software requirements– User, temp, system account policies– Patches


CIS Ruler Example: Backups

· Does a backup policy exist?· Do backup logs exist?· What data is backed up· How often data is backed up· Type of backup (full, differential, etc.)· How the backups are scheduled and verified· How the backup media is handled and labeled· How the backup media is stored· How long the backup media is retained· How backup media is rotated and expired· How backup data is recovered


CIS Ruler: Procedural Key security tools installed

– Network routers implement minimum filtering requirements

– Verify network routers are properly configured and monitored for in/out traffic

– Are all firewalls properly configured and monitored for in/out traffic

– The above rules prevent DDOS attacks from affecting other nets.


CIS Ruler: Procedural User Accounts and Environment

– Remove obsolete user entries from system System Logs

– How long are they kept? Are they secured? Network file sharing

– Review what filesystems this system can access– Review what filesystems this system exports

Email Policy– Abuse Policy?


CIS Ruler: Written Documentation and Policies

Where is it? Is it available to anyone that needs it? Is it up to date? Is anything major missing (SGI policies, but

no HP policies)?


CIS Ruler Example: Security Policy

Purpose - the reason for the policy. Related documents – lists any documents (or other policy) that affect the contents of this

policy. Cancellation - identifies any existing policy that is cancelled when this policy becomes

effective. Background - provides amplifying information on the need for the policy. Scope - states the range of coverage for the policy (to whom or what does the policy

apply?). Policy statement - identifies the actual guiding principles or what is to be done. The

statements are designed to influence and determine decisions and actions within the scope of coverage. The statements should be prudent, expedient, and/or advantageous to the organization.

Action - specifies what actions are necessary and when they are to be accomplished. Responsibility - states who is responsible for what. Subsections might identify who will

develop additional detailed guidance and when the policy will be reviewed and updated.


Procedural: Incident Response Plan Are the six Incident Response steps covered?

– Preparation– Identification– Containment– Eradication– Recovery– Lessons Learned (if there are no lessons learned

documents either the plan isn’t followed or no incidents have occurred).


Acceptable Use Policy


Acceptable Use Guidelines


Procedural: Training & Education Do technical people have the training to do

their job competently? Are there standards their skills can be

measured against? Are there standards of compliance that

ensure they are using their training in accordance with policy?


Procedural: Physical Security Consoles in physically secure areas? Fire suppression? Backups? Offsite backups? Network components secured? Phone wiring secured?


Procedural: Windows 2000 These are based on the SANS “Securing Windows

2000” booklet. Least Privilege Principle Avoid granting unnecessary Admin privs. Limit Domain Trust. Restrict modems in workstations and servers. Limit access to sniffer software (Network

Monitor).


Procedural: Windows 2000 Keep system software updated. Update and Practice a Recovery Plan. Require strong passwords. Require password protected screen savers. Establish Auditing and Review Policies. Require Administrators to have a User and

Administrator account. Require antivirus software. Install host based IDS. Perform periodical low-level security audits.


CIS Procedural Ruler Review Procedural rulers give you a starting point

for determining your site’s policy pie These policies include acceptable use,

privacy, incident response, accountability, backup and any other appropriate action

The CIS procedural ruler is a consensus list of practices done at the charter members sites.


CIS Level 1 Ruler: Unix Patches Key Security Tools Installed System Access, authentication,

authorization User Accounts and Environment Kernel Level TCP/IP tuning Kernel Tuning


CIS Level 1 Ruler: Unix Batch Utilities: at/cron UMASK issues File/Directory Permissions/Access System Logging SSH Minimize network services


CIS Level 1 Ruler: Unix Minimize RPC network services Minimize standalone network services General Email Issues X11/CDE General Administration Policies Specific Servers

– www, ftp, DB, Mail, NFS, Directory, Print, Syslog


CIS Level 1 Unix Ruler - Patches Define a regular procedure for checking,

assessing, testing and applying the latest vendor recommended and security patches.

Keep 3rd party application patches updated. Why?

– The first line of defense is proper patch/Service Pack installation.

– Patches are living and need to be updated regularly


CIS Level 1 Unix Ruler: Security Tools These tools help decrease your detection time,

D Install the latest version of TCP Wrappers on

appropriate network services SSH for login, file copy and X11 encryption Install crypto file signature function to

monitor changes in critical system binaries and config files (tripwire)


CIS Level 1 Unix Ruler: Security Tools Install Portsentry or similar personal FW

software Run NTP or some other time sync tool Run “logcheck” or similar syslog analysis

or monitoring tool Install the latest version of sudo


CIS Level 1 Unix Ruler: Access, Authorization No trusted hosts features: .rhosts, .shosts

or /etc/hosts.equiv Create appropriate banner for any network

interactive service Restrict direct root login to system console Verify shadow password file format is used Verify PAM configuration


CIS Level 1 Unix Ruler: Kernel-Level TCP/IP Tuning System handling of ICMP packets is

secured System handling of source routed packets

secured System handling of broadcast packets

secured Use strong TCP Initial Sequence Numbers Harden against TCP SYN Flood attacks


CIS Level 1 Unix Ruler: Kernel Level Tuning, Batch Utilities Enable kernel level auditing Enable stack protection Ensure ulimits are defined in /etc/profile

and /etc/.login Restrict batch file access to authorized users Ensure cron files only readable by root or

cron user


CIS Level 1 Unix Ruler: UMASK, File Perms, Access

Set daemon umask to 022 or stricter Set user default umask (022 or 027) Console EEPROM password enabled? Check /dev entries for sane ownership and

permissions Mount all filesystems RO or NOSUID All filesystems except / mounted NODEV


CIS Level 1 Unix Ruler: File Perms and Access Verify passwd, group, shadow file perms Verify SUID, SGID system binaries Disable SUID, SGID on binaries only used

by root No World-write dirs in root’s search path Sticky bit set on all temp directories No NIS/NIS+ features in passwd or group

files if NIS/NIS+ is disabled


See what we can find

/usr/bin/find / -local -type f -name '.rhosts' -exec ls -al {} \; -exec cat {} \; 2 (.rhosts)

/usr/bin/find / -local -type f -user root -perm -4000 -exec ls -dal {} \; 2 (SUID files) /usr/bin/find / -local -type f -user root -perm -2000 -exec ls -dal {} \; 2 (SGID files)

find /$-local –o –prune$ -perm –000002 –print

find /name .netrc -print

find / -perm –1000


Audit Report ExampleAudit MethodLs –la (list files) against critical files to determine their permissionsFindingSeveral system configuration files in /etc are writableRisk Level: High

Security Implication The /etc directory is critical for establishing the operating configuration of many system services including startup and shutdown. If an attacker is able to modify these files, it may be possible to subvert privileged operating system commands.

Recommendation Change permissions of all files in /etc to be writable by root or bin only.


/dev Permissions Exhibit# ls –l /devtotal 72-rwxr-xr-x 1 root root 26450 Sep 24 1999 MAKEDEVcrw------- 1 root sys 14, 4 Apr 17 1999 audiocrw------- 1 root sys 14, 20 Apr 17 1999 audio1brw-rw---- 1 root disk 32, 0 May 5 1998 cm206cdcrw--w--w- 1 root root 5, 1 May 26 15:17 consolebrw------- 1 root floppy 2, 1 May 5 1998 fd1brw-rw---- 1 root disk 16, 0 May 5 1998 gscdbrw-rw---- 1 root disk 3, 0 May 5 1998 hdabrw-rw---- 1 root disk 3, 1 May 5 1998 hda1brw-rw---- 1 root disk 3, 10 May 5 1998 hda10brw-rw---- 1 root disk 3, 11 May 5 1998 hda11brw-rw---- 1 root disk 3, 12 May 5 1998 hda12brw-rw---- 1 root disk 3, 13 May 5 1998 hda13brw-rw---- 1 root disk 3, 14 May 5 1998 hda14brw-rw---- 1 root disk 3, 15 May 5 1998 hda15brw-rw---- 1 root disk 3, 16 May 5 1998 hda16


World-Writeable and SUID/SGID Files

Audit MethodFind commands were executed on the servers to locate all files with world-writeable permissions and SUID/SGID permissions. The output was redirected to appropriate files for later analysis. FindingA large number of world-writeable and SUID/SGID files were found on the server XYZ. Further, a number of files in the /usr, /opt and /var directories allow all users to have write permission. Security Implication World-writeable files allow any user or an intruder to change the contents of a file, effecting information integrity. Also, for executable files, an intruder may replace the file with a trojan horse that can damage the system and its integrity. SUID/SGID files execute with the privilege of the owner/group. These can be subverted by an unauthorized user or intruder to escalate their privilege to those of the owner/group of the SUID/SGID file. Risk Level: High Recommendation Review all world-writeable and SUID/SGID files on the system. Using freeware tools like fix-modes or YASSP can facilitate identifying and correcting the permissions on files. After the review, create a list of all the remaining “approved” World-writeable and SUID/SGID files on the system and store in a secure place. Periodically, check the system against this list to identify changes and ensure that such changes are approved. NFS shared files, especially files in /usr, /opt and /var should be exported ‘read-only to specific hosts. Further, through /etc/vfstab, the exported file systems (except special cases like /tmp, /dev and /) should be mounted with the nosuid option to prevent the inadvertent granting of SUID privilege on NFS mounted files.


CIS Level 1 Unix Ruler: System Logging and SSH Capture messages sent to syslog AUTH

facility (enable system logging) Copy syslogs to central syslog server Audit failed logins and SU attempts Enable system accounting Logins allowed via SSH only (no rsh,

rlogin, ftp or telnet)


CIS Level 1 Unix Ruler: Reduce Services (/etc/inetd.conf) Disable name (UDP) Disable exec/rexec (TCP) Disable login/rlogin (TCP) Disable uucp (TCP) Disable systat (TCP) Disable netstat (TCP) Disable time (TCP/UDP)


CIS Level 1 Unix Ruler: Reduce Net Services (/etc/inetd.conf) Disable echo (TCP) Disable discard (TCP/UDP) Disable daytime (TCP/UDP) Disable chargen (TCP/UDP) Disable rusersd (RPC) Disable sprayd (RPC) Disable rwall (RPC)


CIS Level 1 Ruler: Reduce Net Services (/etc/inetd.conf) Disable rstatd (RPC) Disable rexd (RPC) Use TCP Wrappers for all enabled network

services (TCP/UDP)


Sample /etc/inetd.conf# Shell, login, exec, comsat and talk are BSD protocols.#shell stream tcp nowait root /usr/sbin/tcpd in.rshdlogin stream tcp nowait root /usr/sbin/tcpd in.rlogind#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd#comsat dgram udp wait root /usr/sbin/tcpd in.comsattalk dgram udp wait nobody.tty /usr/sbin/tcpd in.talkdntalk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd

This is a fragment of /etc/inetd.conf where shell, login, talk, and ntalk probably should be commented out. Note the /usr/sbin/tcpd so this system is probably running tcpwrappers. More of the file is in the notes pages.


Output ExampleFingerd running

Audit MethodTelnet localhost 79 to connect with the local system’s finger daemon FindingFingerd is active Risk Level: Low

Security Implication Finger can be used to gain reconnaissance information about the system including the last login time, where a user is logged in from, information about their shell. This information could be used to set up either a social engineering or trust model based attack.

Recommendation If finger is not a business critical application in this environment, disable finger or replace with free tools such as sfinger.


CIS Level 1 Unix Ruler: Reduce RPC Network Services Restrict NFS client request to originate

from privileged ports No filesystem should be exported with root

access Export list restricted to specific range of

addresses Export RO if possible Export NOSUID if possible


CIS Level 1 Unix Ruler: Email, X11/CDE Use Sendmail v8.9.3 or later. (v8.11.4 is

current 6/15/01) Restrict sendmail ‘prog’ mailer Verify privileged and checksums for mail

programs Ensure X server is started with Xauth Use SSH to access X programs on remote

hosts


CIS Level 1 Unix Ruler: User Accts, Environment Enforce strong passwords No null passwords Remove root equivalent users (UID=0) No “.” in root PATH No .files world or group writable Remove .netrc, .exrc, .dbxrc files User $HOME dirs should be < 755


TBS Example Using E=D+R •Security policy: automated script to check password file for users with UID 0 (superuser access) returns user ”zippy”.

•Syslog is checked:Apr 15 21:07:59 6C: goodnhacked.com telnetd[5020]: connect from some.comApr 15 21:08:18 6E: goodnhacked.com login[5021]: [email protected] as zippy

•IDS returns:21:07:16.63 badguy.com.26617 > goodnhacked.com.5135: udp 21:07:16.66 goodnhacked.com.5135 > badguy.com.26617: udp 69

5135 is SGI Object Server with a known vulnerability


CIS Level 1 Ruler Review The previous action items should be done

on any Unix system on your network regardless of its function

A similar checklist is being developed for Windows 2000.

The Level 1 rulers impose a minimum security standard on all Unix and Windows 2000 systems.


CIS Level 2 Rulers Once Level 1 rulers have been applied, you

pick the appropriate Level 2 ruler. This is very organization specific. What

works at my site might not apply at yours. Additional service may be disabled if they

aren’t needed.


CIS Level 2 Ruler: Unix Kernel-level TCP/IP tuning Physical Console Security SSH Minimize network services Minimize RPC network services General email issues X11/CDE


CIS Level 2 Ruler: Unix Kernel Tuning

– Network options for non-router machines– Disable multicast

Physical Console Security– Enable EEPROM password. Who knows it?

SSH– Restrictively configure it


CIS Level 2 Ruler: Unix Minimize Network Services

– Disable inetd entirely– Disable FTP– Disable Telnet– Disable rsh/rlogin– Disable comsat– Disable talk– Disable tftp


CIS Level 2 Ruler: Unix Minimize network services

– Disable tftp– Disable finger– Disable sadmin– Disable rquotad– Disable CDE Tooltalk server (ttdbserverd)– Disable RPC/UDP/TCP ufs– Disable kcms_server


CIS Level 2 Ruler: Unix Disable fontserver Disable cachefs service Disable Kerberos server Disable printer server Disable gssd Disable CDE dtspc Disable rpc.cmsd calendar server


CIS Level 2 Ruler: Unix Minimize Network Services

– If FTP service is enabled, see additional level 3 requirements for FTP servers

– If tftp is enabled, use the security option– If sadmind is enabled, use the security option


CIS Level 2 Ruler: Unix Minimize RPC network services

– Disable NFS server– Disable Automounter– Disable NFS client services– Add ports 2049, 4045 to privileged port list– Disable NIS– Disable NIS+– Replace rpcbind with more secure version


CIS Level 2 Ruler: Unix General Email Issues

– Don’t run sendmail on machines that don’t receive mail

– Remove mail aliases which send data to programs (Vacation)

X11/CDE– Disable CDE if not needed– Use the SECURITY extension for X-Server to

restrict access


CIS Level 2 Ruler Review Level 2 rulers are site specific. They are more sensitive to vendor software

requirements. For example, a vendor product may require that you enable the dreaded r-commands. You have no choice so you keep an eye on that vulnerability.

They may impose stricter standards.


CIS Level 3 Ruler Example: Perimeter Defense Scope of Impact – The whole site Probability of Impact – 100% if connected

to the Internet Wide variety of opinions Every site has a Firewall (FW) of some sort.

It may be a packet filtering router or a fancy stateful FW.

What about wireless nets?


Firewalls: Where’s the Threat? FW look to the outside for threats. Can be circumvented by wireless world. Don’t prevent internal attacks. Useless? NO! It’s a component of your layered

defense. Remember the TBS Layered Defense equations.

Personal FW software is GOOD!– Makes wireless nets more secure!

What if crimes are committed by someone inside the firewall.


Firewalls require management. Someone has to manage the firewall.

– Someone has to assure that the firewall is configured properly.

– Someone has to assure that all new applications don’t violate security policies.

– Someone has to review firewall logs.– Firewalls generate a HUGE number of

logs.


Sample Firewall Ruler Firewalls are one part of a layered defense which

should include:– A properly configured border router.– A virus detection solution.– An authentication system for trust management.– Properly configured operating systems and Internet

applications. Personal FW software installed on all hosts.

– An Intrusion Detection System Firewalls require monitoring and change control

management.


TBS and the PerimeterE= D + R Perimeter defenses are the an effective method of “shrinking” D and R and decreasing E.

INTERNET

ISP

E

Front EndCritical systems located on a screened subnet off ofone leg of a firewall.

FirewallDNS Email


Example: D&R at the Perimeter

Oct 12 01:04:26 ucc3.edu 45725: 8w5d^I: %SEC-6-IPACCESSLOGP: list190 denied tcp 202.159.123.192(2235) -> 172.20.8.233(3128), 1 packet

Oct 12 01:10:14 ucc3.edu 45730: 8w5d^I: %SEC-6-IPACCESSLOGP: list190 denied tcp 202.159.123.192(2235) -> 172.20.8.233(3128), 3 packets

This is a log file from a Cisco router on the perimeter, it indicates the router has blocked two attempts to destination port is 3128, the SQUID Proxy. Note: “denied” implies D and R are working. The times are very small!


Pulling the perimeter together Top Ten blocking, egress filtering Additional requirements from your site’s

security policy The notes contain a minimal Perimeter

audit plan!

Top Ten recommendations are shown in notes pages. There are examples of implementations based on this security policy at: http://www.sans.org/giactc/gcfw.htm ( practicals 30 - 35)


Section Review Establishing and testing perimeter defenses

is a good way to reduce D and R time. Top Ten vulnerabilities are generally agreed

to be a priority. Top Ten blocking recommendations are the foundation of a security checklist for perimeters

CVE names help ensure sysadmins and auditors are referring to the same threat


CIS Unix Ruler Review CIS Rulers are a good starting point for

developing a Unix audit plan Level 1 ruler defines minimum security

standards for all Unix systems Level 2-3 rulers are more network and

function specific Procedural rulers address policy issues


Course Revision History

Documents

Auditing Networks, Perimeters and Systems