ITIS 3110 System Hardening

system hardening Act of modifying a system to make it more secure Protecting against internal and external threats Usually a balance between security and usability More usability  less secure Higher security  harder to use Balance required is different for every organization

hardening practices Removing unneeded: Privileges Applications Services Updating installed packages on a regular basis Maintaining user lists with up-to-date information Providing an audit trail Detect changes in files and behaviors

nsa security guides The NSA publishes security guides for various operating systems and applications Linux guide is written for Red Hat Enterprise Linux 5 Guide can be adapted for other Linux distributions

nsa security guides Guides are just a reference Never follow them without understanding what you are doing Many of the security recommendations may not make sense in your environment Adapt and modify as needed

nsa security guides http://www.nsa.gov/ia/mitigation_guidance/security_config uration_guides/index.shtml

vulnerability databases Vulnerability databases are an important resource for determining if your software needs to be patched Often contain mitigation information as well as available update paths

vulnerability databases http://www.cert.org http://www.us-cert.gov/cas/techalerts/index.html http://nvd.nist.gov Interesting article: http://www.cio.com/article/730250/US_NIST_39_s_Vulnerability_Database_Hacked

Typical Resources to Monitor

inetd inetd is the Internet “super-server” A super-server listens to network ports and starts the appropriate server when a connection is received Configuration is in /etc/inetd.conf Note: xinetd is the new improved version

/etc/inetd.conf One service per line 7 tab-delimited fields Lines can be commented out by preceding with a # 7 tab-delimited fields service-name socket-type Protocol wait|nowait User server-program server-args “The wait/nowait entry specifies whether the server that is invoked...will take over the socket...and thus whether inetd should wait for the server to exit before listening for new service requests.” (man inetd)

/etc/inetd.conf service-name socket-type protocol wait | nowait user server-program server-args ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l #ntalk dgram udp wat root /usr/libexec/ntalkd ntalkd telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd

xinetd Secure replacement for inetd Configuration is stored in /etc/xinetd.conf and /etc/xinetd.d/ Most services have their own file in the configuration directory Allows services to be added when a package is installed

xinetd Configuration files allow both enabled and disabled keyword Convention is to only use disabled keyword On Red Hat-like systems chkconfig can control xinetd services

/etc/xinetd.d/tftp } service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s /tftpboot disable = yes }

disabling services Red Hat Debian Standard Service inetd xinetd chkconfig update-rc.d inetd - update-inetd xinetd edit manually

Elevated Privileges

su switch user “Anyone can use” su [options] [commands] [-] [username] If no user specified root is assumed “Anyone can use” Still must know the password  all administers for the system must share the password  Don’t know who changed something while root

sudo sudo allows a user id to perform actions as root or another user sudo -V | -h | -l | -L | -v | -k | -K | -s | [ -H ] [-P ] [-S ] [ -b ] | [ -p prompt ] [ -c class|- ] [ -a auth_type ] [-r role ] [-t type ] [ -u username|#uid ] command sudo -V | -h | -l | -L | -v | -k | -K | -s | [ -H ] [-P ] [-S ] [ -b ] | [ -p prompt ] [ -c class|- ] [ -a auth_type ] [-r role ] [-t type ] [ -u username|#uid ] command sudo -V | -h | -l | -L | -v | -k | -K | -s | [ -H ] [-P ] [-S ] [ -b ] | [ -p prompt ] [ -c class|- ] [ -a auth_type ] [-r role ] [-t type ] [ -u username|#uid ] command sudo sudo allows a user id to perform actions as root or another user More flexible than su which is all or nothing Authenticates user with their password su requires user to know root or other user’s password Can filter which actions they may perform Simplified syntax: sudo command Executes command as root (if set up)

sudo All root-level work should be done using sudo Allows tracking of what users were using root privileges Configuration is in /etc/sudoers sudoers should be edited with visudo checked after editing with visudo –c

sudoers syntax user hosts = (runas) commands Can have aliases for each One or more users (or %group) hosts List of hosts (or ALL), eg. Remote machines allowed to run on runas List of users (or ALL) that can run as for the command Groups can follow a : Root is default commands List of commands (or ALL) that can be run as root Can have aliases for each

/etc/sudoers #%group hostlist=(runas) cmd %wheel ALL=(ALL) ALL #user hostlist=(runas) cmd rgharaib ALL=(ALL) /etc/init.d/maui [a-z]* rgharaib ALL=(ALL) /sw/torque/bin/pbsnodes -[co] [a-z0-9]* rgharaib ALL=(ALL) /opt/xcat/bin/rpower b[0-9]* [a-z]* rgharaib ALL=(ALL) /usr/bin/ssh ananke reboot rgharaib ALL=(ALL) /usr/bin/ssh aether reboot Xyz ALL=(ALL) ALL Userid Xyz can run on any server as any target user for any command Xyz ALL=(root) vi Userid Xyz can run on any server as root for the vi command

Sudo Benefits Disable root No more generic root editing/configuring Who did it? Give individual sudo access to specific users Can be as general as all access Can be specific to a particular command and options If errors or sabotage Know who did it from the log records

Sudo examples operator ALL= /sbin/poweroff SuperMary ALL=(ALL) ALL UID operator can shut down the system SuperMary ALL=(ALL) ALL UID SuperMary can do anything as “root” %supergroup ALL=(ALL) ALL Anyone in the group supergroup has “root” authority msnider ALL= NOPASSWD: /sbin/halt UID msnider can halt the system, no password required trusty dev02 = /usr/bin/* UID trusty can run any command in the /usr/bin directory on system dev02

selinux

selinux Security-Enhanced Linux adds access-control mechanisms to the Linux kernel Most common mechanism is Mandatory Access Control (MAC) Developed primarily by the NSA

selinux All files are assigned a security context policies exist for every application detailing the security contexts they can access

selinux in red hat Red Hat includes decent SELinux support out of the box Can be enabled by editing /etc/selinux/config Usually type should be targeted and mode should be enforcing

selinux Having SELinux enabled may break some necessary functionality Booleans can be used to change SELinux behavior getsebool -a will show available booleans setsebool can modify them

auditd Audit daemon that tracks security operations on a system SELinux problems are logged to the audit daemon Can be configured to meet federal, DoD or other requirements Logs written to /var/log/audit/

selinux + auditd audit2allow will generate a SELinux ruleset from denied actions recorded by auditd Simple mechanism to update SELinux policies for your environment

Other

monitoring changes Host-based intrusion detection systems Software is on the computer itself Designed to detect changes to files on the system Normally used in extremely paranoid environments AIDE (Advanced Intrusion Detection Environment) is one example

aide Creates a database containing hashes of important files on the filesystem Periodically verifies that file hashes have not changed Must be turned off to update anything Database must be rebuilt after an update

logging Centralized log management is key Once logs are centralized, you need a way to condense them into something useful logwatch is one such tool Note: enable sudo to monitor who makes system changes

logwatch Tool to generate summary of system logs Can generate one email containing all systems or an email for each system Split into different components that check for certain patterns Easy to write new components

configuration management Tools and concepts that help maintain systems consistency Administrators use tools to write policies and apply them to multiple systems Policies are verified periodically and any changes on the local system can be backed out Some tools allow administrators to roll back changes that were pushed out via configuration management

configuration management Large organizations and organizations concerned about security can benefit from configuration management Example tools are cfengine and puppet Will have a complete module on configuration management