1 / 26

Host Security: Basic Notions

Host Security: Basic Notions. Applied Security. What is host security?. A host is any computer, including Workstations Network servers Laptops Wirelessly networked devices ... Isn’t host security everything, then?. Host security measures. Host-centric: Tailored to host architecture:

rudolpho
Télécharger la présentation

Host Security: Basic Notions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Host Security: Basic Notions Applied Security

  2. What is host security? • A host is any computer, including • Workstations • Network servers • Laptops • Wirelessly networked devices • ... • Isn’t host security everything, then?

  3. Host security measures • Host-centric: • Tailored to host architecture: • Takes into account not only type of operating system but also configuration • Comprehensive: • protect installed applications • Complex, costly, protects single host

  4. Secure host configuration Unix-like systems

  5. Password management issues: weak passwords default passwords re-used passwords Exploitable services FTP/TFTP Sendmail other services Improper file and directory permissions Improper use of setuid Improper network file configuration Unpatched known vulnerabilities Common Unix Configuration Weaknesses

  6. In Unix, there are three levels of access control Individual (user): Each user has a unique id (uid) in the system. Group: All users by default belong to the “user” group (some distributions), or to a singleton group containing only that individual user. Users can belong to more than one group (most modern versions). Usually a group is defined for access control category. E.g: root/wheel (general administration) www/web (web server administration) mail (mail server administration) adhoc groups can be used to facilitate collaboration such as directory and file sharing World (or all): The universe of all users. Basic UNIX access control

  7. File permissions • File ownership: Each file and directory in UNIX (including programs) is “owned” by a specific user, a specific group, and the world. • To each level of ownership there is an associated set of permission values: read, write and execute. These values can be true (permission granted) or false. Only the owner of a file (or the special user root) can change the file permission settings.Example: drwxr-xr-x 11 brenodem brenodem 374 30 Aug 13:39 . • Indicates that the file ‘.’ (the current directory) is owned by user brenodem, who belongs to the singleton group brenodem. The directory was last modified on Aug. 30th at 13:39. The user brenodem is granted read, write, and execute privileges to the file. The group and world are granted read and execute (but not write) privileges to the files.

  8. Meaning of file permissions • The meaning of permissions for files is clear, but can be complex for directories. • For instance, if a world-accessible file is located deep within a directory structure, all the parent directories of the file must grant execute permissions to the whole world. • This is because, in order to traverse a directory structure, UNIX executes cd on each directory (starting from the lowest common directory, for instance ‘/home’ ). On the other hand, it is NOT necessary that the same directories be world-readable. • If a directory is not readable by a principal, its contents cannot be listed. However, it may well contain files that are readable by that principal, and these can be opened if their name are known.

  9. Proper file and directory permissions • Any UNIX system contains several directories that are world executable, where most of the OS services reside: • /bin (commands) • /etc (configuration files for the above) • /usr (utilities and applications) • /usr/local or /local (extra utilities and applications) • These directories are not required to be world readable, only their content files need to be world readable. If the directories are not world readable (and owned by root) then only the system administrator will be able to have a global view of the system configuration and capabilities. • These directories should be writable only by root to prevent the installation of programs without the administrator’s knowledge. In particular they must be “owned” by root.

  10. Changing ownership and permissions • The root user can change ownership and permissions on files at will. • chown username filename • In some distributions, a user may change ownership of its own files to other users. • To change group ownership of a file, you must own the file and you must belong to the new group the file will be assigned to: • chgrp groupname filename • To change permissions, you must be the file’s owner • chmod [o|g|a|u][+|-][r|w|x] filename • example: chmod og+wx filename adds permissions to write and execute the file to both the file owner and file group owner.

  11. Effective ID • When a user tries to execute a program • The UNIX system decides whether the user is authorized to execute (for instance, the user may belong the the file group owner, and the file may be executable by the group). • When the program is initiated, its effective ID is set to the ID of the user (or program) calling it. • For instance, if a utility program is owned by root (typical), but called by a regular user, the effective id of the running program will equal that of the caller (user), not root. • This standard mechanism is not sufficient in some cases. For instance, the login program.

  12. SUID • The login program is invoked by regular users, but must have root privileges in order to access the protected password files (/etc/shadow), and to authenticate the user. (Effectively spawning a program under a particular user name even if called by another.) • This is called a “set user id” program (suid). -r-sr-xr-x 1 root wheel 26756 16 Aug 10:32 /usr/bin/login • Note the ‘s’ in the list of privileges. That means that the caller (could be anybody, as the file is world executable) will spawn a program with the privileges of the group wheel (which can access the password file, and spawn programs (shell) under arbitrary user identities.)

  13. Proper configuration of file permissions • The system of file access permissions underscores most of the access control decisions of the UNIX operating system. • It is a flexible mechanism that enables different configurations to accommodate different usage needs. • Improper configuration of file and directory permissions can create serious vulnerabilities. • The use of SUID programs is a powerful mechanism that should be utilized only when necessary. For instance, a fragile program with SUID permissions can be easily exploited to grant administrative privileges to an attacker.

  14. Most Unix systems include the RPC utilities suite for remote command execution: rlogin (remote login) rsh (remote shell) rcp (remote copy) Two modes of authentication: host-based and password-based RPCs originating at a trusted host (i.e., a host listed in /etc/hosts or /etc/hosts.allow or /etc/hosts.equiv), identified by network packet source address, are accepted and given uid equal to the claimed username. RPC Utilities • RPCs called from non-trusted computers must provide both username and password. (Both sent as cleartext over the network.)

  15. Disabling RPC utilities • The use of RPC utilities has been deprecated in favor of the ssh and scp programs, both built onto the SSH protocol, which provides encryption. • For backward compatibility the SSH program supports host-based authentication. (This is stronger than in the RPC case, as hosts have SSH keys with which they can mutually authenticate their identities.) • It is important to ensure that the configuration of the /etc/hosts files reflects the trust policies of your network, and that the RPC utilities are disabled whenever possible.

  16. The UNIX password system Past and present

  17. In early versions of Unix, the password was processed using a “secure hash” function derived from the DES cipher. The salt was restricted to 12 bits, resulting in 4096 possible hash values for each password. Passwords were restricted to 8-character length. 8-character passwords converted into 56-bit DES keys Password shorter than 8 characters long padded w/ zeros. Longer passwords truncated in some systems. Salt used to change the DES cipher, which is applied 25 times. Results stored in world readable /etc/passwd file Early Unix Password System

  18. Unix crypt()

  19. DES: IP and FP stand for initial and final permutations, respectively. F: Round function E: Expansion function 3248 bits, is changed on crypt3() using the salt.

  20. Old /etc/passwd file • An entry in the /etc/passwd file has the following form: • Name:Password:UserID:PrincipleGroup:Gecos: HomeDirectory:Shell • smith:Ep6mckrOLChF.:100:100:John Smith/home/smith:/usr/bin/sh • guest:*:200:0::/home/guest:/usr/bin/sh • An entry ‘*’ for password means that the account has been disabled, while an empty password means that password is not required for login! • When shadow passwords are used, ‘!’ or ‘x’ substitutes for the password.

  21. New /etc/passwd file • nobody:*:-2:-2:Unprivileged User:/:/usr/bin/false • root:*:0:0:System Administrator:/var/root:/bin/sh • daemon:*:1:1:System Services:/var/root:/usr/bin/false • smmsp:*:25:25:Sendmail User:/private/etc/mail:/usr/bin/false • lp:*:26:26:Printing Services:/var/spool/cups:/usr/bin/false • sshd:*:75:75:sshd Privilege separation:/var/empty:/usr/bin/false • qtss:*:76:76:QuickTime Streaming Server:/var/empty:/usr/bin/false

  22. /etc/shadow file • Entries of the form: • smithj:Ep6mckrOLChF.:10193:0:99999:5::: • Where the password is followed by: • The date when the password was last changed, measured in elapsed days since Jan. 1st, 1970. • The number of days before the password can be changed again • The number of days after which the password must be changed • The number of days to warn user of an expiring password • The number of days after password expires that account is disabled • The number of days since January 1, 1970 that an account has been disabled • A reserved field for possible future use

  23. Other changes • Since the introduction of shadow passwords, and the new crypt(), other modifications have been introduced, such as the use of MD5 passwords, and also Blowfish-encrypted passwords. • Blowfish is an interesting choice: The algorithm is very slow to change keys, making hashing password expensive (good for security).

  24. Reading assignment for 01/16 • Use of a Taxonomy of Security Faults, by T. Aslam, I. Krsul, and E. H. Spafford • M. Bishop and D. Klein, Improving System Security Through Proactive Password Checking,Computers and Security14(3) pp. 233-249 (May/June 1995)http://nob.cs.ucdavis.edu/~bishop/papers/1995-c+s/proact.pdf

More Related