Sunday, March 13, 2016

Ddos Attacks and mitigation,an account from the practical world

Before I delve into the anti DDoS methodologies involved let me explain what a DdoS is and how it can impact you-the customer.

Denial Of Service (DoS)

DoS stands for Denial of Service which involves bad guys (known as hackers) sending so much garbage data directing to  the customer's site that it's performance starts getting affected. In other words a hacker sends so much garbage requests that your product site just does not have enough resources to serve genuine users.
A DdoS stands for Distributed DoS which is basically a hacker conducting a DoS attack from multiple locations simultaneously making it even more difficult to comprehend and block such users.

How does it impact you?

It has been reported that almost 72% (yes almost three quarters) of servers serving an IT product get Ddos'ed! That means if your domain is not having a DDoS mitigation policy, your business will get be impacted. Not only do you lose money but your brand reputation also gets affected.

A Ddos atrack is when an evil user who hates see you flourish decides to send huge amount of packets to your account. This could start using up the service provider's internet bandwidth or start using resources on the server hosting your domain.

Generally tools such as Cacti (rrdtools) and Nfsen are used to measure incoming and outgoing bandwidth on and the nature of traffic we receive (is it website based or dns). There are tools which can be used to detect such attacks and take preventive action.
An example of a spike in traffic

False alarms can be difficult to identify

Server side monitoring

On the server side one can setup monitoring tools which measure crucial parameters like cpu usage, bandwidth usage, number of processes and threads running.
When an attacker sends a lot of junk data to your site, your site's network will suddenly see a spike in traffic and the bandwidth consumed increases.
Generally the NOC or SOC is quick to detect this increase via alerts or graphs.
In some complex attacks there might not be an increase in bandwidth consumed but a surge in the number of packet arriving per second dramatically increases.

Cpu and other metrics of a server being measured by Graphite

After diagnosing the incident your hosting provider can employ a BGP announcement technique to mitigate the attack.
By changing the BGP announcement the hosting provider tells the whole internet that the best route to them is via a mitigation provider (Prolexic is a popular service).

Now the entire internet thinks that your hosting is via the mitigation provider and starts sending the entire traffic to them.

Such mitigation centers have enough bandwidth and devices to analyze the traffic and apply suitable filters to allow only clean traffic to pass through, thus thwarting a DdoS attack.

For the technically savvy reader, note that even though incoming traffic comes via the mitigation provider, the outgoing traffic (traffic which leaves the server, towards a customer) goes via the normal ISP link.

Further analysis:

A DDoS attack is hugely effective when the illegitimate traffic starts to congest or choke the bandwidth. In such a scenario all the servers within that datacenter (a central place where many servers are packed) are affected. So even if you're domain is not to being attacked but someone else's domain is, than your services get impacted.
To ensure this does not happen companies usually deploy multiple links with large bandwidth.

Important Links:

1) Impact of DdoS
2) Wiki on DDoS
3) Prolexic Mitigation technique

Monday, April 20, 2015

Intro to Juniper's Virtual Chassis aka VC

In networking and system administration redundancy and high uptime is one of the most important requirements. I have already covered about SRX (Juniper's firewall) redundancy in a previous article(link at the end). This post helps to configure redundancy for a very important piece of network equipment- switch. Juniper provides an exciting feature called the Virtual Chassis (VC).

What is a Virtual Chassis?

Suppose you have a switch which is directly connected to the router. As the organisation grows the switch runs of ports. Another scenario will be a datacenter where you have servers in another rack. So now one has to buy another switch. All these servers are similar and need to be connected to the router. Traditionally one would need to have these independent switches connected to the router. Each switch will have its own management ip and connectivity.

But why should this be the case? Logically all switches are supposed to behave similarly. Why cannot we have a situation where we configure all the switches in such a way to make it work as one unit?  Under such a scneario all these switches across different racks function as one big logical unit. And this is the core tenet of a Virual Chassis. And on top of that you get additional features such as:

Additional features of Virtual Chassis (VC)

1) No layer-2 loop between different switches. (STP ceases to exist)
1) Single management ip
2) High capacity backplane (128 Gbps full duplex links)
3) Easier management and scalable

Juniper Virtual Chassis (VC) in Daisy Chain

