What is the trick to get Windows XP firewall to stay on (after a reboot)?

[Arthur Hagen]

Agreed, the third premise should have been "Destination IP address
matches the PORT command sent by the client" per RFCs - but is there a
downside to a stricter implementation?

Well, yeah. A person might be behind a NAT router, in which case the FTP
client has to be configured with the IP to use for PORT commands. If
there's multiple external addresses, like in a load-balanced WAN, it's not
certain that this will be the same IP address as the one the FTP control
connection was established on.

Another setting is when all data transfers are sent through a dedicated data
line, to keep latency low on the main trunk, and transfer speed consistent
on the data line.

A third scenario is when you have asymmetric lines, and want incoming
traffic routed through the line with the highest incoming speed.

I can also imagine scenarios with a multi-homed FTP proxy that can serve
multiple clients using active FTP against the same server.

Windows FTP client does not implement EPRT. It appears a "well behaved
client" would be required to determine if Windows Firewall implements
EPRT:

It's really not the job of the client to determine what the firewall does.
It is the client's job to check what the server supports. EPRT is an old
standard now, and if the firewall handles PORT but not EPRT, that's a design
flaw with the firewall.

Regards,

 

[Alun Jones [MSFT]]

Agreed, the third premise should have been "Destination IP address matches
the PORT command sent by the client" per RFCs - but is there a downside to
a stricter implementation?

Sure - it'll break anything that tries to use a different IP address. Such
as third-party transfer.

Now, you can certainly argue whether third-party transfer is appropriate or
not, but a stricter implementation will break functionality that is used by
some.

Windows FTP client does not implement EPRT. It appears a "well behaved
client" would be required to determine if Windows Firewall implements
EPRT:

---------
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
dtdbcache_:0
sdtvolcheck393
speckeysd.lock
226 Transfer complete.
ftp: 46 bytes received in 0.00Seconds 46000.00Kbytes/sec.
ftp> literal EPRT |1|10.0.0.1|5003
200 EPRT command successful.
ftp> literal LIST
Connection closed by remote host.
---------

All you've shown here is that the EPRT command is accepted by this server,
and that you can't use "literal" to start a transfer without doing some
extra work.

Client did not reply to SYN, but that doesn't help since:

---------
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
dtdbcache_:0
sdtvolcheck393
speckeysd.lock
226 Transfer complete.
ftp: 46 bytes received in 0.00Seconds 46000.00Kbytes/sec.
ftp> literal PORT 10,0,0,1,19,141
200 PORT command successful.
ftp> literal LIST
425 Can't build data connection: Connection refused.
ftp>

No, that's not what you've shown. You've shown that when you tell the
server to connect to a port (that's what "literal PORT blah..blah..blah"
does), which the client isn't listening on, the server gets a RST back -
connection refused. You have not shown whether that RST comes from the
firewall or the TCP stack behind the firewall.

Alun.
~~~~

 

[Triffid]

Sure - it'll break anything that tries to use a different IP address. Such
as third-party transfer.

Now, you can certainly argue whether third-party transfer is appropriate or
not, but a stricter implementation will break functionality that is used by
some.




All you've shown here is that the EPRT command is accepted by this server,
and that you can't use "literal" to start a transfer without doing some
extra work.

My bad, I provided incomplete information.

If the firewall were external to the client, and configured to permit
the traffic, the EPRT command would cause the firewall to start a listen
for the incoming data connection. In most cases the firewall would also
modify the EPRT command prior to forwarding it, changing the address (if
it's doing NAT) and the port (most just grab the next available rather
than checking if the port specified by the client is available first).

Windows Firewall does not appear to 'see' the EPRT command - at least it
did not modify it, nor did it start a listen.

No, that's not what you've shown. You've shown that when you tell the
server to connect to a port (that's what "literal PORT blah..blah..blah"
does), which the client isn't listening on, the server gets a RST back -
connection refused. You have not shown whether that RST comes from the
firewall or the TCP stack behind the firewall.

Similar to above - Windows Firewall does not start a listen in response
to the PORT command, whereas an external firewall would. An external
firewall would have no way of knowing 'literal' was used to generate the
PORT command, Windows Firewall apparently does.

 

[Alun Jones [MSFT]]

Nothing you have posted so far suggests the conclusions that you have drawn.

