New Firewalls-Currently using Fortinet

stunning

Limp Gawd
Joined
Sep 14, 2006
Messages
317
Everyone,

Anyone have any recommendations on Firewalls? We are looking for an all in one package that includes, AV, Webfiltering, etc.

We have an upcoming meeting with Palo Alto Firewalls and would like to know if anyone has worked with this company before hand.

I haven't worked with Baracuda for about 4 years now, anyone know how they are still performing?
 
I like sonicwall :)

What are your needs ? whats the user count ? Throughput ?
 
A lot of people bitch about 'em but I use sonicwalls also. I'll be retiring a Pro 3060 this month and replacing it with a NSA 2400. I don't have any issues with them and they work well.
 
A lot of people bitch about 'em but I use sonicwalls also. I'll be retiring a Pro 3060 this month and replacing it with a NSA 2400. I don't have any issues with them and they work well.

2400's are nice, but when you look inside them and see, yuo almost shit a brick for what you are paying :( I modified one for a friend, he hated listening to the fan noise. Love my sonicwall, just $$ to keep activated for their features. "AND" the TZ210 has no vlan throughput at all :(

DSCN0018.JPG


ALL quiet now !

DSCN0027.JPG


I even modified my TZ210 that was getting hot too!
 
PA firewalls are decent. Don't buy their sales pitch, they're not the best, but overall OK (changing the user-agent was enough to bypass their IDP).

The GUI is horrible, slow and awkward. However, they're good enough for a UTM device.
 
We currently support Checkpoint, Cisco, Fortinet and Juniper. We are in the early stages of looking at PA. Checkpoint and Juniper are worth a look though I'd surprised if they beat Fortinet on pricing and performance though i can't speak to your discounts. Cisco despite their marketing numbers just doesn't have the performance. It's too early to speak on PA though the early reports are looking good. Honestly Sonicwall is not in same class as the other devices and that's all I'll say about them. Assuming your discounts are similar to ours from a numbers perspective Fortinet is hard to beat.
 
We support about 30 different sites, varying from 10- 1500 employees at each site. Each of our site currently host 10- 45mb opteman site. I dont know what we got our Fortinets for because I just started at this place a little over a year ago. My understanding is that we had these firewalls for about 4-5 years and we are currently schedule for replacement due to EoL or contract renewal.

One of our biggest complaints is users streaming media; our central office with roughly 1500 users are pounding our Fortinet AV and the user interface of the Fortimanager IMO just plain sucks!
 
2400's are nice, but when you look inside them and see, yuo almost shit a brick for what you are paying :( I modified one for a friend, he hated listening to the fan noise. Love my sonicwall, just $$ to keep activated for their features. "AND" the TZ210 has no vlan throughput at all :(
I even modified my TZ210 that was getting hot too!

All our rack stuff is in a chilly climate controlled room. So no heat or noise issues there. I won't argue with most of the complaints about Sonicwall.

#1. Their annual renewal for services. We do pay to renew all firewalls. We also use their CDP boxes and I refuse to pay renewals on those. $400 each for the 110-210 units. I've told them a couple times I won't renew the cdp boxes until they drop the price. I actually renegotiated a renewal price on around 10 cdp boxes last year. My vendor couldn't believe sonicwall did that and said he never had seen them do that before. But we do have a lot of their equipment and we do keep up with all the firewalls. Sonicwall did say they would only do it one time and that's held true.

#2. People complain about their support. It is annoying that they outsource to India and some are hard to understand. But they've managed to always fix any issue I was not able to handle myself.
Dell recently acquired Sonicwall so maybe in time we will see native english speaking support in the future like Dell has with their corporate support.

The OS Enhanced takes a little getting used to but it really isn't that bad and the wizards work well. The firewalls are very reliable and do what they're suppose to. Interface in general is easy to understand and work with.
 
Last edited:
All our rack stuff is in a chilly climate controlled room. So no heat or noise issues there. I won't argue with most of the complaints about Sonicwall.

