Re: weird scans from port 80

From: Kasper Dupont (kasperd@daimi.au.dk)
Date: 01/23/03 

From: Kasper Dupont <kasperd@daimi.au.dk>
Date: Thu, 23 Jan 2003 16:36:01 +0100

Tim Haynes wrote:
>
> "Bill K." <bilkay@xxxlocalnet.com> writes:
>
> > In article <3E2ACF08.D4978104@daimi.au.dk>, "Kasper Dupont"
> > <kasperd@daimi.au.dk> wrote:
> >
> >> From RFC 793 page 36:
> >>
> >> As a general rule, reset (RST) must be sent whenever a segment arrives
> >> which apparently is not intended for the current connection.
> >
> > The next sentence reads: "A reset must not be sent if it is not clear that
> > this is the case."
>
> Incidentally, while we're passing by this appalling thread, what is `the
> current connection' supposed to mean in the context of a *NEW* packet??

You need to understand some of the philosophy behind TCP to
answer that question. At boot a computer has aproximately
2^64 connections all in the CLOSED state. Obviously they
cannot all be represented so connections in the CLOSED
state are simply not represented. In other words any
connection not in your table is in the CLOSED state. Every
connection has a fixed pair of peers all of them having
your IP as the local IP, but otherwise the 2^64 connections
have all possible combinations of local IP and remote IP,
port pair. If you have more than one local IP you have more
than 2^64 connections in the CLOSED state.

By opening a socket, binding it to a port, and listening
for connections, you move all the 2^48 possible connections
to the LISTEN state, but that those are represented by only
one entry in your table.

However the discussion are about connections in the CLOSED
state, and as noted previously all connections are initially
in the CLOSED state. In the CLOSED state no packet is
expected, thus no packet can be part of the current
connection. In other words any packet except from those with
a RST bit must be responded with a RST packet.

A connection cannot be moved out of the CLOSED state by a
packet being received. The only way to move a connection out
of the CLOSED state is by a local program beforming some
operation moving it to LISTEN or SYN-SENT state. (IIRC those
are the only two states you can move to from CLOSED.)

The standard does in fact allow multiple connections on the
same local IP:port pair as long as the remote IP:port pair
are different. But AFAIK actual implementations does only
make use of this on the server side. (I cannot see how the
BSD socket API would allow this to be done on the client
side.) The standard does also allow for simultaneously open
where both parties send SYN packets at the same time. That
is however rarely used (I don't know any software using it),
and I do not know if it is supported by Linux. 

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Relevant Pages

  • Re: weird scans from port 80
    ... > with a RST packet. ... > server which has clients with dynamic IP address. ... > How many open connections of this kind can the server ...
    (comp.os.linux.security)
  • Re: FreeBSD 7.0: sockets stuck in CLOSED state...
    ... CLOSED state reflecting a series of connections built by an application but then not properly discarded. ... Likewise, when the application is killed, all of the connections go away -- most likely because the file descriptors are all closed, allowing them to be garbage collected and connection state freed. ... If it is this sort of bug, then most likely you're missing a call to closein a work loop somewhere, and in some exceptional case, you fall out of the loop without calling close. ... Moreover, i've seen that closereports EBADF, but due to the insane amount of connections I can not say for certain that that's when the connection goes into CLOSED state. ...
    (freebsd-net)
  • Re: FreeBSD 7.0: sockets stuck in CLOSED state...
    ... Also one other thing that I've noticed, is that it's always the input buffer that has bytes left; ... Moreover, i've seen that closereports EBADF, but due to the insane amount of connections I can not say for certain that that's when the connection goes into CLOSED state. ... Once you have some data collected for tcbs you know end up in the unexpected CLOSED state, have a look at the relevant fields in the SIFTR log file and let us know what you find. ...
    (freebsd-net)
  • Re: ipfw limit src-addr woes
    ... a packet is not dropped on a condition that fails a skipto test. ... Just do a "skipto" when there's a> state entry and that's it. ... And that's why the counter grows for> established connections too, even though there's a "setup" modifier. ...
    (freebsd-net)
  • Re: ipfw limit src-addr woes
    ... a packet is not dropped on a condition that fails a skipto test. ... Just do a "skipto" when there's a> state entry and that's it. ... And that's why the counter grows for> established connections too, even though there's a "setup" modifier. ...
    (freebsd-questions)