RHCE Study Group Session 9: User and Host Security Joseph Tate jtate (at) dragonstrider (dot) com A. Security concepts 0. Security is not an afterthought. It must be part of the system design. a. Confidentiality --- Sensitive information must be available only to a set of pre-defined individuals. Unauthorized transmission and usage of information should be restricted. For example, confidentiality of information ensures that a customer's personal or financial information is not obtained by an unauthorized individual for malicious purposes such as identity theft or credit fraud. b. Integrity --- Information should not be altered in ways that render it incomplete or incorrect. Unauthorized users should be restricted from the ability to modify or destroy sensitive information. c. Availability --- Information should be accessible to authorized users any time that it is needed. Availability is a warranty that information can be obtained with an agreed- upon frequency and timeliness. This is often measured in terms of percentages and agreed to formally in Service Level Agreements (SLAs) used by network service providers and their enterprise clients. 1. The fewer people who have access to your system, the more secure it is. a. The fewer people with root access, the better. i. Use sudo! (visudo to edit the sudoers file) # %wheel ALL=(ALL) ALL # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now ii. Disable remote and local root logins! 1. Change shell to /sbin/nologin (this prevents any access that requires a shell. Does not affect sudo, ftp or imap/pop3) 2. touch /etc/securetty (prevents access through console or network. (Does not affect su, sudo, ssh, scp or sftp) 3. Disable ssh logins: set PermitRootLogin to no in /etc/ssh/sshd_config. 4. Use PAM to limit access: i.e. to limit vsftpd # /etc/pam.d/vsftpd #denys access to users listed in /etc/vsftpd.ftpusers auth required /lib/security/pam_listfile.so item=user sense=deny \ file=/etc/vsftpd.ftpusers onerr=succeed 2. Set /tmp as it's own file system. 3. Turn off all services you don't need a. redhat-config-services b. ntsysv c. chkconfig --del d. Services enabled by default: i. cupsd, and/or lpd ii. portmap (needed for NFS and NIS) iii. xinetd iv. sendmail (but the external interface is disabled by default.) v. sshd 4. The fewer ports you have open, the less access others have to your system. 5. External threats are not the only threats. a. Being behind a firewall doesn't make you safe 6. Do you really need to be connected to the internet? 7. chroot whenever possible 8. don't build (tarballs, rpms) as root 9. Use iptables (to be discussed in the next class) 10. Password expiration? 11. Change all default passwords a. system account passwords b. mysql and postgresql passwords c. others? 12. Terminal security a. Can a user boot into single user mode without a password? i. use a grub or lilo password ii. lock insecure Operating Systems b. Do you need to disable floppy and/or CD drive booting? c. BIOS password? d. Lock the computer case? 13. Password security a. Choose passwords that are not easy to guess b. Use MD5 passwords c. Use shadow passwords 14. No passwords passed over the network in clear text a. Check imap, pop, smtp auth, web mail, etc. 15. social engineering: users must remember passwords: a. if they can't remember multiple passwords, it will be more secure to set up single logins for all services than to have users write passwords on post-it notes on their monitors. 16. Logging, logging, logging 17. Tools: a. netstat -an and lsof -i (less reliable than nmap) b. nmap -sT -O localhost c. logwatch d. tripwire e. rpm -Va f. man lsof, netstat, nmap and services 18. Standard Operating Procedures a. Vulnerability Assessments (Security Guide Chapter 8) b. Intrusion Detection (Security Guide Chapter 9) c. Incident Response (Security Guide Chapter 10) 19. Common exploits and attacks http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/ch-exploits.html B. Console Access 1. See Chapter 24 of the RH Customization Guide C. VPN configuration 1. CIPE chapter 6 of RH Security Guide D. PAM - Pluggable Authentication Module 1. Gives a common set of functions for authentication against a variety of methods: LDAP, Samba, Kerberos, NIS, /etc/passwd 2. Gives good flexibility and control over authentication for admins and developers 3. If you use a network method like LDAP, use nscd to cache user information locally. 4. configuration files are in /etc/pam.d/ or /etc/pam.conf a. Each pam aware app has a file, named after the service, i.e. login is controled through /etc/pam.d/login b. Format: c. Types of interfaces i. auth: authenticate the user by for example user/password ii. account: verify that access is allowed by checking account status. iii. password: sets and verifies passwords iv. sessions: configure and manage user sessions d. Control flags i. required: This module result must be successful for authentication to continue. If one fails, the user is not notified until all other modules complete. ii. requisite: This module result must be successful as well, but the user is notified immediately reflecting the result. iii. sufficient: This module result is ignored if it fails, but if successful, and no other required modules have failed, then the user is authenticated. iv. optional: The module result is ignored if it fails. If the module result is successful, it does not play a role in the overall success or failure for the module interface. A module flagged as optional becomes necessary for successful authentication when there are no other modules referencing that interface. In this case, an optional module determines the overall PAM authentication for that interface. v. The order of required modules doesn't matter. Sufficient and requisite flags cause order to become important. e. Module arguments i. Invalid arguments will be ignored but will most likely report an error to /var/log/messages. f. Sample #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix.so shadow nullok auth required /lib/security/pam_nologin.so # Why are all three auth methods required? account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so retry=3 password required /lib/security/pam_unix.so shadow nullok use_authtok session required /lib/security/pam_unix.so g. Sample 2 #%PAM-1.0 #How would one change this so that a password prompt wouldn't be displayed if #pam_securetty.so failed? auth required /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_stack.so service=system-auth 5. Device ownership a. There is a special user called the console user (first user logged into a tty or gdm/kdm screen i. Lasts until the last session for that user is exited. b. Is given special permissions to sound cards, floppy and cd drives, etc. c. Control this in /etc/security/console.perms 6. PAM resources a. man pam b. /usr/share/doc/pam- c. http://www.kernel.org/pub/linux/libs/pam/ E. LDAP (chapter 13 of the RH Reference Guide) 1. LDAP is the Lightweight Directory Access Protocol a. Allow access to centrally stored information 2. LDAP terminology a. entry: a single unit within an LDAP directory; unique DN (Distinguished Name) b. attributes: information associated with an entry. May be required or optional by a schema c. LDIF: LDAP Data Interchange Format, and ASCII text representation of LDAP entries. i. Looks like: dn: ou=Group,dc=mi-corporation,dc=com ou: Group objectClass: top objectClass: organizationalUnit 3. Packages: openldap, openldap-clients, openldap-servers, nss_ldap 4. Config files: a. /etc/openldap/ldap.conf global configuration for CLIENT apps. b. /etc/openldap/slapd.conf configuration for the slapd daemon c. /etc/ldap.conf configuration file for nss_ldap module d. /etc/openldap/schema/ contains schema used by slapd 5. Schema: See http://www.openldap.org/doc/admin/schema.html 6. Initial Setup a. Using the comments in /etc/openldap/slapd.conf, set up your server b. Create an initial admin password using slappasswd, and put it into slapd.conf c. use ldapadd and slapadd to populate the directory d. use ldapsearch to verify operation 7. After modifying using slapadd, you'll need to change the ownership of the LDAP databases back to ldap: chown -R ldap /var/lib/ldap 8. To authenticate against ldap, use authconfig 9. Set up the domain LDIF file # cat > example.ldif dn: dc=example,dc=com objectclass: dcObject objectclass: organization o: My Organization dc: example.com dn: cn=Manager,dc=example,dc=com objectclass: organizationalRole cn: Manager ^D # ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f example.ldif # ldapsearch -x -b 'dc=example,dc=com' '(objectclass=*)' 10. Use directory_administrator to administer users 11. gq? (recommended by Chris Hedemark) 12. Other resources a. man ldap ldapadd ldapsearch b. /usr/share/docs/openldap- c. http://www.openldap.org d. http://www.redhat.com/mirrors/LDP/HOWTO/LDAP-HOWTO.html e. http://www.padl.com/ developers of nss_ldap and pam_ldap f. Full list at the end of chapter 13. F. xinetd 0. Provides access, logging, binding, redirection and resource utilization control. 1. /etc/xinetd.conf and all files in /etc/xinetd.d/ 2. To enable a service: disable = no 3. only_from = 127.0.0.1,.example.com,192.168.0.0/24 a. Only allow connections from these hosts. 4. no_access = 0/0 b. Disallow connections from these hosts 5. Lots of other options. See man 5 xinetd.conf 6. imap(s), pop3(s), rsync, telnet, rlogin, finger, etc. all run from xinetd (at least the RH versions of these programs) 7. Set a trap for hackers: a. Easy way to block people who portscan b. Edit /etc/xinetd.d/telnet and change the flags line to read: flags = SENSOR c. Within the braces, add deny_time = 30 to deny for 30 minutes i. FOREVER bans until restart ii. NEVER allows the connection and logs it d. Doesn't work against stealth scans, possible DOS by spoofing IP addresses of legitimate users. 8. Control server resources: a. cps = <#conns> Connections per period b. instances = Total connections allowed (UNLIMITED) c. per_source = Total connections allowed/host (UNLIMITED) d. rlimit_as = Memory space allowed for the service e. rlimit_cpu = Amount of CPU time alloted. G. TCP wrappers 1. "Many UNIX system administrators are accustomed to using TCP wrappers to manage access to certain network services. Any network services managed by xinetd (as well as any program with built-in support for libwrap) can use TCP wrappers to manage access." a. strings -f | grep hosts_access to see if a binary supports tcpwrappers 2. /etc/hosts.allow and /etc/hosts.deny. hosts.allow takes precedence. 3. Rule based access control: IP, hostname or some pattern 4. man 5 hosts_access or see _Red Hat Linux Reference Guide_ 5. Implement connection banners: a. Create a banner file, i.e. /etc/banners/vsftpd b. Put banner contents into file, i.e. 220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Act up and you will be banned. i. See the Red Hat Linux Reference Guide for a list of tokens available. c. Add the banner notification to /etc/hosts.allow or /etc/hosts.deny i. vsftpd : ALL : banners /etc/banners d. see /usr/share/doc/tcp_wrappers-7.6/Banners.Makefile 6. Log attacks from 206.182.68.0/24 and deny connection: a. /etc/hosts.deny: ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert b. %d is the service %c is the client (username, hostname, IP addr). c. To allow the connection, put the line in /etc/hosts.allow 7. For more information see chapter 5 of RH Security Guide and chapter 15 of the RH Reference Guide. H. Securing portmap (NFS, NFS and other RPC services) 1. Limit access using tcpwrappers as it uses weak authentication methods and special abilities. a. Use IP addresses, avoid hostnames 2. Use iptables a. The following blocks port 111 except from 192.168.0/24 and localhost. iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT b. Similar for UDP iptables -A input -p dup -s! 192.168.0.0/24 --dport 111 -j DROP I. Old skool Unix remote protocols and their new and improved secure varieties. 1. rsh,telnet ssh 2. rcp scp 3. ftp sftp a. Disable non-anonymous FTP logins by: i. wu-ftpd: /etc/ftpusers add deny-uid * ii. vsftpd: to /etc/vsftpd/vsftpd.conf add local_enable=NO 4. rlogin slogin