- Simple Nomad - -
- thegnome@nmrc.org <mailto:thegnome@nmrc.org> - No rest for the Wicca'd -
- www.nmrc.org <https://www.nmrc.org> - -

--------< Strategies for Defeating Distributed Attacks

-----------< Simple Nomad
-----------< thegnome@nmrc.org <mailto:thegnome@nmrc.org> - Nomad Mobile Research Centre
-----------< thegnome@bos.bindview.com <mailto:thegnome@bos.bindview.com> - BindView RAZOR Team


--------< Abstract

With the advent of distributed Denial of Service (DoS) attacks such as 
Trinoo, TFN, TFN2K and stacheldraht [1], there is an extreme interest in 
finding solutions that thwart or defeat such attacks. This paper tries to 
look not just at distributed DoS attacks but distributed attacks in general. 
The intent is not to devise or recommend protocol revisions, but to come 
up with useable solutions that could be implemented at a fairly low cost.
This paper is also written with the idea that probably 90% of the problems
surrounding distributed attacks can be easily solved, with the last 10%
requiring some type of long-range strategies or new code to be written.


--------< Basics About Attack Recognition

How does one recognize an attack? Not just a Denial of Service attack, but
any attack? Before we can start applying solutions, we need to have a
discussion of attack recognition techniques. So let's first look at the 
two main methods of attack recognition - pattern recognition and affect 
recognition. 

Pattern recognition looks for a measurable quality of the attack in a 
file, a packet, or in memory. Looking for file size increases of 512 bytes
or seeing a certain byte sequence in RAM are two simple examples of
pattern recognition. Looking for the string "phf.cgi" in web traffic might
be a simple method used by a network-based Intrusion Detection System
(IDS). 

Effect recognition is recognizing the effects of an attack. An example
might be specific log file entries, or an "unscheduled" system reboot.

In intrusion detection, pattern recognition is the only method used by
network-based IDS, while both pattern and effect recognition can be found
in host-based IDS. And herein lies the crux of the problem - attack
methods are calling for effect recognition methods to be applied to
network-based IDSes, and the technology just isn't there. See [2], [3].

Pattern recognition alone has problems to begin with. If a pattern that is
being checked for is altered by the attacker, such as a key word or byte
sequence, then the IDS will miss it. For over a year it has been common
knowledge that by dividing up an attack sequence into fragmented packets,
you can defeat most IDSes. In fact, a majority of commercial IDSes are
still unable to process fragmented IP packets [4].

Now couple this with the fact that effect recognition technology for 
network-based IDSes is virtually non-existent, and you can see the problem.
If an attack is a one-time network event, your network-based IDS stands a
chance of detecting it, but a sustained series of network events will be
even more difficult to detect, especially if the events are disguised to
look like normal network traffic.

Distributed DoS attack tools such as stacheldraht will leave definite 
patterns that can be searched out on the network. But attackers can modify
the source code of the tools, causing a different pattern to be produced.
If they do this, the IDS will not detect the new pattern.

What we need is an Overall Behavior Network Monitoring Tool, that can look
at logs on different systems from different vendors, sniff realtime 
network traffic, and can logically determine bizarre or abnormal behavior
(and alert us). Unfortunately, there *is* no such tool, so we need to make
use of what tools we have (firewalls, IDS, etc) in a way that will thwart
or at least notify us about potential distributed network attacks.
We will discuss such strategies in this paper.


--------< Definition of the Attack Model

Before we start defining attack models, it should be noted that a number
of the attack models discussed here are theoretical. To prevent confusion
we will not differeniate between the two. Our discussion here centers
around the overall concept of a distributed attack, real and theoretical, 
and tries to solve for the concept instead of specific attacks. 

There are two basic models of attack. In the first, the attacker does not 
need to see the results. In the second, the attacker *does* need to see
the results. Distributed DoS attacks are good examples of attacks where
the attacker does not need to see the results, and since this simplifies
our attack model, we will examine that model first.

