Posts Tagged 'Security'

December 10, 2014

Password Managers: One Password To Rule Them All

From banking to social media to gaming, the amount of accounts we have today is growing out of control. Let’s be honest—it’s easy to use the same password or a variation of the same password for all online accounts, but if a hacker can break one of those passwords, they are one step closer to hacking every account.

Who really has the memory to store all those passwords anyway?

That’s where a password manager can help. It controls access by storing (online or locally) every password in an encrypted file that is only accessible by one strong master password.

When a user wants access to their SoftLayer account for example, the password manager will ask for the master password instead of the SoftLayer account password. It automatically populates the username and password fields and logs in.

Password managers are very convenient, but more importantly they enhance security because of the ability to use longer and harder passwords without worrying about forgetting or writing them down on sticky notes posted to a desktop screen.

Do I need a cross-platform password manager?
Today, most people access the same accounts on desktops, tablets, and mobile devices. If that’s you, then yes, you need a cross-platform solution. These Web-based options require yearly subscriptions upwards of $50 for a single user. The convenience of logging in anywhere might be steep, but the additional features might make it worth it. Password managers like Dashlane, LastPass, 1Password, and mSecure offer:

  • Secure storage of bank cards and any identity cards like driver licenses
  • Password generators
  • Keystroke logger protection
  • Automatic backup
  • Multifactor authentication like biometrics or a token
  • Access to pre-determined contacts in case of emergency or death
  • Team password sharing (the team lead controls the master password for a single account like a FedEx account and grants access via the users individual password manager)

Do I need a locally-based password manager?
If you’re not comfortable storing passwords online or you just use your desktop to access accounts, choose a password manager that encrypts and stores passwords on your PC. This option is the least convenient but most secure. All password managers listed above come in the locally-based option for free or at a fraction of the cross-platform price.

User Error
Although much more secure than not using one, password managers do have some downfalls (that stem from user error). Just like any password, you still need to change your master password regularly, never share passwords with anyone, and once installed, a user should update existing passwords with really hard forgettable passwords or use a password generator for each online account.

And always remember to lock your computer or mobile device when not in use. Although password managers make it harder for hackers to virtually access your accounts, they do not protect against someone physically opening the file.

It’s also a good idea to check settings to ensure that when booting or waking up your device, the password manager requires you to re-enter the password.

Pa$$word1 ain’t cutting it.
If you’re not ready to commit to a password manager, think about the consequences the next time you are prompted to update your password. Adding a “1” to the end of your current password isn’t safe or smart.

We’ve all been there, and committing to a password manager in some cases is expensive and setting one up can be time consuming depending on the amount of accounts, so I understand the hesitation. But it’s worth it for that added layer of protection and security.

-JRL

September 18, 2014

The Cloud Doesn't Bite, Part III

Why it's OK to be a server-hugger—a cloud server hugger.

(This is the final post in a three-part series. Read the first and second posts here.)

By now, you probably understand the cloud enough to know what it is and does. Maybe it's something you've even considered for your own business. But you're still not sold. You still have nagging concerns. You still have questions that you wish you could ask, but you're pretty sure no cloud company would dignify those questions with an honest, legitimate response.

Well we’re a cloud company, and we’ll answer those questions.

Inspired by a highly illuminating (!) thread on Slashdot about the video embedded below, we've noticed that some of you aren't ready to get your head caught up in the cloud just yet. And that's cool. But let's see if maybe we can put a few of those fears to rest right now.

“[The] reason that companies are hesitant to commit all of their IT to the cloud [relates to] keeping control. It's not about jobs, it's about being sure that critical services are available when you need them. Whenever you see ‘in the CLOUD!’, mentally replace it with ‘using someone else's server’—all of a sudden it looks a whole lot less appealing. Yes, you gain some flexibility, but you lose a LOT of control. I like my data to not be in the hands of someone else. If I don't control the actual machine that has my data on it, then I don't control the data.”

You guys are control FREAKS! And rightfully so. But some of us actually don't take that away from you. Believe it or not, we make it easier for you.

In fact, sometimes you even get to manage your own infrastructure—and that means you can do anything an employee can do. You'll probably even get so good at it that you'll wonder why we don't pay you.

But it doesn't stop at mere management. Oh, no, no, no, friends. You can even take it one further and build, manage, and have total control over your very own private cloud of virtual servers. Yes, yours, and yours only. Now announcing you, the shot caller.

The point is, you don't lose control over your data in the cloud. None. 'Cause cloud companies don't play like that.

“The first rule of computer security is physical access, which is impossible with cloud services, which means they are inherently insecure.”

Curious. So since you can't physically touch your money in your bank account, does that mean it's a free-for-all on your savings? Let us know; we'll bring buckets.

“These cloud guys always forget to mention one glaring problem with their model— they're not adding any new software to the picture.”

Ready for us to blow your minds? We're actually adding software all the time; you just don't see it—but you do feel it.

