7 Replies Latest reply on Oct 15, 2014 9:45 AM by johnny ringo

    NTA and identifying a flow related to scans/DDoS attacks


      Hi all,


      I'm new to the forums, so excuse me if this has already been asked and answered.  I did search through several video series and tried to search the forums, but didn't find anything specific to my questions.


      We utilize Solarwinds NTA at my work, and occasionally we see large ingress spikes of traffic.  I believe these to be probes or scans sometimes, but finding out the who/what/where/how with NTA seems to be like pulling teeth!


      As an example, we recently had almost a 7Gb/s ingress spike for ~15 minutes.  I tried to set an absolute time period to those 15 minutes, filtered by ingress, and checked the NTA Summary page (as well as a few custom views we've created for identifying such traffic).  Either we don't have our NTA configuration optimized to find this data, or I'm not really understanding how to read the data it is showing.


      Basically my questions for anyone out there who uses NTA:


      + Is there any good documentation or video series that explains how to use NTA for forensics relating to a DDoS attack that you know of? If so, please post any good info here!

      + Have you created a custom view that you use for similar forensics? I'm not looking for deep packet inspection, but anything that may make this particular function more easily understood for the average user.


      Thanks all..



        • Re: 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,


            • Re: NTA and identifying a flow related to scans/DDoS attacks

              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.



              Loop1 Systems: SolarWinds Training and Professional Services

              1 of 1 people found this helpful
                • Re: NTA and identifying a flow related to scans/DDoS attacks
                  johnny ringo

                  @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!

                    • Re: NTA and identifying a flow related to scans/DDoS attacks



                      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.


                      1 of 1 people found this helpful
                    • Re: NTA and identifying a flow related to scans/DDoS attacks

                      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.

                        • Re: NTA and identifying a flow related to scans/DDoS attacks
                          johnny ringo

                          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.