Concur and wish to stress ALL said: knowing where you stand is the major start point for any journey. Figure out exactly where you are THEN take appropriate action. Otherwise you may be simply whistling in the wind.
V/R Jim' H Carvey wrote: > > In-Reply-To: <[EMAIL PROTECTED]> > > Jim, > > Many people make the mistake of diving right in > with scans, looking for holes. Let me recommend > something not quite as easy, but in the end a far > better option. > > Diagram the configuration, and take things one > step at a time. Start with each system in it's > current configuration and document it as best as > possible. Any firewall or screening device should > be in default-deny...block everything unless it's > explicitly allowed....mode. Examine every > configuration, learning what you can. Document > everything, most particularly the final > configuration you decide to use. Set up the > logging appropriate for each device, and actually > collect/review the logs. > > I guess for each stage (ie, pair of devices), it > should look like this: > > 1. Configure as securely as possible. Patches. > Limit available services. > 2. Configure auditing. > 3. Monitor. > 4. Verify on a regular basis. > > From a system-wide perspective, go with a > defense-in-depth stance. Given the description > you gave, perhaps the only thing that should be > reaching the web servers at all are ports 80 and > 443. Okay. Every device prior to the web servers > should block everything and allow only port 80 > (this is just a guess based on what you provided, > but I think you get the idea). On the web servers > themselves, patch and limit > services/functionality. That means at the > operating system level (you don't need the Server > service, do you??) and the application level > (disable all script mapping except what you need). > > And whatever you do, DO NOT think for a moment > that just throwing RealSecure into the mix is > going to secure anything. > > Carv -- James W. Meritt CISSP, CISA Booz | Allen | Hamilton phone: (410) 684-6566
