Odd behaviour of Argus server.
Carter Bullard
cbullard at nortelnetworks.com
Fri May 12 10:58:57 EDT 2000
Hey Russell,
Hmmmm, so we have 2 argi that differ basically because
one is using '-d'. One generates a huge amount of data
that references a subset of network events, for an extended
period of time, to the exclusion of reporting other network
events, and then recovers. The other doesn't express any
of this behavior?
All of this seems very strange/interesting. Not an
infinite loop, but rather some kind of event that
messes with the internal hashing and flow tracking
queues. That would be weird. What did Argi #2 think was
going on during this period? Pretty standard stuff? Any
of the same stuff?
You did mention that there was other traffic that was
being reported by Argi #1, during the problem period.
Did Argi #2 also report these same flows?
Did it appear that Argi#1 just lost one-half of all
the flows?
This is a difficult problem, because we don't
really know what was being presented to Argi #1 to know
if argus() had a problem or if it was something else.
Is it possible that the 'attack' could have caused a
problem?
One thing I would like to know is, "are the last times
reported for the problem flows also the same?" Use
'ra -l' to get the last times, instead of the start times.
This may reveal something interesting.
Carter
> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> Sent: Friday, May 12, 2000 1:22 AM
> To: argus at lists.andrew.cmu.edu
> Subject: Odd behaviour of Argus server.
>
>
> Greetings,
> A couple of days ago we had a strange incident where one
> address in our address space was targeted for what looked like udp
> scans from 12 different IP addresses (all in .edu sites and most in
> resnets or dorms). The 'attack', if that is what it was lasted 10
> minutes and was detected by a perl script that watches 'ra -S
> localhost'.
>
> That was odd enough but the argus server kept repeatedly
> reporting the
> traffic and failed to report real traffic for the next 4
> hours and then
> carried on normally as if nothing had happened.
>
> The argus server in question logs the traffic via -w <file> and this
> file is mv'ed on the hour and run through raconnections and gzip.
> Both the ra that was listening to the server via a socket and the log
> files show the repeated traffic (time stamps are the same).
>
> I have two argus servers, the one that had this problem which
> incidentally runs without the -d option and another on
> another machine
> that runs with -d 60. This argus server reported the initial
> 10 minute
> burst of traffic and nothing else for that address.
>
> The files written by the problem server for the next four hours are
> nearly identical containing the udp traffic to the 'attacked' address
> and a handful (50 - few 100) other udp session and only a few tcp
> session fragments (lone SYN or FIN) or icmp traffic (port unreachables
> from the target host) - nearly all of these bore timestamps around the
> 'attack'.
>
>
> Here is the end of the file in which the 'attack' was first detected,
> The 'attack' started at 16:19 and continued until 16:27 according to
> the other argus server. You can see all the URP generated by the
> 'attack'.
>
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 152.16.242.51 1 0 udp_port 16556 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 141.219.85.236 1 0 udp_port 2678 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 141.219.85.236 1 0 udp_port 8824 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 141.219.85.236 1 0 udp_port 23620 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 131.123.57.92 1 0 udp_port 19225 URP
> 10 May 00 16:22:26 tcp 161.142.78.81.60753 o>
> 130.216.1.7.80 1 0 0 0 s
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 129.120.228.193 1 0 udp_port 20050 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 129.120.228.193 1 0 udp_port 22448 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 152.16.227.51 1 0 udp_port 28975 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 129.120.228.193 1 0 udp_port 31042 URP
> 10 May 00 16:22:26 icmp 130.216.11.148 ->
> 152.16.227.51 1 0 udp_port 1971 URP
> 10 May 00 16:22:26 tcp 208.210.86.12.4353 o
> 130.216.191.1.25 0 1 0 0 S
>
>
> What ever caused the problem it righted itself after 4 hours.
>
> Here is where things return to relative normality:
>
> 10 May 00 16:22:27 udp 129.120.228.193.1460 ->
> 130.216.11.148.23344 1 0 12 0 TIM
> 10 May 00 16:22:27 udp 207.62.155.108.1690 ->
> 130.216.11.148.27941 1 0 12 0 TIM
> 10 May 00 16:22:27 udp 129.120.228.193.1460 ->
> 130.216.11.148.3334 1 0 12 0 TIM
> 10 May 00 16:22:27 udp 207.62.155.108.1690 ->
> 130.216.11.148.25976 1 0 12 0 TIM
> 10 May 00 16:22:27 udp 152.16.227.51.2114 ->
> 130.216.11.148.7340 1 0 12 0 TIM
> 10 May 00 16:22:27 udp 207.62.155.108.1690 ->
> 130.216.11.148.27995 1 0 12 0 TIM
> 10 May 00 16:22:27 udp 129.120.228.193.1460 ->
> 130.216.11.148.28979 1 0 12 0 TIM
> 10 May 00 16:22:27 tcp 203.97.74.108.1072 ?>
> 202.37.88.17.80 1 0 0 0 E
> 10 May 00 16:22:27 udp 207.62.155.108.1690 ->
> 130.216.11.148.19383 1 0 12 0 TIM
> 10 May 00 16:22:31 udp 198.82.113.192.1950 ->
> 130.216.11.148.23647 1 0 12 0 TIM
> 10 May 00 16:26:40 *M tcp 130.216.191.6.119 <o>
> 203.97.37.7.38154 1368 2091 26784 1130548 E
> 10 May 00 16:32:26 tcp 202.180.93.168.1250 ?>
> 130.216.35.202.80 1 0 0 0 E
> 10 May 00 16:36:02 tcp 130.216.191.6.8080 ?>
> 130.123.128.4.3895 1 0 0 0 F
> 10 May 00 19:59:17 tcp 130.216.208.107.1148 ?>
> 207.188.7.24.80 1 0 0 0 F
> 10 May 00 20:38:22 * tcp 203.109.255.220.1480 <|
> 130.216.3.5.80 74 87 4674 38678 ER
> 10 May 00 20:38:22 d tcp 130.216.1.235.2478 <->
> 130.216.1.238.561 42884 44464 0 6284760 E
> 10 May 00 20:38:22 tcp 130.216.191.46.4381 <o>
> 203.109.252.4.80 10 9 0 0 E
> 10 May 00 20:38:22 tcp 130.216.191.46.4980 ->
> 209.185.152.104.80 4 2 0 1075 EFC
> 10 May 00 20:38:22 d tcp 203.109.195.115.1249 |>
> 130.216.3.20.80 2 3 0 0 sSER
> 10 May 00 20:38:22 tcp 130.216.1.7.80 ?>
> 203.96.111.202.6135 1 0 0 0 E
> 10 May 00 20:38:22 tcp 210.55.151.77.1472 |>
> 130.216.1.7.83 4 2 419 292 EFR
>
> Any ideas on what caused this or further tests I can perform on the
> remains. The ls -l of the files clearly shows the affected files:
>
> ls -l data/2000.05.10
> total 31911
> -rw-r--r-- 1 argus argus 935587 May 10 01:02
> argus-2000.05.10.00.00.gz
> -rw-r--r-- 1 argus argus 728068 May 10 02:00
> argus-2000.05.10.01.00.gz
> -rw-r--r-- 1 argus argus 526557 May 10 03:00
> argus-2000.05.10.02.00.gz
> -rw-r--r-- 1 argus argus 462354 May 10 04:00
> argus-2000.05.10.03.00.gz
> -rw-r--r-- 1 argus argus 449681 May 10 05:00
> argus-2000.05.10.04.00.gz
> -rw-r--r-- 1 argus argus 473947 May 10 06:00
> argus-2000.05.10.05.00.gz
> -rw-r--r-- 1 argus argus 483933 May 10 07:00
> argus-2000.05.10.06.00.gz
> -rw-r--r-- 1 argus argus 962268 May 10 08:00
> argus-2000.05.10.07.00.gz
> -rw-r--r-- 1 argus argus 1881503 May 10 09:02
> argus-2000.05.10.08.00.gz
> -rw-r--r-- 1 argus argus 2411654 May 10 10:04
> argus-2000.05.10.09.00.gz
> -rw-r--r-- 1 argus argus 2584735 May 10 11:05
> argus-2000.05.10.10.00.gz
> -rw-r--r-- 1 argus argus 2699908 May 10 12:06
> argus-2000.05.10.11.00.gz
> -rw-r--r-- 1 argus argus 2641171 May 10 13:06
> argus-2000.05.10.12.00.gz
> -rw-r--r-- 1 argus argus 2801275 May 10 14:06
> argus-2000.05.10.13.00.gz
> -rw-r--r-- 1 argus argus 2829599 May 10 15:05
> argus-2000.05.10.14.00.gz
> -rw-r--r-- 1 argus argus 2811024 May 10 16:06
> argus-2000.05.10.15.00.gz
> -rw-r--r-- 1 argus argus 1073073 May 10 17:03
> argus-2000.05.10.16.00.gz
> -rw-r--r-- 1 argus argus 226262 May 10 18:01
> argus-2000.05.10.17.00.gz <---
> -rw-r--r-- 1 argus argus 287259 May 10 19:01
> argus-2000.05.10.18.00.gz <---
> -rw-r--r-- 1 argus argus 284027 May 10 20:01
> argus-2000.05.10.19.00.gz <---
> -rw-r--r-- 1 argus argus 931625 May 10 21:01
> argus-2000.05.10.20.00.gz <---
> -rw-r--r-- 1 argus argus 1570734 May 10 22:02
> argus-2000.05.10.21.00.gz
> -rw-r--r-- 1 argus argus 1351584 May 10 23:01
> argus-2000.05.10.22.00.gz
> -rw-r--r-- 1 argus argus 1093697 May 11 00:01
> argus-2000.05.10.23.00.gz
>
> They also show that we don't have a high bandwidth connection ;-)
>
> Cheers, Russell.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20000512/e1413e1f/attachment.html>
More information about the argus
mailing list