DDoS (Distributed Denial of Service) attacks have become common, appearing to be coming from everywhere and targeting popular public infrastructure. There is usually something unique or common to each DDoS attack. This commonality can be used to classify the traffic and drop it. Depending on the topology and the attack vector the target organization may be able to effectively block the traffic. In some cases the upstream provider may need to be contacted to drop it. If the target organization can effectively communicate the attack vector the upstream providers will be more responsive.
opFlow is well suited to determine the attack vector.
The default landing page for opFlow displays the top 10 sources. If the suspected attack is of the DDoS type change the page to display the top 10 applications. This is done by clicking on the word ‘Advanced’ found in the top menu bar.
Figure #1 – Advanced Window
The Advanced window will render. Change the summary type to ‘App Sources’. Also, change the ‘Specific Time’ section to match the time period that is relevant. Click ‘Apply Selection’ and the landing page will update appropriately.
Figure #2 – Top 10 Applications
In the example above we see UDP:32760 in the second row, this is normal traffic for this particular netowrk. The domain traffic in the first row is very unusual. Now we have an idea that the attack traffic is related to UDP destination port 53. In order to get a tighter vector on this traffic navigate to ‘Views->Conversation Map’. The time interval will be preserved.
The flow data table will be found below the map. Click on the time header of the flow data table to sort based on time. Next change the records per page to 500. The conversation map will change to represent the 500 displayed flow records. Click on a flow data page the represents the DDoS time well.
Figure #3 – Conversation Map
The conversation map above is indicating that all the traffic is focused on one destination. Disable the ‘Zoom Lock’ on the map, then zoom into the center to determine what the attack target is.
Figure #4 – Flow Data Table
We observe that the attack traffic is focused on the DNS server, 10.248.114.10.
Looking at the flow data we see all the flows are a single packet, UDP and destined to port 53. We can also tell that none of these are valid DNS requests because the packet is much to big, 1,308 bytes. DNS responses can be large but a single DNS request should not be more than 150 bytes.
Based on this an ingress policy could be written that discards any packets larger than 150 bytes destined to the DNS server on UDP port 53.
