Security News Chronicle

Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

Security News Chronicle

New Security Planning Guide: Administrator Accounts The Administrator Accounts Security Planning Guide will help you address the problem of intruders who acquire administrator account credentials and then use them to compromise the network. Learn about the steps you can take to help secure your local and domain-based administrator-level accounts and groups.

Increase Your Security Business with the Help of the New Assessment Tool Refer your customers to the new Microsoft Security Assessment Tool (MSAT). The MSAT evaluates resources, processes, and technology for small to medium-sized organizations, providing budget-conscious IT managers with an overview of security gaps and a roadmap to risk mitigation.

Kurt's Closet - Archives

SecurityPortal - Best Practices for Secure Web Development

October 30, 2000 - Surprise, surprise. Until the past year or so, security and business did not often come together in the same paragraph.

Well, it shouldn't be a surprise because ultimately, security is not about technology but about managing risk. Security is present in Internet projects precisely because it's needed to mitigate some risks. Any business has some assets to protect, and in the Internet world, it's the information assets we are concerned with. Examples of assets are: integrity of the site content, site availability, data privacy, trust. As you can see, not all assets are physical

Securing your network An introduction to TCP wrappers

[Sept 17, 2000] Linux Today - AppWatch BIND 9.0.0 released

"BIND version 9 is a major rewrite of nearly all aspects of the underlying BIND architecture. Some of the important features of BIND 9 are:

DNS Security: DNSSEC (signed zones), TSIG (signed DNS requests)
IP version 6: Answers DNS queries on IPv6 sockets, IPv6 resource records (A6, DNAME, etc.), Bitstring Labels, Experimental IPv6 Resolver Library
DNS Protocol Enhancements: IXFR, DDNS, Notify, EDNS0, Improved standards conformance
Views: One server process can provide multiple "views" of the DNS namespace, e.g. an "inside" view to certain clients, and an "outside" view to others;
Multiprocessor Support
Improved Portability Architecture"

You can check the relevant links here. There is also a history of changes (since the last beta and during the full beta period).

Linux Today - Security Portal Hardening the BIND DNS Server

October 02, 2000 - This paper presents the risks posed by an insecure DNS server and walks through compiling, installing, configuring and optionally, chroot'ing BIND 8. The test environment is Solaris 2.5, 2.6, 7 and 8. Many configuration and troubleshooting tips are provided, along with up-to-date references on BIND and alternatives for NT, Linux and Solaris.

Introduction: Why bother? What risks does an insecure BIND pose?
Install and Configure BIND: compile, install, create DNS data, start BIND.
Chroot'ing BIND: Create chroot jail, copy BIND to jail, start BIND.
Troubleshooting
Configuration Notes
Footnotes
References

jrh - Subject: Just don't use BIND! ( Oct 2, 2000, 09:04:06 )

BIND is the sendmail of DNS....great software written in a totally different time of the internet. A big piece of monolithic stuff that needs to be completely redone.

Take a look at djbdns (http://cr.yp.to/djbdns.html). Modular. Written with security in the forefront of the author's consideration.

linux.ie: How DNS works(Jan 23, 2000)
sendmail.net: Why You Should Upgrade to BIND 8.2.2(Jan 09, 2000)
InfoWorld: Working with your Domain Name System will run more smoothly without 'lame' servers(Dec 19, 1999)
UNIX & LINUX Computing Journal: Overview of DNS(Dec 12, 1999)
Security Portal: Securing your name servers(Nov 24, 1999)
Linux.com: A Guide to Named(Nov 14, 1999)
sendmail.net: Vixie Wraps BIND(Nov 13, 1999)
LinuxForum: A Simple Home DNS Configuration(Oct 10, 1999)
Security Portal: DNS Security - closing the b(l)inds(Sep 29, 1999)
32BitsOnline: Book Review: "DNS and BIND" from O'Reilly(Sep 15, 1999)
Network Computing: Developments in DNS: Investigating Bind 8(Nov 28, 1998)

SECURITY: SuSE.de: Installation of a Secure Web Server

(Oct 22, 2000, 12:18 UTC) (153 reads) (0 talkbacks) (Posted by marty)
"Apart from firewalls, which aim at protecting internal networks against attacks from the internet, web servers are the second important field requiring a high degree of security. This article shows how this can be done on a Linux system within just 45 minutes."

SECURITY: Net-Security.org: Bastille Linux v.1.1.1 released -- Red Hat only

(Oct 21, 2000, 19:11 UTC) (86 reads) (0 talkbacks) (Posted by john)

SECURITY: Security Portal: Format Strings - An Interview with Chris Evans

(Oct 11, 2000, 08:37 UTC) (1577 reads) (1 talkbacks) (Posted by marty)
"It appears to me that these format strings have been present a very long time. A CERT advisory mentioned them being in WuFTPD since 1993. Do you think attackers have known about them and been using them?"

USENIX ;login - a glimpse into the future of id

USENIX ;login - hackers

This article is a response to Rik Farrow's question about the L0pht's work on intrusion-detection packages for Network Flight Recorder. In particular he asked how we chose which packets to look at. So I shall attempt to give a brief overview of how a group of hackers — and I use the term in the good sense — goes about approaching network intrusion detection, given the current state of tools and environments.
A little background first — but don't worry, I'll try to make it as painless as possible. For those not familiar with the L0pht, I recommend checking out the Web site, <http://www.L0pht.com>. (Note: that is L-Zero-p-h-t.) What we are, in a nutshell, resembles a marriage between Consumer Reports and public television . . . gone high-tech-security happy. One of the many products/tools/technologies that we played with happened to be Network Flight Recorder's tool of the same name. NFR (<http://www.nfr.net>) was designed to be a black-box recorder of packets going across a network. If you imagine an RMON probe on steroids you have NFR. Learning what types of traffic, who the heavy talkers on the net are, where different servers are located, and logging invalid packets and whether they come in the form of invalid checksums are all functions that NFR was designed to be capable of. Some astute readers might notice that nowhere have I mentioned that NFR was designed explicitly to be an intrusion-detection system — simply a versatile sniffer with an extensible programming language, called "N-Code," for handling packets. I had downloaded a copy from NFR's Web site and, along with fellow L0pht member Silicosis, whipped up a few simple N-Code modules that would handle some trivial intrusion scenarios and posted them on our Web site for everyone to access free of charge. NFR's president and CEO, Marcus Ranum, saw them and approached us to write a more complete set of filters (we are currently at over 200 checks and less than a third done) under contract for NFR. Since we had toyed around with the notion of writing them for free we jumped at the opportunity to put some food on the table. Gee, I hope Marcus does not read this magazine. Hi Marcus — d'oh!

The Standard.com The World's Most Secure Operating System

De Raadt began experimenting with BSD code during his student days at the University of Calgary. Along with several friends, he created an open-source project called NetBSD in 1993; his friends booted him from the project the following year. In archived e-mail, his former colleagues claim he was guilty of "rudeness toward and abuse of users and developers." De Raadt denies those allegations.
De Raadt used NetBSD's code as the foundation for the OpenBSD project, which he formed in 1995. After his machine was hacked by a colleague in 1996, he adopted a security tactic that has become the project's trademark: "proactive auditing."
Over an 18-month period, a team of 10 volunteers vetted OpenBSD's entire source code – all 350 megabytes – weeding out thousands of bugs. Though not necessarily related to security features, those glitches could have been targeted by attackers using "buffer overflows" (which overwhelm a machine with data packets), denial-of-service tools or other elementary hacking techniques. For two years, de Raadt worked 14-hour days, seven days a week to debug his system. Despite his notoriously prickly personality, de Raadt also has managed to attract a legion of collaborators to help him build OpenBSD.
"It's security through quality," says de Raadt, who runs the project out of his Calgary home, surviving on donations and proceeds from T-shirt sales. "It's like in airplanes, [where] safety is a side effect of good engineering."
A sincere passion for technological tinkering motivates de Raadt. Though he lives modestly, his house is bursting with wall-to-wall hardware. He owns over a dozen computers, and his basement is so jammed with Unix machines that several acquaintances have requested guided tours.
OpenBSD's proactive approach is unique among open-source systems, which normally rely on user reports and public forums to find vulnerabilities. The Linux security philosophy, for example, can be summed up as "more eyes means better security" – that is, since the source code is open to peer review, bugs will be quickly spotted and patched.
De Raadt scoffs at that credo. Most reviewers of open-source code, he says, are amateurs. "These open-source eyes that people are talking about, who are they?" he asks. "Most of them, if you asked them to send you some code they had written, the most they could do is 300 lines long. They're not programmers."
Proactive auditing is the key to OpenBSD's vaunted security. Many security professionals would like to see the model duplicated elsewhere, especially in Linux offshoots struggling to seize market share from notoriously buggy Microsoft products.
"I'm surprised there's not a version of Linux out there that has grown supersecure," says Ron Gula, chief technology officer for Network Security Wizard, a developer of intrusion detection systems who says that Linux developers could augment its security using de Raadt's painstaking methods.
OpenBSD is designed to be "secure by default." Most comparable operating systems, by contrast, come out of the box with settings that are inherently insecure. Last year, for example, when hundreds of servers running Red Hat Linux were compromised by buffer overflow attacks, the company blamed system administrators for failing to reconfigure the defaults.
"Linux distributions tend to take the approach of throwing everything possible onto the default install, which leads to a clueless user ending up with a highly insecure operating system," says Matt Barringer of WireX Communications, a vendor of software solutions for Linux server appliances. "OpenBSD takes the opposite approach, by only including the essential and not allowing, by default, services that may not be essential – FTP, for instance."
The secure-by-default policy is also a stress reliever for veteran administrators. "The 10 percent [of these users] who do know how to secure their machines, they get bored with it," says de Raadt. "It's no more exciting than ditch digging. OpenBSD means they can get along with their day-to-day jobs."
Unlike its American counterparts, which until July were bound by strict encryption-export laws, the Canadian-based OpenBSD ships with built-in encryption. (In a subtle display of Maple Leaf pride, labels on OpenBSD discs read: "Made in Canada – Land of Free Cryptography.") The latest version includes OpenSSH, which enables traffic to avoid "sniffers" designed to detect users' passwords.
While it's ideal for security-sensitive tasks, such as running firewalls or data warehousing applications, OpenBSD is probably not the best option for desktops. "Linux is more flexible than OpenBSD, which is a direct result of OpenBSD being more focused on security," says Brenton. "As you lock things down, you lose functionality."
De Raadt sounds unconcerned about customer satisfaction. "I don't pay attention to who's using it," he says. "We don't write OpenBSD for the people, we write it for ourselves. If people end up getting benefits from it, that's great."
Nevertheless, the system is catching on in corporate America. The project doesn't track the number of free downloads or CD-ROMs purchased, but a rough estimate places the number of users in the tens of thousands. Potential investors regularly contact de Raadt with offers of financial backing, he notes, but he has rebuffed them all: "I talked to a venture capitalist a couple of weeks ago. I ended up convincing him to just give us a donation."
De Raadt has devoted himself to OpenBSD with a mathematician's love of constructing elegant systems. He fears that commercialization could compromise security, since bottom-line-obsessed executives would be tempted to skimp on time-consuming audits. Even worse, those image-conscious suits might force de Raadt to abandon his fearsome business-card mascot in favor of something more huggable. For now, the demonic policeman is safe.

Why LD_LIBRARY_PATH is bad

This is one system administrator's point of view why LD_LIBRARY_PATH, as frequently used, is bad. This is written from a SunOS 4.x/5.x (and to some extent Linux) point of view, but this also applies to most other UNIXes.
LD_LIBRARY_PATH is an environment variable you set to give the run-time shared library loader (ld.so) an extra set of directories to look for when searching for shared libraries. Multiple directories can be listed, separated with a colon (:). This list is prepended to the existing list of compiled-in loader paths for a given executable, and any system default loader paths.
For security reasons, LD_LIBRARY_PATH is ignored at runtime for executables that have their setuid or setgid bit set.

SECURITY: LinuxSecurity.com: Complete Reference Guide to Creating a Remote Log Server

(Aug 23, 2000, 22:06 UTC) (15 reads) (0 talkbacks) (Posted by marty)
"A remote log server is nothing more then a system preconfigured at install-time to provide hard drive space for other systems to log to. This system must be completely secured and locked down."

Techweb: How Secure Are You?

(Aug 23, 2000, 21:23 UTC) (223 reads) (0 talkbacks) (Posted by marty)
"For example, the Common Gateway Interfaces in Web server software can supply hackers with root access to the server. Every copy of the Apache open-source Web server--nearly two-thirds of installed Web servers--comes with these vulnerabilities."

Monitoring Connections To Your System By: Vincent Hillier a short note about installation of IP Protocols Logger (http://pltplp.net/ippl/archive/)

Read them the riot act

Longtime Unix users know that many versions of Unix allow system administrators to present a pre-login message to users. The files used are /etc/login and /etc/login.net. The programs that handle logins print out these files. For logins via the console or serial lines, /etc/issue is used, while /etc/issue.net is used on some Unix systems for network logins.
Many distributions of Linux, such as Red Hat 6.2, Mandrake 7.1, and TurboLinux all provide and use those files, and they all work in similar ways. This is not surprising, as Mandrake and TurboLinux are derived from Red Hat. SuSE also provides and uses those files, but in slightly different ways.
To ensure that all users who log in via a console or the network see a message like AUTHORIZED USE ONLY, perform the following steps:
(echo AUTHORIZED USE ONLY ; cat /etc/issue) > \ /tmp/issue mv -f /tmp/issue /etc/issue
You could perform the same steps for /etc/issue.net as well.
All users who log in via the console, serial devices, or the network will now receive your warning that only authorized use of the system is allowed, as shown below in Example 1.
Example 1.
AUTHORIZED USE ONLY   Welcome to mand.nscomputer.com.au   Linux Mandrake release 7.1 (helium)   Kernel 2.2.15-4mdksmp on an i686   login:
If you have used Mandrake, you will realize that Example 1 is missing the Tux that usually appears with output on consoles. I captured a network login; you will see similar things on a virtual console login, except the message AUTHORIZED USE ONLY will appear above Tux.
Of course, your message can be much more elaborate than the one I used above; you can even have it drafted by lawyers.
On your next reboot, your changes are likely to vanish, because at boot time, Red Hat, Mandrake, and TurboLinux all reinitialize the files you changed to create a login message. They all do it differently, although Mandrake and TurboLinux's ways are similar. All three distributions use /etc/rc.d/rc.local to rewrite the files. Since /etc/rc.d/rc.local is a link from S99local in run levels 2, 3, 4, and 5, the rewrite is the last thing done when Linux boots.
Example 2 shows the relevant fragment of code from rc.local under Red Hat 6.2.
Example 2.
  if [ -f /etc/redhat-release ]; then       R=$(cat /etc/redhat-release)       arch=$(uname -m)       a="a"       case "_$arch" in               _a*) a="an";;               _i*) a="an";;       esac       NUMPROC=`egrep -c "^cpu[0-9]+" /proc/stat`       if [ "$NUMPROC" -gt "1" ]; then           SMP="$NUMPROC-processor "           if [ "$NUMPROC" = "8" -o "$NUMPROC" = "11" ]; then               a="an"           else               a="a"           fi       fi       # This will overwrite /etc/issue at every boot. So, make any changes you       # want to make to /etc/issue here or you will lose them when you reboot.       echo "" > /etc/issue       echo "$R" >> /etc/issue       echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue       cp -f /etc/issue /etc/issue.net       echo >> /etc/issue   fi
