A Day in the Life of a CodeGuardian

Twitter Facebook

At CodeGuard, we’ve been able to push a high quality product to market quickly and scale it reliably. Today, we would like to share what happens on a daily basis to make this type of rapid production possible.

Daily Routine

Everyone in the office has different schedules and different priorities. While each team member’s daily routine is different and changes from day to day, here’s what a typical day at CodeGuard for one of our employees might look like.

8:00 Wake up, eat, and get ready for work
9:00 Arrive at work, respond to emails, and plan for the day
9:30 Begin testing new selective restore features
10:00 Gather with the rest of the team for our daily scrum meeting
10:15 Modify the selective restore pipeline to address an unhandled case
10:45 Write an article for our weekly blog post
12:00 Review and implement suggestions made by another team member
12:30 Eat lunch
1:00 More testing for the new selective restore features
1:30 Monthly meeting with supervisor
2:00 Final round of testing for the new selective restore features
3:00 Deploy new selective restore features
3:15 Final testing for the new internal performance metrics dashboard
4:00 Deploy new internal dashboard
4:15 Celebrate two successful deploys by ringing our ceremonial CodeGuard gong
4:30 Leave early and enjoy the holiday weekend


Development Cycle

Now that you’ve seen what a typical day at CodeGuard looks like, let’s talk about our development process.

Our day begins with our daily morning scrum meeting. For those unfamiliar with Agile development practices a scrum meeting is a way for members of a team to share updates regarding ongoing projects. In our scrum meetings we form a circle and have each member share a high level overview of the tasks they completed yesterday, the tasks they plan to complete today and the tasks that need help with in order to move forward. These meetings generally last 10-15 minutes. The rest of the day involves completing the tasks covered during our morning scrum. Typical tasks include planning for new projects, developing current projects, or testing completed projects.


Planning begins at our conference table with each project participant expressing their own thoughts and concerns about project execution. Because our team is small, there is no designated project leader. Instead, one team member is asked to research the project before hand and help guide the discussion. Team members are encouraged to contribute, and sitting idly is not an option. One of the great things about working for a small company is that we have the freedom to try new things. For example, although our main application is written in Ruby, a few of our most recent projects have been written in Go. This level of flexibility would be hard to find at a larger company.


Once we have a plan, we break the project apart into manageable tasks and begin development. We are lucky enough to have access to top of the line tools for writing software. Each employee has their own workstation consisting of an adjustable height desk, 27 inch retina display, and the latest Macbook Pro. Although each team member is free to choose their own development environment, most of gravitate towards command line tools like vim and tmux. We use GitHub issues to keep track of what is being worked on and by whom.


After a task is completed, it must be submitted for review. Depending on the importance of the task, one or several other team members will test and review changes in our staging environment before submitting the final changes to our production servers. In addition to automated testing, the review process often involves analyzing code for uncaught syntactic and logical errors.


Although we spend most of our time working hard to improve our service, being a CodeGuardian isn’t all work and no play. To keep things lighthearted and fun, we have Happy Hour every Friday afternoon, and we routinely plan outings to nearby events. Our most recent adventure involved participating as extras in a big movie production being filmed in downtown Atlanta.


– Taylor

CodeGuard Honored at Georgia CIO of the Year Awards

Twitter Facebook

On October 31st, CodeGuard was honored at the Georgia CIO of the Year Awards ceremony, in the “Emerging” category. Attended by over a thousand technology leaders in the state, the event is one of the largest gatherings of its kind. Excellence was recognized across five categories of company type and size: Non-profit, Emerging (under 250 employees), Corporate (up to 1,000 employees), Enterprise (up to 10,000 employees), and Global (over 10,000 employees).


George Conrades, the Chairman and former CEO of Akamai, gave the keynote. George has been a leader in the technology industry for over 50 years, and his career began 30 years ago at IBM, rising to a senior leadership role under the legendary John Akers. He then joined internet pioneer Bolt, Beranek & Newman as CEO and led their transformation from ARPANET into today’s internet. Over the last 15 years at Akamai, George has helped lead the transformation from premises to cloud computing.


The event was held at the Cobb Galleria and featured a balanced mix of programming, with videos of the finalists, award presentations, and longer videos of the winners. CodeGuard was honored to be one of four finalists in the Emerging category, and though we did not win, were thrilled to have made it to the last stage. Finalists for the CIO Awards are selected by a distinguished panel of CIO judges, including prior Award winners, based on their contributions in innovation, leadership, business value, and community involvement.

