(In reply to Paul Clifford from comment #0)
> Description of problem:
> The ncat binary in the nmap-ncat package has a --proxy-type argument that
> accepts "socks4" as an argument. Prior to the nmap-ncat-6.40-13.el7.x86_64
> package in RHEL 7.5 this implemented the SOCKS4 protocol. From that version
> onwards it implements SOCKS4a instead, which isn't supported by all SOCKS
> servers.
> 
Hello Paul,
Ncat sends IP address instead of FQDN if ip address was specified as destination. 
for example:
# ncat github.com  --proxy localhost:4444 --proxy-type socks4 # uses socks4a extention
# ncat `dig +short github.com   | awk '{ print ; exit }'` --proxy localhost:4444 --proxy-type socks4     ## doesn't use socks4a extention

Ah, interesting! The problem we had was that something like the following used to use socks4, prior to the update to nmap-ncat in RHEL 7.5, but changed to using socks4a which isn't recognised by our corporate socks proxy:
ncat github.com  --proxy localhost:4444 --proxy-type socks4

We've since completed the update to 7.5 and changed the proxy type to socks5 instead, so for what it's worth this no longer directly affects us.

(In reply to Paul Clifford from comment #3)
> Ah, interesting! The problem we had was that something like the following
> used to use socks4, prior to the update to nmap-ncat in RHEL 7.5, but
> changed to using socks4a which isn't recognised by our corporate socks proxy:
> ncat github.com  --proxy localhost:4444 --proxy-type socks4
You're right. Ncat was rebased in latest RHEL and brought socks4a support but it doesn't follow specification very well. I've sent patch upstream:
https://github.com/nmap/nmap/pull/1214

> 
> We've since completed the update to 7.5 and changed the proxy type to socks5
> instead, so for what it's worth this no longer directly affects us.
Yeah. Update to newest version is good idea. 

Thank you for the report!

Thank you for taking the time to report this issue to us. We appreciate the feedback and use reports such as this one to guide our efforts at improving our products. 

If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution. 

For information on how to contact the Red Hat production support team, please visit:
    https://www.redhat.com/support/process/production/#howto

This vulnerability was evaluated by the sub-system, taking into account the kind of the component, and its use cases. It was not considered as a priority for the next release, so it's being closed now as WONTFIX. Feel free to re-open the bug if there is a business reason to deliver a fix for this issue, and contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com