Your friendly Infrastructure as a Service (IaaS) providers out there are doing a lot of development behind the scenes. An internal software update might let us deploy servers 10 minutes faster, for example. You won't see that, but that doesn't mean it's not happening. If you're happy with your servers, then rest assured you're seeing some sweet software in action. Some cloud companies aren't exclusively focused on software (think Salesforce), but that doesn't mean the software is dial-up grade.

“I personally don't trust the cloud. Think about it for a moment. You are putting your data on a server, and you have no clue as to where it is. You have no clue about who else is able to see that data, and you have no clue about who is watching as you access your data and probably no clue if that server is up to date on security patches.”

Just ask. Simply ask all these questions, and you'd have all these answers. Not to be cheeky, but all of this is information you can and do have a right to know before you commit to anything. We're not sure what makes you think you don't, but you do. Your own due diligence on behalf of your data makes that a necessity, not a luxury.

“As long as I'm accountable, I want the hardware and software under my control. That way when something goes wrong and my boss calls and asks 'WTF?', I can give him something more than ’Well I called Amazon and left a message with our account representative.’"

We can't speak for Amazon, but cloud companies often offer multiple ways you can get a hold of a real, live person because we get that you want to talk to us, like, yesterday. Yes, we totally get you. And we want to fix whatever ails you. In the cloud, that is.

But what makes you think we won't know when something goes wrong before you do? (Checkmate.)

“No matter how much marketing jargon you spew at people, ‘the cloud’ is still just a bunch of servers. Stop lying.”

Why yes, yes, it is. Who's lying to you about that? You're right. "They" should stop lying.

The concept of "the cloud" is simply about where the servers are located and how you consume computing, storage, and networking resources. In "the cloud," your servers are accessed remotely via a network connection (often the Internet, for most of the clouds you know and love) as opposed to being locally accessed while housed in a server room or physical location on the company premises. Your premises, as in wherever you are while performing your computing functions. But no one's trying to pull the wool over your eyes with that one.

Think about it this way: If servers at your location are "on the ground," then servers away from your location can be considered "in the cloud." And that's all there is to it.

Did we help? Did we clear the cloudy haze? We certainly hope so.

But this is just the beginning, and our door is always open for you to question, criticize, and wax philosophical with us when it comes to all things cloud. So get at us. You can chat with us live via our homepage, message us or post up on Facebook, or sling a tweet at a SLayer. We've got real, live people manning their stations. Consider the gauntlet thrown.

-Fayza

September 4, 2014

Keeping your private parts private.

Even with the knowledge that images can live on forever to haunt you, people continue to snap self-portraits in compromising positions (it’s your prerogative). Heck, before smart phones came along, people were using Polaroids to capture the moment. And, if history teaches us anything, people will continue the trend—instead of a smart phone, it’ll be a holodeck (a la Star Trek). Ugh, can you imagine that?

The recent high-profile hack of nude celebrity photos came from private phones. They weren’t posted to Facebook or Instagram. These celebrities didn’t hashtag.

#birthdaysuit #emperorsnewclothes #whoneedsdesignerthreads #shegotitfromhermama

Their sensitive data was compromised.

After speculation the hack stemmed from an iCloud® security vulnerability, Apple released a statement saying, “We have discovered that certain celebrity accounts were compromised by a very targeted attack on user names, passwords and security questions, a practice that has become all too common on the Internet.” The cloud platform was secure. The users’ security credentials weren’t.

These were private photos intended for private use, so how did they get out there? How can you protect your data; your images; your privacy?

You’ve heard it once; twice; probably every time you create a new account online (and in this day in age, we all have dozens of user accounts online):

  1. Use a strong password. This SoftLayer Blog is an oldie but a goodie where the author gives the top three ways to make a password: 1) use a random generator like random.org; 2) use numbers in place of letters—for example, “minivan” becomes “m1n1v4n”; 3) write your passwords down in plain sight using “Hippocampy Encryption” (named in honor of the part of the brain that does memory type activities). Or take the XKCD approach to password security.
  2. And for heaven’s sake, don’t use the same password for every account. If you duplicate usernames and passwords across sites, a hacker just needs to access one account, and he or she will be able to get into all of your accounts!
  3. Craft little-known answers to security questions. Don’t post a childhood photo of you and your dog on Facebook with the description, “Max, the best pup ever” and then use Max as a security validation answer for “What’s the name of your favorite pet?” It’s like you’re giving the hackers the biggest hint ever.
  4. If available, use a two-factor authentication security enhancement. The government (FISMA), banks (PCI) and the healthcare industry are huge proponents of two-factor authentication—a security measure that requires two different kinds of evidence to prove that you are who you say you are and that you should have access to what you're trying to access. Read our blog or KnowledgeLayer Article for more details.
  5. Remember passwords are like underwear—don’t share them with friends and change them often. When it comes to passwords, at least once a year should suffice. For underwear, we recommend changing more regularly.

We won’t tell you what to do with your sensitive selfies. But do yourself a favor, and be smart about protecting them.

-JRL

August 11, 2014

I PLEB Allegiance to My Data!

As a "techy turned marketing turned social media turned compliance turned security turned management" guy, I have had the pleasure of talking to many different customers over the years and have heard horror stories about data loss, data destruction, and data availability. I have also heard great stories about how to protect data and the differing ways to approach data protection.

