Denny Reiter wrote:           (written on 08/28/03 at 07:46)
]
]We experienced the packet loss with 9.0.9.  Turning off the route
]cache or limiting it to 15000 helped keep the TNTs responsive on
]their own subnet, but copious rebooting and just watching a sniffer
]for infected customer's dialed up and disabling them is all we've
]come up with to help.

We have 3 TNT's, running 9.0.9 software, using the ethernet2 cards.
Approximately 2 weeks ago the TNT's started to continually lose the
ability to communicate with their local subnet.  In other
words, dialin users could connect just fine, however they couldn't
access anything on the same subnet as the TNT (there are a couple
of web servers on the same subnet).  The TNT was also not
ping-able from that subnet... but it was pingable from everywhere
else.  We attributed the problem to the massive amounts of
ICMP traffic flooding the TNT's, due to the Welchia/Nachi/Lovsan
worm.  We applied the following filter to the ethernet interface
on each of our TNT's:

new filter block-92B-ICMP
set input-filters 1 valid-entry = yes
set input-filters 1 forward = no
set input-filters 1 gen-filter offset = 16
set input-filters 1 gen-filter len = 2 
set input-filters 1 gen-filter more = yes
set input-filters 1 gen-filter mask = ff:ff:00:00:00:00:00:00:00:00:00:00
set input-filters 1 gen-filter value = value = 00:5c:00:00:00:00:00:00:00:00:00:
00
set input-filters 2 valid-entry = yes
set input-filters 2 forward = no
set input-filters 2 gen-filter offset = 23 
set input-filters 2 gen-filter len = 1 
set input-filters 2 gen-filter mask = ff:00:00:00:00:00:00:00:00:00:00:00
set input-filters 2 gen-filter value = value = 01:00:00:00:00:00:00:00:00:00:00:
00
set input-filters 3 valid-entry = yes
set input-filters 3 forward = yes
write

read ethernet {1 2 4}
set filter-name = block-92B-ICMP
write


The above filter will stop all ICMP packets that are 92 Bytes
in length, which is the signature for the worm.  The ping utilities
for windows, linux, etc, do not use 92 Byte packets, thus the above
filter only blocks the worm and does not affect other types of
ICMP.

The above filter got rid of our problem, however then we started having
a new one.  Some dialin users would be able to connect, however
after connecting they could not access anything.  A sniffer capture
showed their traffic coming out of the TNT, followed by the replies
coming back to the TNT, however the TNT was not forwarding the
replies back to the dialin user.  Approximately 10% of dialin connections
were suffering from that problem.

Although we put the above filter on the TNT ethernet interfaces,
the TNT's were still getting hammered with the ICMP packets
from dialin users who were infected.  We then decided to block
the 92 Byte ICMP packets coming in from dialin users.  We did this
in our radius profile, as follows:

         Ascend-Data-Filter = "generic in drop 23 ff 01 == more"
          Ascend-Data-Filter = "generic in drop 16 ffff 005c =="
         Ascend-Data-Filter = "ip in forward 0 0 0",
         Ascend-Data-Filter = "ip out forward 0 0 0",

That was 3 days ago, and everything has been stable ever since.
(knock on wood!!)

-Joe Pautler
 University at Buffalo
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request at bungi.com
Archives: http://www.nexial.com/mailinglists/