{"id":2164,"date":"2016-06-17T15:41:50","date_gmt":"2016-06-17T14:41:50","guid":{"rendered":"http:\/\/emtunc.org\/blog\/?p=2164"},"modified":"2017-02-24T15:03:24","modified_gmt":"2017-02-24T15:03:24","slug":"take-care-applying-palo-alto-best-practices","status":"publish","type":"post","link":"https:\/\/emtunc.org\/blog\/06\/2016\/take-care-applying-palo-alto-best-practices\/","title":{"rendered":"Take Care When Applying Palo Alto Best Practices"},"content":{"rendered":"

This is a follow up from my other blog post<\/a> – as I have found another issue with the best practices provided by Palo Alto<\/a>, I thought I’d consolidate them in a single post.<\/p>\n

<\/p>\n

HTTP Header Range Option<\/h2>\n

I’m going to copy this bit from my previous post:<\/p>\n

It seems Windows Updates doesn\u2019t play nice with Palo Alto best practices; specifically when it comes to range headers.<\/p>\n

Palo Alto best practices state that you should block the HTTP range option for the following reason:
\n<\/span><\/p>\n

\u201cThe HTTP Range option allows a client to fetch part of a file only. When a next-generation firewall in the path of a transfer identifies and drops a malicious file, it terminates the TCP session with a RST packet. If the web browser implements the HTTP Range option, it can start a new session to fetch only the remaining part of the file. This prevents the firewall from triggering the same signature again due to the lack of context into the initial session, while at the same time allowing the web browser to reassemble the file and deliver the malicious content\u201d<\/em><\/p>\n

Turns out some legitimate applications require the HTTP Header Range option – WSUS being one I came across. If you see event logs similar to the below and have range headers blocked on your Palo then it’s probably because of that.<\/p>\n

Event ID 364 \u2013 Content file download failed. Reason: The job is not making progress. The server may be misconfigured. Background Intelligent Transfer Service (BITS) will try again later
\nEvent ID 10032 \u2013\u00a0The server is failing to download some updates.<\/em><\/p>\n

PAN-OS > 7.1<\/span><\/h5>\n

You can find the setting here:\u00a0Device > Setup > Content-ID > Content-ID Settings<\/strong><\/p>\n

PAN-OS < 7.1<\/span><\/h5>\n

CLI access is necessary.
\nTo view the current configuration:<\/p>\n

show deviceconfig setting ctd<\/pre>\n
If\u00a0skip-block-http-range = no\u00a0<\/strong>then range headers\u00a0are<\/strong> being blocked.<\/p>\n
To allow the HTTP Header Range Option then:<\/p>\n
set deviceconfig setting ctd skip-block-http-range yes<\/pre>\n
Forward Segments Exceeding TCP out-of-order Queue<\/h2>\n
Occasionally I have noticed large downloads fail. Files that should take seconds to download would\u00a0take minutes.\u00a0Often times downloads would just stall indefinitely\u00a0at some random point in the download.<\/p>\n
I came across this issue from multiple download locations – the most prevalent being the Amazon S3 storage service.<\/p>\n
The problem can occur if too many out-of-order packets arrive and exceed the\u00a0TCP out-of-order queue limit of 64 per session on the Palo. If this happens the firewall will drop the out-of-order packets which can cause sessions (and downloads) to fail.<\/p>\n
Enabling the\u00a0Forward segments exceeding TCP out-of-order queue<\/em> option may rectify the issue for you.<\/p>\n
PAN-OS > 7.1<\/span><\/h5>\n
You can find the setting here: Device > Setup > Session > TCP Settings
\n<\/strong>Check the ‘Forward segments exceeding TCP out-of-order queue’ box.<\/p>\n
PAN-OS < 7.1<\/span><\/h5>\n
CLI access is necessary.
\nTo view the current configuration:<\/p>\n
show deviceconfig setting tcp<\/pre>\n
Run the following to allow the firewall to forward out-of-order packets.<\/p>\n
set deviceconfig setting tcp bypass-exceed-oo-queue yes<\/pre>\n","protected":false},"excerpt":{"rendered":"
This is a follow up from my other blog post – as I have found another issue with the best practices provided by Palo Alto, I thought I’d consolidate them in a single post.<\/p>\n","protected":false},"author":32,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"footnotes":""},"categories":[1],"tags":[237,220,227],"class_list":["post-2164","post","type-post","status-publish","format-standard","hentry","category-tech","tag-best-practices","tag-palo-alto","tag-panos"],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1trTO-yU","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/2164","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/comments?post=2164"}],"version-history":[{"count":13,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/2164\/revisions"}],"predecessor-version":[{"id":2468,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/posts\/2164\/revisions\/2468"}],"wp:attachment":[{"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/media?parent=2164"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/categories?post=2164"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/emtunc.org\/blog\/wp-json\/wp\/v2\/tags?post=2164"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}