Payment gateways such as Stripe and Authorize.net handle billions of dollars worth of business per month.

That is why payment gateways and shopping carts are juicy targets for hackers to steal Credit Card info, User identity, etc.

As a defense, Payment Gateways require all eCommerce sites to be fully secure against common attacks, which is ensured through PCI DSS security standard.

Sites that are not PCI DSS compliant can face penalties or even lifetime bans if there is a data breach.

Here at Bobcares.com, we help web hosts, digital marketers and web developers ensure 100% PCI compliance in their servers and websites.

As part of this, we secure websites and servers running Apache.

Today let’s take a look at the different steps in this process.

1. Disable weak SSL ciphers

These days, online shoppers look for the HTTPS green padlock sign before submitting their credit card info.

The green light shows that their identity & credit card details are encrypted, and cannot be seen by an attacker.

But is it really secure?

Well, it’s not safe if the method used for encryption (aka Ciphers) is outdated and weak.

In the past few years, attackers have found several flaws in older ciphers such as CBC and RC4, allowing attacks like BEAST, Lucky Thirteen and SWEET32.

That is why here at Bobcares, we always have an ear to the ground to detect new vulnerabilities, and patch our customer servers before any attack is initiated.

We use only the latest and strong Cipher suites in HTTPS connections, and explicitly disable older Cipher suites.

For eg. in Apache servers, the default Cipher suite configuration is:

ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM

This means that Apache disables all “LOW” strength Ciphers by default and allows only “MEDIUM” and “HIGH” strength ciphers along with “RC4+RSA”.

However, RC4+RSA opens the server to FREAK and ROBOT attacks, possibly endangering credit card data.

So our Support Engineers avoid weak ciphers like DES/3DES, RC4, RSA etc., and we substitute them with modern ciphers like AES which uses more complex data scrambling.

Here is an example:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

2. Disable weak protocols & Enable latest TLS

At the dawn of secure web communications in 1995, everyone used SSL or Secure Sockets Layer as the way to establish a secure connection.

Over time, attackers found out several vulnerabilities in these early implementations (SSLv2 and SSLv3), which led to attacks such as POODLE and DROWN.

So, in its place came TLS (Transport Layer Security).

However, that too had vulnerabilities in its first version (TLS 1.0).

So, as of now, only TLS 1.1 and TLS 1.2 are considered secure.

Now, Apache sets the default protocol list as:

SSLProtocol -ALL +SSLv3 +TLSv1

This means that Apache will allow connections to be established with SSLv3 and TLS 1.0 if the browser requests it (some older browsers still try to use SSLv3 & TLS 1.0).

That is why we explicitly disable all protocols and allow only the strong ones. Here’s an example:

SSLProtocol -ALL +TLSv1.1 +TLSv1.2

Protip: If website is using Cloudflare for dns, enable Modern TLS there as well.

3. Secure Apache version information

Ever wonder how do cyber criminals target a server for attacks?

They scan the internet for vulnerable Apache versions, and launch targeted attacks on them.

For eg. let’s say there’s a new vulnerability found for Apache v2.4.1. These tools will search for servers that display v2.4.1 in their headers, and try to exploit that vulnerability.

Now, what if the server headers do not display the version information? The server becomes invisible to the scanners.

That is why, we disable Apache version information in ServerSignature and ServerTokens.

4. Fix ETag inode disclosure vulnerability

Linux assigns unique ID numbers called “inodes” for each file it creates.

Apache has a vulnerability that sends these inode numbers to browsers as part of its file caching mechanism (using entity tags, aka ETags).

Attackers can use these inode numbers to launch targeted attacks to access files, by circumventing security limits.

So, in the servers we maintain, we disable ETag headers using the setting:

FileETag None

5. Ensure the latest Apache version

Apache maintainers release security patches periodically to fix vulnerabilities.

Major operating system vendors such as RedHat, Debian and Ubuntu include these patches in their security updates.

But there’s a problem – Some vendors such as RedHat do not change the Apache version number even after a patch is applied.

This causes PCI scanners to complain that Apache is not patched.

Here at Bobcares, we keep our customer’s servers updated at all times. But, we also see wrong scan results due to the version numbering issues.

We resolve such issues by contacting the PCI scanning service (eg. TrustWave, Comodo, etc.), and have them issue a successful scan acknowledgement by providing them the patch details.

PCI DSS is not a one-time affair

New vulnerabilities are discovered all the time.

So, it is important to keep Apache updated with new security measures as the threat scape changes.

Here at Bobcares, we audit our customer’s Apache servers periodically and apply security patches as soon as they are released.

We enable several layers of network defenses, brute force detectors and web application firewalls to block all kinds of exploit attempts.

This helps our customers pass PCI DSS scans every year and stay certified.

Security beyond PCI DSS

PCI standards cover only a small part of server security.

For eg. it does not cover defenses against DoS attacks, or malware infection.

That is why our Advanced Server Management services ($149.99 /month) takes care of the entire spectrum of server defenses that includes anti-spam, anti-virus, backup integrity and more.

It helps our customers to focus more on their business than spend time worrying about server security, or standards compliance.

If you need help assessing your server’s PCI compliance or full server security, click here to talk to our experts.

Conclusion

Apache PCI compliance tests can fail due to weak cipher configuration, older protocols, file information disclosure, and more. Today we’ve covered how to resolve the common issues arising out of PCI DSS scan for Apache and how to fix them.