Archived from groups: comp.security.firewalls (
More info?)
In article <6j9ad01jnoh069hs70d5llf73579vkmhk7@4ax.com>, mrozium@XSPAMX-
yahoo.com says...
> Leythos wrote:
>
> >The appliance has the proxy as one of the rules you can use - it's a
> >better option than a system running a app to do it. Less chance of it
> >breaking or being misconfigured - less chance of a parts failure too.
>
> Understand that I'm not trying to be argumentative, but claiming that
> an appliance has the exclusive distinction of being less likely to
> fail or be misconfigured is taking great liberties with the truth.
> Anything that can be configured can be misconfigured. Just because
> it's "point-and-click" doesn't make it less likely to be
> misconfigured. The person responsible for the configuration is the
> mitigating factor here, not software. Untrained people should not
> configure firewalls. Parts failure is pretty much a non-issue. Do
> you run your servers on appliances? I've heard those battle cries,
> and quite frankly, neither hold much water today.
Taking your statement - anything that can be configured can be
"misconfigured" - there are MANY more things to misconfigured on a PC
based OS/Firewall combination than a Appliance. Now that we've settled
that a Appliance is less likely to be misconfigured, we have the number
of parts - the appliance is almost always going to have less parts, and
the parts it does have are more likely to be of higher quality than
those in a PC/OS based firewall. Assuming the same level of competence
in the individual, you are statistically less likely to have a problem
with the appliance than the PC based firewall system.
> >> >We've not had to update the firewalls, the rules, once in place, are
> >> >something that covers all of the problems that already come up. If you
> >> >block .EXE you never have to go back and update the firewall to keep
> >> >users from downloading and running .EXE over HTTP/HTTPS or SMTP.
> >>
> >> I see. That would never work in any environment I've seen, as all the
> >> companies and government entities I provide security for *must* be
> >> able to download files, including executables. Especially for M$
> >> updates. Users are only allowed to run approved programs, but that
> >> rarely ever stops today's worms/viruses. Of course, that's one reason
> >> why it's so important to employ a good anti-virus solution.
> >
> >AV is a day late in most cases - the definition files don't come out for
> >the new viruses until a day after they hit the mainstream.
>
> I agree, but I still use it. Don't you? Besides, it's hardly a
> firewall's job to provide anti-virus solutions. Otherwise, we'd be
> constantly updating our firewalls, right?
Where did you get the idea that I don't use AV software - I've used AV
software on every computer everywhere. In fact, I happen to like the
Symantec Small Business Edition 8.1 / Exchange platform. As I said, they
are reactionary when it comes to NEW virus definitions. A properly
configured attachment filter based on extensions will prevent more email
based viruses than a definition file (due to the delay in creating
definitions for new viruses).
One thing that WG has done since the early days is provide the ability
to filter email attachments - no other vendor offered this feature at
the time, and many still don't. This one feature alone has saved more
clients that any other measure I know of. Even when you have AV
software, the updates come out AFTER the virus is known, and that can be
several days or more. If you block executable attachments of all types
then you are 200% ahead of the battle.
> >The updates from MS can easily be configured to pass through the
> >firewall - as I mentioned earlier, the blocking has exception lists and
> >it's easy to configure exceptions for all blocking. We run updates every
> >night.
>
> No, you didn't mention it. You said you block .EXE. I took you at
> your word. To quote your earlier post:
> >For those that did select it, they would not have had a problem - we
> >don't allow .exe or other types through the HTTP proxy service in the
> >firewall.
> And then later in the same post you said:
> >If you block .EXE you never have to go back and update the firewall to keep
> >users from downloading and running .EXE over HTTP/HTTPS or SMTP.
>
> I wondered how you managed not allowing downloading .exe files. Now
> you have me wondering about why you would claim "set-and-forget", yet
> talk about configuring exceptions. Quite perplexing indeed. Please
> understand that I'm not trying to nit-pick you to death, but you've
> made some great claims, and I was wondering if I should jump ship. I'm
> far from being convinced. Maybe it's just me, but I see some glaring
> inconsistencies in your statements.
How can it be perplexing - you configure web filter exceptions for
specific locations and then you can forget about it for a while. I have
exceptions for windows update, MSDN Subscriber sections, Symantec, IBM's
download site, HP's download site, and several others that are trusted
sites. This is all common practice when you use web blocking.
> >If you have your block rules setup properly your people will not be
> >stopped from doing anything they are permitted to do, including updates,
> >but they will be protected from almost all of the bad files out there.
>
> I couldn't agree more. But now you're straying waaaaay away from the
> simple "Less chance of it breaking or being misconfigured...".
> Unless, of course, your customers have simple needs when it comes to
> downloading executable files. A single customer of mine may have more
> than two dozen different programs on different computers and/or
> servers requiring updates or patches from as many (or more) sites
> and/or service providers. I guess my customer's requirements are much
> different than yours. Or, maybe your appliance has a magical rule
> applicator? Seriously, how would you manage without creating an
> exception for each requirement?
Nope, it's actually very simple - base set of rules, base set of known
exceptions that almost everyone would know about anyway (at least any
half-IT type would).
I have customers in both the business and industrial sectors, developers
and office workers, never been a problem. Sure, you might get a call
next year saying that we've added this application suite to our
development platform and can't get updates (because the company that
does the updates uses raw .EXE files), so you remotely connect to the
firewall, add the exception to their web filter, and it's done - 15
minutes work.
As for your 24 applications that need updates from as many companies,
that's part of the initial assessment you are suppose to do before you
install a firewall. You need to determine what the customers are doing
on the net, what they need for protection, what they do inside the
network, what departments need isolated from each others, etc.... Once
you have your list you review it with the customer (or focus group) and
lay out the basic rules and exceptions. I can configure web exceptions,
24 of them, in about 5 minutes using the simple, easy, exception GUI
that's included in the management interface (so could a user with a
little experience).
There is one other way to determine what exceptions are needed - block
everything and wait for the complaints to start rolling in
>
> >Remember, virus updates are reactionary, they don't protect you until
> >the virus is "known" but the vendor that provides your updates.
>
> I agree. You're preaching to the choir.
>
> >> Also, I'm surprised you don't update your firewalls (patches, not
> >> rules). I'd sleep better knowing my firewalls and the computers
> >> behind them were up-to-date.
> >
> >Up to date and needing an update are two different things - we don't
> >blindly apply updates, even Windows updates, on every machine. When you
> >look at the update, unless it does something for your needs you don't
> >have to apply it.
>
> I'm with you there (again) 100%. But how do you find the time to
> review and apply daily updates? Remember, you said:
> >In general, every workstation at a generic desk updates every evening.
> Like Lewis Carroll wrote: "Curiouser and Curiouser". Unless you mean
> you only blindly apply M$ updates to generic boxes.
Yep, most of the workstations in an office are not critical development
systems, they are office workers systems - they get updated between 2AM
and 5AM (spreading the internet load) every day. The critical machines,
servers, development systems, get updated after a review/test is done,
which has nothing to do with the firewall. We have ghost images of the
office workstations, all of them are clones of each other, that can be
restored in 10 minutes in most cases, so if a auto-updated patch from MS
trashes them we can get them back to a last-configured roll out state
quickly - and you can uninstall updates too.
As for finding the time - it's part of the business, at least if you
care about your production servers and your development team. As an
example, I got a call that a client is switching to MAS-200, and want's
to run it on their 2003 server. I took it to my office (MAS-200),
installed 2003 on a test server, added the services that they are
running, then did a couple installs/uninstalls of MAS-200. I took notes
of everything and any issues (install was smooth). Now when I go back to
the clients server there should be no unknowns reaching out to my neck.
As for the time, we get paid for it, they expect us to keep them from
having down-time and testing is one strong method for doing that.
> >In the case of WG, there have not been any security
> >related updates to the firmware in a long time. Yes, they've come out
> >with newer rev's and nicer features, but the updates don't change
> >anything in the security options that most of our clients setups.
>
> Ummm...ok. I'll take your word on that. I guess you don't use the
> V-Class products. This is taken from their site:
> >WatchGuard® Vclass products 22 April 2004
> >WatchGuard Vclass Version 5.1.1 sp1 includes security enhancements
> >to your product.
> Maybe it's not a firmware update. Wait, what else could it be?
And did you read the update - was the update something that applied to
your situation? See, you can't just blindly apply updates, it's not good
to apply them to critical machines unless they do something to fix a
problem you are are having or that needs addressed right away. I've not
installed any of the V-Class units for customers, even state agencies
have not needed the power/features they have. The standard Firebox line
has served everyone quite well these last 7+ years - now going to the X
line.
> To basically sum it up, we both are trying to accomplish the same task
> (more or less), yet we use quite different methods and tools. For
> instance, you choose an appliance as a single point-of-failure, and I
> prefer to use specific tools for specific jobs. Choice is great,
> wouldn't you say?
Yes, choice is what it's all about. I look at the cost of maintaining
the security system, licensing, etc... I choose appliances because I
have never had one die on me yet, and I can hardly state that about a PC
over the last 7+ years that I've been using the WG FB line of firewalls.
For customers that can't afford to be down, they have a spare unit
sitting, fully configured, online and ready to swap into place. For
customers that can handle the down-time they just order another unit
from the vendor or reseller and have it in 12 hours - the nice thing is
that the configs are easily upgraded between versions so that you don't
really have to do anything other than load the config and you're done.
As I said, I've not had one FB go bad in all of these years, so it's not
been a issue being a single point of failure. I have a firebox II in my
home, it's almost 8 years old and works perfectly.
Choice is great, but making the right choice is all that's important to
customers.
Don't get me wrong, I still like FW-1 and some of the others, but I've
not seen a single instance where an appliance could not do the same
thing.
--
--
spamfree999@rrohio.com
(Remove 999 to reply to me)
Facebook
Twitter
Instagram