Info about FW1 (long) was RE: [SunRescue] Ultra 5 questions

Sat Nov 11 09:42:49 CST 2000

On Fri, 10 Nov 2000, Reagen Ward wrote:

:Imagine a dual 200 (I think) U2 running FW-1 for 5k people.  Bad load,
mostly
:due to mutex contention.  FW-1's kernel mods aren't multithreaded.

AND

Jonathan Katz wrote on
Friday, November 10, 2000 6:54 PM

"Yeah-- FW1's lack of "thread()" is baaad, mmmkay." </mackey> We've had
to advise folks several times that getting a box like a 220R or 420R for
a firewall [running FW-1] and planning on throwing more procs in it when
load gets higher won't work.

The other solution is to off-load all firewall services from the single
firewall box (which a surprising amount of people don't do.) They'll throw
the SecurID authentication client, web proxy, and mail-proxy all on the
same box.
---------------------------------------------------------------------------

On the whole topic of FW1, Im  a CCSA, CCSE, and CCSI. I used to be a
consultant for a company whose primary business was implementing and
training people on firewalls in general, and I was the Sr. Engineer for all
of the northeast US. I have been involved in some of the worls largest
security architectures, with the worlds largest companies, aand state and
federal governements. I also used to write articles about security,
operating systems, and firewalls.

Okay self glorification over, lets get to the good stuff.

Straight FW1 i.e. kernel inspection, which consists of accept, reject, or
drop, is actually very light in the processor load department. I've
succesfully put 1000 users through an SS20. The problems with FW1 and
resource utilization come up in three areas.

1. Logging: The higher level of logging you do the more load you have, and
it isn't linear. Short logging all your rules can produce enough load to zap
IDE drives if you have more than a few hundred users. Long logging more than
doubles that load. Account logging, trap logging, emailing, or custom
logging can increase load by a factor of 10 to 20

2. Content security: Under normal circumstances all FW1 inspection occurs as
a ring 0 process, as a wrapper around the network layer. If content security
is implemented (cvp, ufp, uri etc...), an agent has to be run in userspace,
and inspection has to occur both at the sub network layer, and at the
application layer. This increases load by a HUGE amount. I have seen cases
where it mulitplied the total load by a factor of more than 20

3. Encryption: FW1 does encryption in the kernel, which makes for very
efficient processing, but it also means that it's a process with a very
nasty priority. If you are encrypting on your FW1 box don't expect to be
doing much of anything else including processing logs. Unless you manage to
get a VPN accellerator card, which are actually very useful in their most
recent revisions

All that being said the best thing you can do for FW1 is split your policy
enforcement (firewall module) and your management and log processing
(management module)

I highly recommend that for the actual firewall itself you use a nokia box.
THey are the most efficient and cost effective way of running FW1. You then
run all your management services on a multiprocessor Sun machine with fast
scsi I/O.

MP can help you with FW1, and heres why. Though FW1's kernel module isn't in
and of itself multi threaded, it breaks up all it's functions abouve the
kernel into several different processes, which can and will balance across
multiple CPU's if the OS is good at managing process allocation.  This is
especially important for log processing, and content security. Also even
thorugh FW1 processes arent multi threaded, other OS processes are, and
while the firewall is busy hogging one whole processor your os can
redistribute much of the load it produces to other processes. This is
especially useful for FW's running encryption, or if you have other services
running on your firewall (don't, trust me)

A few more tips,

1. never install your CVP or UFP services on the same box as your firewall
or mgmt server
2. Dont run the GUI on your management server, your log viewer will take
forever to come up, and if you ever have to view a selection fugheddaboudit
3. I'll say it again, split your management server and firewall
4. If you must use a sun machine as your firewall module, make it an ultra 2
(sbus and scsi) or an ultra 60 because of the SCSI and 64 bit pci slots, not
because of the MP aspect.
5. Dual processors won't help on your firewall unless you run CVP, but they
help quite a bit with your management server, especially if you run CVP or
high load logging. They will also halp a bit if you run your FW and Mgmt
server on the same box (once again, don't, trust me)
6. Dont run any other services on your firewall module
7. Especially dont run any proxies on your firewall. Stateful inspection is
designed to manage session from client to server, not from client to proxy
to server. Unless you know exactly how to configure your rules your proxy
will bypass FW1 inspection, and the load imposed by having both installed on
the system will make for an unhappy firewall.
8. RAM is king. FW1's stateful inspection maintains connection state tables,
encryption, and logging in RAM. The more RAM you have the happier you'll be.
The absolute minimum RAM for any happy firewall on Sun is 256 megs, with 512
being my recommended minimum. Nokia systems are a lot more efficient so can
get away with far less ram, but I still recommend maxing it out if you have
the budget.

In my architecture I have 150 sites with 2 nokia IP330's at each site
running VRRP for HA failover, and two nokia IP650 with vpn accelerators at
the NOC, with a 3DES isakmp vpn mesh between all locations. Everything is
being logged with traps, we have an IDS on each firewall, and we are running
CVP and UFP on the NOC firewall. All traffic to and from the remote sites
goes through the noc. All of this is being managed by a pair (in failover
configuration) of rave AXmp boxes with 2 gigs of ram and dual 440mhz/2mb
cache ultra sparc IIi, and an FC storage array for the logs. Only 15 of the
sites are live right now. Once we reach 50 sites live (prolly end of
calendar Q1 next year) I'll bring on another HA pair, and then a third once
the whole 150 site mesh comes online.

As far as we know this will be the largest single user (i.e. non service
provider) nokia firewall installation in the world when we are done.

Chris Byrne

-----Original Message-----
From: rescue-admin at sunhelp.org [mailto:rescue-admin at sunhelp.org]On
Behalf Of Jonathan Katz
Sent: Friday, November 10, 2000 6:54 PM
To: Reagen Ward
Cc: rescue at sunhelp.org
Subject: Re: [SunRescue] Ultra 5 questions

On Fri, 10 Nov 2000, Reagen Ward wrote:

:Imagine a dual 200 (I think) U2 running FW-1 for 5k people.  Bad load,
mostly
:due to mutex contention.  FW-1's kernel mods aren't multithreaded.

"Yeah-- FW1's lack of "thread()" is baaad, mmmkay." </mackey> We've had
to advise folks several times that getting a box like a 220R or 420R for
a firewall [running FW-1] and planning on throwing more procs in it when
load gets higher won't work.

The other solution is to off-load all firewall services from the single
firewall box (which a surprising amount of people don't do.) They'll throw
the SecurID authentication client, web proxy, and mail-proxy all on the
same box. Alex Noordergraph's "N-Tier" whitepaper has been a bible lately.
It's one of the blueprint series: (http://www.sun.com/blueprints)
http://www.sun.com/blueprints/1000/ntier-security.html is the "N-Tier"
document in question... [ that doc talks more about splitting up an
e-commerce environment and not a DMZ environment, but apply the same kinda
rules...]

But as for the FW1 stuff...
[ dons sales hat ]
EFS is free with Solaris 8 for limited use (I don't know the license details
off-hand.)

-Jon
--
Jonathan Katz
e-mail: jon at jonworld.com
website: http://jonworld.com
proprietor: http://bachelor-cooking.com
Cell: 317-698-4023 * Pager: 800-759-8888 1770869 * FAX: 530-688-5347