DOCSLIB.ORG

Evaluating UNIX Security Previous Screen Allen B

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Evaluating UNIX Security Previous Screen Allen B 84-01-15.1 Evaluating UNIX Security Previous screen Allen B. Lum Payoff The UNIX operating system's basic security features include password protection, access permission, user profiles, shell scripts, and file ownership. Because new and enhanced UNIX security features are continually being added to these features in response to the demands of an increasingly competitive user community, information security professionals must begin with an understanding of the basic UNIX security environment. This article covers the fundamental security features that can be found in most of the currently available versions of the UNIX operating system. Several checklists are included at the end of the article to assist administrators in ensuring the security of UNIX systems. Problems Addressed The UNIX operating system was originally developed for use by programmers within an open systems environment. The adoption of UNIX as a common operating system across several different platforms has increased the need for security beyond its original purpose. As a result, many UNIX installations have less than optimal security. In addition, there are several versions of UNIX on the market today with differing security features. This article discusses basic access controls (e.g., passwords) and directory and file permissions within the UNIX system. The concepts discussed are applicable to all versions of UNIX unless specifically noted otherwise. UNIX History As the majority of UNIX users know, UNIX was developed at AT Bell Laboratories in the late 1960s by Thompson and Ritchie; the name UNIXis a contraction of uni and multics. The original UNIX system software was written in the assembler language to run on the digital PDP-7 computer. In the early 1970s, UNIX was ported over to the PDP-11 and rewritten in the C programming language. Rewriting UNIX in C enabled the UNIX operating system to be used on other hardware platforms that supported a C compiler. By this time, Bell Labs distributed the UNIX operating system free to universities and the federal government. The rapid decrease in the cost of computer hardware specifically the Reduced Instruction Set Computing processor, which supports the UNIX operating system resulted in wide acceptance of UNIX by the business sector. In 1983, AT announced support of the UNIX operating system under the product name System III. The current version as of this writing is System V Release 4. Other manufacturers have licensed the source code from AT and implemented their own versions with additional features not found in AT's version. Examples of different implementations include SunOS (Sun Microsystems, Inc., Mountain View CA) and the ULTRIX systems (Digital Equipment Corp., Maynard MA). Until recently, UNIX vendors did not place security features as a top priority because customers had not demanded them. In light of recent network intrusions, however, security needs have come into focus, and vendors are responding accordingly. Each vendor's version of UNIX differs in terms of security features, because the vendors obtain the source code of the UNIX operating system and implement various features depending on their particular target market. It is important to examine the vendor documentation for all possible security features. Basic UNIX Architecture Previous screen The UNIX operating system can be divided into three components. The first component is called the UNIX operating system kernel, or simply the kernel. The kernel is the core of the UNIX system and resides in main memory; it must be considered the heart of the UNIX operating system. The second component may be defined as the shell, which serves as the user interface to the kernel. Users communicate to the UNIX kernel by issuing commands through the shell. Common UNIX shells include C and Bourne. The shell typically is executed at log-in time. The third component consists of utilities that reside on disk and are called into main memory only when requested. Examples of UNIX utilities include sendmail andrestore, which send mail and restore backup files respectively. Log-In Procedures From a security perspective, the log-in procedures provide entry to the UNIX system. When a user logs in to the system, a UNIX program called init automatically starts the getty program. The getty program, which is executed on each user terminal, determines the terminal speed and displays the log-in message at the terminal. After thegetty program has been executed, the system waits for the entry of the user's log-in ID. The getty program is then replaced by the loginprogram. Before being replaced, getty transmits the characters entered by the user (i.e., the log-in ID) tologin. When login begins executing, it prompts the user to enter a password. After the password has been entered, login checks the password file (/etc/passwd) and verifies that the password entered is the correct one for that user ID. (The /etc/passwdfile also contains information that defines the user's operating environment.) Start-up files are then executed, as described in the next section. Start-Up Files When a user logs in to the UNIX system, several start-up files are executed. These start-up files are used to determine the system and operating environment for that particular user. They may define a user's terminal and home directory. Depending on the version of UNIX and the type of shell used, several start-up files can be executed. Exhibit 1 lists the most common shells and associated start-up files. Common UNIX Start-Up Files File Name Description Previous screen _________ _____________ .cshrc Defines such items as paths and directories that are searched when programs are executed. This start-up file is executed each time a shell or subprocess is created. It is used in UNIX systems written in the C language. .login Executes specific files that define a user's environment (e.g. a user's terminal characteristics). This command file is executed only after the .cshrc file has been executed. /etc/prof Contains commands that are executed at log-in time for each user (e.g., user-defined menus and default file security). This sys- temwide command fiel is used with UNIX systems that have a Bourne shell. It enables administrators to define security for users (e.g., file protection defaults). .profile Contains commands that further define a user's environment and can start user applications. This start-up file is located in the user's home directory and is executed each time a user logs in. /rsh Limits a user's capabilities by disallowing the ability to change directories, change the PATH variable, using a command containing a slash, or redirect output. A user's default start-up shell is specified into the/etc/passwd file, which will be discussed in greater detail later in this article. In most UNIX systems, start-up files and their associated shells are as follows: · C shell (csh) · —.cscrc · —.login · —.logout · Bourne (sh) and Korn (ksh) shell · —.profile A different set of start-up files will be executed depending upon the user's default shell. If no shell is defined for the user, in most UNIX systems the Bourne shell will be executed. Exhibit 2 illustrates the UNIX log-in process. UNIX Log-in Process There are two schools of thought on the use of the restricted(.rsh) shell. The group that advocates its use claims that the restricted shell offers an excellent security feature as long as the following precautions are taken: · All users are placed in a menu with appropriate traps so users cannot exit or escape into the UNIX environment. · The restricted environment requires a password at log-in. Previous screen · Users are restricted from access to commands that let them escape to the shell (e.g., the use of the mail utilities or vi editor). The biggest drawback to use of the .rsh shell is the ability of users to break out of the shell and access a UNIX prompt. The second group believes that the restricted shell should not be used because of the limitations it places on the user environment. This group suggests alternative procedures that can be set up by the security or systems administrator to perform the same functions as.rsh. These procedures include: · Using secure C programs to limit the user's ability to perform certain functions. · Using restricted menus. · Refusing to give the user access to the shell. The user's menu should be called directly from the log-in routine instead of the shell. The statement calling the menu can be added to the /etc/passwd file. · Placing users in their own subsystem. For security to be effective, it is important to restrict the user's ability to update the start-up files, because they control the user's operating environment. Only the systems administrator should have the ability to change or update these files. (The permissions that control user access to files and directories are discussed later.) Another option that has been used successfully by many companies is to specify an executable program that will be executed instead of a user's shell (i.e., C, Bourne, or K shell) at start-up. This program is typically written in the C language and presents a menulike structure to the user. A user selects an item from the menu, and that item executes an associated program. The advantage of this method is that a user is kept captive to a particular menu. The Root Account Most UNIX systems have an ID called the root account or root ID, which is used by the system administrator. It is designated with a group ID of 0. The root account has access to all system files and utilities and the ability to change system operating characteristics.
Load more