As you can see, the code above writes the contents of /etc/redhat-release to /etc/issue, then writes the current kernel version and other information to the same file. Lastly, it copies /etc/issue to /etc/issue.net. Thus, under Red Hat 6.2 and below, you must significantly modify /etc/rc.local so it has different messages for local and network logins.
Mandrake and TurboLinux, on the other hand, provide for separate messages on local and network logins by initializing the /etc/issue and /etc/issue.net files separately. The code fragment in Example 3 does this from /etc/rc.local on Mandrake 7.1.
Example 3.
  if [ -f /etc/mandrake-release ]; then       R=$(cat /etc/mandrake-release)       arch=$(uname -m)       a="a"       case "_$arch" in           _a*) a="an";;           _i*) a="an";;       esac       NUMPROC=`egrep -c "^cpu[0-9]+" /proc/stat`       if [ "$NUMPROC" -gt "1" ]; then           SMP="$NUMPROC-processor "       [ "$NUMPROC" = "2" ] && \       SMP="Bi-processor "           if [ "$NUMPROC" = "8" -o "$NUMPROC" = "11" ]; then               a="an"       else           a="a"           fi       fi       # This will overwrite /etc/issue at every boot. So, make any changes you       # want to make to /etc/issue here or you will lose them when you reboot.       if [ -x /usr/bin/linux_logo ];then       /usr/bin/linux_logo -c -n -f > /etc/issue       echo "" >> /etc/issue       else       > /etc/issue       fi       echo "$R" >> /etc/issue       echo "Kernel $(uname -r) on $a $SMP$(uname -m) / \l" >> /etc/issue       if [ "$SECURITY" -le 3 ];then       echo "Welcome to %h" > /etc/issue.net       echo "$R" >> /etc/issue.net       echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue.net       else       echo "Welcome to Linux-Mandrake" > /etc/issue.net       echo "-------------------------" >> /etc/issue.net       fi   fi
As you can see, Mandrake places its logo in /etc/issue, but not /etc/issue.net. Also, Mandrake writes different messages to /etc/issue.net depending on your security level.
There are two ways to introduce your own messages into /etc/issue and /etc/issue.net.
One is to modify /etc/rc.d/rc.local to include your message in /etc/issue and /etc/issue.net. If you are using Red Hat, you will also need to remove the copy of /etc/issue to /etc/issue.net if you want different messages for local and network logins.
The main advantage of this approach is that you retain accurate reporting of the kernel version and other information across kernel upgrades.
However, some consider it a security risk to provide information to potential attackers about what kernel version you are running. (I think you should only allow network logins from outside your organization using a secure shell. In addition, if people can log in to a user account, they can quickly find out what version of Linux you are running.)
The other way to introduce your own messages is to modify your /etc/rc.d/rc.local to skip updating /etc/issue and /etc/issue.net. You can then set up those files manually.
This method is advantageous because you can simply edit the files /etc/issue and /etc/issue.net with an editor at any time. However, you lose other useful information from them.
I modified /etc/rc.d/rc.local under Mandrake 7.1 to include my own system message, shown in Example 4. Now, when people log in via the network, they see the message shown in Example 5.
Example 4.
if [ "$SECURITY" -le 3 ];then     echo "Welcome to %h" > /etc/issue.net     echo "$R" >> /etc/issue.net     echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue.net     cat < > /etc/issue.net This system may only be used for authorized purposes. If you do not know what the authorized purposes are, then write to /dev/null. All infractions will be prosecuted to the full extent of the law. EOM     else     echo "Welcome to Linux-Mandrake" > /etc/issue.net     echo "-------------------------" >> /etc/issue.net     fi

Another massive Net attack looming

Top-level White House officials have been meeting with representatives of the insurance and security industries in an attempt to work out an agreement, according to Alan Paller, director of the SANS Institute, a non-profit computer security organisation. Details of the plan are still under discussion, but Paller said it would mirror the strategy the federal government has used with other developing industries, such as electricity.
"It will be a situation where insurance companies will say 'If you meet these minimum standards, we'll give you insurance... then government agencies will say 'You can't connect to our computers unless you have insurance'," Paller said.
More important, Paller said, would be getting major e-commerce Web sites to agree to the standards, and then for them to force their partners to meet the minimum standards.
Representatives from the White House and other federal agencies met with computer security researchers and privacy advocates Thursday evening to hammer out details of the strategy, Paller said.
Tentatively, the group plans to publish its suggestion by the end of this summer, then allow a 90-day review period. The plan is to create a new non-profit or cooperative agency by December that would act as a central repository for security information and minimum standards guidelines.

CheckPW.html

These functions are used to enforce password complexity requirements and are a reasonable alternative to the methods of cracklib(3). Password complexity requirements are configurable to set minimal length, minimal number of unique characters, minimal number of character types (of upper, lower, digit, punctuation and other) and finally minimal difference from well known words (login name, gecos words, and dictionary entries).
The function CheckMyPW(password) will determine if the pass- word supplied satisfies the complexity requirements for the current user. The user's login name and all words in the gecos field of the user's password file entry are used to augment the default dictionary. This is similar to the behaviour of FascistCheck(3) which this can replace.
The function CheckPW(password,words) will determine if the supplied password satisfies the complexity requirements in force. If no complexity requirements have been set then the default configuration in /etc/CheckPW.cf is loaded. The supplied words is a NULL terminated list of words that aug- ments the dictionary (typically this would be the users login name and other words associated with that user). If the password supplied does not meet the requirements an error string is returned which might be suitable for display. If it does meet the requirements then a NULL string is returned.

250 Linux servers infected by denial-of-service program

Some 250 Linux servers were found to have been infected with a hacking program used in denial of service (DOS) attacks, raising serious security concerns with the popular open source code servers.
     The Ministry of Information and Communication (MIC) said yesterday that SECUi.COM, a local communication security firm detected a hacking program used in DOS attacks during a routine check on one of its clients last Tuesday. The company was able to trace the origin to a Linux server in a PC room in Kangnung, Kangwon Province.
     SECUi.COM then reported the incident to the National Police Agency (NPA) and the Korea Information Security Agency (KISA) and the consequent investigation by the NPA discovered that the hacking program had been installed in about 250 servers. Systems operated by 200 companies, 30 colleges and 20 public offices were found to have been infected.
     "At the moment, it appears that the attack was launched through a U.S.-based Internet service provider (ISP), succeeded in attacking the server in Kangnung. That server, in turn, installed the hacking program in 250 other servers," said Koh Kwang-sup, director of information ethics and privacy protection division at the ministry's informatization planning office. Financial institutions and major corporations escaped the attack, Koh added.
     "There have been no reports of damage yet," said Lim Chae-ho, director of technical assistance and consulting team at KISA. Such attacks involve a main agent, the server in Kangnung in this instance, installing hacking programs in a number of other servers which then become agents in the final stage of the attack, launching DOS attack on the intended target.
     The attack, if undetected, could have wrecked great havoc, an even greater one than the Yahoo! DOS attack last February because of the sheer number of servers involved. "In that particular attack, damage data were spread by 60-70 agents, sending data traffic equivalent to that processed during an entire year in a matter of few hours, shutting down the system," Lim said. 250 servers launching attack at the same have a potential to cause greater damage, according to Lim.
     "The final target of the DOS attack, in most likelihood, was a prominent Web site overseas," said Lim.
     The incident involved Linux servers, both the main agent in Kangnung and the 250 agents using Linux systems. "There are 200 or so reported vulnerable spots in the Linux and a program called Scan can detect weak spots in the Linux system that can be used to hack a system," explained Lim, adding that in the latest attack, systems without firewalls, an Internet security measure, fell victims.
     KISA is currently working to remove the hacking programs from the affected systems and the NPA has shut down the servers involved.
     Meanwhile, system operators can take measures to protect themselves against such attacks by downloading a free software called K-COPS (KISA Computer Online Protection Service) from www.kisa.or.kr that can detect the presence of such hacking programs. Other hacking attempts can be detected by using Real Time Scan Detector (RTSD) developed by KISA. (KHR)
Updated: 08/01/2000

*** The Linux Security Quick Reference Guide. This guide is a printable short and superficial PDF document with some security checks and tips including Linux Kernel Security, File Permissions, Intrusions Detection, Linux Security Resources, and more.

Securing and Optimizing Linux: Red Hat Edition

version: 1.3

author(s): Gerhard Mourani, <[email protected]>

last update: June, 2000

available formats:

PDF (4MB)
Example server configuration files (tar file; described in book as "floppy.tgz").

This book addresses unanswered questions about Linux security and optimization in the marketplace. It is intended for a technical audience and discusses how to install a Red Hat Linux Server with all the necessary security and optimization for a high performance Linux-specific machine. It covers (in detail) several ways to configure security and optimization.

Due to a many requests from Linux users, this update includes: a backup section, firewall security approach, Sendmail section, Kernel security and improvement, FTP chrooted configuration and many other changes. This document is indispensable for people that want to get all the advantages, security, and the optimization out of a Linux Server.

Additional changes to this version include- OpenSSH has been added, Sendmail 8.10.1, the book is now compatible with Red Hat Linux 6.2. The firewall rules has been reviewed for easy use, more securities tips added, and how to use the new "sysctl.conf" file of RH 6.2.

More information: http://www.openna.com/books/book.php

SECURITY- Dan & Wietse's Forensics Tools released

