I'm not sure I understand why we need to add the sec and log forwarding profiles to "egress-outside". we already have a policy blocking offending hosts at the top so why apply those profiles in the second rule?
Deny rules don't use Security Profiles. The traffic is blocked based on policy rule parameters and that action happens before using any profiles. The Anti-Spyware profile is set to sinkhole traffic and the auto-tagging places the offending device in the dynamic access group to be blocked by the "block-infected-devices" rule. Without the "egress-outside" rule and its attached Anti-Spyware profile, the "block-infected-devices" rule would be using an address group with no addresses.
Thank you its a neat feature. One question can we use auto tagging to tag external public IPs say source IP address of port scanners from the internet or is auto tagging only for inside address with a user-id agent?
If your hosts query your local DNS servers directly, without going through the firewall, your DNS servers would be added to the DAG and blocked instead of your hosts since the firewall only sees the query from your DNS server. It only worked in this lab scenario because your host was using google DNS and not local DNS as depicted in the slide. The correct way to do this is to tag hosts based on their traffic destined to the sinkhole address NOT the sinkhole action in threat logs. Ignore the "UPDATE" reply; my comment is still correct. This is the original response from them before they deleted their comment: You are correct, although in a GlobalProtect or branch office scenario it is a likely possibility that there wouldn't be an internal DNS server as is shown in the diagram, so this configuration would work. But yes, your solution would be necessary if there is an internal DNS server. Ironically, there is an internal DNS server in the lab I used, but it runs on the client so it did in fact block the DNS server, it's just the IP address of client and DNS server is the same. It was an oversight on my part and I'm glad you pointed it out. My second mistake was there is a video I was unaware of from Jan. 2018 that shows the same example and addresses the same issues! The link is in the notes above. Thanks for keeping me on my toes!
UPDATE: This is actually not correct. The sinkhole action is not because of the query, but when the host actually tries to connect to the domain address.
![ILLSLICK - THE KING'S LANDING [Freestyle]](http://i.ytimg.com/vi/feIJJnNkTfk/mqdefault.jpg)
Best Happy Hour ever! Thanks Palo Alto.
Glad you enjoy it, Ivo!
We encourage you to visit the LIVEcommunity where you can find more great information: live.paloaltonetworks.com/
Great work gents, another 'unknown feature' on the PANOS, have already applied the Cert Error Auto Tag
Thanks! There are a lot of options with this feature and I'm glad to hear it helped!
I'm not sure I understand why we need to add the sec and log forwarding profiles to "egress-outside". we already have a policy blocking offending hosts at the top so why apply those profiles in the second rule?
Deny rules don't use Security Profiles. The traffic is blocked based on policy rule parameters and that action happens before using any profiles. The Anti-Spyware profile is set to sinkhole traffic and the auto-tagging places the offending device in the dynamic access group to be blocked by the "block-infected-devices" rule. Without the "egress-outside" rule and its attached Anti-Spyware profile, the "block-infected-devices" rule would be using an address group with no addresses.
great video
Thank you its a neat feature. One question can we use auto tagging to tag external public IPs say source IP address of port scanners from the internet or is auto tagging only for inside address with a user-id agent?
Murali, did you ever figure this out?
Awesome!
If your hosts query your local DNS servers directly, without going through the firewall, your DNS servers would be added to the DAG and blocked instead of your hosts since the firewall only sees the query from your DNS server. It only worked in this lab scenario because your host was using google DNS and not local DNS as depicted in the slide. The correct way to do this is to tag hosts based on their traffic destined to the sinkhole address NOT the sinkhole action in threat logs. Ignore the "UPDATE" reply; my comment is still correct.
This is the original response from them before they deleted their comment:
You are correct, although in a GlobalProtect or branch office scenario it is a likely possibility that there wouldn't be an internal DNS server as is shown in the diagram, so this configuration would work. But yes, your solution would be necessary if there is an internal DNS server. Ironically, there is an internal DNS server in the lab I used, but it runs on the client so it did in fact block the DNS server, it's just the IP address of client and DNS server is the same. It was an oversight on my part and I'm glad you pointed it out. My second mistake was there is a video I was unaware of from Jan. 2018 that shows the same example and addresses the same issues! The link is in the notes above. Thanks for keeping me on my toes!
UPDATE: This is actually not correct. The sinkhole action is not because of the query, but when the host actually tries to connect to the domain address.