PCI Compliance

The other day I had an old client forward me an email from their credit card processing company, saying that the server upon which their website was hosted failed their PCI Compliance security check.  I had never heard of this and was wary that it might be a service they were being tricked into adding on, but upon further investigation, I learned that many credit card processing companies are now instituting this new security policy, which is designed to tighten up security on web servers in order to decrease the chances of credit card theft.

This sounded all well and good, and I figured that with my background in securing servers to meet Department of Defense standards it ought to be a breeze.  Little did I know that the server in question would put up quite a battle for the lone reason that it was running Plesk, the web host management tool.  I had written off Plesk long ago, having ditched the server I had it running on after many issues with it, and I thought I would never have to work with it again, but alas…

I started Googling, of course, and found some great resources out there which cover the tightening up of Plesk in order to meet PCI compliance.

One of the best articles I found was at linux-advocay.org, which explains how to fix issues with Courier, Qmail, Apache, SSL, and iptables in case you don’t have Plesk’s Firewall add-on.

Also, a fellow by the name of DrJermy writes of his solutions about dealing with Plesk and PCI Compliance.

For some general information about what PCI compliance is all about, check out pcicomplianceguide.org.

My Take

As I worked through the PCI issues with the client who contacted me, I started realizing that the standards by which the server was being scanned were presumptuous in that they didn’t take into account back porting, as implemented by RedHat, and that they were making me fix issues which seemed rather trivial in regards to credit card processing security.

If they really wanted to do something that mattered, they should have a look at the NSA’s hardening guides.

Google Responds to GMail Vulnerability Allegations

Google says the recent GMail account breeches were due to typical phishing scams, not a vulnerability in GMail itself.

With help from affected users, we determined that the cause was a phishing scheme, a common method used by malicious actors to trick people into sharing their sensitive information. Attackers sent customized e-mails encouraging web domain owners to visit fraudulent websites such as “google-hosts.com” that they set up purely to harvest usernames and passwords.

They don’t say exactly how the usernames and passwords were harvested, however.  Were people just dumb/gullible enough to type their Google usernames and passwords into some other web site?  Or was there a way for these phishing sites to grab the authentication info from the user’s browser?  Is this the fault of the web browser or a faulty plugin?

While the fingers continue to be pointed, the specific methodology for adding malicious filters to a GMail account by way of a phishing attack remains a threat.

GMail Vulnerability? Watch Your Back.

I’ve been following the story about the domain name hijacking of MakeUseOf.com the last few weeks with interest.  All signs are pointing to the domain thief having cracked the MakeUseOf.com Gmail account in order to retrieve their GoDaddy.com password and transfer the owenership of the domain.

This is not good for any GMail user, let alone domain name owners who have registered their domains through GMail.

Apparently, this one hacker has stolen over 850 domains this way, and holds them for ransom at $2000 a piece.

The latest part of the saga details how the MakeUseOf.com folks think this happened, right down to the hacking of the GMail account.  If there is indeed a security flaw in GMail, which there appears to be, MakeUSeOf.com offers prudent steps to take in order to secure yourself (emphasis added by me):

(1) Well, my very first advice would be to check your email settings and make sure your email is not compromised. Check fowarding options and filters. Also make sure to disable IMAP if you don’t use it. This also applies to Google Apps accounts.

(2) Change contact email in your sensitive web accounts (paypal, domain registrar etc.) from your primary Gmail account to something else. If you own the website then change the contact email for your host and registrar accounts to some other email. Preferably to something that you aren’t logged in to when browsing web.

(3) Make sure to upgrade your domain to private registration so that your contact details don’t show up on WhoIS searches. If you’re on GoDaddy I’d recommend going with Protected Registration.

(4) Don’t open links in your email if you don’t know the person they are coming from. And if you decide to open the link make sure to log out first.

I would add to that list:

(5) Always use secure, encrypted GMail.  There is an option at the bottom of the main Settings page in GMail for “Always use https” under the “Browser Connection” heading.  Select this and leave it selected!  Otherwise, anything you do in GMail is sent unencrypted over the Internet.  Not good!

Keep in mind that this security flaw not only matters to domain name owners, but to anyone who has any sensitive email in their GMail account, whether it be online banking info, love letters, or whatever.

This will be interesting to watch, and I hope Google takes notice of this.

UPDATE:  This fellow here has posted a proof-of-concept on creating malicious filters in someone’s GMail account.

Who’s hogging the pipe?

If you’ve found yourself in a Network/System Admin position without the proper tools, and can’t seem to get them, there’s usually a way to do things for free with Linux or at least using the repos provided under an enterprise support package such as RHEL. 🙂 This is for monitoring who’s chewing up the pipe by IP address.

* Obviously there’s 100 ways to skin a cat in Open Source, but this is one way that can take you from “Who’s hogging the pipe” to “HEY! Stop doing that” in 15 minutes. Granted this isn’t meant for controlling the traffic, that’s another story. *

How To: ( Warning! – You may need to verify this action with your IT Dept – Warning!)