Date: Tue, 1 Aug 2000 08:10:45 -0400
From: Wietse Venema [email protected]
To: [email protected]
Subject: Dan & Wietse's Forensics Tools released
It is with great relief that we announce the first official release of the Coroner's Toolkit software, also called TCT.
TCT is a collection of programs that can be used for a post-mortem analysis of a UNIX system after break-in. The software was presented first during a free Computer Forensics Analysis class that we gave one year ago (almost to the day).
Notable TCT components are the grave-robber tool that captures information, the ils and mactime tools that display access patterns of files dead or alive, the unrm and lazarus tools that recover deleted files, and the keyfind tool that recovers cryptographic keys from a running process or from files.
To set your expectations, the TCT software is not for the faint of heart. It is relatively unpolished compared to the software that we usually release. TCT can spend a lot of time collecting data. And although TCT collects lots of data, many analysis tools still need to be written. Nevertheless TCT sure beats the competition, which is non-existent, and beats them at the right price, too.
TCT runs on recent versions of SUN Solaris, FreeBSD, RedHat Linux, BSD/OS, OpenBSD, and even runs on SunOS 4.x. It requires perl 5.004 or later, although perl 5.000 is probably adequate if you are going to do the actual analysis on a different machine.
TCT source code is available from the following places:
http://www.porcupine.org/forensics/
http://www.fish.com/forensics/
ftp://tct.earthlink.net/pub/
Enjoy!
Wietse Venema
Dan Farmer

Root Prompt: Unix Internet Security: Considering Conventional Wisdom

Unix has an undeserved reputation for poor network security. There is no inherent design defect in Unix that has led to this reputation -- unless providing a rich collection of network services is considered a security defect. Close examination of the superior security claims of proprietary system vendors reveals that they rest upon a dearth of networking services and the infamous "security through obscurity" policy available only to products of limited market penetration. No proprietary operating system compares favorably to Unix when the disparate and widespread usage, along with the rich variety of network services, are taken into account. As other operating systems come to compete with Unix in the Internet server space, the difficulty of providing such services with high levels of security will become ever more obvious.

Issue #85 Workstation Security Primer - Focus On Linux - 04-28-00

Linux Magazine April 2000 GURU GUIDANCE Unix Security Holes

SECURITY: Security Portal: Why do vendors ship us junk they wouldn't use?

(Jul 5, 2000, 06:57 UTC) (1625 reads) (0 talkbacks) (Posted by marty)
"Most Linux vendors ship the same general packages - Sendmail for SMTP mail services, WuFTPD for FTP, Telnet for remote access and so on. The kicker, though, is that most of these vendors use different software on their servers."

What's the hat got to do with it

Joe Barr takes off his rose-colored glasses and discovers that deception and darkness are old hat in the world of computer security. Plus: ISS's Christopher Klaus responds to some of the claims put forth in this article.

PRNewswire: SecureCRT Opens Up SSH to Open-Source Servers

(Jul 5, 2000, 19:24 UTC) (570 reads) (0 talkbacks) (Posted by marty)
"Van Dyke Technologies, Inc., a provider of quality Internet software, announced today the official release of SecureCRT 3.1 for Windows. Interoperability with new Secure Shell version 2 (SSH2) servers leads the list of product enhancements."

Linux Today - BW Solsoft Delivers Free Version of Security Management Solution for Linux...

sendmail.net 000705securitygeneral -- Securing Sendmail

Though the virus alerts have vanished from the evening news, Internet security remains a justifiably hot topic. Still, while hype, myth, and hysteria abound, useful information seems to be in short supply. Had enough of generalities? Time for something, um, practical? We think so.
This two-part series on securing sendmail, based on the tutorial given by Eric Allman and Greg Shapiro at the recent USENIX technical conference in San Diego, begins by detailing the measures you can take to secure any sendmail installation. It continues tomorrow with a look at the specific roles sendmail can play - from timesharing systems to firewall installations - and how you can make those systems more secure. So dig in. Read on. And tell us what you think.

What is security?
General security principles
Tuning sendmail for security
Users special to sendmail
General security measures
File and directory modes
Restrictive file access
Controlling the aliases file
smrsh
The SafeFileEnvironment option
More tricks for the truly paranoid

LinuxPR: FREE Linux Firewall Released to Public

(Jul 1, 2000, 00:45 UTC) (2147 reads) (1 talkbacks) (Posted by john)
"Gateway Guardian Personal Edition previously sold for $49 USD."

*** SecurityPortal - Shredding Access in the Name of Security By Jay Beale [email protected] Lead Developer of Bastille Linux hardening Perl scripts. Beware: some recommendation below are pretty unrealistic like "You can generally restrict ping to root only, as only the system administrator should need to test or tweak network connectivity. chmod u-s /bin/ping"[June 28, 2000]

In a SUID Audit, we apply a critical principle of Computer Security: minimalism. We remove all paths to root that aren't absolutely necessary. Here, we research each SUID program on the system and make an educated decision about its level of privilege. We can list all³ the Set-UID programs owned by root using the command⁴:

find / -perm -4000 -uid 0 --print

But once we find them, how do we minimize the danger of exploitation?

Lessening the Risk

There are four basic ways to limit the danger of SUID root programs:

Strip the SUID bit, so the program runs as the running user, instead of running as root.

Define a special group for the program in question and make the program executable by members of the group, but not by everyone else. (chgrp wheel /bin/su ; chmod 4750 /bin/su)

Strip the world(other)-execute bit, leaving it executable by the owner and group, but still SUID (more dangerous).

Strip SUID and use Sudo to allow only certain users to run this command. (This is like #2, but far more manageable.)

We'll primarily use option 1 here, but you should consider each. Let's move on to an actual SUID root audit, on Red Hat 6.2.

Auditing Red Hat 6.2

On Red Hat, with only a few exceptions, all of the SUID root programs are executable by everyone on the system.

/bin/mount - mount is suid-root to allow ordinary users to mount floppy and CD-ROM drives. If your users won't be at console, or won't be using floppies/CD-ROM's, you can deactivate set-uid, like this: chmod u-s /bin/mount

/bin/ping - ping is suid-root to allow users to test network connectivity. You can generally restrict ping to root only, as only the system administrator should need to test or tweak network connectivity. chmod u-s /bin/ping

/bin/su - su is set-uid so that ordinary users can switch to root. You should generally leave the set-uid bit on, here, though you could make this executable only by the wheel group. This is customary on many old Unix systems and the wheel group already exists in /etc/group.

/bin/umount - umount is suid-root to allow users to unmount floppies and CD-ROM's. (See above, under /bin/mount )

/sbin/dump - Dump is a backup tool that should really only be used by the sysadmin. It really should never have had suid status! If it can be used at all by junior people, it could be used to look at files not normally accessible to every user. This is a common problem on Linux/Unix systems, where a vendor was probably trying to be helpful. If you need your junior admins (who don't have root) to be able to run this, consider using sudo instead! For now, chmod u-s /sbin/dump.

./sbin/pwdb_chkpwd - There's no man page for this. It seems like it is probably part of PAM, but since we can't find information on it, we'll have to leave it alone for now. Unfortunately, as Garfinkel and Spafford describe in Practical Unix and Internet Security, there are many OS's where this is a sad fact of the suid-root audit: sometimes, you just don't know what the program does! You might check the source or run a deja.com UseNet archive search. In my case, I'm just leaving this one alone. (First one to e-mail me useful information on this gets a honorable mention in my next article!)

/sbin/restore - Restore is dump's counterpart. (see /sbin/dump, above)

/sbin/unix_chkpwd - Again, there's no man page for this and it looks like part of PAM. ( see /sbin/pwdb_chkpwd, above )

/usr/X11R6/bin/Xwrapper - Xwrapper seems to be the script that runs your particular X Server. Your X Server needs to run set-uid root, so that it can take over your screen...

/usr/bin/at - at is used to schedule a command to run later - unfortunately, at has had a rich history of problems. Fortunately, you really can achieve the same functionality with cron! Turn off set-uid on this - even better, deactivate the atd service: (chmod u-s /usr/bin/at ; chkconfig atd off )

/usr/bin/chage - This program is used to set/read password-aging information. It would never be used by users, except that it can tell a user how much time they have until their password expires. I, being paranoid, would deactivate set-uid on this one, since users get an e-mail when their password gets near expiring. This program is especially useless to users when you're not enforcing password aging.

/usr/bin/chfn - This program is used to change your "finger" information. As it writes to the /etc/passwd file, it needs suid to work for any user other than root. If you don't want your users changing their finger information, have no users or are feeling paranoid/grumpy, chmod u-s /usr/bin/chfn. Don't discount the first reason: some sites use the finger information to keep better track of their users!

/usr/bin/chsh - chsh lets a user change their shell, by rewriting the last column of their /etc/passwd entry. If you lock all your users to one shell, or have no users, or are feeling very paranoid, chmod u-s /usr/bin/chsh.

/usr/bin/crontab - crontab allows a user to schedule (possibly repetitive) jobs for later execution. If you, as many admins, don't want your users touching cron for security-reasons, rip suid away!

/usr/bin/gpasswd - Much like passwd, gpasswd lets your users change the group passwords in /etc/group or /etc/gshadow. If you're like most admins and don't use group passwords, strip suid away.

/usr/bin/{lpq, lpr, lprm} - These are the printing utilities. If you don't print from this machine, turn suid off. Otherwise, you really should leave suid on here!

/usr/bin/passwd - As we saw before, this allows ordinary users to change their password. It needs root privilege to write to the /etc/passwd. Unless you have no users, leave suid on!

/usr/bin/procmail - While procmail is used by users to sort/act on incoming e-mail. On Sendmail-based Linux systems, it is also the local delivery agent and needs to run as root. (Sendmail runs as root, but drops privilege before it calls the delivery agent. ) Unless you receive no mail on this host, please don't turn suid off .

/usr/bin/{rcp,rlogin,rsh} - These require root to bind to a low port (<1024). You really, really, really shouldn't be using these as they are dreadfully insecure and are easily replaced by ssh and scp. Definitely deactivate these! ( chmod 0000 /usr/bin/{rcp,rlogin,rsh} )

/usr/bin/sperl5.00503 - Again, we find a case where a command is poorly documented on the system. Luckily, a google search turned up a CERT listing on sperl, AKA suidperl. suidperl is a security answer to an old problem in some kernels. It seems like a safe bet, but you really should ask your local Perl god.

/usr/libexec_ptchown - This is another program that could use a man page. Some discussion on the Linux Security Audit showed that this was used by terminal programs and the like to grab pty's. You should probably leave this alone.

/usr/sbin/sendmail - sendmail has to be suid root to allow ordinary users to send mail. If you have no users, or don't want them to send mail, turn this off. I highly recommend that you leave this on though, as e-mail is a core Internet technology.

/usr/sbin/traceroute - traceroute uses UDP packets of progressively lower Time-To-Live (TTL) values to find the router path between hosts. As admins should probably be the only one testing network connectivity, it should be fairly safe to deactivate suid. (chmod u-s /usr/sbin/traceroute )

/usr/sbin/userhelper - userhelper allows a user to change their own passwd (like passwd), finger info (like chfn) and shell (like chsh), but it is run through a GUI tool. I suggest killing this off, as it had a recent root vulnerability and it duplicates existing commands. If you can find it on the web, check out userrooter, which can easily give any ordinary user a root shell (in Red Hat 6.0-6.1) by exploiting bad parameter-checking in PAM/userhelper.

/usr/sbin/usernetctl - usernetctl allows ordinary users, if they're permitted by config files, to bring up/down the network interfaces. I honestly believe that root should be the only one affecting network interfaces. While some might argue that ppp links, often restarted, should be touched by users, I think this fails on a multi-user, multi-login system. Make your own call! ( chmod u-s /usr/sbin/usernetctl )

Hacker's toolchest -- a useful paper that describes several simple tools that can be as good or even better than expensive commercial monsters like ISS.[June 26, 2000]

Linux Today - LKAP Linux Kernel Auditing Project This is a mission statement for the Linux kernel auditing project(LKAP).[June 15, 2000]

The purpose of this project is self-explanatory. It's an attempt to audit the linux kernel for any security vulnerabilities and/or holes and/or possible vulnerabilities and/or possible holes, and of course without adding more bugs or drawbacks to the existing kernels. The suggested kernels to be audited are 2.0.x kernel series , 2.2.x kernel series, and the 2.3.x/2.4.x kernel series. The group and it's work shall be dealt and worked with via a mailing list.

There's a few things that differ from this project compared to a few others that are similar.

1) To audit the kernel src code without affecting/breaking/disrupting any other part of the kernel. These will not be additional patches you can downloads (add-ons). This auditing is dealing with the current code in the src, not adding or implementing new functions.
2) To educate kernel developers/hackers on how to securely write code. It is my hopes that kernel developers/hackers new and old will subscribe and post to this mailing list with questions and share information, and to simply get help with their code(e.g.: Could this function() cause a possible security hole or lead to an exploit ?"), this is the true power of open source and GNU/Linux
3) To be ahead of the game... A perfect example of this are certain proprietary Operating Systems who sit around and wait for a security bug to come to them and not go to bug themselves. Of course this needs no explanation as to why this never works. I feel that kernel developers/hackers are down to earth and pretty logical people and realize that Linux is _NOT_ perfect, that a lot of the code they write, submit, and gets plugged into the kernel is not flawless and more than likely could be improved for security reasons.
4) To provide an operating system to the public. I want to see a linux where the sysadmin doesn't have to watch his back all the time in fear of see some new knfsd exploit or a way to fork()bomb his/her router via a simple mistake in buffer.c
5) To provide a safe linux to the end-user.. Linux is slowly but surely becoming a choice for the desktop user. Most of these users are walking into linux with no knowledge of what potential dangers lie at their finger tips and in their hard drive. Linux has proven to be one of the most secure operating systems, but I feel as linux becomes more popular with the general public this will change, that more kernel security holes and exploits will arise from nowhere and give us a very unpleasant reality check.
And at last, this will be no easy project, security auditing never is. It takes man power, skill, and just plain aching time. But I believe if the community of gets together on this one, nothing will stop us and Linux will go on to become the #1 security wise operating system to do this date.
Sincerely Bryan Paxton
How to subscribe:
echo subscribe kernel-audit | mail [email protected]

