Re: FreeBSD listen()

[fygrave () SCORPIONS NET (CyberPsychotic)]

~:   - effectivly proxy ftp transfers are denied, since the source IP is not
~:     the one of the client but the one of the remote ftp server
~:   - you'd get problems when using ftp bouncers or ftp bounce networks
~:     (such as bnc4all http://bnc4all.ftp4all.de/, redirect4all or the
~:     rftpd bouncer)
~:   - it might confuse load balancing application layer gateways
~:   - RFC 959 doesn't mention source IP checking anywhere, therefore it
~:     would be a doubtable selfmade addon

You always have to find compromise between convenience and security. This
seem to be the one of such cases. OpenBSD natively shipped ftp daemon
has been including such checks (among the others) since 2.4 if not
earlier, and I haven't seen much complains about it. On the same note,
rfc0959 places several other recommendations, which leaves your ftp daemon
opened wide to  bounces/scans and other possible abuses, f.e:
                        "...  The user may want a file dumped on a TAC
      line printer or retrieved from a third party host.  In the latter
      case, the user-PI sets up control connections with both
      server-PI's.  One server is then told (by an FTP command) to
      "listen" for a connection which the other will initiate.  The
      user-PI sends one server-PI a PORT command indicating the data
      port of the other.  Finally, both are sent the appropriate
      transfer commands."

~:On the other hand random ports choosen by the server violate the RFC, too:
~:"Every FTP implementation must support the use of the default data ports,
~:and only the USER-PI can initiate a change to non-default ports."
~:

 I believe this is refereed to active mode, if the user-pi didn't specify
`non-default' ports with `PORT' and again is compromise to security (one
could just sit and wait when you bind your default port to abuse it).

Randomly choosen ports on server side will require an attacker to perform
ports-can before pulling any connects, or pull non-blocking connects on
whole port-range, and select() those which would succeed, this will in
most cases give the real client enough chances to connect to the data port
first. Still `enough chances' doesn't mean we are secure here of course.

 D. J. Bernstein <djb () CR YP TO> writes:

~:> If you only wish to accept one connection, only call 'accept' once.

~:You're missing the point. Several connections may already have been
~:accepted by the operating system before you ever call accept(). The
~:desired behavior is for the client's connection to be rejected if it's
~:not going to be the one that you obtain from accept().

But this doesn't solve the problem either. Of course if client gets
`connection refused' on his attempt to connect to server-specified data
port, no {RETR,STORE} will be issued, and no data will be transfered,
but now it just turns in plain denial of service. Assuming there's a
quick way for the attacker to find out the port number and establish
the connection to port, before the client does so, attacker would
just go into endless loop connecting to these ports to disrupt passive
ftp service completely.