1. On the Core switch just before the “Gateway” hop takes place, and Pre-NAT rules, you’ll need to enable a port for monitoring the traffic (both TX and RX) to and from the “Gateway”. This box could also be used as a SNORT box. (once again another story)

2. You’ll need a Linux box with dual NIC’s (for remote usage) or a single NIC with Physical terminal access for direct access only.

3. Install and run/configure “iptraf” (using sudo or root access) 
#sudo yum install -y iptraf
#sudo iptraf (once the Screen launches, hit any key)
Scroll down to “Configure” (enter)
Set “Force Promiscuous mode” to ON
(You may wish to keep “Reverse DNS Lookups” off as well)
(Adjust “Additional ports” or any other settings if needed)
“Exit Configuration”
Select “IP Traffic Monitor”
Select the interface that’s plugged into the “Monitored” port. (from Step 1.)
Once the monitoring begins you can sort by bytes or packet count etc.

Find the “Hogger”.

Note: I really like the “iftop” tool as well, but it’s not in the RHEL Repos. ;0)

You can’t control the traffic from this app, but at least you can verify if the traffic is legit or not. Once you have the ip you can do the standard ip/arp/mac table lookups etc. to locate the machine.

HTH.

dbcooper

Practical Security: Wireless Network Security & WPA

In light of the latest wireless vulnerability found, which can break “WPA” using “TKIP” for encryption, I thought I would advise everyone to review your home wireless setup.

The subject of securing your wireless (or wired) networks at home could be talked about for hours on end, and depending on what hardware (model/brand) you have, your set-up and configurations may vary. Please see the documentation that came with your device or the company’s website for more information on the specific model you have. Also, don’t hesitate to call or email the vendor for help if needed.

Basically it comes down to these few things:

  1. Don’t broadcast your SSID if possible. (See your manual, and see this link)
  2. Use Wireless MAC filtering if possible. (See your manual, and see this link)
  3. Don’t use WEP for encryption.
  4. Don’t use WPA w/TKIP (this is now breakable).
  5. Change your WPA from TKIP to AES for encryption. (See your manual)
  6. If your hardware (computer and wireless router) supports it, move to WPA2. (See your manual)

General Home Computer Security Info:

  1. Make sure your Anti-virus application is updating/updated and enabled.
  2. At a minimum, make sure the Windows Firewall is enabled (unless you are on a Mac, in which case you should turn yours on too).
  3. Use strong passwords comprised of alpha/numeric/special characters on all your “Admin” level computer accounts.
  4. If you have any files or folders shared over your home network, make sure they are password protected.

There are a million resources for articles on computers and security online, but here are a few good ones if you are new or inexperienced with the subject (or just need a refresher).

Microsoft Security Resource for Home Users:
http://www.microsoft.com/protect/default.mspx

US-CERT.GOV – Home Users:
http://www.us-cert.gov/nav/nt01/
http://www.us-cert.gov/reading_room/home-network-security/

CERT.ORG – Home Users:
http://www.cert.org/homeusers/
http://www.cert.org/homeusers/HomeComputerSecurity/
http://www.cert.org/tech_tips/home_networks.html

With all that said, have a safe, secure, and happy computing day.

Captchas. No, I didn’t sneeze.

Are captchas annoying to you?  They are to me.  I probably fail at solving them about 15% of the time, which is far too often for my liking.  They get annoying, and as spammers find ways to automate solving them, the captchas continue to get more difficult to read.

Someone who knows a lot about combating spam, and has done a pretty darned good job at it, Matt Mullenweg, suggests in a recent Guardian article that “…Captchas are useless for spam because they’re designed to tell you if someone is ‘human’ or not, but not whether something is spam or not.”  I would have to agree.

There are many efforts to improve upon Catpchas, such as the 3-D Captcha.  In my opinion, this is just making things more complicated than necessary, and would be difficult to implement easily on a typical blog or contact form.

I run about 6 to 8 blogs (depending on my mood from week to week), and have been reluctant to use Captchas on any of them, partly out of usability concerns, but also because they are so easy to fail.  Instead, for my blog comments, I rely upon Mullenweg’s own Kismet spam system.  This feature is built into WordPress blogs, which makes it a breeze to set up, and I am constantly amazed at the loads of spam comments that it stops.

As Mullenweg suggests, focusing on the content rather than the submitter, is the way to go in the long term, and Kismet is great at doing that.

However, I also rely on a simpler test to determine if someone is a human or not mainly because it’s not as annoying as a Captcha, and it prevents a lot of spam comments from making it through in the first place.  It’s easy to add a basic question to a form which must be answered correctly in order for the form to be submitted succesfully.  Questions could be as simple as:

  • What color is an orange?
  • What is 3 plus 3?
  • How many wheels does a car have?

There is a great WordPress plugin which provides this capability and is relatively easy to set up called the Secure and Accessible PHP Contact Form.  If you run any WordPress blogs, I recommend you try it out.

By having a list of simple questions that are randomly selected to appear on your forms, you can stop automated scripts from filling out your forms quite easily.  This, combined with Kismet, a content-based filter of what gets submitted, will pretty much stop spammers in their tracks without creating a hassle for your visitors.