You're both right of course. I'd like to think there's also knowledge involved (or lack thereof: especially with those that don't even know know GNU/Linux except for the web-based panels they "administer" machines from) but of course even knowledge (the right way) doesn't prohibit people from making bad decisions anyway, especially where things boil down to simple economics...

OK, so except for money, trends, referrals and contracts (both good points!) there should also be ways to check for security practically, right? Web stack checklists, specific diagnostic tools, et cetera?

There are many good guides out there that people look over everyday



There are the DISA STIG guides (Security Technical Implementation Guidelines). The STIGs are open to the public.

http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf

and they even have a package to download and run against your machine and it will tell you if you meet the common best practices.

Unix scripts
http://iase.disa.mil/stigs/SRR/unix.html

and

Unix web server scripts
http://iase.disa.mil/stigs/SRR/websr...0070727.tar.gz

1 members found this post helpful.

DISA's STIGs totally slipped my mind! Thanks for the reminder!

There are also quite a few non-govt-related write-ups similar to DISA's STIGs.

I worked for one government organization that was trying to apply STIGs as policy. While this is usually a good practice, this particular organization was doing several things that were a bit extreme:

1. Installing AV on Linux hosts that were dedicated NIDS.

2. Installing iptables on Linux hosts that were dedicated NIDS.

I disagree with doing the above. Those particular IDSs were dropping packets BEFORE AV was installed. They were dealing with extreme amounts of traffic and had a pretty decent signature base. Adding AV to this mix is a recipe for disaster, as both IDS software and AV usually has high levels of overhead. The systems were also pretty deep into the network. IMO, using iptables was like using a sledgehammer when a regular hammer was the better tool.

What ticked me off about all of this was the organization's blind acceptance of a guideline. IDSs should always be bastion hosts. Sometimes, exceptions to guidelines and policy needs to be made.

They also had DNS services running on one particular platform of IDS, which kept crashing the server because of the high stress of sniffing and resolving addresses.

I think it is important to not overload certain systems. The STIGs are pretty good but organizations that have the need to follow STIGs should know that these are only recommendations. Seeing smart people do dumb things makes me not want to work for them (yeah, it wasn't long after that that I left).

I've found an excellent book on handling an intrusion incident:

Incident response: investigating computer crime
by Chris Prosise, Kevin Mandia, and Matt Pepe
http://www.amazon.com/Incident-Respo...dp_ob_title_bk

Monitoring computer systems for evidence of malicious activity, and reacting to such activity when it's detected. With coverage of Windows and Unix systems as well as non-platform-specific resources like Web services and routers, the book covers the fundamentals of incident response, processes for gathering evidence of an attack, and tools for making forensic work easier.

Looks like a good book, its from 2003 though, so I'm sure there have been a lot of changes since then.

The tools used to attack have changed, but how you respond to an attack hasn't. This book isn't about how to protect yourself against the latest threats, it assumes that you will be attacked and that the attacker will succeed. This book covers what to do BEFORE that attack, what do do when you detect the attack, how to gather information about the attack, how to recover from an attack, and how to document the attack and your response for possible use by the courts, and so you know that you've succeeded in removing any back doors or malware left behind by the attacker.

OK, sounds like a good one then.

I'll try to post a full review when I've finished reading it.