security help please

[webhead]

One of my hosted accounts now has to pass some test by Security Metrics in order to take credit card payments over the internet. They gave me a list of failed tests, but they all look like server-level things that I'm not sure I can change. I'll try to briefly list the issues and hope someone can direct me to tutorials or whatever. Some came with instructions for unix-type commands, and I'm not sure if or whether I can do those.

-- turn off ports 21 and 25

-- turn off ICMP replies

-- turn off ping requests

-- 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 (http and https)

-- This SMTP server is running on a non standard port. This might be a backdoor set up by attackers to send spam or even control your machine. Solution: Check and clean your configuration Risk Factor: Medium

-- The remote host is using a version of OpenSSL which is older than 0.9.6m or 0.9.7d There are several bug in this version of OpenSSL

-- The remote service encrypts traffic using a protocol with known weaknesses. Description : The remote service accepts connections encrypted using SSL 2.0

-- The remote host is using a version of OpenSSL which is older than 0.9.6m or 0.9.7d There are several bug in this version of OpenSSL

-- Synopsis : Debugging functions are enabled on the remote HTTP server. Description : The remote webserver supports the TRACE and/or TRACK methods

[Ron]

I am not sure, but given that list, you might have to have a VPS or dedicated server that you can configure to their specifications to pass their tests.

[webhead]

Thanks Ron, that's what I was thinking. But if so, then I'll have to talk to someone official-like at JagPC to get some kind of explanation for this security firm. I can't believe Jag or any other reputable host would have so many security risks, if they really are as bad as this firm says they are.

[mattsiegman]

That security company is full of morons. Ports 21 and 25 are standard SMTP ports. They are perfectly fine so long as the mail server is properly configured. Several of the other tests are pretty stupid too.

But I would talk to Greg of one of the support managers to see what the official response is.

[webhead]

I will be more than happy to pass that along to them, thanks matt. ;-)

Now off to find this Greg.

[webhead]

I should add that the hosted account does not actually handle the payments anyway but passes them off to PayPal. A hacker would have to intercept the page with the PayPal button on it in order to make a customer think they're paying my hosted account instead of the hacker. I have no clue how to prevent that.

[webhead]

The response from Support is that what the security firm is calling "holes" are safe "features" instead. I'd have to move to a dedicated host in order to comply with their demands, and I don't think they can force everyone who does online commerce to do that. I'm going to pass along Support's statement to them and see what happens.

[Connie]

Who is requiring you to use this security firm or their recommendations in order to take credit cards online?

The only time Visa Mastercard requires a site pass security test is when they are doing a certain volume of business online.

If your using paypal, you only need to satisfy paypal.

[webhead]

Supposedly this is coming from Visa and Mastercard. The business I'm hosting is a small weekly newspaper that takes credit card payments over the phone and internet, but internet is through PayPal. They have to fill out quarterly forms that make the IRS look like amateurs, to be allowed to use the credit card services. The credit card companies have contracted with Security Metrics to handle the internet compliance end, and take whatever this firm says as pass or fail.

It's even more ridiculous when we consider that this newspaper only gets maybe one or two online subscriptions a month, which totals less than $100.

[Connie]

I've read the Visa MC regulations. Can't point to them right now. They break online merchants down into several classes based on the volume of monthly transactions. At this time the average small merchant does not have to comply with the security checks. Your certainly not limited to a specific company.

If the only way you are taking payments online is through PayPal the regulations do not apply to you at all. They are meant for merchants who take credit card information on their site. With PayPal, you are passing the customer to PayPal to enter the information.

[Ron]

This is just silly!

Paypal has no such requirements of which I am aware; the secure payments are handled entirely on their (PayPal's) own site.

An organization with which I was associated had a credit card merchant account that specifically forbade internet transactions, so the credit cards were used at live gatherings and over the phone, and paypal was used for internet transactions.

It sounds like your group has the same setup, so the internet security issues don't need to be enforced for their account since they will not be accepting credit cards over the web.

[webhead]

Well, Security Metrics just dropped a bomb and told us we have until TOMORROW to comply with something called PCI-DSS, and will not insure online transactions involving Visa or Mastercard without it. They don't care how little business we do, only that someone could intercept our PayPal button page and charge any amount they want. The credit card companies would then hold us liable for something like $50k.

So their issue isn't with whether PayPal is secure, or how much we set our PayPal button for, but the fact that a hacker could display their own mock payment page.

Supposedly, every company in the world that uses Visa or Mastercard has to comply. I have no way of disproving that, or else most people take the risk. I put in a support ticket and hope it goes high up this time.

[Ron]

Maybe you should contact PayPal for help in dealing with this; perhaps they've dealt with this before.

I really don't understand why they don't get it. You aren't the ones making the credit card transaction. The PayPal transaction does not go through YOUR merchant account. Paypal takes the risk, and then credits your bank account with funds from PayPal, not from a credit card.

I would tell them that you do not accept credit card transactions over the web with your merchant account at all. You direct people to PayPal. Stop telling them that you "accept credit cards using PayPal". You don't. You accept payments from PayPal. You have no idea from where the funds come from your customer -- they could come from their PayPal account, from a linked bank account. They could come from a balance in Malaysian Ringgits, for all you know.

If you also had a way to barter for services over your website, would they still be so concerned? The PayPal transactions have nothing, I repeat: NOTHING to do with your merchant account.

Finally, PayPal button codes are encrypted and they probably only carry your merchant ID and amount and other non-sensitive info, and they simply are a link to PayPal's site. If PayPal's page were intercepted that would be PayPal's issue; and I'm guess their site meets specs more stringent than Stupid Metric's requirements anyway.

Maybe you should find yourself another merchant processor -- one that is familiar with computers, perhaps.

[webhead]

Good idea, I'll try seeing what PayPal can tell me.

I know, I've tried to tell them the whole reason we use PayPal is to avoid the risk, but all they care is that someone could replace our pay buttons with their own, which is something not even PayPal can possibly control. They don't care who actually handles the transaction, only that someone could think they're paying us thru PP when they're really on a hacker's site. So Security Metrics is focusing on whether it's possible for any of our web pages to be intercepted. The actual money is not the issue.

[jason]

Here's a site with information about the PCI standard: http://www.pcistandard.com/. Keep in mind that it is a vendor site, so it will be biased toward the services they sell, but there is a good rundown of the different merchant levels: http://www.pcistandard.com/merchantlevels.html.

If you are sending transactions to PayPal in the clear there is an alternative which might satisfy Security Metrics. PayPal allows you to create a key pair (essentially a digital certificate) which you can use to encrypt the data you send between your site and PayPal. Basically, what happens is that you send PayPal your public key and then encrypt the transaction data with your private key. Then instead of sending a whole bunch of parameters to PayPal you now send just a long encrypted string. PayPal then uses your public key to decrypt the data and processes it as normal.

Here is a link on how to secure your PayPal buttons: https://www.paypal.com/IntegrationCe...ncryption.html

PayPal also has a page about PCI compliance you might want to read: https://www.paypal.com/us/cgi-bin/we...liance-outside

--Jason