[cisco-voip] untraceable connection attempt?

[Brian Meade]

There's a bunch of monitoring tools out there that do a port scan then
probe to make sure those ports stay open.

On Wed, Dec 20, 2017 at 10:56 AM, Wes Sisk (wsisk) <wsisk at cisco.com> wrote:

> +1. I have seen syn scan or TCP half open cause alerts with no ip, no
> mac.
>
> you can get some insight if this happening using the workaround for
> CSCsw73304    CLI show open ports to show ports in SYN_RECV
>
> -wes
>
> On Dec 20, 2017, at 7:47 AM, Dave Goodwin <Dave.Goodwin at december.net>
> wrote:
>
> Any chance there’s an active vulnerability scanning machine on the
> network? With SYN scanning (half-open scans), it only sends a SYN packet to
> each port and never fully opens a TCP connection. I’m wondering whether
> this scenario might cause CallManager to report this incomplete
> registration alarm while not reporting the source IP - since the TCP
> connection was never considered to be established.
>
> I’d like to try for myself a SYN scan of port 2000 using nmap to see if I
> can produce this alarm.
>
> On Wed, Dec 20, 2017 at 12:25 AM Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>
>>
>> Also, definitely not exceeded number of registered devices. Especially
>> not on the node where this alarm was coming from.
>>
>> Sent from my iPhone
>>
>> On Dec 20, 2017, at 12:01 AM, Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>> Yeah it’s tough for sure, because the error is from the device failing to
>> register, before providing any identifying information about itself ... so
>> next to impossible to find from the mothership point of view.
>>
>> You haven’t by chance exceeded the
>> “Maximum Number of Registered Devices” threshold for that node have you
>> (CM Service Parameter)? You’d likely have other alarms if you did though.
>>
>> If it’s a small cluster scenario where you can reasonably access all the
>> phones and access switches; I’d do a registration audit.
>>
>> Could be as simple as a non-Cisco sip device that got plugged into a
>> access port with the admin vlan and tried to use CUCM as its registrar but
>> failed miserably.
>>
>> I’m guessing that isn’t your scenario; my thoughts, if it were me, would
>> be to clear it and see if it comes back. Very possible that it’s an innocuous
>> event that just sent some packets at the wrong time :).
>>
>> Thanks,
>>
>> Ryan
>>
>> On Dec 19, 2017, at 11:39 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>>
>>
>> First time I think I've ever seen this. Especially with no MAC or IP
>> addr.
>>
>> Only one alert.
>>
>> But we've recently started allowing Jabber connections from our data
>> VLANS.
>>
>> I'd hate for it to be the beginning of something larger.
>>
>> Sent from my iPhone
>>
>> On Dec 19, 2017, at 11:35 PM, Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>> Could also be network connectivity among a lot of things but more often
>> than not, bouncing CM service seems to fix if this is a recurring alarm. If
>> it’s a one time alarm you’ve not seen before; likely legitimately referring
>> to a device.
>>
>> If you’ve recently added any new devices, check network connectivity /
>> verify they are all registered. Could also be a bad device that is no
>> longer working but still attempting a registration ... sort of.
>>
>> -Ryan
>>
>> On Dec 19, 2017, at 11:22 PM, Ryan Huff <ryanhuff at outlook.com> wrote:
>>
>> Sounds like you should schedule a bounce of the CM service for this
>> node.
>>
>> Have a read here for more detail: https://www.cisco.com/
>> c/en/us/td/docs/voice_ip_comm/cucm/err_msgs/8_x/ccmalarms851.html
>>
>> Thanks,
>>
>> Ryan
>>
>> On Dec 19, 2017, at 11:11 PM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>>
>> An endpoint attempted to register but did not complete registration
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20171222/950d0ba5/attachment.html>