Do not manually upgrade Apache.
Manual upgrading for security is unnecessary and probably harmful.
How Debian releases software
To see why this is, you must understand how Debian deals with packaging, versions, and security issues. Because Debian values stability over changes, the policy is to freeze the software versions in the packages of a stable release. This means that for a stable release very little changes, and once things work they should continue working for a long time.
But, what if a serious bug or security issue is discovered after release of a Debian stable version? These are fixed, in the software version provided with Debian stable. So if Debian stable ships with Apache
2.4.10, a security issue is found and fixed in
2.4.26, Debian will take this security fix, and apply it to
2.4.10, and distribute the fixed
2.4.10 to its users. This minimizes disruptions from version upgrades, but it makes version sniffing such as Tenable does meaningless.
Serious bugs are collected and fixed in point releases (the
.9 in Debian
8.9) every few months. Security fixes are fixed immediately and provided through an update channel.
In general, as long as you run a supported Debian version, stick to stock Debian packages, and stay up to date on their security updates, you should be good.
Your Tenable report
To check if Debian stable is vulnerable for your issues, Tenable's "2.4.x < 2.4.27 multiple issues" is useless. We need to know exactly which security issues they are talking about. Luckily, every significant vulnerability is assigned a Common Vulnerability and Exposures (CVE) identifier, so we can talk easily about specific vulnerabilities.
For example, on this page for Tenable issue 101788 we can see that that issue is about vulnerabilities CVE-2017-9788 and CVE-2017-9789. We can search for these vulnerabilities on the Debian security tracker. If we do that, we can see that CVE-2017-9788 has the status "fixed" in or before version
2.4.10-10+deb8u11. Likewise, CVE-2017-9789 is fixed.
Tenable issue 10095 is about CVE-2017-3167, CVE-2017-3169, CVE-2017-7659, CVE-2017-7668, and CVE-2017-7679, all fixed.
So if you're on version
2.4.10-10+deb8u11, you should be safe from all these vulnerabilities! You can check this with
dpkg -l apache2 (ensure your terminal is wide enough to show the full version number).
Staying up to date
So, how do you ensure you're up to date with these security updates?
First, you need to have the security repository in your
/etc/apt/sources.list.d/*, something like this:
deb http://security.debian.org/ jessie/updates main
This is a normal part of any installation, you should not have to do anything special.
Next, you must ensure that you install updated packages. This is your responsibility; it is not done automatically. A simple but tedious way is to log in regularly and run
# apt-get update
# apt-get upgrade
Judging from the fact that you report your Debian version as 8.8 (we're at 8.9) and the
... and 48 not upgraded. from your post, you might want to do this soon.
To be notified of security updates, I higly recommend subscribing to the Debian security announcements mailinglist.
Another option is ensuring your server can send you emails, and installing a package like apticron, which emails you when packages on your system need updating. Basically, it regularly runs the
apt-get update part, and pesters you to do the
apt-get upgrade part.
Finally, you could install something like unattended-upgrades, which not only checks for updates, but automatically installs the updates without human intervention. Upgrading the packages automatically without human supervision carries some risk, so you need to decide for yourself if that is a good solution for you. I use it and I'm happy with it, but caveat updator.
Why upgrading yourself is harmful
In my second sentence, I said upgrading to the latest Apache version is probably harmful.
The reason for this is simple: if you follow Debian's version of Apache, and make a habit of installing the security updates, then you are in a good position, security-wise. Debians security team identifies and fixes security issues, and you can enjoy that work with minimal effort.
If, however, you install Apache 2.4.27+, say by downloading it from the Apache website and compiling it yourself, then the work of keeping up with security issues is fully yours. You need to track security issues, and go through the work of downloading/compiling/etc every time a problem is found.
It turns out this is a fair amount of work, and most people slack off. So they end up running their self-compiled version of Apache that becomes more and more vulnerable as issues are found. And so they end up a lot worse than if they simply had followed Debian's security updates. So yes, probably harmful.
That's not to say there's no place for compiling software yourself (or selectively taking packages from Debian testing or unstable), but in general, I recommend against it.
Duration of security updates
Debian doesn't maintain its releases forever. As a general rule, a Debian release recieves full security support for one year after it has been obsoleted by a newer release.
The release you're running, Debian 8 /
jessie, is an obsoleted stable release (
oldstable in Debian terms). It will receive full security support until May 2018, and long-term support until April 2020. I'm not entirely sure what the extent of this LTS support is.
The current Debian stable release is Debian 9 /
stretch. Consider upgrading to Debian 9, which comes with newer versions of all software, and full security support for several years (likely until mid-2020). I recommend upgrading at a time that is convenient for you, but well before May 2018.
Earlier, I wrote that Debian backports security fixes. This ended up being untenable for some software due to the high pace of development and high rate of security issues. These packages are the exception, and actually updated to a recent upstream version. Packages I know of this applies to are
chromium (the browser),
Finally, this entire way of dealing with security updates is not unique to Debian; many distributions work like this, especially the ones that favour stability over new software.