Security Incidents mailing list archives
Unusual scan pattern
From: r.fulton () AUCKLAND AC NZ (Russell Fulton)
Date: Wed, 19 Jan 2000 13:57:47 +1300
HI folks,
I have not seen this type of scan before so I am forwarding the
argus logs for others to examine.
Below are logs as recorded by argus on our DMZ outside our packet
filter.
For those of you who are familiar with argus and are wondering why
thing look a bit different, that's because I have patched ra to
display the date in an unambiguous format and I have changed the
status display at the end of the record to include all tcp state
information not just the final state:
s is SYN sent
S syn+ack seen
E established (i.e. we have seen something that looks like a data
packet)
R RST sent or received (look at the <> to see which way it went)
F FINWait state
C Close state
i.e a 'normal' tcp session looks like 'sSEFC'.
Here is the log of one session, there were several similar sessions
directed against different machines (or groups of machine). 130.216/16
is our address block, 130.216.1.1 is our primary DNS and 130.216.1.4
is our mail host and backup DNS.
date time proto source dest packets bytes status
to fr to fr
09 Jan 00 11:05:43 tcp 133.74.6.1.23 <| 130.216.1.1.23 1 1 0 0 ER
09 Jan 00 11:05:43 tcp 133.74.6.1.23 <| 130.216.1.4.23 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.25 <| 130.216.1.4.25 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.25 <| 130.216.1.1.25 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.143 <| 130.216.1.1.143 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.143 <| 130.216.1.4.143 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.110 <| 130.216.1.4.110 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.110 <| 130.216.1.1.110 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.80 <| 130.216.1.1.80 1 1 0 0 ER
09 Jan 00 11:05:44 tcp 133.74.6.1.80 <| 130.216.1.4.80 1 1 0 0 ER
The E flag on these means that argus thought that the incoming packets were
part of an established tcp stream for which it had not seen the handshake
packets. Our hosts respond with a RST. Note source and destination ports
are the same -- Is this some form of tcp 'ping' designed to go through
packet filters?
09 Jan 00 11:05:44 tcp 133.74.6.1.16450 <| 130.216.1.1.80 1 1 0 0 sR
09 Jan 00 11:05:44 tcp 133.74.6.1.16460 -> 130.216.1.1.23 4 3 0 0 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16461 <| 130.216.1.1.143 1 1 0 0 sR
09 Jan 00 11:05:44 tcp 133.74.6.1.16462 <| 130.216.1.1.110 1 1 0 0 sR
They now try and get some tcp connections, telnet succeeds but tcp wrappers
kills the session.
09 Jan 00 11:05:44 s tcp 133.74.6.1.16463 -> 130.216.1.1.111 2 0 0 0 s
portmapper denied by packet filter
09 Jan 00 11:05:44 s tcp 133.74.6.1.16464 -> 130.216.1.1.2766 7 0 0 0 s
09 Jan 00 11:05:44 tcp 133.74.6.1.16465 -> 130.216.1.1.25 5 5 0 99 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16466 o> 130.216.1.1.21 4 3 0 0 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16467 -> 130.216.1.1.22 5 4 0 15 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16468 <| 130.216.1.1.1114 1 1 0 0 sR
09 Jan 00 11:05:44 tcp 133.74.6.1.16469 <| 130.216.1.1.1 1 1 0 0 sR
09 Jan 00 11:05:44 s tcp 133.74.6.1.16470 -> 130.216.1.1.515 7 0 0 0 s
09 Jan 00 11:05:44 tcp 133.74.6.1.16472 <| 130.216.1.4.80 1 1 0 0 sR
09 Jan 00 11:05:44 tcp 133.74.6.1.16473 -> 130.216.1.4.23 4 3 0 0 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16476 <| 130.216.1.4.143 1 1 0 0 sR
09 Jan 00 11:05:44 tcp 133.74.6.1.16477 <| 130.216.1.4.110 1 1 0 0 sR
09 Jan 00 11:05:44 s tcp 133.74.6.1.16478 -> 130.216.1.4.111 2 0 0 0 s
09 Jan 00 11:05:44 s tcp 133.74.6.1.16479 -> 130.216.1.4.2766 7 0 0 0 s
09 Jan 00 11:05:44 tcp 133.74.6.1.16480 o> 130.216.1.4.25 5 4 0 104 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16481 o> 130.216.1.4.21 4 3 0 0 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16482 -> 130.216.1.4.22 5 5 0 15 sSEF
09 Jan 00 11:05:44 tcp 133.74.6.1.16483 <| 130.216.1.4.1114 1 1 0 0 sR
09 Jan 00 11:05:44 tcp 133.74.6.1.16485 <| 130.216.1.4.1 1 1 0 0 sR
09 Jan 00 11:05:44 s tcp 133.74.6.1.16486 -> 130.216.1.4.515 7 0 0 0 s
more sessions that were denied either because of filter, tcpwrappers or
no server. time stamps suggest that this was done by a single script.
09 Jan 00 11:05:46 tcp 133.74.6.1.17448 -> 130.216.1.1.53 6 5 31 31 sSEFC
09 Jan 00 11:05:47 tcp 133.74.6.1.17449 -> 130.216.1.4.53 6 6 31 31 sSEFC
09 Jan 00 11:05:49 tcp 130.216.1.4.39666 -> 133.74.6.1.113 6 5 10 35 sSEFC
09 Jan 00 11:05:49 tcp 130.216.1.1.40323 -> 133.74.6.1.113 6 5 10 35 sSEFC
09 Jan 00 11:07:00 tcp 133.74.6.1.26712 -> 130.216.1.1.53 6 5 36 36 sSEFC
09 Jan 00 11:07:01 tcp 133.74.6.1.26716 -> 130.216.1.4.53 6 6 36 36 sSEFC
some complete dns sessions -- no we don't have logging turned on.
09 Jan 00 11:08:53 tcp 133.74.6.1.29708 <- 130.216.1.1.23 3 3 0 0 sS
09 Jan 00 11:08:57 tcp 133.74.6.1.2 ?> 130.216.1.1.23 1 0 0 0 F
09 Jan 00 11:08:57 tcp 133.74.6.1.2 ?> 130.216.1.4.23 1 0 0 0 F
09 Jan 00 11:08:57 tcp 133.74.6.1.4 |> 130.216.1.1.23 2 1 0 0 FR
09 Jan 00 11:08:57 tcp 133.74.6.1.5 ?> 130.216.1.1.23 1 0 0 0 E
09 Jan 00 11:08:57 tcp 133.74.6.1.4 |> 130.216.1.4.23 2 1 0 0 FR
09 Jan 00 11:08:57 tcp 133.74.6.1.5 ?> 130.216.1.4.23 1 0 0 0 E
09 Jan 00 11:08:57 tcp 130.216.1.1.23 |> 133.74.6.1.1 1 1 0 0 SR
09 Jan 00 11:08:57 tcp 130.216.1.4.23 |> 133.74.6.1.1 1 1 0 0 SR
09 Jan 00 11:08:57 tcp 133.74.6.1.3 <| 130.216.1.1.23 1 1 0 0 FR
09 Jan 00 11:08:57 tcp 133.74.6.1.3 <| 130.216.1.4.23 1 1 0 0 FR
09 Jan 00 11:09:02 tcp 133.74.6.1.30059 <| 130.216.1.4.1 1 1 0 0 sR
09 Jan 00 11:09:02 tcp 133.74.6.1.30064 <| 130.216.1.1.1 1 1 0 0 sR
more weird stuff; F's on their own or with FR suggest lone FIN packets.
09 Jan 00 11:09:03 tcp 133.74.6.1.995 o> 130.216.1.4.111 1 0 0 0 s
09 Jan 00 11:09:03 tcp 133.74.6.1.994 o> 130.216.1.1.111 1 0 0 0 s
09 Jan 00 11:28:34 tcp 133.74.6.1.11254 -> 130.216.1.4.53 6 5 32 32 sSEFC
09 Jan 00 11:28:35 tcp 133.74.6.1.11308 -> 130.216.1.1.53 6 5 32 32 sSEFC
09 Jan 00 11:28:50 tcp 133.74.6.1.12928 -> 130.216.1.4.53 6 6 34 34 sSEFC
09 Jan 00 11:28:52 tcp 133.74.6.1.12930 -> 130.216.1.1.53 6 6 34 34 sSEFC
09 Jan 00 11:47:37 tcp 133.74.6.1.8509 -> 130.216.1.1.53 6 5 31 31 sSEFC
09 Jan 00 11:47:38 tcp 133.74.6.1.8558 -> 130.216.1.4.53 6 6 31 31 sSEFC
It is possible that the DNS traffic was an attempt to exploit recent
BIND probles. The two sessions look very similiar but are not identical.
Our servers have been patched but, so far as I can tell don't log attemped
abuse.
What interests me is the initial tcp data packets which look as if
they have been crafted to go through firewalls (at least simple packet
filter types) and the artifical source port numbers.
Cheers, Russell.
Russell Fulton, Computer and Network Security Officer
The University of Auckland, New Zealand.
Current thread:
- Unusual scan pattern Russell Fulton (Jan 18)
- ANOTHER DNS MAC ADDRESS Change w/h Unix Log File Michael Vaughan (Jan 19)
- Re: ANOTHER DNS MAC ADDRESS Change w/h Unix Log File Cy Schubert - ITSD Open Systems Group (Jan 21)
- Re: ANOTHER DNS MAC ADDRESS Change w/h Unix Log File Ex Machina [xm] (Jan 21)
- Re: ANOTHER DNS MAC ADDRESS Change w/h Unix Log File CyberPsychotic (Jan 21)
- Re: ANOTHER DNS MAC ADDRESS Change w/h Unix Log File Dug Song (Jan 22)
- Re: Unusual scan pattern Granquist, Lamont (Jan 19)
- Slow scan Mixmaster (Jan 19)
- Re: Unusual scan pattern Richard Bejtlich (Jan 20)
- Re: Unusual scan pattern Kevin Houle (Jan 20)
- Re: Unusual scan pattern Russell Fulton (Jan 23)
(Thread continues...)
- ANOTHER DNS MAC ADDRESS Change w/h Unix Log File Michael Vaughan (Jan 19)