Mandatory PCI Security Standard from Visa and MasterCard


Well-Known Member
Oct 13, 2005
Spokane, Washington
cPanel Access Level
Root Administrator
i just recieved a email from Merchant Plus. I just enrolled.

Dear Merchant,

Due to the increase in hacker activity and resulting consumer fears of using credit cards online, Visa and MasterCard have recently imposed a mandatory security standard for all merchants, including Level 4 merchants processing less than 20,000 transactions a year.

As of June 30, 2005, you are required to be compliant with the Payment Card Industry (PCI) security standards or risk fines and permanent expulsion from card acceptance programs.

For most merchants, this means enrolling with a Visa and MasterCard-certified security vendor for PCI certification services consisting of Quarterly Security Scanning of your office and store Internet connections as well as your website, plus the completion of a Security Self-Assessment Questionnaire.

It is imperative that you act now to become compliant with the PCI security standards to avoid potential fines and being barred from transacting credit cards. Visa and MasterCard have imposed fines of more than $500,000 per event for non-compliance and data security compromises.

MerchantPlus is here to help. We have contracted with ScanAlert™, the world's largest Web site security certification service, to provide this service to our customers at NO COST for the first year and just $19.00 per year thereafter.

If you select a vendor other than ScanAlert, you can expect to pay between $500 and $5,000 annually for this service.

As a valued customer, your continued business success is important to us. Failure to act now could result in serious fines and the loss of your ability to accept credit cards. As such, we have worked to provide you with a FREE offer from ScanAlert.
Last edited:


Well-Known Member
Oct 13, 2005
Spokane, Washington
cPanel Access Level
Root Administrator
After the first ScanAlert scan of the network and server there a few issues that I saw that needs to be fixed.

So I submitted a support ticket to my host and this what I said

After the scan from ScanAlert there are some issues that has to be fixed for me
to meet the Mandatory PCI Security Standard from Visa and MasterCard.

Your Web server appears to support the TRACE and/or TRACK methods.

It has been shown that servers supporting these methods are subject to
cross-site-scripting attacks, dubbed XST for 'Cross-Site-Tracing'.

General Solution
Block the TRACE, TRACK, or both methods in your Web server.


The remote host appears to have 10 or more open ports.

This is potentially very dangerous and typically indicates that there is no
firewall, or that the firewall has been mis-configured. Given the plethora of
attacks available against many different systems, it is imperative that a good
firewall policy be in place, as it will prevent most exploits from taking

If a firewall is in place, review all open ports and the services running on
them to ensure they are valid. After verifying the ports, you can mark this
vulnerability as resolved.

# Linux:< /b>
# Depending on kernel configuration ipchains or iptables should be enabled and
port filtering configured to allow public access only to ports requiring it.


The remote SSH daemon supports connections made using the version 1.33 and/or
1.5 of the SSH protocol.

These protocols are not completely cryptographically safe so they should not be

General Solution
Set the option 'Protocol' to '2'
To do this edit the sshd_config file, typically /etc/ssh/sshd_config
Add, uncomment, or change the Protocol to 2.
Restart sshd, typically /etc/rc.d/init.d/sshd restart
Set the option 'Ssh1Compatibility' to 'no'

SSH 1 should never be used in a production environment.


The remote name server appears to allow recursive queries.

