07-29-2010 11:40 AM - edited 03-11-2019 11:18 AM
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
07-29-2010 06:57 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide