mailing list archives
Re: Ncrack on exotic Windows-land
From: ithilgore <ithilgore.ryu.l () gmail com>
Date: Fri, 26 Jun 2009 21:53:37 +0300
Rob Nicholls wrote:
I have no idea why Windows sends the RST, it shouldn't. The only
explanation I can come up with is that Windows doesn't support one-way
TCP connections. When I saw this I muttered some anti-Windows,
anti-Microsoft slurs and threw my hands up in disgust.
I've only tried this using ftp on the command line and quitting the FTP
server, but I only see this behaviour (the unusual RST immediately being
sent) if the Windows Firewall is enabled. If I disable it I can see the
final handshaking done properly. I'm not sure if the Windows Firewall is
behind the RST sent to the OSX clients or if this is a separate - but
similar - issue. Can either of you reproduce your issues if the Windows
Firewall is disabled?
You are right about the firewall. I reproduced the issue with Windows Firewall
disabled and it worked as it should.
I would imagine (for the ncrack issue) that the Windows Firewall knows that
the process has exited (and released it's connection) so it sends a reset
because even if it got a response back there wouldn't be an application
that's listening so it would just get filtered, causing the FTP server to
send more traffic trying to gracefully close the connection.
The problem is that ncrack does *not* exit - it doesn't use a separate process
for each connection like for example hydra does - as it is always one thread
utilizing nsock to handle parallel sockets. But even if that was the case, the
process wouldn't exit until it read the final server's reply (which is what the
main problem is - losing that final reply because of the Windows kernel
prematurely sending the RST back to the server and thus killing the socket and
any associated receive-buffers).
In addition, what baffles me is that the Windows firewall is supposed to filter
only incoming connections. Any connection beginning from the inside, is
supposedly not influenced by using stateful firewall techniques (keeping a table
of every connection alive and allowing any packet that belongs to any of them to
As for what you said about the FTP server sending more traffic trying to
gracefully close the connection: the only thing that it would need to send would
be the ACK of the client's FIN. I don't see how this 'innovative' approach would
lead to any significant performance gain (which anyway should *not* be the
I can see why it's potentially bad for a firewall - other firewalls may do
the same? - to do this (it should only issue resets in response to a
connection request for a nonexistent connection, and shouldn't be
proactive), but I can understand what they're trying to do. I suspect we'll
have to live/deal with it, especially as the Windows Firewall is on by
Honestly, this is the first time I come across this bizarre behavior. I know of
no other firewall which does anything similar. It goes against the RFC rules,
against the rules of logic and potentially against the rules of the universe.
Given that the windows firewall is, as you said, enabled by default and that
ncrack is limited by the underlying network stack as it doesn't use raw sockets
or other low-level stuff, I don't see any other solution at the moment, other
than specifically instructing the users to disable the firewall for the time
they are running ncrack (or else they will suffer a serious performance
degradation). I really don't like this approach but anything else would require
sending ha^H^H mails to Microsoft about changing the firewall's behaviour (and I
have a feeling they might go unanswered).
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org