Firewall Wizards mailing list archives

Re: FW-1 technical strength


From: Chris Brenton <cbrenton () sover net>
Date: Thu, 31 Dec 1998 08:55:47 -0500

"Stout, Bill" wrote:

This was a banner ad site with thousands of 'gets' to small images.  If
sessions weren't released quickly by the image database, the FW would lock
up due to tracking a high amount of concurrent sessions.  The connection was
a 10Mbps ethernet at a co-location site, FW-1 on an UltraSparc 2.

The default config supports a maximum of around 4,000 active sessions.
My guess is that you where exceeding this count (pretty scary
considering we are talking about banner ads). I seem to remember someone
over on the FW-1 mailing list mentioning they had a similar problem and
resolved it by increasing the kernel memory. This resulted in about a
100% increase in supported active sessions (if memory serves).

Rummaging around the Checkpoint knowledgebase for FTP, I found patch # 3,064
fixes an NT memory leak:

Hummm. 3064 has been around for about a year. You are complaining about
memory leaks that have been fixed? Is there anything outstanding that is
still a problem today?

Related to memory leaks, FireWall-1 3.0b Service Pack 8 fixes an SMTP memory
leak:
" 1. Fixed a memory leak in SMTP when using MIME stripping. "

I think we both agreed that the SMTP security server (ala proxy) still
needs *a lot* of work. I'd almost feel safer with Sendmail 5. ;)

"4. Large FTP transfers: If a file transfer through the FireWall-1 took more
than TCP_TIMEOUT (set by default to 60 minutes) the control connection is cut
 in the middle resulting in file transfer failure.

OK. I have to agree with you on this one but only to a point. The
default FW1 config has problems with FTP file transfers that take longer
than an hour. Now that companies like MS are releasing 70 MB patches,
this is more of a problem than it used to be.

The fix however is to simply change the value of one properties setting
(TCP time-out). Not what I would consider a major problem as any NAT
device will run into the same thing.

"*Stealth scanning refers to a method of port scanning where no TCP
connection is made.  Instead, a midstream TCP packet (for example, an ACK or
FIN) is sent to a host.  The details are specific to the host operating
system, but usually if a service is listening on a port, a RST packet will
be sent back.  Ports where services are not listening send either an ACK /
RST or do not respond at all."

Agreed this was a problem. FW-1 used to allow FIN traffic inbound just
in case there was a slow system that was trying to close a session that
the state table had already purged. This was pretty lame (not as bad as
some of the default properties settings, but pretty bad just the same).
My guess is that someone made a judgment call to err on the side of
being nice. Personally I would rather have a firewall that blocks
traffic. ;)

This was fixed a year ago with patch 3064 as well. 

The NSA protocol (standard) I inferred to was MISSI (Multi-Level Information
System Security Initiative), and ability to support FORTEZZA.

According to the FOCI rules, sensitive items can't come from a contractor
who may be under 'foreign ownership, control, or influence'.

Hummm. So the gripe is not with the level of security that the device is
capable of providing, just with who makes it.

Again, this all is out of the realm of
commercial security folk.  Even when directly asking agencies about FOCI
relevance to 'national infrastructure' installations, they won't give
quotable answers.

Agreed. Considering I have consulted to a number of FW-1 installs at US
military sites, I'm not even sure who this would even apply to. If the
military is using FW-1, what type of government agency is banning it?

One last thing, I did notice that Service Pack 8 seems to make FireWall-1
3.0b Y2K compliant.  Must mean all other versions of FW-1 are NOT Y2K
compliant (how often do companies update their 'set-and-forget' firewall
software?)

Not true. Just had a FW-1 install with patch 3064 pass a Y2K audit at a
financial institution. The deal is that the product only uses a 2 digit
year field for 19xx, but switches to 4 digits at 1/1/2000. Not my idea
of an elegant solution, but it made the auditors happy. Their concern
was that the product would continue to function normally after year 2000
which the product was able to do.

Cheers,
Chris
-- 
**************************************
cbrenton () sover net

* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet



Current thread: