Tutorial: Auto-tagging & DNS Sinkhole
HTML-код
- Опубликовано: 6 сен 2024
- This tutorial shows how automated actions can be taken by a Palo Alto Networks firewall in response to any log entry using the (PAN-OS 8+) Auto-Tagging feature. In this video you will see how Auto-Tagging can quarantine a host which has been sinkholed by the AntiSpyware security profile. Typically a host would be sinkholed if it made a DNS query for a domain known to be malicious. Although possible that a user would accidentally perform a DNS lookup of a malicious domain, it is more likely that the DNS request is the result of a malware infection. This video shows how to use the following Palo Alto Networks firewall features to quarantine, notify and enable un-quarantine activities without burdening the firewall operators:
Auto-Tagging
Log Forwarding Profile
Anti-Spyware Security Profile
DNS Sinkhole
Dynamic Address Groups
URL Filtering
very well explained! I would recommend to decrease the timeout for admin overrides. Default is set to 15 min. In this time the user/system could try to establish another „sinkhole-session“ which would not be tagged (but blocked anyway;) ).
Auto-tagging is a great feature as well as the whole pan os is;)
If your DNS is running in another subnet, you need one more security policy above the override rule. Otherwise the session would be blocked by the first DNS packet.
This example video is only working because the DNS-Server is running on this windows "client" machine.
If you have Internal DNS servers the procedure described in the video could isolate your DNS server since it will be the "Attacker" that gets sinkholed in the Threat log. If you have an Internal DNS server you can still use this procedure with a small modification to the procedure.
The beauty part about Auto-Tagging is that it works off from anything that generates a log entry.
You don’t have to base the Auto-Tagging off from the ( action eq sinkhole ), in this situation I would base it off from the configured sinkhole address and reference the traffic log.
This will positively match the infected host and not your DNS server.
( addr.dst in 72.5.65.111 )
Nice. Thanks for that comment! I specifically went down to the comments to see if anyone noticed this issue. I was wondering why you didn't add the quarantine log forwarding profile to a rule blocking traffic to the synchole address rather than the allow traffic rule. And it totally makes sense changing the log filter match to just match traffic going to the synchole destination address. Thanks for the great video!
Hi, not sure if I get this right. Basically what's you saying is that the log type should be Traffic instead of threat under Log Forwarding Profile Match list, keep the filter - Action eq sinkhole and under Built in action use Destination address as a Target ? 🙄
this video was *SMOKE & MIRRORS...*
all he's doing is Quaratining his DNS server.
FAIL
FAIL
FAIL
Was anyone able to TWEAK the *Log-Forward Profile* to target the SINKHOLE address (instead of 'action eq sinkhole')
?
@@HughJass-jv2lt You people don't understand how the sinkhole actually works. The DNS server isn't ever attempting to go to the malicious website. It's ONLY attempting to go the an external name server. The firewall sees the query to an external name server requesting resolution for a domain the firewall recognizes as malicious and responds to the internal name server with a sinkhole IP address set up by the firewall administrator.
The ONLY IP address that will EVER get sinkholed is the source IP address that is attempting to connect to the IP address of the sinkhole. Since the internal name server never attempted to reach out to any other server other than the external name server, the internal name server will NEVER attempt to connect to the sinkhole IP address.
This will NOT quarantine the DNS server because the DNS server never tried to connect to the malicious site. This isn't how DNS works at all! lmao.
The internal DNS server is never attempting to connect to the malicious site. It's attempting to reach out to an external name server. The only time anything will ever hit the sinkhole is when a device attempts to reach out to the sinkhole IP address, which the name server would never attempt to do.
The internal DNS server could attempt to query the external name server 1000 times and it would never get quarantined because the internal DNS server is never going to attempt to connect the to malicious site. The firewall is ONLY looking for an attempted connection the the sinkhole IP address, which only the client would be attempting to reach out to because of the query results the internal DNS server gave it.
An internal name server doesn't connect to the requested sites on behalf of the client. That's not how DNS works and it's not how the sinkhole feature works either.
Now, you could end up quarantining your Web Proxy servers depending on how your network is designed, but name resolution isn't ever what's going to get you sinkholed. It's the actual reaching out to the sinkhole IP address that gets you quarantined.
perfect video thank you four your support.If you have PAN, try it.
How could I get a hold of the customized Response Page with the override field mentioned in the video?
Awesome configuration, very useful video.
Glad it was helpful!
As always, please be sure to visit the LIVEcommunity to participate in online discussions, read our blogs and see all of the great information that we have there:
live.paloaltonetworks.com
Using Pan-OS 9.1 and facing problem with response page not loading and thus no option for admin override. I have enabled response page under interface management and using redirection on the same interface IP. Anything got changed with 9.1?
Remember that if you are accessing a website with https, I believe that you'll need to enable ssl forward proxy decryption in order to get the response page.
@@linuxbowling Exactly! SSL Decryption is needed for the override page to be displayed if the site is tls encrypted.
Anyway of getting a copy of the customized Response Page ?
You can edit, google HTML to word
im gonna have to *rewatch* this one ...
lol
this video was *SMOKE & MIRRORS...*
8:50
all he's doing is Quaratining his DNS server.
FAIL
FAIL
FAIL
:\
Okay...
upon further review:
17:00
It's *STEP #3* that needs to be rewritten....
_somehow set the LOGIC to target Destination-ipaddress EQUALS ipaddress-of-sinkhole_
^assuming this is possible....
then That would do it.
This would be a viable solution.
Awesomeness!
Very useful feature. Can you please provide commands to remove the tag manually..
Hi! you can manually clear a tag by using this command: clear auto-tag vsys ip tag-dest tags [ ... ]