Re: What is the trick to get Windows XP firewall to stay on (after a reboot)?
From: Triffid (triffid_at_nebula.net)
Date: 01/13/05
- Next message: Malke: "Re: File sharing problem"
- Previous message: Chuck: "Re: Sudden loss of connectivity?"
- In reply to: Alun Jones [MSFT]: "Re: What is the trick to get Windows XP firewall to stay on (after a reboot)?"
- Next in thread: Robert Moir: "Re: What is the trick to get Windows XP firewall to stay on (after a reboot)?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 12 Jan 2005 22:45:43 -0500
Alun Jones [MSFT] wrote:
> "Triffid" <triffid@nebula.net> wrote in message
> news:hg2Fd.33132$TN6.1040827@news20.bellglobal.com...
>
>>
>>Alun Jones [MSFT] wrote:
>>
>>>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.
>
>
> 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).
>>>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.
>
>
> 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.
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:port Remote Address:port
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
- Next message: Malke: "Re: File sharing problem"
- Previous message: Chuck: "Re: Sudden loss of connectivity?"
- In reply to: Alun Jones [MSFT]: "Re: What is the trick to get Windows XP firewall to stay on (after a reboot)?"
- Next in thread: Robert Moir: "Re: What is the trick to get Windows XP firewall to stay on (after a reboot)?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