The event was organized by the Georgia CIO Leadership Association (GCLA), Georgia’s preeminent professional association for senior technology leaders. Founded in 2003, its membership is comprised exclusively of chief information officers or individuals in equivalent positions from public and private companies, government, education and non-profit organizations throughout the state. The GCLA is a 501(c)(6) professional association led by a CIO Advisory Board from organizations including: Georgia-Pacific, GE Energy, American Cancer Society, NCR Corporation, and The Coca-Cola Company.




CodeGuard restore just got more powerful

Twitter Facebook
Many of our customers find themselves captivated with our Automatic Restore feature, and we don’t blame them! The ability to automatically restore your website back to any date in time with the click of a button is a powerful tool indeed. For some of our customers though, this tool is a little too powerful for their needs. That’s why we recognized the value in having multiple restore options available: Automatic Restore, Individual File Restore, Download Zip.
If you only wanted to restore one folder, out of the 40 folders in your website, our best recommendation to date was for you to download a zip file of the entire backup and restore that one directory manually via SFTP/FTP. Sounds quick and easy, right? Well our customers with larger websites helped us understand very quickly that downloading a 50 GB website was not an option for them!
We knew the time had come to upgrade our Download Zip restore. Today we are proud to announce an enhancement that dramatically improves this feature: Selective Download.

Selective Download

CodeGuard Download Zip Backup Restore
Now when you request a zip backup from your CodeGuard dashboard you are given the option to download the entire backup, or select specific files and folders to download into a zip file. For our customers who added their own websites to CodeGuard this interface will feel very familiar, and look  similar to our website addition process. You can expand folders and uncheck or check as many boxes as your heart desires. We will wrap it all up into a zip file and email you the download link.
CodeGuard Download Zip Backup
In addition to emailing you the link, we will make these zip files available to you in the dashboard for days after they were requested. So instead of hunting through your email inbox to find where that zip file went, you can simply log in to CodeGuard and re-download your zips right from the Restore tab.

Behind the scenes

The final set of improvements we made to this feature are ones that can’t be seen in the interface. Our engineering team put their heads together to create a new, much more efficient way of requesting zips from our system. Zip downloads complete much faster now, and you can also request as many zips as you want for any given website or backup.
Our old process for requesting zips was slightly inefficient, in that you could only request one zip at a time. You could not request another zip backup until the first zip was done being created. With new and improved logic driving this feature, you can now request as many zips as you want. So not only are our zips faster and more accessible with an improved UI, they are also much more accessible to you, and available for longer periods of time. That is quite the list of improvements!

What’s next?

In the next week or two we hope to extend this new logic to also include our Individual File Restore feature. This will include the improved UI for searching through your files and folders, and a faster back-end driving the restore once it’s started. The last few months our team has been extremely focused on improving our restore experience from every angle. Once we are done with our improvements to the Individual File Restore feature we guarantee that no matter what your restore needs are, CodeGuard will have a method that is perfect for you to get the job done.
So no matter what restore type you choose to initiate, we promise it will be intuitive, easy, and fast. Keep a look out on our blog for future updates!

CVE-2014-3704 Drupal SQL Injection Vulnerability – How can you fix it?

Twitter Facebook

This is a critical vulnerability. If this is the first you are hearing about it and you manage a Drupal website, I would highly recommend that you go read the Drupal PSA and follow the instructions there before doing anything else.



The situation with CVE-2014-3704

On October 15th, 2014 the Drupal core team released the details of a vulnerability, CVE-2014-3704, that was classified as the most severe type of vulnerability: Highly Critical. This CVE-2014-3704 SQL injection attack can allow remote, anonymous users to take control of your Drupal installation and gain access to all of your content. The Drupal team describes it in a bit more technical detail:

Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.
A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.
This vulnerability can be exploited by anonymous users.

The website firewall company, Sucuri, observed attacks on Drupal sites starting only 8 hours after the vulnerability was disclosed. Those attacks have become systematized and are now widespread. As a result, the Drupal team is advising all website owners to assume “[…] that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC […].”

What should website owners do about CVE-2014-3704?

Unfortunately, the patch that Drupal provided for CVE-2014-3704 can only prevent a future attack. If your site has already been compromised, as the Drupal team and Sucuri data suggest is very likely, the patch can not undo an attack that has already occurred. The recommendation from Drupal is to restore your website to a time before October 15th to remove the backdoor and then apply the patch to prevent re-infection.

