Great Circle Associates Firewalls
(July 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Sidewinder Versus EagleRaptor
From: Bill Stout <bill . stout @ hidata . com>
Date: Tue, 16 Jul 1996 17:22:58 -0700
To: Firewalls @ GreatCircle . COM

I believe that NT will become the 'King O.S.' in a few years, and as 
more bugs are found/fixed in the unpublished source, it may even 
become secure.  However (I have) both security and functionality 
requirements for a Firewall that Eagle NT/NT does not (yet) meet.  
Eventually it will be capable of supporting security conscious sites.

Read on if you like apple to oranges comparisons.

...

At 04:40 PM 7/16/96 -0500, you wrote:
<much snipped>
>TIS on Unix and Eagle on NT are different animals.

Just wanted to be clear on that.  Different products for different
applications, and market segments.  

Firewall professionals currently use UNIX.  Period.  Small office 
environments with low security requirements, little functionality 
and having low technical skills would use current NT solutions.  
A nice job if you can get it, but an easy environment to hack into.  

The documentation for Eagle NT says nothing about not being a domain
member(dangerous), only about not being an NT PDC or BDC.  Breaking
into a LAN shouldn't allow you to break into/log into a Firewall.

BTW, does; 'C:\ nbtstat -a 204.7.243.x' on an internet PC return 
users/processes on a Eagle NT system?  

Can NT 4.0b1 browse all files on a Eagle NT system with 3.51 and sp3?  

Can you run a webbrowser on an Eagle NT system and browse your Firewalls' 
registry at http://dev1.ora.com/andcgi/wregcgi.exe?

Don't know?

>...Sendmail is too buggy to even suggest
>running it on your firewall (even if one claims to have fixed all the bugs
>in the quarter million lines of code).  

Nope, firewalls typically don't have sendmail connections on the outside.  
But as a mail relay host sendmail is required on the inside.  Sendmail 
itself isn't buggy.  A non-sendmail knowledgeable administrator will 
blame sendmail for his e-mail errors.

>That is why we developed the SMTP
>proxy.  It doesn't just patch things through.  It filters out
>unsafe/unnecessary SMTP commands and it also looks for and prevents the
>buffer overrun addressing attack. 

The presence of an SMTP mail relay host is a requirement for any company
which wants to send mail via the Internet.  A small office may get away
with using a SMTP Gateway, but I believe that the SMTPd proxy entry in 
proxy.cmd only allows a single host entry for SMTP.  Gateways also strip
fields from messages, akin to crumpling and unfolding a letter each time 
it passes through a gateway. A full SMTP command set is also required for 
a site making full use of SMTP.  

>...Also, the sendmail server on the firewall
>would slow down the overall performance due to hitting the disk.  Our
>philosophy is to try and never touch the disk.  This philosophy seems to
>have worked since we tested out to be the fastest firewall tested in the
>DataComm performance testing.

No brainer there.  Of course removing functions lower overhead.  The less
your firewall does, the faster it is at doing nothing.  (Chuckle)

Now just think if you could program it all in a VLSI chip set.  Pretty soon
the thing would be as fast and secure as a router.  ;)

>>                                                   · rlogin
>>                                                   · rsh
>>                                                   · X-11
>>                                                   · Finger
>These have been documented everywhere as things you just don't enable.
>That's why we disable them.  Our GSP can generally handle the passage of
>them.  Does the TIS proxy support for this do more than just pass them
>through?  Creating a completely separate proxy is not real useful unless it
>is doing something intelligent like filtering out commands or data that are
>considered unsafe or opening and closing ports dynamically or performing
>user authentication.

Nope. Using Gauntlet as an example, rlogin is authenticatable.  Rsh is not.  
However these proxies are directionally knowledgeable and are always(?!?) 
used only in outgoing situations, never incoming.

If you have ever worked^H^H administered in a development company, you know 
how precious some of these applications are to the developers.

>>                                                   · Printer
>>                                                   · POP3
>Our GSP would handle these.  Not sure what a new proxy would do to secure
>them any further.

A proxy would allow one to make outgoing connections to remote printers (vs.
faxing) or in from the internet for remote users to connect to the mail server.

>>                                                   · Administrative GUI
>(info-gw)
>>
>A proxy for a admin GUI?  I guess you might say we support this in that our
>current beta release of EagleNT supports the "remote management" feature of
>the firewall that we have in our Unix version.  

The 'Hawk' administration tool only runs on the firewall locally.  There is
no remote management in the current version of Eagle NT.  

>It uses an encrypted
>connection back to the firewall.  I understand from the LAN/Times article,
>assuming it is correct, that the most critical functions of the TIS cannot
>be done from the GUI - not true for our GUI, remote or otherwise.

TIS does need to do work on their GUI.  Must not be many webmasters in 
Virginia.

