Posts Tagged 'Security'

November 2, 2012

The Trouble with Open DNS Resolvers

In the last couple of days, there's been a bit of buzz about "open DNS resolvers" and DNS amplification DDoS attacks, and SoftLayer's name has been brought up a few times. In a blog post on October 30, CloudFlare explained DNS Amplification DDoS attacks and reported the geographic and network sources of open DNS resolvers that were contributing to a 20Gbps attack on their network. SoftLayer's AS numbers (SOFTLAYER and the legacy THEPLANET-AS number) show up on the top ten "worst offenders" list, and Dan Goodin contacted us to get a comment for a follow-up piece on Ars Technica — Meet the network operators helping to fuel the spike in big DDoS attacks.

While the content of that article is less sensationalized than the title, there are still a few gaps to fill about when it comes to how SoftLayer is actually involved in the big picture (*SPOILER ALERT* We aren't "helping to fuel the spike in big DDoS attacks"). The CloudFlare blog and the Ars Technica post presuppose that the presence of open recursive DNS resolvers is a sign of negligence on the part of the network provider at best and maliciousness at worst, and that's not the case.

The majority of SoftLayer's infrastructure is made up of self-managed dedicated and cloud servers. Customers who rent those servers on a monthly basis have unrestricted access to operate their servers in any way they'd like as long as that activity meets our acceptable use policy. Some of our largest customers are hosting resellers who provide that control to their customers who can then provide that control to their own customers. And if 23 million hostnames reside on the SoftLayer network, you can bet that we've got a lot of users hosting their DNS on SoftLayer infrastructure. Unfortunately, it's easier for those customers and customers-of-customers and customers-of-customers-of-customers to use "defaults" instead of looking for, learning and implementing "best practices."

It's all too common to find those DNS resolvers open and ultimately vulnerable to DNS amplification attacks, and whenever our team is alerted to that vulnerability on our network, we make our customers aware of it. In turn, they may pass the word down the customer-of-customer chain to get to the DNS owner. It's usually not a philosophical question about whether DNS resolvers should be open for the greater good of the Internet ... It's a question of whether the DNS owner has any idea that their "configuration" is vulnerable to be abused in this way.

SoftLayer's network operations, abuse and support teams have tools that flag irregular and potentially abusive traffic coming from any server on our network, and we take immediate action when we find a problem or are alerted to one by someone who sends details to abuse@softlayer.com. The challenge we run into is that flagging obvious abusive behavior from an active DNS server is a bit of a cat-and-mouse game ... Attackers cloak their activity in normal traffic. Instead of sending a huge amount of traffic from a single domain, they send a marginal amount of traffic from a large number of machines, and the "abusive" traffic is nearly impossible for even the DNS owner to differentiate from "regular" traffic.

CloudFlare effectively became a honeypot, and they caught a distributed DNS amplification DoS attack. The results they gathered are extremely valuable to teams like mine at SoftLayer, so if they go the next step to actively contact the abuse channel for each of the network providers in their list, I hope that each of the other providers will jump on that information as I know my team will.

If you have a DNS server on the SoftLayer network, and you're not sure whether it's configured to prevent it from being used for these types of attacks, our support team is happy to help you out. For those of you interested in doing a little DNS homework to learn more, Google's Developer Network has an awesome overview of DNS security threats and mitigations which gives an overview of potential attacks and preventative measures you can take. If you're just looking for an easy way to close an open recursor, scroll to the bottom of CloudFlare's post, and follow their quick guide.

If, on the other hand, you have your own DNS server and you don't want to worry about all of this configuration or administration, SoftLayer operates private DNS resolvers that are limited to our announced IP space. Feel free to use ours instead!

-Ryan

October 23, 2012

Tips from the Abuse Department: Know Spam. Stop Spam.

As an abuse administrator, I'm surrounded by spam on a daily basis. When someone sends an abuse-related complaint to our abuse@softlayer.com contact address, it gets added to our ticket queue, and our Abuse SLayers take time to investigate and follow up with the customers whose servers violate our acceptable use policy. The majority of those abuse-related submissions are reporting spam coming from our network, and in my interaction with customers, I've noticed that spam (and the source of spam) is widely misunderstood.

Most spam tickets we create on customer accounts pinpoint spam sent from a compromised or exploited server. Our direct customer didn't send the phishing email, malware distribution, pharmacy advertisement or pornographic spam, but that activity came from their account. While they're accountable for the abusive behavior coming from their server, in many cases, they don't know that there's a problem until we post an abuse ticket on their account. These servers are targeted and compromised by common techniques and exploits that could have been easily avoided, but they aren't very well known outside the world of abuse.

To protect yourself from a spammer, you need to think like a spammer. You need to understand how someone might try to exploit your environment so that you can prevent them from doing so. As you're looking at ways to secure your server proactively, make sure you target these five exploits in particular:

1. User Auth Login

This is by far the most common exploit to used to send spam. This method involves a person or script using the credentials of a user to send spam through a domain's mail server. The majority of these incidences are caused by malware on a client PC that obtains the login and password for a domain user and uses that information to log on and send mail from the client PC through the server. Often, these spam messages are sent through a botnet command structure.

When an account is compromised, simply changing the password for the compromised user on the server usually won't stop the abuse. We see quite a few accounts that continue to send spam after an initial abuse ticket results in a password change. Most servers that are sending spam with this method are found to only be sending a small amount of spam at any given time to avoid detection. The low volume of spam that is being sent per server is made up for by the fact that there are thousands of servers being used for the same spamming campaigns.

In order to stop the User Auth Login exploit, a customer needs to clean all of the malicious software (malware) from their environments. To prevent future User Auth Login compromises, users should be made aware of the potential dangers of untrusted software, and if they believe their machines are infected, they need to know what to do.

2. Tell-a-friend Exploitation

The User Auth Login technique is the most common method employed by spammers, but the "tell-a-friend" script exploitation isn't far behind when it comes to volume of affected servers. This spamming method find websites that use scripts to invite users to refer friends to a page or product. Spammers will use the 'Your Message' field in one of these scripts to input their own content and links, and they'll push the actual page referral link to the bottom of the message. When these site scripts aren't secure, the spammer will use them to send hundreds or thousands of messages.

To avoid having your website fall victim to this type of spam, be very wary of any widget or script you add. If you need to add Facebook, Twitter and email "share" functionality to your site, make sure you incorporate a tell-a-friend script that does not allow for customizable messages or does not accept input of more than one email address. Also, users won't need the "cc" or "bcc" fields, so you can be sure those are axed as well. If you can't find a good "share" script that you're comfortable with from a security perspective, it might be a good idea to remove that functionality to avoid exploitation.

3. Uploaded Mailers

Spam sent via an uploaded third party mailer can sometimes prove difficult for admins to locate. An uploaded third party mailer could be capable of creating it's own outbound SMTP connection, and that would allow a program to bypass the existing MTA on the server and render any legitimate mail logs useless for investigation. Another challenge is that a php mailer can be uploaded to a location within a user's web content, and that mailer is run by the user 'nobody' (the default Apache user).

We strongly suggest configuring your server to have the mail headers show the script's user (that's not the Apache default user) and the location the script is running from on the server. Many times, these kinds of mailers are maliciously uploaded after a user's FTP password is been compromised, so be sure your FTP login information is secure.