Distributed attacks have one interesting element in common. Typically 
someone else's system is used to perform fairly critical tasks to meet the
objective. The flow of action is usually like so:

Figure 1:

*--------* *--------* *-------*
| | | | | |
| client |---->| server |---->| agent |
| | | | | |
*--------* *--------* *-------*

issues processes carries
commands command out commands
requests
to agents

There can be multiple servers, and hundreds of agents. The usual 
deployment involves installing servers and agents on compromised systems,
in particular installing the agents on systems with a lot of bandwidth. To
help prevent detection and tracing back to the attacker directing the
activities, the act of issuing commands is typically done using
encryption, and by using ICMP as a transport mechanism.

With encryption, this helps at least hide the activities from active 
sniffers being used by administrators, although it does not preclude 
detection by other means. The packets used in part of the communications 
by such products as TFN2K and stacheldraht can be encrypted, rendering 
common viewing via a sniffer or IDS from casual detection of the rogue 
packets.

While the model for hostile behavior that does not require viewing of the
results or "return packets" is in reality a little more complex than the
model I've outlined, the model for hostile behavior that *does* require
viewing of the results or "return packets" is a lot more complex [5]. For
the sake of brevity, we will only cover possible techniques that will help
hide the attacker's source address and/or use maximum stealth techniques,
including theoretical ones such as traffic pattern masking and upstream
sniffing [6].

We will divide up the more complex scenario of "the attacker seeing the 
results" into three categories - enumeration of targets, host and host 
service(s) identification, and actual penetration - and outline each 
category.

Enumeration: This is the act of determining what hosts are actually 
available for potential probing and attack. 

Enumeration example 1, figure 2:

*----------* *---------*
| | NMap forged ICMP_ECHO packets | |
| attacker |--------------------------------->| targets |
| | ---------------------| |
*----------* / *---------*
| /
ngrep target replies to forged source
| /
<--------------------

This first enumeration example is fairly simple - by sending forged 
ICMP_ECHO packets, the attacker sniffs the replies destined for the forged
source address. This can be readily accomplished using tools such as NMap
[7] and ngrep [8] as long as the attacking host is upstream from the
target network.

Enumeration example 2, figure 3:
*---*
| f |
| i |
| r |
*----------* | e | *---------*
| | forged ICMP_TSTAMP packets | w | | |
| attacker |-----------------------------| a |-->| targets |
| | ----------------| l |---| |
*----------* / | l | *---------*
| / *---*
snort target replies to forged source(s)
| /
<--------------------

This second example of enumeration is also fairly simple. Assuming the 
firewall is blocking ICMP_ECHO, we decide to send ICMP_TSTAMP packets with
forged addresses. Instead of ngrep in this example, we use an IDS product
called snort [9]. Snort is configured to capture the ICMP_TSTAMPREPLY
packets. Once again in this example we are assuming the attacking host is
upstream of the target network.

Now we move on to host and host service identification.

Host/Host Services Identification example 1, figure 4:

*---*
| f |
| i |
| r |
*----------* NMap forged source address | e | *---------*
| | with source port of 80 | w | | |
| attacker |-----------------------------| a |-->| targets |
| | ----------------| l |---| |
*----------* / | l | *---------*
| / *---*
snort target replies to forged source
| /
<--------------------

In figure 4, port and OS identification scans are done against targets 
behind a firewall by taking advantage of the fact that SYN/ACKs with a 
source port of 80 are allowed through. Mistaken as web traffic, the IDS 
and the firewall are bypassed and the targets are scanned. Using a list of
valid hosts attained via host enumeration techniques, only valid targets 
are scanned. By forging the source address, it helps hide the true source
of the scan. Reply packets are recovered via snort.

Figure 4 outlines a poorly configured firewall (or even a simple packet 
filtering ruleset on a router), so we will look at something a little more
sophisticated.

Host/Host Services Identification example 2, figure 5:

*---------*
| |
/->| master |-----------
| | | \
| *---------* |
| | | |
| | v v
| *---------* *---------*
| | | | | 
| | client1 |-- | client2 |--
| | | \ | | \ *---*
| *---------* \ *---------* \ | f |
| | \ \ | i |
| v \ \ | r | *---------*
| *---------* \ -----| e |-->| |
| | | ----------------------| w |-->| various |
| | client3 |-----------------------------| a |-->| targets |
| | | ----------------| l |---| |
| *---------* / | l | *---------*
| / *---*
| *---------* target replies to forged sources
| | | /
\->| sniff |--------/ 
| | /
*---------* /
/
<------------------
/
<----------------
/
<--------------

Figure 5 is one of the more complex models. This involves multiple clients
directed by a master, performing slow methodical port scans of the target
network. All of the port scans are using forged addresses from trusted
sources whose IP addresses are allowed through the firewall. An upstream
sniffer captures the replies. The clients and sniffer could even reside on
hosts belonging to the trusted sources, and perhaps even be allowed
through a VPN. This type of scenario is rather complex due to the lack of
custom software need to perform the scans, although various existing
products could be modified to handle most of the elements involved.

When discussing actual attacks, in particular distributed attacks, the 
best path into a network is the path you know works. Therefore the main 
line of attack will more than likely involve Figures 4 and 5, with a few 
possible modifications.

Actual Penetration, example 1, figure 6:

*---*
| f |
| i |
| r |
*----------* Sploit to remotely set up a | e | *---------*
| | reverse telnet via port 25 | w | | |
| attacker |-----------------------------| a |-->| targets |
| | ----------------| l |---| |
*----------* / | l | *---------*
/ *---*
Return of reverse telnet 
*----------* output on port 80
| | /
| listener |<-------
| |
*----------*

In this example an exploitable sendmail daemon was found on a system that
didn't really need sendmail running, and since sendmail was running as
root, a reverse telnet was set up [10].

Actual Penetration, example 2, figure 7:

*----------*
| |
/->| attacker |----------
| | | \
| *----------* |
| | | |
| | v v
| *---------* *---------*
| | | | | 
| | client1 |-- | client2 |--
| | | \ | | \ *---*
| *---------* \ *---------* \ | f |
| | \ \ | i |
| v \ \ | r | *---------*
| *---------* \ -----| e |-->| |
| | | ----------------------| w |-->| various |
| | client3 |-----------------------------| a |-->| targets |
| | | ----------------| l |---| |
| *---------* / | l | *---------*
| / *---*
| *---------* /
| | | /
\->| sniff |--------/
| results | /
| | /
*---------* /
/
<-----------------
/
<---------------
/
<-------------

In figure 7 the attacker directs attacks against targets via the clients 
to try to compromise various daemons to run arbitrary commands as root.
Results are sent to forged IP addresses, but a sniffer captures these
results. In case of logging and host-based IDS, the attacker is not
suspected, the owners of the forged IP addresses are.


--------< Patterns of Attack

At first glance, it may seem easy to defend against the onslaught of 
attacks, probes, and enumeration techniques. But it must be remembered 
that byte pattern recognition or traffic on certain source and destination
ports can easily be changed by the attacker. A lot of the techniques
outlined above can and will use encryption, and can potentially operate
over TCP, UDP, and/or ICMP, and can use different source and destination
ports.

In particular let's look at figures 5 and 7 above. These are complex 
scenarios, but could conceivably be done especially from a trusted host or
network. The VPN is often considered a security tool, and its use is 
considered adequate in helping secure a channel. But all a VPN does is 
ensure that a communications link can be established with the 
communications link itself being somewhat secure. The end points are 
critical - if you have established a VPN with a business partner of field 
office, you are only as secure as that remote site's computer systems.
Does your business partner or remote office keep updated and patched as
often as you do? Does your vendor have a security policy in place? Have
you even asked your business partner or vendor these questions?

