- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-05-2012 07:03 AM
We'd like to build a custom app ID that permits only one specific DNS query to make it through... for example, we want wireless clients (which have our Palo Alto as their default gateway) to only query for the DNS A record "vpngateway.example.com"
Has anyone built anything like this? The custom app signature tech note focuses specifically on HTTP... if we could get an example of building a DNS specific custom app signature, that would be awesome
Thanks guys,
Eric
01-31-2013 10:10 AM
Just to kind of follow up on this and provide some closure, the way we decided we're going to do this is via PA's DNS proxying... we're going to force proxying on and only allow the one specific domain we want to resolve via DNS to be explicitly resolved to the IP we want that one host record to resolve to. This basically solves our problem in a reasonably elegant way.
12-27-2012 01:35 PM
you can use context 'dns-req-section' and \x to start and end hex
bytes for length to construct the domain name in the question like the
example below, however I'm not aware of how to construct a valid
pattern to match case insensitive.
the below will match www.hp.com but not www.HP.COM and so on.
also, if you could match case insensitive someone could use
name/label compression to subvert the pattern match.
set application dns-qname-www.hp.com signature www.hp.com and-condition "And Condition 1" or-condition "Or Condition 1" operator pattern-match pattern \x03\xwww\x02\xhp\x03\xcom\x0000010001\x
set application dns-qname-www.hp.com signature www.hp.com and-condition "And Condition 1" or-condition "Or Condition 1" operator pattern-match context dns-req-section
set application dns-qname-www.hp.com signature www.hp.com scope protocol-data-unit
set application dns-qname-www.hp.com signature www.hp.com order-free yes
set application dns-qname-www.hp.com signature www.hp.com comment "0001 is type A 0001 is class IN"
set application dns-qname-www.hp.com parent-app dns
01-21-2013 04:02 PM
Hi Eric,
I'm afraid you might be out of luck here. One of the many differences between DNS and HTTP is that the first one is 1 packet in each direction.
This means in your case you won't be able to have the custom app matched unless DNS as a parent application is allowed but if you do this all DNS requests will be allowed through not just the one you specify in your customer app.
Let's assume you create your custom_dns application where www.hp.com is detected and allow it in a policy from A(client) to B (dns server).
Now, if the default dns application is denied as soon as the firewall detects that this is a DNS request (It does it before the content is inspected) the request will be denied. Application has been detected as dns and there is an deny action associated wit it
On the other hand if the default dns application is allowed when the traffic goes through the firewall the application will shift from dns (the default one) to the custom_dns as soon as the firewall reads the content. So in the logs you'll see a correct match with the custom_dns app you created but being this the mechanism this implies all other dns requests will be allowed as well.
.
Hope this helps to understand the logic.
-Salvo
01-31-2013 10:10 AM
Just to kind of follow up on this and provide some closure, the way we decided we're going to do this is via PA's DNS proxying... we're going to force proxying on and only allow the one specific domain we want to resolve via DNS to be explicitly resolved to the IP we want that one host record to resolve to. This basically solves our problem in a reasonably elegant way.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!