RE: FW-1 technical strength

["Stout, Bill" <StoutB () pios com>]

> ----- Original Message -----
> From: Chris Brenton [SMTP:cbrenton () sover net]
> Sent: Wednesday, December 30, 1998, 12:52:55
>
> "Stout, Bill" wrote:
> >
<snip>

> > 3.      At one web service bureau, unserviced requests overwhelmed the
> > filter tables, causing the firewall to lock up, requiring hard reboot 
> every
> > two to four hours.
>
> I would need a bit more info to comment on this one. Are we talking T3+
> with 1,000+ connections/sec or traffic that is more in line with the
> average connect speed? 
<snip>

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.
 
> > 4.      Some NT systems apparently had memory leaks, locked up, and 
> required
> > occasional reboot.
>
> This is not a feature?
:^)
> I would guesstimate I have 30+ FW-1 installs running on NT out in the
> field. None (that I'm aware of) have memory leak problems and typically
> run for months without a reboot (OK, this is about 1/3 the running time
> of the Sun installs, but we are talking NT after all ;)

Rummaging around the Checkpoint knowledgebase for FTP, I found patch # 3,064
fixes an NT memory leak:
"1. Executing alerts on Windows NT creates system memory leaks."

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. "

<snip>
> > 6.      Tough time doing large FTP sessions through it, FTP transfers 
> would
> > often die.
>
> Humm. I've heard complaints about this but have never run into it with
> one of my installs (NT or Sun). Even while using NAT & passive transfers
> from a DMZ server.

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

"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. After installing Patch
3055, if you 
 need to transfer files for more then TCP_TIMEOUT, you need to modify the
file 
 $FWDIR/lib/base.def changing the line '#define FTP_CONTROL_TIMEOUT
TCP_TIMEOUT' 
 to '#define FTP_CONTROL_TIMEOUT <seconds>' where <seconds> is the number 
 of seconds you want the control connection to remain open."
 
> > 7.      It allows stealth scanning of the internal network since FW 
> response
> > for existing nodes differs from non-existent nodes.
>
> I would love to hear a bit more detail on this one. I agree with the
> stealth scanning *if* you leave the default properties settings in tact.
> Your comment 
> "since FW response for existing nodes differs from non-existent nodes",
> are you referring to SYNDefender? If so I'm not sure how this would
> matter as SYNDefender can create a positive session response for all
> service requests, even for services that do not actually exist. IMO the
> SYN relay mode is one of the best tools available for making scanning
> pretty useless.

> From NSA X3 TECHNICAL REPORT X3-TR001-97 Check Point Firewall-1 version 3.0a
Analysis and Penetration Test Report (was posted on http://mitten.ie.org/):
"For unestablished connections, packets with the SYN or RST bit set are not
allowed through (so a new connection cannot be initiated from the outside,
and existing inside connections cannot be aborted).  All other packets are
rewritten at the firewall with the URG bit set and a "mangled" sequence
number.  (This appears to mean subtracting 10000 or 20000 from the sequence
number).  The data portion of the packet is also removed.  The resulting
packet should be rejected by the target machine since the TCP sequence
number is not correct.  If there was not an active session on that port, the
machine will either not respond or will generate a RST.

If the firewall is configured to allow packets from the inside to the
outside, the RST would be seen on the outside.  This configuration could be
used for stealth scanning* through the firewall."
 
"*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."

> > 8.      It was going through qualification for use at U.S. government 
> sites
> > since it had some NSA protocol support, however FW-1 is made in Israel 
> which
> > is an occasional ally
> <snip>
>
> Not the first time I've heard that FW-1 has been *banned* from use by
> the US government. I still have yet to see an active link that shows
> this to be true however. I also know that CP has responded to this
> allegation at least once before claiming it was false.

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'.  MISSI protects
classified data within protective layers, separated by equipment such as
firewalls or features in an O.S..  That equipment is considered 'sensitive',
and the vendor should not be under 'foreign ownership, control, or
influence'.  Security products in general are considered 'sensitive', and
fall under government FOCI rules.  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.  The concern is that other countries may trojan security
products like the NSA was accused of with Crypto AG.  (Those who know me
note I'm wording carefully here).  ;^)
http://www.qainfo.se/~lb/crypto_ag.htm

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?)

"2. Fixed Year 2000 bugs in select and find functions in the Log Viewer.
With this fix, all known 
 Year 2000 limitations on FireWall-1 3.0b are closed. "

Happy new year,

Bill

May 9/9/99 not mean infinity on your system.