4. Software Exploits

The "software exploits" category casts a huge shadow. Every piece of software on a server — from mail servers, content management systems and control panels to the operating system itself — can be targeted by hackers. They probe servers to find security vulnerabilities and weak coding, and when they find a vulnerability, they take control.

The hacker who found the software vulnerability might not actually take advantage of the exploit immediately. That user may sell access to other entities for their use, and that use often ends up being spam. In addition to having strong firewall rules and access restrictions, you should update and maintain the current stable versions of all software on your servers.

5. WordPress Exploits

WordPress exploits would technically fall under the "Software Exploits" category, but I'm breaking it out into its own category simply due to the volume of spam issues that are the result of exploiting this particular piece of software. The first step to protecting against spam being sent through this source is to make sure you have the latest version of WordPress installed. With that done, be sure to research the latest security plugins for that version and install any that are applicable to your environment.

These five techniques are not the only ones used by spammers to take advantage of your environment, but they are some of the most common. To protect yourself from becoming a source of spam, make your servers a more difficult target to exploit. To stop spam, you need to know spam. Now that you know spam, it's time to stop it. Ask questions, test your environment regularly and watch your logs for any unexplained usage.

-Andrew

October 16, 2012

An Introduction to Risk Management

Whether you're managing a SaaS solution for thousands of large clients around the world or you're running a small mail server for a few mom-and-pop businesses in your neighborhood, you're providing IT service for a fee — and your customers expect you to deliver. It's easy to get caught up in focusing your attention and energy on day-to-day operations, and in doing so, you might neglect some of the looming risks that threaten the continuity of your business. You need to prioritize risk assessment and management.

Just reading that you need to invest in "Risk Management" probably makes you shudder. Admittedly, when a business owner has to start quantifying and qualifying potential areas of business risk, the process can seem daunting and full of questions ... "What kinds of risks should I be concerned with?" "Once I find a potential risk, should I mitigate it? Avoid it? Accept it?" "How much do I need to spend on risk management?"

When it comes to risk management in hosting, the biggest topics are information security, backups and disaster recovery. While those general topics are common, each business's needs will differ greatly in each area. Because risk management isn't a very "cookie-cutter" process, it's intimidating. It's important to understand that protecting your business from risks isn't a destination ... it's a journey, and whatever you do, you'll be better off than you were before you did it.

Because there's not a "100% Complete" moment in the process of risk management, some people think it's futile — a gross waste of time and resources. History would suggest that risk management can save companies millions of dollars, and that's just when you look at failures. You don't see headlines when businesses effectively protect themselves from attempted hacks or when sites automatically fail over to a new server after a hardware failure.

It's unfortunate how often confidential customer data is unintentionally released by employees or breached by malicious attackers. Especially because those instances are often so easily preventable. When you understand the potential risks of your business's confidential data in the hands of the wrong people (whether malicious attackers or careless employees), you'll usually take action to avoid quantifiable losses like monetary fines and unquantifiable ones like the loss of your reputation.

More and more, regulations are being put in place to holding companies accountable for protecting their sensitive information. In the healthcare industry businesses have to meet the strict Health Insurance Portability and Accountability Act (HIPAA) regulations. Sites that accept credit card payments online are required to operate in Payment Card Industry (PCI) Compliance. Data centers will spend hours (and hours and hours) achieving and maintaining their SSAE 16 certification. These rules and requirements are not arbitrarily designed to be restrictive (though they can feel that way sometimes) ... They are based on best practices to ultimately protect businesses in those industries from risks that are common throughout the respective industry.

Over the coming months, I'll discuss ways that you as a SoftLayer customer can mitigate and manage your risk. We'll talk about security and backup plans that will incrementally protect your business and your customers. While we won't get to the destination of 100% risk-mitigated operations, we'll get you walking down the path of continuous risk assessment, identification and mitigation.

Stay tuned!

-Matthew

October 5, 2012

Spark::red: Tech Partner Spotlight

This guest blog comes to us from Spark::red, a featured member of the SoftLayer Technology Partners Marketplace. Spark::red is a global PCI Level 1 compliant hosting provider specializing in Oracle ATG Commerce. With full-redundancy at every layer, powerful servers, and knowledgeable architects, Spark::red delivers exceptional environments in weeks, instead of months. In this video we talk to Spark::red co-founder Devon Hillard about what Spark::red does, how they help companies that are outgrowing current solutions, and why they chose SoftLayer.

The Three Most Common PCI Compliance Myths

As a hosting provider that specializes in Oracle ATG Commerce, Spark::red has extensive experience and expertise when it comes to the Payment Card Industry Data Security Standards (PCI DSS). If you're not familiar with PCI DSS, they are standards imposed on companies that process payment data, and they are designed to protect the company and its customers.

We've been helping online businesses maintain PCI Compliance for several years now, and in that time, we've encountered a great deal of confusion and misinformation when it comes to compliance. Despite numerous documents and articles available on this topic, we've found that three myths seem to persist when it comes to PCI DSS compliance. Consider us the PCI DSS compliance mythbusters.

Myth 1: Only large enterprise-level businesses are required to be PCI Compliant.

According to PCI DSS, every company involved in payment card processing online or offline should be PCI Compliant. The list of those companies includes e-commerce businesses of all sizes, banks and web hosting providers. It's important to note that I said, "should be PCI Compliant" here. There is no federal law that makes PCI compliance a legal requirement. However, a business IS required to be PCI compliant technically in order to take and process Visa or MasterCard payments. Failure to operate in with PCI compliance could mean huge fees if you're found in violation after a breach.

Payment card data security is the most significant concern for cardholders, and it should be a priority for your business, whether you have two hundred customers or two million customers. If you're processing ANY credit card payments, you should make sure you are PCI-compliant.

There are four levels of PCI compliance based on the number of credit card transactions your business processes a year, so the PCI compliance process is going to look different for small, medium-sized and large businesses. Visit the PCI Security Standards Council website to check which level of PCI compliance your business needs.

Myth 1: Busted.

Myth 2: A business that uses a PCI-compliant managed hosting provider automatically becomes PCI-compliant.

Multiple parties are involved in processing payment data, and each of them needs to meet certain standards to guarantee cardholders' data security. From a managed hosting provider perspective, we're responsible for things like proper firewall installation and maintenance, updating anti-virus programs of our servers, providing a unique ID for each person with computer access to restrict access to the most sensitive data, regular system scanning for vulnerabilities. Our customer — an online retailer, for example — would need to develop its software applications in accordance with PCI DSS, keep cardholders data storage to a minimum, and perform application-layer penetration tests that are out of their hosting provider's control.

If you're pursuing PCI compliance, you have a significant advantage if you start with a PCI-compliant managed hosting provider. Many security questions are already answered by your PCI-compliant host, so there is a shorter list of things for you to be worry about. You save money, time and effort in the process of completing PCI certification.

Myth 2: Busted.

Myth 3: A business that uses SSL certificates is PCI compliant.

Secure Sockets Layer (SSL) certificates allow secure data transmission to and from the server through data encryption that significantly decreases the network vulnerabilities from IP spoofing, IP source rooting, DNS spoofing, man-in-the-middle attacks and other threats from hackers. However, SSL cannot protect cardholder data from attacks using cross-site scripting or SQL injection, and they don't provide secure audit trails or event monitoring. SSL certificates are an important part of secure transactions, but they're only part of PCI DSS compliance.

Myth 3: Busted.

If you have questions about PCI compliance or you're interested in Oracle ATG Hosting, visit Spark::red, give us a call or send us an email, and we'll do what we can to help. When PCI compliance doesn't seem like a scary monster in your closet, it's easier to start the process and get it done quickly.

-Elena Rybalchenko, Spark::red

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
September 10, 2012

Creating a Usable, Memorable and Secure Password

When I was young, I vividly remember a wise man sharing a proverb with me: "Locks are for honest people." The memory is so vivid because it completely confused me ... "If everyone was honest, there would be no need for locks," I thought, naively. As it turns out, everyone isn't honest, and if "locks keep honest people honest," they don't do anything to/for dishonest people. That paradox lingered in the back of my mind, and a few years later, I found myself using some sideways logic to justify learning the mechanics of lock picking.

I ordered my first set of lock picks (with instruction booklet) for around $10 online. When the package arrived, I scrambled to unwrap it like Ralphie unwrapped the "Red Ryder" BB gun in "A Christmas Story," and I set out to find my first lock to pick. After a few unsuccessful attempts, I turned to the previously discarded instruction booklet, and I sat down to actually learn what I was supposed to be doing. That bit of study wound up being useful; with that knowledge, I managed to pick my first lock.

I tend to collect hobbies. I also tend to shift every spare thought towards my newest obsession until whatever goal I set is accomplished. To this end, I put together a mobile lock-picking training device — the cylinder/tumbler from a dead bolt, my torq wrench wrapped with electrical tape to prevent the recurrence of blisters, and my favorite snake rake. I took this device with me everywhere, unconsciously unlocking and resetting the lock as I went about my shopping, sat in a doctor's office or walked around the block. In my mind, I was honing my skills on a mechanical challenge, but as one of my friends let me know, people who saw me playing with the lock in public would stare at me like I was a budding burglar audaciously flaunting his trade.

I spent less money on a lock picking set than I would have on a lock, and I felt like had a key to open any door. The only thing between me and the other side of a locked door in front of me was my honesty. What about the dishonest people in the world, though? They have the same access to cheap tools, and while they probably don't practice their burgling in public, can spend just as much time sharpening their skills in private. From then on, I was much more aware of the kinds of locks I bought and used to secure my valuables.

When I started getting involved in technology, I immediately noticed the similarities between physical security and digital security. When I was growing up, NBC public service announcements taught me, "Knowledge is Power," and that's even truer now than it was then. We trust technology with our information, and if someone else gets access to that information, the results can be catastrophic.

Online, the most common "hacks" and security exploits are usually easily avoidable. They're the IRL equivalent of leaving valuables on a table by an unlocked window with the thought, "The window is closed ... My stuff is secure." Some of those windows may be hard to reach, but some of them are street-level in high-traffic pedestrian areas. The most vulnerable and visible of access points: Passwords.

You've heard people tell you not to do silly things like making "1 2 3 4 5" your combination lock, and your IT team has probably gotten onto you about using "password" to log onto your company's domain, but our tendency to create simpler passwords is a response to the inherent problem that a secure password is, by its nature, hard to remember. The average Internet user probably isn't going to use pwgen or a password lockbox ... If you had a list of passwords from a given site, my guess is that you'd wind up seeing a lot more pets' names and birth years than passwords like S0L@Y#Rpr!Vcl0udN)3mblyR#Q. What people need to understand is that the "secure" password can be just as easy to remember as "Fluffy1982."

Making a *Usable* Secure Password

The process of creating a unique, usable and secure password is pretty straightforward:

  1. Start with a series of words or phrases which have a meaning to you: A quote in a movie, song lyric, title of your favorite book series, etc. For our example, let's use "SoftLayer Private Clouds, no assembly required."
  2. l33t up your phrase. To do this, you'd remove punctuation and spaces, and you'd replace a letter in the phrase with a special character. You predetermining these conversions to create a template of alterations to any string which only take minimal thought from you. In the simplest of cyphers, letters become a numbers or characters that resemble the letter: An "o" becomes a "0," "e" becomes a "3," an "a" becomes an "@," etc. In more complicated structures, a character can be different based on where it lies in the string or what less-commmon substitutions you choose to use. Our example at this point would look like this: "S0ftL@y3rPr1v@t3Cl0udsn0@ss3mblyr3qu1r3d"
  3. Right now, we have a password that would make any brute-forcing script-kiddie yearn for the Schwarts, but we're not done yet. If someone were to find our cypher and personal phrase, they may be able to figure out our password. Also, this password is too long for use in many sites with password restrictions that cap you a 16 characters. Our goal is to create a password between 15-25 characters and be prepared to make cuts when necessary.
  4. A good practice is to cut out the beginning or ending of a word. In our example (taking out the l33t substitutions for simplicity here), our phrase might look like this: "so-layer-priv-cloud-no-embly-req"
  5. When we combine the shortened password with l33t substitutions, the last trick we want to incorporate is using our Shift key. An "e" might be a "3" in a simple l33t cypher, but if we use the Shift key, the "e" becomes a "#" (Shift+"3"): "S0L@Y#Rpr!Vcl0udN)#mblyR#Q"

The main idea is that when you're "locking" your accounts with a password, you don't need the most complicated lock ever created ... You just need one that can't be picked easily. Establish a pattern of uncommon substitutions that you can use consistently across all of your sites, and you'll be able to use seemingly common phrases like "Fluffy is my dog's name" or "Neil Armstrong was an astronaut" without worrying about anyone being able to "open your window."

-Phil (@SoftLayerDevs)

July 27, 2012

SoftLayer 'Cribs' ≡ DAL05 Data Center Tour

The highlight of any customer visit to a SoftLayer office is always the data center tour. The infrastructure in our data centers is the hardware platform on which many of our customers build and run their entire businesses, so it's not surprising that they'd want a first-hand look at what's happening inside the DC. Without exception, visitors to a SoftLayer data center pod are impressed when they walk out of a SoftLayer data center pod ... even if they've been in dozens of similar facilities in the past.

What about the customers who aren't able to visit us, though? We can post pictures, share stats, describe our architecture and show you diagrams of our facilities, but those mediums can't replace the experience of an actual data center tour. In the interest of bridging the "data center tour" gap for customers who might not be able to visit SoftLayer in person (or who want to show off their infrastructure), we decided to record a video data center tour.

If you've seen "professional" video data center tours in the past, you're probably positioning a pillow on top of your keyboard right now to protect your face if you fall asleep from boredom when you hear another baritone narrator voiceover and see CAD mock-ups of another "enterprise class" facility. Don't worry ... That's not how we roll:

Josh Daley — whose role as site manager of DAL05 made him the ideal tour guide — did a fantastic job, and I'm looking forward to feedback from our customers about whether this data center tour style is helpful and/or entertaining.

If you want to see more videos like this one, "Like" it, leave comments with ideas and questions, and share it wherever you share things (Facebook, Twitter, your refrigerator, etc.).

-@khazard

July 25, 2012

ServerDensity: Tech Partner Spotlight

We invite each of our featured SoftLayer Tech Marketplace Partners to contribute a guest post to the SoftLayer Blog, and this week, we're happy to welcome David Mytton, Founder of ServerDensity. Server Density is a hosted server and website monitoring service that alerts you when your website is slow, down or back up.

5 Ways to Minimize Downtime During Summer Vacation

It's a fact of life that everything runs smoothly until you're out of contact, away from the Internet or on holiday. However, you can't be available 24/7 on the chance that something breaks; instead, there are several things you can do to ensure that when things go wrong, the problem can be managed and resolved quickly. To help you set up your own "get back up" plan, we've come up with a checklist of the top five things you can do to prepare for an ill-timed issue.

1. Monitoring

How will you know when things break? Using a tool like Server Density — which combines availability monitoring from locations around the world with internal server metrics like disk usage, Apache and MySQL — means that you can be alerted if your site goes down, and have the data to find out why.

Surprisingly, the most common problems we see are some that are the easiest to fix. One problem that happens all too often is when a customer simply runs out of disk space in a volume! If you've ever had it happen to you, you know that running out of space will break things in strange ways — whether it prevents the database from accepting writes or fails to store web sessions on disk. By doing something as simple as setting an alert to monitor used disk space for all important volumes (not just root) at around 75%, you'll have proactive visibility into your server to avoid hitting volume capacity.

Additionally, you should define triggers for unusual values that will set off a red flag for you. For example, if your Apache requests per second suddenly drop significantly, that change could indicate a problem somewhere else in your infrastructure, and if you're not monitoring those indirect triggers, you may not learn about those other problems as quickly as you'd like. Find measurable direct and indirect relationships that can give you this kind of early warning, and find a way to measure them and alert yourself when something changes.

2. Dealing with Alerts

