PA Default Behaviour for un-matched UDP traffic?

Reply
Highlighted
L2 Linker

PA Default Behaviour for un-matched UDP traffic?

Hello,

 

I am pretty new to PA firewalls, and started looking at the default firewall behaviour for various kinds of traffic.

Hence wanted to know, what happens when PA sees unmatched UDP traffic, say a DNS reply, from outside for which it doesn't have a DNS request recorded from the inside? Does it drops the incoming DNS reply or does it allows it?

 

I have been searching internet for a while now, but couldn't get the correct answer to this question, any help appreciated :)

 

Thanks,

Fatema. 

Highlighted
L6 Presenter

Re: PA Default Behaviour for un-matched UDP traffic?

If the unknown-udp/tcp  applications are added in the security policy then traffic is allowed:

 

un.PNG

 

Highlighted
L2 Linker

Re: PA Default Behaviour for un-matched UDP traffic?

Thanks for the answer!

That means the default is PA is going to block it, if we haven't added the unknown-tcp/udp to the security policy?

Also, how to see where it might have been added? I can't find the corresponding tab on the PA-mgmt as shown in your screenshot?

Highlighted
L2 Linker

Re: PA Default Behaviour for un-matched UDP traffic?

Okay, I found it. It's under Applications tab (I don't know how I missed it when looking for applications),

so for the security policies having "any" in the "Application" field  and "allow" in "Action" field, will be allowing unknown-tcp/udp as well? and all other security policies for which you define corresponding applications (like ssh, web-browsing etc) to allow, will be blocking unknown-tcp/udp?

 

Also, had another question: so for all the DNS responses that PA would get for which it doesn't find corresponding DNS requests, won't it be classified under "dns" as application instead of "unknown-udp"? 

Highlighted
L4 Transporter

Re: PA Default Behaviour for un-matched UDP traffic?

don't quote me on this, but it should just be dropped.

 

if there was no session generated for an outbound DNS request, a stateful firewall would not be able to open the port for the received s2c traffic. it gets even more convoluted when you factor in dynamic ip and port natting, assuming you aren't using public IPs on the inside. most of the time, DNS servers are going to see your public IP, presumably the IP of the untrusted interface, so the best they could do is spoof that as the source IP to generate a response from a DNS server. that would then hit the PA, which would have no session to reference who to forward the response back on to, so it should just drop it.

 

if anything, it should count against a UDP flood attack and be covered under the zone protection file, assuming you have one configured and applied to your untrust interface.

 

if that makes any sense.

--
CCNA Security, PCNSE7
Highlighted
L2 Linker

Re: PA Default Behaviour for un-matched UDP traffic?

Thanks Brad for the explanation!

Makes sense. That means PA would automatically going to drop responses if it doesn't find a corresponding session (kinda protection from DNS amplification/reflection attack). For other kind of DOS attacks, zone protection file should take care of them.

 

Just trying to think, how the above use-case would be different, or same as the "unknown-udp" App.

 

Thanks!

Highlighted
L4 Transporter

Re: PA Default Behaviour for un-matched UDP traffic?

not sure I follow. if we are talking about the unknown-udp app, I don't think it applies here. it has nothing to do with session matching (or lack thereof). it has to do with not being able to associate the traffic with an otherwise known app.

 

if you want more information on that, this article by @reaper should help

 

https://live.paloaltonetworks.com/t5/Management-Articles/Pro-Tips-Unknown-Applications/ta-p/77052

--
CCNA Security, PCNSE7
Highlighted
L2 Linker

Re: PA Default Behaviour for un-matched UDP traffic?

Hmm, thanks for the link to the article.

Yeah, I got a little confused between un-matched udp traffic and "unknown-udp", hence wanted to know what happens when PA sees incoming traffic that is not matched with any sessions currently in PA.

So in a nutshell, PA would just drop the traffic silently, as you mentioned earlier.

 

I will look into unknown-udp/tcp App-IDs in more detail to know about them :)

 

Thanks. 

Highlighted
L6 Presenter

Re: PA Default Behaviour for un-matched UDP traffic?

Hey,

 

I am a little bit late here. I didn't understand your initial question fully and thought you are looking to permit unknown-udp/tcp traffic. As @bradk14 has mentioned already we have stateless (very old firewalls, it is actually ACLs) and stateful firewalls (Palo, SRX ASA etc). So if palo receives the traffic and cannot find any associated session it will try to create one based on the security policies. Bear in mind that your traffic can be classified a "unknown-udp/tcp" and this is based on how the palo app-id engine seeing it. We need to differentiate between unknown-udp/tcp as application and the unknown source or destination tcp/udp traffic. Hope this make sense. 

 

p.s going to get coffee 

Highlighted
L2 Linker

Re: PA Default Behaviour for un-matched UDP traffic?

Hmm, now I am confused..

So what should PA do when it sees a DNS reflection attck? i.e thousands of DNS replies to an IP behind PA, for which PA never saw any DNS requests originated from that IP behind PA, will it classify that traffic as unknown-udp and allows it to hit the poor IP behind PA, or will PA drops it thinking "I never saw DNS requests from that IP and hence I am going to drop these bunch of DNS replies to that IP"?

 

I am going to assume, what Brad had mentioned, that PA is going to "silently drop" those DNS replies, as they will not match any current seesions in PA.

 

Thanks! 

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!