NimbusDDOS Attack Simulation Platform

NimbusDDOS Attack Platform

NimbusDDOS Attack Platform

JNS is happy to announce the spin-off of our DDoS attack platform service offering.  The new service offering is a consolidated offering of a service previously only available as a professional services engagement.  Details of the new service can be found at www.NimbusDDOS.com

Feature Overview

  • 8 Standard DDOS attacks
  • Cloud-based attack platform is geographically diverse
  • Cloud-based attack platform for scalability
  • Integrated performance testing of target system
  • Standard attacks with volume up to 20Gbps
  • Custom attacks in excess of 100Gbps
  • On-shore DDoS Experts

Why Perform DDoS Testing?

  • Financial losses due to service unavailability
  • Test/train technical staff in DDoS response
  • Validate that existing DDoS mitigation strategy is functioning
  • Assess performance impact of low-grade DDoS attacks
  • Network load-testing
Posted in DDoS, Security | Tagged , , | Leave a comment

Tips for Neat Cabling

Before

Cabinets prior to re-cabling.

After

Cabinets after re-cabling.

In a previous post, I listed observations related to server room organization.  One of the main sources of clutter in a server room is disorganized cabling.  Below are some quick tips to keep your cabling in control.  If your server room needs tamed, give JNS a call.

Zipties & Velcro – Use zipties for more permanent cables such as PDU power cables, and structured cabling.  Velcro wraps work well for less permanent cabling, for example network cabling from servers to top of rack access switches.

Color Code – Any consistent system will do.  One common method is to use a unique color that corresponds to each vlan.  Be sure to document the significance of the color, and post in the server room.

Use Custom Cable Lengths – Virtually all cables can be purchased in custom lengths.  Power and network cables can both be purchased in 1foot increments.  The ultimate in custom length is making your own cables, but the benefit of doing this usually isn’t worth the extra time.

Allow Network Cables to Relax – Network cables are usually sold on a spool or looped in a bag, which gives them a natural tendency to curl.  A trick I’ve used is to un-spool the cable and hang it in the hot aisle.  The heat and weight of the cable causes the cable to relax and straighten allowing for much faster and neater cable runs.  (see photo below for example)

Cable Storage

Hang cables for easy storage.

Choose Cable Management Wisely – Avoid using cable management systems that use the smaller, closely spaced, fingers to hold the cable.  These systems tend to damage the cable, and make the addition and removal of cable very difficult.

Use an Intuitive System – For instance, one client associated the rack unit of the server, with the port in the top-of-rack access switch.  Technicians intuitively expected that the server at rack unit 10 had its NIC connected to port 10 in the access switch.  This isn’t possible in all environments, but clever methods to intuitively convey information can help when documentation is lacking.

Separate Inter-Cabinet Cable Runs – The cable runs in the above-cabinet ladder rack are just as important as cabling within the cabinet.  Use proper cable management to separate bundles of cables based on the purpose and destination of the cable.

Posted in DC Ops., Organization | Tagged , , , , , | 1 Comment

Distributed Denial of Service (DDoS) Attack Platform

JNS has just finished creating a distributed denial of service (DDoS) attack platform.  We will have more information on our main website shortly, but if you are interested please contact JNS.

In a nutshell, the service allows JNS consultants to launch simulated DDoS attacks targeting a clients network and systems.

Value to the Client

  • Assess overall DDoS risk and preparedness
  • Create DDoS mitigation strategies
  • Validate DDoS strategies and procedures work as expected
  • Give technical staff real-world DDoS experience in a controlled setting
  • Validate DDoS theories and assumptions

Feature Overview

  • Cloud-based service capable of generating massive scale attacks from multiple geographic locations.
  • Capable of spoofed and non-spoofed attacks
  • Layer7 application attacks
  • Bandwidth attacks (UDP/ICMP floods)
  • Protocol attacks (Syn floods, etc.)
  • Custom attacks specific to the client environment
  • Expert assessment and guidance from JNS DDoS professionals
  • Granular control to minimize impact on active production environments
Posted in DDoS, Security, Uncategorized | Tagged , , , , , | Leave a comment

AWS Auto Scaling Groups

