Section 4 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4

     You need to let your clients open new connections to the outside world
     on ports 1024 and above.

Again, if your firewall understands FTP, none of the four points above apply
to you. Let the firewall do the job for you.

C.7 What software uses what FTP mode?

  It is up to the client to decide what mode to use; the default mode when a
new connection is opened is ``active mode''.

Most FTP clients come preconfigured to use active mode, but provide an
option to use ``passive'' (``PASV'') mode. An exception is the windows
command line FTP client which only operates in active mode.

Web Browsers generally use passive mode when connecting via FTP, with a
weird exception: MSIE 5 will use active FTP when FTP:ing in ``File
Explorer'' mode and passive FTP when FTP:ing in ``Web Page'' mode. There is
no reason whatsoever for this behaviour; my guess is that someone in Redmond
with no knowledge of FTP decided that ``Of course we'll use active mode when
we're in file explorer mode, since that looks more active than a web page''.
Go figure.

C.8 Is my firewall trying to connect outside?

  My firewall logs are telling me that my web server is trying to connect
from port 80 to ports above 1024 on the outside. What is this?!

If you are seeing dropped packets from port 80 on your web server (or from
port 25 on your mail server) to high ports on the outside, they usually DO
NOT mean that your web server is trying to connect somewhere.

They are the result of the firewall timing out a connection, and seeing the
server retransmitting old responses (or trying to close the connection) to
the client.

TCP connections always involve packets traveling in BOTH directions in the
connection.

If you are able to see the TCP flags in the dropped packets, you'll see that
the ACK flag is set but not the SYN flag, meaning that this is actually not
a new connection forming, but rather a response of a previously formed
connection.

Read point 8 below for an in-depth explanation of what happens when TCP
connections are formed (and closed)

C.9 The anatomy of a TCP connection

  TCP is equipped with 6 ``flags'', which may be ON or OFF. These flags are:

FIN
     ``Controlled'' connection close
SYN
     Open new connection
RST
     ``Immediate'' connection close
PSH
     Instruct receiver host to push the data up to the application rather
     than just queue it
ACK
     ``Acknowledge'' a previous packet
URG
     ``Urgent'' data which needs to be processed immediately

In this example, your client is 5.6.7.8, and the port assigned to you
dynamically is 1049. The server is 1.2.3.4, port 80.

You begin the connection attempt:

5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON

The server receives this packet and understands that someone wants to form a
new connection. A response is sent:

1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON

The client receives the response, and informs that the response is received

5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON

Here, the connection is opened. This is called a three-way handshake. Its
purpose is to verify to BOTH hosts that they have a working connection
between them.

The internet being what it is, unreliable and flooded, there are provisions
to compensate for packet loss.

If the client sends out the initial SYN without receiving a SYN+ACK within a
few seconds, it'll resend the SYN.

If the server sends out the SYN+ACK without receiving an ACK in a few
seconds, it'll resend the SYN+ACK packet.

The latter is actually the reason that SYN flooding works so well. If you
send out SYN packets from lots of different ports, this will tie up a lot of
resources on the server. If you also refuse to respond to the returned
SYN+ACK packets, the server will KEEP these connections for a long time,
resending the SYN+ACK packets. Some servers will not accept new connections
while there are enough connections currently forming; this is why SYN
flooding works.

All packets transmitted in either direction after the three-way handshake
will have the ACK bit set. Stateless packet filters make use of this in the
so called ``established'' filters: They will only let packets through that
have the ACK bit set. This way, no packet may pass through in a certain
direction that could form a new connection. Typically, you don't allow
outside hosts to open new connections to inside hosts by requiring the ACK
bit set on these packets.

When the time has come to close the connection, there are two ways of doing
it: Using the FIN flag, or using the RST flag. Using FIN flags, both
implementations are required to send out FIN flags to indicate that they
want to close the connection, and then send out acknowledgements to these
FINs, indicating that they understood that the other end wants to close the
connection. When sending out RST's, the connection is closed forcefully, and
you don't really get an indication of whether the other end understood your
reset order, or that it has in fact received all data that you sent to it.

The FIN way of closing the connection also exposes you to a
denial-of-service situation, since the TCP stack needs to remember the
closed connection for a fairly long time, in case the other end hasn't
received one of the FIN packets.

If sufficiently many connections are opened and closed, you may end up
having ``closed'' connections in all your connection slots. This way, you
wouldn't be able to dynamically allocate more connections, seeing that
they're all used. Different OSes handle this situation differently.

References

1    Steven M. Bellovin.
     Firewall-friendly FTP.
     RFC 1579.

2    R. Finlayson.
     Ip multicast and firewalls.
     RFC 2588, May 1999.

3    Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear.
     Address allocation for private internets.
     RFC 1918, February 1996.

4    R. Thayer, N. Doraswamy, and R. Glenn.
     IP Security Document Roadmap.
     RFC 2411, November 1998.

Section 4 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4

© allanswers.org | Terms of use