Transcription
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 2013Usage of Netflow in Security and Monitoring ofComputer NetworksShivam ChoudharyBhargav SrinivasanMIT ManipalMIT ManipalABSTRACTManagement of a network is a challenging task withoutaccurate traffic statistics. Through this paper thesecurity benefits of implementing a Netflow [1] basedanalysis system and then a novel open sourceapplication useful in Netflow analysis and managementof flow records is proposed. Netflow data providesimportant information about network conversations andbehavior. Netflow statistics are generated by Cisco andJuniper routers and switches, as well as server softwareNetflow probes. Netflow data provides enoughinformation to serve the needs of several differentapplications such as billing, network planning and mostimportantly traffic engineering, which we specificallyanalyze to assess the state of the network. The flowrecords are UDP packets lacking payload data whichstill provides enough data to the network administratorto be a valuable analysis tool. Netflow profiling is agood moderation which strikes a balance between detailand summary and provides a real-time analysis oftraffic flows, connection information and abnormalnetwork behavior. Netflow data on the router issampled at a variable rate which actually satisfies theconditions which have been set to monitor the incomingtraffic, and then compared periodically to test if anincoming sequence is a DOS or a possible threat to thenetwork by examining the packet sequences. Throughthis paper the performance of a network is gauged byusing a parameter called unexpectedness [2], which is amethod to gauge the amount of traffic flowing througha network.usage-based accounting i.e. a method of billingcustomers. Today, based in part upon market demandsfor performance and accounting, Netflow profiling isbuilt into networking devices. Although properstandards have not yet been established, Netflowmethodology is robust enough to persist through thisperiod of vendor-specific implementations, and itsbenefits and popularity in the industry warrant its earlyadoption.Table 1: Certain important fields encapsulated inthe flow records of a Netflow v5 packetGeneral TermsNetflow, Virtual Router, GNS3, Cisco Packet Tracer,BacktrackKeywordsNetflow, Cisco Packet Tracer, GNS3, Virtual Box, VirtualRouter, Unexpectedness, Decoding Netflow Packets.1. INTRODUCTIONNetflow [1] is a traffic profile monitoring technologydeveloped by Darren Kerr and Barry Bruins at CiscoSystems, back in 1996. Netflow data provides importantinformation about network conversations andbehaviour. Each unique flow is recorded by the networkdevices or probes, and the flows are then reported to adata collection server.The notion of Netflow [3] profiling was introducedwithin the networking research community, andsubsequently extended by other researchers, to monitorinternet traffic. Netflow profiling had been predicted tobe relevant to applications such as route caching andNetwork administrators who collect measurement dataoften find that they either have collected too little dataor too much of it. In a sense, Netflow profiling is a goodmoderation which strikes a balance between detail andsummary. The proposed method is network independentso it can adjust to the requirements of any kind ofnetwork. This type of data proves invaluable againstDoS (denial of service) attack and overloading of thenetwork. In this paper a system which can be effectivelyused to capture Netflow Data and can be used to extractcertain parameters from it is described so that a DoSattack can be detected and prevented.1.1 Netflow v5 Flow Record FormatAs described by Table 1, the Netflow v5 packetreceived can be decoded using a Perl script which wedesigned, with reference to certain previously designedmodules which effectively captures and separates thevarious fields. This script also logs the data which can17
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 2013then be used for further processing. An algorithmwhich can be used to design a system for processing thesampled flow data has been proposed.2. Outline of the SystemThe monitoring system comprises of a router which isconfigured to export Netflow information to a flowdatabase which is organized by a Perl script. The scriptthen stores the flow information in a separate file everyday and a separate folder for each month. The Netflowdata is then compared periodically to test if an incomingsequence is a DOS or a possible threat to the networkby examining the packet sequences that arrive throughthe router. This is clearly depicted in Figure 1.The monitoring station is a small machine that reads theexported flows and compares them to an existingmalicious packet sequence database. When a sequenceof malicious packets is matched and detected, then thesystem generates an alert status. This could then befurther analysed by network administrators to determinewhether the threat needs attention.The router is configured to store flow information, bythe user, and it transmits this information to a databasewhich is listening for it. In the proposed simulationcase, the router sends the Netflow v5 information in theform of UDP packets, through a specific port (2055 intest case), to a client which is listening on the sameport. Once the packets are received, Perl modules [4] areused which help decode the packet and extract flowinformation. The script reads the incoming UDPpackets and extracts the flow headers and the requiredflow records and stores the information in a log file. Adatabase is created using a Perl module which reiterateshis function periodically, forming new data logs on adaily, monthly and yearly basis while organizing themaccordingly.A small Perl snippet (figure 2) was created as requiredand it can be easily modified to provide efficientmethods of organization for the logged and preprocessed data. The records are indexed effectively andan optimal searching algorithm can be formulated toeffectively retrieve the required flow data. The availableNetflow data on the router is sampled at a variable rateof Z samples per second which corresponds to thecluster of packets that actually satisfy the conditionswhich have been set to monitor the incoming Netflowpackets, and only these ones will be allowed to enter theprocessing system, which will then perform a detailedanalysis of the incoming traffic and check for anyanomalies.As depicted through the flowcharts (figure 3), themonitoring system borrows from the database thevalues of previously identified attack patterns andsequences, which are simultaneously compared withincoming traffic. This system monitors traffic on portswhich are most susceptible to attacks. Effectively themonitoring system acts as an interface between twodatabases i.e. the collection database and the Threatdatabase.2.1 Monitoring StationThe role of the monitoring station is to judge whetherthe incoming traffic requires the attention and detailedthreat analysis using the system. The station is designedto segregate packets which flow into the processingmodule and those which are just sent for storage.Condition of Denial of Service (DOS) attacks ornetwork overloading can be established by evaluating ifeither one or more of the following signatures areobserved.2.1.1 Malicious Data PacketsThe following are the examples of how the “malicious”data packets can look like and how one can configurethe router to protect against the specific type of attack.Finally, at the end, methods consolidate all theprotection mechanisms into a single firewallconfiguration and use it to protect the system againstDOS attack is proposed.2.1.1.1 ARP poisoning:There may be improper configuration in the networkcausing broadcast storms and lot of ARP packets mightbe received by the router. Also, sometimes it is possiblethat a customer facing port receives lot of ARP requestand reply packets as part of a DOS attack. Thus asimple rate limit imposed on such packets can be aneffective prevention strategy.2.1.1.2 Packets with strange (Martian) addresses/strange IP options field:They commonly are sent by improperly configuredsystems on the network and have destination addressesthat are obviously invalid. Malformed packets such asthese are most likely crafted and are often part of DOSattacks. Hence a filter is set in order to check formartian IPs. IPs with options field enabled are notdetected by the router, hence an IP packet with toomany options can easily be used to fabricate a DOSattack. These types of packets are strictly monitored andfiltered to protect system resources from being depletedor misused.2.1.1.3 Malicious control plane packets:A router may be subject to DOS attacks by sendinglarge number of such packets which go up to the router.Such control packets generated by a DOS attacker willcontain either invalid information that will be discarded,or may even contain malicious information that cancause router’s forwarding information to get corrupted.18
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 2013Figure 1: Diagram showing the logical flow of packetsPerl program snippet to store Netflow in an organized manner. now time strftime "%Y%m%d", localtime; now month int( now time/100);if( now time! first time ! run) {# check if date (year,month,day) changedif( now month! first month ! run) { # if date changed check if month changed path 'd:\perl\logm' no '\log1.txt'; # create a new monthly table first month now month; no no 1;} path 'd:\perl\logm' no '\log' no2 '.txt'; # create table entries for today first time now time; run 1;# from now on we only check for the tables when the date changed no2 no2 1;}Figure 2: Perl Program to store the Netflow DataFigure 3: Flow Diagram showing storage and collection of Netflow Data RecordsControl plane packets are accepted only from wellknown peers and thus such a filter prevents injection ofrouting protocol PDUs into the network and hencetampering with the routing configuration.19
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 20132.1.1.4 Half open TCP ports (TCP SYN/RST,RST/FIN attacks):A very common DOS attack experienced by routers isthe TCP SYN/RST attack. Here a lot of malicious TCPSYN packets or RST packets are received by a router.Now, on receiving a TCP SYN packet, the system willattempt to complete a TCP 3- way handshake, and willqueue up the TCP SYN packets in its protocol controlblocks as pending connections. This leads to the portbeing half open and later become an unused port. Thisis one of the very popular methods for performing aDOS attack, and is preferred by most attackers or scriptkiddies. Similarly, when it receives a packet withRST/FIN, it will queue them up for processing and itleads to half open ports, resulting in a scenario similarto the one previously described. Thus a rate limitingsystem can be implemented to provide a check and thusaid in the prevention of such malicious activity.2.1.1.5 Flood of UDP/ICMP and other OAMpackets:An attacker usually tries to deplete all networkresources by flooding the system with ICMP pings ortrace routes or other types of OAM packets. Therefore arate limit has to be brought into effect, in order toprevent overloading. Other forms of injected packetsoverloading such as ftp, SNMP, ntp, DNS can also becapped.Figure 4 shows the proposed algorithm to tackle all theidiosyncrasies of the packets.3. Formulation of UnexpectednessThrough the simulations, the performance of a networkis gauged by using a parameter called unexpectedness[2],which is a method to gauge the amount of trafficflowing through a network. The value can then be usedto infer traffic deviation from pre-set 'normal'conditions, and hence the flow of traffic through thenetwork can be monitored and it provides theadministrator with a profound understanding of thenetwork's current state.The value of unexpectedness is a standardized value,which is network independent and can function as a toolto monitor the severity of overloading of the network.The value gives administrators a fair idea about thetraffic flowing through the network, and thus enablesappropriate judgement.3.1 Proposed AlgorithmIn the algorithm an extremely simple method based onthe available flow data to calculate the unexpectednessand it involves defining the following parameters,U Rate of sampling and storage of processed flowrecords at a variable rateLa Rate of incoming flow records (Flows/sec) at therouter in an “attack” scenarioLn Rate of incoming flow records (Flows/sec) at therouter in a “normal” scenarioLneff the effective rate of incoming flow records in a“normal” scenarioLaeff the effective rate of incoming flow records in an“attack” scenarioLneff U*(Ln/ (Ln La)) undernormal conditionsLaeff U*(La/ (Ln La)) underattack conditionsLet Ln 10 4; La 10 5; U 2·10 4 ;( we leave outthe units for better readability)We obtain Lneff 1.82 · 10 3 and Laeff 1.82·10 4Now, if the attack rate increases by 10% then L’a 1.1·10 5,The effective rates become L’neff 1.67·10 3 and L’aeff 1.83 · 10 4,i.e., the effective rate of attack flow records increasesby 0.83%,While the effective rate of normal flow recordsdecreases by 8.3%So, Unexpectedness L’aeff x 100% 83%.Hence this raises an alarm and prompts the networkadministrator to further investigate the issue.3.2 Result of the above formulationIn order to obtain the above calculations, we haveconsidered two scenarios a 'normal' scenario and an'attack' scenario. The 'normal' scenario entailscomputers to operate in a fully functional optimallyloaded state, which is considered as regular anduntampered behaviour which is carefully judged andpre-set by the administrators according to theirrequirements. The 'attack' scenario is characterized byall the systems overloading the network such that itemulates a denial of service attack or simply depletionof network resources. Hence the unexpectedness scalecan be obtained to monitor the network effectively andthis approach makes this system scalable to a very highextent.4. Simulation of the NetworkSimulation of the network was achieved using acomplete virtualization of the system, provided by thepopular network simulation tool GNS3. Using the IOS20
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 2013was simulated in GNS3. The two clouds C1 andrepresent two networks from Virtual Box.effectively two machines running in Virtual Boxconnected through a Virtual Router runningWindows.C2Soarein4.2 Storing the Netflow DataFigure 4: Flowchart illustrating a proposed algorithm forthe monitoring station.image of a Cisco 3620 series router the virtual testnetwork was created. We start by having two networksin which one is the administrator and his router ishaving Netflow enabled on it and the other is theattacker which is trying to attack the administrator’snetwork, and we have configured two virtual machinesto act as two independent hosts. The Backtrack R3 is apacket generation system and we have anotherBacktrack R3 which is the administrator’s network. Weare using Scapy [5] for packet crafting and transmissionbecause it gives us more control over how the packetmoves and more control over the various flags.4.1 Configuration of the NetworkThe network is configured in the following way,1) IP Address 10.1.5.100 (255.0.0.0) to the BacktrackAdministrator system.2) IP Address 192.168.44.1(255.255.255.0) to theBacktrack R3 packet injector System.A router can be used to connect these two networks byconfiguring it properly. The topology of the network isas shown below in figure 5. The following topologyNetflow is enabled on the virtual router and then theNetflow data is dumped into the UDP port number 2055of the admin machine (IP address 10.1.5.100). On thisport a Perl script is running and this script is used todecode the packets and arrange them properly inmonths, days, years so that the data packets are properlyarranged for future reference. The idea of the system isto analyse the Netflow data and then compare it withthe records and look for certain parameters in the dataso that an attack packet can be isolated and the networkis saved from further harm. Statistically it is seen thatan attacker or hacker never attacks all of a sudden. Theykeep on gathering information about a network forsome time using custom scanning techniques which canbe very discrete and cannot be prevented otherwise. Forexample if the network imposes a limit on the numberof ports to be scanned a clever work around can beusing an ever changing IP Address spoof and then keepon scanning the ports or a second and more crude waycould be having a script scanning few ports (well withinthe limits of the network) without ever being detected.4.3 Decoding of Netflow packetsThis is the central problem of which we are trying tofind a solution. So using Netflow all data packets arelogged on and details are extracted. So for example ifan attacker tries to attack the system still using differentIP addresses but the behaviour of the packets matches amalicious pattern in the database then he can be suitablytracked down and preventive measures can be taken. IfNetflow is enabled and the dump of the file is checkedthough we will get the file but we won’t be able todecode anything from the dumped data. So properdecoding of the data is required to get the informationfrom the Netflow packets. So in the system a decodingscript is running on the port 2055 (in simulation case ipaddress 10.1.5.100) that decodes the data and dumps itinto a text file. Figure 6 shows the Netflow data beingdumped on the port without any decoding. So as onecan infer from the figure it is gibberish and doesn’tmake any sense. But once the packets are properlydecoded very useful parameters can be extracted fromthese packets.21
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 2013Figure 5: The Topology of the NetworkFigure 6: Captured packet format by NetflowSo from Figure 6 it can be inferred clearly that decodingof these packets is required to get the information. So adecoding script is running on port number 2055.So anydata that gets dumped on port number 2055 is decodedand can be seen through the script.To enable Netflow Version 5 on the router standard IOScommands is used. Also the port number anddestination address to dump the UDP Netflow data is tobe specified while configuring the router. Figure 7clearly shows the router configuration. Just to check ifthe network is working properly it is pinged usingICMP packets. This result is summarized in Figure 8.From this it is obvious that the network is connectedand the router is aware of it. These ICMP22
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 2013Figure 7: Router Netflow Configurationpackets just ensure that the network is present and doesnot tell us any information about the network. It issimply an indication of presence of a host computer ona particular IP address. Many network administrators(such as that of Apple) disable this because theyunnecessarily engage the server with hello packets.Also if the identity of the server is to be restricted topublic then ICMP packets can be disabled on thenetwork.But in the test case network no Access Control List(ACL) is applied and no ports are blocked. So it can beseen clearly from figure 8 that one can easily ping thenetworks in the topology. Now Scapy [5] was used togenerate packets and then send the packets to theAdmin’s network. Now through the router each andevery packet will be captured and it will be dumpedonto the Admin’s side. So one can now have scriptsrunning to compare the data packets in the network.Furthermore the system is in very early stage of itsdevelopment and requires further research andimprovement. Filtering of packets can be implementedmore effectively using advanced techniques. Thecalculation of unexpectedness can be further improvedand also the fact that Netflow loses certain amount ofaccuracy compared to SNMP (Simple NetworkManagement Protocol) and TCP connection summaries,but it is a fair tradeoff in processing speeds, indexingcapabilities of the flow records.The methodology shows that the acquired Netflowsummaries provide invaluable insight of the actual stateof the network. Netflow is the weapon of choice fornetwork administrators if right aggregation technique isemployed.Figure 8: Ping Results of the NetworkAfter the data has been dumped it will be decoded andthen compared using another script to extract the detailsfor that packet. And then these details will be used todetermine whether the attack is happening or not.Figure 9 below shows those typical Netflow packets.5. ConclusionIn this paper we set out to gain insights into thecapabilities of Netflow. We can gain the same oradditional information from Netflow compared to othermeasurement techniques be it more detailed, such as ata packet level, or more brief. We propose an algorithmand present an implementation that is able to assess andprevent any threat risks for the network using Netflowdata.The implementation of the system can be effectivelysummarized as an independent real time sampling,aggregating and monitoring system. The versatility ofthe system lies in the fact that it can be used to properlygauge the possibility of a DoS attack or depletion ofresources using a scale based on formulating a standardvalue of unexpectedness.Figure 9: Netflow Data showing various protocolsand their flow rates23
International Journal of Computer Applications (0975 – 8887)Volume 68– No.24, April 2013[1] Cisco, Cisco IOS Net Flow Technology Data Sheet. http://www.cisco.com/go/netflow [4] Decoding Kobayashi, Atsushi. "CPAN RT." Net::Flow.Cpan.org, 2008. Web. 15 Dec. 2012. Brown, L. D., Hua,H., and Gao, C. 2003.[2] Vojtech Krmicek. GEANT3 JRA2 T4 InternalDeliverable. “Inspecting DNS Flow Trace for Purposesof Botnet Detection port scanning.” 2011. Paper[5] “Scapy”, an open source software for generating custompackets http://oss.netboxblue.com/pug/scapy.html .com/pug/scapy.html .6. REFERENCES[3] Cisco Systems Inc., “NetFlow Services and Applications-Whitepaper,” eflct/tech/napps wp.h%tm .[6] William Stallings, SNMP, SNMPv2, SNMPv3 andRMON 1 and 2, 1999.24
Netflow, Cisco Packet Tracer, GNS3, Virtual Box, Virtual Router, Unexpectedness, Decoding Netflow Packets. 1. INTRODUCTION Netflow [1] is a traffic profile monitoring technology developed by Darren Kerr and Barry Bruins at Cisco Systems, back in 1996. Netflow data provides importa
![Cisco NetFlow Configuration [Cisco NetFlow] - Cisco](/img/69/cisco-netflow-configuration.jpg)