On a daily basis, I deal with NIST 800-53 rev.4, PCI, HIPAA, CSA, FFIEC, and SOC controls among many others. I also deal with specific customer security worksheets that ask for information about how we (SoftLayer) protect their data in the cloud.

My first response is always, WE DON’T!

The looks I’ve seen on faces in reaction to that response over the years have been priceless. Not just from customers but from auditors’ faces as well.

  • They ask how we back up customer data. We don’t.
  • They ask how we make it redundant. We don’t.
  • They ask how we make it available 99.99 percent of the time. We don’t.

I have to explain to them that SoftLayer is simply infrastructure as a service (IaaS), and we stop there. All other data planning should be done by the customer. OK, you busted me, we do offer managed services as an additional option. We help the customer using that service to configure and protect their data.

We hear from people about Personal Health Information (PHI), credit card data, government data, banking data, insurance data, proprietary information related to code and data structure, and APIs that should be protected with their lives, etc. What is the one running theme? It’s data. And data is data folks, plain and simple!

Photographers want to protect their pictures, chefs want to protect their recipes, grandparents want to protect the pictures of their grandkids, and the Dallas Cowboys want to protect their playbook (not that it is exciting or anything). Data is data, and it should be protected.

So how do you go about doing that? That's where PLEB, the weird acronym in the title of this post, comes in!

PLEB stands for Physical, Logical, Encryption, Backups.

If you take those four topics into consideration when dealing with any type of data, you can limit the risk associated with data loss, destruction, and availability. Let’s look at the details of the four topics:

  • Physical Security—In a cloud model it is on the shoulders of the cloud service provider (CSP) to meet strict requirements of a regulated workload. Your CSP should have robust physical controls in place. They should be SOC2 audited, and you should request the SOC2 report showing little or no exceptions. Think cameras, guards, key card access, bio access, glass alarms, motion detectors, etc. Some, if not all, of these should make your list of must-haves.
  • Logical Access—This is likely a shared control family when dealing with cloud. If the CSP has a portal that can make changes to your systems and the portal has a permissions engine allowing you to add users, then that portion of logical access is a shared control. First, the CSP should protect its portal permission system, while the customer should protect admin access to the portal by creating new privileged users who can make changes to systems. Second, and just as important, when provisioning you must remove the initial credentials setup and add new, private credentials and restrict access accordingly. Note, that it’s strictly a customer control.
  • Encryption—There are many ways to achieve encryption, both at rest and in transit. For data at rest you can use full disk encryption, virtual disk encryption, file or folder encryption, and/or volume encryption. This is required for many regulated workloads and is a great idea for any type of data with personal value. For public data in transit, you should consider SSL or TLS, depending on your needs. For backend connectivity from your place of business, office, or home into your cloud infrastructure, you should consider a secure VPN tunnel for encryption.
  • Backups—I can’t stress enough that backups are not just the right thing to do, they are essential, especially when using IaaS. You want a copy at the CSP you can use if you need to restore quickly. But, you want another copy in a different location upon the chance of a disaster that WILL be out of your control.

So take the PLEB and mitigate risk related to data loss, data destruction, and data availability. Trust me—you will be glad you did.

-@skinman454

May 8, 2014

SoftLayer Security: Questions and Answers

When I talk to IBM Business Partners about SoftLayer, one of the most important topics of discussion is security. We ask businesses to trust SoftLayer with their business-critical data, so it’s important that SoftLayer’s physical and network security is as transparent and understandable as possible.

After going through the notes I’ve taken in many of these client meetings, I pulled out the ten most frequently asked questions about security, and I’ve compiled answers.

Q1: How is SoftLayer secured? What security measures does SoftLayer have in place to ensure my workloads are safe?

A: This “big picture” question is the most common security-related question I’ve heard. SoftLayer’s approach to security involves several distinct layers, so it’s tough to generalize every aspect in a single response. Here are some of the highlights:

  • SoftLayer’s security management is aligned with U.S. government standards based on NIST 800-53 framework, a catalog of security and privacy controls defined for U.S. federal government information systems. SoftLayer maintains SOC 2 Type II reporting compliance for every data center. SOC 2 reports are audits against controls covering security, availability, and process integrity. SoftLayer’s data centers are also monitored 24x7 for both network and on-site security.
  • Security is maintained through automation (less likely for human error) and audit controls. Server room access is limited to authorized employees only, and every location is protected against physical intrusion.
  • Customers can create a multi-layer security architecture to suit their needs. SoftLayer offers several on-demand server and network security devices, such as firewalls and gateway appliances.
  • SoftLayer integrates three distinct network topologies for each physical or virtual server and offers security solutions for systems, applications, and data as well. Each customer has one or many VLANs in each data center facility, and only users and servers the customer authorizes can access servers in those VLANs.
  • SoftLayer offers single-tenant resources, so customers have complete control and transparency into their servers.

Q2: Does SoftLayer destroy my data when I’ve de-provisioned a compute resource?

