O'Reilly: Evaluating Firewalls

> Why do these evaluations always consider lack of GUIs and colorful graphs a mark against an application?

Because it evaluated the products from three perspectives, Enterprise, Small Business and Home user. In the Enterprise it's often not difficult to find someone who can find a text based interface manageable. In a small business or home situation however, the odds swing the other way making a lack of a GUI very unmanageable and foreign. As such when including areas where a UNIX admin is not usually found, a CLI is generally going to be counted as a failing.

As for graphs, no matter how good you are using a cli a graph presents basic information (if properly done) very quickly. A management interface that polls and graphs the results can be checked and understood quickly and left to run on a station where it can be seen by everyone who needs access to that information.

However, it is true this isn't that much of a failing of PF. PF's logging facilities have made it possible for many front ends to be written for it that will graph information in just about any way you need. So while OpenBSD and PF on it's own will not draw graphs for you, you can probably find an application that provides you with the information you want, whereas many canned logging and graphing features in some other firewall products may not be as flexible.

> Why do these evaluations always consider lack of GUIs and colorful graphs a mark against an application? I'd like to know where in the rulebook it states "GUI good, CLI bad."
>
> Why don't functionality and manageability by themselves determine how a product ranks? If my experience using and managing the product is good, then I give it high marks -- regardless of whether it has a GUI or pretty graphs.
> A number of Pix admins I know refuse to use the Pix management GUI and stick to the CLI. Whether or not PDM was around wouldn't impact their assessment. And I know a number of firewall admins who consider the fact that Check Points can't be managed flexibly outside of the GUI a mark against the product.

word! pf syntax can be read and understood if you're capcable of reading and understanding simple english. one reason why checkpoint and others lack thiss sophisticated grammar, that's why they need gui's; ever tried to convert checkpoint .c files to something different, readable? welcome to hell if so.

>
> I realize that it's a matter of personal preference, and that some people are GUI oriented. But that's not everyone. Some people, like me, rate the application higher if there isn't some flashy GUI to have to click through in order to manage something which is intrinsically simple.
>

gui constrain me, comfort == shell/vi



> PF rocks, plain and simple. I consider the fact that I can manage it using nothing more than my shell and a text editor over SSH more usable than other options.

> Why do these evaluations always consider lack of GUIs and colorful graphs a mark against an application? I'd like to know where in the rulebook it states "GUI good, CLI bad."

Because there is more to the security business than just functionality.

In most organizations, you will also have to deal with non-informed management types, and most of them insist on getting meaningless graphics that show them that they are in charge (heck, I've even seen one tech-wannabe wanting to register a patent on some basic `manager security dashboard' idea).

In many setups, if you want to have better security, you're much better off if you can get upper management to stop breathing down your neck. Considering that these people have no technical background (or forgot their brains at the entrance when they turned management), you can expect some pretty meaningless AND time wasting requests from them.

Remember, every hour you spend painstakingly putting together a `risk assesment and this month's attack summary does not cost them ANYTHING, since it's not taken off their work time, and they will be quick to dismiss it, stating that `it's obvious to build, so it's taken five minutes of your time, right ?' (for stuff that usually takes half a day or a full day to produce.

Cisco understands this perfectly, and delivers manager-ready firewalls, which ALSO do the technical part reasonably well. It can be misconfigured, and it has holes, but the default configuration is moron-accessible, and you can build reasonable VPNs out of them with very little technical training.

