[Lug-nuts] Distro security and CVEs (was: Snort)

So, afterthought to one bit I wrote, the other day: Some years ago, I was senior sysadmin at a firm operating a "merchant bank", which is a term of art for a data farm that processes credit card transaction data. As you might imagine, we took software and network security very seriously. One of the recurring tasks I had to shoulder every six months was guiding us through PCI DSS -- the Payment Card Industry Data Security Standard testing and certification. We paid one of many specialised firms to probe our infrastructure using their own bot software, which fingerprinted our site's software versions and issued a report about what they believed we were running, and then listed known vulnerabilities in some configurations of those versions of those pieces of software. I would login to the testing company's site, and read a number of such claims about parts of our site, and those candidate vulnerabilities -- and my job was to prove to them that our site did _not_ suffer those vulnerabilities in fact, or alter/upgrade our software so as to eliminate the possible problem, and, again, prove that no problem (any longer) existed. Along the way, I read and analysed a lot of CVEs, which IIRC stands for Common Vulnerabilities and Exposures (record). E.g., I'd read the report that says "We detected that you're running Apache 2.2.15, so prove to us you are not vulnerable to the flaws described in this list of CVEs, in order to pass DSS certification." So, for many of those CVEs, I'd query CentOS package metadata, thus: $ rpm -q --changelog {package-name} | grep CVENUMBER ...and find that CentOS/Red Hat had backported a fix to that package of Apache httpd v. 2.2.15, quote that return data to the PCI DSS tester, and Robert's your father's brother. In other cases, even though CentOS/RHAT hadn't backported a patch, reading the CVE details revealed that the vulnerability existed only in configurations of the software we had carefully avoided by switching off unwanted features or not having enabled non-default ones. And that is a theme I wished to stress: Code you are not running is code that cannot be attacked. If you are not sure you need a software feature (especially in code exposed to public data), maybe you should disable it in your running configuration, on general principle. In rare cases, to sidestep/eliminate the risk scenario described in a CVE, I would need to upgrade/replace software or otherwise make substantive site changes. But, point is, that was _rare_. A quite large fraction of CVEs could be finessed by pared-down site configuration, and using maintained packages that backport security fixes. By the way, it's worth subscribing to, and skim-reading, your distro's security announce mailing list. (And beware, especially in Internet-facing roles, of distro releases that are past their security-coverage EOL dates.)