JNS consultants have had multiple occasions to work with clients that host their infrastructure in the Amazon cloud.  One key feature of AWS is the ability to horizontally scale your environment using auto-scaling groups.  Some clients are intimidated by this, but auto-scaling groups are fairly simple to setup and maintain.  Below is a simple script that creates an auto-scaling group using command line tools that are pre-installed on the Amazon linux distribution.  The script below is stripped down for simplicity.  JNS uses similar but more advanced scripts for all manner of AWS system management.  If you would like the assistance of AWS experts, please contact JNS.

#!/bin/bash

ASG_NAME='ASG name'        # An arbitrary name for the ASG
CONSOLE_NAME='name'        # The name launched instances are given
AMIID='ami-xxxxxxxxxx'     # The AMI that will be launched
INSTANCE_TYPE=m1.large     # The instance type
SSHKEY='key'               # The name of the EC2 key to use
SECURITY_GROUPS='g1,g2'    # List of security groups for instances
AZ='us-east-1a,us-east-1b' # availability zones to be used
MIN_SIZE=4                 # minimum number of instances running
MAX_SIZE=100               # maximum number of instances running
NUM_SCALE_UP=2             # Number of instances to be launched
NUM_SCALE_DOWN=-1          # Number of instances to shutdown
ELB='Some ELB'             # Name of the ELB used by the instances

# First create a launch config that defines the AMI to use
# instance type, ssh key and security groups
as-create-launch-config $ASG_NAME-launch \
       --image-id $AMIID \
       --instance-type $INSTANCE_TYPE \
       --key $SSHKEY \
       --group $SECURITY_GROUPS

# Next define an auto-scale group
as-create-auto-scaling-group $ASG_NAME-group $CREATE_PARAMS \
       --availability-zones $AZ \
       --launch-configuration $ASG_NAME-launch \
       --max-size $MAX_SIZE --min-size $MIN_SIZE \
       --tag "k=Name, v=$CONSOLE_NAME, p=true"

# Create a policy to be used for scaling up and scaling down
SCALE_UP=`as-put-scaling-policy $ASG_NAME-pol-up \
       --auto-scaling-group $ASG_NAME-group \
       --adjustment=$NUM_SCALE_UP \
       --type ChangeInCapacity`
SCALE_DOWN=`as-put-scaling-policy $ASG_NAME-pol-down \
       --auto-scaling-group $ASG_NAME-group \
       --adjustment=$NUM_SCALE_DOWN" \
       --type ChangeInCapacity`

# create a cloudwatch alarm which has the above policies
# set as the action.  This one triggers based on average
# CPU aggregated across members of the auto-scaling group
mon-put-metric-alarm --alarm-name $ASG_NAME-scale-up \
       --alarm-description "Scale up at 40% load" \
       --metric-name CPUUtilization \
       --namespace AWS/EC2 \
       --dimensions AutoScalingGroupName=$ASG_NAME-group \
       --statistic Average \
       --period 60 \
       --threshold 40 \
       --comparison-operator GreaterThanThreshold \
       --evaluation-periods 3 \
       --unit Percent --alarm-actions $SCALE_UP
mon-put-metric-alarm --alarm-name $ASG_NAME-scale-down \
       --alarm-description "Scale down below 10% load" \
       --metric-name CPUUtilization \
       --namespace AWS/EC2 \
       --dimensions AutoScalingGroupName=$ASG_NAME-group \
       --statistic Average \
       --period 60 \
       --threshold 10 \
       --comparison-operator LessThanThreshold \
       --evaluation-periods 3 \
       --unit Percent --alarm-actions $SCALE_DOWN
Posted in AWS/Amazon | Tagged , , , , , , | Leave a comment

Thoughts on an Organized Data Center/Server Room

JNS consultants have worked in a wide array of data centers and server rooms, each with its own unique flavor.  Some are immaculate, with cables exactingly cut and tied to create a stunning visual presentation.  More often, however, we see cabinets with a rats nest of cables, the result of overworked or irresponsible datacenter technicians.  Below are some observations related to organization within the datacenter.  Give JNS a call if your server room needs a facelift.

Proper Organization Will Save You Time and Money – Organizing your data center resources allows your data center technicians to work more effectively.  Proper organization is a front-loaded task, but the time you spend upfront will save time during a crisis with faster diagnosis.

Increased Availability – An organized server room will increase system availability.  Clutter and disorder cause data center operations staff to make errors, its as simple as that.