This article will quickly go through the points mentioned. Refer to the diagram. If the switches were independent then connecting them will mean a chance for layer 2 loops which means a broadcast storm! Without VC enabled Sw1 connects to Sw2 which connects to Sw3, while Sw3 connects to Sw1 as well. This will mean STP will kick in and block a few ports. This is highly undesirable.

Again, when the switches are independent all of them will have a management ip which means managing them becomes a pain.

The links connecting all the switches have chances of failing bringing down the network

What if we end up having 8 or 10 such racks, each having a switch and needing interconnectivity? The topology becomes highly complex.

With Virtual Chassis, VC enabled all the switches behave as one switch. Hence there is no loop! All the switches have one management ip and all the member switches can be controlled from that single ip.

All the members are connected using dedicated links which give a 64 Gbps full duplex throughput (128 Gbps) giving robust interconnectivity between the switches. Since these are dedicated links they are much more reliable.

Even a 8 switch VC behaves like one logical unit and only one switch describes the topology.

This is a highly desirable feature which has been lauded by the network industry.

Virtual Chassis and its components

Virtual Chassis follows a Master Slave paradigm. In it, one switch acts as the Master member which runs the routing, firewalling and manages the control plane. Another switch acts as the backup which continuously synchs this data and keeps a copy. It becomes active when the active switch fails.

All the other switches run in the "line card" mode. These switches are dumb and DO NOT run the routing engine. They are responsible for switching the packets and act as line cards/ports of the mega logical switch. Think of those switches as just additional line cards/ports attached to the Master switch.

NOTE: Each switch regardless of master or line card state has a its PFE active.

VCP port/cable

Each EX 4200 and above have 2 vcp ports while in EX2200 a ge port needs to be configured as a vcp port. A VCP port is exclusively used by all the members of a Virtual Chassis to synch data with each other. There is a dedicated VCP cable available which gives high speed connectivity. The cables need to be connected in such a way that all the members have multiple connectivity so that even if a switch fails the path is not broken to other switches. There are two ways to achieve it- Braided ring and Daisy chain. This will be discussed in the next part of this series.

NOTE: The VC utilizes VCCP to make sure that there are no loops formed in VCP cable connectivity. Infact it uses ISIS protocol and assigns 128.x.x.x series ip to all member switches.

Traffic flow in a VC

Let us assume a 3 member Virtual Chassis. Switch0 is master, SW1 is backup and SW2 is in line card mode. The uplink is connected to SW2 on port 0. The virtual chassis is the gateway for all the devices connected to it. 

Note: The exact configuration will be discussed in another part

Scenario 1: Intra switch traffic

Suppose there is a server connected to SW2 and it wants to communicate with a server in SW1. The traffic flow works exactly the way it would assuming this is one mega switch. The SW2 on receiving this traffic will realise that the destination resides on the same switch and the path is via the VCP cable.

The packet will be forwarded through the VCP cable connecting SW2 and SW1. SW1 on receiving will then forward it to the appropriate egress port. 

Scenario 2: Inter switch traffic

Suppose the server now wants to connect to the internet. The packet will come to SW2 ingress port and if there is no route it will expected move to the routing engine which will reside on SW0, just the way it works for a single switch

Daisy Chained vs Braided Ring

Finally, let us move to two different type of topologies,

1) Daisy Chained

The above diagram is in daisy chain. It does not really provide any additional capabilities but comes with a certain limitation. Since the first and the last VCs have to be connected one needs to have a cable that is long enough to cover the distance. The longest cable in market is 5m long.
Thus the VC is constrained to 5 m in length, which is around 3/4 switch VC.

2) Braided Ring

In braided ring, the VC's connect themselves alternately which allows for longer VC members (the maximum allowed limit). The following diagram will help understand why.

Juniper's Virtual Chassis (VC) in braided ring

Quick facts:

1) EX 2200 does not have dedicated VCP ports
2) EX 4200 has a 64gbps (one way) VCP ports
3) You can extend a VC across locations (buildings/datacenters) using a concept called extended VC.

In the next article of this series, I will cover the actual configuration, and basic troubleshooting steps

Important Links:

1) Different Virtual Chassis components
2) In depth article on Virtual Chassis
3) Switch Design
4) HA for SRX
5) Juniper VC topolgies