Re: scan log

[Valdis.Kletnieks () VT EDU (Valdis Kletnieks)]

On Tue, 13 Jun 2000 10:03:00 +1200, Russell Fulton <r.fulton () AUCKLAND AC NZ>  said:
> 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

Amen brother. ;)

I'm not convinced that an FTP 'MGET *' isn't to blame here.   Remember
that the FTP 'PORT' stuff works backwards from what you'd expect -
*you* tell the *server* what port of yours to connect to.  You send it
a port, and the FTP server connects back from its 20 to the port
you specified.

Now, if there was conclusive proof that nobody was running FTP on
mordor, it would be a different story. ;)

> 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

Hmm.. Somebody doesn't use HTTP/1.1 'persistent' connections? ;)

> 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).

RFC793, section 3.5 specifically says:
  Case 1:  Local user initiates the close

    In this case, a FIN segment can be constructed and placed on the
    outgoing segment queue.  No further SENDs from the user will be
    accepted by the TCP, and it enters the FIN-WAIT-1 state.  RECEIVEs
    are allowed in this state.  All segments preceding and including FIN
    will be retransmitted until acknowledged.  When the other TCP has

It's not "a combination of stacks".  You get into this state *any*
time you're trying to tear down a TCP connection, and the remote
end isn't producing an ACK for your FIN.  The reason you "frequently"
see this is because you can get to CLOSE of a connection because a
previous segment got back an ICMP Host Unreachable.  So the most
probable scenario is:

1) User clicks on a URL, and starts fetching the stuff for the web page.
2) Your server starts sending the bits down the pipe.
3) Modem burp.  The terminal server or router tosses a Host Unreachable.
4) You close, and send a FIN.  It of course goes into the bit bucket.
5) You retransmit, and THAT goes bit bucket too, because the guy
just reconnected and got DHCP'ed to a different IP.
5a) If somebody ELSE gets the IP via DHCP, you might see a NAK of your FIN. ;)

If you're RECEIVING the FIN, and know your modem didn't burp, go back
to (3) and write in "BGP routing flap/router crash" instead, and reverse
the senses of "You" and "them". ;)

And as above, if you know you weren't poking the webserver at aaa.bbb.ccc.ddd,
look for other explanations. ;)

                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech