Notes:
|
|
|
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| News | See Also | Recommended Books | Recommended Links | Classic Papers | Usenix | CERT | Solaris security |
| People | Auditing | Presentations | Decoy-based defense | Humor | History | Etc |
There are two type major types of security papers that I am interested in:
Old classic papers that introduces an inprotant concept or tool, or threat. They may or may not have a practical value now, but still is an important part of the heritage without knowing which it is impossible to become a really good security speciist.
Resent how-to papers that have practical value. Among most promising generic sources of security papers three really stand out: Sun blueprint series, Usenix (Login and conferences) and SysAdmin magazine (in that particular order). SUNS institute and SecurityFocus also contain some interesting staff. National Security Agency also has some interesting papers, for example The Inevitability of Failure The Flawed Assumption of Security in Modern Computing Environments.
Of course one of the first thing to do if you try to immerse into a new field is to read classic papers. I value those author who are not only security researchers but gited programmers and among recent authors David Curry and Wietse Venema are my favorites. The latter also is the author of a really excellent MDA (Postscript). He also wrote several important papers including Murphy's law and computer security.
As for more practical papers , I would recommend to pay attention to the authors of Sun Security Blueprints. For example Alex Noordergraaf wrote one very important paper SolarisTM Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology. There are some other pretty decent Sun blueprint papers also well worth reading. After reading an excellent paper Build A Honeypot by Larry Spitzner I now think that he is a rising star in the computer security journalism. That's a really meteoritic rise that I would never expect from somebody "who used to blow up things of a different nature" ;-). Alex Noordergraaf wrote several other less important but still interesting papers that also well worth reading.
See also rootshell.com - docs -- good collection of documents. Among vendors RAPTOR has probably one of the best Web security library.
Usenix now opened its archives and can be a good source of papers on security. For example here is one interesting paper Infrastructure A Prerequisite for Effective Security by Bill Fithen, Steve Kalinowski, Jeff Carpenter, and Jed Pickel, CERT Coordination Center
The authors started their presentation with some scary data compiled by CERT. A 1997 survey shows that 50% of systems were not kept up to date with security patches after they were compromised. One site appeared in 35 incidents between 1997 and 1998; the site was used for password sniffing and probing of other sites in many of those cases. Ten of the 35 incidents involved root compromise of the host. In another break-in, 20-25 hosts were compromised. All of these systems needed to be rebuilt, but the site's administrator said that they didn't have enough resources to do so. The authors set out to improve infrastructure manageability at CERT by creating an easily maintained system of distributing software packages. The result is SAFARI, a centralized repository of 900 collections of software for multiple versions of UNIX. Using SAFARI, a sysadmin can build new systems from scratch and update existing systems with patches and new packages. SAFARI includes flexible version controls so that developers and admins can easily post and retrieve software packages from the same central repository.
Usenix membership is not required for the access of full text of papers that are more than a year old.
Dr. Nikolai Bezroukov
Note: Links to the sources are not necessary current (and keeping them current is not the goal of this page -- the selection of the most important papers is), but you can always use Google or other search engine to find some location of the text of WEB. In such cases I would appreciate information about broken link and the new URL for the paper.
|
Breathing new life into
old news
The more things change, the more they stay the same."
There are many resources available on the Internet to help with managing IT security -- far too many for the newcomer to be able to sort out the valuable ones from the useless ones. In this article, I'll present a number of very useful documents designed to help in managing enterprise security in a practical manner. I will review some of the most common documents that I've used to help IT organizations evaluate their security and provide them with assistance on what to do to maintain security. Rather than referring to the many, many books available or to voluminous and boring standards documents, I'll present freely available and easily understood documents that can be easily adapted and applied to most IT organizations.
Why do systems administrators need to use guides, practices, and checklists? The answer is simple -- admins can't possibly be experts in all areas of IT security that must be managed by modern enterprises. Even a small company with one or two servers, an Internet connection, and 20 or so workstations poses a lot of work to fully evaluate how secure it is. So, we need guides, written practices, and checklists to provide us with guidance on how to maintain security and to make sure that we cover all the details.
Specifically in this article, I'll review the Open Source Security Testing Methodology Manual (OSSTMM), a number of NIST Special Publications, some of the DISA guides and checklists, the Standard of Good Practice (SoGP), and the ISO17799 standard. These are all freely available (except for ISO17799) and will greatly ease the task of evaluating and maintaining enterprise security.
The Open Source Security Testing Methodology Manual (OSSTMM)
The Open Source Security Testing Methodology Manual is a guide for evaluating how secure systems are. It contains detailed instructions on how to test systems in a methodological way, and how to evaluate and report on the results.
The OSSTMM consists of six sections:
- Information Security
- Process Security
- Internet Technology Security
- Communications Security
- Wireless Security
- Physical Security
It also includes a number of templates intended for use during the testing process to capture the information gathered.
The OSSTMM is a great resource for systems administrators who want to evaluate the security of a wide range of systems in an ordered and detailed way. It contains instructions on testing systems but few details on how to protect systems.
NIST Special Publications
The Information Technology Laboratory of the National Institute of Standards and Technology (NIST) publishes a number of guides and handbooks under the Special Publications program. Some of these are quite high-level, covering areas of management, policy, and governance. But many include details that are perfect for systems administrators and operations people. The following is an overview of some of the available guides -- check the NIST Web site for the full list of currently available guides.
The great thing about the NIST documents and checklists is that they are not copyrighted. That's right; you can copy and modify these as much as you want without fear of reprisals. You can modify these checklists to suit your own requirements, for example, to develop your own checklist for new servers going into production or to define your own security auditing process. You can even adapt these guides to become your new security policy.
NIST SP800-100 Information Security Handbook: A Guide for Managers
This is a big document (178 pages) that supersedes the older SP800-12 as a general handbook on managing information security. For IT managers or systems administrators new to security this is really the best place to start, although much of the content is at a high level targeted for managers. Some of the chapters, such as those on governance and investment management will be too high level for systems administrators, but others such as the ones on incident response, contingency planning, and configuration management will be very useful. This guide includes an appendix containing a list of Frequently Asked Questions (FAQs), which provides a lot of useful information.
NIST SP800-44 Guidelines on Securing Public Web Servers
If you're operating Web servers on the public Internet, then you need to read this guide. Aimed at technical and operations people, it describes the threats to public Web servers and provides detailed guidelines for securing them. The following areas are covered:
- Planning and management of Web servers
- Securing the operating system
- Securely installing and configuring the Web server
- Securing Web content
- Authentication and encryption technologies
- Implementing a secure network for a Web server
- Administering a Web server
Examples and references are provided for the Apache and Microsoft IIS Web servers, and there is a comprehensive appendix with details on installing and configuring both of these. There is also an appendix containing a very useful checklist for securing Web servers.
NIST SP800-45 Guidelines on Electronic Mail Security
Version 2 of the Guidelines for Electronic Mail Security was released in February 2007. This guide covers many areas from the installation and secure operation of email servers to encryption and signing of emails and securing various email clients. The following areas are covered in detail:
- Planning and managing mail servers
- Securing the mail server operating system
- Securing mail servers and content
- Administering the email server
- Implementing a secure network infrastructure
- Securing mail clients
- Signing and encrypting email content
As in the guide for Web servers, a checklist is provided in the Appendices for quickly checking the security of an existing or planned mail server. It doesn't have any operating system or mail software specific sections but is detailed enough to cover almost any installation.
NIST SP800-81 Secure Domain Name System (DNS) Deployment Guide
DNS is a critical component of most IT environments, and risks to DNS need to be taken very seriously and managed appropriately. This guide presents recommendations for secure deployment of DNS servers. It examines the common threats to DNS and recommends approaches to minimize them. It covers the technical details of installing the BIND DNS server on Unix systems and provides recommendations for securing the operating system.
This guide explains how to secure zone transfers with TSIG signatures and gives a very good overview of DNSSEC implementation and management. It is thoroughly recommended if you are involved with managing DNSSEC services.
NIST SP800-48 Wireless Network Security (802.11, Bluetooth, and Handheld Devices)
This guide was written in 2002, so it is a bit outdated now. However, the fundamentals of wireless technology haven't changed a lot, and this guide does a very good job of explaining the threats to wireless networks. It covers primarily IEEE 802.11 (WiFi) and Bluetooth and presents good guidelines on security controls, such as positioning access points, controlling network access, and encryption methods. Even if you're not familiar with wireless networking, this guide serves as an excellent introduction.
NIST SP800-92 Guide to Computer Security Log Management
Just about every device in the world of IT generates log messages. Some devices, such as firewalls, generate huge amounts of log data all of which needs to be managed in a secure manner.
This guide introduces the requirement to securely manage log data. It includes guides on log management infrastructure and processes such as reporting and analysis tools. It also includes details on the Unix syslog system and contains references to many tools and further guides for managing log data.
NIST and DISA Checklists
Sometimes we just don't have the spare time to read though the lengthy guides; this is when checklists come in handy. NIST has developed a program for the development of checklists for securing IT systems. The program is now owned by DISA (Defense Information Systems Agency), and it provides a large number of checklists that make the job of evaluating systems much easier and more methodological.
A number of checklists are available here, including ones covering:
- Most versions of Unix
- Microsoft Windows 2000, 20003, XP, Vista
- Oracle RDBMS
- BIND DNS servers
- Cisco PIX firewalls
- Cisco IOS
- Wireless networks
- Apache Web server
Unix Security Checklist
The Unix Security Checklist comes as a zip file containing a number of documents with three major sections and five appendices. Some of the documents are very large (one is 360 pages long). The checklist is very detailed and contains checks for the Unix OS and most common applications found on Unix (such as SSH). The checks are all in .doc Word format, which makes it very easy to adapt them to your own purposes. The most important sections are Section 2 and Section 3.
Section 2, "SRR Results Report" contains a table that allows you to document the vulnerabilities discovered during the Security Readiness Review (SRR). Section 3, "System Check Procedures", covers procedures about how to perform the SRR for Unix systems. Unix systems covered by this checklist are HP-UX, AIX, Solaris, and Red Hat Linux.
Standard of Good Practice (SoGP)
Published by the Information Security Forum (ISF), the Standard of Good Practice presents comprehensive best practices for managing IT systems from a business perspective but in a practical and achievable way. It has been targeted for larger businesses, but is still applicable to the small to medium businesses as well.
The standard is broken down into six sections, which it calls "aspects":
- Aspect SM: Security Management
- Aspect SD: System Development
- Aspect CB: Critical Business Applications
- Aspect CI: Computer Installations
- Aspect NW: Networks
- Aspect UE: User Environment
This is a very large document (247 pages), which would be very well suited for adoption as a comprehensive security policy. Even if you're not specifically solving security problems, the SoGP would act as a good set of guidelines for IT management practices.
ISO17799
No overview of security guides and practices would be complete without a mention of ISO17799. Titled "A Code of Practice for Information Security Management", it was originally developed in 1993 by a number of companies and published as a British standard. It became an ISO standard in 2000 with a number of later editions and add-on documents following. It essentially consists of about 100 security controls within 10 major security headings. It is intended to be used as a reference document to identify the measures required to be applied to specific areas and issues. It contains 10 sections on the following subjects:
- Development of an enterprise IT security policy
- Establishing a security organization, defining management and responsibility
- Asset classification and control
- Security of personnel -- resources, training, awareness, incident reporting
- Implementing physical security controls
- Management of computers and networks
- Controlling access to computer systems
- Integrating security into new systems
- Business continuity and disaster planning
- Compliance with security requirements
The good thing about ISO17799 is that it is a standard against which an organization can be audited, and it can be seen as a common standard for IT security management. There are also many additional documents and books available to supplement the standard.
The bad thing about ISO17799 is that it is heavily commercialized; the 115-page document costs approximately US $200 and contains information that is available elsewhere at no cost (such as the SoGP).
Conclusions
There are many security guides available, and in this article I've presented some of the best ones that you can get and use for free. The OSSTMM and NIST/DISA checklists are good guides for evaluating the security of existing systems. The NIST guides are good for defining the best practices to manage systems securely, and the SoGP and ISO17799 documents offer standards against which your enterprise can be evaluated.
Managing IT security across the enterprise can be a bewildering experience; many managers and systems administrators have problems simply deciding where to start. With the right guides and checklists, however, the job can be greatly simplified and more easily understood.
Resources
ISO17799 -- http://www.iso-17799.com/
NIST & DISA Checklists -- http://csrc.nist.gov/checklists/repository/ or http://iase.disa.mil/stigs/checklist/index.html
NIST Special Publications -- http://csrc.nist.gov/publications
Open Source Security Testing Methodology Manual (OSSTMM) -- http://www.osstmm.org
Standard of Good Practice (SoGP) -- http://www.isfsecuritystandard.com/index_ns.htm
Unix Security Checklist -- http://csrc.nist.gov/checklists/repository/1078.html
Kerry Thompson is a Security Consultant in Auckland, New Zealand with more than 20 years commercial experience in Unix systems, networking, and security. In his spare time he is a technical writer, software developer, sheep farmer, woodworker, private pilot, and father. Contact him at: kerry@crypt.gen.nz.
This paper describes the basic principles of designing and administering a relatively secure network. The principles are illustrated by describing the security issues a hypothetical company faces as the networks that support its operations evolve from strictly private, through a mix of Internet and private nets, to a final state in which the Internet is fully integrated into its operations, and the company participates in international electronic commerce. At each stage, the vulnerabilities and threats that the company faces, the countermeasures that it considers, and the residual risk the company accepts are noted. Network security policy and services are discussed, and a description of Internet architecture and vulnerabilities provides additional technical detail underlying the scenario. Finally, a number of building blocks for secure networks are presented that can mitigate some of the vulnerabilities. Keywords: computer network security, internet, cryptography, authentication
From
Mary
Baker's Publications
Burns describes a PAM created to check the strength of user-supplied passwords when user changes his/her password. Very good and simple approach to improving password security.
Paul unravels X.509 certificates, one of the most popular computer security standards specifying the contents of digital certificates, by showing how you can decode and display them in a readable form. Additional resources include x509.txt (listings) and x509.zip (source code).
Attack trees provide a formal, methodical way of describing the security of systems, based on varying attacks. Bruce shows how you can use them to improve security by modeling attacks.
[Jan 15, 1999]
Network Magazine Back Issues July 1999 Security Reality Check by Rik Farrow
[Jan 15, 1999]
Internet Application Security -- decent overview
[Jan 3, 1999] SysAdmin: Implementing Security on Linux by Patrick Lambert -- good discussion of basics
Here is good comment on this paper from LinuxToday
| Fred Mobach - Subject: Very good story ... (Jan 2, 2000, 20:05:28 ) |
| ... although some additional notes might be helpful. I enjoy every
story on security, but reading BugTraq on a daily base has made me
paranoid ?!? You should install GNU/Linux on a system, which is standalone or is only connected to a small set of systems (in a test network) where others don't have access. Otherwise you can't never be sure if your system is infected during the install. Who do you trust ? Root logins via telnet or ssh are never allowed by me. If you need root access, sudo or su will do. In addition to the setuid problem also the guid should be taken care for (-2000 in the find command). To see with ports are open to the world run 'nmap -sS -O hostname' to see them. Whichever you don't need or don't know : close them down, you really don't need them (otherwise you would know). If you installed firewalling afterwards on your system, run nmap again. If you're running OpenSSH or SSH, you don't need in some cases inetd. Telnet, ftp, rcp are substituted by these secure shells. Normally I need neither inetd nor portmapper. If you really do need inetd, consider xinetd. In many cases the RPC's aren't needed, they can be substituted by expect scripts. Also rsync is of great help. You won't run NFS on systems, connected to the Internet, do you ? Nor X11, I assume. If you think you do need these protocols, you inserted a firewall between the Internet and your system to prohibit these protocols to be exchanged with other computers on the Internet ? Firewalling ? Very important. You did start with deny on all interfaces as a default, right ? No comments on the final thoughts, he's really on topic. For those lucky people who understand the Dutch language, have a look at http://www.nluug.nl/features/ for an advances study on firewalling. Regards, Fred |
See also:
LinuxHelp.net: Secure Shell (SSH/SSH2) Setup Guide (Dec 29, 1999)
SecurityPortal: OpenSource projects - what I learned from Bastille (and others) (Dec 24, 1999)
IBM developerWorks: Open source software: Will it make me secure? (Dec 24, 1999)
ZDTV: The Philosophy of Security (Dec 21, 1999)
LinuxPR: Bastille Linux releases v1.0.0 at SANS San Francisco Security Conference 99 (Dec 14, 1999)
UNIX & LINUX Computing Journal: Linux Security Tools (Dec 12, 1999)
Linux Gazette: Securing Linux: The First Steps (Nov 15, 1999)
[Nov.7, 1999]
forum - Guest Feature Implementing a Secure Network
Hardening a Unix computer for Internet use
Wizard's Guide to Security by Carole Fennelly
Dave Wreski: Linux Security Administrator's Guide.
A very good handbook to improve the security of our Linux system. Dave Wreski
explains here the filesystem security mechanisms, passwords, Cryptography...
DOWNLOAD.
Usenix Security Symposiums
Complete Usenix Security Symposium '02 Program
8th USENIX Security Symposium, Washington, D.C.
7th USENIX Security Symposium, San Antonio, Texas
The Sixth USENIX Security Symposium, San Jose, California
5TH USENIX UNIX Security Symposium
Security IV, Santa Clara, California
login;
Special issues:
Selected papers
Note: In case some link below turned to be dead please check ResearchIndex [NEC Research Institute; CiteSeer; Computer Science]. Many papers are also available in postscript from http://www.deter.com/unix/ You can also try the Purdue Coast archive (http://www.cerias.purdue.edu/coast/archive/data/categ21.html) but this site prohibit direct pointing and thus not listed in links. I actually hate one particular security pseudo-academic for this restriction ;-)
**** [Morris] A Weakness in the 4.2BSD Unix TCP-IP Software by Robert T. Morris.
Each CERT Security Improvement module addresses an important but narrowly defined problem in network security. It provides guidance to help organizations improve the security of their networked computer systems.
Each module page links to a series of practices and implementations. Practices describe the choices and issues that must be addressed to solve a network security problem. Implementations describe tasks that implement recommendations described in the practices. For more information, read the section about module structure.
***** SolarisTM Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology By Alex Noordergraaf and Keith Watson December 1999. Great paper. This probably No.1 paper that explains how to remove unnecessary packages -- actually they consider a very practical case of Solaris + Netscape Enterprise Server. The paper a little bit weak on tool side, though.
The Solaris Operating Environment installation process requires the selection of one of four installation clusters:
Each installation cluster represents a specific group of packages (operating system modules) to be installed. This grouping together of packages into large clusters is done to simplify the installation of the OS for the mass market. Because each of these installation clusters contains support for a variety of hardware platforms (SolarisTM Operating Environment (Intel Platform Edition), microSPARCTM, UltraSPARCTM, UltraSPARC II, and so on) and software requirements (NIS, NIS+, DNS, OpenWindowsTM, Common Desktop Environment (CDE), Development, CAD, and more), far more packages are installed than will actually ever be used on a single Solaris Operating Enironment.
The Core cluster installs the smallest Solaris Operating Environment image. Only packages that may be required for any SPARCTM or Solaris Operating Environment (Intel Platform Edition) system are installed. The End User cluster builds on the Core cluster by also installing the window managers included with the Solaris Operating Environment (OpenWindows and CDE). The Developer and Entire Distribution clusters include additional libraries, header files, and software packages that may be needed on systems used as compile and development servers.
The size of the clusters varies significantly: the Core cluster contains only 39 packages and uses 52MBytes; the End User cluster has 142 packages and uses 242 MBytes; the Developer cluster has 235 packages and consumes 493 MBytes of disk space. Experience to date has shown that in many cases, a secure server may require only 10 Solaris Operating Environment packages and use as few as 36MBytes of disk space.
Installing unnecessary services, packages, and applications can severely compromise system security. One well known example of this is the rpc.cmsd daemon, which is unnecessary on many data center systems. This daemon is installed and started by default when the End User, Developer, or Entire Distribution cluster is chosen during the installation process.
There have been many bugs filed against the rpc.cmsd subsystem of OpenWindows/CDE in the last few years, and at least two CERT advisories (CA-99-08, CA-96.09). To make matters even worse, scanners for rpc.cmsd are included in the most common Internet scanning tools available on the Internet. The best protection against rpc.cmsd vulnerabilities is to not install the daemon at all, and avoid having to insure it is not accidentally enabled.
The problem described above is well known in the computer industry, and there are hundreds of similar examples. Not surprisingly, almost every security reference book ever written discusses the need to perform "minimal OS installations" [Garfinkel]. Unfortunately, this is easier said than done. Other than the occasional firewall, no software applications are shipped with lists of their package requirements, and there's no easy way of determining this information other then through trial and error.
Because it is so difficult to determine the minimal set of necessary packages, system administrators commonly just install the Entire Distribution cluster. While this may be the easiest to do from the short-term perspective of getting a system up and running, it makes it nearly impossible to secure the system. Unfortunately, this practice is all too common, and is even done by so-called experts brought in to provide infrastructure support, web services, or application support. (If your organization is outsourcing such activities, be sure to require the supplier to provide information on what their OS installation policies and procedures are, or you may be in for some unpleasant surprises.)
The rest of this article presents one method for determining the minimal set of packages required by a particular application--the iPlanetTM Enterprise Server. Future articles will discuss other applications. The tentative list includes NFSTM Servers (with SecureRPC and Solstice DiskSuiteTM), iPlanetTM WebTop, and SunTM Cluster. If you have followed this procedure and developed the scripts for a particular application, please forward them to the authors for inclusion in future articles.
CERT® Security Improvement Modules very uneven, some are weak, some are outdated.
Each CERT Security Improvement module addresses an important but narrowly defined problem in network security. It provides guidance to help organizations improve the security of their networked computer systems.
Each module page links to a series of practices and implementations. Practices describe the choices and issues that must be addressed to solve a network security problem. Implementations describe tasks that implement recommendations described in the practices. For more information, read the section about module structure.
- Configuring Solaris as a WEB server -- does not use or recommend Titan or similar script.
- Using Tripwire to verify the integrity of directories and files on systems running Solaris 2.x
- Inspecting your Solaris system and network logs for evidence of intrusions
- Inspecting the logs produced by the TCP wrapper program on a Solaris 2.x system
- Configuring NCSA httpd and Web-server content directories on a Sun Solaris 2.5.1 host
- Enabling process accounting on systems running Solaris 2.x
- Installing, configuring, and using tcp wrapper to log unauthorized connection attempts on systems running Solaris 2.x
- Configuring and using syslogd to collect logging messages on systems running Solaris 2.x
- Using newsyslog to rotate files containing logging messages on systems running Solaris 2.x
- Installing, configuring, and using logdaemon to log unauthorized login attempts on systems running Solaris 2.x
- Installing, configuring, and using logdaemon to log unauthorized connection attempts to rshd and rlogind on systems running Solaris 2.x
- Understanding system log files on a Solaris 2.x operating system
- Installing, configuring, and using swatch to analyze log messages on systems running Solaris 2.x
- Installing, configuring, and using logsurfer on systems running Solaris 2.x
- Configuring and installing lsof 4.50 on systems running Solaris 2.x
- Configuring and installing top 3.5 on systems running Solaris 2.x
- Installing, Configuring, and using npasswd to improve password quality on systems running Solaris 2.x --ourdated; i saw a paper about PAM implementation of npasswd is Sysadmin
- Installing and configuring sps to examine processes on systems running Solaris 2.x
- Installing and securing Solaris 2.6 servers
- Installing, configuring, and operating the secure shell (SSH) on systems running Solaris 2.x
- Characterizing files and directories with native tools on Solaris 2.X
- Detecting changes in files and directories with native tools on Solaris 2.X
- Installing and operating lastcomm on systems running Solaris 2.x
- Installing, configuring, and using spar 1.3 on systems running Solaris 2.x
- Installing and operating tcpdump 3.5.x on systems running Solaris 2.x
- Installing, configuring, and using argus to monitor systems running Solaris 2.x
- Using newarguslog to rotate log files on systems running Solaris 2.x
- Installing libpcap to support network packet tools on systems sunning Solaris 2.x
- Writing rules and understanding alerts for Snort, a network intrusion detection system
- Disabling network services on systems running Solaris 2.x
- Installing noshell to support the detection of access to disabled accounts on systems running Solaris 2.x.
- Disabling user accounts on systems running Solaris 2.x
- Installing OpenSSL to ensure availability of cryptographic libraries on systems running Solaris 2.x.
- Installing and Operating ssldump 0.9 Beta 1 on systems running Solaris 2.x.
Building Secure N-Tier Environments by Alex Noordergraaf - This
article provides recommendations on how to architect and implement secure N-Tier
commerce environments.
****
Securing Solaris Servers -- (Securing Solaris Servers - A Checklist Approach
Paul D. J. Vandenberg and Susan D. Wyess) point by point checklist from Usenix
-- this is probably the third best paper on this topic paper that is available
on the Internet.
http://www.usenix.org/sage/sysadmins/solaris/index.html
This material is excerpted from an internal U.S. Government document on web security, which the authors played leading roles in preparing. This material has been officially reviewed, and the authors have been granted permission to use this material in a non-official publication.
Server Security Checklist Overview
Acknowledgements
About the Authors
Background
Goal
Using the Checklists
References
Armoring Solaris by Lance Spitzner
**** Armoring Solaris by Lance Spitzner: http://www.enteract.com/~lspitz/armoring.html -- good and based on the concept of minimizing the number of packages installed.
*****
SolarisTM
Operating Environment Network Settings for Security[updated December
2000]
-by Keith Watson and Alex
Noordergraaf
Discuss the many low-level network options available within Solaris and their
impact on security.
**** Solaris Security Guide -- good sabernet paper. Some advice is of qustionable quolity. Yes, of course, you can enable BSM but you better buy an additional hard 80G drive before and hire somebody to look into all those logs ;-)
dir:/var/audit flags:lo,ad,pc,fc,fd,fm naflags:lo,ad # # lo - login/logout events # ad - administrative actions: mount, exportfs, etc. # pc - process operations: fork, exec, exit, etc. # fc - file creation # fd - file deletion
**** Installing a Firewall bastion host Hardening Solaris 2.7 By Seбn Boran. He is the author of IT Security Cookbook -- this a very good paper that contain important information that is difficult to find elsewhere.
This article presents a concise step-by-step approach to securely installing Solaris for use in a firewall DMZ, or other sensitive environment. There are many books and web articles on general hardening, but deciding exactly how to do it for your Solaris system can be tricky.
The focus in this article is on preparing the Operating System to securely run services, rather than the setup of the services themselves. Firewall engines like Raptor, Firewall-1, Sunscreen etc. are not examined here.
This article is specific to Solaris 2.7, other versions are similar, but will have some differences in startup file names, kernel parameters etc. This article has been updated since the original release, see the Additional Notes section.
***+ Strip Down SUN Servers by Strip Down SUN Servers by Joe@Checkpoint: looks like rework of Security FAQ. Decent list of checks, but nothing special. Might be useful as an add on to Vandenberg-Wyess paper. http://www2.checkpoint.com/~joe/strip-sunserver.txt
1) Keep the system disconnected from the network until all is ready.
2) Install only the core operating system, adding only necessary packages.
1. Install the latest OS version supported by CheckPoint S/W Tech.
2. Be sure root has a umask setting of 077 or 027 after you have fully configured the system.
3. Be sure root has a safe search path, as in /usr/bin:/sbin:/usr/sbin It helps avoid Trojan horses in the current working directory.
4. Generally, examine all "S" files in /etc/rc2.d and /etc/rc3.d. Any files that start unneeded facilities should be renamed (be sure the new names don't start with "S"). Test all boot files changes by rebooting, examining /var/adm/messages, and checking for extraneous processes in ps -elf output.
5. Make sure the to enable the "CONSOLE" line in /etc/default/login. To disable use of ftp by root, add "root" to /etc/ftpusers.
6. Remove /etc/hosts.equiv, /.rhosts, and all of the "r" commands from /etc/inetd.conf Do a kill -HUP of the inetd process.
7. Remove, lock, or comment out unnecessary accounts, including "sys", "uucp", "nuucp", and "listen". The cleanest way to shut them down is to put "NP" in the password field of the /etc/shadow file. Also consider using the noshell program to log attempts to use secured accounts.
8. The file /etc/logindevperm contains configuration information to tell the system the permissions to set on devices associated with login (console, keyboard, etc). Check the values in this file and modify them to give different permissions.
9. No file in /etc needs to be group writeable. Remove group write permission via the command chmod -R g-w /etc
10. By default, if a Solaris machine has more than one network interface, Solaris will route packets between the multiple interfaces. This behavior is controlled by /etc/init.d/inetinit. To turn of routing on a Solaris 2.4 (or lesser) machine, add "ndd -set /dev/ip ip_forwarding 0" at the end of /etc/init.d/inetinit. For Solaris 2.5, simply "touch /etc/notrouter". Be aware that there is a small window of vulnerability during startup when the machine may route, before the routing is turned off.
FOCUS on Sun Solaris Default Processes and init.d Pt. I
This article has been written to provide insight into a stock installation of Solaris 8, and the services started by default. Solaris 8 by default runs many services. This example was provided using Solaris 8, which is the latest version available, and a Sparcstation 20. Most of this document will apply to releases of Solaris prior to 8, and to both the Sparc and Intel architectures. For documentation purposes, a full OEM install was done. Many topics discussed will be familiar to seasoned administrators. However, this document will benefit all parties involved in the administration and security aspects of Solaris.
Here is a simple approach which merely checks the files integrity against what was originally installed. If something has changed, i.e. someone has replaced a system binary with something malicious, it will find it. Of course if you don't scan everything, you won't really know.
This script will compare what is on a CD-ROM to what is on a hard drive. This assumes that you can fit everything important to you on a CD. I think this is fairly reasonable if you only take system/software binaries and not data. The minimal Solaris install is 200-300 MB depending on version, which will fit fairly easily on a CD. Having a good trusted backup is paramount. Without it you can only guess as to what has been changed.
#!/bin/sh cd /cdrom find . -type f | grep -v TRANS.TBL | \ grep -v /proc | \ while read F do VAR1=`md5sum $F | awk '{print $1}'` VAR2=`md5sum ${F#.} | awk '{print $1}'` if [ "$VAR1" != "$VAR2" ] then echo $F CHANGED echo $VAR1 $VAR2 fi doneWhen setting up a system, include a run of the following script. It is paramount that this be done before connecting to the Internet. That way it is a "trusted" OS at the time you run this. If you had your system on the Internet for two years and then do it, you may have already been attacked, and just don't know it.
Rapid Recovery Techniques: Exploring the Solaris[tm] Software Registry
****
Rapid Recovery Techniques: Exploring the Solaris[tm] Software Registry
-by Richard Elling Discuss how
to use processes to recover from errors caused by people.
{***} YASSP Yet Another Solaris Security Package by Jean Chouanard, Xerox PARC. See also Softpanorama Unix Audit and internal Scanning Tools (Internal Vulnerability Scanning) page. Package seems to be dead (was not updated since November 2000)
As the source of the SECclean package are available, it is easy for you to copy it and to localize it so it will reflect your configuration. From this package, we have derived different classes of package to install NIS server, NFS server and end user workstation.
Long list of RC files turn off : "cacheos cachefs.root asppp uucp cachefs.daemon xntpd spc rpc autoinstall nfs.client autofs nscd lp nfs.server volmgt PRESERVE sendmail cacheos.finish sysid.sys sysid.net snmpdx dmi dtlogin power init.dmi init.snmpdx".
These names are the name of the init files located in the
/etc/init.d directory. For all the links existing under any /etc/rc?.d/
directory, the postinstall script will delete these link and write a trace
trace log under /etc/rc?.d/Disable-By-SECclean which enable you to re-create
the link if needed.
If you need to re-enable some of these RC file, you can either re-create the
package to fit your need (see Package modification) or
just manually recreate the link after the install.
These files are based on the SUN distribution files, but have been simplified.
*** Spreading the wealth -- nothing new. Rehash of old info.
Peter is conducting an experiment this month. He'd like his column to act as a forum featuring tips gathered from around our wide sysadmin audience. Read Peter's helpful hints here -- and then send in your own! If the experiment succeeds, network tips will become a regular feature of future columns as well. (1,300 words)
- Limit root login sources and methods
Disable root logins everywhere but on the system console by uncommenting the
CONSOLE=line in/etc/default/login. Disable ftp root logins by addingroot(and other system accounts) to/etc/ftpusers.
- Prevent an entire category of security attack
Disable all stack-overflow security attacks by adding the line
noexec_user_stackto/etc/systemand then rebooting. (Available starting with Solaris 2.6.)
- Increase startup script security
(This tip from Jochen Bern.)
There are a couple of security holes that a simple "umask 022" at the beginning of boot scripts will fix -- and virtually no boot scripts break by adding it.
Room to grow 'Debugging' Solaris
As a leader in Internet technologies, Sun must assume more responsibility for the security of its users' applications and data. Many straightforward improvements to Solaris would benefit the vast majority of users. For example, the
fix-modesprogram, which is used frequently by sites wishing to secure their Solaris installations, has no known side effects. Sun could eliminate the need for the program by implementing its capabilities as part of a Solaris release.Another tool that Sun could incorporate is Titan, again cowritten by a Sun employee. The ASET tool is included with Solaris, but is rarely found to be useful by the security community. To improve the security of Solaris, more than a single tool is needed; there must be a systemic approach to improving its security as shipped and allowing systems administrators to further increase its security.
Many other changes, such as those found in Solaris Security FAQ, could be implemented or made optional with the use of simple programs or scripts. In fact, Jean Chouanard of Xerox PARC has done just that by using content from the FAQ and Hal Pomeranz's forthcoming SANS Securing Solaris: Step-by-Step booklet. The script is available for downloading; see Resources for the URL.
Other potential security improvements include making
syslog.confwork out of the box, keeping BIND up to date, and replacing sendmail with something more secure (qmail, for instance).
***+ Peter Galvin's Solaris Security FAQ -- important historical document. Almost a standard reference on Solaris security. Partially outdated. Still contains a very good points. Some points are incorrect for Solaris 7 and 8. Some recommendations are pretty superficial.
***+ Securing a Solaris 2 Machine [local copy]
This document is just to get you started; it is not exhaustive. The Computing Service offers the advice in this document only as a guide to the sort of problems of which a Unix System Administrator should be aware and accepts no responsibility for any problems which may arise from its application to particular systems outside the control of the Service.
This document should be read in conjunction with the Computing Service's leaflet ``So you want to run a secure Unix system, do you?'' which covers the general concepts.
The most recent version of Solaris 2 is version 2.4. The Sun CD comes with a directory of patches. Load these patches together after the operating system at install time.
***+ Secure Solaris Setup -- this is a decent starting document, but there are better than that.[Dec 20, 1999]
This page is intended to walk you through some of the steps required to set up a secure Solaris machine. For obvious reasons, I am unable to post all of the security measures that I take on the machines that I manage. The following steps should be considered a good beginning, not a guarantee that the resulting machine will be secure
- Install the current Sun patches for your OS.
- Install the current version of Eric Allman's sendmail.
- Install tcp wrappers. These are available from several ftp sites, including Coast.
- Consider alternative login authentication schemes, such as S/Key for remote logins. Other systems worthy of your consideration are ssh and kerberos.
- Change file and directory ownerships and permissions, where appropriate. Most directories should not have group write permissions, and system files should be owned by root (with the possible exceptions of some SUID executables).
- Verify the contents of your /.rhosts and /etc/hosts.equiv files. Also edit your /usr/dt/config/Xaccess and/or /etc/dt/config/Xaccess files so that you only provide xdm login service to appropriate external hosts. (The syntax of these files is explained in the comments.) In most cases, "localhost" should be the only entry, and there should be no starred entries.
- Configure Tripwire and set up a Tripwire database NOW, while you know that your system has not been altered.
- Examine the SUID and SGID files on your system. Make sure that no SUID files exist on your system that do not come from you. Consider disabling SUID and SGID permissions on commands that you do not use or that you only use as root.
- Monitor system activity on an ongoing basis. Use
sarto keep track of usage, and be suspicious about unexplained spikes. Usetopto pinpoint the usage hogs. Pay particular attention to processes that continue to run after the users have logged out, especially if they have names likebnc,eggdrop, orirc.- Install npasswd. If you have a password file independent of CIT's, run Crack on it on a regular basis.
- Examine and keep up on security advisories
- For Solaris 2.6+ systems, you can disable the ability to execute code from the stack. Add the line:
set noexec_user_stack=1
to the/etc/systemfile and reboot. For more information, see Executable Stacks and Security for more information.
***+
Hardening a Unix computer for Internet use by Hal Stern's. See also
his other Sysadmin columns at
/sunworldonline/common/swol-backissues-columns.html#sysadmin
Rob Kolstad, long-time USENIX executive and noted industry personality, often points out that a good system administrator is a master of change on many time scales. That statement is most appropriate in the context of last month's topic, managing TCP/IP connections....
... ... ...
Connection erection
Just because you can name the remote end of a socket with an IP address and port number pair doesn't mean the other side can or even wants to talk to you. Making yourself appear interesting (and trusted) is a security problem we'll cover shortly. Making sure your servers have sufficient connection management resources is a growing performance problem. As the use of network services has exploded, many years-old assumptions about resource allocation have proven far too restrictive.A server-side process prepares to accept socket connections by first calling
listen()and thenaccept(). The first call determines the depth of the incoming connection queue, while the second call is what actually puts the socket into a receive-ready state. In the days of pre-Internet boom the default value of five pending connections was frequently hard-coded in the implementation oflisten(). Current socket interface code, however, interprets the argument and sets the queue depth. When the socket in question is owned byhttpd, or any other process that receives a high volume of connection requests, the queue depth is a critical performance limit.An embryonic socket connection goes through a three-way handshake between client and server. The connection stays on the incoming connection queue until the handshake has been completed. Knowing the steps involved will help you determine just how long the average connection dance will take.
- The connecting side (client), sends a connection request to the server, asking it to synchronize a connection (a so-called SYN packet).
- If there's room in the queue, the server accepts the request, and returns an acknowledgement with its first sequence number.
- The client acknowledges the server's initial sequence number, and the connection is established.
The connection remains in the queue for the duration of the last two packet exchanges, or the total of the round-trip network transfer time between client and server, plus the time required for the client to process the server's initial packet.
Once the connection queue is full, further attempts to connect to the socket are discarded. If you find connections are refused, or if your browser is complaining that it can't open a URL because the server isn't responding, you're probably bumping into the backlog limit.
Using a bit of queuing theory, we can determine the maximum connection request rate (RR) knowing the average round-trip time (RT) and the connection queue depth (