If you have your website backed up with CodeGuard, restoring to a time before October 15th should not be an issue. If you do not have daily backups, CodeGuard or otherwise, you could also check with your hosting provider. However, while they may have a disaster recovery backup of their servers (including your website content) that was taken some time between 24 hours and 7 days ago, that would not help in a case like this where backdoors could have been inserted weeks ago. If you do not have a viable backup, the only other option that Drupal provides is to rebuild your website from scratch. Ouch. Backdoors can be incredibly difficult to find manually, so if you do not have a comprehensive backup, rebuilding is the only other truly safe option if you have been compromised by CVE-2014-3704.

Backups are a necessary part website infrastructure

Just like reliable hosting, a comprehensive backup strategy should be high on the list of priorities when building a new website or maintaining an existing property. In addition to providing some measure of insurance against events like CVE-2014-3704, they can also save you time in cases where files are accidentally deleted or when plugin updates go awry.

In addition to 99.99% levels of reliability and daily backups, CodeGuard’s ChangeAlert feature can also be helpful in bringing unauthorized file content changes to your attention. In the event that the backdoor was inserted in a file or your static content was defaced, CodeGuard can provide you with a notification of the change and the tools to roll back the malicious activity.

In this age of rapidly exploited vulnerabilities like CVE-2014-3704, a comprehensive backup strategy is no longer a nice-to-have option, it’s a must-have for every website owner or administrator.

– Jonathan

Why Do WordPress Websites Go Down?

Twitter Facebook

CodeGuard and WordPress

WordPress is a great tool for creating and managing websites. With over 60 million websites using WordPress, it is by far the most popular content management systems on the web. Not only that, WordPress is also open source which means that it is constantly being updated and improved. Why then, is it so common for WordPress websites to go down?

Unreliable Hosts

Often, the problem is not the user’s fault, but their host’s or even other people on their shared server. Failing hardware, outdated software, or mismanaged resources, can all cause server crashes. When this happens any websites on the server will go down. If you’re lucky, the server will be back up shortly, and you will have access to your website again. Sometimes, though, files and databases can become corrupt. In this case, your website might not be accessible, or it might look or behave differently. It often takes an experienced user to fix this type of problem.

WordPress Vulnerabilities

Problems can also arise within WordPress itself. Because WordPress is so easy to install, users often fail to properly secure their installation against outside attacks, and with so many on the web, WordPress installations are a popular target for hackers. The fact that all of the WordPress bugs and vulnerabilities are posted online makes it even easier for attackers to compromise a WordPress site. CVEDetails.com keeps an up-to-date list with information about many known WordPress vulnerabilities.

Once a hacker has access to your website, you might not even know that anything has changed. Many hackers create networks of compromised websites that they can use for DDOS attacks, click fraud, and adware/spyware/malware distribution.

Plugin Vulnerabilities

Plugin vulnerabilities are possibly the largest contributor to WordPress failures. In mid July, ZDNet published an article that described how vulnerabilities in just four WordPress plugins affected over 20 million WordPress installations. One of the vulnerabilities even allowed “attackers to upload malicious PHP files or backdoors to the target server without needing admin privileges.” Just like WordPress, many plugin bugs and vulnerabilities are published online for everyone to see. On one hand, the fact that everyone has access to this information is good, because it prompts developers to fix the problems, if they haven’t already, and it gives users a heads up that their website may be susceptible. Unfortunately, though, this information also makes it easier for hackers to find and exploit vulnerable plugins.

Besides being vulnerable, WordPress plugins are often buggy, bloated, or poorly maintained. In addition, multiple plugins can conflict with each other. Plugin incompatibility is one of the reasons why we at CodeGuard discontinued support for our WordPress plugin in favor of a more reliable and platform-agnostic website backup strategy.

What can you do?

There are several things you can do to make sure your WordPress website stays up and running.

  1. Choose a reputable host
    If you want your website to available 24/7 make sure you choose a reliable hosting provider. Do a little bit of research beforehand to see if other users have had problems with the host you have in mind.
  2. Secure your WordPress installation
    WordPress has published an excellent guide to help you harden your WordPress installation against outside attacks.
  3. Keep your plugins up-to-date
    Old plugins with known vulnerabilities are easy targets for hackers. Keeping your plugins up-to-date will help ensure that they are bug-free and harder to attack. Limiting the number of plugins you have is also a good idea, because it reduces the number of attack vectors that hackers can potentially exploit.
  4. Have a backup
    If all else fails, it’s important to have a plan for recovery. CodeGuard provides easy backups for your WordPress installation, and we have specific WordPress features that make restoring your site even easier.

– Taylor