ANS Documentation

Improve This Doc
  • Cloud
  • Domains and DNS management
  • Backup and High Availability
  • eCommerce Stacks
  • Security
    • DDoSX®
    • Web Application Firewall
    • Threat Monitoring and Threat Response
    • McAfee Antivirus
    • Vulnerability Scans
    • ANS MDR
    • Keeping Magento secure
    • Keeping WordPress secure
    • Brute Force Attacks
    • CryptoLocker
    • Dirty COW
    • The Logjam attack
    • Meltdown and Spectre
    • Memcached security concerns and reflection/amplification DDoS attacks
    • Wana Decryptor / Wana Decrypt0r 2.0 / WannaCry
    • Log4J Vulnerability
    • Polkit Security Vulnerability CVE-2021-4034
    • CVE-2022-0847 - Dirty Pipe Vulnerability
  • Email
  • Monitoring and usage management
  • Networking
  • Operating systems
  • Webcelerator
  • MyUKFast
  • Home >
  • Security >
  • Vulnerability Scans

Vulnerability Scans¶

If you handle payment details on your server, you’ve likely had to take part in the PCI circus and get an automated scan ran against your solution.

The scans check for common issues like software versions and unnecessary open ports, things that may point to deeper security issues on a server.

At the end of a scan, a PDF is generated that lets you know how you’ve scored and points out anything that needs changing before your server can be used for storing payment information. The issues that need resolving are typically flagged as critical or high.

Running one of these scans against a CentOS or Red Hat server will likely return a worrying amount of software outdated issues, and the main point of this article is to let you know that it’s not as bad as it looks due to the Red Hat backporting policy

Backported fixes¶

Red Hat’s backporting policy is outlined on the link below:

https://access.redhat.com/security/updates/backporting/?sc_cid=3093

The gist of it is that due to Red Hat/CentOS being an enterprise, LTS style, operating system one of the main features is that the major version numbers that ship with a release won’t change for the duration. Just refusing to update packages isn’t really a viable option, as this would leave Red Hat systems vulnerable to any security issues found during the operating systems lifecycle. Instead, Red Hat take the security fixes from higher versions of the packages and include them in their own releases, whilst leaving out any new features that may change how the program fundamentally operates.

To illustrate this, here’s a fictitious example:

CentOS 5 launches with the package widgets, running version 9.1.20.

After launch of CentOS 5, a disclosure points out a number of vulnerabilities in widgets-9.1.20 and the widgets team push out a series of security patches.

Whilst they push out their updates, they take the opportunity to implement some new functionality that changes how widgets handles it’s plugins and call it widgets-9.2.0

This breaks a few of the older clients that interface with widgets-9.1.20

Instead of putting widgets-9.2.0 in the CentOS repositories, CentOS release a new package called widgets-9.1.21 that contains the security fixes but not the new plugin changes.

This way, CentOS can be sure that implementations of widgets will continue to work on CentOS 5.

Confusion arises when a PCI scan checks for the widget version. In that example, it would spot widgets-9.1.21, see that it’s lower than widgets-9.2.0 and flag up that the version of widgets on that server hasn’t had critical security patches applied.

CVE Numbers¶

Each failure on a PCI report should come with an accompanying CVE number, in the following format:

CVE-1999-0067

These numbers relate to a vulnerability, which can be looked up here:

https://web.nvd.nist.gov/view/vuln/search

Our main reason for being interested in them is that we can crosscheck a CVE with Red Hat to see if the issue was resolved with a backport, or if we actually need to take action on it.

Each CVE can be checked against the Red Hat website https://access.redhat.com/security/cve/ like so:

https://access.redhat.com/security/cve/CVE-2014-0160

From that page, you can see that the vulnerability described in CVE-2014-0160 didn’t affect various versions of Red Hat, though to a PCI scan it would probably flag as a failure.

To rectify this with your scanning agency, simply sending them that Red Hat CVE page, the backporting link from earlier and the version of the software in question should be enough to get them to revoke the failure.

Checking against RPM¶

A quick way to check whether or not a package has had the backport applied is to view the change log of the package. On Red Hat-based operating systems you can use the below command where [PACKAGE] is the name of the package you would like to check.

rpm -q --changelog [PACKAGE]

You can then search through this by using the grep command. For example to search whether or not PHP has had a backport applied for CVE-2016-1903 you would use the below command.

rpm -q --changelog php | grep CVE-2016-1903

Next Article > ANS MDR

  • Useful Links
  • SMB
  • Enterprise
  • Channel
  • Public Sector
  • ANS Data Centres
  • About ANS
  • Careers
  • Blog
  • Get in touch
  •  
  • Sales 0800 458 4545
  • Support 0800 230 0032
  • Get in touch

© ANS Group Limited | Terms and Conditions | Corporate Guidance | Sitemap
ANS Group Limited, registered in England and Wales, company registration number 03176761, registered office 1 Archway, Birley Fields, Manchester M15 5QJ