Dana Nowell wrote:
>
> On Sat, 29 May 1999, Chris Michael wrote:
>
> > At 10:09 AM 5/28/99 , Larry Claman wrote:
> > > I won't comment on this, other than
> > >to say that many (most) security experts still distrust NT.
> >
> > And why is that, exactly? Is this distrust based on an analysis of how the
>
> I'd started a long list but Paul Robertson beat me to most of it. While I
> agree with Paul's post, he missed a few IMO.
>
> Ninth - Reliability/maintainability:
> A firewall is a 24x7 operation, rebooting everytime I bug fix the GUI, a
> minor proxy, or other piece of code is not a 24x7 option. I've run 24x7
> shops before (reboot every 6-18 months just 'cause, no kidding, been
> there). I expect a Unix box to be rebooted periodically just like any
> other. And due to the changing security picture, I expect that I'll have
> a 'high' patch rate on a firewall compared to an internal only production
> system that is tightly controlled. However, a reboot on practically every
> patch is not acceptable. Additionally if I added a new feature I have to
> reinstall the NT service packs, increasing the down time.
>
> Tenth - there's always some OS code so the OS counts
> The question was if all the OS code was replaced by the firewall vendor,
> what's the problem. Implication, the OS is not involved in the firewall so
> who cares. No vendor I know of on NT removes all the code from the adapter
> upto the active firewall, most use at least the NDIS drivers from Redmond
> (or the adapter vendor). So the question is moot (of course I could be
> wrong, if you think I am, see the next point).
>
> Eleventh - Reliability 2 (or why the OS counts anyway :-).
> Any OS code above the 'firewall' on the same box that causes the box to
> crash is a denial of service on the firewall. Consequently, a pretty blue
> screen on the NT firewall due to a GUI error while looking at a log or
> other user operation implies a firewall stability/usability/reliability
> problem. I've NEVER panic'ed a UNIX box while using cat, tail, head, grep,
> more, or vi via telnet or the console. I have been blue screen of death'ed
> before, usually at a VERY inopportune time.
Money is the real issue. "The firewall crashed, but we got it
back up in three minutes" dosen't count when sombody lost a
telnet link to the system where a large database update was in
progress. Yes, if you are using any sort of IP number translation.
If the firewall crashes, all the links through it at that time die.
This is because the information translating the addresses goes away
when it dies. If it can't give you 24x7 reliability, don't use it.
It just isn't worth it. If firewall crashing causes 25 links to be
lost over a 1 year period, each costing 1 hour of lost work. Then
it is worth it to buy a $2500 specialized firewall box. Lack of
reliability costs money.
A major don't on firewalls. If you have access a DB through a
firewall that may crash, don't use IP address translation of any
sort to access it. That is either IPPORT Forwarding, or
Masquerading. If the firewall goes down, the link to the DB goes
down with it. That can cause major problems and frustrations for
your users as well as lost time. Give both the DB server, and
it's users real IP address and just screen/route between them, or
arange for both of them to be on one side of the firewall.
Masquerading/IPPORT forwarding are good if the standard connection
through them is of short durration, but as soon as a connection
wants to last much more than an half hour, then they start to be
problematic due to firewall crashes and timeouts.
The only reason I'm using a Linux IPCHAINS based firewall at home
is it's cheep, and I don't need high reliability for my home DSL
link. Now granted, it's only crashed twice. Once to a static
jolt, oops, and once to a mistyped command, again oops. Otherwise
it's been down twice sence Feb. Once to install the UPS, and once
for a kernel patch.
--
| Bryan Andersen | [EMAIL PROTECTED] | http://softail.visi.com |
| Buzzwords are like annoying little flies that deserve to be swatted. |
| -Bryan Andersen |
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