A: Yes. When a customer cancels any physical or virtual server, all data is erased using Department of Defense (DoD) 5220.22-m standards.

Q3: How does SoftLayer protect my servers against distributed denial of service (DDoS) attacks?

A: A SoftLayer Network Operations Center (NOC) team monitors network performance and security 24x7. Automated DDoS mitigation controls are in place should a DDoS attack occur.

It’s important to clarify here that the primary objective of this DDoS mitigation is to maintain performance integrity of the overall cloud infrastructure. With that in mind, SoftLayer can’t stop a customer from being attacked, but it can shield the customer (and any other customers in the same network) from the effects of the attack. If necessary, SoftLayer will remove the target from the public network for periods of time and null-routes incoming connections. Because of SoftLayer’s three-tiered network architecture, a customer would still have access to the targeted system via the private network.

Q4: How is communication segmented from other tenants using SoftLayer?

A: SoftLayer utilizes industry standard VLANs and switch access control lists (ACLs) to segment customer environments. Customers have the ability to add and manage their own VLANs, providing additional security even inside their own accounts. ACLs are configured to permit or deny any specified network packet (data) to be directed along a switch.

Q5: How is my data kept private? How can I confirm that SoftLayer can’t read my confidential data?

A: This question is common customers who deal with sensitive workloads such as HIPAA-protected documentation, employee records, case files, and so on.

SoftLayer customers are encouraged to deploy a gateway device (e.g. Vyatta appliance) on which they can configure encryption protocols. Because the gateway device is the first hop into SoftLayer’s network, it provides an encrypted tunnel to traverse the VLANs that reside on SoftLayer. When securing compute and storage resources, customers can deploy single tenant dedicated storage devices to establish isolated workloads, and they can even encrypt their hard drives from the OS level to protect data at rest. Encrypting the hard drive helps safeguard data even if SoftLayer were to replace a drive or something similar.

Q6: Does SoftLayer track and log customer environments?

A: Yes. SoftLayer audits and tracks all user activity in our customer portal. Some examples of what is tracked include:

  • User access, both failed and authenticated attempts (destination IP is shown on a report)
  • Compute resources users deploy or cancel
  • APIs for each call (who called the API, the API call and function, etc.)
  • Intrusion Protection and Detection services that observe traffic to customer hosts
  • Additionally, customers have root access to operating systems on their servers, so they can implement additional logging of their own.

Q7: Can I disable access to some of my users through the customer portal?

A: Yes. SoftLayer has very granular ACLs. User entitlements are segmented into different categories, including Support, Security, and Hardware. SoftLayer also gives customers the ability to limit access to public and private networks. Customers can even limit user access to specific bare metal or virtual server.

Q8: Does SoftLayer patch my operating system?

A: For unmanaged cloud servers, no. Once the updated operating system is deployed on a customer’s server, SoftLayer doesn’t touch it.

If you want help with that hands-on server administration, SoftLayer offers managed hosting. In a managed hosting environment, Technical Account Managers (TAMs) are assigned as focal points for customer requests and issues. TAMs help with reports and trending data that provide recommendations to mitigate potential issues (including OS patching).

Q9: Is SoftLayer suited to run HIPAA workloads?

A: Yes. SoftLayer has a number of customers running HIPAA workloads on both bare metal and single-tenant virtual servers. A Business Associate Agreement (BAA), signed by SoftLayer and the customers, clearly define the shared responsibilities for data security: SoftLayer is solely responsible for the security of the physical data center, along with the SoftLayer-provided infrastructure.

Q10: Can SoftLayer run government workloads? Does SoftLayer use the FISMA standards?

A: The Federal Information Security Management Act (FISMA) defines a framework for managing information security that must be followed for all federal information systems. Some state institutions don’t require FISMA, but look to cloud hosting companies to be aligned to the FIMSA guidelines.

Today, two SoftLayer data centers are audited to the FISMA standards – Dallas (DAL05) and Washington, D.C. (WDC01). Customers looking for the FISMA standard can deploy their workloads in those data centers. Future plans include having data centers that comply with more stringent FedRAMP requests.

For additional information, I highly recommend the on-demand SoftLayer Fundamentals session, “Keep safe – securing your SoftLayer virtual instance.” Also, check out Allan Tate’s Thoughts on Cloud blog, “HIPAA and cloud computing: What you need to know” for more on how SoftLayer handles HIPPA-related workloads.

-Darrel Haswell

Darrel Haswell is a Worldwide Channel Solutions Architect for SoftLayer, an IBM Company.

April 23, 2014

Security: 10 Tips for Hardening a Linux Server

In light of all the complex and specialized attacks on Internet-facing servers, it’s very important to protect your cloud assets from malicious assailants whose sole purpose is to leach, alter, expose, siphon sensitive data, or even to shut you down. From someone who does a lot of Linux deployments, I like to have handy a Linux template with some extra security policies configured.

Securing your environment starts during the ordering process when you are deploying server resources. Sometimes you want to deploy a quick server without putting it behind an extra hardware firewall layer or deploying it with an APF (Advance Policy Firewall). Here are a couple of security hardening tips I have set on my Linux template to have a solid base level of security when I deploy a Linux system.