**** Advanced Linux security/Securing Linux, Part 2 by Michael H. Warfield (LinuxWorld) Good overview. Nice references. One of the few descriptions of using immutable and append-only attributes on the EXT2 filesystem:

Filesystem partitions
There is a reason for the filesystem standard, and it is well worth your while to invest time in taking full advantage of it. The filesystem can be divided into major partitions, and each partition can be configured and mounted differently. I strongly recommend separate /, /usr, /usr/local, /var, and /home partitions, at the very least.
/usr can be mounted read only and can be considered inviolate for purposes of validation. If anything ever changes in /usr, that change should ring an alarm bell -- literally. Of course, if you change something in /usr yourself, you will know that the change is coming.
The same idea applies to /lib, /boot, and /sbin. If you can make them read-only and alarm any attempts to change files, directories, or permissions, then do it.
It isn't possible to mount all of your major partitions as read only. For example, /var, by its very nature, cannot be read only, and for that reason nothing should be allowed to execute out of it. Things like configuration files for X servers should be symbolically linked to files which are kept in places which can be made read only -- and not through variable storage dumps.
Extending ext2
Use of the append-only and immutable attributes on the ext2 file system can provide enhancements to a secure installation. While not perfect in and of themselves, these attributes can be useful in detecting intrusion attempts when an attacker attempts to install rootkits or other backdoors over existing files. To be sure, such measures can be thwarted once they are detected. But by then, you should already have been notified and made aware of the intrusion.
If you have critical filesystems mounted read only and the files are marked as immutable, an intruder must remount the filesystems and remove the immutable bits -- all without getting caught or triggering an alarm. This is no small feat, and an intruder who recognizes this is more likely to go off in search of more vulnerable prey than risk being caught.
The immutable and append-only attributes are just two of the extended attribute flags on the ext2 filesystems. A file which is flagged as immutable cannot be changed, not even by root. A file flagged as append only can be changed, but it can only have material appended to it. Even the root user cannot modify it in any other way.
These attributes are added to a file by the chattr command, and can be listed with the list attribute or lsattr command. For more information on enhanced file protection through ext2 permissions attributes, see man chattr.
While partitions and ext2 attributes seem simple enough on the surface, they are actually bits of arcana -- and little effort or progress has been made in making them user-friendly. Even sophisticated users and administrators have been known to get tripped up on them, and so you should not treat them trivially.
Secure log files
The immutable and append-only attributes are particularly effective when used in combination with log files and log backups. You should set active log files to append only. When the logs are rotated, the backup log file created by the rotation should be set to immutable, while the new active log file becomes append only. This usually requires some manipulation of your log rotation scripts.

SECURITY: Linux.com: The Arash Baratloo interview [libsafe developer] [Jun 7, 2000]

Arash Baratloo and Navjot Singh two of the primary developers for Libsafe, a free software library that protects against security exploits based on buffer overflow vulnerabilities. They work as members of the Network Software Research Department at Bell Labs, the R&D arm of Lucent Technologies."

SANS Resources - How To Eliminate The Ten Most Critical Internet Security Threats -- the popular list of ten. Can be useful as a tool for persuading PHB to allocate additional resources for security.

Root Know Your Enemy: A Forensic Analysis by Lance Spitzner Last Modified: 23 May 2000

This paper is a continuation of the Know Your Enemy series. The first three papers covered the tools and tactics of the black-hat community. This paper, the fourth of the series, studies step by step a successful attack of a system. However, instead of focusing on the tools and tactics used, we will focus on how we learned what happened and pieced the information together. The purpose is to give you the forensic skills necessary to analyze and learn on your own the threats your organization faces.

Linux Today - Open Source IT The Myth of Open Source Security

"An author of the open source Mailman program explains why open source is not as secure as you might think -- using security holes in his own code as an example."
"Open source software projects can be more secure than closed source projects. However, the very things that can make open source programs secure -- the availability of the source code, and the fact that large numbers of users are available to look for and fix security holes -- can also lull people into a false sense of security."
"Eyes that look do not always see
With people motivated to look at the source code for any number of reasons, it's easy to assume that open source software is likely to have been carefully scrutinized, and that it's secure as a result. Unfortunately, that's not necessarily true. "

Linux Today - LinuxSecurity.com Interview with Frank van Vliet

