Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   

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:

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.

  1. Introduction: Why bother? What risks does an insecure BIND pose?
  2. Install and Configure BIND: compile, install, create DNS data, start BIND.
  3. Chroot'ing BIND: Create chroot jail, copy BIND to jail, start BIND.
  4. Troubleshooting
  5. Configuration Notes
  6. Footnotes
  7. 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, <gmourani@openna.com>
last update: June, 2000
available formats:
  1. PDF (4MB)
  2. 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 wietse@PORCUPINE.ORG
To: BUGTRAQ@SECURITYFOCUS.COM
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.

 

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 jay@bastille-linux.org 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 all3 the Set-UID programs owned by root using the command4:

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:

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

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

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

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

 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 majordomo@nl.linux.org

**** 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 sec