About drwillis07

While true out of the box, there is a way to accomplish this manually using the API interface and the dynamic address object feature. 1. You could create a dynamic address object that is referenced by the QoS policy. This policy is committed even though the DAO is empty. 2. When a user is manually detected as consuming too much bandwidth (DDoS protection looks at session levels, not bandwidth), you would add those users to the XML document referenced by a script (several ways to do that - manual script manipulation or the use of a block list API added into the GUI) 3. A process on your server would detect that the script was updated and execute the API to push the document to firewall(s) directly or via Panorama to populate the DAO on the firewall with your bad user(s) 4. Another automated process on your server would then remove the IP address of the bad actors at a set time every day based on the timestamp of the actor's addition See here as a potential basis for your workflow - Sample API workflow for Dynamic Address Objects Obvious challenges here - besides writing scripts and monitoring CRON (or CRON-like processes) is tracking on bandwidth consumption by user. The function that is missing on the appliance is the lack of such a report. The only way to get that out of the appliance is to apply QoS as a reporting only (i.e. no max bandwidth) function, but you would need to create a policy per user - which is unrealistic. You would want to look to an external tool to gather this kind of information. ... View more

Das, You get 30 days for orders shipped domestically (within US), or 45 days for orders shipped internationally, before the support contract begins - or when you activate the appliance, whichever date is sooner. If you haven't touched the firewall after one year you would get 1 month (roughly) of time to update before going off support. By then, though, you should have received a request to renew your support subscription. Dave ... View more

Dave, A bit of clarification on the wildfire subscription service - you can set it up to automatically check and download new wildfire generated signatures every 15 minutes but it could take as long as 30 minutes to get a signature for malware your firewall detected and uploaded for analysis. Based on traffic in the wild, stopping this stuff within the first hour (let alone the first 30 minutes) should provide a huge improvement in protection - thus the for-fee subscription service. Your SE can definitely cover off what we're seeing in our Wildfire servers. Also, and forgive me if you already know this, you can configure a file blocking object that does trigger on any .exe download (matching the base security rule, or object specific applications) that forces the user to hit a continue button and acknowledge the download - all of this is without wildfire.  Wildfire PE files types include Win32 Portable Executable (PE) files (e.g. exe, dll, and scr), so you could use this continue configuration to force users to stop and validate the download of other file types mentioned here on Live: .pif, .lnk, . com, .bat and .vbs . Alternatively you can configure wildfire to "continue and forward" which does the same thing - forces the user to acknowledge and accept a download prior to the firewall allowing the transaction AND sending off a file hash to the wildfire cloud servers to see if the file should be uploaded for analysis. Again, this would be for the subset of file types within the PE category today. Bear in mind that should the encrypted email get through, any potential executables that may be initiated when the user clicks on a link will still be detected by the firewall configured with a file blocking policy - this is also true of links embedded in PDF files. HTH ... View more

Paula, Please look at the document - Understanding NAT found here: https://live.paloaltonetworks.com/docs/DOC-1517 It contains examples of several common scenarios for both source and destination NAT which should address your needs for DMZ servers. ... View more