It is also possible that during upstream sniffing sessions that an 
attacker could determine that due to relationships with certain vendors 
you may have rules through the firewall entirely based upon IP address
and/or hostname. These can and will be exploited if uncovered, either
through the trusted vendor or by spoofing and sniffing as outlined in the
above models.

However we *can* look at the above attack models and make some general
determinations.

- All attacks involve possible covert communication methods between the
attacker and the attacking/probing device.
- When possible, traffic is disguised to look like normal network 
traffic.
- When possible, IP addresses will be spoofed to mask the location of
attacker, attack clients, probing machines, and/or to implicate a third
party in case of accidental discovery.


--------< Primary Defensive Techniques

Let's first look at the easy-to-do defenses that can be put in place.

First off we need to eliminate as many unwanted forms of traffic through
the firewall as possible. This can be done by denying all traffic, and
very carefully opening things up. Sometimes by clicking on a pretty icon
in the firewall GUI control software labelled "DNS" or "Mail" we feel we
are controlling the environment, but this may be opening up ports 53 and
25 to the world. If attackers learn this, they could use these openings to
help set up covert channels. Ensure that when allowing public traffic into
your network (DNS, SMTP, HTTP, FTP) that you do *not* allow these forms of
traffic into your networks without limits. Check to make sure that turning
on DNS in the firewall did not open up TCP and UDP port 53 to every device
on your network.

All public boxes, such as your Web, FTP, and mail servers should reside in
a separate network (appropriately referred to as a "dead zone" or DMZ).
These boxes should not be allowed to initiate network conversations with
computers inside the internal network - if compromised, these boxes will
be used as stepping stones to the internal network across all channels you
leave open.

All Internet-connected boxes should not have compilers on them, should 
have as few services running as possible, and should have fairly 
sophisticated modifications to prevent compromise (see the Host
Recommendations section below).

Make sure management channels and ports are closed or at least secured. 
For example, does turning on remote management to your Checkpoint Firewall
automatically open up port 256? Make sure you've set things up correctly.
Is SNMP closed from the outside? From the DMZ?

While it is my opinion that all computers should be secured as adequately 
as possible, if you are on a limited budget, or you must prioritize what 
boxes get secured first, secure them in this order - firewall, public 
boxes in the DMZ, internal servers, workstations.

Obviously keeping the boxes themselves as updated as possible is the most
desired thing - the latest patches and tweaks - as this will make your
systems less of a potential target or launch point for further attacks.


--------< ICMP Defenses

Since a lot has been written about TCP/UDP rules for a firewall, but 
little has been written about ICMP, I've decided to expand upon the 
philosophy of handling ICMP at the firewall.

It is considered "bad form" by some Internet pundits to turn off ICMP 
entirely. ICMP was originally developed to *help* networks, and is often 
used as a diagnostic tool by WAN administrators. But today the various 
inadequacies of ICMP are being used and abused in ways not originally 
intended by supporters of RFC 792, and certain strategies need to be 
implemented to make things a little safer. Therefore we need to try and 
contain as much of the abuse as possible without shooting ourselves in the
foot.

Most Internet-connected sites block inbound ICMP Echo to their internal 
networks, but do not block most everything else. This will still leave the 
site inadequately protected. Inbound ICMP Timestamp and Information 
Request will respond if not blocked, and both can be used for host 
enumeration across a firewall that allows such traffic through. Even 
forging packets with illegal or bad parameters can generate an ICMP 
Parameter Problem packet in return, thereby allowing yet another method of
host enumeration.

One of the common methods used to issue commands from a master to clients 
(especially if the clients are behind a firewall) in a stealth manner is 
to use ICMP Echo Reply packets as the carrier. Echo Replies themselves 
will not be answered and are typically not blocked at the firewall. An 
excellent early example of this type of communication can be found in Loki 
[11]. Loki was also pilfered from (at least in concept) during the 
development and evolution of TFN [1] as communications use Echo Reply 
packets between client and server pieces, which are also encrypted.

