Re: 2000 server solution
From: David (davidwnh_at_adelphia.net)
Date: 10/22/03
- Next message: Dejan Lazic: "Check Point FireWall-1 and CCSA"
- Previous message: David: "Re: firewall for isolating wireless network?"
- In reply to: Wolfgang Kueter: "Re: 2000 server solution"
- Next in thread: Wolfgang Kueter: "Re: 2000 server solution"
- Reply: Wolfgang Kueter: "Re: 2000 server solution"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 22 Oct 2003 02:37:44 GMT
Maybe you should start by looking up the RFC that defines firewall. It
is more than a buzzword and includes much more than simple packet header
filtering.
>
>
> It does matter that one unterstands which security issue is handled on which
> layer of the network model and what kind of device and software is
> neccessary for the wanted purpose. Sorry, but you lack unterstanding of
> firewall basics because the buzzword 'firewall' has confused you.
>
>
If you ran a webserver that was being hit by smurf attacks wouldn't you
filter ICMP or better yet put a device in front of it which took this
load off of the server itself? There are several types of DOS attacks
which can be adequately dealt with by blocking the unwanted traffic
further upstream.
>>>Give me a reason to hide something, that is designed for public access.
>>
>>Because in the real world, you are not the one deciding what is
>>available for public access - the chap that designs the security
>>structure is the one that decides what is and is-not for public access.
>
>
DOS attacks.
>>>Why not? If nothing is listerning on the other ports there is no reason
>>>to hide these ports from the public (always assuming that the stack is
>>>not vulnerable). Nothing running there, tcp-rst or icmp port unreachable
>>>is sent, done.
>>
>
>
Funny how you contradict yourself by saying it is not necessary,yet
stating "this is and always will be" your default configuration. There
obviously had to be a reason.
>>This is the reason that most firewalls block ALL ports in both
>>directions until a rule is created to do otherwise.
>
>
> Right, nothing wrong with that approach. And be sure this is the default on
> all systems that I have installed so far and will always be. But: The
> ruleset of my packet filters normally copies the output of netstat -an
> (maybe in conjunction with the configuration of the tcp-wrapper) of every
> host every host behind it.
>
If a webserver somehow gets compromised through the service itself or
one of the technologies it uses to serve up dynamic content then that
machine could possibly be reconfigured to do anything on any port if you
don't have a firewall in front of it. Go out and actually administer a
webserver in a corporate situation and see if you have enough time to
continuously audit the web pages, scripts,etc. that every two-bit web
programmer the company hires publishes to that server. You have to
consider the what if, so that a single missed or unknown vulnerability
doesn't lead to unlimited possibilities.
Securing a server goes far beyond shutting off unnecessary services, and
includes that fact that you cannot prevent all potential for initial
intrusions with %100 certainty so you have to plan for the unknown as
well.
> Now, what does a packet filter in front of those two servers add to the
> security of the setup?
>
>
- Next message: Dejan Lazic: "Check Point FireWall-1 and CCSA"
- Previous message: David: "Re: firewall for isolating wireless network?"
- In reply to: Wolfgang Kueter: "Re: 2000 server solution"
- Next in thread: Wolfgang Kueter: "Re: 2000 server solution"
- Reply: Wolfgang Kueter: "Re: 2000 server solution"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|