1 / 21

Secure Operations

Secure Operations. Sources : Chapters 17, 18, 19 and 20 from Practical UNIX and Internet Security, Garfinkel and Spafford 3 rd Edition Available on Safari. Also from Chapter 4, 5 in Pfleeger and Pfleeger. So far we have seen …. Application of secure design principles:

laasya
Download Presentation

Secure Operations

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. Secure Operations Sources: Chapters 17, 18, 19 and 20 from Practical UNIX and Internet Security, Garfinkel and Spafford 3rd Edition Available on Safari. Also from Chapter 4, 5 in Pfleeger and Pfleeger

  2. So far we have seen … • Application of secure design principles: • Least privilege: access control in OS. • Separation of privilege: multi-factor authentication. • Reluctance to trust: use of shadow passwords. • Complete mediation: system calls. • Next: Protecting the weakest links. • While securing an Operating system, the weakest links are often the overlooked issues: e.g., not getting the latest patch etc.. • We will see some more design principles in action.

  3. Securing the weakest link. • Can you think of some of the weakest links on an operating system?

  4. Securing the weakest link. • Can you think of some of the weakest links on an operating system? • Not fixing programming bugs: • Failing to update security patches. • Not backing up data. • Protecting integrity of information. • Insecure configuration • E.g., preventing weak accounts. • Testing for integrity (with MD5 checksums)

  5. Keeping up to date. • Why keep up to date? • Software management systems • E.g., Linux uses what are called as package managers: • rpm (RPM package manager), yum (RedHat/Fedora), apt-get (on Debian Linux versions), (home)brew (OS X) • These managers help check for the latest software and update accordingly. • In Windows: E.g., Windows automatic update manager or iTunes update manager etc. • Source vs. binary based managers. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 17

  6. Keeping up to date. • Features to choose when selecting a package manager: • Ability to keep track of versions installed. • Distributed updates. • Using safe Mirrors with MD5 checksums: • When downloading software in UNIX/Linux: • Most package managers come pre-configured with websites that provide MD5 checksums along with software. • However, you can customize this…. • In Windows: all downloads with the Windows update manager come with MD5 checksums Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 17

  7. Backups: issues. • Backing up data is a crucial security operations. • Why backup? • What to backup? • What data needs to be backed-up? • When to backup? • How fast to restore a backup? • How long to keep a backup? • Protecting backups? Any issues? • These days it is easier to backup then ever: • E.g., Windows Backup • UNIX/Linux: rsync (remote sync). • Mac OS: Time Machine. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  8. Backups: issues. • What to backup? • System files or everything? Full, Project-related, home directory and mail, • Depending on the context, we need to make a decision as to what to backup. This is the first step in a backup process (and the easiest)!. • Remember, /dev/ contains "non"files (mounted drives, keyboards, printers, …) • Synchronizing two live systems is more difficult:Synchronize temporary files? Lock files? Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  9. Backups: issues. • What data needs to be backed up – files? • Every file in an OS comes with lot of information: • The data that the file contains. • The permissions on the files (e.g., who created it, what permissions does that person have? Etc.) • Certain other meta-data: • Date when the file was created. • Date when the file was last modified. • Date when the file was last read (or accessed). • When backing up a file – sometimes we need to backup more than just the data part. • E.g., in Digital forensics – where a crime is being investigated, a file (e.g., a file containing tax fraud information), should not just be copied – even the date of modification and last access may be important during a court case (to show that the police haven’t tampered with it). • Or when you submit an assignment on WebCT, but it doesn’t go through, how do you prove to the Professor that you finished the assignment on time? By looking at the modification time. • Problem: Usually file copy operations do not preserve meta-data. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  10. Backups: issues. • Problem: file copy operations may not preserve meta-data. • WINDOWS: Copy and Paste or Cut and Paste: • Does not preserve: original owner, original creation time of file • Does preserve (in Windows 7): Last modificationtime. • UNIX/Linux:Copy command (cp) doesn’t preserve permissions, by default • E.g., cpxyz.txtabc.txt destroys ALL the meta-data. • Need to select the right choices: E.g., cp –prxyz.txtabc.txt • Alternative (for directories and multiple files): tar. • Even bigger problem: copying across the network results in inconsistency in data being preserved (e.g., copying from H: drive to a local drive). • SOLUTION: Use a digital forensics software. (E.g., safecopy) Still, issues to be aware of: • File owned by ibarland, moved to a unix machine w/o account 'ibarland' – what happens? • Timestamp consistent between machines? • Moral of the story: When backing up files – use options that preserve all the data that you would need later. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  11. Backups: issues. Types of backups: Full vs. incremental backup. • Full backups back all the data. • Good to do the first time.Subsequent full backups waste time. • Incremental backups • Software checks differences with previous backup, and then backs up accordingly. • Might just check timestamps, or check (hash of) actual contents. E.g., tar (Linux full backup) vs. rsync (Linux remote incremental backups). Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  12. Backups: issues. • Other issues to consider: • How fast to restore a backup? • E.g. Tape drive vs regular drives. • Offsite vs. on-site? Off-site has more security as an advantage (e.g., if on-site is attacked). Also offline is better than on-line backups. • How long to keep a backup? Monthly? Project duration? Weekly, Daily, Hourly? • Organizations usually have data retention policies. • E.g., Commonwealth of VA: requires 1 year of backups. • After a backup: • Guarding against Media failure. • Verifying backups. • Security for Backups • Usually physical threats Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  13. Backups in organizations. • Class exercise: Case study: • Radford University: • What is the type of Environment? (in terms of number of workstations/desktops) • What needs to be backed-up? • How often should the backup be done? • Where to store the backups? • Data retention schedule? Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  14. Backups in UNIX/Windows • Backup up critical system files. • System files in UNIX are in /etc • E.g., passwd, network configuration etc. • In Windows C:\Program Files • In MAC: /etc • Backup User folders • In UNIX: /home directory (or /users) • In Windows: usually a shared partition on a drive. Or C:\Documents and Settings\ • When to backup? • Changes to file systems? Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  15. Backup software in UNIX/Windows • UNIX: • scp (secure copy over network) • Rsync (distributed copies) • Windows: • Comes with several specialized/advanced softwares (e.g., Windows Vista Automatic Backup Manager , Norton GHOST). Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  16. Paper trail • Printed copies are crucial. Systems always fail. • Paper copies protect against integrity changes. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 18

  17. Secure option: Defending accounts • “An ounce of prevention …” • A huge weak link in many OSes are the user accounts. • Examples: • The username: guest/ password; guest account on all standard ftp installations (from wu-ftpd daemon – this is the ftp server released from the Washington University at St. Louis). • As a system admin, what do you need to check in terms of user accounts? Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 19

  18. Defending accounts • As a system admin, what do you need to check in terms of user accounts? • Accounts with weak passwords – use password checking programs(e.g., CAIN and ABEL). • Accounts without passwords?! • Simply open the /etc/shadow file and look for accounts with no password information in UNIX. • Simple UNIX script to check: cat /etc/shadow | awk -F: 'length($2)<1 {print $1}' • Disable such accounts! • Check for default accounts. • E.g. daemon, ftp, etc. • Ensure roothas a non-empty-string password! • Protect against dormant accounts. If users are not going to use a system for an extended period, suspend the account. • Next: How to suspend an account? Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 19

  19. Defending accounts • Protect against dormant accounts. If users are not going to use a system for an extended period –suspend the account. • How to suspend an account? • Set password in the /etc/shadow file to “*” • This will prevent a user from logging in. • Change the shell associated with the user. A shell is the first program that runs in UNIX when a user logs in. • E.g., in the /etc/password file you will see shells such as /usr/sbin/bash. The “bash” shell here is in the /usr/sbinfolder. • If you specify a shell program that doesn’t exist… the user cannot login! • Another way to protect against dormant accounts: Lock accounts. • Disable an account when a user has not logged in for a while. • Example in UNIX: • usermod -10 ibarland • This will ensure that if “ibarland” doesn’t login atleast once within 10 days, their account is locked. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 19

  20. Protecting the root account • Remember: The principles of least privilege. • All OSesprovide support for this principle. • Example: • In UNIX: sudo • In Windows: runas Administrator • Logging in as root (or Administrator) is dangerous – e.g., you may login as root, forget that you are root and browse the Internet. A bug in the browser can now be exploited by someone to gain access to your account – the root account! • Solution: Execute only certain commands as Administrator using “sudo”. • E.g., sudo cp /etc/shadow /etc/shadow.backup • This will allow you to make a copy of shadow to shadow.backup. • You will be prompted for your password. • Your username must be part of the “sudo” users group for this to work. • Least privilege for least amount of time: sudorequires periodic re-authorizing • Same with runas Administrator in Windows. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 19

  21. Secure operations: Protecting all accounts • The problem with “multi-tasking” in operating systems: Most OSes allow multiple programs to run on the CPU by sharing the CPU in a “round-robin” fashion. This is a security issue: E.g., a keyboard sniffer can be running alongside a login program. • Trusted path to login programs. • Login programs accept user passwords • Must prevent keystroke sniffers from reading in the password as the password is being typed. • Solution: Trusted path to login program. • E.g., Ctrl+Alt+Delete in Windows. This disables all the other programs running in the background. Hence, no program can sniff the password. Practical UNIX and Internet Security 3rd Edition by Garfinkel and Spafford – Chapter 19

More Related