Note: The following instructions assume that you are using CentOS or Red Hat Enterprise Linux.

1. Change the Root Password
Log in to your server and change the root password if you didn’t use a SSH key to gain access to your Linux system.

  • passwd - Make sure it’s strong.
  • Don't intend on using root.

2. Create a New User
The root user is the only user created on a new Linux install. You should add a new user for your own access and use of the server.

  • useradd <username>
  • passwd <username> (Make sure this is a strong password that’s different from your root password.)

3. Change the Password Age Requirements
Change the password age so you’ll be forced to change your password in a given period of time:

  • chage –M 60 –m 7 –w 7 <username>
    • M: Minimum of days required between password changes
    • m: Maximum days the password is valid
    • w: The number of days before password will warn of expiration

4. Disable Root Login
As Lee suggested in the last blog, you should Stop Using Root!

  • When you need super-user permissions, use sudo instead of su. Sudo is more secure than using su: When a user uses sudo to execute root-level commands, all commands are tracked by default in /var/log/secure. Furthermore, users will have to authenticate themselves to run sudo commands for a short period of time.

5. Use Secure Shell (SSH)
rlogin and telnet protocols don’t use an encrypted format, just plain text. I recommend using SSH protocol for remote log in and file transfers. SSH allows you to use encryption technology while communicating with your sever. SSH is still open to many different types of attacks, though. I suggest using the following to lock SSH down a little bit more:

  • Remove the ability to SSH as root:
    1. vi /etc/ssh/sshd_config.
    2. Find #PermitRootLogin yes and change to PermitRootLogin no.
    3. Run service sshd restart.
  • Change the default SSH 22 port. You can even utilize RSA keys instead of passwords for extra protection.

6. Update Kernel and Software
Ensure your kernel and software patches are up to date. I like to make sure my Linux kernel and software are always up to date because patches are constantly being released with corrected security flaws and exploits. Remember you have access to SoftLayer’s private network for updates and patches, so you don’t have to expose your server to the public network to get updates. Run this with sudo to get updates in RedHat or CentOS: yum update.

7. Strip Your System
Clean your system of unwanted packages. I strip my system to avoid installing unnecessary software to avoid vulnerabilities. This is called “reducing the attack surface.” Packages like NFS, Samba, even the X Windows desktops (i.e., Gnome or KDE) contain vulnerabilities. Here’s how reduce the attack surface:

  • List what is installed: yum list installed
  • List the package name: yum list <package-name>
  • Remove the package: yum remove <package-name>

8. Use Security Extensions
Use a security extension such as SELinux on RHEL or CentOS when you’re able. SELinux provides a flexible Mandatory Access Control (MAC); running a MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system. You’ll have to explore the official Red Hat documentation, which explains SELinux configuration. To check if SELinux is running, run sestatus.

9. Add a Welcome/Warning
Add a welcome or warning display for when users remote into your system. The message can be created using MOTD (message of the day). MOTD’s sole purpose is to display messages on console or SSH session logins. I like for my MOTDs to read “Welcome to <hostname>. All connections are being monitored and recorded.”

  • I recommend vi /etc/motd

10. Monitor Your Logs
Monitor logs whenever you can. Some example logs that you can audit:

  • System boot log: /var/log/boot.log
  • Authentication log: /var/log/secure
  • Log in records file: /var/log/utmp or /var/log/wtmp:
  • Where whole system logs or current activity are available: /var/log/message
  • Authentication logs: /var/log/auth.log
  • Kernel logs: /var/log/kern.log
  • Crond logs (cron job): /var/log/cron.log
  • Mail server logs: /var/log/maillog

You can even move these logs to a bare metal server to prevent intruders from easily modifying them.

This is just the tip of the iceberg when securing your Linux server. While not the most secure system, it gives you breathing room if you have to deploy quick servers for short duration tests, and so on. You can build more security into your server later for longer, more permanent-type servers.

- Darrel Haswell

Darrel Haswell is an advisory SoftLayer Business Partner Solution Architect.

Categories: 
February 3, 2014

Risk Management: 5 Tips for Managing Risk in the Cloud

Security breaches have made front-page news in recent months. With stories about Target, Neiman Marcus, Yahoo! and GoDaddy in the headlines recently, the importance of good information security practices is becoming harder and harder to ignore — even for smaller businesses. Moving your business into the cloud offers a plethora of benefits; however, those benefits do not come without their challenges. Moving your business into the cloud involves risks such as multi-tenancy, so it's important to be able to properly manage and identify these risks.

1. Know the Security Your Provider Offers
While some SaaS providers may have security baked-in, most IaaS providers (including SoftLayer) leave much of the logical security responsibility of a customer's systems to the customer. For the security measures that an infrastructure provider handles, the provider should be able to deliver documentation attesting these controls. We perform an annual SOC2 audit, so we can attest to the status of our security and availability controls as a service organization. With this information, our customers use controls from our report as part of their own compliance requirements. Knowing a provider's security controls (and seeing proof of that security) allows business owners and Chief Information Security Officers (CISO) to have peace-of-mind that they can properly plan their control activities to better prevent or respond to a breach.