Don’t Overdo It – We’ve all seen the marketing photos of the perfect server room; with pristine cabling, identical servers, and attractive blue LEDs blinking in harmony.  I’m a firm believer in a clean cabinet, but like most things the sweet spot is in moderation.  The goal of organizing a server room is to create an environment that assists the operators in maintaining and troubleshooting within the environment.  Attempting to achieve perfection is a costly endeavor with diminishing business returns.

The Layout Should be Intuitive – Simple and intuitive design reduces human error.  Regardless of what documentation might say, people will often make assumptions even if it contradicts documentation.  For example, lets assume you have two cabinets each with a single PDU.  Above each cabinet is a power receptacle.  But rather than having the PDU plug into the receptacle directly above the cabinet it is in, it plugs into the one above the neighboring cabinet.  This is an extreme and unlikely scenario, but it illustrates how a technician could cause an outage by making incorrect assumptions in a non-intuitive environment.

The Layout Should be Consistent – In a high availability, live-site environment, consistency is critical to maintaining a stable environment.

Posted in DC Ops., Organization | Tagged , , , , | 1 Comment

Distributed Denial of Service (DDoS) Mitigation

Recently, the JNS team was consulted to provide a DDoS risk assessment for a high profile client.  The client has a mixed environment of cloud-based virtual systems on Amazon Web Services, and physical systems on a managed hosting provider.  Multiple areas of risk were discovered, and mitigation strategies were presented to address these.  This post discusses, in brief, the most common DDoS mitigation strategies (there are many others).  If you are experiencing a DDoS attack, or would like assistance in formulating a strategy to protect your site, please contact JNS.

Strategy #1 – Hide Behind Your CDN
Clients with limited resources and a pre-existing contract with a content distribution network (CDN) often use this strategy.  The basis for this mitigation strategy is to conceal the client’s modest web server resources behind the much larger resources of a CDN provider.  This strategy requires that all resources (static and dynamic) be served through the CDN.  Services that do this include Akamai’s Dynamic Site Accelerator product or Edgecast’s Application Delivery Network.  This  mitigation strategy is well suited to stopping many layer3/4 attacks including ICMP/UDP floods, SYN floods, Slowloris attack, and connection exhaustion attacks due to the proxy behavior of the CDN.  This strategy will not protect against layer7 targeted application attacks as they will simply be passed by the CDN to the underlying client servers.

Strategy #2 – Auto-scale in the Cloud
Many clients operating in the cloud attempt to mitigate a DDoS attack using the scale out capabilities inherent in most cloud services.  The basis for this mitigation strategy is to automatically expand the client’s cloud resources to match any increase in demand; whether they are legitimate requests or attack traffic.  This strategy is particularly appealing as it requires minimal changes to the client infrastructure.  The caveat of this strategy is that all components of the environment must auto-scale.  This is often difficult or impossible to do with relational database components.  This leaves any database driven resource susceptible to DDoS attacks.

Strategy #3 – DDoS Hardware Mitigation Solutions
For clients with control of their own servers and networks, dedicated DDoS mitigation hardware is often the first solution that comes to mind.  If a client’s infrastructure is large enough this provides excellent DDoS mitigation.  However, recent DDoS attacks can often exceed 50Gbps of traffic requiring substantial network resources to absorb the attack and let the mitigation hardware do its job.  Hardware solutions are capable of mitigating virtually all attacks provided that the network can withstand the traffic volume.

Strategy #4 – Dedicated Mitigation Services
Mitigation services provided by companies like Prolexic and Verisign offer a solution that allows the client to outsource DDoS mitigation to a purpose built mitigation network.  These services often work in one of two methods.  The first is a proxy-based service that with a simple DNS change directs all traffic through the mitigation network.  The traffic is filtered, then the clean traffic is proxied through to the client systems.  The second method, involves creation of GRE tunnels between the mitigation vendor’s network and the client’s infrastructure.  During an attack, the client alters BGP announcements to force all traffic destined to their network to pass through the mitigation network.  The mitigation network cleans the traffic, and then passes it along to the client’s network via the GRE tunnels.  This strategy is capable of handling virtually all attacks including layer7 application attacks.  The largest mitigation vendors have capacity to handle in excess of 500Gbps of attack traffic.

Posted in DDoS, Security | Tagged , , , , , , , , , , | 1 Comment

First!

Welcome to the JNS blog.  This blog will have posts by JNS consultants on all variety of topics.  If you find any of the information useful, post a comment with your feedback.

Enjoy!

Posted in Uncategorized | Tagged | Leave a comment