#1. Their annual renewal for services. We do pay to renew all firewalls. We also use their CDP boxes and I refuse to pay renewals on those. $400 each for the 110-210 units. I've told them a couple times I won't renew the cdp boxes until they drop the price. I actually renegotiated a renewal price on around 10 cdp boxes last year. My vendor couldn't believe sonicwall did that and said he never had seen them do that before. But we do have a lot of their equipment and we do keep up with all the firewalls. Sonicwall did say they would only do it one time and that's held true.

#2. People complain about their support. It is annoying that they outsource to India and some are hard to understand. But they've managed to always fix any issue I was not able to handle myself.
Dell recently acquired Sonicwall so maybe in time we will see native english speaking support in the future like Dell has with their corporate support.

The OS Enhanced takes a little getting used to but it really isn't that bad and the wizards work well. The firewalls are very reliable and do what they're suppose to. Interface in general is easy to understand and work with.

I can't wait till they send me for Training :) ( dell that is )
 
OP I agree the FM interface isn't great, then again Provider-1 isn't much to write about either. What version are you running? There are some decent improvements going from 4.2 to 4.3. It is my experience that most folks under size their UTM using firewall only or vendor marketing numbers. It pays to do in house performance testing.
 
Palo Alto make some incredible stuff. I'd definitely compare them with some of the other leaders like Checkpoint, Cisco, etc. How many nodes are you firewalling?
 
OP I agree the FM interface isn't great, then again Provider-1 isn't much to write about either. What version are you running? There are some decent improvements going from 4.2 to 4.3. It is my experience that most folks under size their UTM using firewall only or vendor marketing numbers. It pays to do in house performance testing.



We are on 4.3.7. Yes 4.3 was a huge improvement, but I swear there are like MR releases every few weeks and getting all of our sites to comply with downtime is a pain in the a$$. It seems that everytime we have some sort of issue, Fortinet fixes it with another patch or MR.

As far as Nodes, lets just say EVERY thing and Everybody. The way the guy had it set up he created policies for every single device; theres like 50 different policies per server. We narrowed and grouped things down which helped with the performance.

Im not very happy with their support, thus as to why we were looking at changing firewalls.
 
Palo Alto and Checkpoint are going to be your big contenders in a large environment. They have the latest firewall tech, and great management options for multi-site. I have a friend who works in a large Palo Alto environment. They like it so far. You can't go wrong with Checkpoint either- They're really well established.

You may also want to check into the new "next gen" Cisco ASA's. I haven't worked with them yet, but Cisco's TAC support team has always taken care of me. They certainly know how to treat an enterprise client.
 
Right on about Fortinet releases. We've not had any issues with support but we've got a dedicated account team and they care of us. If your out on Fortinet I'd say CP would be the way to go. P1 is a decent management platform. If you go that route seriously consider putting the MDS on a vm. Also, do not even think about logging to the CMA. Suck it up and purchase an MLM. We are still running SPLAT in production but GAIA looks great in the lab but all the blades haven't been ported yet. We've got Diamond support which I can say without a doubt is better support by far than any of their competitors offer, but it isn't anything like cheap.
 
I liked the sonicwall we had. Did a pretty good job. Got an opportunity to work with Forigate 200b, 300c, and honestly I would stick with it. The last company I was with loved them. Had very little issues. Were looking to implement them now and bailing on the barracuda 610 we have
 
I liked the sonicwall we had. Did a pretty good job. Got an opportunity to work with Forigate 200b, 300c, and honestly I would stick with it. The last company I was with loved them. Had very little issues. Were looking to implement them now and bailing on the barracuda 610 we have

I like how the sonicwall is lay out, it's pretty easy. The wizards are nice too. I like the,, if I had money right now I'd buy a 2400, instead I'm going to build a new 1u astaro box..
 
PA's are a little different to work with. Nice GUI interface but OMFG it is slow. This also happens on their cli as well. I don't really like how their NAT'ing works. The reports are nice and being able to do packet captures from a GUI is nice as well.
 
I like how the sonicwall is lay out, it's pretty easy. The wizards are nice too. I like the,, if I had money right now I'd buy a 2400, instead I'm going to build a new 1u astaro box..

The layout isn't bad.. everything on the left.. configs in the middle. The Content Filtering was lacking for me..
 