>>Non-proxied service for NNTP, Whois, Real Audio, quotd,
>>(unauthenticated, directionally savvy port 'service(s)'):
>>
>>  · Proxyd                      · plug-gw
>>
>>Eagle also includes 'Generic pass-through', an unauthenticated, 
>>directionally clueless open port 'service'.  Must be the only 
>>'real way' to punch a hole in your firewall.
>>
>Actually the GSP is direction aware and must also be allowed by a rule
>(which can authorize based on src/dst, and time of day.  

Nope.  You're confusing your Proxyd with your GSP.  I hate when that happens.

>...Mainly because most services that it
>passes are not authentication aware like NTP, NNTP, POP3, etc.  If its an
>interactive service, then you could probably use our TELNET proxy configured
>via "Custom Telnet" which allows you to telnet to a port other than 23 and
>would support authentication.

That's what your Proxyd is for.

>>Authentication methods supported:
>>
>>        Eagle NT                     Gauntlet
>>      · S/Key                              · S/Key
>>      . Password list              · Enigma Logistics devices
>>                                               · SecureID (Security Dynamics)
>>                                                · SecurNet (Digital Pathways)
>>                                                · CryptoCard
>>                                               · DigiPass
>>
>As noted before, at the time of the NT port, SecureID did not have support
>for NT clients.  I noticed that Cryptocard does support NT now, not sure if
>that was true at the time of our port.  Digital Pathways just announced
>support for NT in March, I would assume it wasn't really production shipping
>until a little later.  Bottom line, our Unix port supports most of the above
>except DigiPass and Enigma.  The EagleNT version will roll in the others as
>the vendors support an NT version of their client code (actually a few
>months later due to development and test time).
>
>I would add a few more items to your list (and I will use the current beta
>version of our EagleNT) to compare against and I don't know the answer for
>TIS on some of these and have just guessed:
>
>                                                Eagle
>TIS
>
>NT version of F/W                   Yes
>No
>(The last I talked to TIS, they did not have an NT port.  Another vendor
>offers a port of TIS on NT, but do not know how it compares to the Unix
>version).

I breathlessly await the day TIS ships an NT Gauntlet package.
I also breathlessly await public NT source code from Microsoft.
Nah, I think I'll start breathing now...

>DNS Proxy                               Yes
>No
>(This is the ability to create a split/dual-level DNS on one system.  We
>have found that a very significant portion of customer support is related to
>debugging someone else's DNS environment.  The DNS proxy allows a customer
>to create the public/private DNS desired, but with one server running on the
>firewall and with a simpler syntax for the database files).
>
>Automatic OS Hardening      Yes
>Not sure
>(Our software auto-installs and turns off all networking services, disables
>all user accounts other than administrator/root and turns off IPX and
>NetBui.  It also installs IP level code to perform anti-spoof and
>anti-source route code.  I would guess that the TIS package does not
>automatically do all this - if it does, great stuff.)

Yup.  Gauntlet does grind through the O.S. and finds stupid mistakes or other
things it doesn't like.  Compliments of Marcus Ranum, I believe.  However 
I do dislike Gauntlet expecting a local compiler.

>Continuous Integrity Check  Yes
>Yes
>(Where we automatically and continuous checksum our executables (MD-5),
>continuously check for unauthorized services and continuously disable IP
>forwarding/routing.)                     
>
>SNMP Traps on logging       Yes
>Not sure
>(We can notify a central network management station via an SNMP trap for
>some or all of the log entries.)
>
>Suspicious Activity Monitoring  Yes
>No
>(We continuously monitor the firewall for suspicious activity and create
>alerts and also perform automatic traceroutes back to the source of the
>suspicious activity).

Gauntlet does send e-mail to the admin containing security alerts.  Any
firewall that logs permitted access, and reports denied access can be
reguarded as having 'continuous suspicious activity monitoring'.  What 
makes Eagle NT different is the ability to log additional entries in the
logfile which meet user-defined thresholds.  The value of these are 
debateable, since user access varies greatly day-by-day.

>DEC Alpha NT Support           Yes
>No

That's moot, since both packages support different platforms, except Intel.  
Pentium Pros are now very close to Alpha system performance.

>TIS is a good firewall.  They wouldn't be in business if it wasn't.  The
>main difference noted in LanTimes is that Raptor is, as a whole, much easier
>to install and maintain verses a TIS installation.  We also directly support
>the NT port, TIS doesn't (the last time I checked).
>
>Best regards,
>
>Dale
>     
>===============================================================================
>	Dale Lancaster 		Web: www.raptor.com
>
>	Raptor Systems		"The Eagle of Firewalls"
>	dlancaster @
 raptor .
 com   	
>	(214) 423-6212	  	Eagle - LanTimes "Best of Times" Honor - July 1996
>===============================================================================
>
>
>
<=======10========20========30========40========50========60========70========80
William B. Stout       | Major revelations:
Senior Systems Admin   | "All objects are part of a larger object."
Hitachi Data Systems   | "3 aware beings comprise a person; mind, body, spirit."
NT/UNIX/I-net/Routers  | "The secret of life: To be involved with 'creation'."
408-970-4822           | Infowar, Cyber-war, yes, 'they' are out to get you...
--------------------------------------------------------------------------------



Indexed By Date Previous: Re: Hey! Admin! List owner! Yeah, YOU! (fwd)
From: Bastian <bastian @ net2 . netacc . net>
Next: Re: 'ntsecurity' list ref
From: Michael Ryan <mike @ NetworX . ie>
Indexed By Thread Previous: Re: Sidewinder Versus EagleRaptor
From: Dale Lancaster <dlancaster @ raptor . com>
Next: Re: Sidewinder Versus EagleRaptor
From: Dale Lancaster <dlancaster @ raptor . com>

Google
 
Search Internet Search www.greatcircle.com