2. Use the Cloud to Distribute and Replicate Your Presence
The incredible scalability and geographical distribution of operating in the cloud can yield some surprising payoff. Experts in the security industry are leveraging the cloud to reduce their patch cycles to days, not weeks or months. Most cloud providers have multiple sites so that you can spread your presence nationally, or even globally. With this kind of infrastructure footprint, businesses can replicate failover systems and accommodate regional demand across multiple facilities with the minimal incremental investment (and with nearly identical security controls).

3. Go Back to the Basics
Configuration management. Asset management. Separation of duties. Strong passwords. Many organizations get so distracted by the big picture of their security measures that they fail to manage these basic rights. Take advantage of any of your provider's tools to assist in the ‘mundane’ tasks that are vitally important to your business's overall security posture. For example, you can use image templates or post-provisioning scripts to deploy a standard baseline configuration to your systems, then track them down to the specific server room. You’ll know what hardware is in your server at all times, and if you're using SoftLayer, you can even drill down to the serial numbers of your hard drives.

4. Have Sound Incident Response Plans
The industry is becoming increasingly cognizant of the fact that it’s not a matter of if, but when a security threat will present itself. Even with exceedingly high levels of baked-in security, most of the recent breaches resulted from a compromised employee. Be prepared to respond to security incidents with confidence. While you may be physically distanced from your systems, you should be able to meet defined Recovery Time Objectives (RTOs) for your services.

5. Maintain Constant Contact with Your Cloud Provider
Things happen. No amount of planning can completely halt every incident, whether it be a natural disaster or a determined attacker. Know that your hosting provider has your back when things take an unexpected turn.

With proper planning and good practice, the cloud isn't as risky and frightening as most think. If you're interested in learning a little more about the best practices around security in the cloud, check out the Cloud Security Alliance (CSA). The CSA provides a wealth of knowledge to assist business owners and security professionals alike. Build on the strengths, compensate for the weaknesses, and you and your CISO will be able to sleep at night (and maybe even sneak in a beer after work).

-Matt

January 10, 2014

Platform Improvements: VLAN Management

As director of product development, I'm tasked with providing SoftLayer customers greater usability and self-service tools on our platform. Often, that challenge involves finding, testing, and introducing new products, but a significant amount of my attention focuses on internal projects to tweak and improve our existing products and services. To give you an idea of what that kind of "behind the scenes" project looks like, I'll fill you in on a few of the updates we recently rolled out to improve the way customers interact with and manage their Virtual LANs (VLANs).

VLANs play a significant role in SoftLayer's platform. In the most basic sense, VLANs fool servers into thinking they're behind the same network switch. If you have multiple servers in the same data center and behind the same router, you could have them all on the same VLAN, and all traffic between the servers would be handled at the layer-2 network level. For customers with multi-tier applications, zones can be created to isolate specific servers into separate VLANs — database servers, app servers, and Web servers can all be isolated in their own security partitions to meet specific security and/or compliance requirements.

In the past, VLANs were all issued distinct numbers so that we could logically and consistently differentiate them from each other. That utilitarian approach has proven to be functional, but we noticed an opportunity to make the naming and management of VLANs more customer-friendly without losing that functionality. Because many of our customers operate large environments with multiple VLANs, they've had the challenge of remembering which servers live behind which VLAN number, and the process of organizing all of that information was pretty daunting. Imagine an old telephone switchboard with criss-crossing wires connecting several numbered jacks (and not connecting others). This is where our new improvements come in.

Customers now have the ability to name their VLANs, and we've made updates that increase visibility into the resources (servers, firewalls, gateways, and subnets) that reside inside specific VLANs. In practice, that means you can name your VLAN that houses database servers "DB" or label it to pinpoint a specific department inside your organization. When you need to find one of those VLANs, you can easily search for it by name and make changes to it easily.

VLAN List View

VLAN Naming

VLAN Detail Page

VLAN Naming

While these little improvements may seem simple, they make life much easier for IT departments and sysadmins with large, complex environments. If you don't need this kind of functionality, we don't throw it in your face, but if you do need it, we make it clear and easily accessible.

If you ever come across quirks in the portal that you'd like us to address, please let us know. We love making big waves by announcing new products and services, but we get as much (or more) joy from finding subtle ways to streamline and improve the way our customers interact with our platform.

-Bryce

August 14, 2013

Setting Up Your New Server

As a technical support specialist at SoftLayer, I work with new customers regularly, and after fielding a lot of the same kinds of questions about setting up a new server, I thought I'd put together a quick guide that could be a resource for other new customers who are interested in implementing a few best practices when it comes to setting up and securing a new server. This documentation is based on my personal server setup experience and on the experience I've had helping customers with their new servers, so it shouldn't be considered an exhaustive, authoritative guide ... just a helpful and informative one.

Protect Your Data

First and foremost, configure backups for your server. The server is worthless without your data. Data is your business. An old adage says, "It's better to have and not need, than to need and not have." Imagine what would happen to your business if you lost just some of your data. There's no excuse for neglecting backup when configuring your new server. SoftLayer does not backup your server, but SoftLayer offers several options for data protection and backup to fit any of your needs.