As techniques are developed to thwart specific tools, simple permutations 
will continually bypass defenses. Therefore it is recommended that all 
non-essential ICMP traffic be eliminated from traversing the Internet. 
Here is a chart I've devised (see [12] for more details) that defines ICMP 
traffic types and a bit of info about each. While all ICMP can be used for 
tunneling, some ICMP types are better suited than others for tunneling. 
Obviously the larger the data tunnel, the better (if you wish to send a 
lot of data), but as little as 2 bytes can be used to issue commands via a
command structure. A "good" tunnel is one where the ICMP type is a little
less forgiving regarding free-form data insertion into the data fields of
the ICMP packets. 

ICMP Chart, figure 8:

ICMP Target Host "Good" Max Size Block at
Type Description Replies? Tunnel? of Tunnel Firewall
---- -------------- ----------- ------- --------- --------
0 Echo Reply No Yes 64K Limited
3 Destination No No 8+ bytes No
Unreachable
4 Source Quench No No 8+ bytes Limited
5 Redirect No No 8+ bytes Limited
8 Echo Yes Yes 64K Limited
11 Time Exceeded No No 8+ bytes Limited
12 Parameter Prob No Yes 8 bytes Limited
13 Timestamp Yes Yes 8 bytes Yes
14 Timestamp Reply No Yes 12 bytes Yes
15 Info Request Yes Yes 2 bytes Yes
16 Info Reply No Yes 2 bytes Yes
17 Address Request No* No 4 bytes Limited
18 Address Reply No No 4 bytes Limited

* Typically an Address Request is answered by a gateway, but may be 
answered by a host acting in lieu of a gateway.

First we have to approach the entire "ICMP limiting" problem in terms of
both inbound and outbound. To cut some of the communication links in
models outlined above we have to "contain" ICMP. ICMP Echo does come in
handy for verifying that remote sites are up, but outbound Echo should be
limited to support personnel (okay) or a single server/ICMP proxy
(preferred).

If we limit Echo to a single outbound IP address (via a proxy), then our
Echo Replies should only come into our network destined for that 
particular host.

Redirects are typically found in the wild between routers, not between
hosts. The firewall rules should be adjusted to allow these types of ICMP
only between the routers directly involved in the Internet connection that
need the information. If the firewall is functioning as a router, it is
quite possible that Redirects can be completely firewalled without adverse
effects, both inbound and outbound.

Source Quench packets are generated when a large amount of data is being 
pushed toward a host or router, and the host or router wishes to tell the 
sender to "slow things down". This is typically seen during streaming
uploads of data to a host, and can be generated by a router along the way
or via the target host itself. If the hosts inside the network can only
upload to a host on the Internet via FTP, then it is possible that the
only source of legitimate Source Quench packets will be destined toward
the FTP proxy, and all other Source Quench traffic can be dropped.

Time Exceeded packets are an interesting animal. There are two types of 
Time Exceeded packets - code zero for Time To Live (TTL) timeouts, and
code one for fragmented packet reassembly timeout. 

The TTL is a value initialized and placed in the TTL field of a packet 
when it is first created, and as the packet crosses a network hop its TTL
counter is decremented by one. Starting with a TTL of 64, once the 64th
hop is crossed the router that decremented the TTL to zero will drop the
packet and send a Time Exceeded back to the sender with a code of zero,
indicating the maximum hop count was exceeded.

In the case of fragmented packet reassembly timeout, when a fragmented 
datagram is being reassembled and pieces are missing, a Time Exceeded code
one is set and the packet is discarded. It is possible to perform host
enumeration by sending fragmented datagrams with missing fragments, and
waiting for the Time Exceeded code one to alert the sender that a host
existed at the address, so care must be taken with the handling of these
types of packets.

