Agenda - status.lsu.edu/security/
This page is a working document and will be updated as time and events require and permit.
The agenda for today's talk is:
Return to the Top of Page
Introduction
"Security" is not a single act, but rather a process and a method of thinking. There needs to be a continual cycle of analysis, implementation, testing, and re-evaluation for security to function properly within an organization.
Possibly the most important aspect of security is education. It's essential that Managers, Directors and other Executives in the organization understand the security process and know its implications so they can justify the time spent on security measures, and so that a security policy can be developed for your organization. A well written and thought out security policy, written by Managers and Information Technology workers alike, and with authority and cooperation behind it, provides a vehicle for all other security functions within the organization.
Information Technology workers, like Systems Administrators, need education to make them aware of security threats as well as to provide them the knowledge to protect their systems. The security policy helps to define expectations of these workers as well as justifies time spent on security measures. To aid in this education, the Security Focus site has an excellent Security Basics section for the beginner who is earnestly interested in learning about the field.
We've segmented the topic of UNIX Security into the following categories:
Return to the Top of Page
Developing a Security Policy
A security policy is a living document that indicates the events requiring a response and guides the actions you take. In other words, it should make clear what securing a system means, what an intrusion is, and what the appropriate authorized response to an event is. Don't attempt to have your policy cover every possiblility, it just makes it easier for an intruder to leverage the legal system in their favor to get out of trouble due to a "loophole" in your policy. Rather, keep the policy at a higher level, but technically current, generalizing unauthorized behavior and the warrented response.
The policy should be the result of collaboration between the Managers and the IT workers. There should be a scheduled review cycle, and each intrusion should be viewed as an "opportunity" to refine the policy.
Return to the Top of Page
Locking Down
Perhaps the best starting point in securing systems, after a policy statement has been created, is to prevent intruders from being able to get into your systems. Below are a few topics to consider when "locking the doors" to your UNIX machines. This list is not comprehensive, but should serve as a good beginning.
- Provide a pre-connection banner. A banner, stating that use of the machine implies no privacy, will help you during the discovery / recovery phase in getting help from law enforcement agencies. The tcpwrappers program is a useful way to get banners sent to a client before the server attempts authentication. Here is the currently approved LSU banner:
NOTICE: This is the Louisiana State University computer system, which may be
accessed and used only by authorized persons. LSU reserves the right to review
and/or monitor system transactions for compliance with its policies and/or
applicable law. Upon reasonable cause, LSU may disclose such transactions to
authorized persons for official purposes, including criminal and other
investigations, and permit the monitoring of system transactions by law
enforcement agencies. Access or use of this computer system by any person,
whether authorized or unauthorized, constitutes consent to these terms.
- Secure the "real" network
- Work with your Network Administrators to understand the network topology and hardware your systems are connected to. Have them turn off all non-essential protocols between the public network and your systems (ICMP replies). Have a point of contact you can call if you need them to filter IP addresses during an attack or to have them enable a sniffer to capture an intruders packets.
- Place systems on a private sub-net if they don't need to be exposed to the public network. If a web server needs to talk to a database server, connect the two systems with a private network so the database server is hidden from public view.
- Turn off services you don't need:
- inittab
Disable starting any services you don't need (i.e. a print server).
- inetd
Comment out all un-needed services (i.e. chargen, telnet, ftp)
- rc.* (or equivalent)
Whether your system uses rc.* or an /etc/rc directory structure, you should again, disable the starting of any services that aren't needed by the running system (i.e. httpd, apmd)
- Secure running services:
- Change any default passwords used to manage needed services (i.e databases, network monitors), or create a new administrative user ID and disable the default ID.
- Make sure services are running with the least authority (i.e a non-root user).
- Add cryptographic capabilities to needed services (i.e. SSL to web servers, encryption to databases).
- For larger services like sendmail, bind, or apache make sure you are at the latest version of code.
- Secure access:
- OpenSSH provides a free SSH v1 and SSH v2 compatible, encrypted remote command, interactive login, and file copy mechanism for use on your systems. root passwords are protected from sniffing and any potentially sensitive data is encrypted while in transit.
- OpenSSL provides a free SSL / TSL implementation to be used with the OpenSSH package or other services.
- Take advantage of /etc/hosts.allow and /etc/hosts.deny provided by tcpwrappers (see below) to limit access to services.
- Use shadow passwords.
- Use password management features to include "good" passwords.
- Delete unused / old accounts.
- Limit who has root access and change the password frequently.
- Limit physical access to the machine.
- Secure the "UNIX" network:
- Verify that NFS exports are not world exported.
- Verify that NIS maps are only root writable.
- Use an access controlled portmap for NIS systems.
- Periodically check for promiscuous mode NICs.
- Restrict "r" commands (rsh, rexec, etc.) by creating empty, root owned .rhosts and .netrc files.
- Verify that /etc/hots.equiv is empty and only root writable.
- Attempt to lock down X Windows by restricting xhost + sessions.
- Secure the UNIX Filesystem:
- Verify the absence of SUID and SGID bits on all shell scripts.
- Verify all programs with SUID and SGID bits set.
- Verify appropriate filesystem permissions.
- Verify adequate system backup and restore procedures are in place and working.
- APPLY ALL THE LATEST OS PATCHES!!!
Return to the Top of Page
Logging
Logging provides invaluable clues as to what's going on in your system as well as to what others are attempting to do with your system - so make sure you make the most of it. Take the time to understand each service on your machines and it's logging capabilities. Know where your logs are and learn how to analyze them.
Here are several logging issues to consider:
- syslogd
- Disable the ability for another machine to log to your syslogd unless you absolutely need this feature (though there is a practical use of this feature...)
- Set the logging level as verbose as disk space will allow (recommended level of 9).
- Log to a seperate filesystem.
- Enable logging of as many system services as possible.
- Verify that overall level is set to info.
- tcpwrappers
This tool, written by Wietse Venema, allows any inetd registered service to allow or deny, as well as log, each connection attempt. Other services, like SSH, are also tcpwrappers aware. This is the "de facto" standard and is the first line of defense.
- SMTP / HTTP / FTP logs
These services are historically known to be the source of many system intrusions. Monitor these logs for suspicious connections or activity.
- Automated compression and rotation
A tool like logrotate provides a mechanism to automatically compress, archive and delete logs based on age, allowing you to maximize logging while minimizing disk consumption. Remember, logs are your only record of past behavior. Older logs should be dumped to tape or transferred to another system for archival.
- Automated analysis of logs
No one should have enough time to read all the logs you capture. A tool like xxx helps by summarizing activity and establishing a base-line of normal activity to help detect abarent behavior.
- .sh_history (or equivalent)
Verify that each user has one and monitor it periodically for "suspicious" activity.
- Process Accounting
Process accounting should be enabled and the logs analyzed nightly. You need a base-line of "normal" behavior to detect suspicious behavior. These logs should also be rotated and archived.
- Software tools to generate special logs:
- Perro - is a set of three daemons that logs incoming IP/TCP, IP/UDP and IP/ICMP packets
- PortSentry - is a program designed to detect and respond to port scans against a target host in real-time by automatically updating /etc/hosts.deny.
Return to the Top of Page
Detecting
Hopefully monitoring your logs will tip you off to suspicious activity. But, how do you go from suspicion to confirmatoin? There are several tools available that can "automagically" alert you to changes in the system, like TripWire. These, used along with some other by-hand techniques will more often than not tell you if a system has been compromised.
The most recent types of compromises involve root-kits. root-kits are a package that provides a set of replacement programs for all the standard utilities, like ps, ls, find, etc. The root-kit tools are designed to hide all traces of the intruder being in your system (see rootshell for more info on root-kits).
root-kits exist primarily for GNU/Linux and Sun environments, but almost any system can have their standard utilities replaced. Most intruders place the root-kit configuration files in the /dev structure, but due to replacement of ls and find, it can be very hard to detect the new entries.
- Command tools:
- ifstatus - checks NIC's for promiscuous mode
- lsof - lists open files for running processes
- tcpdump - network packet analysis
- Larger change detection packages:
- Tripwire - is a tool that can detect file replacement on your system (i.e. an intruder has replaced your ps)
- rpm -Va will indicate whether files have been modified since installation on GNU/Linux systems supporting RPM.
- lppchk is similar to the rpm command, but for AIX systems.
Return to the Top of Page
Testing
If you don't check the security of your systems, intruders will be glad to do it for you. It's imperative for a Systems Administrator to routinely check the external security of their machines. Several tools exist to check / probe your machines for openings.
It's also very important to update your testing software or add the latest modules to the testing suite.
If you are responsible for an entire network (subnet) worth of machines, you should announce that you are going to scan / test the entire network before you actually do it-- you might be surprised how many other people are watching and will detect your scans!
- secure-sun-check - checks for common SunOS security configuration problems
- Nessus
- SecureScan - checks for IRIX security problems
- pmap_tools - toolsuite to check for portmap, rpc, rpcbind vulnerabilities
- nmap - multi-level security scanner
- ISS - multi-level security scanner
- Fremont - a network discovery tool
Return to the Top of Page
Recovering
Many (if not all) systems will be compromised. The first step to recovery is admitting you've been "taken". The best solution is to reinstall the system and recover known-good data. Quite often, however, it's necessary to recover in-place a compromised system.
The first rule of recovery is to not trust any of the data you see. Initially, it's impossible to tell what parts of the system the intruder has modified (including logs, applications, data, etc.)
- CERT provides an excellent document on how to recover from a "root" compromise.
Return to the Top of Page
LSU Specifics
- security@lsu.edu
The security@lsu.edu e-mail address has been established to receive security breach or news information on campus. Please feel free to e-mail any intrusion information you might have, questions, etc. to that address. Dr. Icaza is maintaining a database of UNIX security related events and we periodically send the Computer Crimes squad of the FBI, down in New Orleans, with updates. You are also encouraged to give the e-mail address to people outside of LSU who suspect an LSU machine is intruding them.Any information we receive, and feel should be made public knowledge, will be filtered to protect the original sender and disseminated through the NETCON@listserv.lsu.edu and TECHALRT@listserv.lsu.edu e-mailing lists. These addresses can also be used as a forum to discuss security related issues.
- abuse@lsu.edu
The abuse@lsu.edu e-mail address has been established to receive e-mail abuse information. If your systems are allowing e-mail relay, we've probably received and e-mail complaining about spam passing through it. This address is not to be used to report security incidents.
- InfraGard
LSU has membership with Dr. Emilio Icaza, Isaac Traxler, Brian Ropers-Huilman and Hortensia Valdez are all participating, and sitting on the acting Board of Directors, of the New Orleans Chapter of InfraGard. InfraGard is a joint multi-governmental agency / civilian organization whos mission is to share information about security issues and educate organizations about security risks. As part of our membership, we receive periodic e-mails from NIPC concerning known or potential security threats, both cyber and physical. If any information in these bulletins is relavent, it is forwarded to the NETCON and TECHALRT e-mailing lists.
Return to the Top of Page
Conclusion
Dr. Emilio A. Icaza, Director of High Performance Computing for the Office of Computing Services at LSU.
Isaac W. Traxler, Systems Administrator with High Performance Computing.
Brian D. Ropers-Huilman, Systems Administrator with High Performance Computing.
Special thanks to:
- Alric "Ric" Haag - for bringing the topic of security to the forefront on this campus.
- Will Hatcher, Terri Campbell and the rest of the Computer Crime Division of the New Orleans FBI branch.
- Sydney Reed and the New Orleans InfraGard Chapter.
- Stuart Thomas (security consultant)
- LSU Campus Police
Return to the Top of Page
The statements and opinions included in these pages
are those of Isaac W. Traxler, Brian D. Ropers-Huilman only. Any statements and opinions included in these pages are NOT
those of Louisiana State University or the LSU Board of Supervisors.
© 1999-2001 Isaac W. Traxler, Brian D. Ropers-Huilman
This page last updated 2001/05/17 10:40:54.