Re: ncat should try connecting to all resolved addresses, not only the first one

[Jacek Wielemborek <d33tah () gmail com>]

12/12/2013 17:16:09 Fyodor <fyodor () nmap org>:
> On Tue, Dec 3, 2013 at 12:20 PM, Jaromir Koncicky 
<jkoncick () redhat com>wrote:
> > Could you please look and this and give me a feedback?
> > I'd like to finish this issue and make an acceptable patch which could be
> > included in nmap.
> > Thanks!
>
> Hi Jaromir.  Thanks for the updated and much-improved patch.  However, I'm
> not sure if we really want this behavior or not, and I'd be interested in
> hearing from others whether they desire it or not, and why.  I haven't
> thought about this as much as you have, but here are some pros and cons
> that I see:
>
> PROS of trying each address from getaddrinfo sequentially if one times out
> or port is closed/filtered:
>
> * Can help the case in your bug report where application is listening on
> just one protocol (IPv4 or IPv6) but both addresses are returned for the
> host name and Ncat tries the other protocol first.
>
> * Can help if a machine has multiple A records for redundancy so Ncat can
> still connect even if one of them is down at a given time.
>
> CONS:
>
> * Maybe other solutions are better.  For example the application could be
> run on both protocols (and Redis does in fact support IPv6 now) or you
> could specify to Ncat the protocol you want (-4 or -6) or use a literal
> IP/IPv6 address or give a DNS name which only resolves to one address.
>
> * Ncat is a pretty low level tool.  If it times out an address or
> connection is refused, user might want to know about it rather than have
> Ncat "magically" try other addresses.
>
> * Changes like this risk adding new bugs and/or breaking things for people
> who depended on the old behavior.  This is only a minor con since it could
> be used to argue against any change, and we do like to move forward.
>
> NEUTRAL:
>
> * Consistency with Nmap: Nmap only scans one address by default even if
> more are returned by getaddrinfo.  Though Nmap does tell you about the
> other addresses (at least in verbose mode) and does offer the resolveall
> NSE script to scan them all if desired.  Also Nmap does not experience this
> exact issue since Nmap always uses IPv4 unless you ask for -6.  We will
> probably change that behavior at some point though to function more like
> Ncat.
>
> * Do you know what other programs do or don't follow this behavior?  I'm
> thinking of apps like OpenSSH, Chrome/Firefox, wget/curl, etc.
>
> I'd be interested in hearing more arguments for (or against) this change
> before we seriously consider integrating it.
>
> Cheers,
> Fyodor
> _______________________________________________
> Sent through the dev mailing list
> http://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/

Hi,

I'd like to add another one to PROS - the current behavior isn't really 
intuitive. Suppose you're running an IPv6-ignorant HTTP server, or SSH, or 
anything like that. You're experiencing problems and want to make sure that 
it's listening. You run ncat localhost 22... and it says "connection refused". 
On the other hand, "telnet localhost 22" will connect with no problems.

Personally, I like the "try out all the A records" approach and I believe that 
trying out both IPv4 and IPv6 is the least that Ncat should do in this case. I 
also had the idea that Ncat should perhaps warn that IPv4 was assumed if 
neither -4 nor -6 was specified, or maybe do so only in case of an error. 

Or, though something says me that it's too extreme (and it completely breaks 
backwards compatibility), make Ncat not connect at all if there was no IP 
protocol number specified. This is probably not a good idea though.

Anyway, I like the solution used in the patch.

Jacek

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/