KML_FLASHEMBED_PROCESS_SCRIPT_CALLS

Archive for the ‘Security’ Category

 

The Top 3 Private Networking Use Cases for CloudLink

Tuesday, April 2nd, 2013 by

Public clouds are fantastic for a majority of infrastructure use cases. And interconnectivity between clouds enables myriad solutions to empower businesses to have multiple synchronized points of presence across the world. Companies can easily set up connections that traverse the public Internet as a means to transmit and potentially synchronize data between cloud data centers. But these connections need to be reliable and more often than not, private.

CloudLink private network between cloud data centers

CloudLink private network between cloud data centers

With public network connections between clouds, users are at the mercy of hops and latency. For example, data may take one route with a particular number of hops, and a second later, may follow a completely different path and take a longer or shorter amount of time based on the connection.

In terms of securing the transport, some companies rely on point-to-point VPN connections using a hardware or software solution or some combination of the two. However, these solutions are also constrained by the connection and have limited speeds.

There are some scenarios or use cases that warrant using dedicated private networking to join geographically dispersed clouds. This is where GoGrid’s CloudLink service comes into play.

GoGrid’s CloudLink is a data center interconnect product—a redundant 10 Gbps pipe that is isolated to GoGrid traffic only. CloudLink enables private network traffic between different servers in GoGrid’s US data centers. As part of our “Complex Infrastructure Made Easy” mission, we designed this service to be basic yet powerful and still meet the needs of demanding organizations. Because this is a private network, much like the private network within GoGrid’s standard cloud infrastructure, there are no bandwidth costs. You simply decide on the connection speed (10 Mbps, 100 Mbps, or 1 Gbps), configure your connection, and pay for just the dedicated connection. (more…) «The Top 3 Private Networking Use Cases for CloudLink»

Software Defined Networking on the Edge

Thursday, March 14th, 2013 by

One of the recent trends in technology is the movement toward software-defined networks (SDN). With SDN, networking is no longer tied to a specific proprietary device but rather integrated via software. GoGrid has adopted this software defined networking architecture for its new product offerings starting with Dynamic Load Balancers and now with our new Firewall Service.

SDN typically means that the control plane is separated from the forwarding plane and is centralized. This setup is easier to manage and enables a more distributed system. In addition, management of the network is typically programmatic with SDN. In GoGrid’s architecture, for example, management is centralized while the activities are distributed. This design allows for greater resiliency and self-healing capabilities, meaning there’s always a way to return a failed distributed node to its previously stable state. We also enable access to these services via our management console and a public RESTful API.

Although most people think of SDN as it applies to the core (switches and routers), GoGrid’s strategy has been to start at the edge and then work toward the core. Dynamic Load Balancers and the Firewall Service are considered to be on the network edge. However, other services closer to the core, such as Private Network Automation (PNA), have adopted this architecture as well. Details about the Dynamic Load Balancer are explained in this previous blog post.

Firewall Service

GoGrid is introducing a new Firewall Service designed to be self-healing and available to all customers in all our data centers. Customers can deploy this service through the management console or API. Having a Firewall Service available to all our customers is an important step in further securing infrastructure in the cloud. Although GoGrid has secured its data centers and has built-in security measures to protect our customers’ infrastructure, our customers want greater granular control of port access for their individual servers. Our new Firewall Service is designed to meet and exceed those needs by making it easy to set up security wherever Cloud Servers are located.

This service comes with several key features: (more…) «Software Defined Networking on the Edge»

Leverage Automation for your Private Network

Tuesday, January 29th, 2013 by

GoGrid has recently released some new features that improve on the customer experience using our private network.  Private Network Automation (PNA) is currently available in all our data centers. As of this most recent release, these new features will be exposed if you enable PNA by contacting support:

  • All servers will have a private IP assigned upon creation (both virtual and dedicated)
  • Any private IPs that are used will be marked as assigned on the portal
  • Cloud Storage no longer requires static routes. It is now accessible via your favorite protocol (Samba, SCP, etc.)

The assignment of private IPs happen automatically at the time a new server is deployed. GoGrid has enabled this for all new customers. If you are an existing customer, this is feature IS NOT enabled in data centers where you have servers deployed. You will need to file a support ticket to request this feature. Note that once enabled, this will be active for all new servers only – existing servers will keep their existing settings.

As you can see from the screenshot below, once you create the server, you will have a public IP and a private IP assigned. Note that this feature is enabled for both virtual and dedicated servers.

AMS_private_IP

This is also visible in the Networking tab so that you can monitor private IPs that have been assigned from your block.

PNA_List

(more…) «Leverage Automation for your Private Network»

How to Recover from a Linux Security Breach – Recovery & Hardening (Part 2)

Tuesday, January 29th, 2013 by

This is Part 2 of a GoGrid security blog series on identifying and recovering from a Linux security breach. Part 1 provided general guidelines for conducting a security analysis on a compromised Linux server and forming strategic teams to address and resolve the breach.

In this article, we’ll review some recommended steps for recovering from a breach.

Recovering from the Breach

Lock the doors

Now that you’ve confirmed that there are no intruders logged in and you’ve identified the established connections, it’s time to “lock the doors.” Locking the doors largely depends on who is managing your firewall. Contact GoGrid in the event that we’re managing your firewall or perform the following actions if you manage your firewall:

  • Modify your system’s iptables configuration to restrict all remote console connections such as SSH to your office network
  • Modify your system’s iptables configuration to block all previously identified suspicious connections from and to your system.
  • Modify your system’s iptables to block all other services from the public Internet to your server. Doing so will effectively bring down your website or services, but you want to avoid compromising your customers or web site visitors.

Install and run a rootkit analyzer

(more…) «How to Recover from a Linux Security Breach – Recovery & Hardening (Part 2)»

How to Recover from a Linux Security Breach – Forensics, Analysis, & Building Teams (Part 1)

Monday, January 28th, 2013 by

This 2-part GoGrid security blog series provides general guidelines for conducting a security analysis on a compromised Linux server and for recovering from a breach. Before you begin the security analysis, you need to consider two important factors:

1. The type of data your compromised server is storing or transmitting,
2. How important the server’s function is to your business

The data type—Personally Identifiable Information (PII) or Protected Health Information (PHI), for example—is important because your organization could be legally required to notify external parties and local or federal government agencies in the event of a breach. The compromised server’s function is important because its criticality may drive the recovery timeline.

You also may want to consider engaging a third-party that specializes in security forensics.

This series will cover 3 important items:

1) Understanding & assessing the breach
2) Setting up forensics & recovery teams
3) Recovering from the breach

Although this series won’t replace what a competent security firm can accomplish, it does provide an overview of some core processes, procedures, and activities you can do to potentially recover from a breach. And because each incident varies based on your computer system, be sure to conduct additional analysis and consult with experts to double-check your breach identification and resolution plan. (more…) «How to Recover from a Linux Security Breach – Forensics, Analysis, & Building Teams (Part 1)»