ASA5550 DoSed by fake UDP packets

Unanswered Question
Jul 29th, 2010

Our ASA5550 was croaking last night and eventually I figured out it was getting blasted by UDP SIP packets:

                                       From IP             To IP

1186    09:51:09.670894    58.61.157.139    149.137.1.150    SIP    Request: REGISTER sip:149.137.1.150 (wireshark)

These packets were catured in our inside interface, and came in because have SIP open to the world for some bizarre reason. The host 149.137.1.150 did not have a SIP service running on it, I don't know why it was chosen as a target. What was actually killing our ASA was not the packets themselves, but that it was setting up a connection for each incoming packet. Output from "show conn":

UDP out 127.0.0.1:5066 in 149.137.1.150:0 idle 0:00:05 flags ti
UDP out 58.61.157.139:5066 in 149.137.1.150:0 idle 0:00:05 flags ti

There were actually many more connections to 127.0.0.1 than to 58.61.157.139. Anyway, we took the 149.137.1.150 host down, cleared the arp table and put in a block for 58.61.157.139 and that took care of it.

What is strange though, is that even though 149.137.1.150 is gone and cleared from the arp table, if a remove the acces-list rule blocking 58.61.157.139 and let it start spewing SIP packets at the now-nonexistent host 149.137.1.150, it still DoSes the ASA with bogus connections:

UDP out 127.0.0.1:5066 in 149.137.1.150:0 idle 0:00:19 flags ti
UDP out 127.0.0.1:5066 in 149.137.1.150:0 idle 0:00:19 flags ti
UDP out 127.0.0.1:5066 in 149.137.1.150:0 idle 0:00:19 flags ti

There is still no arp entry for 149.137.1.150 and as far as I can tell these connections are "internal" to the ASA.

Is there a way to get the ASA to not attempt to create these connections? So far, I have been unable to capture any packets now that host 149.137.1.150 is gone. Also, I am mystified by what "149.137.1.150:0" (port 0?) could mean.

Thanks in advance,,

-W Sanders

St Marys College of California

http://wsanders.net

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Magnus Mortensen Thu, 07/29/2010 - 18:57

W,

     The port 0 connections are created bye the SIP inspection as secondary connections to the initial SIP connection. These connections are usually for some voice traffic and are build with a port of 0 indicating that they are the half-open inspection generated connections. Outside of blocking this traffic (which yout should so if that host has no SIP functionality), there isn't much we can do to prevent this at this time. I would highly suggest opening a Service-request for this one so that we can investigate the issue a bit more thoroughly. Once you open that case, please message me the SR number so I can track it.

- Magnus

Actions

This Discussion