For any poor sod who needs to deal with the PCI Data Security Standard (PCI DSS)

Any engineer dealing with PCI DSS compliance issues probably looses a little bit of the joy in life :-).

Now don't get me wrong, The PCI DSS has a laudable aim and is written quite well and mostly sensibly but like the bible is open to a vast amount of interpretation...

So lets start with the fundemental issue:

Q. Is my load balancer secure?

A. If you have  Firewalled port 22 (SSH) and 9080/9443 (Loadbalancer.org admin ports) then YES IT IS SECURE -  job done, go home.

But why is it secure?

• Because the only externally accessible services are on those ports, and ONLY your network admin should EVER have access to them.
• The load balancer acts as a router, so any 'load balanced' services pass straight through to your backend servers (which are hopefully secure).
• No security vulnerability has EVER been found in the fundamental routing system of our load balancer (LVS/HAProxy/Pound).

But you can (and should) try to make it EVEN more secure by:

• Replicating your external firewall on the actual load balancer to stop attacks from the internal network
• Harden your 'admin network access' i.e. those IPs/Subnets with access to SSH or WebAdmin ports:
• Change SSH passwords / Keys or just disable completely if you like (keep the SSH key for replication if you have a clustered pair).
• Change web interface passwords
• Keep up to date with software releases, just ask support@loadbalancer.org to be added to our security mailing list.

This is because we take security very seriously and make sure that all important packages such as OpenSSL & Apache etc. are kept up to date with the relevant security patches. NB. These patches are to protect you from your own staff on your admin network as hackers obviously can't even get to these possibly vulnerable applications.

Now because we are nice and helpful at Loadbalancer.org we even have introduced a script in v7.3  that automates the whole lock down process for you!

Just log in to the console as root and type the command: lbsecure

WARNING: v7.5.2 - Severe security risk!

A nasty bug is present in the lbsecure script, please make sure you upgrade to v7.5.3 or later.

You will be asked to provide new passwords for the web interface and the
console root account, plus an IP subnet that should be allowed remote access

The script will then automatically regenerate random SSH keys and lock down the firewalls on both master and slave load balancer units.

NB. Obviously if you specify your admin network incorrectly you will lock yourself out!

Ps. We have completely re-written the SSH Key synchronisation code in v7.6.4 to automatically be secure from first boot.

OK, So lets get back to what we are supposed to be talking about:

The PCI Data Security Standard

PCI DSS is the global data security standard adopted by the payment card brands for all entities that process, store or transmit cardholder data.  It consists of common sense steps that mirror security best practices.

I have highlighted in red the parts that are relevant to the Loadbalancer.org appliance:

Build and Maintain a Secure Network

• Install and maintain a firewall configuration to protect cardholder data - OK, Make sure you have an external firewall configured correctly and for double security one on the load balancer as well.
• Do not use vendor-supplied defaults for system passwords and other security parameters - OK, Just run lbsecure or make changes manually.

Protect Cardholder Data

• Protect Cardholder Data
• Protect stored cardholder data
• Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

• Use and regularly update anti-virus software or programs
• Develop and maintain secure systems and applications - OK, Make sure you have the latest software updates

Implement Strong Access Control Measures

• Restrict access to cardholder data by business need to know
• Assign a unique ID to each person with computer access - OK, Either treat the Loadbalancer.org appliance is a single user bastion host (recommended) or manually configure.
• Restrict physical access to cardholder data

Regularly Monitor and Test Networks

• Track and monitor all access to network resources and cardholder data - OK, Use a combination of SNMP & logging (again single user system recommended for making this easier)
• Regularly test security systems and processes - OK, No problem but see the rant in the next section!

Maintain an Information Security Policy

• Maintain a policy that addresses information security for all personnel

Now obviously you need to do all this work, document it test it and question your assumptions...but I don't see anything difficult here...

So why do we keep getting so many support cases relating to PCI-DSS compliance?

Well, I think its because you get the "My boss says I must do X on every device in my system or we are not compliant."

The classic ones being:

Q. My boss says , "We must run a virus scan on the load balancer!"

A. Oh good grief, how on earth would you get a virus on the load balancer?

Q. We just ran a security scan on the local system as root and we got 1000 positive hits!

Oh good grief, do we have to explain again why security scanners generate millions of false positives on a custom Linux distribution.

We use a custom version of Centos which is based on Red Hat Enterprise Linux, how can a security scanner be taken seriously if it doesn't understand RedHat Enterprise Linux patch numbers?

Most other vendors (who run the same software stack) don't get this problem because they don't let you see what they are running (so that you can't tell if it is secure or not).

If someone gets local access you are already screwed anyway! (if you are worried then just disable root access).

-- Rant over