Security Incidents mailing list archives
Re: Unusual scan pattern
From: OFriedrichs () SECURITY-FOCUS COM (Oliver Friedrichs)
Date: Wed, 19 Jan 2000 14:09:15 -0800
I seem to recall someone mentioning to me once that Windows NT ends connections with an RST instead of a FIN. I don't have a sniffer handy or I would verify, so I don't know if this was true or not. - Oliver
-----Original Message----- From: Russell Fulton [mailto:r.fulton () AUCKLAND AC NZ] Sent: Tuesday, January 18, 2000 4:58 PM To: INCIDENTS () SECURITYFOCUS COM Subject: Unusual scan pattern 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:
- Re: ANOTHER DNS MAC ADDRESS Change w/h Unix Log File, (continued)
- 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)
- semi careful, very patient attacker Jon Paul, Nollmann (Jan 24)
- Re: Unusual scan pattern Oliver Friedrichs (Jan 19)
- Unknown Port Numbers Edwin Covert (Jan 21)