I have been notified by my security scan company that the current version of apache is on the non-PCI compliant listing.  I must move to apache 2.2.21 as soon as possible!  (Yeah, Right)  However, installing the debian package won't work because of an extremely long list of dependencies.  Is there any information on a new release based around apache 2.2.21 and is there a possible release date?

Forum: 
Jeremy Davis's picture

And will be released no earlier than late April (that is when Ubuntu 12.04 is released which will be the basis of TKL v12.x).

But in the meantime, I would suggest that you speak further with your security scan company, because it sounds like they are doing a simple version check as opposed to proper vulnerability scanning. That is a cheap, easy, non-technical way of 'testing' for vulnerabilities that works very well with Windows servers. But it generally won't apply to a Linux server such as Ubuntu (and by extention TKL).

Whilst the vanilla version of Apache2.2.14 (the version available in TKL v11.x) probably has a number of security bugs, the version that actually runs on your server has had security fixes backported to that version. This security updates come through the 'security' repo and so are auto applied to TKL servers.

The implication is that whilst the vanilla version of Apache2.2.14 (as would be installed on a Win machine) may not be PCI compliant, I doubt that there would be any issues with the version running on your TKL server. Unless the PCI states particular versions are 'non complient' (which perhaps it does...) then I strongly suspect that the version on your server is in fact compliant. As you can see from the changelog, there were security bugs resolved as recently as Nov 2011.

Personally, I would ask your security scan company to inform you of which particular vulnerability scans (as opposed to version number scans) your server doesn't pass and/or which particular vulnerabilites it suffers from which make it non-compliant. If there are any real security issues, you could then log a bug with Ubuntu and it will get fixed (but it will still be v2.2.14 - just with the security issue fixed). If they can't or won't do that, then personally I would look for another security scan company that can and will actually scan for security issues, rather than just check version numbers against a list of 'non compliant' versions. If you are happy to stick with the latter then I'll happily do that for you for half the price they're charging! :)

Going on from that, you could hack your server to have the version they request (eg compile from source). This would probably be a time consuming exercise which would mean a huge increase in ongoing maintenance. The ironic implication of that is that as you will not longer receive autmatic security updates and your machine would arguably become less secure!

Having neither the time nor the patience to wait, I took steps to install the latest version of Apache Web Server (2.2.21-5).  It is a rather time consuming task but I have brought all systems back into compliance.

If you are planning to do this yourself, you will need to download Apache2 and all dependencies to your local desktop, then install them using the WebMin Software updater.  The only one you will have a problem with is apache2.2-common - which locks up while installing.  It asks for user input.  Simply open a terminal window to your server and initialize the process from a root authorized prompt.  The command to use is:  dpkg --configure -a

Remember to back up your /etc/apache2 or /etc/httpd directory.  It actually backs up your config files but one can never be too safe.  Once you have the Apache Common installed, the rest of the dependent packages will install directly from the WebMin Software Installer.  When complete, you can copy your config files directly back into place (if you started with a 2.2.## version of Apache).  Reboot and away you go.  Oh, don't forget to stop the Apache server before starting all this.

Good Luck and if you have questions, post them here!!

Jeremy Davis's picture

Assuming that you got them from a later version of Ubuntu, probably a better way to go would be to add the repo (and the security repo) and pin those apache (and dependancy) packages to that repo (so it only updates apache and doesn't try to update everything). That way you can get updates in the normal way.

Otherwise as I said before you will not receive any security updates and will continuously and manually have to check all these packages for updates and go through this whole process regularly. Like I said this will add huge overheads to your maintenance schedule and actually make your server less secure (there will be greater gap between when security vulnerabilities are found and when you manually patch them, as opposed to automatically applied backported security patches - as is the case in a vanilla TKL appliance).

Did you speak with your security scan company? Because whilst this exercise may make your server 'compliant' in their eyes, realisticlly it is making your server less secure. So it depends on whether your aim to to find an 'easy' way to make your server compliant in their eyes, or whther you are actually trying to make your server as secure as possible...

Personally if they don't understand how security works in Linux (ie backported patches) then I'd be looking for a new security scan company. Considering that over half of the webservers online are running Linux surely there'd be some about that do understand it and would actually be properly testing for real vulnerabilities, not just checking versions...

I spoke with them but they are unresponsive.  I am just trying to satisfy them for now.  I will rebuild this thing in April when the new release comes out.

However, now I have to block the SunRPC port.  I tried running RPCinfo -p but only get an error (I believe it is disabled).  However, they are still reporting UDP activity on port 111.  Is there an easy way to disable activity on UDP 111?

Thanks again for your help.

Jeremy Davis's picture

The easiest way is probably to enable IPtables (firewall - which is disabled by default) and block that port. You can do this via Webmin but obviously you'll also need to enable all the ports you use (eg 80 & 443 for HTTP, 22 for SFTP & SSH, 12320 - Webshell, 12321 - Webmin, 12322 - phpMyAdmin + any other custom ports).

Also you can find out what is listening on port 111 using this command:

netstat -l | grep 111

I run that command and I get NOTHING.  The netstat doesn't show anything on 111.  I think that port is being assumed open by the security people but it isn't.  I will be adding it to the IPtables in my Webmin and go for it that way.

 

Thanks,

Doug

Add new comment