NTA and identifying a flow related to scans/DDoS attacks

I’m not sure NTA or any similar type tool based on Neflow can give you the visibility you need because they are Netflow based and do not look inside the packets. But I’m not an NTA expert and with some configuration you may be able to get the info you need.

Netflow can be very limited when trying to really understand what is going on and being able to prove it. Deep Packet Inspection (DPI) will give you more detail and information but you mention also that you are not looking for this. Bear in mind though, that here are and can be many aspects to DPI, it is not always about detail and complexity and timings, response, etc.  DPI can be very flexible but also as a result sometimes complex and difficult to interpret.

There are DPI tools that do not focus on application response but on network usage, giving more information on network and user activity by grabbing information ‘off the wire’, following specific protocols, like Internet, performing some reassembly of packets, picking out the critical information, usually the ‘names’, that normal users can interpret and understand and storing them. The software is trying to do a lot of the work, extract some of the complexity, make the data easier to interpret, be able to ‘get the big picture’ and then drill down.  ‘A sort of ‘netflow extender’ more information and detail on bandwidth, transactions between applications, user activity, etc.  Netflow is not required and can be deployed at those critical points in the network where you need more visibility.

An interesting use case we came across recently, the customer had an issue with some web application servers runnig slow. They were public facing and they thought maybe a DDoS attack. The servers hosted online game and gambling applications so they are always suspicious of being targeted. The CPU's on the servers were flatlined but there was nothing in the logs. They deployed a deep packet inspection tool and they saw lots of traffic over port 80. You could say that this was also possible using NetFlow? However, the crucial piece of data came about when they drilled down on the HTTP traffic. They saw thousands of requests to a resource called stress-test.cgi. When they cross checked the IP it was one of their own. Turns out one of their application people was running stress tests in the middle of the day. Easy fix but it shows that when it comes to troubleshooting you need as much detail as possible.

Hope this helps,

Darragh

First, I would ABSOLUTELY agree with the approach darragh.delaney outlines. When troubleshooting a potential attack, there is really no such thing as too much information.

However, to your point of not wanting to use DPI; you should be able to easily capture this information from NTA as it is capturing the following 7 fields from your packet headers:

• ifIndex
• Source IP
• Destination IP
• IP Protocol
• Source port
• Destination Port
• ToS

While not nearly as verbose as DPI, with the right architecture you can certainly ID 'safe' traffic for your network. By default, this should assist you with quickly identifying 'potential threat' traffic as it occurs. Unfortunately, I do not know off-hand of a video series devoted to identifying DDoS via NetFlow. If you care to trudge through the white-papers, here's a really good start: A Cisco Guide to Defending Against Distributed Denial of Service Attacks - Cisco Systems

I would like to mention one quick thing though; you can't run NTA without NPM. I would really look at NPM v11 and test the free Network Packet Analysis Sensor. I think you'll be surprised at how easy it is to use and how it really ties in the missing data that you usually are looking for after starting with NTA.

-ZackM

Loop1 Systems: SolarWinds Training and Professional Services

• LinkedIN: Loop1 Systems
• Facebook: Loop1 Systems
• Twitter: @Loop1Systems

@zackm, darragh.delaney,

I wonder if you wouldn't mind explaining how the QoE sensors in NPM could help with DDoS attacks a bit further.  While I agree having DPI technologies is really useful for getting visbility beyond the typical data you get from NetFlow, it seems that the QoE sensors as currently designed would not be helpful in this case because:

-they have to be configured to be looking for certain traffic a priori

     -the signatures can't be customized so even if you were monitoring the right application, you could not configure it to inspect and track a threat

-do not expose the layer 7 header info or contents through the SolarWinds UI so you could not even look at the monitored application contents if you wanted to

I have to admit I haven't played with the new QoE sensors so I could be wrong, that's why I'm asking.  Thanks!

@jrchapman

I am not a QoE expert either but from my experience of it I think you are correct. It's main focus is on gathering high level application an timing information. When it comes to security monitoring you need to look at the contents as you say. At the upper end of monitoring you could try and record all packets and store them so you can look at them after an event. There are systems out there that do this but can be expensive and you need lots of storage. Wireshark is fine for looking at your own data for a short period but you will run into problems if you connect it to a SPAN port.

The next option is to look inside the packets and store certain metadata. Metadata could be the output of an IDS engine which would show what packet data triggered the event or the name of a file that someone accessed on a network. NetFort LANGuardian is an example of a tool which gathers metadata, the video below shows how this could be used with Orion.

Maybe this is the middle ground, something that gives more detail than NetFlow but does not have the resource requirements of full packet capture and storage? I do work for NetFort so of course my own view is based on my LANGuardian experiences but I would be interested in your opinions.

Thank you all for your replies. I'm slowly starting to understand this a bit more in depth! I do have a question for zackm, or anyone else who knows:

How would I be able to accomplish pulling the information from those headers? Are there views I can create, or is this all on the NTA Summary page by default? Being able to tell my boss, "this was where the traffic was sourced from, and this is where it was destined for" is what I'm mostly looking for here.  As it is right now, the views I'm looking at don't really show much that helps, and everything seems to be a top 5 (but if it is distributed over a large enough network, it may not even show up?).

I must admit I'm still confused by some of the terms used in NTA for analysis, such as endpoints and receivers mostly.  It seems to me it would be easier to simply call them source and destination, reversing the term for whether traffic is ingress or egress.

It is a bit tedious to answer the question "this was where the traffic was sourced from, and this is where it was destined for" because of how NTA displays the data currently.

1)  You can click on any of the interfaces listed in the NetFlow Sources View on the NTA Summary page and you can see where traffic is flowing from that interfaces' perspective.  There is no way I know of to get a quick "end to end" view of a flow.  I do have a feature request for adding this ability on to the Atlas map here:  https://thwack.solarwinds.com/ideas/3621

2) you can also do a search by endpoint IP, or port in the search bar on the NTA Summary Page.

3) You can build your own pages that show exactly the traffic, time frame, or interface that you want to see, but again these do not display how the traffic is flowing end to end.

HTH...

thanks darragh.delaney!  This is a great example of how I was thinking DPI sensors in a network could be used for this purpose.  Also its a great demo of how you could use that in conjunction with SAM and UDT.  I will have to look at LAN guardian a bit further.  thanks again