Thanks for the comments, but it looks like they actually got a test demo of a Palo Atlo for 90 days.
 
2400's are nice, but when you look inside them and see, yuo almost shit a brick for what you are paying :( I modified one for a friend, he hated listening to the fan noise. Love my sonicwall, just $$ to keep activated for their features. "AND" the TZ210 has no vlan throughput at all :(

DSCN0018.JPG


ALL quiet now !

DSCN0027.JPG


I even modified my TZ210 that was getting hot too!


I like it, btw, the inside is shit and they are loud so i hack it to make it work but I like it.:eek::eek::p
 
I have 4 of the PA 4060 and they are pretty great. The training is nice too. We use them for some pretty off the wall solutions but so far the stability and throughput are impressive. Also support is great too. No complaints other than the slowness of the GUI. Got around that mostly by scripting everything and inputting it via CLI.
 
I have 4 of the PA 4060 and they are pretty great. The training is nice too. We use them for some pretty off the wall solutions but so far the stability and throughput are impressive. Also support is great too. No complaints other than the slowness of the GUI. Got around that mostly by scripting everything and inputting it via CLI.

One thing I hate about firewall CLI is that they are ALL different!!!! Well switches too...wth am I just complaining about the obvious lol
 
I like it, btw, the inside is shit and they are loud so i hack it to make it work but I like it.:eek::eek::p

Yeah that was one for a member on here, the one I have to do in a week is going to be different. I'm going to be using voltage regulators instead of resistors..
 
PA firewalls are decent. Don't buy their sales pitch, they're not the best, but overall OK (changing the user-agent was enough to bypass their IDP).

The GUI is horrible, slow and awkward. However, they're good enough for a UTM device.

I'd be quite interested in hearing the details of how you "changed a user agent and bypassed their IDP"? Were you inside or outside the network? How was the PA configured? What user agent are you referring to?

As far as the GUI - opinions vary. I will concede that the commit times aren't instantaneous but far from being "unusable". It really depends on how many policies you are managing and changing and how frequently you are changing them.

Its funny that you say PA is good enough for a UTM device when they're not a UTM at all. A true NGFW is not a UTM.

I've seen several articles talk about the "hype" of Palo Alto NGFWs yet I've never seen a PA not do exactly what it says it will do. Most all the competition is the same old firewalls with "bolt on's" for IPS, Malware, A/V, etc. and do not use a Positive Enforcement Model (default deny).

To the OP - glad to hear you have a 90 day trial of a PA box. I believe you'll see the true value in the box during the time you have it. Let us know how it works out.
 
It can't block software from calling home, all it does is check the user-agent string for default, known payloads (meterpreter for example). Change it to Mozilla 4.0/something and it passes straight through their scanning.

It's a decent firewall, but it's in no way better than anything else on the market.
 
It can't block software from calling home, all it does is check the user-agent string for default, known payloads (meterpreter for example). Change it to Mozilla 4.0/something and it passes straight through their scanning.

It's a decent firewall, but it's in no way better than anything else on the market.

You're mistaken and it sounds like you don't understand how Palo Alto works. If an application tries to communicate from the inside out, Palo Alto will check to see if that App is indeed allowed to communicate. If it's not specifically allowed, it's denied. Palo Alto uses a Positive Control Model (Default Deny). Your analogy above is not correct about how the PA works. You're speaking of a blacklist and if it doesn't find it on the blacklist it allows the traffic to pass. You're wrong.

I question if you have any real world experience at all with Palo Alto NGFW's.
 
You're mistaken and it sounds like you don't understand how Palo Alto works. If an application tries to communicate from the inside out, Palo Alto will check to see if that App is indeed allowed to communicate. If it's not specifically allowed, it's denied. Palo Alto uses a Positive Control Model (Default Deny). Your analogy above is not correct about how the PA works. You're speaking of a blacklist and if it doesn't find it on the blacklist it allows the traffic to pass. You're wrong.

I question if you have any real world experience at all with Palo Alto NGFW's.

I work as a security auditor and I've come across them a few times. The "application" is http (web) which is allowed from the client segment to the external one. The backdoor software mimics a regular web session, as per a user would do.

