Re: need help to answer firewall question......

From: x y (jamescagney90210@yahoo.com)
Date: 05/05/02


From: "x y" <jamescagney90210@yahoo.com>
Date: Sun, 5 May 2002 12:29:53 -0400

I think you answered it exactly right. It is inappropriate and unsafe to
expect all your network security and authentication to come from the
firewall.

Checkpoint is a fine firewall and supports a fairly large number of
authentication methods, so if Checkpoint can't do what your boss is asking
for, it's a fair bet that most firewalls can't do it. You might ask your
boss what his goal is and whether he got this information from some article
or magazine, and if so, can you see the article so that you can have a
better idea of what the goal is.

Increasing security is a tradeoff with reducing convenience and in some
cases blocking legitimate users. This is not something you want to happen to
your webserver at an e-business site. You want everyone to be able to access
the site. Ask your boss: does he want to set up a login ID and password or
machine certificate for all 1 millon visitors to your web site? Probably
not. Is it useful for him to know that Einer Norb on 123 Main Street in
Sweden visited your web site, and is he going to have someone phone Einer to
find out if his visit to your web site was legitimate? Probably not. There's
just no such thing as a huge database on the internet of people, their
street addresses and their IP addresses, and if there was, it still wouldn't
help you determine whether the visit was legitimate, whether the machine was
compromised or being remote controlled, whether the session was hijacked,
whether the user's password or certificate were stolen, or whether someone
else is sitting at that person's keyboard while he's in the bathroom.

You could respond that no one else out there is doing what he is asking: not
Yahoo, not Microsoft.com, not Amazon.com, and not any of your competitors.
The best you and your boss can do is to keep informed on the recommended
best security practices from various security web sites and implement the
parts of those security practices that make sense for your organization. The
goal is never to make your firewall an impenetrable fortress, because it
will never be that.

The firewall does "authenticate" successful connections to your servers by
logging the IP address, because as I understand it, IP address spoofing is
hard to do and get the response packets back.

"noname" <noname@example.com> wrote in message
news:3CD4B878.5030408@example.com...
> Dear all,
>
> I manage the firewall in my company. I was asked by my boss about the
> capability of our existing firewall (a Checkpoint). He specifically
> asked whether it knows *who* is coming in to our private network and
> *what* he has done.
>
> My boss used an analogy: suppose the tcp ports are like doors to a
> building, network traffic will be like people carrying documents. A
> different protocol port will be like a different door. People with
> documents will come in and out of these doors. The firewall will then be
> like a security guard guarding the building. A security guard can check
> *who* the people are (authenticate them), where they come from, where
> they are going, inspect the documents they are carrying, and direct them
> to the appropriate door if they are found to be valid visitors, and even
> follow them.
>
> So he asked: can the firewall do *all* these?
>
> I answered: Not a packet-filtering/stateful inspection firewall. It can
> do some or most of these, but not all. An application-proxy firewall can
> definitely do more, but still has its limitation. What the checkpoint
> basically does is to check the source address of the packet, its
> destination address, its protocol/port, check the rulebase to see if it
> matches, and let it pass if it does, and drop/reject if it doesn't.
> Checkpoint does have resource rules that work with security servers to
> inspect more (eg, mail viruses, url strings, etc), but it still doesn't
> authenticate visitors-at-large from the Internet.
>
> Then he asked: So how do I know *who* is coming in from the Internet,
> and *what* is he doing? Everyday, Internet users all over the world are
> accessing our web servers, etc. How do I know whether they are
> legitimate users or not? What about traffic between the web servers and
> the application servers, or the application servers and the database
> servers? How do I know whether they are legitimate or not? How do I know
> whether they are triggered by legitimate transactions? Or is someone
> trying to do something funny through the database port, say, getting our
> customers database records illegally?
>
> I answered: Network and host-based IDSes allow us to monitor intrusion
> at network and host levels respectively. And IDS will alert us if there
> are exceptional activities. Their logs and the servers logs can capture
> the source addresses of the users. We can block source addresses of
> these intruders
>
> As to know *who* actually is coming in from the Net and who is doing
> what, it is difficult for standard web port. The secure equivalent of
> http is SSL, which have client and/or server authentication. This will
> help us identify the users. As to communication between web and app
> server, between app and db servers, similarly, the two
> services/applications on both ends should authenticate each other first
> before actual communication. And these application should have their own
> logs. If the applications are written such that there are no or
> insufficient authentication, no logs, then the developers have to
> improve on it.
>
> He is not convinced. He says the firewall or the network must be able to
> do all these; cannot depends on the servers or applications.
>
> Maybe my reply is not satisfactory, doesn't hit the bull's eye, or I did
> not understand him, or the way I phrase it is not understood by him. (Or
> maybe he is right? There are firewalls that can do that.......)
>
> I wonder if someone here can help and advise me on how best to respond
> to his queries, and lead me to any products that can help to address his
> concern.
>
> Thanks.
>



Relevant Pages