Unix Forensics and Distributed Denial of Service

Unix Forensics and Distributed Denial of Service
October 6, 2000
Speaker: Dave Dittrich, University of Washington
Scribe: Nick Feamster
Notes on the DDoS Talk (10/6/2000)
----------------------------------

In the past, the following techniques have been popular:
1997: sniffers
1998: rootkits
1999: DDoS
Today: kernel module hacks, universal rootkits

Often exploits are people's first efforts at coding.

Recently Targeted Sites:
* Hacker News Network
* Brazilian Government
* New Zealand's primary ISP
* British Telecom
* NHL Official Website
* 250 Systems in Korea

How big are the DDoS networks?  estimated 40-50 machines for a given
attack

Defenses:
- changes in protocols (host identity protocols)
- ingress/egress filters
- traceback mechanisms
- improving response across countries
- FBI: greater powers for search and seizure (Carnivore, etc.)

Issues:
- Kernel modules are hard to detect!
- It's also pretty easy to nohup a process and then rm it, providing for
some potential confusion.
- Lack of network-level forensics (hard to legitimately log abnormal
traffic)
- basic sysadmin skills are easy, but most people don't want to do it
- on David's network, he estimates one system rooted per day
- he has authored 4-5 DDoS tools himself => does this benefit the
blackhats?  or does it lead to speedier responses?
- cable modem/DSL users: most people don't know whether their machine
has been hacked or not

What about law enforcement response?
- sniffers = wiretaps?
- local kernal modules
- response to widespread use
  - tools for diagnosis
  - means of response

========================================================================

Q & A
-----

Q. How do people respond to people trying to do David's job?
A. Usually they are cooperative when they know how to be

Q. White-hat vs. Black-hat in real life?
A. Often people don't report problems for fear that their machines will
be seized, taken offline, etc.

Q. Why should a dumb user not install an insecure OS?  What are the
reasons/incentives for being thorough in this respect?
A. - Bad PR
   - liability/litigation
   - ** if anything, customers do not want security ** (too much
   trouble)
   - pressure is on ISPs to do the right thing (filtering, etc.)
   - support for traceback
     - but this is really just an "attack"-back, because these attacks
     are run on hacked machines

Q. Experiences at Universite of Michigan?
A. Categories of solutions:
   - network
   - hosts
   - benefit you/others/both
   Lesson: there is no silver bullet.  Even a traceback cannot prevent
   network floods, etc.  Host identification will solve network
   consumption issues, but not other issues.

   Often people's solution to a break-in is to simply reinstall from the
   distribution CD.  Obviously, this is dumb.  Same thing will happen
   again!


Interesting note:  University of Washington disallows incoming TCP
connections (i.e., from external hosts)!

Windoze/DSL connections is a nasty combination.

Q. More black hats vs. White Hats
A. Black hats have the time, white hats have "real jobs"
   
People often think they have no assets to protect ("why do I care?").
But what about: 
   - CPU
   - bandwidth
   - disk space

Q. Are there patterns of attacks?  Like time of year, etc.?
A. late August/early September is very popular for some reason

Q. Are the Univ. of Washington students themselves ever involved in
these attacks themselves?
A. Not generally.  The occasional stalking attack (ex-girlfriends, etc.)

Q. What is the evolution of attacks?  That is, what will attacks look
like 2-5 years from now?
A. In terms of DDoS, tools are getting more efficient, harder to detect
and easier to propagate.  Victims of attacks will start to want legal
actions.  Small groups are getting better at breaking into a larger
number of machines.

Q. Any particular OS a target?
A. Seemingly Linux has more intrusions.  RedHat in particular, although
older versions of Slackware, etc. occasionally are subject to exploit.

Q. What about a secure OS distro?
A. should be easy to set up, and probably will involve minimal
services.  linuxconf...ick.

Brought to you by the MIT LCS Applied Security Reading Group