<?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: Internal IP's hitting sinkhole policy in Next-Generation Firewall Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223386#M5666</link>
    <description>&lt;P&gt;Yes, I suggested to put the FG in transparent mode, I think they are agreeing on it, we'll see how it goes next week, we're supposed to meet with them on the next steps.&lt;/P&gt;</description>
    <pubDate>Mon, 10 Mar 2025 22:44:07 GMT</pubDate>
    <dc:creator>cdcirexx</dc:creator>
    <dc:date>2025-03-10T22:44:07Z</dc:date>
    <item>
      <title>Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223337#M5659</link>
      <description>&lt;P&gt;Hello all,&lt;/P&gt;
&lt;P&gt;We have a sinkhole configured on our PA440, and we're seeing some IP's hitting it and getting sinkholed, there's 1 endpoint that's an old NT4 legacy machine that runs on our production environment. And other ones that are windows and probably wifi endpoints like phones. I have no way of scanning the old NT4 box, and that only ran our production app made for manufacturing. The other endpoints showing on the sinkhole log that are windows 10 do have anti malware and is monitored by our mssp. Should I open a PAN support ticket and have then analyze pcaps?&lt;/P&gt;
&lt;P&gt;Thanks in advanced.&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 17:11:38 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223337#M5659</guid>
      <dc:creator>cdcirexx</dc:creator>
      <dc:date>2025-03-10T17:11:38Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223346#M5660</link>
      <description>&lt;P&gt;Hi &lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/23401"&gt;@cdcirexx&lt;/a&gt; ,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If you have Premium support on your NGFW, you could open a PANW support ticket with the Security Assurance service.&amp;nbsp; &lt;A href="https://www.paloaltonetworks.com/services/solution-assurance/premium-support" target="_blank"&gt;https://www.paloaltonetworks.com/services/solution-assurance/premium-support&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If you don't have Premium support, I do not know if they will help you.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The most common causes of DNS sinkholes in my environment have been (1) ads where a safe website redirected the user to a blocked domain, or (2) false positive such as mask.apple-dns.net which is blocked as a proxy avoidance or anonymizer.&amp;nbsp; I think it is used by iCloud.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The 1st thing that you would want to do is determine the domain requested.&amp;nbsp; If you do &lt;STRONG&gt;not&lt;/STRONG&gt; have an internal DNS server or you have a NGFW between your user and DNS server, you can see the domain under Monitor &amp;gt; Logs &amp;gt; Threat&amp;nbsp;( action eq 'sinkhole' ).&amp;nbsp; If you have an internal DNS server, the source IP address for those logs will be it.&amp;nbsp; You would check the logs on the DNS server.&amp;nbsp; If you have EDR software on the endpoint, it may also record the activity.&amp;nbsp; Otherwise, you may need a packet capture as you mentioned.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;After you determine the sinkholed domain, you will need to determine what process initiated the request.&amp;nbsp; That's even harder.&amp;nbsp; EDR software can help significantly.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Tom&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 18:01:36 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223346#M5660</guid>
      <dc:creator>TomYoung</dc:creator>
      <dc:date>2025-03-10T18:01:36Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223370#M5661</link>
      <description>&lt;P&gt;Hello Tomyoung,&lt;/P&gt;
&lt;P&gt;Thanks for the reply, yeah we do have internal DNS and they show on the threat logs sinkholing a bunch of random domain names like zxxyyrf.com, I'm sure they are malicious domains. We have a mssp that's got things in place like SIEM and XDR from Fortinet, on our DC's they installed a device called Stellar cyber and it collects a bunch of logs. They said this would show up on their systems if something does come up.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;So could those just be ads our internal clients are trying to reach out to? When I typed the ip address of the pan sinkhole, that's when I saw some endpoints reaching out to it. Our mssp thinks we have some kind of C2 that's reaching out to it's main hosts.&lt;/P&gt;
&lt;P&gt;Thanks again.&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 19:28:42 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223370#M5661</guid>
      <dc:creator>cdcirexx</dc:creator>
      <dc:date>2025-03-10T19:28:42Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223379#M5662</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;P&gt;Unless required, I would lock down those systems into their own VLAN and locked down by security policies. As well as restrict access to the internet. If the systems are that old, maybe just keep blocking the traffic or find an older scanner that can scan the systems.&lt;/P&gt;
&lt;P&gt;Regards,&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 21:39:33 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223379#M5662</guid>
      <dc:creator>OtakarKlier</dc:creator>
      <dc:date>2025-03-10T21:39:33Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223381#M5663</link>
      <description>&lt;P&gt;Hi &lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/23401"&gt;@cdcirexx&lt;/a&gt; ,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Those domains do not look good.&amp;nbsp; They do not look like ads.&amp;nbsp; &lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/27580"&gt;@OtakarKlier&lt;/a&gt; has some good ideas about quarantining those devices.&amp;nbsp; I would reach out to your SIEM/XDR MSSP for the next steps.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Tom&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 21:47:28 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223381#M5663</guid>
      <dc:creator>TomYoung</dc:creator>
      <dc:date>2025-03-10T21:47:28Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223383#M5664</link>
      <description>&lt;P&gt;Thanks to all the informative answers guys, I do have all my production machines in their own vlan and blocked from internet access. And after having a chat with our mssp, their advising to put a FG firewall in front of the PA440, I was trying to let them know if may not make a difference or might cause performance issues, they're concerned that the PA440 might have allowed the C2 malware in. Our company is working on getting our CMMC certification, so this is causing concern among upper management.&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 22:30:46 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223383#M5664</guid>
      <dc:creator>cdcirexx</dc:creator>
      <dc:date>2025-03-10T22:30:46Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223385#M5665</link>
      <description>&lt;P&gt;If it is a FG in L2 mode only for the incident, then fine.&amp;nbsp; As long as it gets them looking at the machines.&amp;nbsp; Their most pressing task is to do incident response (IR) on the machines.&amp;nbsp; If they are arguing for a permanent solution, then they need to refocus on IR.&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 22:37:27 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223385#M5665</guid>
      <dc:creator>TomYoung</dc:creator>
      <dc:date>2025-03-10T22:37:27Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223386#M5666</link>
      <description>&lt;P&gt;Yes, I suggested to put the FG in transparent mode, I think they are agreeing on it, we'll see how it goes next week, we're supposed to meet with them on the next steps.&lt;/P&gt;</description>
      <pubDate>Mon, 10 Mar 2025 22:44:07 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1223386#M5666</guid>
      <dc:creator>cdcirexx</dc:creator>
      <dc:date>2025-03-10T22:44:07Z</dc:date>
    </item>
    <item>
      <title>Re: Internal IP's hitting sinkhole policy</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1251125#M6802</link>
      <description>&lt;P&gt;&lt;A href="https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000PRR2CAO&amp;amp;lang=en_US" target="_blank"&gt;https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000PRR2CAO&amp;amp;lang=en_US&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Sun, 29 Mar 2026 18:47:24 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/internal-ip-s-hitting-sinkhole-policy/m-p/1251125#M6802</guid>
      <dc:creator>M.Pahlavanzadeh</dc:creator>
      <dc:date>2026-03-29T18:47:24Z</dc:date>
    </item>
  </channel>
</rss>

