PA Default Behaviour for un-matched UDP traffic?

[Fatema]

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. 

[TranceforLife]

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

[Fatema]

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?

[Fatema]

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"? 

[bradk14]

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.

[Fatema]

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!

[bradk14]

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

[Fatema]

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. 

[TranceforLife]

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 

[Fatema]

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! 

[TranceforLife]

Correct, but PA will classify the traffic not as "unknown-udp" as an application. It will be a simple traffic drop. As traffic trying access from outside to inside without any session match. 

[Fatema]

Alrighty, PA should document it somewhere those corner cases, as it becomes difficult for new bees, like me to understand the default PA behavior (or it can be just common sense, that I could be missing 🙂 )

Thank you TraceforLife and Brad for quick responses and explanations.

Appreciate it!

[reaper]

here's some documentation 🙂 Pro-Tips: Unknown Applications