This means it allows anyone to use it to resolve third parties names (such as If you are not an ISP you should not provide public DNS
resolution as this allows hackers to do cache poisoning attacks against this
Note: This may be a "false positive" for one of the following

# We were unable to conclusively test for this vulnerability remotely, but
based on this device's fingerprint it is possible that it exists.
# When checking for a specific file or response we received a redirect or other
response that was inconclusive.

We suggest you manually check for its existence by confirming appropriate
patches are installed or file redirections, etc. are proper. Then mark this as
"Resolved" below if the vulnerability does not exist.

General Solution
Restrict recursive queries to only the hosts that should use this nameserver
(such as those of the LAN connected to it).

If you are using bind 8, you can do this by adding the following to your
named.conf file options section:

options {
/* other options in your config */
recursion no;
fetch-glue no;

If you are using another name server, consult its documentation.


Oracle Web Listener for NT makes use of various batch files as cgi scripts,
which are stored in the /ows-bin/ directory by default.

Any of these batch files can be used to run arbitrary commands on the server,
simply by appending '?&' and a command to the filename. The command will be
run at the SYSTEM level. The name of a batch file is not even neccessary, as it
will translate the '*' character and apply the appended string to every batch
file in the directory. Moreover, UNC paths can be used to cause the server to
download and execute remote code.

General Solution

Remove the ows-bin virtual directory or verify that there are no batch files in
the directory it points to.


The remote DNS server answers to queries for third party domains which do not
have the recursion bit set.

This may allow a remote attacker to determine which domains have recently been
resolved via this name server, and therefore which hosts have been recently

For instance, if an attacker was interested in whether your company utilizes
the online services of a particular financial institution, they would be able
to use this attack to build a statistical model regarding company usage of
aforementioned financial institution. Of course, the attack can also be used to
find B2B partners, web-surfing patterns, external mail servers, and more...

For a much more detailed discussion of the potential risks of allowing DNS
cache information to be queried anonymously, see the links.

General Solution
Restrict access to your DNS server to local users and child servers.


Perl, sh, csh, or other shell interpreters are installed in the cgi-bin
directory on a WWW site, which allows remote attackers to execute arbitrary
commands with the privileges of the HTTP server (usually root, or nobody).

General Solution
Perform one of the following:

Remove the mentioned script from your cgi-bin directory.

Check the script vendor's site for a patched version of the script.

Create an ACL rule to block public access to this url.


This test attempts to identify the Operating System type and version by sending
modified ICMP requests using the techniques outlined in Ofir Arkin's paper 'ICMP
Usage In Scanning'.

An attacker may use this technique to try and identify the remote operating

General Solution
Block ICMP requests.

No solution is required as this is a low level vulnerability.


We were able to determine which versions of the SSH protocol the remote SSH
daemon supports.

This gives potential attackers additional information about the system they are
This is their reply back

On the following issues:

1) Disabling Trace/Track is not something we are prepared to add to every
single virtual host on our shared servers. On your VPS server you are
certainly allowed to add rewrite rules to disable these per these

2) Any cPanel server is going to have an issue with 10+ open ports. First of
all, the servers are running iptables and have all unecessary ports closed off.
However, it is impossible to stay below this 10 port limit in a cpanel
environment and still offer all the services we do:
Port 21: ftp
Port 22: ssh
Port 25: smtp
Port 26: smtp (for providers blocking port 25)
Port 80: http
Port 110: pop3
Port 143: imap
Port 443: https
Port 465: secure smtp
Port 993: secure imap
Port 995: secure pop3
Port 2084-2096: general cpanel service ports.
Port 3306: mysql

So even before whm/cpanel ports the 10 port setting is breached.

3) SSH V1/V2 are both supported at this time, we'll look into the
ramifications of a global V1 disable.

4) We allow recursive queries so that customers can use their own DNS host
names as their personal resolvers instead of their ISPs so they can see updates
to their website in real time. We aren't going to disable this.

5) There's no ows-bin or Oracle applications on our servers.

6) This would defeat the purpose of offering dns services to our customers

7) Disabling the execution of scripts in a users cgi-bin would render a
majority of users scripts useless.

8) ICMP requests are allowed and aren't going to be disabled at this time as
they don't pose a serious risk of any kind to our network.

9) This doesn't pose a serious risk to our services as openssh is updated and
always kept updated.

System Administrator
From this you can see there are going be issues for those on a shared servers that have users that accept visa and mastercard.


Well-Known Member
May 4, 2004
England, UK
True, but I would expect most ecommerce websites to host on a VPS or dedicated server - there are several downsides to hosting potentially sensitive data on a shared machine.


Well-Known Member
Verifed Vendor
Jun 15, 2002
Go on, have a guess
Indeed. The reply you got seems perfectly accurate and reasonable. Some of those report results are a load of rubbish, some are valid.