Alun said:
While I did not explicitly state that the EPRT and PORT commands reached
the server exactly as typed, that is indeed what I observed.
You have to state these things - while we've probably got a division working
hard on one right now, I haven't yet been issued with a mind reading
accessory. All I have to go on are what you tell me, and what I can
reproduce myself.
In the case of a firewall external to the client, the firewall would
listen on the port specified in the outgoing EPRT or PORT command - on
behalf of the client - with no knowledge of the client's ability to accept
a connection on the port he specified.
Windows Firewall did not start a listen according to netstat -a and Port
Explorer.
You're thinking of a proxy, not a firewall. The two are not synonymous,
even though they often serve similar functions.
A proxy accepts incoming connections, and acting on behalf of that incoming
connection, creates a new connection onward. [Look up the less
technological meanings of "proxy" in a dictionary, to see why it got that
name.]
According to (ISC}2, proxies are either application-level proxies or
circuit-level proxies. Only the application-level proxy creates a
separate TCP connection.
A firewall, on the other hand, either stops or allows network traffic, based
on its source and/or destination (and sometimes on its contents).
You're thinking of a packet filter, not a firewall. The two are not
synonymous.
A NAPT router (which may be a part of a firewall, or a separate entity)
inspects and alters network traffic, forwarding most of them unchanged.
Once upon a time, there were proxying firewalls and packet filtering
firewalls. Along came stateful inspection, circuit-level proxies, etc.
and the lines have been somewhat blurred since.
So, while a proxy would result in a new listening socket, a firewall does
not. The firewall says "aha - I've been told to allow traffic through on
port 12345", and it starts allowing traffic through on that port. It's a
completely different layer of the network transport, and cannot be inspected
or inferred through netstat -a.
An application-level proxy would open a new listening socket, a packet
filter would not. The behavior of a firewall would depend on it's
architecture, and perhaps it's configuration (if both filtering and
proxying are supported).
No, one would not expect to see a listen started in the case that you sent a
"literal PORT" command, but you would see a listen started prior to an FTP
client sending a PORT command that it (rather than you) has chosen to send.
That would be the listening socket created by the FTP client, and whose
address and port it uses in the PORT command.
The Windows Firewall analyses IP traffic for patterns that have been allowed
or refused, and passes that IP traffic on to the next layer or does not
pass, depending on whether the traffic is allowed or not.
Your description uses none of the terms above, therefore doesn't say
much about the architecture. Perhaps discussing the observed behavior
will be more productive.
On Windows XP SP2, Windows Firewall enabled with default settings
(client), Port Explorer to monitor sockets, ftp.exe as the client, and a
Solaris system on my local subnet providing FTP service (server). Note
the server is in a debug mode such that it waits for me to tell it to
send the next response to the client:
|c:\ftp server
|Connected to server.
At this point Port Explorer reports three new established TCP connections:
Process Local Address
ort Remote Address
ort
ftp.exe client:2977 server:21
alg.exe localhost:1034 client:2977
alg.exe client:2979 server:21
netstat -a on the server shows server:21 established to client:2979,
i.e. the third connection above only. This suggests alg.exe is behaving
as an application-level proxy.
I have the server continue, and return to the client:
|220 "Welcome to server FTP service."
|User (server
none)): triffid
|331 Please specify the password.
|Password:
|230 Login successful.
|ftp> ls
Windows Firwall pops up and informs me it has blocked File Transfer
Program from accepting connections. I ignore it. At this point the
server receives a PORT command, but does not reply just yet. The PORT
command specifies client:5002, however Port Explorer does not see a
listen on 5002, instead it sees:
ftp.exe client:2981 localhost:0 LISTEN
alg.exe is not involved. It doesn't look like a proxy now.
I have the server continue:
|200 PORT command OK
|150 Opening data connection
Port Explorer sees the data connection established, but not to the PORT
specified:
ftp.exe client:2981 server:20 ESTABLISHED
netstat -a on the server shows server:20 establshed to client:5002 - yet
the client wasn't listening on 5002 according to Port Explorer.
Interesting ;-)
I wonder what would happen if, instead of having the server go ahead and
connect to client:5002, I have a third system attempt a connection to
client:2981 ?
I suggest you try it.
Triffid