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

From: Alun Jones [MSFT] (alunj_at_online.microsoft.com)
Date: 01/10/05

  • Next message: Ishmealm: "Re: Restart Service Rights" 
    Date: Mon, 10 Jan 2005 08:34:06 -0800

    "Triffid" <triffid@nebula.net> wrote in message
    news:VJVDd.80695$P%3.2580840@news20.bellglobal.com...
    > 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>
    > ---------
    >
    > i.e. Windows Firewall is not simply proxying the PORT command.
    > Interesting.

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

  • Next message: Ishmealm: "Re: Restart Service Rights"

    Relevant Pages