It is recommended that by proxying all outbound traffic, inbound ICMP 
traffic should come back through the firewall to the proxy address. This 
at least limits Time Exceeded packets to a single inbound address. But it 
is possible to block Time Exceeded packets. Most applications will have an
internal timeout that is not dependent upon receiving a Time Exceeded 
packet, some applications may still be relying upon receiving one. YMMV on
this one. Block it unless too many critical internal applications are 
affected.

The ICMP Parameter Problem packets are sent whenever an ICMP packet is 
sent with incorrect parameters that will cause the packet to be discarded. 
The host or router discarding the host sends a Parameter Problem packet 
back to the sender, pointing out the bad parameter. By sending illegally 
constructed ICMP packets to a host, you can cause the host to reply with a
Parameter Problem packet. Obviously if the type of illegally constructed 
ICMP is allowed through the firewall, you can enumerate hosts.

There is no reason to allow inbound or outbound Timestamp, Timestamp
Reply, Info Request and Info Reply packets across the firewall. Whatever
value they might have should be limited to the internal network only, and
should never cross onto the open Internet. The same may be said of Address 
Requests and Address Replies, as there is no real reason for a host to be
aware of the destination's IP Address mask to send the packet. Address 
Requests and Replies are intended to assist diskless workstations booting 
from the net to determine their own IP address mask, especially if there 
is subnetting going on, therefore there is no reason to pass this traffic 
across a firewall (in fact, routers adhering to RFC 1812 will not forward 
on an Address Request to another network anyway).

The general philosophy here is that only publicly addressable servers 
(such as web, e-mail, and FTP servers), firewalls, and Internet-connected 
routers have any real reason to talk ICMP with the rest of the world. If 
adjusted accordingly, virtually all stealth communication channels that
use ICMP, inbound or outbound, will be stopped.


--------< Host Recommendations

What are some good precautions we can use on hosts connected to the 
Internet? We will not cover Microsoft offerings here, but will assume the
we will be using only open sourced operating systems on hosts we have that
are addressable from the Internet (Web, SMTP, FTP, etc). All machines 
serving the public via the Internet should be locked down. Here is a 
recommended list of tactics to help protect the machines exposed to the
Internet.

- Isolate all public servers to a DMZ.
- Each offered service should have its own server. For example, if your
public services are email and web, do not try to save money and run both
on the same server. Use separate servers.
- If using Linux (recommended) you can use any one or several of the 
"buffer overflow/stack execution" patches and additions to prevent most 
(if not all) local and remote buffer overflows that could lead to root 
compromise. Solar Designer's patch [13] is highly recommended as it 
includes additional security features, such as secured
- Instead of SSH, use Secure Remote Password (SRP) [14]. SRP offers PAM
compatibility, drop-in replacement for telnet and FTP daemons, encrypted
telnet and FTP sessions, and defeat of zero knowledge attacks. One great
advantage to SRP is that only enough material to determine that you know
the password is stored in the password file, so even if the password file
is captured by an intruder it cannot be cracked. You can even have
passwords up to 128 characters in length!
- Limit access to those SRP-enabled telnet and FTP daemons to internal
addresses only, and insist that only SRP-enabled clients can talk to
them. If you must run regular FTP for public access (such as anonymous
FTP) run SRP FTP on a different port. 
- Use trusted paths. Only allow execution of root-owned binaries that 
are in a directory owned by root that is not world or group writable. To
enforce this you can modify the kernel if need be [15].
- Use the built-in firewalling capabilities. By turning on firewall 
rules you can often take advantage of the kernel's handling of state 
tables. The state table keeps track of IP addresses and port connections. 
If a packet is received that is *not* a SYN packet and *not* part of an 
existing conversation, drop the packet. This may require kernel 
modification to support it [16].
- Use some form of port scan protection. This can be done either via a
daemon on Linux [17] or via kernel modifications [16].
- Use Tripwire [18] or an equivalent to help detect modifications to
important files. Version 2.2.1 for Linux is freeware, other versions are
not.