"Frank van Vliet is the author of AuditFile, many security advisories, and recently pointed out configuration errors on apache.org. We thought our readers would be interested in an interview with Frank van Vilet because of the recent paper he and Peter van Dijk released outlining the steps they took to compromise apache.org. Their paper does not point out any new vulnerabilities, it merely shows how simple configuration errors can leave a system susceptible to attack. In this interview Frank explains how he audits a systems security, major pitfalls administrators fall into, and how he attempts to uncover bugs. We believe that everyone can learn something from this interview. Note: Frank uses the alias {}"
"LinuxSecurity: When and how did you gain interest in security? How did you gain your security knowledge?
Frank: When I finally switched from Windows to Linux, I spent a lot of time studying the Linux kernel source. When I finished that one I knew C enough to start coding on my own. I started working on my first security project called Auditfile. A kernel patch making it possible to restrict file access per process or per binary. This enabled me to run my apache webserver only allowing it to read default libraries (/lib/*, /usr/lib/*), read its configuration files, htdocs (wwwroot) directory, and only allowing it to write to logfiles with no further access. At the same time I took over control of the security focused group RooT66 http://root66.nl.eu.org and I joined ShellOracle http://www.shelloracle.org. I spent hours reading various texts and joined Buffer0verfl0w security http://b0f.freebsd.lublin.pl I also got involved with projects like SecNet http://irc.secnet.org (not finished when writing this). I have done some freelance security jobs for small webhosters"

OpenBSD perfects security by one-upmanship By Sam Williams [May 17, 2000]

The great violin maker Antonio Stradivari is reputed to have said that perfection consists not in doing extraordinary things but in doing "ordinary things extraordinarily well."

Still, when it comes to OpenBSD, the open-source operating system that for the last three years has built up a near-perfect track record for software security, it shouldn't be too surprising that project leader Theo de Raadt espouses a similarly reductionist design philosophy.
"On the grand scale we're not doing anything perfect," de Raadt says. "But we are doing a good job of making the little things perfect."
In a year that has seen software security jump from the back room to the front page, OpenBSD is getting a lot of attention. Although open-source advocates have long held up the community development model as superior to the "security by obscurity" approach, recent episodes such as the Red Hat (RHAT) "back door" controversy (see "French law would increase code accessibility") have demonstrated that time-to-market pressures can still produce slip-ups, even in the world of open-source development.
To remedy this situation, a growing number of security-conscious software vendors and consumers are turning to projects such as OpenBSD, projects that home in on security with a craftsman's zeal, disregarding the market as much as possible.

SECURITY: SunWorld: Hacker's toolchest; Techniques and tools for penetration testing [May 13, 2000]

What is a hacker's approach to penetration testing? What tools do they use? In this column, Carole Fennelly asks noted security specialists Brian Martin, Mark Abene, and Rain Forest Puppy for their perspective."

LinuxPapers.org: Using Log Files [May 13, 2000]

Even if you are only running your own Linux box at home, sooner or later you will face the task of having to solve some strange problems... where the only hint is some messages left in a log file. To prepare yourself for this, you should start peeking into log files right now..."

SECURITY: freshmeat: Security Issues of Auto-upgrades[May 13, 2000]

Package managers with download capabilities make it easy to download and install the latest software releases, bugfixes, and security patches. Could they also make it easy to download and install the latest exploits without your knowing about it?

SECURITY: eWeek: Microsoft's Outlook: Cloudy security [May 13, 2000]

IT managers and security experts, increasingly cynical and sharply critical over virus assaults through Microsoft Corp.'s Outlook e-mail client, are questioning not only Microsoft's technology but also its reaction to the latest attacks. ... 'If we didn't already have [Outlook] installed, I don't think I'd get it now'..."

Linux Today TheStandard Reading Red Hat's Piranha Problem Note that Pirahna, while being Open Source, was developed as a commercial product by Red Hat Software. The implication of your article was that Pirahna was written by hobbyists in their spare time. It was not. This was a a luck of quality control in the commercial open source software written by full-time employees of Red Hat. The fact weaken the argument that "software written by coders in their spare time isn't tested". but the truth is that Red Hat really lack quality control. It is true that there is some low quality open source software out there. It is also true that there is some very badly written and expensive closed source software around. On this front OSS has an major advantage: you don't have to pay lots of money to find out that the software is poor quality.

"Security holes are not uncommon in the software industry. But a recent vulnerability discovered in a Red Hat (RHAT) Linux product has refueled the debate over the security of open-source software."
"Internet Security Systems' research division discovered in mid-April that Piranha, a collection of utilities used to administer the Linux Virtual Server in the latest version of Red Hat Linux, ships with a default password. If the password is not reset, a malicious hacker could use it to make changes to Web pages on the server and possibly bootstrap to other servers on the network that might have vulnerabilities, says Chris Rouland, director of the ISS research division that calls itself the 'X-Force.'"
"ISS has since helped Red Hat fix the problem. The default password was 'simply overlooked in quality assurance and not removed,' Rouland says, adding that such oversights illustrate a flaw in the security model of open-source software, in which many independent developers adapt and add to the product's code."
"'There's limited quality assurance in the open-source environment,' says Rouland, 'because open-source software is basically a bunch of peoples' hobby.'"

"I'm a strong advocate of open design because it gives a lot of people a chance to look at software," says Avi Rubin, principal researcher at AT&T Labs in Florham Park, N.J., and author of The Web Security Source Book. "Open source is more debatable because it gives everyone a chance to find the vulnerabilities – the good hackers as much as the bad hackers."
Rouland suggests that open-source software's distribution method and collaborative, free-form development make its security questionable for mission-critical applications. The Piranha incident could be used to bolster either side in this debate.
"You could argue that open-source worked because ISS, a security company, found the hole and it was fixed extremely quickly," says Elias Levy, CTO for security portal Security Focus. "You could also argue that if ISS found this problem, who else found it that we don't know about?"

LinuxPlanet - Tutorials - Security and Apache An Essential Primer

1 Maxwell's Demon and Hat Colour
2 Mandatory Versus Discretionary Access Control
3 Realms: Areas of Controlled Access
4 Apache Security Processing Phases
5 Restricting by IP Address
6 Labelling and Inheritance
7 The Standard Apache Security Modules
8 Which Database is Authoritative?
9 Conclusions/For More Information

SECURITY: RootPrompt.org: Passive Fingerprinting; IDing remote hosts, without them knowing

(May 1, 2000, 13:39 UTC) (Posted by john) (0 talkbacks posted) (711 reads)
"Passive Fingerprinting is a method to learn more about the enemy, without them knowing it. Specifically, you can determine the operating system and other characteristics of the remote host using nothing more then sniffer traces. Though not 100% accurate, you can get surprisingly good results."

IBM Global Services - Business Continuity and Recovery Services - Denial of Service Attacks

This paper is written to help those concerned about denial-of-service (DoS) attacks, such as those recently experienced by e-Bay, Yahoo!, Amazon.com and other well-known online companies. It emphasizes the point that Internet security requires teamwork and attentiveness by all members of the Internet community.

SECURITY: Security Portal: SubDomain - Security Software for Linux

(Apr 26, 2000, 09:21 UTC) (Posted by john) (2 talkbacks posted) (644 reads)
"SubDomain is a kernel module that mediates system calls... allows you to configure which files a process is allowed to access, how it is allowed to access them (read / write / execute), and allows you to manipulate what child processes are allowed to do."

SECURITY: SecurityFocus.com: Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities

(Apr 27, 2000, 00:47 UTC) (Posted by marty) (0 talkbacks posted) (128 reads)
"A serious vulnerability exists in the IP Masquerading code present in, but not necessarily limited to, the 2.2.x Linux kernel. Due to poor checking of connections in the kernel code, an attacker can potentially rewrite the UDP masquerading entries, making it possible for UDP packets to be routed back to the internal machine."

SECURITY: CNET News.com: Red Hat glitch leaves Web servers wide open

(Apr 26, 2000, 01:11 UTC) (Posted by john) (3 talkbacks posted) (886 reads)
"Red Hat's Piranha software, which lets several Linux machines share a task such as delivering Web pages, has a password-protected feature used to control the software. But the part of the software that checks the password also will run whatever command an attacker wants, said Mike Wangsmo, director of the Piranha product."

Bell Labs libsafe Added to Slackware-current

We are pleased to announce that today version 1.3 of Bell Labs' libsafe library was merged into the slackware-current "contrib" tree. libsafe replaces several standard C library functions with versions that have been hardened against buffer overflow exploits. As this type of exploit comprises many (perhaps most) of the security vulnerabilities that are discovered these days, and as libsafe is transparently used by most programs throughout the system, its inclusion greatly increases system security with minimal impact on
the user.

Please see Bell's libsafe web page for more details:

http://www.bell-labs.com/org/11356/libsafe.html

The slackware-current ChangeLog also has more slackware-specific information, as does the libsafe.txt file in the /contrib directory.

ftp://ftp.slackware.com/slackware/slackware-current/ChangeLog.txt
ftp://ftp.slackware.com/slackware/slackware-current/contrib/libsafe.txt

Please note that libsafe is in the /contrib directory and not merged into the main distribution. This is due to a few problems noted in the libsafe.txt file, namely:

- libc4 and libc5 compatibility is broken. libsafe replaces libc6 functions, but is preloaded for everything. Programs dynamically linked against another libc version will see the libsafe functions, get confused, and die. This is to be expected.

- some other programs may break; we know that 'xv', at least, does.

See the aforementioned libsafe.txt before installing the libsafe package.

-- The Slackware Linux Project
http://www.slackware.com

Poking Holes in Linux However, the security community is divided, or undecided, about whether open-source as an operating system offers enough security.

A hole discovered in a Red Hat (RHAT) Linux product has experts debating how secure open-source software is, given that the code is wide open for the world to see. The research division of Internet Security Systems (ISS), dubbed X-Force, discovered a vulnerability this week in a collection of utilities, called Piranha, used to administer the Linux Virtual Server in the current distribution of Red Hat Linux, version 6.2.
The product ships with a default password that is easy to figure out, particularly now that it has been reported. If a network administrator does not change the password, a remote hacker could use it to take control over the Web server and make changes to Web pages. The password also could be used to exploit vulnerabilities in other servers attached to the network, X-Force director Chris Rouland said today.
...Linux's rise in popularity over the past few years has breathed new life into the open-source movement, with Linux enjoying increased acceptance as an alternative to Windows and other proprietary operating systems. Linux offers high performance, is freely distributed and can be quickly and easily improved. However, its free-form development means that its distributions lack standards and support.
"The fact that they've been finding holes in (Unix-based) Sendmail for 20 years indicates that open-source is not the best for security," Rouland said.
Most experts agree that open-source software can be valuable for encryption software. When testing encryption for weaknesses, it is assumed that hackers will know the algorithms, and the more people who try to crack it, the better. However, the security community is divided, or undecided, about whether open-source as an operating system offers enough security.
"I'm a strong advocate of open design because it gives a lot of people a chance to look at software. Open-source is more debatable because it gives everyone a chance to find the vulnerabilities – the good hackers as much as the bad hackers. So the jury's still out on open-source," says Avi Rubin, principle researcher at AT&T Labs in Florham Park, N.J., and author of The Web Security Source Book.
Open-source proponents argue that hackers can always reverse-engineer closed software to get the same advantage that open-source offers, but Rubin says it's not quite that simple. "Linux was designed with more security in mind than Windows, but at the same time, people haven't been banging on it for as long as Windows."
No operating system is safe straight out of the box. But because there hasn't been as much widespread use of Linux to secure sensitive machines, Linux users tend to be somewhat lax about security, says Alan Paller, research director at the System Administration, Networking and Security (SANS) Institute in Bethesda, M.D.
"It's not that the operating system is intrinsically weaker, it's that the people who use it are less careful," Paller says. "Nobody closes the holes." A free script can be used to fix most of the security holes, he adds.
ISS' discovery of the hole in Red Hat's Piranha software could be used to prove either point on the open-source security debate.
"You could argue that open-source worked because ISS found the hole and it was fixed extremely quickly," says Elias Levy, CTO for security portal SecurityFocus.com. "You could also argue that if ISS found this problem, who else found it that we don't know about? So it's a double-edged sword."

sendmail.net interview/venema sendmail.net: Q&A: Wietse Venema[Apr. 18, 2000]

How's it going?
Slowly. It's a problem, because by now lots of vendors are shipping systems with IP version 6 support. Postfix has taken a lot of my attention, and of course there are other things too, like the forensics tools I've been working on with Dan Farmer. We gave a free, full-day class on computer forensics last August and promised about six tools. The tools were given to the attendees as a beta release, but we really want to finish a first public release. I was actually hoping we would do it in April.
Can you describe those tools in more detail?
In our class, we explained how to get evidence after a break-in. There are all kinds of little bits and pieces of information that stay behind on a system when it's being used. And it's all very volatile, because every bit on a computer will eventually be overwritten, so you have to be really careful to recover the information or else it's gone forever. The most spectacular tools we have are for recovering deleted files. And they turn out to work much better than we expected.

... ... ...

You used to say you wrote every single packet you received to disk as insurance against crackers. Is that still true?
On my previous machine in the Netherlands, I used to do that. I'm not doing that currently, but I am in the process of reinstalling this functionality again.
Do you consider that good policy for a heavily targeted site?
Well, that depends on how much disk you have and on the bandwidth of your network. When I connected my own machine to the Internet a couple of years ago, I thought, "Well, maybe some people will attack me. How will I find out?" One possibility was to record everything that came over my network to a disc on a machine that no one could break into, and every now and then just look at the logs. Even if somebody managed to break in, it would be recorded and I could still see what happened and what the damage was.
Like running a surveillance camera in a 7-Eleven.
Well, the unfortunate thing is that nothing ever happened. So I recorded several years of "nothing happened." [laughter] I didn't do this when I came to the US, but I'm going to do it again, just as a kind of insurance.
Do you follow the Bugtraq list pretty closely?
I post to it infrequently, and I follow it from a distance. I don't know if you've noticed, but there are several new vulnerabilities every week. I don't think anybody on this planet is really keeping up to date with all these vulnerabilities. [laughs]

The complexity is killing open source security. As Elias Levy noted in his paper "Is Open Source really more secure than closed?" :[Apr. 17, 2000]

If Open Source were the panacea some think it is, then every security hole described, fixed and announced to the public would come from people analyzing the source code for security vulnerabilities, such as the folks at OpenBSD, the Linux Auditing Project, or the developers or users of the application.
There have been plenty of security vulnerabilities in Open Source Software that were discovered, not by peer review, but by black hats.

But there have been plenty of security vulnerabilities in Open Source Software that were discovered, not by peer review, but by black hats. Some security holes aren't discovered by the good guys until an attacker's tools are found on a compromised site, network traffic captured during an intrusion turns up signs of the exploit, or knowledge of the bug finally bubbles up from the underground.

Why is this? When the security company Trusted Information Systems (TIS) began making the source code of their Gauntlet firewall available to their customers many years ago, they believed that their clients would check for themselves how secure the product was. What they found instead was that very few people outside of TIS ever sent in feedback, bug reports or vulnerabilities. Nobody, it seems, is reading the source.

The fact is, most open source users run the software, but don't personally read the code. They just assume that someone else will do the auditing for them, and too often, it's the bad guys.
Old versions of the Sendmail mail transport agent implemented a DEBUG SMTP command that allowed the connecting user to specify a set of commands instead of an email address to receive the message. This was one of the vulnerabilities exploited by the notorious Morris Internet worm.

Sendmail is one of the oldest examples of open source software, yet this vulnerability, and many others, lay unfixed a long time. For years Sendmail was plagued by security problems, because this monolithic programs was very large, complicated, and little understood but for a few.

Vulnerabilities can be a lot more subtle than the Sendmail DEBUG command. How many people really understand the ins and outs of a kernel based NFS server? Are we sure its not leaking file handles in some instances? Ssh 1.2.27 is over seventy-one thousand lines of code (client and server). Are we sure a subtle flaw does not weakening its key strength to only 40-bits?

...While some of the binaries are cryptographically signed to verify the identity of the packager, they make no other guarantees. Until the day comes when a trusted distributor of binary open source software can issue a strong cryptographic guarantee that a particular binary is the result of a given source, any security expectations one may have about the source can't be transferred to the binary.

...Whatever potential Open Source has to make it easy for the good guys to proactively find security vulnerabilities, also goes to the bad guys.

It is true that a black hat can find vulnerabilities in a binary-only application, and that they can attempt to steal the source code to the application from its closed source. But in the same amount of time they can do that, they can audit ten different open source applications for vulnerabilities. A bad guy that can operate a hex editor can probably manage to grep source code for 'strcpy'.

Security through obscurity is not something you should depend on, but it can be an effective deterrent if the attacker can find an easier target.

So does all this mean Open Source Software is no better than closed source software when it comes to security vulnerabilities? No. Open Source Software certainly does have the potential to be more secure than its closed source counterpart.

But make no mistake, simply being open source is no guarantee of security.

Internet Security Handbook Edition One Cyberspace Center, The Hong Kong University of Science and Technology, Clearwater Bay, Kowloon, February, 1997

ZDNet PC Week Higher stakes, more options[Apr. 5, 2000]

The security debate pits two theories against one another -- "many eyes" vs. "security by obscurity." Open-source projects such as Linux follow the many eyes principle, which states that the more developers working on code and the fewer secrets, the harder it is to compromise the software because more people will detect issues and fix them.
"I tend to lean toward the open-source model for a couple of reasons," said Kelly Fulks, systems administrator at Huntsville Hospital, in Huntsville, Ala. "You have more people looking at the code, and if something goes wrong, we totally control the fix. It's lower cost, and it's always better to invest in people talent instead of paying for software." The hospital uses Sendmail.

Some vendors don't buy that. Lee Badger, principal computer scientist at Network Associates Inc., in Santa Clara, Calif., counters that the many-eyes theory "assumes people are motivated to examine even the mundane code, and I'm not sure that's always the case."
Proprietary-source advocates argue for hiding the code as a deterrent to breaking the code, just as burglars avoid houses with locked doors. That's the security by obscurity theory. If open source empowers software builders, it equally empowers attackers. With freely available blueprints, hackers can get clever at building malicious code to attack systems.
There is one tangible benefit that open-source security products offer over their closed counterparts: lower capital investment. Take CyberNet, for example. At the upcoming NetWorld+Interop conference in May, the Ann Arbor, Mich., startup will introduce the NetMax enterprise VPN (virtual private network) router for $400 -- a fraction of the cost of comparable VPN products from such closed-source vendors as Cisco Systems Inc. and Nortel Networks Corp. CyberNet will follow with enterprise firewalls and secure Web servers, officials said.

Open-source proponents argue that money is better spent on programming and services talent than capital equipment.
"The money they save on products can go to hiring people that can read and understand and support the code," said Will Harris, development support engineer at Red Hat Inc., in Durham, N.C. "You can put your own 'many eyes' on it."

SANS Resources - Help Defeat Denial of Service Attacks Step-by-Step

***** Root Prompt -- Build A Honeypot by Lance Spitzner. Larry proved that he is a real new star in computer security journalism. That's really meteoritic rise that I would never expect about people "who used to blow up he blew up things of a different nature ;-). I think that he is currently number one in this area. Excellent job -- congratulations Larry.

Linux Today TechWeb Task Force Internet Security Holes Rampant More than half of businesses on the Internet leave themselves open to security breaches because they fail to safeguard themselves."

"That is the finding of an Internet-security task force boasting some of the biggest names in the computer industry. The task force collects information from its members about Internet security." "A survey of e-businesses discovered one-half to three-quarters of businesses connected to the Internet have at least one of 20 known security holes. While some businesses take steps such as installing firewalls to protect themselves, most fail to employ adequate safeguards." "CMGI, Cisco Systems, and Verio are among task force members."

Intrusion Detection Primer -- weak but some links might be useful.

Root Prompt -- Nothing but Unix Know Your Enemy: II by Lance Spitzner This paper showed that Lance Spitzner became one of the prominent authors in this area.

This article is the second of a three part series. In the first article, Know Your Enemy, we covered the tools and methodologies of the Script Kiddie. Specifically, how they probe for vulnerabilities and then attack. The third paper covers what script kiddies do once they gain root. Specifically, how they cover their tracks and what they do next. This, the second paper, will cover how to track their movements. Just as in the military, you want to track the bad guys and know what they are doing. We will cover what you can, and cannot determine, with your system logs. You may be able to determine if you are being probed, what you were being probed for, what tools were used, and if they successful. The examples provided here focus on Linux, but can apply to almost any flavor of Unix. Keep in mind, there is no guaranteed way to track the enemy's every step. However, this article is a good place to start.

SECURITY: Linux Journal: Assessing the Security of Your Web Applications [Mar 6, 2000]

Web sites are moving away from static HTML to dynamic interactive web applications. It is the dynamic, interactive web application that is making the Internet the universal medium. Web applications bring a new level of risk to web sites. Security of these web applications is paramount to the security of the site."

SECURITY: Upside: New site on Linux security [Mar 4, 2000]

Last month's denial of service uproar has intensified attention to Internet security. Coincidentally... last month also saw the debut of LinuxSecurity.com, a new website completely dedicated to Linux operating system security issues."

SECURITY: IBM developerworks: Make your software behave: Learning the basics of buffer overflows[Mar 4, 2000]

ZDNet Sm@rt Reseller - TripWire Delivers Open-Source DDoS And Security Answer

The three Linux powerhouses are partnering with Tripwire to incorporate tightly the open-source Tripwire into their server Linux operating-system lines. Expect to see Tripwire security in each company's fall Linux release.

The Tripwire open-source program will be available in the third quarter. The main site will go live on the afternoon of Feb. 29. Tripwire's open-source development, however, will be hosted on VA Linux Systems' SourceForge.

The latest version of Tripwire, 2.2.1, is the open-source product's foundation. That program defends its systems with integrity assessment.

With this technology, Tripwire's first wall is intrusion detection. That is reinforced by constant monitoring for unauthorized system change. For example, Tripwire tripped up distributed denial-of-service (DDoS) Trojan infections by finding the obnoxious programs hidden deep in the operating system. Once discovered, the system administrator can rip those programs out.

Tripwire goes beyond just trying to prevent intrusions. It also tracks attacks, so you'll know exactly what happened. It gives you an evidence chain, allowing you to find and terminate the original attacker with extreme prejudice.

This program is already available in binary for Compaq TRU64 4.0; HP-UX, versions 10.20 and 11.00; IBM AIX, 4.2 and up; SGI Irix, version 6.5; Solaris 2.6 and 7.0; and Windows NT 4.0. A source-code version already was made available for users of Red Hat Linux 5.2 and up. Although not approved formally, that version also would run on Caldera, Debian and SuSE systems with Linux kernel 2.0.36 or higher.

Linux Today InfoWorld We can prevent those distributed denial of service attacks with 'egress filtering'

"Ironically, DDoS attacks are so technically crude that they can be almost entirely prevented by a simple change in most networks. Systems that spread the DDoS attack failed to have 'egress filtering' turned on."
"Either fix involves a simple change to a configuration file for a router. It imposes no performance penalty, because the system only checks that the address prefix of each packet is valid. The Internet Society provides a paper called Request for Comments 2267 that describes these procedures and other steps to take (see http://info.internet.isi.edu/in-notes/rfc/files/rfc2267.txt )."
And every corporation with an Internet connection can ensure that spoofed packets don't leave the corporate network. (This is called egress filtering. See www.sans.org/y2k/egress.htm for details.)

In addition, firewalls are essential protection for any system with a high-speed connection to the Internet. WatchGuard Technologies, which I wrote about in several columns last fall, offers five firewall appliances scaled for small to large businesses. WatchGuard provides an excellent white paper on the latest attacks (see www.watchguard.com/press/ddos1.asp , particularly the Resources section)."
Complete Story

Linux Today InfoWorld Anti-DoS efforts take hold at universities[Feb. 26, 2000]

"A GROUP OF security companies and organizations are expected to announce an initiative next week that will provide universities with free software to help guard themselves against being turned into "zombies" used to launch a distributed (DoS) denial of service attack."
"SSH Communications Security, the SANS Institute, RSA Security, Massachusetts Institute of Technology (MIT), and MindBright Technologies will detail plans on Monday to equip more than 130 colleges and universities in the United States with free encryption software via SSHs (Secure Shells)."
"Through the security initiative, every student, faculty members, and staff member from the participating universities will be provided with SSH universal log-ins and stronger authentication channels via SSH product versions 1.0 and 2.1 for use on servers and PCs. Secure Shell is a secure log-in program developed by SSH Communications Security that eliminates clear-text password transmission and provides encrypted file transfers."

Linux Today Linux Journal Network Monitoring with Linux[Feb. 26, 2000]

"Are you having trouble keeping your network under control? Here is an introduction to NOCOL: the freeware network monitoring system which will help you keep instability at bay."
"NOCOL, Network Operation Center On-Line, enables a designated machine to host a collection of network monitoring agents. These agents can perform a variety of tasks, from checking that a machine is ``up'' using the ICMP ping method to ensuring that a remote web server is operating as it should by requesting a test page. This allows problems on a network to be diagnosed and reported in a variety of ways, be it by e-mail, web page or dedicated terminal."
"As an example of NOCOL's flexibility, I coded an extension to the notifier tool, which utilized our internal SMS messaging system. This allowed text messages describing CRITICAL problems to be sent to my mobile phone. This was done by coding an e-mail front-end to the SMS gateway, so all notifer had to do was fire off an e-mail in the correct format."

National Post Online - financialpost[Feb. 22, 2000]

Those three individuals -- and possibly more -- are believed to have exploited some weaknesses in a program called WU-FTP or WU-FTPD.

Linux Today PRNewswire Reliable Software Technologies' Free Security Scanning Tool Addresses Hacking Concerns[Feb. 22, 2000]

"First to provide a solution that proactively prevents hacker attacks on computer and Internet software, Reliable Software Technologies (RST) today announced a free, open source software tool that automatically identifies over 130 of the most common security problems during the software development and auditing process. ITS4 codifies security expertise into rules used to identify potential security problems in source code. The new software tool will be available today for downloading from the RST Website (http://www.rstcorp.com/its4)."
Press Release

CERT-CC Understanding Malicious Content Mitigation For Web Developers[Feb. 7, 2000]

Web pages contain both text and HTML markup that is generated by the server and interpreted by the client browser. Servers that generate static pages have full control over how the client will interpret the pages sent by the server. However, servers that generate dynamic pages do not have complete control over how their output is interpreted by the client. The heart of the issue is that if untrusted content can be introduced into a dynamic page, neither the server nor the client has enough information to recognize that this has happened and take protective actions.

In HTML, to distinguish text from markup, some characters are treated specially. The grammar of HTML determines the significance of "special" characters -- different characters are special at different points in the document. For example, the less-than sign "<" typically indicates the beginning of an HTML tag. Tags can either affect the formatting of the page or introduce a program that the browser executes (e.g., the <SCRIPT> tag introduces code from a variety of scripting languages).

Many web servers generate web pages dynamically. For example, a search engine may perform a database search and then construct a web page that contains the result of the search. Any server that creates web pages by inserting dynamic data into a template should check to make sure that the data to be inserted does not contain any special characters (e.g., "<"). If the inserted data contains special characters, the user's web browser will mistake them for HTML markup. Because HTML markup can introduce programs, the browser could interpret some data values as HTML tags or script rather than displaying them as text.

The risk of a web server not doing a check for special characters in dynamically generated web pages is that in some cases an attacker can choose the data that the web server inserts into the generated page. Then the attacker can trick the user's browser into running a program of the attacker's choice. This program will execute in the browser's security context for communicating with the legitimate web server, not the browser's security context for communicating with the attacker. Thus, the program will execute in an inappropriate security context with inappropriate privileges.

DDJ X.509 CERTIFICATES by Paul Tremblett[Jan 27, 2000]

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).

DDJ ATTACK TREES by Bruce Schneier[Jan 27, 2000]

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 27, 2000] Linux PR Free embedded Linux firewall software from Fireplug

"...turns a minimally configured consumer PC into a basic stand alone Internet firewall, complete with address translation, proxying, and IP packet forwarding"
FirePlug's development team is pleased to present the EDGE Router a FirePlug ThinLinux demonstration of their commodity computing products. This software will allow you to turn a very minimally configured consumer PC (you know that old 486, the one currently being used as a doorstop) into a basic stand alone Internet firewall, complete with address translation, proxying, and IP packet forwarding (all from a single floppy and 16 megs RAM).
Find out more @ http://edge.fireplug.net

LinuxPlanet: Using Apache with Suexec on Linux - Executing CGI Scripts as Other Users[Jan 20, 2000]

SecurityPortal.com[Jan 20, 2000]

How did our contestants fair? Red Hat had the best score, with 348 recess days on 31 advisories, for an average of 11.23 days from bug to patch. Microsoft had 982 recess days on 61 advisories, averaging 16.10 days from bug to patch. Sun proved itself to be very slow, although having only 8 advisories it accumulated 716 recess days, a whopping three months to fix each bug on average. We can assume Sun and Microsoft should have and can do better, but we cannot prove that due to the fact that they use a closed system for developing software and fixing bugs. However we can clearly see that Red Hat could have done much better and cut their turn around time in half, had they only been more attentive to their own community. There were instances when software had already been patched by the author, but Red Hat was slow in creating RPM distribution files and issuing advisories.

1999 Advisory Analysis
Vendor	Total Days of Hacker Recess	Total Advisories	Days of Recess per Advisory
Red Hat	348	31	11.23	Details
Microsoft	982	61	16.10	Details
Sun	716	8	89.50	Details

Obviously, all vendors benefited on our scorecard from security vulnerabilities being disclosed only to them, accounting for many of the patches being available the same day as the advisory. We call these "friendly" advisories as opposed to "full disclosure" advisories. This will certainly stoke the argument between the full disclosure crowd and those arguing for releasing bug details only when the vendor has patched them. No matter which side of the argument you are on philosophically, we believe that full disclosure is the dominant trend, and vendors will need to better cope with being blindsided. Red Hat did a better job of handling the "full disclosure" bug releases, usually solving these problems in under 2 weeks, with 67 days being the extreme case. Microsoft usually took over 3 weeks to patch "full disclosure" bug releases, with a worst case of 146 days. Sun took in excess of 100 days 3 times, including a mind-numbing 385 days for a CDE problem related to a CERT advisory.

A frustrating part of "friendly" advisories is the fact that they are not accompanied by any date history. If Bindview, for example, warns Microsoft of a problem with NT, they do not provide the public any information about how long the bug fix has been a "work in progress", and when they first contacted Microsoft. This prevents us from gauging how efficiently the vendor is solving problems stemming from "friendly" advisories.

If you assumed that most of the initial advisories came from industry leading security firms with a staff of programmers and a fancy lab, you would be wrong. In fact, a wide majority of the bugs are discovered by individuals working independently. We think that this fact in itself is an indirect nod to the power of Open Source - you never know where a bug or a fix is going to come from and Open Source lets everyone participate in the process.

What have we proven in compiling these numbers? We think an entire year of data, while not conclusive, provides a fairly good indication that Open Source software can have its security vulnerabilities identified and repaired in a more timely manner than traditional closed source software. A bug fix from Microsoft takes almost 50 percent longer to reach the market as a fix from Red Hat - this despite the fact that Microsoft has huge advantages in funding and employees. An attentive Linux administrator who did not want to wait for Red Hat RPM files could get their patches even more quickly. The resources provided via Open Source seem to be providing Linux with the advantage needed to turn around bug fixes so rapidly. Is it possible that the slowness on the part of closed source vendors like Microsoft is due in part to a different and more rigorous quality assurance testing process? The process certainly is different, however Microsoft had to re-release five of its security patches in 1999 due to regression errors in the code, so it cannot likely be argued that the more lengthy release cycles by closed source vendors is translating into higher quality code.

Information about security vulnerabilities is moving across the Internet with greater and greater speed and is disseminated to a wider range of people. In the future, the gap between general awareness of a security vulnerability and its repair will become a more critical issue, leading to increased downtime, financial setbacks and loss of privacy. Open Source software seems to be at least part of the solution for closing that gap.

[Jan. 17, 2000] Linux Today: Dave Farquhar A Windows Author Reviews Linux-Mandrake 7.0

Kudos to Mandrake for taking security seriously. Mandrake has security levels, ranging from Cracker Heaven to Paranoid. Mandrake also permits you to tell it what kind of work you intend to do with your Linux box, and selects appropriate packages by default. If you're using Advanced or Expert configuration, you can even choose individual packages.

Skirting US export laws, once you get networking up and going, Mandrake provides you with a list of overseas FTP servers from which to download encryption software. This is a very nice added feature--in this day and age, you should always install SSH as a substitute for telnet access, but distributing SSH with Linux is a thorny issue at best.

Cisco - Improving Security on Cisco Routers -- a valuable paper from Cisco[Jan. 17, 2000]

Some thoughts on (network) intrusion detection systems[Jan. 17, 2000]

Kurt Seifried, [email protected], for http://www.securityportal.com/

January 12, 2000 - Last week I did a general overview of IDS systems and anti-virus software, and why they may not be the answer. Well in some respects they aren't and in some they are. But I think the main issue is the current model of intrusion detection (be it host or network based, looking for bad packets or data in the case of anti-virus software) is flawed (and the alternatives have a ways to go). Now to back up that statement so I don't get flame roasted.

Problem 1) Basic performance problems (machine):

Let's take a system like Network Flight Recorder for example (and don't get me wrong, as current NIDS systems go, NFR is one of the best on the market), NFR hoovers up all the traffic and can log it and compare it against a set of rules (modules actually) to see if any matches known attacks. NFR can also have multiple detection units that report to a central authority, so you can detect scans more reliably. So like most people you have a pretty diverse network, some Solaris, some Cisco, some NT, and so on and so forth. If you want to detect as many attacks as possible, you need to load all the modules available, resulting in slower performance, because NFR is literally doing more stuff. This will also result in the highest number of false positives, which will require you to spend a lot of time "filtering" manually. You can of course reduce the number of modules you need by not loading the ones that detect NetWare specific attacks for example, the assumption being you have no NetWare servers, or at least none accessible to the Internet. This can be a problem because at some point you might attach a NetWare server to the network in say your Internet DMZ, or (accidentally or otherwise) make an existing internal NetWare server visible to the Internet. The other, related problem, is that you might not load modules to detect attacks on Radius servers (same assumption as the NetWare servers apply here), which you might regret at some later point, very close to this is the idea of removing modules for old attacks, that you have patched all your applicable servers for. The problem basically boils down to the fact that networks have a habit of changing, rather quickly, and new services, new operating systems, and old bugs have a way of getting in without the correct people being notified. To ensure you don't miss anything (as the NFR admin), regular port sweeps using tools like nmap would be required to make sure new machines don't pop up, or new services, this technique of course is not infallible.

Problem 2) Basic performance problems (man):

The man hours required to properly maintain and respond to an (N)IDS system vary, most of it depends on how much traffic you monitor, and how often you get attacked (so generally speaking bigger sites, higher profile sites, and the like will generate more work). I also don't know about you, but I don't want to spend 8 hours a day staring at packet logs, trying to figure out what is hostile and what isn't (and then responding to it). Even if all goes well and you detect an attack successfully, the most you can do about it is to firewall the perpetrator, and contact their network administrator, chances are the attack was spoofed, or launched from a compromised machine (even if 99% of hosts on the Internet are secure, that still leaves around 1 million that aren't by today's numbers). Unlike the physical world, where most people (criminals being a subset of people) can't afford to hop on a jet plane, scoot over to Australia, rattle a few doorknobs in the hopes that one is open and rob the place, the Internet allows just that. The problem of "false positives" is made worse by the number of low level attackers (known as "script kiddies") seems to be increasing, largely due to the propensity of free UNIX platforms (*BSD, Linux), hacking tools (Bugtraq, rootshell), and Internet access (especially high speed access like ADSL and cable). This will only continue for the foreseeable future, I don't know when or where it will level off (or start to decline for that matter) but I don't think it will be anytime soon.

... ... ...

See also interesting critique A Response to Kurt Seifreid's Network Intrusion Detection System Article and A response to Elliot Turner's article

MSN News Stealing cards easy as Web browsing. See also Slashdot discussion[Jan. 16, 2000]

Just how easy is it to steal credit card numbers on the Internet? On Thursday, MSNBC was able to view nearly 2,500 credit card numbers stored by seven small e-commerce Web sites within a few minutes, using elementary instructions provided by a source. In all cases, a list of customers and all their personal information was connected to the Internet and either was not password-protected or the password was viewable directly from the Web site.

Cisco Flow Logs and Intrusion Detection at the Ohio State University[Jan. 16, 2000]

SecurityPortal.com Network Intrusion Detection Systems and Virus Scanners - are they the answer? by Kurt Seifried, [email protected], for http://www.securityportal.com/[Jan.9, 2000]

January 5, 2000 - It takes a lot less effort to destroy and break things, than it takes to build and fix them. This is nowhere more evident then computer networks. Corporations, governments, universities and other organizations spend large sums of money on computer network infrastructure, and the cost of keeping them running is not trivial. And this doesn't even take into consideration malicious attacks and security controls which add even more cost to building and maintaining a network of computers. Unfortunately for most of us, the desktop is Microsoft centric, which means most of us can't do a whole lot to it to make it more secure. If you run Windows 95 or 98 you get no file permissions (and hence the computer has absolutely minimal protection from hostile acts), if you run Windows NT 4.0 Server or Workstation the default settings are full control for everyone for all files on the system, and registry keys (fixing this takes a long time, and will break some applications). Let's assume for a minute you have fully locked down the machines, users cannot modify them, they are physically secure, and so on, are you secure? No. New problems for various operating systems are made public all the time, these range from minor security issues to full blown "take control of the machine remotely and do what you want with it". Also, due to the single user oriented nature of Windows there exists a whole class of malicious software called viruses, which typically consist of some code to exploit a program or system bug, a replication mechanism, and possibly some additional software that ranges from annoying to destructive. What are network and systems administrators to do in such an increasingly hostile world?

VXE- virtual executing environment by Serge Lozovsky <[email protected]> -- Interesting approach for the protection of often compromised UNIX daemons(sendmail,popd, etc.). [Jan.2, 2000]

Can be used for protecting any other program including CGI scripts. The approach somehow reminds classic IBM VM/CMS approach. Requires creating of VXE description (VXED) for each protected program or a group of protected programs (for example user-supplied CGI scripts). Several sample VXED are supplied with the system (popdesc.vxe, smptserv.vxe, tcl.vxe, tcl.vxf, etc.). Looks like a very powerful approach -- much more powerful than chroot. Can be extremely useful for protecting user-supplied CGI scripts. Free for non-commercial use.

Main problem with UNIX security is that superuser can do with system anything he wants. There are programs (daemons) which work with superuser privilegies, for example popd, sendmail, and accessible from network (Internet/Intranet). There could be bugs in any program, so intruder connects to such programs via network, exploit existing bugs in it and get a control over all host.
VXE (Virtual eXecuting Environment) protects UNIX servers from such intruders, hacker attacks from network and so on. It protects software subsystems, such as: SMTP, POP, HTTP and any other subsystem, already installed on the server. There is no need to change configuration of existing software - just PROTECT it.
...Virtual eXecuting Environment (VXE) protects the host and particular subsystems, which work as superuser and could have bugs. When the program works in superuser mode, it can access all resources of the operating system (OS). VXE creates virtual environment for each subsystem. In such environment only needed for normal work resources are visible and available for subsystem. Subsystem here, is startup program and all subprocesses initiated (forked) by it. Any subprocess runs in the same VXE that the parent. To affect any system resources, program use OS system calls (syscalls). VXE has means to describe what system calls, with what parameters are available for each subsystem. For example, it can be described (for file operation syscalls) that some files are readable and some executable, network operations unavailable (in case of POP server - it handle network connection, but doesn't make new ones) and this restrictions can't be broken even by a program with superuser privileges.
These restrictions can be as smart as needed. If intruder gets a control over such subsystems, he can't use ordinary methods to sniff information or affect the system. Everything he can do in theory, using sophisticated methods, - is to affect the work of hacked subsystem, but not OS itself, nor another subsystems. Here, ordinary methods, are those, when intruder gets superuser privileges and runs command interpreter (shell), and ordinary utilities, such as text editor, copy utility and so on. He can't do anything without such utilities. For example, POP server doesn't need text editor and copy utility for it's work, so there is no such programs in VXE environment, created for POPD protection....
VXE description (VXED) is small LISP program (set of functions) which use declarative description of acceptable parameters for different system calls. This VXED loaded to the kernel, controls system calls parameters from the specified subsystem. So VXEDs are dynamically loadable modules, handled by the small LISP interpreter, inserted into the kernel. In current VXE version, this is vxelisp, derived from RefLisp (Bill Birch [email protected]). vxelisp has new internal bigstring representation, full set of string and bit functions. Kernel version of vxelisp is reentrant, to handle different VXEDs simultaneously.
There are two methods to activate VXED. Explicit and implicit (automatic). Explicit activation is done by vxe program. Parameters are VXED pathname, path and parameters of executable, which will be run with restrictions, described in named VXED. For automatic method, vxed utility preloads all needed VXEDs into the kernel. Each VXED has activation pattern. During program start (exec), kernel checks executable path against patterns. VXED with matching pattern is activated. This method can be used, to activate protection at the start of any program in specified directory (and all subdirectories). For example, to protect system from CGI scripts, supplied by users, VXEDs can be defined for each user subdirectory.
Any sophisticated VXED can be created manually, using full power of vxelisp. But VXE doesn't force administrator to learn and use LISP. One can think about VXE as of self-learning system. VXE development system (DS) runs VXE in trace mode.
Such run makes description of permitted (used) system calls. Creation and modification of VXED is made via WWW interface. Development system supports two types of VXED. Strict and filesystem types. Strict VXED describes all permitted syscalls explicitly. Filesystem VXED describes read, write, and execute permissions for defined paths. Specified restrictions apply to filesystem syscalls, all other syscalls are permitted. After VXED has been created for particular subsystem, VXED works in soft mode. In this mode all violations of VXED are logged, but syscalls are performed. VXE DS can upgrade VXED automatically, using logged information.
Surely, needed changes in VXED can be done manually using VXED editor. Violations can be caused by intruder activity or by deviation in subsystem's behavior under various circumstances. VXE administrator reviews log with the help of DS and makes decision, if upgrade is reasonable. If there are no violations, VXED can be switched to production mode. In this mode violations are logged and syscalls are blocked (fail). Once again, the log can be used for intruder detection or for VXED upgrade (tuning).
For security reasons, all control actions over VXE can be done only by superuser and outside any VXE.
VXE affects performance in following ways. If program runs outside any VXE, every syscall executes two assembler instructions more (checks if VXE is in effect for current process and jump if no). For every exec syscall a small C subroutine checks if there is a matching VXED already available in the kernel. For programs that run in VXE, a few lines of C code checks if parameter verification is needed. Some syscalls can be marked in VXED as uncheckable (for example, by default, read and write operations). And only the rest syscalls are checked by very small LISP functions. These functions located in VXED and can be easily observed by administrator.

Several interesting links found of Free BSD site:[Dec 21, 1999]

23-Aug-98 Suidcontrol-0.1 utility has been released. The suidcontrol is an experimental utility for managing suid/sgid policy under FreeBSD. You can get more information at http://www.watson.org/fbsd-hardening/suidcontrol.html
9-Aug-98 FreeBSD Security How-To has been published. This work is currently in beta and can be found at http://www.best.com/~jkb/howto.txt
Feature Article Nov96

Security Tools -- another list of useful security tools [Dec. 19, 1999]

findsuid, pcheck ftp://isgate.is/pub/unix/sec8/ This little shell script can be run from cron and will report setuid and setgid changes (very handy and simple script!)
freestone ftp://ftp.soscorp.com/pub/sos/freestone Portable firewall implementation
ipfirewall ftp://ftp.nebulus.net/pub/bsdi/security This an ip filtering tool on steroids that is comparable (if not more extensible) to commercial versions.
merlin http://ciac.llnl.gov/ A Front end for a variety of popular security tools such as
obvious ftp://isgate.is/pub/unix/sec7/ Looks for obviously stupid passwords.
xroute ftp://ftp.x.org/contrib/utilities/ An X packet router (go figure right) to move X packets between hosts.

Linux, Independent Media, and the Survival of Democracy[Dec. 14, 1999]

Linux PR Bastille Linux releases v1.0.0 at SANS San Francisco Security Conference 99 -- Perl script similar in function to ASET, Titan, etc. Can be adapted to FreeBSD and Solaris[Dec. 14, 1999]

Bastille Linux releases v1.0.0 at SANS San Francisco Security Conference 99
Dec 14th, 05:40 UTC
The Bastille Linux development team is proud to announce the first release of the Bastille Linux hardening script. The Bastille Hardening script attempts to provide the most secure, yet functional, Redhat 6.0 system available. (Support for Red Hat 6.1 is forthcoming.) Bastille Linux was designed with several major goals:
Bastille Linux draws from every available major reputable source on Linux Security. The initial development integrated Jay Beale's existing hardening scripts for Solaris and Linux with most major points from the SANS Securing Linux Step by Step, Kurt Seifried's Linux Administrator's Security Guide, and several other sources.
Bastille Linux has been designed to educate the installing administrator about the security issues involved in each of the script's tasks. Each step is optional and contains a description of the security issues involved.
Once the initial development was near complete, we brought the effort to the developers of the Bastille Discussion mailing list. Further, we began soliciting outside suggestions and testing. The script was GPL'd promptly and the Specification shared.
The Bastille Linux hardening script is a community consensus project: it attempts to integrate existing "best practices" documents and the shared knowledge of many administrators. The project needs constant input from its user community (This means you!) in order to remain current, as well as to fill in the gaps in our existing structure. Bastille Linux is far from perfect, and your input is crucial to making it better.
Bastille Linux 1.0.0 is available from the following locations:
http://bastille-linux.sourceforge.net/bastille-1.0.0.tar.gz
http://www.gl.umbc.edu/~jbeale1/bastille-1.0.0.tar.gz

Linux Today: Progressive Systems Announces Free Givaway Of Linux Firewall

Progressive Systems, Inc. announced the free giveaway of a personal-use version of its Phoenix Adaptive Firewall. The fully featured firewall will support two users and is not time-limited. The software can be downloaded from http://www.progressive-systems.com. In addition, Progressive Systems is giving away unlimited session copies of the software to Linux user groups. User groups may obtain copies of the software by contacting Progressive's sales staff.
Press Release

UNIX & LINUX Computing Journal: The Password of Choice

(Dec 12, 1999, 15:14 UTC) (Posted by marty) (2 talkbacks posted) (720 reads)
"Now, for whatever reason, most people hate passwords. Most will choose simple, possibly obvious ones that may even be written on a yellow stickie on their monitor."

UNIX & LINUX Computing Journal: The Text Based Interface

(Dec 12, 1999, 15:07 UTC) (Posted by marty) (7 talkbacks posted) (959 reads)
"So why do so many UNIX users, after getting frustrated using Linuxconf, the "Control Panel", HP's SAM or any other GUI admin tool have tendency to huff and puff, then close the damn thing and fire up an xterm?"

SECURITY: UNIX & LINUX Computing Journal: Linux Security Tools

(Dec 12, 1999, 14:52 UTC) (Posted by marty) (0 talkbacks posted) (503 reads)
"Linux has a large selection of both ported and inherent tools that you as an adminstrator or otherwise can peruse to make security checks and audits a little easier."

Locking doors, latching windows[Dec. 2, 1999]

LW: What tools does Abacus include?
CR: The publicly released tools include

Psionic Logcheck
Psionic PortSentry
Psionic HostSentry

Logcheck was the first publicly released package. Logcheck combs through system audit trails at specified intervals (usually hourly, as set up in cron). It then looks for unusual or known security events and mails them to the administrator for further analysis and action.
Logcheck was largely inspired by a script I saw on the TIS Gauntlet firewall by Marcus Ranum and Fred Avolio called frequentcheck.sh. It did quarter-hourly reporting of security events on the firewall, and I really liked its simplicity. I obtained permission from the authors to clone the tool back in 1995. I rewrote the tool and made some changes to the original logic to make it work better for general system administration and packaged it up to work on multiple platforms.
PortSentry was the second released package and was started back in 1997 after I got tired of having people scan the ports of systems I controlled.
PortSentry is a real-time port-scan detection and response tool. It is designed to detect attackers and stop the activity while notifying administrators. It is surprisingly effective at detecting and stopping many attacks cold. In essence it turns your machine into a black hole once an attack is seen and makes further intrusion attempts from the attacking host almost impossible.
Most people are surprised at how many probe attempts PortSentry detects. A typical user on a 24-7 connection (cable modem, commercial user, etc.) averages around two probes a day! The Internet is truly a dangerous place for those not paying attention to their computers.
I had for a long time been using TCP wrappers combined with a custom script to drop the route of people who hit the booby-trapped port. This worked well, but I really wanted a tool specifically designed to do the job.
I spent an evening coding the original prototype and put it out on the Internet a couple of months later. After that, many feature requests started coming in and the tool began to expand from the original, which only did full TCP port-connection detection, to the current tool, which covers just about everything, including all major stealth scan types.
HostSentry actually started about the same time I wrote Logcheck back in 1995-96. HostSentry uses Login Anomaly Detection (LAD) to see if a user login is suspicious. Basically, it attempts to use existing usage patterns and known intrusion practices to spot accounts that have had a compromised password. This is especially useful in catching accounts that have had passwords sniffed (which is one of the most common ways to break in to a host).
The HostSentry tool was actually just called LAD in the beginning. It was written after I was called in to help clean up a security incident. A user had his account compromised off a sniffed POP3 password. I wrote the original prototype in C in a couple of evenings and used it to track system users and spot other compromised accounts. It was surprisingly effective at helping clean up the mess. I let the project rest for a couple of years and resurrected it by rewriting it in Python (my favorite programming language BTW).

Linux Today SuSE Security Announcement - new security tools[Nov. 26, 1999]

Tools developed by SuSE (all open source) and included in SuSE 6.3 :
SuSE FTP Proxy - The first program of the SuSE Proxy Suite. A secure FTP proxy with support for SSL, LDAP, command restriction, active and passive FTP support, and much more.
RPM: fwproxy.rpm, fwproxys.rpm (SSL - not in the US version)
SuSE Firewall - The new firewall script from SuSE, rewritten from scratch. Autodetection of interface information, masquerading, autoprotection of services, protection from internal networks, fail-close design and easy to configure. RPM: firewals.rpm
Harden SuSE - A special script for hardening a SuSE Linux 5.3 - 6.3. By answering 9 questions, the system is reconfigured very tightly. e.g. disabling insecure network services, removing suid/sgid/world-writable permissions which are not critical. RPM: hardsuse.rpm
SuSE Secumod - This loadable kernel module enhances the security of the system by adding a symlink/hardlink/pipe protection, procfs protection, trusted path execution and capabilities. RPM: secumod.rpm
SuSE Secchk - These are cron scripts which run daily, weekly and monthly to check the security of the system and compare them to the last run. RPM: seccheck.rpm
Yast-1 - New administration menu for setting password aging, authentication fail delay and logging of logins + failures. RPM: yast.rpm
SuSE auditdisk - Please note that this tool is in beta phase! This tool generates a bootdisk with checksum data and all binaries etc. needed to automaticaly verify file checksums upon booting. This way it can't be subverted by lkm's like a standard e.g. tripwire installation.
WWW: http://www.suse.de/~marc - not included on SuSE 6.3 yet
Watch out for updates of these tools on our WWW or FTP update sites. Although these are tools developed by SuSE, they (should) work on any Linux distributions with little problems.
New tools included in the SuSE Linux distribution (not created by SuSE):
FreeS/WAN - IPSEC implementation to build secure VPN tunnels via public networks.
RPM: freeswan.rpm (not in the US version)
GNU Privacy Guard - A free pgp-like tool for secure (not limited to email) communication. Frontends are also included.
RPM: gpg (not in the US version)
Nessus - A very good network security scanner!
RPM: nessus
plus tmpwatch, arpwatch, plug, sslwrap, the newest nmap and more. "Old" packages include: john, saint, cipe, pgp, scanlogd, ssh, tripwire, etc.

SUSE webpage for security announcements:
http://www.suse.de/security

[Aug 17, 1999] A new version of cfingerd, the configurable finger daemon, has been announced. It allows extensive control over the information returned by finger, and contains a number of security fixes.

[Aug 17, 1999] FCheck v2.07.37 has been released. FCheck is a perl system which performs system integrity checking and intrusion detection on a number of different platforms. See the announcement for details.

[Aug 14, 1999] forum - Guest Feature Forum The Internet Auditing Project -- a good PR show within the possible limits and they are for sure qualified enough to go farther if they want to but they have done nothing for security

Articles: Internet Auditing Project Results -- good comments

*** UNIX Security Resources -- good

Programs To Help Keep Your System Safe

[May 26, 1999] SecuriTeam.com

[May 20, 1999] NETSYS.COM TECHNICAL LIBRARY

[March 28, 1999] Linux Today Worm for Linux x86 found in wild

[March 28, 1999] 32BitsOnline.com - Security Tools [Regular Columns-Platforms-Linux-Linux Journeys]

UNESCO Observatory on the Information Society - Themes - Content Regulation - Violence in Cyberspace -- International review of criminal policy - United Nations Manual on the prevention and control of computer-related crime

The burgeoning of the world of information technologies has, however, a negative side: it has opened the door to antisocial and criminal behavior in ways that would never have previously been possible. Computer systems offer some new and highly sophisticated opportunities for law-breaking, and they create the potential to commit traditional types of crimes in non-traditional ways. In addition to suffering the economic consequences of computer crime, society relies on computerized systems for almost everything in life, from air, train and bus traffic control to medical service coordination and national security. Even a small glitch in the operation of these systems can put human lives in danger. Society's dependence on computer systems, therefore, has a profound human dimension. The rapid transnational expansion of large-scale computer networks and the ability to access many systems through regular telephone lines increases the vulnerability of these systems and the opportunity for misuse or criminal activity. The consequences of computer crime may have serious economic costs as well as serious costs in terms of human security.

Five Security Secrets -- ZDNet Products

Alerting Wares Keep Downtime To a Minimum

Internet Security Systems Inc. RealSecure 2.0

Story Your Biggest Security Threat. (It Isn't What You Think)

Have you ever looked at murder statistics? The media focuses on mysterious killers who murder strangers. Sure, it happens. But in reality, you are most likely to be killed by someone you know. The same thing holds true with network security. Everyone focuses on mysterious outside hackers. But in reality, your network is most likely to be compromised by people inside your organization.

...To prevent unauthorized access to private networks, companies typically set up firewalls where the internal network meets the (external) Internet. Fine and good. But a new report by enterprise network services company NetVersant Technologies reveals that firewalls don't protect you where you are most vulnerable. Because they don't shield you from the people inside your own organization. The two biggest inside problems are:

Internal attacks. According to the Computer Security Institute/FBI and Ernst & Young,
nearly 50% of all network attacks come from the inside. Often, from unhappy workers.
Which explains why 76% of the IT executives surveyed by NetVersant said they were
concerned about inside attacks from unhappy employees.

Non-compliance. Who cares how good your systems are if employees ignore them? In the NetVersant survey, 82% reported spotty -- or no -- compliance with their company's network security policies. 85% say a properly-implemented firewall would still be at
risk from a disgruntled employee. And 75% say the firewall is at risk from garden-variety employee incompetence.

Tech Tutorials Network Security Anything But Bulletproof

http://www.gelb.com/chapter1.html -- firewalls
http://www.gelb.com/chapter2.htm -- firewalls

Performance Computing - Features - Kerberos A Secure Passport

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created: May 16, 1997; Last modified: February 28, 2008

version:	1.3
author(s):	Gerhard Mourani, <[email protected]>
last update:	June, 2000
available formats:	PDF (4MB) Example server configuration files (tar file; described in book as "floppy.tgz").