Control panels like cPanel and Plesk include backup functionality and can be configured to automatically backup regularly an FTP/NAS account. Configure backups now, before doing anything else. Before migrating or copying your data to the server. This first (nearly empty) backup will be quick. Test the backup by restoring the data. If your server has RAID, it important to remember that RAID is not backup!

For more tips about setting up and checking your backups, check out Risk Management: The Importance of Redundant Backups

Use Strong Passwords

I've seen some very week and vulnerable password on customers' servers. SoftLayer sets a random, complex password on every new server that is provisioned. Don't change it to a weak password using names, birthdays and other trivia that can be found or guessed easily. Remember, a strong password doesn't have to be a complicated one: xkcd: Password Strength

Write down your passwords: "If I write them down and then protect the piece of paper — or whatever it is I wrote them down on — there is nothing wrong with that. That allows us to remember more passwords and better passwords." "We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet." Just don't use any of these passwords.
I've gone electronic and use 1Password and discovered just how many passwords I deal with. With such strong, random passwords, you don't have to change your password frequently, but if you have to, you don't have to worry about remembering the new one or updating all of your notes. If passwords are too much of a hassle ...

Or Don't Use Passwords

One of the wonderful things of SSH/SFTP on Linux/FreeBSD is that SSH-keys obviate the problem of passwords. Mac and Linux/FreeBSD have an SSH-client installed by default! There are a lot of great SSH clients available for every medium you'll use to access your server. For Windows, I recommend PuTTY, and for iOS, Panic Prompt.

Firewall

Firewalls block network connections. Configuring a firewall manually can get very complicated, especially when involving protocols like FTP which opens random ports on either the client or the server. A quick way to deal with this is to use the system-config-securitylevel-tui tool. Or better, use a firewall front end such as APF or CSF. These tools also simplify blocking or unblocking IPs.

Firewall Allow Block Unblock
APF apf -a <IP> apf -d <IP> apf -u <IP>
CSF* csf -a <IP> csf -d <IP> csf -dr <IP>

*CSF has a handy search command: csf -g <IP>.

SoftLayer customers should be sure to allow SoftLayer IP ranges through the firewall so we can better support you when you have questions or need help. Beyond blocking and allowing IP addresses, it's also important to lock down the ports on your server. The only open ports on your system should be the ones you want to use. Here's a quick list of some of the most common ports:

cPanel ports

  • 2078 - webDisk
  • 2083 - cPanel control panel
  • 2087 - WHM control panel
  • 2096 - webmail

Other

  • 22 - SSH (secure shell - Linux)
  • 53 - DNS name servers
  • 3389 - RDP (Remote Desktop Protocol - Windows)
  • 8443 - Plesk control panel

Mail Ports

  • 25 - SMTP
  • 110 - POP3
  • 143 - IMAP
  • 465 - SMTPS
  • 993 - IMAPS
  • 995 - POP3S

Web Server Ports

  • 80 - HTTP
  • 443 - HTTPS

DNS

DNS is a naming system for computers and services on the Internet. Domain names like "softlayer.com" and "manage.softlayer.com" are easier to remember than IP address like 66.228.118.53 or even 2607:f0d0:1000:11:1::4 in IPv6. DNS looks up a domain's A record (AAAA record for IPv6), to retrieve its IP address. The opposite of an A record is a PTR record: PTR records resolve an IP address to a domain name.

Hostname
A hostname is the human-readable label you assign of your server to help you differentiate it from your other devices. A hostname should resolve to its server's main IP address, and the IP should resolve back to the hostname via a PTR record. This configuration is extremely important for email ... assuming you don't want all of your emails rejected as spam.

Avoid using "www" at the beginning of a hostname because it may conflict with a website on your server. The hostnames you choose don't have to be dry or boring. I've seen some pretty awesome hostname naming conventions over the years (Simpsons characters, Greek gods, superheros), so if you aren't going to go with a traditional naming convention, you can get creative and have some fun with it. A server's hostname can be changed in the customer portal and in the server's control panel. In cPanel, the hostname can be easily set in "Networking Setup". In Plesk, the hostname is set in "Server Preferences". Without a control panel, you can update the hostname from your operating system (ex. RedHat, Debian)

A Records
If you buy your domain name from SoftLayer, it is automatically added to our nameservers, but if your domain was registered externally, you'll need to go through a few additional steps to ensure your domain resolves correctly on our servers. To include your externally-registered domain on our DNS, you should first point it at our nameservers (ns1.softlayer.com, ns2.softlayer.com). Next, Add a DNS Zone, then add an A record corresponding to the hostname you chose earlier.

PTR Records
Many ISPs configure their servers that receive email to lookup the IP address of the domain in a sender's email address (a reverse DNS check) to see that the domain name matches the email server's host name. You can look up the PTR record for your IP address. In Terminal.app (Mac) or Command Prompt (Windows), type "nslookup" command followed by the IP. If the PTR doesn't match up, you can change the PTR easily.

