Portal Home > Knowledgebase > Articles Database > Is that enough?
Is that enough?
| Posted by htorbov, 03-10-2014, 10:48 AM |
| Starting third-party processing web platform, which will be used with API calls, similar to Stripe:
1. Brought a new laptop, installed Windows 7;
2. Made registration on Amazon AWS (which is PCI compliant), lunched an CentOS instance with HTTP/HTTPS ports opened globally and SSH only to laptop's IP;
4. Installed apache, php, mysql and clamav on the instance using SSH;
4. Transferred web application (php) to the laptop, using CD (to prevent possible botnets on a flash drive);
5. Changed password/strings encryption keys and mysql authorization passwords;
6. Uploaded the web application to the webserver using SFTP;
7. Closed the SSH port temporary;
Notes:
a) SSL encryption for HTTP calls;
b) pdo() for mysql (with named placeholders to prevent injections);
c) password_hash() for seller's password (password_verify() to verify passwords);
d) mcrypt_encrypt() for cardholder data (mcrypt_rijndael_256 encryption);
e) encryption/database parameters are contained in settings.php, which is with restrictions;
Any opinions?
|
| Posted by Thomas_iKoula, 03-10-2014, 01:38 PM |
| Already a good start so far.
A next step could be looking around your firewall, and to prevent your server to be scanned.
|
| Posted by chrismfz, 03-10-2014, 02:18 PM |
| Mod_security and WAF rules like Atomicorp's or Comodo.
Firewall/IDS like CSF, apf etc.
List will get bigger*, that's good for a start.
(* policies, php handler, php hardening, kernel hardening and so on)
|
| Posted by Afterburst-Jack, 03-10-2014, 02:31 PM |
| Ideally you'd avoid storing card details on the same server as the client login/etc. Thus, if someone successfully attacks your login server damages are far less severe - people do not have your encrypted card details. Your login server will generally be an attacker's first target.
E.g. store a card identifier (like stripe does) in your database on your current server; and have a secondary server that can only be accessed by the first server with specific details (card id, charge amount), instructing it to perform the charge.
|
| Posted by htorbov, 03-10-2014, 07:31 PM |
| Thanks for the answers!
a) the firewall: Amazon EC2 is firewalled itself (using security groups), and I cannot think of more-reliable one. It's simply managed using their control panel. I've set global open ports only on 80/443.
b) the php: it's hardened (suhohin);
c) the system: i's hardened also;
d) the additional server: Very interesting idea. But if the attacker gets into the server (somehow), he'll basically get the access to the other one as well. Something more, PCI compliant standards require encrypted and secured transmitting way of cardholder's data between the networks, which for me looks like unnecessary and unsecured step. Then I'll have to worry about information capture within the network.
I'm very worried about the seller's and customer's data. I want everything to be perfect, simple, fast and secured. I will not start offering the platform's services, before testing it at least few months.
I'm considering using their network scan (https://portal.aws.amazon.com/gp/aws...PenTestRequest), to prevent any firewall concerns.
Also, I'm required to hire PCI QSA to review and scan the system, but I'm interested in the community opinions as well.
Last edited by htorbov; 03-10-2014 at 07:44 PM.
|
| Posted by Afterburst-Jack, 03-11-2014, 03:57 AM |
| The idea is he only has the card identifer and the ability to instruct your other server to conduct a charge. He would not have the ability to get the encrypted card details. If you also store who should be the recipient on the other server ( like stripe ) damages would be minimal even with a full breach of security on your login server.
|
| Posted by htorbov, 03-11-2014, 06:02 AM |
| Yes, excellent. I can make it that way.
Thanks for the tips, guys!
|
Add to Favourites 
Print this Article
Also Read
Shared Hosting
Shared Hosting