The only way to tell for sure whether the firewall pays any attention to the
EPRT or PORT commands are to:
1. Check at the _server_ side to see what the command looked like when it
reached the server (that way, you can tell if NAPT is happening), to compare
with the command you sent.
2. Have a process bound to, and listening on, the port that you specified.
In your tests, the server is attempting to connect to the address and port
the client gave in the EPRT or PORT command, and is receiving a RST as a
result. You have no way to tell whether this RST is prompted by the
firewall refusing the SYN to come in, or by the TCP stack saying "I don't
have any listening sockets on that port". You do not have any listening
sockets on that port, so an incoming SYN will be reset, firewall or no.

The firewall has no knowledge of the difference between a PORT command that
you specify by using literal and one that is specified by a client's action
(if it did, how would third-party FTP clients be supported?)

To be honest, I don't know (yet) if EPRT is supported by our NAPT component.

If you have information (server logs, say) that would support your
assertions, please post them, but what you have posted to date is not a
basis for the assertions you have made.

Alun.
~~~~

 

[Triffid]

Nothing you have posted so far suggests the conclusions that you have drawn.

Not even "suggests" ? ;-)

The only way to tell for sure whether the firewall pays any attention to the
EPRT or PORT commands are to:
1. Check at the _server_ side to see what the command looked like when it
reached the server (that way, you can tell if NAPT is happening), to compare
with the command you sent.

While I did not explicitly state that the EPRT and PORT commands reached
the server exactly as typed, that is indeed what I observed.

2. Have a process bound to, and listening on, the port that you specified.
In your tests, the server is attempting to connect to the address and port
the client gave in the EPRT or PORT command, and is receiving a RST as a
result. You have no way to tell whether this RST is prompted by the
firewall refusing the SYN to come in, or by the TCP stack saying "I don't
have any listening sockets on that port". You do not have any listening
sockets on that port, so an incoming SYN will be reset, firewall or no.

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.

The firewall has no knowledge of the difference between a PORT command that
you specify by using literal and one that is specified by a client's action
(if it did, how would third-party FTP clients be supported?)

So one would expect see a listen started in either case, but it is not
according to the utilities I used.

The observed behavior suggests Windows Firewall is oblivious to the PORT
command, rather it appears to be triggered by the client process'
attempt to listen - perhaps contrary to your implied assertion that
Windows Firewall resides "in front of" the TCP stack.

To be honest, I don't know (yet) if EPRT is supported by our NAPT component.

If you have information (server logs, say) that would support your
assertions, please post them, but what you have posted to date is not a
basis for the assertions you have made.

I have documented, but refrained from posting, observations which I
believe support assertions somewhat beyond those posted to date. I
support responsible disclosure.

Triffid

 

[Alun Jones [MSFT]]

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.]

A firewall, on the other hand, either stops or allows network traffic, based
on its source and/or destination (and sometimes on its contents).

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.

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.

So one would expect see a listen started in either case, but it is not
according to the utilities I used.

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 observed behavior suggests Windows Firewall is oblivious to the PORT
command, rather it appears to be triggered by the client process' attempt
to listen - perhaps contrary to your implied assertion that Windows
Firewall resides "in front of" the TCP stack.

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.

Alun.
~~~~

 

[Phillip Windell]

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.

I want first dibs on the beta!

BTW - Excellent explaination of the difference between a proxy and a NAT
device. It's nice to hear someone else explain it,..I've gotten tired of
doing it myself. I like to call them NAT devices rather than firewalls
because "firewall" is just too generic a term and can mean almost anything
in varying contexts. Even a proxy can be considered a "firewall" because it
either allows or disallows traffic according to rules.

 

[Alun Jones [MSFT]]

I want first dibs on the beta!

The beta team already knows this.

BTW - Excellent explaination of the difference between a proxy and a NAT
device. It's nice to hear someone else explain it,..I've gotten tired of
doing it myself. I like to call them NAT devices rather than firewalls
because "firewall" is just too generic a term and can mean almost anything
in varying contexts. Even a proxy can be considered a "firewall" because
it
either allows or disallows traffic according to rules.

Thanks - I guess that while there's a certain fudging of the terms because
they appear from the outside to do the same thing, there are real reasons
for differentiating between them.

Our firewall, for instance, is in the same service component as our NAT -
but we talk about the two separately, because they are truly logically
separate functions.

Alun.
~~~~

 

[Triffid]

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 Addressort Remote Addressort
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 (servernone)): 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