NSLookup

SSL Certificates

Getting an SSL certificate for your site is optional, but it has many benefits. The certificates will assure your customers that they are looking at your site securely. SSL encrypts passwords and data sent over the network. Any website using SSL Certificates should be assigned its own IP address. For more information, we have a great KnowledgeLayer article about planning ahead for an SSL, and there's plenty of documentation on how to manage SSL certificates in cPanel and Plesk.

Move In!

Now that you've prepared your server and protected your data, you are ready to migrate your content to its new home. Be proactive about monitoring and managing your server once it's in production. These tips aren't meant to be a one-size-fits-all, "set it and forget it" solution; they're simply important aspects to consider when you get started with a new server. You probably noticed that I alluded to control panels quite a few times in this post, and that's for good reason: If you don't feel comfortable with all of the ins and outs of server administration, control panels are extremely valuable resources that do a lot of the heavy lifting for you.

If you have any questions about setting up your new server or you need any help with your SoftLayer account, remember that we're only a phone call away!

-Lyndell

April 29, 2013

Web Development - Installing mod_security with OWASP

You want to secure your web application, but you don't know where to start. A number of open-source resources and modules exist, but that variety is more intimidating than it is liberating. If you're going to take the time to implement application security, you don't want to put your eggs in the wrong basket, so you wind up suffering from analysis paralysis as you compare all of the options. You want a powerful, flexible security solution that isn't overly complex, so to save you the headache of making the decision, I'll make it for you: Start with mod_security and OWASP.

ModSecurity (mod_security) is an open-source Apache module that acts as a web application firewall. It is used to help protect your server (and websites) from several methods of attack, most common being brute force. You can think of mod_security as an invisible layer that separates users and the content on your server, quietly monitoring HTTP traffic and other interactions. It's easy to understand and simple to implement.

The challenge is that without some advanced configuration, mod_security isn't very functional, and that advanced configuration can get complex pretty quickly. You need to determine and set additional rules so that mod_security knows how to respond when approached with a potential threat. That's where Open Web Application Security Project (OWASP) comes in. You can think of the OWASP as an enhanced core ruleset that the mod_security module will follow to prevent attacks on your server.

The process of getting started with mod_security and OWASP might seem like a lot of work, but it's actually quite simple. Let's look at the installation and configuration process in a CentOS environment. First, we want to install the dependencies that mod_security needs:

## Install the GCC compiler and mod_security dependencies ##
$ sudo yum install gcc make
$ sudo yum install libxml2 libxml2-devel httpd-devel pcre-devel curl-devel

Now that we have the dependencies in place, let's install mod_security. Unfortunately, there is no yum for mod_security because it is not a maintained package, so you'll have to install it directly from the source:

## Get mod_security from its source ##
$ cd /usr/src
$ git clone https://github.com/SpiderLabs/ModSecurity.git

Now that we have mod_security on our server, we'll install it:

## Install mod_security ##
$ cd ModSecurity
$ ./configure
$ make install

And we'll copy over the default mod_security configuration file into the necessary Apache directory:

## Copy configuration file ##
$ cp modsecurity.conf-recommended /etc/httpd/conf.d/modsecurity.conf

We've got mod_security installed now, so we need to tell Apache about it ... It's no use having mod_security installed if our server doesn't know it's supposed to be using it:

## Apache configuration for mod_security ##
$ vi /etc/httpd/conf/httpd.conf

We'll need to load our Apache config file to include our dependencies (BEFORE the mod_security module) and the mod_security file module itself:

## Load dependencies ##
LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
## Load mod_security ##
LoadModule security2_module modules/mod_security2.so

We'll save our configuration changes and restart Apache:

## Restart Apache! ##
$ sudo /etc/init.d/httpd restart

As I mentioned at the top of this post, our installation of mod_security is good, but we want to enhance our ruleset with the help of OWASP. If you've made it this far, you won't have a problem following a similar process to install OWASP:

## OWASP ##
$ cd /etc/httpd/
$ git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git
$ mv owasp-modsecurity-crs modsecurity-crs

Just like with mod_security, we'll set up our configuration file:

## OWASP configuration file ##
$ cd modsecurity-crs
$ cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_config.conf

Now we have mod_security and the OWASP core ruleset ready to go! The last step we need to take is to update the Apache config file to set up our basic ruleset:

## Apache configuration ##
$ vi /etc/httpd/conf/httpd.conf

We'll add an IfModule and point it to our new OWASP rule set at the end of the file:

<IfModule security2_module>
    Include modsecurity-crs/modsecurity_crs_10_config.conf
    Include modsecurity-crs/base_rules/*.conf
</IfModule>

And to complete the installation, we save the config file and restart Apache:

## Restart Apache! ##
$ sudo /etc/init.d/httpd restart

And we've got mod_security installed with the OWASP core ruleset! With this default installation, we're leveraging the rules the OWASP open source community has come up with, and we have the flexibility to tweak and enhance those rules as our needs dictate. If you have any questions about this installation or you have any other technical blog topics you'd like to hear from us about, please let us know!

-Cassandra

Subscribe to security