--------< IDS Recommendations

Since many of the methods to defeat network-based IDS are still applicable 
to most commercial IDS products available (see [2], [3], and [4] for 
details), it is recommended using an IDS that at least can reassemble or 
at least detect fragmented datagram packets. This limits you to Snort [9], 
NFR, Dragon, and BlackIce [19], with Snort in its current version only
able to detect very small fragment sizes of packets. Only Dragon can
handle fragmented packet reassembly at high network speeds with lots of
traffic.

If you are on a budget, you can limp by with Snort, although any serious 
or high-traffic site is going to require Dragon to handle the load. The 
next question is - what should I watch for? Here is a partial list:

- Be sure to include all of the existing rules, including new rules for
some of the distributed DoS attacks (see [1] for details on those 
attacks).
- Since much of ICMP will be blocked if the ICMP Recommendations section
is followed, numerous opportunities for IDS triggers exist. Any inbound or
outbound ICMP packets that would normally be blocked can be triggered
upon.
- *Any* network traffic you have firewalled off can be a potential IDS
trigger. Examine what you are blocking and why, and consider adding IDS
rules to look for such packets.
- If your IDS supports detection of attacks over long periods of time 
(for example, a port scan) be sure to not exclude trusted hosts you might
be allowing through the firewall. This includes VPNs. Spoofed packets from
those trusted sites might *look* like normal traffic, but could possibly
be probes or attacks.
- If you can train any user of ping to use small packet sizes when 
pinging hosts (such as 'ping -s 1 target.address.com'), set your IDS to
look for Echo and Echo Replies with packets larger than 29 bytes.


--------< Conclusions

By securing the hosts, limiting the channels of communication between 
nefarious elements, and adjusting firewall and IDS rules, most of the 
network attacks outlined here (real and theoretical) can be defeated. A
side effect of implementing these recommendations is that not only are
distributed attack models stopped, but overall security is greatly
enhanced. Full frontal attacks are easily detected and can be quickly
avoided.

--------< Acknowledgements

I would thank the BindView RAZOR team for their support during the writing
of this paper. Numerous times I asked the team questions and received
answers that opened up new ideas. Their help was invaluable.

I'd also like to thank my wife and kids for being patience while I toiled
away for hours over the computer. There is nothing like support from home.


--------< References

Here are some articles and papers related to the subject presented here.

--< [1] David Dittrich (dittrich@cac.washington.edu) provided detailed
analysis of three distributed denial of service tools found in the wild.
"The DoS Project's "trinoo" distributed denial of service attack tool"
https://staff.washington.edu/dittrich/misc/trinoo.analysis;
"The "Tribe Flood Network" distributed denial of service attack tool"
https://staff.washington.edu/dittrich/misc/tfn.analysis;
The "stacheldraht" distributed denial of service attack tool
https://staff.washington.edu/dittrich/misc/stacheldraht.analysis.

--< [2] Thomas H. Ptacek and Timothy N. Newsham wrote an enormously
influential paper discussing IDS avoidance, with many of the documented
techniques still not corrected by commercial IDS vendors since the paper's 
debut in January of 1998.

"Insertion, Evasion, and Denial of Service: Eluding Network Intrusion
Detection"
https://www.clark.net/~roesch/idspaper.html

--< [3] Rain Forest Puppy (rfp@wiretrip.net), author of numerous advisories,
wrote a tool called whisker, which is a CGI vulnerability scanner. RFP
wrote up this paper explaining the techniques he outlined in whisker,
can could be applied to other protocols besides HTTP.

"A look at whisker's anti-IDS tactics"
https://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html

--< [4] Greg Shipley did a review for Network Computing of intrusion detection
systems, both host and network based. The results were interesting enough
to influence some of the thoughts in this paper as the article was much
more interesting than one would expect for a trade magazine product review.

"Intrusion Detection: Take Two"
https://www.networkcomputing.com/1023/1023f1.html

