6 Aug
2022
6 Aug
'22
6:45 p.m.
So, afterthought to one bit I wrote, the other day:
Here's a rhetorical question, which I'm going
to ask not to be a jerk
but rather as lead-in to some practical suggestions going forward:
Have you ever portscanned your system from a nearby IP, in order to
better understand and document your system's attack surface? Did you
ever then go through each service thus proven to be exposed to public
network traffic, studying each and its configuration details, to reduce
the attack surface and use only very solid code to handle public
traffic?
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.)