You are generally correct. However, port 20 is weird.
In regular FTP, the client connects to the server on port 21 (command). When
a data connection is needed, the client passes and IP and port to the server
via the PORT command. The server connects back to the client on the passed
IP/port but uses a source port of 20 - it doesn't connect to the client's
port 20. I'm not aware of any other protocol definition where the SOURCE
port of a new socket is specified. Your comment implies that the server
connects to the client's port 20 which is incorrect.
Packet level firewalls like this since it gives a fixed port on incoming
packets for ftp data - they don't need to be concerned about a floating port
(packet level firewalls don't like to remember previous traffic). In my
opinion, floating the source port is more secure and also largely eliminates
the "unable to create socket" messages you can get if the client system
reuses port numbers after a socket is disconnected. That is, its possible
for the new data connection to try to use the exact same IP/port
combinations on both sides while the previous connection is being broken
down which is illegal. This scenario occurs and is documented as a problem
with using port 20 in the original FTP RFC.
Application level firewalls generally don't have a problem with floating the
source port. Since they remember previous network traffic, they know which
temporary ports are open and how to validate them. However, because they
have to talk to firewalls which do, they do have to know how to deal with
connections which require the source data port to be 20.
PASV turns round the data connection establishment.
When the client issues a PASV command to the server, the server responds
with an IP/port combination. The client then connects to the server on this
combination. I believe, but would need to check the RFC, that the client
uses a source port of 20 in this case. If your site generally only allows
outbound traffic through their firewall, then PASV is frequently viewed as
"firewall friendly" since all of the socket creates are from the inside out
(without PASV, the data connection is from outside in). Most FTP client
implementations that I've seen don't handle PASV well. I know you can write
FTP servers which use PASV as we've done this for software distribution and
I know they work where socket creates are only allowed from inside out (in
our case, the directional filters are done on routers, not firewalls, but
the concept is the same).
In general, the FTP data socket has been the curse of all security people;
especially when the "stream" mode is used (which is the general
implementation). Some of the problems with this combination were known when
the protocol was written (firewalls came later). Using a fixed port of 20
and using stream mode was viewed by the writers as a problematic and they
have been proven correct.
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, May 31, 2001 7:43 PM
> To: '[EMAIL PROTECTED]'
> Subject: PASV FTP description
>
> Can anyone briefly describe the difference between PASV ftp vs. non-PASV
> (regular? active?) with reguards to how the ports get assigned?
>
> What considerations on firewalls (any brand) need to made when
> distinguishing between the two?
>
> The way I understand regular FTP, the client connects to server on port 21
> then the server connects back to client on 20 with the data. Is this
> correct
> and how is PASV different?
>
> -erik
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Claussen, Ken
> Sent: Wednesday, May 30, 2001 11:39 AM
> To: 'Graham, Randy (RAW) '; '[EMAIL PROTECTED]'
> Subject: RE: Recommended readings
>
>
> comments inline...
>
> Ken Claussen MCSE CCNA CCA
> [EMAIL PROTECTED]
> "The Mind is a Terrible thing to Waste!"
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Graham, Randy (RAW)
> Sent: Wednesday, May 30, 2001 10:38 AM
> To: '[EMAIL PROTECTED]'
> Subject: Recommended readings
>
>
> Well, I posted this last week but have since gotten a few requests for it,
> so I wanted to post this again. Following is the starting list I give to
> people when they ask me for book suggestions. My personal library is much
> more than this, and I can certainly recommend more books than what I list
> here. However, this is what I give to people as a starter if they aren't
> really sure what they want to learn. I'm open to suggestions for
> additions
> or removals.
>
> I recommend anyone buying books online start with http://www.bookpool.com/
> and http://www.bestbookbuys.com/ for purchases in the USA. Outside the
> US,
> I don't know what sites are best for shopping.
>
> ----------
>
> Firewalls:
> ----------
>
> Building Internet Firewalls - Zwicky, et al
> KC> The first edition is good, but a bit outdated (now), however the
> second
> edition is an excellent resource to begin building a framework for any
> type
> of firewall architecture. It includes information about NT, Linux, and
> Unix
> primarily.
>
> IDS:
> ----
>
> Network Intrusion Detection: An Analysts' Handbook - Northcutt
> Intrusion Signatures and Analysis - Northcutt
> KC> An excellent resource, I highly recommend this book as well for all
> security minded individuals!
>
> Networking:
> -----------
>
> TCP/IP Illustrated, Volume I- Stevens, Wright
> Internetworking with TCP/IP, Volume I - Comer
> Computer Networks - Tanenbaum
> KC> I agree both excellent texts.
>
> Vulnerability Testing:
> ----------------------
>
> Hacking Exposed - Scambray, et al
> KC> This text is quite old now( Copyright 1998 I beleive), but an
> excellent
> resource for anyone who want lots of background into all of the different
> attacks and ways to counteract them. I wish they would come out with a
> second edition to include many of the new exploits.
>
> General Security:
> -----------------
>
> Practical Unix and Internet Security - Garfinkel, Spafford
> KC> Cisco IOS security, Cisco Press is an excellent resource for general
> Cisco Router security.
>
> Cryptography:
> -------------
>
> Applied Cryptography - Schneier
>
> Web sites:
> ----------
>
> http://www.google.com/ -- excellent search engine
> http://www.securityfocus.com/ -- security news and education
> http://www.sans.org/ -- security training and reading
>
> KC> www.cert.org an excellent resource for current information on exploits
> and attacks.
>
>
> ---------
>
> Randy Graham
> --
> You're kind of trying to pick between "horible disaster" and "attrocious
> disaster" -- Paul D. Robertson (on VNC vs. PPTP)
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