Recommended publications
  • Secure Telnet
    The following paper was originally published in the Proceedings of the Fifth USENIX UNIX Security Symposium Salt Lake City, Utah, June 1995. STEL: Secure TELnet David Vincenzetti, Stefano Taino, and Fabio Bolognesi Computer Emergency Resource Team Italy Department of Computer Science University of Milan, Italy For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org STEL Secure TELnet David Vincenzetti Stefano Taino Fabio Bolognesi fvince k taino k b ologdsiunimiit CERTIT Computer Emergency Response Team ITaly Department of Computer Science University of Milan ITALY June Abstract Eavesdropping is b ecoming rampant on the Internet We as CERTIT have recorded a great numb er of sning attacks in the Italian community In fact sning is the most p opular hackers attack technique all over the Internet This pap er presents a secure telnet implementation whichhas b een designed by the Italian CERT to makeeavesdropping ineective to remote terminal sessions It is not to b e considered as a denitive solution but rather as a bandaid solution to deal with one of the most serious security threats of the moment Intro duction STEL stands for Secure TELnet We started developing STEL at the University of Milan when we realized that eavesdropping was a very serious problem and we did not like the freeware solutions that were available at that time It was ab out three years ago Still as far as we know e tapping problem and there are no really satisfying
    [Show full text]
  • Unix Security
    Unix Security Vulnerability Assessment Course All materials are licensed under a Creative Commons “Share Alike” license. ■ http://creativecommons.org/licenses/by-sa/3.0/ 2 Agenda ■ Why assess ■ Where are we in the process ■ What’s needed ■ Defining vulnerabilities ■ NIST 800-53A controls ■ Assessment Exercise ■ Security Exercise ■ Conclusion 3 Vulnerability Assessment ■ Provides the opportunity to address weaknesses before an enemy can exploit them ■ Implementation: Scanning tools that identify vulnerabilities in computer hardware, software, networks and operating systems ■ Common techniques – Multiple tools – one tool may not identify all vulnerabilities – Ability to identify backdoors security perimeter, e.g. modems, VPNs, etc. – all potential vulnerabilities need to be assessed – Correction verification mechanism – ability to check if vulnerability has been eliminated ■ Compliance with OMB, DOD, DHS policy – Utilize NIST 800-53 and 800-53A – DOD 8500 series 4 What’s Needed ■ Unix experience – Hands on experience: configuration, managing, building various Unix systems – Working knowledge of best practices ■ Security Experience – Intimate knowledge of how to secure a system – Prior experience with CIS Benchmark, DISA STIG/SRR ■ Data Collection – Network scans from NMAP and Nessus – Host output from any data collection tools ■ Other Skills – Need to work with administrators – Put vulnerability in their language – Be tedious while looking for vulnerabilities – Work well in a team 5 Defining Unix Vulnerability Assessment ■ Defining Unix Vulnerability Assessment – Unix Vulnerability Assessment – Unix Security Issues – Security Paradigm – System Hardening: The CIS Philosophy – Network Based Vulnerability Scanning – Host (Local) Vulnerability Scanning – Remote vs. Local Vulnerability Scanning – Common Problems and Issues – Mitigation 6 Unix Vulnerability Assessment ■ Definition – Examining the operating characteristics of a Unix environment remotely and locally in order to accurately assess its security posture (or profile).
    [Show full text]
  • Computer Network Security Protocols: a Review
    International Journal of Enhanced Research in Management & Computer Applications ISSN: 2319-7471, Vol. 5 Issue 1, January-2016 Computer Network Security Protocols: A Review Anil Kumar Programmer-Cum-Networking Engineer, Haryana Roadways, Transport Department, Govt of Haryana, India. ABSTRACT Network security is a complicated subject, historically only tackled by well-trained and experienced experts. However, as more and more people become ``wired'', an increasing number of people need to understand the basics of security in a networked world. This document was written with the basic computer user and information systems manager in mind, explaining the concepts needed to read through the hype in the marketplace and understand risks and how to deal with them. Keywords: Protocol, Security, Secure Socket Layer (SSL) and Transport Layer Security (TLS) Protocols; secure IP (IPSec); Secure HTTP (S-HTTP), secure E-mail (PGP and S/MIME), DNDSEC, SSH. 1. INTRODUCTION The rapid growth of the Internet as bothan individual and business communication channel has created a growing demand forsecurity and privacy in this electronic communication channel. Security and privacy are essential if individual communication is to continue ande-commerce is to thrivein cyberspace. The call for and desire for security and privacy has led to several security protocols and standards. Among these are: Secure Socket Layer (SSL) and Transport Layer Security (TLS) Protocols; secure IP (IPSec); Secure HTTP (S-HTTP), secure E-mail ( PGP and S/MIME), DNDSEC, SSH, and others. In this paper I discuss these protocols and standards within the framework of the network protocol stack as follow: Application Layer Transport Layer Network Layer Data Link Layer: PGP, SSL IPSec PPP S/MIME TLS VPN RADIUS S-HTTP TACACS+ HTTPS SET KERBEROS 2.
    [Show full text]
  • Filesystem Hierarchy Standard
    Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Filesystem Hierarchy Standard LSB Workgroup, The Linux Foundation Version 3.0 Publication date March 19, 2015 Copyright © 2015 The Linux Foundation Copyright © 1994-2004 Daniel Quinlan Copyright © 2001-2004 Paul 'Rusty' Russell Copyright © 2003-2004 Christopher Yeoh Abstract This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems. All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder. Dedication This release is dedicated to the memory of Christopher Yeoh, a long-time friend and colleague, and one of the original editors of the FHS.
    [Show full text]
  • Unix Security Overview: 1
    CIS/CSE 643: Computer Security (Syracuse University) Unix Security Overview: 1 Unix Security Overview 1 User and Group • Users – root: super user (uid = 0) – daemon: handle networks. – nobody: owns no files, used as a default user for unprivileged operations. ∗ Web browser can run with this mode. – User needs to log in with a password. The encrypted password is stored in /etc/shadow. – User information is stored in /etc/passwd, the place that was used to store passwords (not anymore). The following is an example of an entry in this file. john:x:30000:40000:John Doe:/home/john:/usr/local/bin/tcsh • Groups – Sometimes, it is more convenient if we can assign permissions to a group of users, i.e. we would like to assign permission based on groups. – A user has a primary group (listed in /etc/passwd), and this is the one associated to the files the user created. – Any user can be a member of multiple groups. – Group member information is stored in /etc/group % groups uid (display the groups that uid belongs to) – For systems that use NIS (Network Information Service), originally called Yellow Page (YP), we can get the group information using the command ypcat. % ypcat group (can display all the groups and their members) 2 File Permissions • File Permissions – The meaning of the permission bits in Unix. ∗ Owner (u), Group (g), and Others (o). ∗ Readable (r), Writable (w), and Executable (x). ∗ Example: -rwxrwxrwx (777) • Permissions on Directories: – r: the directory can be listed. – w: can create/delete a file or a directory within the directory.
    [Show full text]
  • Chapter 3 Unix Overview
    Chapter 3 Unix Overview Figure 3.1 Unix file system Directory Purpose / The root directory /bin or /sbin Critical executables needed to boot the system /dev Device drivers /etc System configuration files such as passwords, network addresses and names,system startup scripts /home User home directories /lib Shared libraries used by programs /mnt Temporary mount point for file systems /proc Images of currently executing processes on the system /tmp Temporary files /usr A variety of critical system files, including system utilities (/usr/bin), and administration executables (/usr/sbin) /var Stores varying files such as /var/log, /var/mail Table 3.1 Important Directories in the Unix file system Figure 3.2 Unix Architecture Figure 3.3 Relationship between init, inetd, and various network services Sample /etc/inetd.conf file containing services spawned by inetd /etc/inetd.conf file format • Service name (port # defined in /etc/services) • Socket type (stream or dgram) • Protocol (tcp, udp, rpc/tcp, or rpc/udp) • Wait status (wait or nowait) • Username (service run as) • Server program • Server program arguments Use of inetd.conf to create backdoor listeners and attack relays Common Unix Administration Tasks ♦ Vulnerability of using “.” in your search path $PATH ♦ Showing all running processes ps –aux ps –aef ♦ Killing/restarting processes kill –HUP pid killall –HUP inetd ♦ /etc/passwd file ♦ Unix permissions rwxrwxrwx chmod command Common Unix Administration Tasks (cont.) ♦ SetUID programs – Executes with permissions of its owner, not of its
    [Show full text]
  • The Complete Freebsd
    The Complete FreeBSD® If you find errors in this book, please report them to Greg Lehey <grog@Free- BSD.org> for inclusion in the errata list. The Complete FreeBSD® Fourth Edition Tenth anniversary version, 24 February 2006 Greg Lehey The Complete FreeBSD® by Greg Lehey <[email protected]> Copyright © 1996, 1997, 1999, 2002, 2003, 2006 by Greg Lehey. This book is licensed under the Creative Commons “Attribution-NonCommercial-ShareAlike 2.5” license. The full text is located at http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode. You are free: • to copy, distribute, display, and perform the work • to make derivative works under the following conditions: • Attribution. You must attribute the work in the manner specified by the author or licensor. • Noncommercial. You may not use this work for commercial purposes. This clause is modified from the original by the provision: You may use this book for commercial purposes if you pay me the sum of USD 20 per copy printed (whether sold or not). You must also agree to allow inspection of printing records and other material necessary to confirm the royalty sums. The purpose of this clause is to make it attractive to negotiate sensible royalties before printing. • Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. • For any reuse or distribution, you must make clear to others the license terms of this work. • Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.
    [Show full text]
  • Utmp, Wtmp, Sulog
    utmp, wtmp, sulog lastlog File UNIX records the last time that each user logged into the system in the lastlog log file. This time is displayed each time that you log in: e.g. login: grossman password: Last login Mon Feb 14 09:19 on console Unfortunately, the design of the lastlog mechanism is such that the previous contents of the file are overwritten at each login. As a result, if a user is inattentive for even a moment or if the login message clears the screen, the user may not notice a suspicious time. Furthermore, even if a suspicious time is noted, it is no longer available for the system administrator to examine. utmp, wtmp, utmpx, and wtmpx Files UNIX keeps track of who is currently logged into the system with a special file called utmp, or utmpx on Solaris systems. This is a binary file that contains a record for every active session and generally does not grow to be more than a few kilobytes in length. A second file, wtmpx, keeps a record of both logins and logouts. This file grows every time a user logs in or logs out and can grow to be many megabytes in length unless it is pruned. utmpx and wtmpx are found in /var/adm on our Solaris systems. utmp and wtmp do not exist in Solaris. The extended wtmpx file used by the Solaris operating system includes the following: Username, 32 characters instead of 8 inittab ID, indicates the type of connection Terminal name, 32 characters instead of 8 Device name Process ID of the login shell Code that denotes the type of entry Exit status of the process Time that the entry was made Session ID Unused bytes for future expansion Remote hostname for logins that originate over a network Examining the utmpx and wtmpx Files UNIX programs that report the users that are currently logged into the system, e.g.
    [Show full text]
  • Cisco Identity Services Engine CLI Reference Guide, Release 2.2 Americas Headquarters Cisco Systems, Inc
    Cisco Identity Services Engine CLI Reference Guide, Release 2.2 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1
    SUSE Linux Enterprise Server 15 SP1 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to eciently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xiii
    [Show full text]
  • Linux Server Security, 2Nd Edition Expertly Conveys to Administrators
    Linux Server Security, 2nd Edition By Michael D. Bauer Publisher: O'Reilly Pub Date: January 2005 ISBN: 0-596-00670-5 Pages: 542 Table of • Contents • Index • Reviews • Examples Linux Server Security, 2nd Edition expertly conveys to administrators and Reader developers the tricks of the trade that can help them avoid serious • Reviews security breaches. It covers both background theory and practical step-by- • Errata step instructions for protecting a server that runs Linux. Packed with • Academic examples, this must-have book lets the good guys stay one step ahead of potential adversaries. Linux Server Security, 2nd Edition By Michael D. Bauer Publisher: O'Reilly Pub Date: January 2005 ISBN: 0-596-00670-5 Pages: 542 Table of • Contents • Index • Reviews • Examples Reader • Reviews • Errata • Academic Copyright dedication Dedication Preface What This Book Is About The Paranoid Penguin Connection The Second Edition Audience What This Book Doesn't Cover Assumptions This Book Makes Organization of This Book Conventions Used in This Book Safari® Enabled How to Contact Us Using Code Examples Acknowledgments Chapter 1. Threat Modeling and Risk Management Section 1.1. Components of Risk Section 1.2. Simple Risk Analysis: ALEs Section 1.3. An Alternative: Attack Trees Section 1.4. Defenses Section 1.5. Conclusion Section 1.6. Resources Chapter 2. Designing Perimeter Networks Section 2.1. Some Terminology Section 2.2. Types of Firewall and DMZ Architectures Section 2.3. Deciding What Should Reside on the DMZ Section 2.4. Allocating Resources in the DMZ Section 2.5. The Firewall Chapter 3. Hardening Linux and Using iptables Section 3.1.
    [Show full text]
  • Logging Policies
    Logging Policies The accounting system, the kernel, and various utilities all emit data that is logged and eventually ends up on your finite-sized disks. Most of that data has a limited useful lifetime and needs to be summarized, compressed, archived, and eventually thrown away. Logging Policies Logging policies vary from site to site. Common schemes include: Throw away all data immediately Reset log files at periodic intervals Rotate log files, keeping data for a fixed period of time Compress and archive logs to tape or other permanent media. The correct choice for your site depends on how much disk space you have and how security conscious you are. Even sites with an abundance of disk space must deal with the cancerous growth of log files. Whatever scheme that you select, maintenance of log files should be automated with cron. Throwing away log files We do not recommend throwing away all logging information. Sites that are subject to security problems routinely find that accounting data and log files provide important evidence of break-ins. Log files are also helpful for alerting you to hardware and software problems. In general, given a comfortable amount of disk space, data should be kept for at least a month and then discarded. In the real world, it may take this long for you to realize that your site has been compromised by a hacker and that you need to review the logs. If you need to go back further into the past, you can recover older logs from your backup tapes. Some administrators allow log files to grow until they become bothersome, then restart them from zero.
    [Show full text]