Archive for the ‘Session’ Category

Grace - XY plotting tool

Saturday, April 5th, 2008

I have collected packets of a DDOS attack on one machine recently. It is just pure SYN attack to destination port 80, with over 5000 packets from different IP in 1 second. I try to create a graph with this packet by using Grace, a WYSIWYG 2D plotting tool for the X Window System and M*tif. Grace runs on practically any version of Unix-like OS. As well, it has been successfully ported to VMS, OS/2, and Win9*/NT/2000/XP.

First, I used Argus client - ra to show unidirectional RMON stat, with only source port and destination port selected, piped it to awk to make it readable data by Grace, and then convert the number for destination port. For example, X=0, Y=2224 (source port), then X=1, Y=80 (destination port):

[[email protected] /]# ra -nr syn.argus -M rmon -s sport | awk '{ print 0,$1 }' | sed -e 's/0 80/1 80/g' > syn.dat

The output of syn.dat looks like this:

[[email protected] /]# head -n 6 syn.dat
0 2224
1 80
0 2236
1 80
0 2242
1 80

Then use grace to plot it.

[[email protected] /]# xmgrace6 syn.dat &

This is the graph of 23 seconds DDOS from source port to destination port.
DDOS Ports Grace Graph

If I use afterglow to show the connection from source to destination port, the graph looks like this.
DDOS Ports Afterglow Graph

This is the graph after I converted the source and destination IP to decimal, for example, from 192.168.1.123 to 3232235899.
DDOS IP Grace Graph

1 second source port to destination port graph, approximate 5000 SYN per second:
DDOS Ports Grace 1 Second Graph

From the port graph, I guess the DDOS was launched from 1 host with spoofed source IP and large bandwidth pipe, what do you think?

Argus to check traffic spike

Saturday, March 8th, 2008

When I checked my Ourmon graph today, I noticed same spike happened at the same time in 2 days.
Usually I don’t really pay attention if there is little spike in the nighttime, but it is not normal when it happened continuously at the same time in 2 days.

Late night traffic spike

Since I have full network traffic log, I converted the tcpdump traffic to Argus flow.

 [[email protected] /nsmdir/2008-03-08]# argus -r snort.log.time -w argus.out 

The traffic spike was neither generated from port 25 nor port 80, I used racluster to merge the status records from the same flow without traffic of port 25 and 80, then piped to rasort to sort (-m) the total count of the packet transaction. -s option is to select and show the fields you want to print, -L0 is used to show the labels. Here is the result:

[[email protected] /nsmdir/2008-03-08]# racluster -nnr argus.out -w - - not port 80 and not port 25 | rasort -nnr - -m pkts -s +1ltime +load +bytes +rate -L0 | less

        StartTime           LastTime    	 Flgs   Proto            SrcAddr  Sport    Dir       DstAddr  Dport     TotPkts   TotBytes       State     Load   TotBytes         Rate
   03:27:47.764771    03:33:46.183595  e sD        6     192.168.134.56.39448     ->     10.2.3.102.46743   2501219 1031277512   FIN 23018378 1031277512  6978.480957
   03:33:46.708627    03:37:43.800844  e sD        6     192.168.134.56.40071     ->     10.2.3.102.16396    526755  543955768   FIN 18354234  543955768  2221.730469
   03:31:51.398870    03:33:15.015036  e sD        6     192.168.134.56.39880     ->     10.2.3.102.32666    212332  219148920   FIN 20967134  219148920  2539.365479
   03:21:43.412374    03:41:50.372550  e sD        6       192.168.200.77.4105    < ? >  10.2.3.102.38327     68916   56532894   CON 374712.5   56532894    57.098816

10.2.3.102 is one of the hosts in my network, so from the packet count and total bytes information, I could identify the spike was generated by which host. You may sort based on other criterias to get the result you want, as there might be flows from different IP with little packet count, with large bandwidth transfer rate (load).

To check the traffic, I used ra to show the flow:

[[email protected] /nsmdir/2008-03-08]# ra -nnr argus.out -L0 - host 192.168.134.56 | less

         StartTime    Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  TotPkts   TotBytes State
   03:27:46.938889  e           6     192.168.134.56.39446     ->     10.2.3.102.21           16       1464   CON
   03:27:47.537244  e           6     192.168.134.56.39447     ->     10.2.3.102.21           22       1964   CON
   03:27:47.764771  e s         6     192.168.134.56.39448     ->     10.2.3.102.46743     36705   15095192   CON
   03:27:52.764922  e sD        6     192.168.134.56.39448     ->     10.2.3.102.46743     30281   12522592   CON
   03:27:57.765092  e iD        6     192.168.134.56.39448     ->     10.2.3.102.46743     14032    5782634   CON
   03:28:02.765262  e sD        6     192.168.134.56.39448     ->     10.2.3.102.46743     41270   17023976   CON

This seems like a passive FTP transfer for me (by checking the src ports), so I logged on to server to check for the FTP log to verify:

Mar  8 03:33:10 server ftpd: ([email protected]@192.168.134.56) [NOTICE] /home/xxx/public_html/mm//xxx.com_2008.03.08_03-31-02 uploaded  (207309250 bytes, 2444.40KB/sec)
Mar  8 03:33:42 server ftpd: ([email protected]@192.168.134.56) [NOTICE] /home/xxx/backup//xxx.com_2008.03.08_03-21-02 uploaded  (891289600 bytes, 2428.22KB/sec)
Mar  8 03:37:39 server ftpd: ([email protected]@192.168.134.56) [NOTICE] /home/xxx/backup//xxx.com_2008.03.08_03-21-02.001 uploaded  (514473734 bytes, 2121.01KB/sec)

The log information explains all. There was a new job which was setup recently, running at every 3.30 AM to transfer the backup files to host 10.2.3.102.

I do have traffic grapher to check which ports generated the spike but that is another story which is not worth for a blog post.