ExpressWay Trickle Brute Force

[RITR]

Someone was (I blocked it manually from net fw) slowly trying different SIP URLs looking for valid ones. It was about one try every 30 - 90 seconds. I'm not seeing related events in the ExpressWay-Core so I'm assuming it blocked it. We only use it for Webex trunking and MRA. Is the 404 coming simply from the Edge or is actually checking something and returning a real "[user] not found"? My concern is I don't want it to get a valid response if it stumbles across a valid URL.

Log snippet:

- datetime	tvcs: Event="Call Rejected" Service="SIP" Src-ip="[hackerip]" Src-port="29777" Src-alias-type="SIP" Src-alias="sip:[ourdomain].com" Dst-alias-type="SIP" Dst-alias="sip:[johndoe]@[ourdomain].com" Call-serial-number="8e35802a-bb6f-463d-913b-d0fda2ea455f" Tag="1ff5e867-a566-4e1a-8b0c-b230c7bf5773" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="datetime"
- datetime	tvcs: Event="Search Completed" Reason="Not Found" Service="SIP" Src-ip="[hackerip]" Src-port="29777" Src-alias-type="SIP" Src-alias="[ourdomain].com" Dst-alias-type="SIP" Dst-alias="sip:[johndoe]@[ourdomain].com" Call-serial-number="8e35802a-bb6f-463d-913b-d0fda2ea455f" Tag="1ff5e867-a566-4e1a-8b0c-b230c7bf5773" Detail="found:false, searchtype:INVITE, Info:Policy Response" Protocol="TCP" Level="1" UTCTime="datetime"
- datetime	tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="[ourdomain].com" Dst-alias-type="SIP" Dst-alias="sip:[johndoe]@[ourdomain].com" Call-serial-number="8e35802a-bb6f-463d-913b-d0fda2ea455f" Tag="1ff5e867-a566-4e1a-8b0c-b230c7bf5773" Detail="searchtype:INVITE" Level="1" UTCTime="datetime"
- datetime	tvcs: Event="Call Attempted" Service="SIP" Src-ip="[hackerip]" Src-port="29777" Src-alias-type="SIP" Src-alias="sip:[ourdomain].com" Dst-alias-type="SIP" Dst-alias="sip:[johndoe]@[ourdomain].com" Call-serial-number="8e35802a-bb6f-463d-913b-d0fda2ea455f" Tag="1ff5e867-a566-4e1a-8b0c-b230c7bf5773" Protocol="TLS" Auth="NO" Level="1" UTCTime="datetime"

[Jonathan Schulenberg]

That would depend on your Search Rules. If they match on Exp-E and point at a Traversal  Zone it will make it to Exp-C. Likewise if there is a match on Exp-C it will hit the CUCM Neighbor Zone and be evaluated against the Incoming CSS on the SIP trunk.

You might be able to use a CPL rule on Exp-E to block it right from the start. What SIP calls are you receiving from Webex though? Edge Audio and legacy Hybrid Calling are capable of using MTLS and therefore matching the Webex zone at ingress, allowing you to distinguish them from generic unauthenticated calls in the blocking CPL rule. SIP outdial/call-my-video-system can’t use MTLS though; you’ll have to let those calls through the CPL rules.

[RITR]

Our Webex usage is Edge Audio with MTLS, no video or SIP outdial. So with a CPL in place they will not be able to ascertain valid URLs through brute force? With the below in place on the Edge, all functionality of ours continue to work.

[Jonathan Schulenberg · Accepted solution]

That should do it. CPL is the first call processing step, before Transforms or Search Rules. If a call is blocked by CPL rule it never made it past Exp-E. You could confirm by looking at the search history; it should stop at the CPL rule.

[RITR]

Ok. Since the net fw is blocking that specific attacker I'll have to keep an eye on the logs for further events. Thanks for the help.