Security Backup and Restore

1. Security Backup and Restore

2. Security • there are almost as many security issues relating to authorized users as to potential intruders • security considerations permeate most system administrative activities, and security procedures work best when they are integrated with other, normal system activities

3. Security (cont). • before you can address security related issues you need to answer these questions • what are you trying to protect? • what valuable asset might be lost? • loss of equipment • loss of data (alteration, deletion or copy) • loss of use

4. Security (cont). • a well secured system is a combination of policies that: • prevent every possible relevant threat • plan & prepare for what to do when the worst happens anyway • never is almost always shorter than you think! • good security is largely a matter of planning and habit....

5. Security (cont). • your policy should cover things like • who is allowed to use the account • password requirements and prohibitions • proper and improper use of local systems and those accessed via the Internet • conditions which cause a user to lose account • what usage is allowed on which computers • consent to monitoring • disposal of printed and magnetic media

6. Security (cont). • a system is only as secure as its most vulnerable part • when users cause security problems, there are 3 main reasons • ignorance • laziness • malice

7. Security (cont). • Ranking of potential security threats • taken from Computerworld, p24, 30 Mar 98

8. Security (cont). • UNIX offers 2 basic ways of securing... • passwords are meant to prevent unauthorized access to the system • file permissions are meant to limit access to files and programs to only the authorized user • in a given network the least protected system defines the overall security level for all the systems

9. Security (cont). • the first line of defense is physical security • prevent theft and vandalism - lock it up • limit access to console and CPU • control the environmental factors • power, temp, humidity, fire, flood, etc. • don’t forget food and drink..... • restrict or monitor access to systems • limit access to backup media • backups are the final line of defense

10. Security (cont). • using groups • groups should be defined on the basis of the need to share files • group divisions are often structured around projects • use a designated common file structure for holding shared files (ie. /export/groups) • be aware of the permissions being set

11. Security (cont). • set user ID (SUID) and set group ID (SGID) file access modes provide a way to grant users system access to which they are not otherwise entitled on a temporary, command-level basis • be very, very careful..... • access is added using chmod’s s access code

12. Security (cont). • # chmod u+sfile(s) SUID access • when file is executed the process’ effective UID is changed to that of the user owner of the file and has that user’s access rights • # chmod g+sfile(s) SGID access • when file is executed the process’ effective GID is changed to the group owner of the file and has that group’s access rights

13. Security (cont). • you can tell a file has SUID set by an s in place of the x for user’s execute permissions (ie. -rwsr-xr-x) • you can tell a file has SGID set by an s in the place of the x for group’s execute permissions (ie. -rwxr-sr-x) • did I already say be very, very careful?! • keep these files to an absolute minimum!!!

14. Security (cont). • to find SUID and SGID files try the command • find / \( -perm -2000 -o -perm -4000 \) -type f -print • for a more comprehensive list try • find / -type f \( -perm -2000 -o -perm -4000 \) -exec ls -l {} \; | diff - /usr/local/bin/old/fs • where /usr/local/bin/old/fs is a list of known SUID and SGID files previously created - check any discrepancies right away

15. Security (cont). • some administrative virtues • paranoia is common sense • cries of paranoia generally mean your just doing your job well.... • attention to detail • it will almost always be the little thing that bites you • adherence to routine • the one time you skip it is the one time it “matters”

16. Security (cont). • event auditing • chose what events to track • chose what objects to monitor • group into classes of related items • set default audit event (or class) list • decide where the audit trail file is located • establish any other parameters needed • modify boot scripts to start auditing

17. Security (cont). • CERT • Computer Emergency Response Team • administers an email list of security advisories • to be added: cert-advisory-request@cert.org • also see the anonymous FTP site: info.cert.org

18. Backup & Restore • developing an effective backup strategy is an ongoing process • the “time” to develop a good backup strategy is right now, starting from however you are approaching things at the moment

19. Backup & Restore (cont.) • there are many factors to consider - these questions are among the most important • what files need to be backed up? • where are these files? • who will back up the files? • where, when, and under what conditions should backups be performed? • how often do these files change?

20. Backup & Restore (cont.) • how quickly does an important missing or damaged file need to be restored? • where will the data be restored?

21. Backup & Restore (cont.) • “the” backup strategies.... • a full backup is the simplest and most thorough • but they can be time consuming and unwieldy • restoring a single file can be very inconvenient • however... this may still be the best daily choice • an incremental backup can finish much quicker • only captures files that have changed since the previous backup • can be done more frequently • usually much faster than a full backup

22. Backup & Restore (cont.) • UNIX uses the concept of a backup level to distinguish different kinds of backups • a full backup is level 0 • backing up the system at any level means saving files that have changed since the last backup at the previous level • level 1 gets everything since the last level 0 • level 2 gets everything since the last level 1 • ...and so on

23. Backup & Restore (cont.) • ...so a typical backup scheme might be • Monday - level 0 • Tuesday through Friday - level 1 • another popular plan is... • first Monday of the month - level 0 • all other Mondays - level 1 • Tuesday through Friday - level 2 • take into account how the system is used

24. Backup & Restore (cont.) • always do a full backup before making any major changes to your system! • you probably will want to keep multiple sets of backups and rotate through the sets. • some parts don’t need backup • like /tmp • others need backup much more frequently • like /home

25. Backup & Restore (cont.) • backup storage considerations • know where things are • make routine restorations easy • write-protect backup media • environmental considerations • heat, cold, wet, dry, total or partial destruction... • handle media properly • take security into account

26. Backup & Restore (cont.) • off-site backups are the last barrier between your system and total annihilation • backup should be done on unmounted filesystems only • be sure to validate the backup worked correctly before shipping off-site • storage should be locked, fireproof and environmentally controlled

27. Backup & Restore (cont.) • this is one time when being compulsive is a good thing! • it is very easy to put off backups, especially when you are responsible only for your own files • just assume... that the next time you sit down at your computer that you’ll be seeing smoke curling out of the disk drive.... • IT WILL HAPPEN!

28. Backup & Restore (cont.) • backup media • magnetic tape • 1/2 inch 9-track • 1/4 inch cartridges (QIC) • 8mm and 4mm cartridges • floppy disk • removable disk

29. Backup & Restore (cont.) • floptical and magneto optical disk • writeable CD-ROM • jukeboxes, stackloaders and similar devices • hard disks

30. Backup & Restore (cont.) • virtually all UNIX documentation recommends that filesystems be dismounted before a backup is performed (except for /) • this recommendation is rarely followed! • however, you do need to make sure your users are aware that open files may not always be backed up correctly under these circumstances

31. Backup & Restore (cont.) • there primarily 3 programs used for backup • tar • cpio • dump (or ufsdump) • tar and cpio are sufficient to periodically save important files • they also have the advantage of being able to backup both local and remote filesystems (mounted via NFS)

32. Backup & Restore (cont.) • some differences between tar and cpio • cpio easily backs up completely arbitrary sets of files; tar works best on directory subtrees • cpio packs data much more efficiently • on restore, cpio skips over bad spots; tar dies • cpio can span tapes; tar cannot • however, tar is used much more frequently than cpio....

33. Backup & Restore (cont.) • combining find with tar or cpio is one easy way of performing incremental backup • the examples below copy all files under /home which have been modified today, excluding any object (.o) files $ tar c1 `find /home -mtime -1 ! -name ‘*.o’ ! -type d -print` $ find /home -mtime -1 ! -name ‘*.o’ -print | cpio -o >/dev/rmt1

34. Backup & Restore (cont.) • the BSD dump utility represents the next level for backup systems under UNIX • it selectively backs up all files within a filesystem (single disk partition) • under Solaris it is called ufsdump • backs up only local filesystems • dump keeps track of when it last saved each filesystem and at what level

35. Backup & Restore (cont.) • the file that stores the info is /etc/dumpdates • this file must exist and be owned by root • dump will not create it if it doesn’t • if it doesn’t then the backup record will not exist either...

36. Backup & Restore (cont.) • general format for dump • $ dump options arguments filesystem • arguments correspond to the options • not all options have arguments • some dump options • 0-9 - the level • u - update history upon successful finish • f - specify device to backup to (other than default tape device)

37. Backup & Restore (cont.) • some examples for dump • dump 1usfd 2300 /dev/rmt1 6250 /dev/rdisk2e • dump 3u /chem • dump 4Wd 45000 /anything • dump 0uf /dev/rmt/0n /usr

38. Backup & Restore (cont.) • restoring.... • tar & cpio are used to restore files saved using either tar or cpio • restore is used to restore dump files • another backup & restore program you may run across is called bru

39. Backup & Restore (cont.) • other related utilities • mt • mag tape manipulation • dd • transfer raw data between devices

40. Printers & Spooling • any spooling system includes: • user commands to initiate printing • queues • spooling directories • server processes • administrative commands • many systems use the BSD spooling facility

41. Printers & Spooling (cont.) • the BSD spooling system key pieces... • lpr - add a job to print queue • lpq - list jobs in print queue • lprm - remove job from print queue • lpd - printer deamon (in /usr/lib) • lpc - administrative interface • status, abort, stop, start, disable, enable, down, up • /etc/printcap - printer configuration file

42. Printers & Spooling (cont.) • System V printing facility is also used by many systems... • key pieces include; • lp (to initiate requests), cancel (does just that), lpstat (to list queue) • lpsched - spooling deamon • admin commands: accept, reject, enable, disable, lpadmin, lpmove, lpusers (in /usr/lib) • /var/spool/lp/request/[printer] - request info

43. Printers & Spooling (cont.) • troubleshooting printers • make sure you’re using the right kind of cable • make sure the connections are good • make sure the printer is turned on • verify that its queue is set up properly • removing and reading the queue will sometimes fix things • is the daemon running?

44. Printers & Spooling (cont.) • sometimes killing and restarting the daemon will fix things • has someone spooled a huge print job? • aborting the current job may clear the problem • power cycling the print device may help • you will lose the current job • you may need to kill and restart daemons too