• Choose a category
• All
• Classic-Fiction

22315, 3306, 2244 ### 22315=200.216.205.189

This certainly looks like a port sweeper. Indeed, the graph shown in Figure 14-7 illustrates that the 200.216.205.189 source IP address connected to port 3306 on many destination addresses in the 11.11.0.0/16 subnet (we restrict the next graph to just the source IP address 200.216.205.189 in bold below):

# psad -m iptables.data --gnuplot --CSV-fields "dst dp:3306,count" --CSV-regex "SRC=

200.216.205.189" --gnuplot-graph points --gnuplot-yrange 0:150 --gnuplot-file-prefix

fig14-7

$ gnuplot fig14-7.gnu

The graph in Figure 14-7 shows the number of packets (on the y-axis) sent by the IP address 200.216.205.189 to TCP port 3306 for each destination IP address (on the x-axis). A total of 24 destination addresses were involved in the port sweep, and on some systems over 120 packets were sent to port 3306.

Figure 14-7. MySQL 3306 port sweep

Another way to visualize the above information is to use AfterGlow to generate a link graph. Such a graph contains the source and destination IP addresses in a viewable format and shows the series of packets from the source IP address 200.216.205.189 to several destinations in the 11.11.0.0/16 subnet:

# psad -m iptables.data --CSV --CSV-fields "src:200.216.205.189 dst dp:3306" --CSV-

max 6 | perl afterglow.pl -c color.nf | neato -Tpng -o fig14-8.png

The psad interface to AfterGlow produces the link graph shown in Figure 14-8. (See the --CSV-max argument to psad in bold above, which is used to limit the number of data points to six, for readability.)

Figure 14-8. Link graph of MySQL port sweep

Slammer Worm

The Slammer (or Sapphire) worm was one of the fastest-spreading worms in history. It exploited a stack overflow vulnerability in Microsoft SQL Server 2000 and was delivered in a single 404-byte UDP packet (including the IP header) to port 1434.

The Slammer worm can easily be identified in your iptables log data as a packet to UDP port 1434 and an IP LEN field of 404. The psad signature set includes the PSAD-CUSTOM Slammer communication attempt signature to alert you when the worm hits one of your systems. Let's see if the Slammer worm was active against the honeynet from external sources:

# psad -m iptables.data --gnuplot --CSV-fields "timestamp dp:1434,counthour" --gnuplot

-graph lines --gnuplot-xrange 1140887484:1143867180 --CSV-regex "LEN=404.*PROTO=UDP"

--CSV-neg-regex "SRC=11.11." --gnuplot-file-prefix fig14-9

$ gnuplot fig14-9.gnu

Gnuplot produces the line graph shown in Figure 14-9. (Note the LEN=404 criterion in the --CSV-regex command-line argument in bold above; this is critical because there are other UDP packets to port 1434 logged in the Scan34 data set, but they are not from the Slammer worm because the total packet length is not 404 bytes.)

Figure 14-9. Slammer worm packet counts by the hour

Indeed, the Slammer worm was active against the honeynet, and the large spike on March 20 shows a peak activity of about 57 packets per hour.

This is a significant amount of activity, but what happens when we change the time scale? Let's ratchet the time scale up to see what the Slammer activity was minute by minute (note the use of the countmin option on the psad command this time):

# psad -m iptables.data --gnuplot --CSV-fields "timestamp dp:1434,countmin"

--gnuplot-graph lines --gnuplot-xrange 1140887484:1143867180 --CSV-regex "LEN=404.

*PROTO=UDP"

--CSV-neg-regex "SRC=11.11." --gnuplot-file-prefix fig14-10

$ gnuplot fig14-10.gnu

Now the Slammer worm activity, shown in Figure 14-10, doesn't look quite as bad as the sharp spike in Figure 14-9, but this is just because the time scale has changed. The number of packets from systems infected with the Slammer worm did not change, but on March 21 a maximum of four packets is established for the entire five-week period covered by the Scan34 challenge.

Figure 14-10. Slammer worm packet counts by the minute

Nachi Worm

The Nachi