The PA initially blocked the session, changing the User-agent string from Metapreter to a valid browser, be it Internet explorer, Mozilla, etc allowed the software to call home and establish a remote shell.

Specifying ACLs based on applications is NOT how you do it, you create an IP-ruleset and then, if you feel like it, apply applications to that ruleset. PA firewalls only look for the header information in connection attempts, that's another way of bypassing them. Start the session via http, change over to ssh or anything you feel like it because it's already added to the state table as a valid connection.

The way you describe them is exactly as per their sales pitch. It's not very professional defending products you sell on public forums, especially when you're dead wrong :D
 
You've "come across them a few times" doesn't equate to real world experience. BTW - if you start a session as HTTP and try to change it to something else, PA will identify and block that if the policy for the new app. PA doesn't stop inspecting traffic and applying policy once a session is established. That would make you wrong. The fact you believe that makes me question your actual experience, if any with PA.

If you did audit a PA then I'd be curious to who managed the policy on the PA, how it was configured, etc.? I have seen people who don't understand how the PA works and enforces policy incorrectly configure them and make them in effect, just another traditional port based firewall.

None of my comments are based on marketing, hearsay or 3rd party association. They are based on every day first hand real world use of PA's devices. For the record, I have no affiliation with Palo Alto Networks, am not a reseller of theirs. I don't even sell their devices. That would make you wrong again.


I work as a security auditor and I've come across them a few times. The "application" is http (web) which is allowed from the client segment to the external one. The backdoor software mimics a regular web session, as per a user would do.

The PA initially blocked the session, changing the User-agent string from Metapreter to a valid browser, be it Internet explorer, Mozilla, etc allowed the software to call home and establish a remote shell.

Specifying ACLs based on applications is NOT how you do it, you create an IP-ruleset and then, if you feel like it, apply applications to that ruleset. PA firewalls only look for the header information in connection attempts, that's another way of bypassing them. Start the session via http, change over to ssh or anything you feel like it because it's already added to the state table as a valid connection.

The way you describe them is exactly as per their sales pitch. It's not very professional defending products you sell on public forums, especially when you're dead wrong :D
 
This describes how "NGFW" work, and their flaws http://www.youtube.com/watch?v=s2cz--bzZRE

