Analyzing Distributed Denial Of Service Tools The Shaft Case

Analyzing Distributed Denial Of Service Tools: The Shaft Case Sven Dietrich –NASA Goddard Space Flight CenterNeil Long –Oxford UniversityDavid Dittrich –University of WashingtonABSTRACTIn t his paper we present an analysis of Shaft , an example of malware used in dist ribut ed denial of service (DDoS) attacks. This relatively recent occurrence combines well-known denial of service a t t acks (such as TCP SYN flood, smurf, and UDP flood) wi t h a dis t ribu t ed and coordinated approach to create a powerful program, capable of slowing network communications to a grinding halt.Denial of service at t ack programs,root kits ,and net work sniffers have been around in t he comput er underground for a very long t ime. They have not gained nearly t he same level of a en ion by he general public as did he Morris Internet Worm of 1988, bu have slowly progressed in t heir development . As more and more syst ems have come t o be required for business, research, educat ion, t he basic funct ioning of government , and now ent ert ainment and commerce from people’s homes, t he increasingly large number of vulnerable sys tems has converged wit h t he development of t hese t ools t o creat e a sit uat ion t hat result ed in dist ribut ed denial of service attacks that took down the largest e-commerce and media sites on the Internet.In contrast, we provide a comparative analysis of several distributed denial of service tools(e.g., Trinoo, TFN, Stacheldraht, and Mstream), look at emerging countermeasures against someof these tools. We look at practical examples of these techniques, provide some examples from test environments and finally talk about future trends of these distributed tools.IntroductionNet work-based at t acks are not hing new,but up t o last year t he t echniques ut ilized were focused on simple point -t o-point denial of service. By denial of service we mean overwhelming the victim host or net-work to the point of unresponsiveness to the legitimate user.We provide a little overview,by no means com-plete, of previous point-to-point denial of service tech-niques. There are four major poin t -to-poin t tech-niques: TCP SYN flooding, UDP flooding, ICMP flooding, and Smurf attacks. The first one misbehaves from t he st andard t hree-way TCP handshake causing resource consump ion and bandwid h consump ion,whereas t he remaining ones int end t o consume t he vict im’s bandwidt h.The year 1999 saw an emergence of new denial of service tools. The change was inevi t able: t he growt h of net work pipes made simple point -t o-point tools either useless, or the improved tracking capabili-ties easily shut down the source of the problem. Even though some solutions or at least containment methods exist for the above, the distributed variants as an evo-lut ion of coordinat ed many-t o-one at t acks escape t he traditional model sufficiently.Rather than relying on a single source, at t ackers could now t ake advant age of some hundred, t housand, even t en t housand or more systems to inflict denial of service onto their victims.AnalysisThe DDoS Network ModelA Distributed Denial of Service Network follows a hierarchical model, with one or more attackers con-trolling a so-called handler ,which in turn controls the hordes of agents that execute the commands relayed to them.The communication between the attacker and the handler,and bet ween t he handler and t he agent s is referred to as the control traffic of t he ne twork,whereas t he communicat ion bet ween t he agent s and t he vict ims is referred t o as t he flood traffic .Cont rol t raffic can be TCP,UDP,ICMP,or a combinat ion of the three. Flood traffic consists of traffic generated by each individual point -t o-point denial of service t ech-nique, or sometimes a combination thereof.In order to remove himself from view,the attacker introduces additional layers between the vic-tim host(s) and himself. He can access the handler via a variet y of mechanisms, t he most popular being a simple telnet .More sophisticated tools use, or can take advan tage of, more advanced techniques, such as encrypt ed TCP connect ions (ssh is a possibilit y for TFN, blowfish-encryp ed proprie ary as in S achel-draht ) or non-st andard met hods such as embedding commands in ICMP or UDP packets (e.g., LOKI [22,23] or Q). Additional care is taken to protect the han-dler,as it is the key control point and effectively theAnalyzing Distributed Denial Of Service Tools: The Shaft Case Dietrich, Long, & Dittrichanonymizer of the network. So as to eliminate a single point of failure, more t han one handler is found in pract ice, and in most cases each handler has equal power over its agents.The agents are controlled from the handler,often using a different pro t ocol t han the one in effec tbetween attacker and handler.It is speculated that this is done t o evade correlat ion. The communicat ion is not necessarily bidirectional, as there have been cases of oblivious t ransfers. Inst ruct ed by t he at t acker,t he handler can cont rol t he numerous agent s t o perform the attacks by proxy.As we will see, some DDoS tools provide a clear overview of t he DDoS net work, e.g.,enabling t o det ermine t he st at us and performance of each individual agent.Figure 1:A typical DDoS network FindingsShaft was init ially det ect ed t hrough anomalous net work act ivit y.Wit h t he help of t he net work ana-lyzer Argus [1], spikes (see Figure 2) in t he packet flows led t o t he discovery of t he shaftnode agent on t he compromised syst em wit hin t he local net work. It was one of about 100 nodes in a Shaft DDoS network.The successful retrieval of an attack binary,the shaftn-ode agent, and eventually its source, permitted a thor-ough analysis of its functionality.Since t he shaftmaster handler was not ret rieved unt il four mont hs lat er,it t ook simulat ion, t horough analysis of Argus [1] logs and a pinch of creativity to reconstruct the functionality of this attack tool. Simu-lat ion and analysis t ools such as t he Unix debugging t ool strace ,and disassembly of binaries are the main contributors to the understanding of munication FeaturesAs a first st ep, it was import ant t o ident ify t he network communication aspect of Shaft. Shaft (in the analyzed version, 1.72) is modeled aft er Trinoo [11],in that communication between handlers and agents is achieved using t he unreliable IP prot ocol UDP.See St evens [29] for an ext ensive discussion of t he TCP and UDP protocols. Remote control is established viaa simple t elnet connect ion t o t he handler.Shaft uses tickets for keeping t rack of t he t ransact ions issued t o its individual agents. Both passwords and ticket num-bers have t o ma t ch fort he agen t t o execu t e t he request . A simple let er-shift ing (Caesar cipher,see Schneier [27]) is in mand StructureNext , analyzing t he command st ruct ure of t he tool provided additional understanding of the capabili-t ies of Shaft. Using available source and t he simple Unix command strings ,we est ablished t he command synt ax of bot h t he agent and t he handler.It provided insight into the capabilities of the handler that was not apparent from the agent source.A full listing of both he agen and handler commands can be found in Appendix 1 and 2, respectively.Figure 2:Spikes in network activity.DetectionBrief Description of Installation MethodsAs with previous DDoS tools, the methods used t o ins t all t he handler/agen t will be t he same as inst alling any program on a compromised Unix sys-t em, wit h all t he st andard opt ions for concealing t he programs and files (e.g., use of hidden directories,root kits ,kernel modules, et c.). The reader is referred t o Dit t rich’s Trinoo analysis [11] for a description of pos-sible installation methods of this type of tool.Further findings [32] have revealed that the Shaft DDoS t ools were indeed used in conjunct ion wit h a root kit ,an inet d-based (inet d is t he Unix server t hat handles most incoming connections such as telnet and ftp) trojan, a trojaned secure shell (SSH) daemon, and a set of Unix shell script s t o aut omat ically dist ribut e the tools out to the individual agent systems. The pre-sent inetd-based trojan has been known to exist in the wild as early as May 1999.The distribution Unix shell script (from [32]), as sent with netcat [19] to the trojaned system, is as fol-lows:#!/bin/shecho "oir##t"echo "QUIT"sleep 5echo "cd /tmp"Dietrich, Long, & DittrichAnalyzing Distributed Denial Of Service Tools: The Shaft Casesleep 5echo "rcp user@host:shaftnode ./"sleep 5echo "chmod +x shaftnode"sleep 5echo "./shaftnode"echo "exit"This shell script inst alls t he shaft node agent on t he syst em, by performing a remot e copy from a reposi-tory host into the /tmp directory,making it executable and launching it. The reader is referred t o [32] for a complet e discussion of t he inst allat ion, t rojaning and rootkit-ing of the handler host.Time Pro t ocol Src IP/Port Flow Ds t IP/Port21:39:22 tcp z.z.z.z.53982↔x.x.x.x.2121:39:32 t cp x.x.x.x.1023→y.y.y.y.51421:39:56 udp x.x.x.x.33198→z.z.z.z.2043321:45:20 udp z.z.z.z.1765→x.x.x.x.1875321:45:20 udp x.x.x.x.33199→z.z.z.z.2043321:45:59 udp z.z.z.z.1866→x.x.x.x.1875321:45:59 udp x.x.x.x.33200→z.z.z.z.2043321:45:59 udp z.z.z.z.1968→x.x.x.x.1875321:45:59 udp z.z.z.z.1046→x.x.x.x.1875321:45:59 udp z.z.z.z.1147→x.x.x.x.1875321:45:59 udp z.z.z.z.1248→x.x.x.x.1875321:45:59 udp z.z.z.z.1451→x.x.x.x.1875321:46:00 udp x.x.x.x.33201→z.z.z.z.2043321:46:00 udp x.x.x.x.33202→z.z.z.z.2043321:46:01 udp x.x.x.x.33203→z.z.z.z.2043321:48:37 udp z.z.z.z.1037→x.x.x.x.1875321:48:37 udp z.z.z.z.1239→x.x.x.x.1875321:48:37 udp z.z.z.z.1340→x.x.x.x.1875321:48:37 udp z.z.z.z.1442→x.x.x.x.1875321:48:38 udp x.x.x.x.33204→z.z.z.z.2043321:48:38 udp x.x.x.x.33205→z.z.z.z.2043321:48:38 udp x.x.x.x.33206→z.z.z.z.2043321:48:56 udp z.z.z.z.1644→x.x.x.x.1875321:48:56 udp x.x.x.x.33207→z.z.z.z.2043321:49:59 udp x.x.x.x.33208→z.z.z.z.2043321:50:00 udp x.x.x.x.33209→z.z.z.z.2043321:50:14 udp z.z.z.z.1747→x.x.x.x.1875321:50:14 udp x.x.x.x.33210→z.z.z.z.20433Table 1:Compromise flow on Nov 28.Algorithmic Overview of AttacksUpon launch, t he shaft agent (t he ‘‘shaft node’’)reports back to its default handler (its ‘‘shaft mast er ’’)by sending a ‘‘new <upshifted password>’’command,which regist ers t he new agent in t he pool of agent s available t o t he handler.For t he default password of ‘‘shift ’’found in t he analyzed code, t his would be ‘‘t ijgu’’. Therefore a new agent would send out ‘‘new tijgu’’, and all subsequent messages would carry that password in it. Only in one case does the agent shift in he opposi e direc ion for one par icular command,e.g., ‘‘pkt res rghes’’. While it was init ially unclear whether this was a mistake, a more thorough analysisof the shaftmaster revealed that both shifts were used in an attempt to evade analysis.Incoming commands arrive as space separat ed items: command, upshifted password, command argu-ment , socket number,t icket , and opt ional argument s,which can be represented as the message flow diagram between handler H and agent A:1. A →H: "new", f(password)2. H →A: cmd, f(password), [args], Na, Nb3. A →H: cmdrep, f(password), Na, Nb, [args]4. Jump to step 2.•f(X) is the Caesar cipher function on X•Na, Nb are numbers (tickets, socket numbers)•cmd, cmdrep are commands and command acknowledgmen t s•args are command argumentsThe flooding occurs in bursts of 100 packets per host, with the source port and source address random-ized. This number is hard-coded, but it is believed that more flexibility can be added. Whereas the source port spoofing only works if the agent is running as a root privileged process, the author has added provisions for packet flooding using the UDP protocol and with the correct source address in the case the process is run-ning as a simple user process. It is noteworthy that therandom funct ion is notproperly seeded, which mayAnalyzing Distributed Denial Of Service Tools: The Shaft Case Dietrich, Long, & Dittrich lead t o predict able source port sequences and sourcehost IP sequences.The source port is generated with (R mod(65535-1024)+1024) where R is he ou pu of he rand() function. This will generate source ports greater than 1024 at all times.The source IP is of the form R1.R2.R3.R4 where R1, R2, R3, R4 are the outputs of rand()mod255. The source IP numbers can (and will) contain a zero in the leading octet.Additionally,the sequence number for all TCP packe s is fixed, namely 0x28374839, which helps wit h respect t o det ect ion at t he net work level.The ACK and URGENT flags are randomly set, except on some platforms.Destination ports for TCP and UDP packet floods are randomized.The client must choose t he durat ion (‘‘t ime’’), size of packets, and type of packet flooding directed at t he vict im host s. Each set of host s has it s own dura-tion, which gets divided evenly across all hosts. This is unlike TFN [6] which forks an individual process for each victim host.For the type, the client can select UDP,TCP SYN, ICMP packet flooding, or the combi-nation of all three. Even though there is potential for having a different type and packet size for each set of vict im host s, t his feat ure is not exploit ed in t his ver-sion.When a general command is issued, it is sent to all hosts listed in a hidden file containing all the Shaft agent s, in general wit h a t imeout of 30 seconds. To dat e, no mechanism t o alt er t hat t imeout has been found. Some commands have longer t imeout s, up t o 300 seconds. A list of outstanding tickets (transactions wait ing t o complet e) is available t o t he at t acker wit h the ‘‘ltic’’command, which lists the ticket number and it s corresponding remaining t ime. The at acker can visually correlate the ticket number to the actual com-mand by scrolling back in his screen buffer and com-paring the number that was printed after the execution of t he command, similar t o seeing a process id dis-played when sending a process into the background on a Unix system.The aut hor of Shaft seems t o have a part icular interest in statistics, namely packet generation rates of its individual agents. The statistics on packet genera-t ion rat es are possibly used t o det ermine t he ‘‘yield’’of t he DDoS net work as a whole. This would allow the attacker to stop adding hosts to the attack network when it reached t he necessary size t o overwhelm t he vict im net work, and t o know when it is necessary t o add more agents to compensate for loss of agents due to attrition during an attack (as the agent systems are identified and taken off-line).Packet Flow AnalysisIn this section we will look at a practical exam-ple of an attack carried out with the Shaft distributed denial of service attack tool, as seen from the attack-ing network perspective.The handler is list ening on port 20433, and an exis ing connec ion on por 20432 is awai ing he commands of t he at t acker.The packet flow is illus-trated in Table 1.There is quite some activity between the handler andhe agen, as hey go hrough he command request and acknowledgement phases. There was also what appeared to be testing of the impact on the local network itself with, among others, UDP packet flood-ing against the broadcast address (first 2-3 spikes), fol-lowed by ICMP flooding as shown in Figure 2. See Figure 3 for a fine-grained view.Figure3:28Nov 1999 floods 21:00-23:00. The interesting portion is the first three lines. It shows he penet rat ion from t he handler (z.z.z.z) using t he inetd-based trojan with source port 53982 and destina-tion port21 (any inetd related portwould have worked), t he download of t he shaft node binary from y.y.y.y via rcp (remote copy,port 514), and the regis-tration of the shaftnode agent with its shaftmaster han-dler.The theory that these were the traces of the pene-tration was confirmed by findings [32] on the handler host. The ten second delay between the packet on port 21 and the remote copy on port 514 is consistent with he scrip men ioned in he sec ion on ins alla ion methods. Later that night, the attacker performed sev-eral at tacks (three UDP and one combination TCP/UDP/ICMP) in order t o t est t he Shaft net work furt her,as illust rat ed in Figure 4. Let us look at t he individual phases from a lat er at t ack aft er it became possible to record the packet contents, as well as gen-eral flow dat a, subsequent t o a det erminat ion of t he agent, handler and communication ports. Subse-quently,the handler cont inued t o send such packet s even though the agent had been disabled and the host integrity recovered.This is illustrated in Table 2.Dietrich, Long, & Dittrich Analyzing Distributed Denial Of Service Tools: The Shaft CaseFigure4:Further testing 29 Nov 1999 02:00-07:00.ime flow command18:06:40 Z→X alive tijgu hi 5 817018:09:14 Z→X ime tijgu 700 5 643718:09:14 X→Z ime tijgu 5 6437 70018:09:16 Z→X size tijgu 4096 5 871718:09:16 X→Z size tijgu 5 8717 409618:09:23 Z→X ype tijgu 2 5 9003Table 2:Setup and configuration phase on Dec 4. ime flow command18:09:24 Z→X own tijgu a.a.a.a 5 525618:09:24 X→Z owning tijgu 5 5256 a.a.a.a 18:09:24 Z→X pktres tijgu a.a.a.a 5 1993 18:09:24 Z→X own tijgu b.b.b.b 5 7818:09:24 Z→X pktres tijgu j.j.j.j 5 884518:09:24 Z→X own tijgu c.c.c.c 5 624718:09:25 Z→X own tijgu d.d.d.d 5 419018:09:25 Z→X own tijgu e.e.e.e 5 237618:09:25 X→Z owning tijgu 5 78 b.b.b.b18:09:26 X→Z owning tijgu 5 6247 c.c.c.c 18:09:27 X→Z owning tijgu 5 4190 d.d.d.d 18:09:28 X→Z owning tijgu 5 2376 e.e.e.e 18:21:04 X→Z pktres rghes 5 1993 51600 18:21:04 X→Z pktres rghes 0 0 5140018:21:07 X→Z pktres rghes 0 0 5150018:21:07 X→Z pktres rghes 0 0 5140018:21:07 X→Z pktres rghes 0 0 51400Table 3:Host list and statistics.The handler issues an ‘‘alive’’command, and says ‘‘hi’’t o it s agent, assigning a socket number of ‘‘5’’and a ticket number of 8170. We will see that this ‘‘socket number’’ will persist throughout this attack. A t ime period of 700 seconds is assigned t o t he agent, which is acknowledged. A packet size of 4096 bytes is specified, which is again confirmed. The last line indi-cates the type of attack, in this case ‘‘the works’’, i.e., UDP,TCP SYN and ICMP packet flooding combined. Failure o specify he ype would make he agen default to UDP packet flooding.Now t he list of host s t o at t ack and which ones they want statistics from on completion, as shown in Table 3.To prot ect t he ident it y of t he vict ims, t he hosts IP number have been replaced with a.a.a.a through j.j.j.j.t ime flow command18:24:25 Z→X own tijgu e.e.e.e 5 449318:25:53 Z→X own tijgu b.b.b.b 5 939218:27:05 Z→X own tijgu a.a.a.a 5 308518:27:06 X→Z owning tijgu 5 3085 a.a.a.a 18:33:52 Z→X own tijgu c.c.c.c 5 187818:33:53 X→Z owning tijgu 5 1878 c.c.c.c 18:36:04 X→Z pktres rghes 0 0 10410018:36:20 Z→X pktres tijgu a.a.a.a 5 1511 18:36:21 X→Z owning tijgu 5 1754 a.a.a.a 18:37:33 X→Z pktres rghes 0 0 8170018:38:13 Z→X own tijgu f.f.f.f 5 312618:38:13 Z→X pktres tijgu f.f.f.f 5 469718:38:14 X→Z owning tijgu 5 3126 f.f.f.f 18:38:47 X→Z pktres rghes 5 151176600 18:39:15 Z→X own tijgu g.g.g.g 5 427218:39:16 X→Z owning tijgu 5 4272 g.g.g.g 18:39:41 Z→X own tijgu c.c.c.c 5 885018:39:41 Z→X pktres tijgu c.c.c.c 5 9924 18:40:43 Z→X own tijgu c.c.c.c 5 267218:41:25 X→Z owning tijgu 5 5195 h.h.h.h 18:45:33 X→Z pktres rghes 5 9924 53700 18:48:01 X→Z pktres rghes 0 0 4880018:49:54 X→Z pktres rghes 5 4697 45700 18:50:56 X→Z pktres rghes 0 0 4490018:51:22 X→Z pktres rghes 0 0 4570018:53:04 X→Z pktres rghes 0 0 6370018:54:47 Z→X own tijgu i.i.i.i 5 208618:54:47 Z→X pktres tijgu i.i.i.i 5 698018:54:47 X→Z owning tijgu 5 2086 i.i.i.i 19:06:27 X→Z pktres rghes 5 6980 241200Table 4:More hosts and statistics.Now that all other parameters are set, the handler issues several ‘‘own’’commands, in effect specifying the victim hosts. Those commands are acknowledged by t he agent wit h an ‘‘owning’’reply.The flooding occurs as soon as the first victim host gets added. The handler also requests packet statistics from the agents for cert ain vict im host s (e.g., ‘‘pkt res t ijgu a.a.a.a 5 1993’’). Note that the reply comes back with the same ident ifiers (‘‘5 1993’’) at t he end of t he 700 second packet flood, indicat ing t hat 51600 set s of packet s were sent. One should realize t hat, if successful, t his means 51600 x 3 packets due to the configuration of all three (UDP,TCP,and ICMP) types of packets.In turn, this results in roughly 220 4096 byte packets per second per host, or about 900 kilobytes per second perAnalyzing Distributed Denial Of Service Tools: The Shaft Case Dietrich, Long, & Dittrichvictim host from this agent alone, about 4.5 megabytes per second t ot al for t his lit t le exercise.A graphical view can be seen inhe firs por ion (minu es 1through 12) of Figure 5.Figure 5:4Dec 1999 floods.Note the reverse shift (‘‘shift’’becomes ‘‘rghes’’,rat her t han ‘‘t ijgu’’) for t he password on t he packet statistics. Continuing on with the attack, as shown in Table 4, the attacker selects new targets in a staggered manner,but still keeping the established settings of the 700 second combina ion ype a ack of 4096 by e packet s. The yields of t he at t ack vary from roughly 800 kilobytes per second per host in a multi-target set-ting to 4.2 megabytes per second per host in a single target set t ing (Target I). The st aggered approach can be observed in the right two thirds of Figure 5 (min-utes 14 through 50).Cryptographic AspectsShaf t incorpora t ed several no t ewor t hy t ech-niques for keeping informat ion secret. For one, t helet er-shift ing or Caesar cipher,was applied severalimes wit hin t his t ool. As described previously,he transaction password ‘‘shift’’was shifted by one letter upwards to generate the string ‘‘tijgu’’observed on thenet work. However,a different shift in t he opposit edirect ion generat ed ‘‘rghes’’for t he ret urn st at ist ics.While the author(s) of this program did not encrypt the ent ire message exchange bet ween handler and agent ,t hey did nevert heless obfu scate t he real st rings, such as applying the shift to the handler IP numbers in the binary and also t he port numbers in t he case of a ‘‘swit ch’’command, namely by adding an offset to the real port number.As wit h t he original Trinoo t ool, t he Shaft han-dler cont ained 13-charact er st rings, st rangely resem-bling Unix crypt () out put. Through close analysis of t he handler code, it was est ablished t hat t hey repre-sented the access passwords to the control port of the program, that is where the attacker would connect to and perform t he dist ribut ed denial of service from a convenient, but not quite menu-driven, command line.The ac ual passwords were recovered in a similar fashion o he ones from Trinoo and S acheldrah ,except that the above shifts had to be performed on the ciphertext first.Similar to the handler settings in earlier tools, the author of Shaft attempts to keep the list of its agents in a non-trivial format. Other tools encrypt that list using Blowfish, but this tool packs the four octets of the IP number into a 4-byte integer and writes the ASCII rep-resentation of that number to a file, one per line. For example, adding t he agent wit h IP address 127.0.0.1using ‘‘+node 127.0.0.1’’would yield a line cont ain-ing ‘‘16777343’’, which is:127 × 2560+0×2561+0×2562+1×2563.In order t o ext ract t he IP numbers from t he list , one would apply the reverse transformation.Anomaly DetectionThe network flooding which took place was ini-tially noticed after a cursory glance at the hourly net-work flow data files recorded using an Argus [1] mon-itor at the main Internet connection point. Without anysuch monitoring the activities would have almost cer-tainly gone unnoticed since the floods took place over t he Sunday-Monday nigh t .O ther IDS recordsDietrich, Long, & Dittrich Analyzing Distributed Denial Of Service Tools: The Shaft Caseindicated a possible UDP portscan had taken place butfor host IPs not possible on the local net blocks.For example, t he t ypical argus dat a file at t hat time of day (night) would be 4Mbytes but these grew t o bet ween 40 and 100Mbyt es. Analyzing such large data files takes significant effort and resources (hence t he hourly rot at ion) but it was possible t o det ermine the start time of the rapid rise in connections and then tracing the external connection (handler) and internal flooder (agent ) becomes a mat t er for t rial and error and some measure of good fortune. In this instance the first guess was used to contact the host administrator who was able t o locat e t he process st ill left running (al hough inac ive), ob ain an lsof [18] ou pu and recover residual files and logs.Reducing the data for the hourly flows down to somet hing suit able for graphical display was compli-cat ed by t he very large number of dat a point s which overwhelms most of the standard graphing or statisti-cal packages.O t her t raffic moni t oring applica t ions which might have indicated that an unusually large network flow had occurred would not usually have an accurate time nor could have been used to trace the external →internal communications channel correspondence. For example snmp monitoring of packet numbers is a pop-ular me hod. Accumula ed by e coun s per sub-ne (host , port , et c) could also have been obt ained using NeTraMet [5] but again t his would have been inade-quate for the post event analysis.Impact of Victim Hosts/networksThe effect of the combined outpouring of packets has already been considered from the point of view of the target victim but it should be noted that very little legit imat e t raffic was able t o move over t he Int ernet gat eway while t he flood t ook place. This secondary denial of service would be of major significance dur-ing normal working hours and when combined wit h several such agent s dist ribut ed around one sit e can lead to saturation of the essential backbone infrastruc-ture and routers.Impact on network – given the time of day it had lit t le or no impact apart from slowing ext ernal port scanners (!) – maybe it is worth noting that on typical asynchronous ATM ext ernal connect ions t here would be an impact on outgoing verus incoming. The impact of one host running flat out will be a lot less than sev-eral hos t s running as agen t s. Delibera t ely limi t ing agents to one per site would have considerable bene-fit s when it comes t o avoiding det ect ions while st ill retaining effective DoS of the target(s).Secondary EffectsPoor DNS response (if any) – even problems managing ne twork devices during the peaks. The flurry of ‘‘response’’packets caused by the floods can crea e addi ional complica ions wi hin he ne work.Due to the ‘‘inband-signalling’’nature of TCP/IP,the control messages related to network management must travel over the very same congested network.NIDS vs. Active ScanningNetwork Intrusion Detection Systems (NIDS)During very high (near saturation) flows almost no event of any kind would be logged by an IDS sys-tem – they would either have to drop packets at a very high rat e or require mult i-CPU archit ect ures in order to combine packet collection and packet state analysis.As pipe capaci ies con inue o grow (Gigabi , e c)here will be serious difficul ies for ne work flow monitors such as Argus to keep up based on the typi-cal PC architecture (there is seldom a budget available for a top end machine which will, hopefully,be wast-ing cycles 99 % of the time waiting for such events).Passive ScanningFor t he purpose of det ect ing malicious act ivit y,cert ain feat ures of t he whole DDoS package have t o be considered and provide clues for passive scanning of such event s. This program does not provide for code updat es (like TFN or St acheldraht ). This may imply ‘‘rcp’’or ‘‘ft p’’connect ions during t he init ial int rusion phase (see also [11]). As found in [32], t he int ruders used ‘‘rcp’’in t heir dist ribut ion script s, but this could easily be altered.The program uses UDP traffic for its communi-cation between the handlers and the agents. Consider-ing t hat t he t raffic is notencrypt ed, it can easily be det ect ed based on cert ain keywords. Performing an ‘‘ngrep’’[20] for the keywords mentioned in the syn-tax sections (Appendix 1 and 2), will locate the con-t rol t raffic, and looking for TCP packe t s wi t h sequence numbers of 0x28374839 (decimal 674711609) may locat e t he TCP SYN packet flood raffic. The lat t er t raffic can be det ect ed t hrough it s secondary effect of causing SYN|ACK and RST|ACK traffic wit h sequence numbers of 0x2837483a (deci-mal 674711610), as point ed out by Richard Bejt lich (who has been wit nessing t hese effect s – wit h t his same sequence number – for well over a year [3]).Source por s of he flood raffic are always above 1024, and source IP numbers can include zeroes in the leading octet.Strings in this control traffic can be detected with the ‘‘ngrep’’program using the same technique shown in [11, 12, 13]. Here are some examples t hat will locate the control traffic between the handler and the agent, independently of the port number used.#ngrep -i -x "alive tijgu" udpU 192.168.10.1:4001 -> 192.168.10.2:1875361 6c 69 76 65 20 74 69alive ti 6a 67 75 20 68 69 20 35jgu hi 520 38 36 34 31 0a 8641.U 192.168.0.2:1494 -> 192.168.0.1:2043361 6c 69 76 65 20 74 69alive ti 6a 67 75 20 35 20 38 36jgu 5 8634 31 20 62 6c 61 6841 blah。