<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: SIP Register Message Brute Force Attack in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/428864#M94801</link>
    <description>&lt;P&gt;That is good question.&amp;nbsp; In order for a session to be seen/evaluated by the FW, we would agree that there needs to be a 3 way handshake between Client and Server (responder).&amp;nbsp; So, the FW is seeing multiple of these requests coming in from the CLIENT.&amp;nbsp; We (the FW) are see these attempts.&amp;nbsp; Why are you clients sending these?&amp;nbsp; We do not know, and I believe you may not know.&amp;nbsp; Only the developer of the SIP application can determine how and why their application is sending out the packets.&amp;nbsp; I have so many crazy (non protocol following) applications. For example... when Chrome users go out to the Internet, why does Chrome perform a host sweeping technique (communicating to various servers on port 80/443) rather than connect to a single server?&amp;nbsp; This is due to the application and we (the FW/security guys) have the visibility to see unusual patterns of traffic, due to developer's application.&amp;nbsp; So.. I guess you will need to read/research/contact the SIP application company to see why they do the things they do.&amp;nbsp; (sorry, wish I could be more helpful)&lt;/P&gt;</description>
    <pubDate>Tue, 24 Aug 2021 16:46:38 GMT</pubDate>
    <dc:creator>S.Cantwell</dc:creator>
    <dc:date>2021-08-24T16:46:38Z</dc:date>
    <item>
      <title>SIP Register Message Brute Force Attack</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/427217#M94586</link>
      <description>&lt;P&gt;Can anyone suggest why this alerts keep triggering on regular basis. Internal connection - destination port is 5060. Observed multiple SYN/FIN connection.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;SIP Register Request Attempt(33592&lt;/STRONG&gt;&lt;SPAN&gt;)&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;SIP clients typically use TCP or UDP on port numbers 5060 or 5061 for SIP traffic to servers and other endpoints. Port 5060 is commonly used for non-encrypted signaling traffic whereas port 5061 is typically used for traffic encrypted with Transport Layer Security (TLS).&lt;/SPAN&gt;&lt;SPAN&gt;A SYN-FIN flood is a DDoS attack designed to disrupt network activity by saturating bandwidth and resources on stateful devices in its path. By continuously sending SYN-FIN packets towards a target, stateful defenses can go down (In some cases into a fail open mode).&lt;/SPAN&gt;&lt;SPAN&gt;On checking logs in DT,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;# SF Normal establishment and termination.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;# RSTR Established, responder aborted.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;# SH Originator sent a SYN followed by a FIN, we never saw a SYN ACK from the responder (hence the connection was "half" open).&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;# OTH No SYN seen, just midstream traffic (a "partial connection" that was not later closed).&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 17 Aug 2021 03:02:04 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/427217#M94586</guid>
      <dc:creator>MUNNA2117</dc:creator>
      <dc:date>2021-08-17T03:02:04Z</dc:date>
    </item>
    <item>
      <title>Re: SIP Register Message Brute Force Attack</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/428864#M94801</link>
      <description>&lt;P&gt;That is good question.&amp;nbsp; In order for a session to be seen/evaluated by the FW, we would agree that there needs to be a 3 way handshake between Client and Server (responder).&amp;nbsp; So, the FW is seeing multiple of these requests coming in from the CLIENT.&amp;nbsp; We (the FW) are see these attempts.&amp;nbsp; Why are you clients sending these?&amp;nbsp; We do not know, and I believe you may not know.&amp;nbsp; Only the developer of the SIP application can determine how and why their application is sending out the packets.&amp;nbsp; I have so many crazy (non protocol following) applications. For example... when Chrome users go out to the Internet, why does Chrome perform a host sweeping technique (communicating to various servers on port 80/443) rather than connect to a single server?&amp;nbsp; This is due to the application and we (the FW/security guys) have the visibility to see unusual patterns of traffic, due to developer's application.&amp;nbsp; So.. I guess you will need to read/research/contact the SIP application company to see why they do the things they do.&amp;nbsp; (sorry, wish I could be more helpful)&lt;/P&gt;</description>
      <pubDate>Tue, 24 Aug 2021 16:46:38 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/428864#M94801</guid>
      <dc:creator>S.Cantwell</dc:creator>
      <dc:date>2021-08-24T16:46:38Z</dc:date>
    </item>
    <item>
      <title>Re: SIP Register Message Brute Force Attack</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/428866#M94803</link>
      <description>&lt;P&gt;To add to my statement.&amp;nbsp; If you want, just modify that ID from alert to ALLOW, and commit.&amp;nbsp; now, you will not see those alerts (but you also have not determined why.... )&lt;/P&gt;</description>
      <pubDate>Tue, 24 Aug 2021 16:47:44 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/428866#M94803</guid>
      <dc:creator>S.Cantwell</dc:creator>
      <dc:date>2021-08-24T16:47:44Z</dc:date>
    </item>
    <item>
      <title>Re: SIP Register Message Brute Force Attack</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/428938#M94812</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/190846"&gt;@MUNNA2117&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;Just a suggestion, but do you have a Message Waiting Indicator (MWI) light on your phones? This sounds a lot like MWI registration which in general is pretty poorly implemented across most vendors. Easy enough to work around, but I would guess that this is due to that MWI registration process.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 24 Aug 2021 21:10:43 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/sip-register-message-brute-force-attack/m-p/428938#M94812</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2021-08-24T21:10:43Z</dc:date>
    </item>
  </channel>
</rss>

