On Tue, 13 Jun 2000 10:03:00 +1200, Russell Fulton <r.fulton_at_AUCKLAND.AC.NZ> said:
> On Sun, 11 Jun 2000 22:30:31 -0500 Max Gribov <mgribov_at_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
Received on Jun 15 2000
Intro
