PCI Compliance questions

B

bkluth

Verified User
Joined
May 3, 2004
Messages
28
Hello,

I have several clients who need to be PCI Compliant, and I am their host.

I am running DA on 3 servers...these items will need to be addressed on all three servers.

Server/DA versions:
Server 1: DirectAdmin 1.29.2
Server 2: DirectAdmin 1.31.1
Server 3: DirectAdmin 1.28.5

(Would updating DA to current version (?) on all 3 servers correct any of these items?)

So here are some items and questions:

Item 1: The remote POP3 server might be vulnerable to a buffer overflow bug when it is issued at least one of these commands, with a too long argument : auth user pass If confirmed, this problem might allow an attacker to execute arbitrary code on the remote system, thus giving him an interactive session on this host. Solution: If you do not use POP3, disable this service in /etc/inetd.conf and restart the inetd process. Otherwise, upgrade to a newer version.

Question 1: How would I update to the newest (stable/secure) version of pop3?
Server 1: vm-Pop3d 1.1.7f-DA-2
Server 2: vm-Pop3d 1.1.7f-DA-2
Server 3: vm-Pop3d 1.1.7f-DA-2

Item 2: The remote host is using the Apache mod_frontpage module. mod_frontpage older than 1.6.1 is vulnerable to a buffer overflow which may allow an attacker to gain root access. *** Since SMetrics was not able to remotely determine the version *** of mod_frontage you are running,
you are advised to manually *** check which version you are running as this might be a false *** positive.

Question 2: How do I tell what version of mod_frontpage I am running, and how would I update to the newest (stable/secure) version? I do require FP for my clients to use.

Item 3: Synopsis : The remote service encrypts traffic using a protocol with known weaknesses. Description : The remote service accepts connections encrypted using SSL 2.0, which reportedly suffers from several cryptographic flaws and has been deprecated for several years. An attacker may be able to exploit these issues to conduct man-in-the-middle attacks or decrypt communications between the affected service and clients. Solution: Consult the application's documentation to disable SSL 2.0 and use SSL 3.0 or TLS 1.0 instead.

Quesiton 3: How would I update this?

Thanks for any information you can provide.
Becky
 
Last edited:
You cannot update mod_frontpage since Microsoft stopped supporting it in June 2006. Its best to remove it and tell your clients to use the ftp built into their FrontPage client. If they are using FrontPage specific feature they need to stop using them as soon as possible because those are a thing of the past.
 
bkluth said:
I have several clients who need to be PCI Compliant, and I am their host.

I am running DA on 3 servers...these items will need to be addressed on all three servers.

Server/DA versions:
Server 1: DirectAdmin 1.29.2
Server 2: DirectAdmin 1.31.1
Server 3: DirectAdmin 1.28.5

(Would updating DA to current version (?) on all 3 servers correct any of these items?)
Click to expand...
Probably not. Update them anyway.
Item 1: The remote POP3 server might be vulnerable to a buffer overflow bug when it is issued at least one of these commands, with a too long argument : auth user pass If confirmed, this problem might allow an attacker to execute arbitrary code on the remote system, thus giving him an interactive session on this host. Solution: If you do not use POP3, disable this service in /etc/inetd.conf and restart the inetd process. Otherwise, upgrade to a newer version.

Question 1: How would I update to the newest (stable/secure) version of pop3?
Server 1: vm-Pop3d 1.1.7f-DA-2
Server 2: vm-Pop3d 1.1.7f-DA-2
Server 3: vm-Pop3d 1.1.7f-DA-2
Click to expand...
Update to Dovecot (search these forums) and see if these problems go away; if not, then discuss the specific problems with the Dovecot community; it's both active and fast-moving.
Item 2: The remote host is using the Apache mod_frontpage module. mod_frontpage older than 1.6.1 is vulnerable to a buffer overflow which may allow an attacker to gain root access. *** Since SMetrics was not able to remotely determine the version *** of mod_frontage you are running,
you are advised to manually *** check which version you are running as this might be a false *** positive.
Click to expand...
Do that. Check the version.
That said, floyd's response makes sense, too :).
Question 2: How do I tell what version of mod_frontpage I am running, and how would I update to the newest (stable/secure) version?
Click to expand...
Code: 
# ls -al /usr/local/directadmin/customapache/mod_frontpage-*
On our servers that returns 1.6.1. It should on yours as well.
I do require FP for my clients to use.
Click to expand...
1.6.1 is the latest version; there won't ever be another version.
Item 3: Synopsis : The remote service encrypts traffic using a protocol with known weaknesses. Description : The remote service accepts connections encrypted using SSL 2.0, which reportedly suffers from several cryptographic flaws and has been deprecated for several years. An attacker may be able to exploit these issues to conduct man-in-the-middle attacks or decrypt communications between the affected service and clients. Solution: Consult the application's documentation to disable SSL 2.0 and use SSL 3.0 or TLS 1.0 instead.

Quesiton 3: How would I update this?
Click to expand...
Code: 
# ls -ald /usr/local/directadmin/customapache/mod_ssl-*
The above should return the version of ssl you're running. The most recent supported by DirectAdmin appears to be mod_ssl-2.8.30-1.3.39; perhaps someone will have an idea on how to update to a later version.

Or perhaps I'm looking at this incorrectly and someone else can update this reply.

Jeff
 
We are in a similar situation. One of the issues we have been working with after a security scan by a 3rd party provider is the security of SSL v2.0 vs. v3.0.

Due to the security weaknesses with the SSL v2.0 protocol we are attempting to disable this option. From extensive searching it appears that all applications/services that use SSL will need to have this disabled independantly. To see if your server allows for SSL v2.0 enter the following at a command line:

# openssl s_client -port 443 -host "Enter IP address Here" -ssl2

If your server accepts SSL v2.0 you will see communication open along with the public SSL cert - take not of the final lines that verify the SSL v2.0 protocol:

New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : SSLv2
Cipher : DES-CBC3-MD5

For Apache we have found that the following additions to the httpd.conf file are the way to go. Under the <VirtualHost "IP of Host Server":443> we have added the following directives (this is not the <VirtualHost _default_:443> section - look further down in your httpd.conf):

SSLOptions +StrictRequire
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

The second line tells Apache to only use TLSv1 and SSLv3 while the third line designates the suite of encryption ciphers to use. We originally added these directives to the <VirtualHost _default_:443> section, but it did not appear to work as planned.

We restarted Apache and followed up by entering the openssl command above. At this point we receve an error message that suggests SSL v2.0 is not avaiable - good thing:

CONNECTED(00000003)
4106:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s2_pkt.c:428:

With this in mind, we attempted to modify the virtual host(s) templates in /usr/local/directadmin/data/templates/. After rewriting all existing users httpd.conf files to include the above directives we are still seeing SSL v2.0 connections as being availabled for each virtual host/IP on the server.

It appears that a directive like the above (SSLProtocol + SSLCipherSuite) needs to be implemented for all IP's on the server. Otherwise you will see that the openssl s_client command (above) will still allow SSL v2.0 connections on a per IP basis. We have succesfully disabled SSL v2.0 for the host server IP in the httpd.conf file, but are not struggling with how to do this for all virtual host IP's.

Any recommendations? Is it possible to add additional Virtual Host directives in the host server httpd.conf file for all IP's on the server? Or will this conflict with DA's virtual host files?
 
Hello,

For SSL setups, the most important virtualhost is the first one, as it's the one used for the handshakes. All other virtualhosts are ignored for SSL. Once the connection is established using the setting from the first VH, then the name based lookups will continue normally and the other VH's are used.

SO, what you need is this template:
/usr/local/directadmin/data/templates/ips_virtual_host.conf

It contains the first virtualhosts used in /etc/httpd/conf/ips.conf. These are the ones that will control the SSL certificate and SSL rules.

You could also try adding them to the global virtualhost which is loaded before even those ones. In the /etc/httpd/conf/httpd.conf, there is a virtualhost:
<VirtualHost _default_:443>
which defines the generic rules that all port 443 VH's will have.. so it would actually be easiest to add your rules withint that VH (assuming it accepts it)

John
 
John your awesome - thank you!

I was rewriting all of the virtual_host files thinking that the user httpd.conf files were the solution. I completely overlooked the ips.conf - works GREAT!

In our installation adding the settings to the <VirtualHost _default_:443> didn't do anything (even for the host server). However the second VH in /etc/httpd/conf/httpd.conf worked for the host server while ips.conf worked for all virtual hosts.

Thanks again!
 
DirectAdmin Support said:
Hello,


SO, what you need is this template:
/usr/local/directadmin/data/templates/ips_virtual_host.conf



You could also try adding them to the global virtualhost which is loaded before even those ones. In the /etc/httpd/conf/httpd.conf, there is a virtualhost:
<VirtualHost _default_:443>

John
Click to expand...

I've followed these steps and SSLv2 is not available for port 443 on sites, but PCI is still complianing that it is available on port 2222. I have looked through every .conf file, but cannot find a section dealing with SSL on 2222. How do i change that?