OpenBSD doesn't compete in that market. It's not the project's goal. Any enterprising company CAN grab the OpenBSD base and produce some manager-ready tools out of them. In fact, quite a few companies do. Peered inside an `all-in-one' firewall recently ? Once you scrape the labels, you will find a Linux/FreeBSD/OpenBSD inside (if you're lucky, it will be OpenBSD).

For the time being, it looks like no free software project has this kind of product as a goal, they're all commercial...

PIX firewalls (at least up to all the 6.x OS versions) do not filter from higher security level interface (usually inside lan interface) to lower security level inteface (usually outside/internet, DMZ interfaces) traffic at all.
CRAP! Read the Common Criteria TOE documentation for 5.2 and 6.2 versions.

> I read the article and I was disappointed. Bottom line: The article s very misleading: It's very shallow, lacks details and inaccurate: PIX firewalls (at least up to all the 6.x OS versions) do not filter from higher security level interface (usually inside lan interface) to lower security level inteface (usually outside/internet, DMZ interfaces) traffic at all.

What?

access-list outside_acl remark some filtering rules here
access-list outside_acl ... permit and or deny some stuff
access-list inside_acl remark some filtering rules here
access-list inside_acl ... permit and or deny some stuff
...
access-group outside_acl in interface outside
access-group inside_acl in interface inside

voila, higher security to lower security filtering

> People actually use Smoothwall? I guess my question is, why?

Presumably, because it offers reasonable protection for a very modest investment of time (learning) and money (can run on most any hardware).

Or was your question 'why do people use Smoothwall instead of (favourite firewall 'distribution' of choice)'?

Joachim

> This article is basically pointless. What the hell does that mean to make an article on 3 "firewalls" with totally different goals? This article is just yet another attempt to try to make some readers with useless information.
> I just noted they said that OpenBSD was the best one if you don't need fancy useless stuff like graphs or GUIs.
>

I agree... Comparing 3 firewalls with the depth they covered is like comparing 3 cars... 1 minivan, 1 corvette, and 1 motorcycle... which one is the best for every person out there? How is that possibly a question anyone asks themselves, let alone needs an entire article to find the answer to?

I think a more precise comparison (say, more firewalls, or just one topic about the three like VPN tunneling or transparent bridging capabilities) would go a long way to improving the value of the article... and they probably had the knowledge to write about such things.

> So, let the brainless point and click get hack(sic) and the serious one do it right and simply with full control.

Pity for the rest of us that the brainless who point, click and get hacked are the very same who unwittingly generate the tsunami of spam and targetted DDoS attacks that is the daily routine on the internet.

> I would love to try openbsd but can users give their examples of usage in regards to packets per second and system utilization? with and without ruleset.
>
> what hardware is required for >20kpps?

It depends on the complexity of the ruleset, its optimization level (even if pf automatically optimizes rulesets a good ruleset design helps yet) and, of course, the mean number of rules required to process each packet. I think that you will need to do some testing yourself.

If in doubt, buy the best hardware (computer and NICs) you can afford.

20KPPS is generally a meaningless measure use for Router. Anyways, here some experience.

Like for a Cisco PIX, 20 KPPS might be easy or hard to do. If you want to replace a PIX 515E, likely any Pentium 1.5 Ghz or better will do the job fine. What is CPU intensive on a firewall like PF or a PIX is not really transferring packet but the number of STATE (new connection) that must be created every second (how many time per second the ruleset must be interpretted and how long this ruleset is on average).

At 20 KPPS (real and sustain), one of the determining factor is the quality of the Ethernet Card. Cheap 15$ card of the 10/100 Mbits/s variety can cause problems, especially with cheap (50$ switches). Otherwise, I have good experience with many Intel and broadcom chipset.

XEON 2Ghz -- IPSEC + PF at 6KPPS (40 Mbits), Less than 40% CPU Cycle. Now, I believe that IPSEC cause much of the CPU consomption. This server is also doing others task,

XEON 2 Ghz -- More than 1000 PF Rules. The base load of this system is 1KPPS generated by over 1000 Workstation (when nobody is at work). Basically, the system is idle at this load <1% or 2% CPU. This system experience subtain peak of over 35 Kpps. It CPU Cycle consomption is generally less than 20% in steady state. Rules are not optimized for performance, frequently modified or added wihtout any consideration for performance. This server also run ALTQ queuing, SQUID, SMTP, Routing BGPD and RIPD and some more.

I have Pentium II 450 Mhz that sustain over 20KPPS in specific scenario (4 100 Mbits/S interface). However, there is cases where you will see the CPU peak at 100%. I am not even sure that this is related to PF.

Sorry, I have no experience of OpenBSD machine without ruleset. Even my Pentium 133 at home have a ruleset of over 200 PF rules. Even this machine experience peak in excess of 2KPPS.


> I would love to try openbsd but can users give their examples of usage in regards to packets per second and system utilization? with and without ruleset.
>
> what hardware is required for >20kpps?