# httpd 2.2 security recommendations



## vivek (Feb 24, 2009)

At my work place we are soon going to start accept orders using e-com and credit cards. We run ngnix server (public IP) for static files and dynamic stuff is handled by Apache and fastcgi+php5. I'm already running ngnix in jail using chroot and apache from freebsd jail (private IP). MySQL is also running from another Linux server. I've also installed and configured mod_security2. What else is required on server level to secure it further apart from pf?


----------



## ddekok (Feb 26, 2009)

I recently had to complete a PCI (Payment Card Industry) Self Assessment Questionnaire for the same thing.

The SAQ that I completed can be found here: https://www.beanstream.com/website/pdf_files/Self_Assmnt_Qust.pdf

This may or may not be applicable in your case, so you should contact your payment gateway for more information. At any rate, it is a detailed check list to get you on your way.

The most obvious thing I see missing is virus scanning. You should regularly run a virus scanner such as ClamAV.

The check list I linked to also goes into detail about wireless and workstation access. The easiest way to deal with that is just to segregate your production environment from everything else (including wireless).

If you don't already have a security policy and an incident response plan (that details actions during card holder data breach), you should probably have one written up and signed off by employees.

Those are the more major points. I hope that helps.


----------



## ddekok (Feb 26, 2009)

I should note that this is if you are connecting to a web service for payment processing. If you are redirecting to another site (such as PayPal), then the questionnaire I linked to isn't applicable.

The reasoning behind the tighter security is that your server can be compromised and settings mucked around with.


----------



## Mel_Flynn (Feb 27, 2009)

What's the reason of running a full-featured virus scanner, which scans for viruses of which 99.999% doesn't affect the host OS, FreeBSD, but interferes with every IO operation?
Genuine question btw, I might be missing something.


----------



## ddekok (Feb 27, 2009)

Mel_Flynn said:
			
		

> What's the reason of running a full-featured virus scanner, which scans for viruses of which 99.999% doesn't affect the host OS, FreeBSD, but interferes with every IO operation?
> Genuine question btw, I might be missing something.



It used to be that running a virus scanner was optional on non-Windows systems, however the PCI decided to kick things up a notch and made it mandatory for all operating systems (I believe that was in the last year). So there is the "because they said so" answer.

A more informative answer is that systems such as FreeBSD may not be affected by a virus directly but could be a carrier. A web application, such as WordPress, can be exploited and have payloads uploaded. The payload may exploit the clients web browser, or even run shell commands to find relevant data.

Of course, proper security measures can prevent this, however, the PCI folk probably want to err on the side of caution.


----------



## ddekok (Feb 27, 2009)

The virus scanner doesn't have to monitor every file access, you just have to routinely scan the system (using a cron job or something).


----------



## vivek (Feb 27, 2009)

Thanks for providing information, including FAQ.


----------



## Mel_Flynn (Mar 19, 2009)

ddekok said:
			
		

> A more informative answer is that systems such as FreeBSD may not be affected by a virus directly but could be a carrier. A web application, such as WordPress, can be exploited and have payloads uploaded. The payload may exploit the clients web browser, or even run shell commands to find relevant data.



So, the spec should really read:
If an application is installed on the computer that allows visitors to upload data, a virus scanner must be run periodically.

Otherwise, I see no need for this. Of course, more and more webapplications have "easy to download and install plugins", which are then porely protected and exploited makes this a bit less straight-forward as it seems to be.


----------

