WordPress Login Brute Force Protection

Lately I’ve had a bunch of wordpress sites that seem to randomly come under brute-force attacks on their wp-login pages.  One relatively simple solution is to password-protect the login file which will block the attacker from even trying to log in.  Seems like a reasonable security measure that can be put in place.  Use a htpasswd generator to create the .htpasswd file.

Add the code below to your root level .htaccess file, and make sure to change out the path to your .htpasswd file as necessary.

# START brute force protection
 ErrorDocument 401 "Unauthorized Access"
 ErrorDocument 403 "Forbidden"
 <FilesMatch "wp-login.php">
 AuthName "Authorized Only"
 AuthType Basic
 AuthUserFile /path/to/.htpasswd
 require valid-user
 </FilesMatch>
 # END brute force protection

PayPal 2016 merchant security upgrades

PayPal is upgrading SSL certificates, connection types, and so forth, which is generally a good thing.  However, CentOS has a tendency to be a bit behind on just about everything and that includes the version of cURL that is bundled into the OS.

To test your CentOS machine (or just about any linux machine) to see if it’ll be compatible with PayPal’s new updates, run this command:

curl https://api-3t.sandbox.paypal.com/nvp

If you get an SSL Error (35), you’ll need to run some updates.  If you get a long string back from PayPal complaining about the method not being supported, then you’re in good shape.

To get CentOS to actually use a modern version of cURL, there’s some great instructions here http://serverfault.com/questions/321321/upgrade-curl-to-latest-on-centos that worked perfectly for me.

Why You Should Never Use MongoDB

Had a project today that I figured might be a good use case for MongoDB.  Since I’ve never used that tech before, I started googling around to see if my use case would be a good fit.

As it turns out, I can probably just use a combination of MySQL and Amazon S3 and make it easier and cheaper than using MongoDB, but along the way I found a great read: Why You Should Never Use MongoDB by Sarah Mei.  She talks about using MongoDB as a replacement for a relational database (MySQL, PostgreSQL, etc.) and how it doesn’t fit that use case in real-world situations.  If you’ve got some random JSON data and that data can be of formatting any-which-way, then MongoDB works great.  It also seems to work well as a cache layer between a RDBMS and code, but as a straight up replacement to an RDBMS? Nope.

SNI is Awesome!

I learned something awesome the other day — you no longer need a dedicated IP address for every site that needs to have an SSL certificate!  Not only does this greatly help with IPv4 exhaustion, but on a personal level, it means that I can throw more SSL-based sites on a single server without needing to add additional IP addresses.  So cool!

To make it work, your server needs to be SNI compatible.  Looks like most modern operating systems are, including CentOS 6, which I’m using to host my “big” server at AWS with cPanel.

I’m just so excited about being able to host as many secure sites as I want without any concern for IP address allocation.  Cool!

BTW, I found a place to get SSL certificates for $8 per year, and they’re using the same backend technology as GoDaddy.  If you haven’t already, check out Starfield Technologies.

Video Creation

I just got done putting together the “why” video for DuxCal.  1 minute and 15 seconds of finished video took I-don’t-know how many hours to put together.  Writing the script, recording the raw footage, finding the right supporting media, doing voiceovers, editing the script, additional voiceovers, editing, and finally publishing, takes quite a while.

When you see a really smooth professional video with a great script, good camera work, and a clear voiceover, that should be appreciated just for the art and talent it took to create it.

I don’t think I’ll ever become a professional at video creation, but it is really nice to have a finished product!

DuxCal

We’re really happy today to announce a brand new product, DuxCal!  DuxCal is a scheduling system that people can use to book time on your calendar without the hassle of trying to negotiate an available, figuring out timezones, and the back-and-forth of too many emails.

With DuxCal, you simply send a link to your calendar and the recipient can schedule time that works for you and works for them.

Right now DuxCal is in a free beta period.  Once the beta period is complete, it will be priced at $15/user/year.  For more information, check out http://duxcalendar.com

Example screenshot of booking time:

Screen Shot 2015-06-27 at 12.53.07 PM

Amazon AWS Cloud Conversion

All small businesses are affected at one time or another by growing pains, whether in staffing, product offerings, or technology.  One of our clients recently contacted us to say that they had outgrown their “home grown” system and needed to find a real enterprise solution with an architecture that would last through their next few stages of growth or beyond.

In this situation, the client wanted to move from multiple co-location cabinets to a 100% cloud based solution with zero single points of failure.  Zero single points of failure means that if any one system goes down, it cannot take the rest of the system with it.  Cost is increased, but confidence and reliability are also increased.

Challenges of the migration:

  • Multiple co-location facilities
  • Around 1 terabyte of database data split onto two MySQL master-master chains each with one or more slaves
  • Multiple active developers continuing with day-to-day engineering work
  • Could not be down for days as data was transferred
  • Multiple regions were desired for complete redundancy

Solutions:

  • Created MySQL slaves on the EC2 architecture and replicated data pre-migration in real time to the cloud for the two MySQL chains
  • Created site-to-site networking (with OpenVPN) for secured VPN networking between the co-location facility and the EC2 VPC (virtual private cloud)
  • Utilized Route 53 for DNS services and enabled latency-based routing with health checks to route users to their nearest data center
  • Various software tweaks to have their system be aware of where it is being executed and make appropriate connections

Result:

  • Migration was performed with approximately 1 minute of downtime
  • Client system now has zero single points of failure
  • Client can now add servers and capacity as needed without physically purchasing hardware or going to a data center

Timeline and costs:

  • Project was completed ahead of schedule
  • Costs for cloud hosting services are coming in exactly within predicted range

Personally, this was a really fun project.  It’s great to see a client’s systems mature from something “home grown” into a real enterprise solution.  I know they now have an architecture that will last them a very long time.