R
Robert Moir
Triffid said:
It blocks unsolicited inbound connections, as its designed to. Your failiure
to understand how it works is your problem, not Microsoft's or any of the
people here.
--
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
What is the trick to get Windows XP firewall to stay on (after a reboot)?
It blocks unsolicited inbound connections, as its designed to. Your failiure
to understand how it works is your problem, not Microsoft's or any of the
people here.
--
T
Triffid
Leythos said:If you initiate the connection with the system it will allow the
connection to converse with your computer too - that's how everything
works. With FTP, you can't really block 20 and have FTP work properly.
I understand how FTP works. I mentioned it only as an easily
reproduceable example.
My issue with Windows Firewall is the fact it pops up claiming to have
blocked something, when in reality it has not - clearly misleading behavior.
L
Lars M. Hansen
On Mon, 03 Jan 2005 15:31:58 -0500, Triffid spoketh
Please provide examples of unsolicited traffic that the Windows firewall
claims to have blocked but which in fact it has not.
Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)
I understand how FTP works. I mentioned it only as an easily
reproduceable example.
My issue with Windows Firewall is the fact it pops up claiming to have
blocked something, when in reality it has not - clearly misleading behavior.
Please provide examples of unsolicited traffic that the Windows firewall
claims to have blocked but which in fact it has not.
Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)
T
Triffid
Lars said:On Mon, 03 Jan 2005 15:31:58 -0500, Triffid spoketh
Please provide examples of unsolicited traffic that the Windows firewall
claims to have blocked but which in fact it has not.
I fail to see the relevance of solicited vs. unsolicited traffic to the
issue I raised.
The firewall permits inbound FTP data connections by default, but does
not display an exception for FTP by default, i.e. there is at least one
invisible "permit" rule built in. The firewall raises a Windows Security
Alert when traffic is permitted by the invisible rule.
The Alert says "Windows Firewall has blocked this program from accepting
connections...", which is misleading because it has in fact permitted
the connection - apparently by design.
The responses to my post suggest people here don't consider this
behavior problematic, but it makes me distrust the software - so I dug a
little deeper to see if my unease is justified. Turns out it is.
I clicked "Unblock" on the Alert window, which added a visible exception
for the Windows FTP client with unlimited scope. This is reasonable
behavior, although it would be nice if the user were prompted for scope
given that the FTP data connection which raised the alert was from a
server on the local subnet.
FTP continues to function after adding the exception, the exception
merely stops the spurious alerts (as expected)
Next I constrained the FTP exception's scope to "Custom list" and
specified a single RFC1918 IP address which is *not* on my local subnet,
i.e. I configured the firewall to permit FTP data connections from one
unreachable IP address *only*.
Guess what?
Active mode FTP still works to all servers, regardless of their IP
address. I then changed the scope to "My network (subnet) only". Same
result, i.e. restricting scope has no effect.
In summary:
- Windows Firewall has a default exception for FTP, with unlimited
scope, but it is not shown on the default exception list.
- Windows Firewall raises spurious FTP alerts unless a visible FTP
exception is added.
- Changes to the FTP exception scope have no effect. Scope is unlimited
regardless of configured scope.
Microsoft has already released a patch to fix exception scope on dialup
connections. Given the above, one wonders how many more invisible
exceptions and broken scope restrictions remain to be discovered.
Triffid
P
Printer Expert
My issue with Windows Firewall is the fact it pops up claiming to
have
Want to know which ports are open on your Windows XP SP2 firewall?
Just type this from a CMD line:
c:\> netsh firewall show portopening
I am not a firewall expert but the general consensus seems to be
that this firewall is next to useless (as compared to the freebie
firewalls such as Sygate & Zone Alarm, etc.). That is, if you
think you need a firewall, DO NOT RUN WINDOWS FIREWALL!
The Windows XP SP2 firewall is intended by Microsoft to allay the
fears of the moms and pops out there ... to make them "feel" safe
without actually doing much to make them safe. To that end it pops
up all sorts of useless messages without actually blocking anything.
To the point of the original poster, I too had trouble getting the
Windows XP firewall to fire up (even though all my setting seemed OK,
it still would not start upon a reboot of my windows xp sp2 PC).
When I looked it up, I was amazed to find out that nobody actually uses
the windows firewall as it is basically a toy compared to the real
stuff that
is out there free on the web.
Thus, don't worry that windows xp sp2 firewall won't start
automatically.
See details at:
Windows XP SP2 more Secure? Not so fast!
http://reviews.zdnet.co.uk/software/os/0,39024180,39163696,00.htm
XP SP2 Firewall Warning.
http://www.iamnotageek.com/a/103-p1.php
Update: Ten New Security Holes in Windows XP SP2?
http://www.winnetmag.net/Article/ArticleID/44502/44502.html
Critical XP Firewall Issue
http://www.nwfusion.com/news/2004/1217microfixes.html?nl</a
have
Want to know which ports are open on your Windows XP SP2 firewall?
Just type this from a CMD line:
c:\> netsh firewall show portopening
I am not a firewall expert but the general consensus seems to be
that this firewall is next to useless (as compared to the freebie
firewalls such as Sygate & Zone Alarm, etc.). That is, if you
think you need a firewall, DO NOT RUN WINDOWS FIREWALL!
The Windows XP SP2 firewall is intended by Microsoft to allay the
fears of the moms and pops out there ... to make them "feel" safe
without actually doing much to make them safe. To that end it pops
up all sorts of useless messages without actually blocking anything.
To the point of the original poster, I too had trouble getting the
Windows XP firewall to fire up (even though all my setting seemed OK,
it still would not start upon a reboot of my windows xp sp2 PC).
When I looked it up, I was amazed to find out that nobody actually uses
the windows firewall as it is basically a toy compared to the real
stuff that
is out there free on the web.
Thus, don't worry that windows xp sp2 firewall won't start
automatically.
See details at:
Windows XP SP2 more Secure? Not so fast!
http://reviews.zdnet.co.uk/software/os/0,39024180,39163696,00.htm
XP SP2 Firewall Warning.
http://www.iamnotageek.com/a/103-p1.php
Update: Ten New Security Holes in Windows XP SP2?
http://www.winnetmag.net/Article/ArticleID/44502/44502.html
Critical XP Firewall Issue
http://www.nwfusion.com/news/2004/1217microfixes.html?nl</a
G
Guest
In your example, you refer to an FTP server and an XP machine. If you
initiate an FTP connection from XP to the server, the connection is allowed
whether the box is checked or not and you will in fact receive data from the
server. This inbound traffic was solicited.
By checking the box, would be able to initiate an FTP connection to the XP
box. Of course this would be of limited use if you were not running an FTP
server on the XP box.
The Firewall control panel is explicit in saying that exceptions are
allowing inbound connections. This firewall is not designed to block outbound
connections. I would refer you to the link I mentioned below
(http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2top.mspx)
where it is clearly stated that almost no outbound checking is done.
In Summary:
I would recommend that you understand the technology you are using and
"testing" before making wild assertions. No one is claiming that this is a
complete solution, but should be used as another layer of protection *if*
desired. Otherwise, feel free to add a product like ZoneAlarm to your
arsenal. But make sure you understand how it works and what protection it
affords you.
initiate an FTP connection from XP to the server, the connection is allowed
whether the box is checked or not and you will in fact receive data from the
server. This inbound traffic was solicited.
By checking the box, would be able to initiate an FTP connection to the XP
box. Of course this would be of limited use if you were not running an FTP
server on the XP box.
The Firewall control panel is explicit in saying that exceptions are
allowing inbound connections. This firewall is not designed to block outbound
connections. I would refer you to the link I mentioned below
(http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2top.mspx)
where it is clearly stated that almost no outbound checking is done.
In Summary:
I would recommend that you understand the technology you are using and
"testing" before making wild assertions. No one is claiming that this is a
complete solution, but should be used as another layer of protection *if*
desired. Otherwise, feel free to add a product like ZoneAlarm to your
arsenal. But make sure you understand how it works and what protection it
affords you.
T
Triffid
Triffid said:I fail to see the relevance of solicited vs. unsolicited traffic to the
issue I raised.
The firewall permits inbound FTP data connections by default, but does
not display an exception for FTP by default, i.e. there is at least one
invisible "permit" rule built in. The firewall raises a Windows Security
Alert when traffic is permitted by the invisible rule.
<snip>
Deafening silence... I guess that was more information than you expected
to be publicly disclosed when you asked for examples?
If so, what is considered the most appropriate approach?
G
Guest
Please see my 1/4 response.
Triffid said:<snip>
Deafening silence... I guess that was more information than you expected
to be publicly disclosed when you asked for examples?
If so, what is considered the most appropriate approach?
L
Lars M. Hansen
On Wed, 05 Jan 2005 19:24:44 -0500, Triffid spoketh
Your failure to see the difference between solicited and unsolicited
traffic says enough about your understanding of networking and
security...
Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)
<snip>
Deafening silence... I guess that was more information than you expected
to be publicly disclosed when you asked for examples?
If so, what is considered the most appropriate approach?
Your failure to see the difference between solicited and unsolicited
traffic says enough about your understanding of networking and
security...
Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)
T
Triffid
Lars said:On Wed, 05 Jan 2005 19:24:44 -0500, Triffid spoketh
Your failure to see the difference between solicited and unsolicited
traffic says enough about your understanding of networking and
security...
My definition of solicited traffic is limited to packets that belong to
an established connection. What's yours?
L
Lars M. Hansen
On Wed, 05 Jan 2005 19:24:44 -0500, Triffid spoketh
Your failure to see the difference between solicited and unsolicited
traffic says enough about your understanding of networking and
security...
My definition of solicited traffic is limited to packets that belong to
an established connection. What's yours?[/QUOTE]
Yet you keep complaining about the Windows firewall allowing obvious
solicited (ftp) traffic?
You still have not provided any examples of unsolicited traffic that the
Windows firewall claims to have blocked but which in fact it has not.
Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)
T
Triffid
Lars said:On Thu, 06 Jan 2005 21:14:16 -0500, Triffid spoketh
Yet you keep complaining about the Windows firewall allowing obvious
solicited (ftp) traffic?
FTP data traffic is not transferred over an established connection. The
server initiates a *new* connection from port 20 to an ephemeral port on
the client, which falls outside my definition of solicited traffic.
You still have not provided any examples of unsolicited traffic that the
Windows firewall claims to have blocked but which in fact it has not.
Yes I have - by my posted definition, *all* inbound connection requests
(FTP data included) are unsolicited. Your definition remains unspecified.
G
Greg Hennessy
FTP data traffic is not transferred over an established connection. The
server initiates a *new* connection from port 20 to an ephemeral port on
the client, which falls outside my definition of solicited traffic.
Thats because you're a f*cking idiot who doesnt understand the difference
between active and PASV ftp.
L
Lars M. Hansen
On Thu, 06 Jan 2005 23:24:36 -0500, Triffid spoketh
Since your client requestst the FTP data, then the resulting data stream
is solicited. The fact that FTP works different that most if not all
other protocol doesn't change the fact that your computer solicited the
traffic, and it got just what it asked for.
My definition of solicited traffic is very simple: If you asked for it,
it's solicited. So, when you request a file transfer, and packets comes
knocking, those are all solicited, even when you take into the account
the special circumstances that needs to be taken into account for FTP.
Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)
FTP data traffic is not transferred over an established connection. The
server initiates a *new* connection from port 20 to an ephemeral port on
the client, which falls outside my definition of solicited traffic.
Yes I have - by my posted definition, *all* inbound connection requests
(FTP data included) are unsolicited. Your definition remains unspecified.
Since your client requestst the FTP data, then the resulting data stream
is solicited. The fact that FTP works different that most if not all
other protocol doesn't change the fact that your computer solicited the
traffic, and it got just what it asked for.
My definition of solicited traffic is very simple: If you asked for it,
it's solicited. So, when you request a file transfer, and packets comes
knocking, those are all solicited, even when you take into the account
the special circumstances that needs to be taken into account for FTP.
Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)
D
David Candy
Well said.
T
Triffid
Greg said:Thats because you're a f*cking idiot who doesnt understand the difference
between active and PASV ftp.
The discussion is about how Windows Firewall handles active mode FTP.
Passive mode FTP, which is not supported by the Windows FTP client, is
irrelevant in the current context.
T
Triffid
Lars said:On Thu, 06 Jan 2005 23:24:36 -0500, Triffid spoketh
Since your client requestst the FTP data, then the resulting data stream
is solicited. The fact that FTP works different that most if not all
other protocol doesn't change the fact that your computer solicited the
traffic, and it got just what it asked for.
Indeed - FTP has unique characteristics, so it's always interesting to
explore how firewalls implement FTP.
My definition of solicited traffic is very simple: If you asked for it,
it's solicited. So, when you request a file transfer, and packets comes
knocking, those are all solicited, even when you take into the account
the special circumstances that needs to be taken into account for FTP.
Hmmm, that complicates the issue. Under my definition, deciding whether
or not inbound traffic was solicited is quite straightforward - it
either belongs to an established connection, or it doesn't. Under your
definition, additional decisions are required - and therein lies the rub.
Using your definition in conjunction with RFC959, I would consider an
inbound FTP data connection to be solicited only if all of the following
are true:
- Source IP address matches the established FTP control connection
- Source port is TCP 20
- Destination IP address matches the established FTP control connection
- Destination port matches the PORT command sent by the client
Windows Firewall implements a considerably more promiscuous definition
of a solicited inbound FTP data connection.
Triffid
A
Arthur Hagen
Triffid said:Using your definition in conjunction with RFC959, I would consider an
inbound FTP data connection to be solicited only if all of the
following are true:
- Source IP address matches the established FTP control connection
- Source port is TCP 20
- Destination IP address matches the established FTP control
connection
- Destination port matches the PORT command sent by the client
Your third premise is wrong. The destination port is also specified in the
PORT command, and does not have to be the same as the outgoing IP. It's
common, but still a mistake, to assume that 1 box = 1 IP = 1 route. For the
server, it's a requirement to use the same IP address for the data stream as
the control connection, but for the client, there's no such restriction, and
in fact, the client MUST specify an IP address in the PORT command. See
RCF1123 for details.
Furthermore, there's EPRT in addition to PORT, and a well behaved client
will try EPRT first, and fall back to PORT only if the server doesn't
understand EPRT. See RFC2428 and RFC2766 for details. If the firewall only
understands PORT and not EPRT, while both the client and server groks EPRT,
you have a big problem.
Client Server
172.16.0.1:1025 -> 10.0.0.1:21 USER user
172.16.0.1:1025 <- 10.0.0.1:21 3xx Need password
172.16.0.1:1025 -> 10.0.0.1:21 PASS pass
172.16.0.1:1025 <- 10.0.0.1:21 200 OK
172.16.0.1:1025 -> 10.0.0.1:21 EPRT |1|172.16.0.2|32770|
172.16.0.1.1025 <- 10.0.0.1.21 200 OK
172.16.0.1.1025 -> 10.0.0.1:21 GET file
172.16.0.2:32770 <- 10.0.0.1:20 <data>
172.16.0.1.1025 <- 10.0.0.1.21 200 Complete
172.16.0.1.1025 -> 10.0.0.1:21 QUIT
Regards,
G
Greg Hennessy
The discussion is about how Windows Firewall handles active mode FTP.
Passive mode FTP, which is not supported by the Windows FTP client, is
irrelevant in the current context.
I rest my case.....
T
Triffid
Arthur said:Your third premise is wrong. The destination port is also specified in the
PORT command, and does not have to be the same as the outgoing IP. It's
common, but still a mistake, to assume that 1 box = 1 IP = 1 route. For the
server, it's a requirement to use the same IP address for the data stream as
the control connection, but for the client, there's no such restriction, and
in fact, the client MUST specify an IP address in the PORT command. See
RCF1123 for details.
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?
Furthermore, there's EPRT in addition to PORT, and a well behaved client
will try EPRT first, and fall back to PORT only if the server doesn't
understand EPRT. See RFC2428 and RFC2766 for details. If the firewall only
understands PORT and not EPRT, while both the client and server groks EPRT,
you have a big problem.
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.
---------
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>
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.