Thomas
 
Hello,

Yes. The directadmin.conf is used to override the internal defaults. For this option, it's blank, so adding it to the directadmin.conf will determine what it's set to.

John
 
DirectAdmin Support said:
SO, what you need is this template:
/usr/local/directadmin/data/templates/ips_virtual_host.conf

It contains the first virtualhosts used in /etc/httpd/conf/ips.conf. These are the ones that will control the SSL certificate and SSL rules.
Click to expand...

John, It does include the virtual hosts with dedicated IPs however it doesn't include the server's primary IP. How can I add the CipherSuite to the primary IP address of the server? I have tried adding it to _default_ but that isn't working at all. Heck I have added to just about every virtual host directive and the primary IP is still accepting SSL v2.

BigWil
 
However, I did find that if I add a VirtualHost directive after the _default_ directive that this does work. Like so:
<VirtualHost 12.23.34.45:443>
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
ServerName shared.domain
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
ScriptAliasMatch ^/~([^/]+)/+cgi-bin/+(.*) /home/$1/public_html/cgi-bin/$2
AliasMatch ^/~([^/]+)(/.*)* /home/$1/public_html$2
DocumentRoot /home/admin/domains/sharedip

User admin
Group admin

CustomLog /var/log/httpd/homedir.log homedir
</VirtualHost>
 
After you do all of the above, then setup a proper firewall so block port scanning after 10 or so attempts.... pci scanning engines will be blocked after the limit reached. Most PCI companies come up with many false positives as they don't seem to understand that patched software versions are acceptable.... you will have to manually submit each patched version as they find an issue with the main release version.

It's a pain, but it's needed as well.
 
Yes I already block them on a couple of ports, but I wouldn't suggest blocking them on all ports as they will just fail with an unable to scan device notice. I do block things like proftpd and ssh at the firewall. Also block phpMyAdmin using Mod_Security. They don't seem to accept patch responses on those for sure.
 
BigWil said:
John, It does include the virtual hosts with dedicated IPs however it doesn't include the server's primary IP. How can I add the CipherSuite to the primary IP address of the server?
Click to expand...
The server IP's VirtualHost lives in:
/etc/httpd/conf/extra/httpd-vhosts.conf

John
 
Ahhhh... hiding in the extras. Didn't think of looking in those aside from the httpd-ssl.conf where I did not find it. I will switch things around tomorrow. Thanks John.

Big Wil
 
BigWil said:
Yes I already block them on a couple of ports, but I wouldn't suggest blocking them on all ports as they will just fail with an unable to scan device notice. I do block things like proftpd and ssh at the firewall. Also block phpMyAdmin using Mod_Security. They don't seem to accept patch responses on those for sure.
Click to expand...

Trust me.... try it first.... :)
 
DirectAdmin Support said:
Hello,

Yes. The directadmin.conf is used to override the internal defaults. For this option, it's blank, so adding it to the directadmin.conf will determine what it's set to.

John
Click to expand...

Hello,

after i change anything on directadmin.conf,

should i do directadmin restart ?


thank you
 
Yes, DirectAdmin needs to be restarted after making any change to the directadmin.conf.

The dataskq reads the directadmin.conf fresh each time, so your changes with regards to the dataskq are instant. Failure to restart DA can cause issues in this case because the directadmin binaries would think the setting is the oldway, and the the dataskq would see the new way.. so you've have sync issues. With things like dovecot=1, this is very important, as the dataskq does bacukp/restores/mbox-conversions, and the directadmin creates accounts and sets passwords, meaning you'd end up with 2 versions of entires in your password files.

Anyway, short version: Yes restart ;)

John
 
I might be rehashing a few things here on this subject but for the benefit of others who were trying to understand this like I was this is what I ended up doing to get my server PCI compliant. I might add that I was almost to the point of going over to the data center and pulling the server out of the cabinet and throwing it out the window out of sheer frustration.

In a nutshell this is what I did and it finally passed;

Code: 
in /etc/httpd/conf/httpd.conf at the bottom of the file I did this:
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLOptions +StrictRequire
SSLProtocol ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
</IfModule>


in /etc/dovecot.conf I did this;
ssl_cipher_list = HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3

in /usr/local/directadmin/conf/directadmin.conf I did this:
ssl_cipher=SSLv3

And I finally got the server 100% PCI compliant

and this is on a server running CENTOS 5.5 64Bit with DA CustomBuild

Hopefully this is of some help to someone else out there. And a thanks to John from DA support for what to insert into directadmin.conf
 
You must log in or register to reply here.
Back
Top