It's no good having alerts sent to someone who isn't responding (or who can't at a given time). Using a service like Pagerduty allows you to define on-call rotations for different types of alerts. Nobody wants to be on-call every hour of every day, so differentiating and channeling alerts in an automated way could save you a lot of hassle. Another huge benefit of a platform like Pagerduty is that it also handles escalations: If the first contact in the path doesn't wake up or is out of service, someone else gets notified quickly.

3. Tracking Incidents

Whether you're the only person responsible or you have a team of engineers, you'll want to track the status of alerts/issues, particularly if they require escalation to different vendors. If an incident lasts a long time, you'll want to be able to hand it off to another person in your organization with all of the information they need. By tracking incidents with detailed notes information, you can avoid fatigue and prevent unnecessary repetition of troubleshooting steps.

We use JIRA for this because it allows you to define workflows an issue can progress along as you work on it. It also includes easy access to custom fields (e.g. specifying a vendor ticket ID) and can be assigned to different people.

4. Understanding What Happened

After you have received an alert, acknowledged it and started tracking the incident, it's time to start investigating. Often, this involves looking at logs, and if you only have one or two servers, it's relatively easy, but as soon as you add more, the process can get exponentially more difficult.

We recommend piping them all into a log search tool like (fellow Tech Partners Marketplace participant) Papertrail or Loggly. Those platforms afford you access to all of your logs from a single interface with the ability to see incoming lines in real-time or the functionality to search back to when the incident began (since you've clearly monitored and tracked all of that information in the first three steps).

5. Getting Access to Your Servers

If you're traveling internationally, access to the Internet via a free hotspot like the ones you find in Starbucks isn't always possible. It's always a great idea to order a portable 3G hotspot in advance of a trip. You can usually pick one up from the airport to get basic Internet access without paying ridiculous roaming charges. Once you have your connection, the next step is to make sure you can access your servers.

Both iPhone and Android have SSH and remote desktop apps available which allow you to quickly log into your servers to fix easy problems. Having those tools often saves a lot of time if you don't have access to your laptop, but they also introduce a security concern: If you open server logins to the world so you can login from the dynamic IPs that change when you use mobile connectivity, then it's worth considering a multi-factor authentication layer. We use Duo Security for several reasons, with one major differentiator being the modules they have available for all major server operating systems to lock down our logins even further.

You're never going to escape the reality of system administration: If your server has a problem, you need to fix it. What you can get away from is the uncertainty of not having a clearly defined process for responding to issues when they arise.

-David Mytton, ServerDensity

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
April 18, 2012

Dome9: Tech Partner Spotlight

This guest blog comes to us from Dave Meizlik, Dome9 VP of marketing and business development. Dome9 is a featured member of the SoftLayer Technology Partners Marketplace. With Dome9, you get secure, on-demand access to all your servers by automating and centralizing firewall management and making your servers virtually invisible to hackers.

Three Tips to Securing Your Cloud Servers

By now everyone knows that security is the number one concern among cloud adopters. But lesser known is why and what to do to mitigate some of the security risks ... I hope to shed a little light on those points in this blog post, so let's get to it.

One of the greatest threats to cloud servers is unsecured access. Administrators leave ports (like RDP and SSH) open so they can connect to and manage their machines ... After all, they can't just walk down the hall to gain access to them like with an on-premise network. The trouble with this practice is that it leaves these and other service ports open to attack from hackers who need only guess the credentials or exploit a vulnerability in the application or OS. Many admins don't think about this because for years they've had a hardened perimeter around their data center. In the cloud, however, the perimeter collapses down to each individual server, and so too must your security.

Tip #1: Close Service Ports by Default

Instead of leaving ports — from SSH to phpMyAdmin — open and vulnerable to attack, close them by default and open them only when, for whom, and as long as is needed. You can do this manually — just be careful not to lock yourself out of your server — or you can automate the process with Dome9 for free.

Dome9 provides a patent-pending technology called Secure Access Leasing, which enables you to open a port on your server with just one click from within Dome9 Central, our SaaS management console, or as an extension in your browser. With just one click, you get time-based secure access and the ability to empower a third party (e.g., a developer) with access easily and securely.

When your service ports are closed by default, your server is virtually invisible to hackers because the server will not respond to an attacker's port scans or exploits.

Tip #2: Make Your Security as Elastic as Your Cloud

Another key security challenge to cloud security is management. In a traditional enterprise you have a semi-defined perimeter with a firewall and a strong, front-line defense. In the cloud, however, that perimeter collapses down to the individual server and is therefore multiplied by the number of servers you have in your environment. Thus, the number of perimeters and policies you have to manage increases exponentially, adding complexity and cost. Remember, if you can't manage it, you can't secure it.

As you re-architect your infrastructure, take the opportunity to re-architect your security, keeping in mind that you need to be able to scale instantaneously without adding management overhead. To do so, create group-based policies for similar types of services, with role-based controls for users that need access to your cloud servers.

With Dome9, for example, you can create an unlimited number of security groups — umbrella policies applied to one or more servers and for which you can create user-based self-service access. So, for example, you can set one policy for your web servers and another for your SQL database servers, then you can enable your web developers to self-grant access to the web servers while the DBAs have access to the database servers. Neither, however, may be able to access the others' servers, but you — the super admin — can. Any new servers you add on-the-fly as you scale up your infrastructure are automatically paired with your Dome9 account and attached to the relevant security group, so your security is truly elastic.

Tip #3: Make Security Your Responsibility

The last key security challenge is understanding who's responsible for securing your cloud. It's here that there's a lot of debate and folks get confused. According to a recent Ponemon Institute study, IT pros point fingers equally at the cloud provider and cloud user.

When everyone is responsible, no one is responsible. It's best to pick up the reigns and be your best champion. Great cloud and hosted providers like SoftLayer are going to provide an abundance of controls — some their own, and some from great security providers such as Dome9 (shameless, I know) — but how you them is up to you.

I liken this to a car: Whoever made your car built it with safety in mind, adding seat belts and air bags and lots of other safeguards to protect you. But if you go speeding down the freeway at 140 MPH without a seatbelt on, you're asking for trouble. When you apply this concept to the cloud, I think it helps us better define where to draw the lines.

At the end of the day, consider all your options and how you can use the tools available to most effectively secure your cloud servers. It's going to be different for just about everyone, since your needs and use cases are all different. But tools like Dome9 let you self-manage your security at the host layer and allow you to apply security controls for how you use a cloud platform (i.e., helping you be a safe driver).

Security is a huge topic, and I didn't even scratch the surface here, but I hope you've learned a few things about how to secure your cloud servers. If the prospect of scaling out security policies across your infrastructure isn't particularly appealing, I invite you to try out Dome9 (for free) to see how easily you can manage automated cloud security on your SoftLayer server. It's quick, easy, and (it's worth repeating a few times...) free:

  1. Create a Dome9 account at https://secure.dome9.com/Account/Register?code=SoftLayer
  2. Add the Dome9 agent to your SoftLayer server
  3. Configure your policy in Dome9 Central, our SaaS management console

SoftLayer customers that sign up for Dome9 enjoy all the capabilities of Dome9 free for 30 days. After that trial period, you can opt to use either our free Lite Cloud, which provides security for an unlimited number of servers, or our Business Cloud for automated cloud security.

-Dave Meizlik, Dome9

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
April 4, 2012

Sharing a Heavy Load - New Load Balancer Options

I always think of Ford, Chevy and Toyota pick-up truck commercials when I think of load balancers. The selling points for trucks invariably boil down to performance, towing capacity and torque, and I've noticed that users evaluating IT network load balancers have a similar simplified focus.

The focus is always about high performance, scalability, failover protection and network optimization. When it comes to "performance," users are looking for reliable load balancing techniques — whether it be round robin, least connections, shortest response or persistent IP. Take one of the truck commericals and replace "towing capacity" with "connections per second" and "torque" with "application acceleration" or "SSL offloading," and you've got yourself one heck of a load balancer sales pitch.

SoftLayer's goal has always been to offer a variety of local and global load balancing options, and today, I get to announce that we're broadening that portfolio.

So what's new?

We've added the capability of SSL offloading to our shared load balancers and launched a dedicated load balancer option as well. These new additions to the product portfolio continue our efforts to make life easier on our customers as they build their own fully operational virtual data center.

What's so great about SSL offloading? It accelerates the processing of SSL encrypted websites and makes it easier to manage SSL certificates. Think of this as adding more torque to your environment, speeding up how quickly certs can be decrypted (coming in) and encrypted (heading out).

Up until now, SoftLayer has offered SSL at the server level. This requires multiple SSL certifications for each server or special certs that can be used on multiple servers. With SSL offloading, incoming traffic is decrypted at the load balancer, rather than at the server level, and the load balancer also encrypts outbound traffic. This means traffic is processed in one place — at the load balancer — rather than at multiple server locations sitting behind the load balancer.

With SoftLayer SSL offloading on shared load balancers, customers can start small with few connections and grow on the fly by adding more connections or moving to a dedicated load balancer. This makes it a breeze to deploy, manage, upgrade and scale.

What do the new load balance offerings look like in the product catalog? Here's a breakdown:

Shared Load Balancing
250 Connections with SSL $99.99
500 Connections with SSL $199.99
1000 Connections with SSL $399.99
Dedicated Load Balancer
Standard with SSL $999.00

I'm not sure if load balancing conjures up the same images for you of hauling freight or working on a construction site, but however you think about them, load balancers play an integral part in optimizing IT workloads and network performance ... They're doing the heavy lifting to help get the job done. If you're looking for a dedicated or shared load balancer solution, you know who to call.

-Matt

March 27, 2012

Tips and Tricks - How to Secure WordPress

As a hobby, I dabble in WordPress, so I thought I'd share a few security features I use to secure my WordPress blogs as soon as they're installed. Nothing in this blog will be earth-shattering, but because security is such a priority, I have no doubt that it will be useful to many of our customers. Often, the answer to the question, "How much security do I need on my site?" is simply, "More," so even if you have a solid foundation of security, you might learn a new trick or two that you can incorporate into your next (or current) WordPress site.

Move wp-config.php

The first thing I do is change the location of my wp-config.php. By default, it's installed in the WordPress parent directory. If the config file is in the parent directory, it can be viewed and accessed by Apache, so I move it out of web/root. Because you're changing the default location of a pretty significant file, you need to tell WordPress how to find it in wp-load.php. Let's say my WordPress runs out of /webroot on my host ... I'd need to make a change around Line 26:

if ( file_exists( ABSPATH . 'wp-config.php') ) {
 
        /** The config file resides in ABSPATH */
        require_once( ABSPATH . 'wp-config.php' );
 
} elseif ( file_exists( dirname(ABSPATH) . '/wp-config.php' ) && ! file_exists( dirname(ABSPATH) . '/wp-settings.php' ) ) {
 
        /** The config file resides one level above ABSPATH but is not part of another install*/
        require_once( dirname(ABSPATH) . '/wp-config.php' );

The code above is the default setup, and the code below is the version with my subtle update incorporated.

if ( file_exists( ABSPATH . 'wp-config.php') ) {
 
        /** The config file resides in ABSPATH */
        require_once( ABSPATH . '../wp-config.php' );
 
} elseif ( file_exists( dirname(ABSPATH) . '..//wp-config.php' ) && ! file_exists( dirname(ABSPATH) . '/wp-settings.php' ) ) {
 
        /** The config file resides one level above ABSPATH but is not part of another install*/
        require_once( dirname(ABSPATH) . '../wp-config.php' );

All we're doing is telling the application that the wp-config.php file is one directory higher. By making this simple change, you ensure that only the application can see your wp-config.php script.

Turn Down Access to /wp-admin

After I make that change, I want to turn down access to /wp-admin. I allow users to contribute on some of my blogs, but I don't want them to do so from /wp-admin; only users with admin rights should be able to access that panel. To limit access to /wp-admin, I recommend the plugin uCan Post. This plugin creates a page that allows users to write posts and submit them within your theme.

But won't a user just be able to navigate to http://site.com/wp-admin? Yes ... Until we add a simple function to our theme's functions.php file to limit that access. At the bottom of your functions.php file, add this:

############ Disable admin access for users ############

add_action('admin_init', 'no_more_dashboard');
function no_more_dashboard() {
  if (!current_user_can('manage_options') && $_SERVER['DOING_AJAX'] != '/wp-admin/admin-ajax.php') {
  wp_redirect(site_url()); exit;
  }
}
 
###########################################################

Log in as a non-admin user, and you'll get redirected to the blog's home page if you try to access the admin panel. Voila!

Start Securing the WordPress Database

Before you go any further, you need to look at WordPress database security. This is the most important piece in my opinion, and it's not just because I'm a DBA. WordPress never needs all permissions. The only permissions WordPress needs to function are ALTER, CREATE, CREATE TEMPORARY TABLES, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT and UPDATE.

If you run WordPress and MySQL on the same server the permissions grant would look something like:

GRANT ALTER, CREATE, CREATE TEMPORARY TABLES, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, UPDATE ON <DATABASE>.* TO <USER>@'localhost' IDENTIFIED BY '<PASSWORD>';

If you have a separate database server, make sure the host of the webserver is allowed to connect to the database server:

GRANT ALTER, CREATE, CREATE TEMPORARY TABLES, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, UPDATE ON <DATABASE>.* TO <USER>@'<ip of web server' IDENTIFIED BY '<PASSWORD>';

The password you use should be random, and you should not need to change this. DO NOT USE THE SAME PASSWORD AS YOUR ADMIN ACCOUNT.

By taking those quick steps, we're able to go a long way to securing a default WordPress installation. There are other plugins out there that are great tools to enhance your blog's security, and once you've got the fundamental security updates in place, you might want to check some of them out. Login LockDown is designed to stop brute force login attempts, and Secure WordPress has some great additional features.

What else do you do to secure your WordPress sites?

-Lee

Subscribe to security