--< [5] Simple Nomad (thegnome@nmrc.org) presentations to SANS covered possible
network enumeration, host identification, and port scanning techniques using
various adaptations of off-the-shelf products.

"Network Cat and Mouse", SANS Network Security '99, New Orleans
https://www.sans.org/
"The Paranoid Network", to be presented at SANS 2000, Orlando, FL

--< [6] Simple Nomad (thegnome@nmrc.org) white paper that expanded on the ideas
originally developed and presented in [5].

"Traffic Pattern Duplication to Avoid Intrusion Detection", 
To be released soon.

--< [7] Fyodor (fyodor@dhp.com) has written NMap, considered to be one of the
best host and host service enumeration tools available, loaded with tons of
features.

NMap, https://www.insecure.org/nmap/

--< [8] Jordan Ritter (jpr5@darkridge.com, jpr5@bos.bindview.com) has written a 
handy tool to sniff and grep through network traffic, appropriately called ngrep.

ngrep, https://www.packetfactory.net/ngrep/

--< [9] Martin Roesch (roesch@clark.net) has written a great IDS called snort
that is simple to use, fast, and free. 

snort, https://www.clark.net/~roesch/security.html

--< [10] Stuart McClure, Joel Scambray, & George Kurtz have written a book
entitled "Hacking Exposed" which uncovers numerous attacker techniques. The
reverse telnet technique is detailed in Chapter 13, page 382-3.

"Hacking Exposed", ISBN 0-07-212127-0, 1999
https://www.hackingexposed.com/

--< [11] Michael D. Schiffman wrote a white paper that illustrate a method 
for using ICMP to establish a covert communications method across a network, 
including across a firewall. Jeremy Rauch assisted Schiffman in developing
proff of concept software, and Schiffman followed it up with a later article
that covered implementation issues. Both are available at Phrack's web site at
https://www.phrack.com/.

"Project Loki: ICMP Tunnelling", Phrack 49, File 6 of 16, 1996.
"LOKI2 (the implementation)", Phrack 51, File 6 of 17, 1997.

--< [12] RFC 792, RFC 950, RFC 1122, RFC 1123, and RFC 1812, specifically 
section 4.3 of RFC 1812 on the handling of ICMP by routers.

--< [13] Solar Designer's Linux kernel patch is available from
https://www.openwall.com/linux/.

--< [14] Thomas Wu developed Secure Remote Password (SRP) while attending
Stanford. It touts a number of unique features, including defeating zero
knowledge attacks and even protects against password recovery from the
password file.

SRP, https://srp.stanford.edu/srp/

--< [15] Michael D. Schiffman wrote two articles for Phrack which cover
trusted path execution - one for Linux and one for OpenBSD. While the code
will not cleanly patch current kernels, it is a good place to start. Visit
https://www.phrack.com/.

"Hardening the Linux Kernel", Phrack 52, File 6 of 20, 1998.
"Hardening OpenBSD for Multiuser Environments", Phrack 54, File 6 of
12, 1998.

--< [16] Simple Nomad pulled together several security patches for 2.0.3x
kernels and developed a single patch. Two of the included items show how
to make use of the built-in state table and kernel-level port scan detection.

nmrcOS kernel patches, https://www.nmrc.org/nmrcOS/

--< [17] Solar Designer's scanlogd daemon detects multiple port connections
from a single address. NMap can easily defeat this with slower scans but it
is still useful.

scanlogd, https://www.openwall.com/scanlogd/

--< [18] Tripwire can be obtained from Tripwire, Inc. at 
https://www.tripwiresecurity.com/. The Linux version is free.

--< [19] Commercial IDS products mentioned here can be obtained via the
following vendors:

NFR IDA from NFR, https://www.nfr.net/
BlackIce from Network Ice Corp., https://www.networkice.com/
Dragon from Network Security Wizards, https://www.securitywizards.com/

--------< EOF