Re: scan log

[r.fulton () AUCKLAND AC NZ (Russell Fulton)]

On Sun, 11 Jun 2000 22:30:31 -0500 Max Gribov <mgribov () KPLAB COM> wrote:

> this are logs of a port scan i have recently received on one of my
> machines. i searched for those ports in all known port databases to me,
> but couldnt find anything. why would someone scan that specific range
> (observe the precise inrementation) of ports on a linux machine?
>
> Jun 11 22:20:21 mordor scanlogd: From 209.3.31.70:20 to 151.202.106.23
> ports 2632, 2633, 2634, 2635, 2636, 2637, 2638, 2639, 2640, ..., flags
> ??r??u, TOS 00, TTL 60, started at 22:20:13

Are you sure this is a scan?  My scan detection software see patterns
like this several times a day.  Since my system is based on argus I can
go back and dump out the traffic context and I usually find that what
we have is a bunch of short web or ftp session.

uuu.xxx.yyy.zzz.2632 -> aaa.bbb.ccc.ddd.80
uuu.xxx.uuu.xxx.2633 -> aaa.bbb.ccc.ddd.80
uuu.xxx.uuu.xxx.2634 -> aaa.bbb.ccc.ddd.80
uuu.xxx.uuu.xxx.2635 -> aaa.bbb.ccc.ddd.80
uuu.xxx.uuu.xxx.2636 -> aaa.bbb.ccc.ddd.80
uuu.xxx.uuu.xxx.2637 -> aaa.bbb.ccc.ddd.80
uuu.xxx.uuu.xxx.2638 -> aaa.bbb.ccc.ddd.80

Now some combinations of client and server tcp stacks result in untidy
session termination and I frequently see things like this:

aaa.bbb.ccc.ddd.80 -> uuu.xxx.yyy.zzz.2632  FIN
aaa.bbb.ccc.ddd.80 -> uuu.xxx.yyy.zzz.2633  FIN
aaa.bbb.ccc.ddd.80 -> uuu.xxx.yyy.zzz.2634  FIN
aaa.bbb.ccc.ddd.80 -> uuu.xxx.yyy.zzz.2635  FIN
aaa.bbb.ccc.ddd.80 -> uuu.xxx.yyy.zzz.2636  FIN
aaa.bbb.ccc.ddd.80 -> uuu.xxx.yyy.zzz.2637  FIN
aaa.bbb.ccc.ddd.80 -> uuu.xxx.yyy.zzz.2638  FIN

up to two minutes after the tcp sessions have closed.  This looks just
like a FIN scan to scan detection software but in fact is the server
still trying to shut down the sessions.  (I suspect that some load
balancing software is responsible for this sort of behaviour).

I now ignore most short scans to consecutive high numbered ports.

What it boils down to is that you can not say very much about such
incidents without the context of the traffic in which they occur.

Cheers, Russell

Russell Fulton, Computer and Network Security Officer
The University of Auckland, New Zealand