How can I get a response page for DNS Sinkhole?
13135
Created On 06/17/21 19:09 PM - Last Modified 05/03/22 01:11 AM
Question
- How can I get a comfort response page if we're browsing to a domain that is being DNS sink-holed?
- How can I see the full URL that the user or spyware was trying to access at the sink-holed domain?
Environment
- Palo Alto Networks firewall
- PAN-OS >= 7.1
Answer
The DNS Sinkhole action can cause web-browsing to malicious websites to be blocked before the TCP connection can even begin. If the connection was allowed to progress, and the subsequent traffic was HTTP based, it could have been blocked by URL Filtering (which would be able to present with a Response Page).
Given that the HTTP session is not allowed to begin when executing DNS Sinkhole, the current solution used to inject response pages in URL Filtering can't be used for the DNS Sinkhole case without additional effort. This article describes the workaround to serve URL Filtering Response pages to DNS sinkholed domains where the subsequent traffic is HTTP or HTTP(S).
To request this feature be added to PAN-OS natively, reach out to your Palo Alto Networks SE, and vote up on Feature Request FR ID: 6752
Workaround
- Host a custom response page in a web-server of your choice in your network, and set the Anti-Spyware DNS Sinkhole IP to point to that web-server's IP address.The web-server will act as 'http-sinkhole'. For our lab testing we used the httpd docker container available at https://hub.docker.com/_/httpd
- Create a default landing page at index.html. For our httpd example that file is located at /usr/local/apache2/htdocs/index.html and its contents are: <html><body><h1>Sinkholed by Palo Alto Networks firewall</h1></body></html>
- Make sure that the http-sinkhole page responds to any URI's. To achieve this, add a directive to serve a soft-404 response redirected to index.html. i.e. For our httpd example, this can be achieved by adding the following line in httpd.conf:
ErrorDocument 404 "/index.html"
- (Recommended)Create isolation in Layer2 by defining a dedicated VLAN for the http-sinkhole server. This will mitigate any potential lateral movement in case malware is able to exploit a vulnerability in the http-sinkhole server.
- (Recommended)Create a 'Sinkhole zone' and make sure your Security Policy only allows connections from Trust to the Sinkhole zone.
- Make sure that the http-sinkhole server is in a different Zone than your users, otherwise, if it was deployed in the same Zone, the traffic may not traverse the firewall.
- Define a 'Sinkhole' security policy configured to allow traffic. The destination IP will be that of the http-sinkhole server. Make sure to only allow App-ID 'web-browsing' to port tcp/80 and 'ssl' to port tcp/443 to the web-server to prevent any malware from possibly executing any exploits against the http-sinkhole server.
- Define a new URL Filtering profile with all categories set to block, and associate it to the 'Sinkhole' Security Policy. This will result in injecting the firewall's URL Filtering response pages, as well as logging the full URI resource in the URL Filtering logs that Anti-Spyware DNS sink-holed and that the spyware would have tried to access.
- For HTTP(S), deploy a PKI or Trusted Root CA signed certificate in the http-sinkhole server, that is trusted by hosts and the firewall. This will allow the HTTP(S) response page to be served to users without presenting them with an unknown certificate issuer warning. Note that instructions to complete this step are not covered in this article. Please refer to your web-server's documentation,
- Use SSL Forward Proxy to inspect your traffic. This will allow both Response Page injection and full URI logging in the URL Filtering logs. If you instead used SSL Inbound Inspection, it will not allow the response page injection since SSL Inbound inspection does not intervene the session but It will however allow full URI logging.
Additional Information
- Do not use a FQDN address for the Sinkhole IP as this will break the solution. The reason is that the firewall, upon observing the initial DNS query to the malicious domain, will install a DISCARD session after injecting the sinkhole CNAME response. The host will then initiate a subsequent DNS query with the same source port to resolve the CNAME, which will be matched and dropped by the DISCARD session.