The PA firewalls were set up by the distributors of PA, best practices were followed (or so I'd hope from an official partner).

Sorry it's taken me so long to respond. I've been out of town.

First of all, the video you posted is from a competitor of PA (also, they currently have a pending lawsuit against PA). I AGREE with you, Application Firewalls have their limitations and are not a replacement for IPS. The video you have posted states EXACTLY that! Palo Alto is not only an application firewall but they also do a fine job of IPS. PA ranks in NSS Labs as one of the top vendors in IPS alone as well as a NGFW. PA starts at layer 2 and finishes at layer 7.

Second, you're "real world experience" consists of "I've come across them a few times".

Your lack of experience of PA firewalls is highlighted by the fact that you "think" they can be compromised by starting a session with HTTP and changing it mid-stream to SSH. While that may be true of a layer 7 only device, that is not true and a PA would easily identify the behavior of the change in traffic and block it. You truly don't understand how their App ID works if you think that a mere header can be changed and traffic permitted.

So in order to make this short, I will happily put you behind a PA firewall with only HTTP as allowed traffic and you with a Windows 7 or XP workstation in a default configuration. It sounds like your "compromise" was a situation where both the client and the server are under control of the hacker. That is not a likely real world situation.

We will do a traffic capture. If you can compromise the firewall I will be happy to send the results to PA, as I'm sure their engineers will be eager to understand how their NGFW is so easily compromised.

Until then you've provided nothing except "they're no better than any other firewall". It seems as Gartner and NSS don't agree with you (as far as I know they're not paid off by PA).

I want to be clear, there is no such thing as a secure system. If you want a secure system, then unplug the network connection and don't allow anyone else physical access. Palo Alto does security as well as if not better than anyone else in the business, which is the point of this discussion.
 
I won't respond to this. You've registered for this thread and come here to defend PA - You're affiliated with them in some way.

", I will happily put you behind a PA firewall with only HTTP as allowed traffic "

Do your marketing in some other way than on enthusiast forums, please.
 
I won't respond to this. You've registered for this thread and come here to defend PA - You're affiliated with them in some way.

", I will happily put you behind a PA firewall with only HTTP as allowed traffic "

Do your marketing in some other way than on enthusiast forums, please.

As I said, I have no affiliation with Palo Alto other than I believe in their products. I am a small business consultant and the PA I would put you behind is one of my clients sites.

Feel free to call me anytime (919) 696-0019 - is my direct and only number. I have a 4 year old website (www.andersontechconsulting.com). Feel free to google me or whatever. I was exposed to Palo Alto Networks working on a project for (http://www.commwellhealth.org/) several years ago. With the advent of the PA-200 I recognized that the technology was readily available (and reasonably affordable) for small businesses. I have been implementing it whenever possible since then (which is many, many clients).

I have NOTHING to hide behind. My name is David Anderson and I live in Raleigh NC. You now have my direct and only number and my name.

You are correct on one point, I'm defending PA. I have used (and use every day) their products and believe the "marketing hype". Their products are real and they work as adverrtised. I believe your claims against them to be bogus and I'm willing to "put my money where my mouth is".

For anyone else reading this - I'm happy to show you to a PA running in the "real world" in a small business environment. They're by no means perfect and as I said before the best security policy is to unplug the wire that connects your network to the internet however, if you have to connect to the internet (which is almost any business today) then PA is as good of protection as you can get.

Idmud - will you post the same? Even if you were correct (which you are wrong) and I worked directly for PA, why not post some REAL evidence of being able to compromise the PA firewall?

I am giving you an opportunity (genuine) to show you can easily compromise a PA firewall and your only response is that I'm obviously some PA employee that has come here to "market" their products and you won't respond? If you have a real "case" against PA, then it should be easy for you to respond.

I don't make a single cent from selling a PA. My money is made by supporting small business infrastructure and security. The LESS problems I have the more money I make. I'm a huge supporter of PA because they work.
 
Dell recently acquired Sonicwall so maybe in time we will see native english speaking support in the future like Dell has with their corporate support.

Since I posted that I have been in contact with Sonicwall support on a couple of small issues. Questions actually about some config settings with the new NSA 2400. Anyway I was surprised when I got a couple phone calls from a fellow in the U.S. identifying himself as "Dell Sonicwall support" in native english language.

It appears my prediction has come true.
 
Since I posted that I have been in contact with Sonicwall support on a couple of small issues. Questions actually about some config settings with the new NSA 2400. Anyway I was surprised when I got a couple phone calls from a fellow in the U.S. identifying himself as "Dell Sonicwall support" in native english language.

It appears my prediction has come true.

I can help with config issues and stuff :)

They really are trying to turn it around..
 
I work as a security auditor and I've come across them a few times. The "application" is http (web) which is allowed from the client segment to the external one. The backdoor software mimics a regular web session, as per a user would do.

The PA initially blocked the session, changing the User-agent string from Metapreter to a valid browser, be it Internet explorer, Mozilla, etc allowed the software to call home and establish a remote shell.

Specifying ACLs based on applications is NOT how you do it, you create an IP-ruleset and then, if you feel like it, apply applications to that ruleset. PA firewalls only look for the header information in connection attempts, that's another way of bypassing them. Start the session via http, change over to ssh or anything you feel like it because it's already added to the state table as a valid connection.

The way you describe them is exactly as per their sales pitch. It's not very professional defending products you sell on public forums, especially when you're dead wrong :D


If you truly is a professional security auditor then you shall be able to present some facts, otherwise your claims will just be seen as FUD (Fear, Uncertainty and Doubt).

Facts such as information of the DUT (Device Under Test) regarding which hardware (model), which software (firmware) and which databases (app, url and threat-db) were being used along with which data was being sent through the DUT so others can reproduce your findings.

But also how the security policies were setup...

If you use "any, any, allow" then of course traffic will be able to pass the firewall. Same with specific settings regarding how different identified threats should be handled. Did you for example use "default" as action for informational, low, medium, high and critical threats or did you use "block" as action?

Also did you (or the client) contact the vendor regarding this finding and what was their response (which any professional security auditor would do or would recommend their client to do)?
 
I won't respond to this. You've registered for this thread and come here to defend PA - You're affiliated with them in some way.

", I will happily put you behind a PA firewall with only HTTP as allowed traffic "

Do your marketing in some other way than on enthusiast forums, please.


And you are affiliated with some of their competitors in some way?

Regarding that DEFCON19 video here is part of the response I received when I contacted an Sales Engineer at PaloAlto Networks:

"
Claim: Application firewalling does not replace the need for IPS.

Absolutely true. There is no question that IPS technology is a requirement. App-ID is not intended to replace IPS or even reduce the need for it. This is the reason we have invested in building a best-in-class IPS functionality into the device. This is also why IPS is a critical piece of the next-gen firewall requirements.


Claim: Application cache causes traffic to be misidentified.

Not true. App-ID cache delivers performance gains without sacrificing accuracy. Application and protocol decoders validate the traffic on sessions identified using the cache, and if the validation checks fail, the cache entry is removed. The session is then switched out of the decoder and identified as unknown. Also, at short periodic intervals, new sessions are inspected by the App-ID engine regardless of the cache hit.

This handles cases where the destination/port may have been reused for a different application server. We repeated the test described in their claim by populating the App-ID cache with an entry for web-browsing by sending multiple HTTP sessions on the same destination/port. The SMTP traffic in a following session on the same destination/port causes a cache hit, is inspected by the HTTP decoder, fails validation checks, is switched out of the decoder, and reported as unknown. The cache entry is invalidated as part of this and the next SMTP session will be identified as SMTP.


Claim: Does not inspect both Client-to-server and Server-to-client directions of traffic.

Not true. Traffic is inspected in both directions. We repeated the test described in their claim, sending an HTTP GET request followed by a FTP server response on the same session. The session is initially identified as web-browsing but switches to unknown-tcp when inspecting the FTP server response, since the traffic is neither HTTP nor FTP.


Claim: Can evade Application firewall using client-server collusion by starting the connection as a permitted application and switching to another.

Not a genuine or valid test. The scheme devised in the test assumes both the client and server are already under the control of the attacker. We don¹t know of any real-world clients or servers that can talk HTTP initially and then switch to SMTP. In any case, App-ID has coverage for many evasive real-world tunneling applications and we continue to add coverage for more as we discover them.


Claim: Some applications can only be identified on specific ports.

Partially true. The application example given was DNS. The identification scheme for DNS includes a check for port 53 since we don¹t expect any real world DNS service to be running on any other port and since DNS traffic is often very short and difficult to reliably identify by signature alone. Non-DNS traffic sent to port 53, will be validated in the DNS decoder to ensure it is really DNS. If the validation checks fail, the session is switched out of the DNS decoder and identified as unknown.


Claim: Does not inspect traffic at Layer 7 when the Application can¹t be identified.

Partially true. Traffic that does not match any of the applications that we have coverage for will be reported as unknown and eventually stop being scanned for threats. The best practice for dealing with unknown traffic is to deny it in security policy. Customers using an application that we don¹t currently have coverage for, can submit a request for adding coverage for it in one of our weekly content updates, or create a custom App-ID on their own. Allowing unknown applications is a risk that other firewalls or IPS products cannot prevent.
"
 
What is your experience after been using PA for some time?

Here is a summary of my experience (as a customer) of things to keep in mind when you setup a NGFW:


* SSL-decryption (whitelistning).

PA uses a whitelist for certain CN so its SSL decryption wont block stuff that cannot be decrypted anyway (for example windowsupdate, which if being SSL-terminated wont function).

Current list is available at https://live.paloaltonetworks.com/docs/DOC-1423


* SSL-decryption (performance).

Previously due to the design of the PA-2000 boxes the SSL termination feature could overload the mgmtplane making bad things happen (for example wrong user being logged). This has been fixed (and is only mentioned as a historic reference).


* Commit times

Recently there are reports of commits taking as long as 20 minutes or more to complete for PA-2000 boxes. Discussions in the support forums believes this can have to do with to little RAM in the mgmtplane which makes the PA-2000 device to swap and therefor take ages to complete. As a sidenote a PA-5000 box takes roughly 5-10 seconds to commit the same ruleset (with AV, IPS etc enabled).

This is supposed to be addressed in upcoming PAN-OS 5.0 but rumours says that there will be a new device out shortly who will replace the PA-2000 series.


* Antivirus

This can be both good and bad but the AV feature in PA is streambased. Which means that there is virtually no upper size for how large the files who get scanned can be (compared to Fortigate) but at the same time not all file formats can be scanned streambased.


* Application identification

NEVER EVER use "service:any" (service is the PA name for port). Use "service:application-default" unless you can manually specify UDP/TCP and port/range your flow will use (however service:any can of course be used when you want to block traffic because you want often a block to be as wide as possible while an allow should be as narrow as possible).


* Application dependencies

Some applications, for example "Facebook", have dependencies towards other applications which must also be enabled for a particular rule to function. This gives that occassionally one are forced to open a bit too much (based on content of the flow/session).

This is said to be addressed in PAN-OS 5.0 who will better merge dependencies so you from 5.0 wont need to allow "web-browsing" just because you wish to allow "Facebook". The difference will be that the upcoming "Facebook" will allow as much "web-browsing" as needed for identification - if not identified after a few packet the "web-browsing" will no longer be accepted for the particular flow/session.

There are however workarounds for this today - you can combine the AppID being used with an url-filter and/or a url-category.


* User identification

The regular method of using dedicated userid/pan-agent servers will most likely not scale that well for enterprise use. You might consider install the userid/pan-agent service on each DC and lock it to only follow the security log from localhost.

That is because the userid/ip mapping is done by tailing/following the security log (events 672, 673 and 674 for Win2003 DCs and events 4768, 4769 and 4770 for Win2008 DCs) and when a user logins to the domain only the DC who authed the user will log its presence (the security log is not replicated within the domain for some odd reason).

With a network of just 2 DCs this is not a problem (even if you have 10.000 concurrent users). But if you have lets say have 50 DCs (with 10.000 concurrent users) the math will be something like (with 2 PA devices):

- Dedicated userid/pan-agent servers (tailing security log of each DC over the network):

50 * 5Mbit/s * 2 + 2 * 0-100kbit/s ~= 500Mbit/s network load (5Mbit/s is estimated network load to follow a single DC in an environment with approx 10.000 concurrent users).

vs.

- Userid/pan-agent installed on each DC (and configured to only read the local security log):

50 * 0-100kbit/s * 2 ~= 0-10Mbit/s network load (that is each PA device (2 of them in this example) will connect directly to each DC (who runs the userid/pan-agent service)).


* Testcase

In order to see how application identification works in real life you can use this simple test:

Setup a rule which will allow "appid:web-browsing" (basically any HTTP based traffic) along with "service:any" (yeah I know I said you should NEVER EVER use service:any in an allow rule but this is just an example :) along with a http server who listens at TCP81.

When the client sends a request such as "a b c" (instead of "GET / HTTP/1.0" which is more like a true HTTP request) the packet is allowed through to the server. Not until the server replies with "HTTP ERROR 400/Bad Request" the AppID engine will know that this flow/session is supposed to be a HTTP communication but "a" is not a valid HTTP request and the response will never reach the client.

Workaround for above (if you dont want the request to hit the server) is to deny "appid:unknown" but also create a custom AppID (application signature) or ThreatID (IPS signature) which demands that the "HTTP-Request-Method" should be HEAD, GET or POST (or which HTTP request methods you wish to allow). Another method (along with previously mentioned methods) is to use "service:application-default" or if possible "service:TCP80" (given that your server normally would listen to TPC80 and the stuff at TCP81 was some other service). You can also put a proxybased firewall inline with the NGFW device to further inspect the contents of the traffic (depends of course on how the proxyfirewall is being setup but still). There are some options which in combination can be a sufficient "workaround" to handle this testcase security wise.


* Vulnerabilities

NSS Labs discovered that an AET (Advanced Evasion Technic) named "split TCP-handshake" could bypass the IPS being used in PA. PA released PAN-OS updates addressing this issue the same day as the results from NSS Labs went public (v4.0.2 with v3.1.9 released a week or so later).

https://www.nsslabs.com/research/ne...ngfw/network-firewall-group-test-q2-2011.html


* Performance worries

Found at the PA forums:

"
Perfomance on PA 4060 - Huge Disappointment:

We are having a poc at an ISP with a 4060 . It is a huge disppointment performance wise . We are seeing very high dataplane utilization on very small sessions. 50% on 220,000 sessions. 38% on 149,000 sessions. This is a box that is supposedly can handle 2M sessions.

Palo Alto is claiming there is nothing wrong with the unit as it is performing as expected based on the traffic . I thought PAN isn't a UTM . It is looking more like one to me.
"

reply to the above (from another customer):

"
The utilization on its own is pretty much couldnt care less since you will have the virtually the same latency with one packet vs 100.000 packets (until it hits the roof).

As you can see with your figures using 149k sessions yielded 38% utilization on the fpga's bringing you a ratio of 3921 sessions per percent.

With 220k sessions you had 50% which brings you a ratio of 4400 sessions per percent.

According to some tests performed by NSS Labs in autumn 2010 and spring 2011 the tested PA unit (4020) yielded higher true throughput than stated in the datasheets:

http://www.paloaltonetworks.com/literature/research/NSS-Labs-Report.pdf
http://www.paloaltonetworks.com/literature/research/NSS-Labs-Report-2011.pdf

So the question here is how you have setup the test-network along with which settings you use in your PA unit?

Are you for example having extensive use of NAT's and PBF's and stuff like that?
"

ended with (reply from thread starter):

"
Sorry been busy . Well the box is holding . We are now averaging 600000 sessions and dataplane utilization is averaging 78% . We had another issue with very high utilization on the management cpu . It turns out we were logging 7000 records per second . Which was taxing the management cpu to the max . We had to play around with what we were logging and it has come down . The good thing is the box held with the 300% increase in traffic . That was our greatest fear and the POC is looking good.

Thanks
"

and:

"
Upgraded to 4.1.2 and did a load balancing with two PA 4060s and it has helped with the performance issue.
"
 
Two people registering to defend PA, jebus christ...

There are 2 people that have come here to challenge your claims and this is your only response. As I've said before, I'm not a PA employee or PA reseller. My clients purchase the PA boxes from a local reseller and I install and maintain them.

Specifically you've made 3 claims.

Claim #1 - changing the user agent was enough to bypass their IDP
PA firewalls are decent. Don't buy their sales pitch, they're not the best, but overall OK (changing the user-agent was enough to bypass their IDP).

The GUI is horrible, slow and awkward. However, they're good enough for a UTM device.

Claim #2 - It can't block software from calling home.
It can't block software from calling home, all it does is check the user-agent string for default, known payloads (meterpreter for example). Change it to Mozilla 4.0/something and it passes straight through their scanning.

It's a decent firewall, but it's in no way better than anything else on the market.

Claim #3 - start an HTTP session and change to SSH to bypass security
I work as a security auditor and I've come across them a few times. The "application" is http (web) which is allowed from the client segment to the external one. The backdoor software mimics a regular web session, as per a user would do.

The PA initially blocked the session, changing the User-agent string from Metapreter to a valid browser, be it Internet explorer, Mozilla, etc allowed the software to call home and establish a remote shell.

Specifying ACLs based on applications is NOT how you do it, you create an IP-ruleset and then, if you feel like it, apply applications to that ruleset. PA firewalls only look for the header information in connection attempts, that's another way of bypassing them. Start the session via http, change over to ssh or anything you feel like it because it's already added to the state table as a valid connection.

The way you describe them is exactly as per their sales pitch. It's not very professional defending products you sell on public forums, especially when you're dead wrong :D

I've told you who I am but even if Nir Zuk came into this forum and posted you should be jumping at the chance to prove your claims correct. What difference does it make if it's a PA employee or not?

There is no marketing hype here, just a legitimate real world offer for you to prove your claims to be valid.
 
Back
Top