Hi guys,
I'm new to the forum

I've looked through the FAQs and all the other places which are official at Linode and couldn't find an answer to my questions.

I want my online shop or other client's sites which accept credit cards not through PayPal to be able to comply with the PCI-DSS SAQ D.

Which in some of it's requirements , asks for a firewall and an actively updating Antivirus software.

My question is : Are all Linodes protected that way , or should I install on my own Linux machine some flavor of them and that's only something installed on the actual machine?

I have never installed any of these on linux. do they cost money ?

Can I install some free versions of both of these ?

Any answers would be greatly appreciated!

Thanks,
Itamar

_________________
Web Seeds - An Internet Company
www.webseeds.co.il

IMO, you can't achieve SAQ D (with local card data storage) PCI compliance on a Linode, and a firewall or anti-virus is the least of your problems. Disk is not completely under your control (at a minimum any Linode administrator can technically access it). Plus there's no way to completely isolate the physical network, which means every other machine touched by your Linode (or at least on the same fabric, but the network topology is not exposed) technically needs to comply as well. Particularly with SAQ D, I think you'll have a hard time answering a lot of questions that require implementation of items outside of your administrative control in a VPS environment.

You might take a peek at viewtopic.php?t=5622 where this was also discussed - I think the net result was an agreement that you really don't ever want to touch card data if you have any way of helping it.

I used to think achieving PCI compliance (with stored data) would be unlikely in any VPS environment, but then Amazon went and apparently became certified as a service provider, so I suppose it isn't impossible.

-- David

Edit: Update to qualify overly broad comment about "PCI compliance" since some forms (e.g., SAQ A and probably C) should be ok in a VPS environment as they don't trigger as many of the physical controls as do card data storage and SAQ D. PCI compliance at the smaller merchant levels is also self-certification, so this is just my opinion.

It's a checklist, not a form of security, so it's entirely up to what the person(s) checking through the checklist thinks. It's also designed for an older time, when servers were big boxes in a room in your building and people wore ties and everything ran Windows NT. I have no idea what viruses have to do with anything, but I take a lot of oseltamivir when handling credit card payments, just in case.

My solution: don't play the PCI game at all. Exposing yourself to the legal and financial liability of credit card handling adds all sorts of Problems and Concerns that you can otherwise ignore.

_________________

/* TODO: need to add signature to posts */

Your credit card processor almost certainly has a remote processing option anyhow. Either part of the order process redirects the user to their server (often with a skin to look like it's part of your site, on the higher end packages), or it goes in an iframe, or that sort of thing.

Right now, we're doing that with paypal (who we're using as a payment processor for credit cards), since we don't want to have to worry about it. And before you laugh at the "paypal" comment, we haven't yet had an offer from any "real" credit card processors that beat PayPal's rates sufficiently to make it worth our while to switch.

You should look at Stripe. You can create a form that's hosted on your own site and have the credit card data posted to their servers, so it never has to hit yours and you don't have to worry about PCI compliance. Their fees are the same as PayPal's too.

It looks like a very good service, and much more developer-friendly but unfortunately three things would keep us from switching:

1) They're US-only, and we're in Canada
2) Their rates (2.9% + $0.30) are higher than PayPal's (as low as 1.9% + $0.30 depending on volume).
3) Even if the rates are the same, there would be a momentum to overcome, kind of a "if the rates are the same why switch"

I'll keep my eye on it, though, if their rates or availability improves. We have no great love for PayPal.

One can easily achieve PCI Compliance levels 2-4 on Linodes. We've done it, plenty of customers have done it. There's nothing about Linode that precludes one from getting certified.

Level 1 is a different story, however it's for the Walmarts and other very large organizations ("Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region").

-Chris

I'm not familiar with credit card transaction compliance, but I'll mention that most Linux distros have iptables preinstalled for a firewall. It's a command line utility with GUI frontends, and confusing to learn, but easy once you know it.

There's also ClamAV for antivirus, which is also command line with GUI frontends. Antivirus is generally not needed in Linux, as long as you remain with well-known and fully open source software, avoid using root/sudo as much as possible, and pay attention to what you're doing, anti-virus isn't needed. I'll add in, however, that virtually anybody who uses ClamAV or any of it's Windows ports live by ClamAV.

_________________
Kris the Piki Geeker

I don't think it's the merchant level, though 1 does clearly have more stringent requirements, as much as the compliance level (A-D). If actual card data is being stored (SAQ D) as in the OP's post, it seems to me that there are elements that are really tough to satisfy (or are outside the control of the merchant), such as the physical access restrictions. I mean you could claim compliance, but it wouldn't necessarily be technically true. Then again, that's true of a lot of the PCI compliance process, as is the converse where just being compliant does not necessarily guarantee security.

But I do agree SAQ A, and probably C, should be doable as long as no card data is stored on the Linode, and my first response was probably written too broadly, which I'll clarify.

-- David

While it only matters if you need the feature, which many sites might not, one thing I don't believe they do is provide a way to securely store card data for later use (such as as returning customer, or recurring billing).

Another recent player in the space is Samauri (https://samurai.feefighters.com/) who seems a more direct competitor to someone like Braintree in terms of API. I'm still mostly watching since its a pretty new offering

At the very least, it's nice to be seeing some new players who let you fully control the whole user experience while still letting you maintain separation from the card data.

-- David

They do indeed support recurring billing.

But do they support recurring billing with random amounts?

For example, in Canada, the dominant coffee chain is Tim Hortons. They don't accept credit cards in-store, but you can get a reloadable card and fill it with a credit card online. On their website, I've configured the card to automatically refill to $40 whenever the balance drops below $20. Depending on what items I buy in-store, the refill amount is variable, as is the period between refills.

I think "perfect" might become the enemy of "good enough" here. The one I do have experience with (Braintree) supports that scenario, though, by storing card data in a "vault", accessible with a token you can safely store locally.

Tim Hortons probably also has the physical facilities and regulatory support to make a lot of this happen in-house.

(Interestingly, they do accept credit cards in the US. The environment is such that high-speed signatureless transactions are possible, and faster than cash most of the time. Always throws me off when I'm in Canada and forget to bring cash, but the Tim Hortons outside of the Air Canada baggage clam at Pearson takes one of my cards, so it's all good.)

Yes, they do. You can do it one of two ways:
1. Changing the customer's plan, and thus the price
https://stripe.com/docs/subscriptions - look for "Changing a customer's subscription"
2. You can bill the customer based on usage
https://stripe.com/docs/subscriptions - look for "Metered billing and one-time charges"