Nmap: ncat closes connection before server response

Created on 31 May 2018  路  6Comments  路  Source: nmap/nmap

command issued

command> echo -ne "GET / HTTP/1.1\r\nHost: my.host\r\n\r\n" | ncat localhost 80

actual result:

command> (... i mean "nothing")

expected result:

HTTP/1.1 200 OK
Server: nginx/1.12.2
...
...
command>

tested versions

nmap-ncat-6.40-7.el7.x86_64 # centos base repo
nmap-ncat-6.40-13.el7.x86_64 # centos base repo
ncat.x86_64 2:7.70-1 # rpm package downloaded from insecure.org
CentOS Linux release 7.4.1708 (Core) #cat /etc/centos-release
Linux coloso 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # uname -a

additional notes

nginx access log shows a line like = 127.0.0.1 - - [current date] "GET / HTTP/1.1" 499 0 "-" "-" "-" etc...
what makes me suspect that the tool closes conection early (499 status code)

if i run the software directly from console (i.e. from no "echo" redirection) , the software responds and never closes until force with ^C

i used to use nc to do this often.. if the behavior had changed please write down in some faq.. sorry if ugly, i don't master markdown

Ncat expected-behavior

Most helpful comment

Thanks for reporting this. Ncat has had some trouble with similar tests in the past, but we do not consider this a bug. If you can, you should update Ncat to a more recent version, since 6.40 is missing 5 years of bug fixes and improvements.

The way Ncat handles EOF on its various pipes has been pretty exhaustively enumerated. In this case, the echo command finishes writing to Ncat's stdin very quickly, before the server has had a chance to respond. Ncat supports half-open TCP connections, so it calls shutdown on the socket. Some servers don't understand half-open TCP, so when they read EOF on their network socket, they close the connection without responding. Ncat 7.50 and later support the --no-shutdown option to avoid this. Other workarounds that work on older versions of Ncat include calling sleep in a subshell that pipes to Ncat, which allows enough time for the server to respond: (echo -en "GET / HTTP/1.0\r\n\r\n"; sleep 3) | ncat localhost 80; this has the downside of making the command always take 3 seconds, but it is at least compatible with other netcat implementations.

All 6 comments

Unfortunately I cannot reproduce your issue:

$ echo -ne "GET / HTTP/1.1\r\nHost: www.foo.com\r\n\r\n" |ncat -v localhost 80
Ncat: Version 7.70SVN ( https://nmap.org/ncat )
Ncat: Connected to 127.0.0.1:80.
HTTP/1.1 403 Forbidden
Date: Tue, 12 Jun 2018 21:12:14 GMT
Server: Apache
Content-Length: 273
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access / on this server.</p>
<hr>
<address>Apache Server at www.foo.com Port 80</address>
</body></html>
Ncat: 47 bytes sent, 418 bytes received in 0.02 seconds.
$

Tested with SVN and ncat_7.70+dfsg1-3kali1_amd64.deb.

This is likely driven by variations in the two environments. Please try to use option --no-shutdown and see if this makes a difference.

i forgot to mention i have a local nginx server ... but that doesn't matter, you could do it with any http server, or with any smtp, pop, telnet or any request-response transaction based server...

the point is when ncat get the request by stdin, as soon as it recieves it closes the connection and doesn't wait for any server action

edit: now it works, i did nothing (maybe a server reboot in this period?), maybe it occurs under certain unknown conditions o_脭

Thanks for reporting this. Ncat has had some trouble with similar tests in the past, but we do not consider this a bug. If you can, you should update Ncat to a more recent version, since 6.40 is missing 5 years of bug fixes and improvements.

The way Ncat handles EOF on its various pipes has been pretty exhaustively enumerated. In this case, the echo command finishes writing to Ncat's stdin very quickly, before the server has had a chance to respond. Ncat supports half-open TCP connections, so it calls shutdown on the socket. Some servers don't understand half-open TCP, so when they read EOF on their network socket, they close the connection without responding. Ncat 7.50 and later support the --no-shutdown option to avoid this. Other workarounds that work on older versions of Ncat include calling sleep in a subshell that pipes to Ncat, which allows enough time for the server to respond: (echo -en "GET / HTTP/1.0\r\n\r\n"; sleep 3) | ncat localhost 80; this has the downside of making the command always take 3 seconds, but it is at least compatible with other netcat implementations.

i have more info ...

it seems with my local instance of nginx this works, it waits until the response arrives (maybe will with any other http server anywhere also)

echo -ne "GET /whatever HTTP/1.1\r\nHost: myHost\r\n\r\n" | ncat my-http-server 80
HTTP 200 OK
Server: nginx... ...

i am experimenting with an esp8266 wifi module http simple server programmed with arduino, but until it answers fine to browser requests, with ncat this issue occurs though until i leave the connection open... maybe it occurs with some other software/devices, i don't know the actual reason

more info ...

[root@coloso ~]# echo -ne "GET / HTTP/1.1\r\n\r\n" | ncat 192.168.218.161 80
[root@coloso ~]#

below is the debug of program i am writing .. there clearly shows the connection closes client-side (ncat) before response could be sent... with firefox network dev tool also lacks response header

sendResponse(): len, response: 15
sendSerialData(): link, length: 0, 26
HTTP/1.1 404 Not Found < ------------- HERE THE PROGRAM SHOWS THE RESPONSE TO SEND

sendSerialData(): serial available: 10 < ------ HERE IT SHOWS 10 BYTES OF UNREAD BYTES IN BUFFER
0,CLOSED <---------- BUFFERED DATA THAT SHOWS THE CONNECTION CLOSED BEFORE

sendResponse(): send error <------------ HERE THE PROGRAM TRIES TO SEND THE RESPONSE....
closeLink(): AT+CIPCLOSE=0 <--------- ... BUT FAILS TO SEND AND DISCONNECT....
closeLink(): not closed <------------ ... BECAUSE IT IS ALREADY DISCONNECTED

now trying again with ncat in "interactive" mode... it seems to work, but response delays 1-2 seconds

[root@coloso ~]# ncat 192.168.218.161 80
GET / asd <------ MY PROGRAM IS REALLY SIMPLE, IT JUST SEARCH FOR "GET" AND THE URL
HTTP/1.1 404 Not Found <----------- HERE IS THE RESPONSE

meanwhile in my debug arduino console...

sendResponse(): len, response: 15
sendSerialData(): link, length: 0, 26
HTTP/1.1 404 Not Found <----------- ALREADY COOKED RESPONSE

sendSerialData(): serial available: 0 <--------- THERE IS NO BUFFERED DATA
<-------------- NO BUFFERED DATA
sendSerialData(): serial available: 0
sendResponse(): response sent <----------- RESPONSE SENT
closeLink(): AT+CIPCLOSE=0
closeLink(): closed <------------ LINK CLOSED OK

more overwhelming evidence... this is the debug info skipping any arduino program at all, with data piped directly from esp-01 to serial console...

[root@coloso ~]# echo -ne "GET / asd"|ncat 192.168.218.161 80
[root@coloso ~]#

0,CONNECT
+IPD,0,9:GET / asd0,CLOSED

a similar example with firefox where you can see the connection don't closes...

+IPD,0,345:GET / HTTP/1.1
Host: 192.168.218.161
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1

... the cogwheel keeps spinning as firefox waits for a response that never comes as no response is processed... that proves the link keeps open, clears my doubts about a bug in my program and rises me to continue my developing

however i still don't know the difference that keeps the connection alive sending ncat in "interactive mode" to nginx (maybe also to apache)

i tested multiple ncat versions all with the same behavior, the latest and current is 7.70 downloaded directly from insecure.org, for tested versions see first message in thread

update: it seems "--no-shutdown" option worked! (could be the default, many scripts could break, i made an alias) ... so anyway thanks for your time and keep going... nmap/ncat rocks!

Was this page helpful?
0 / 5 - 0 ratings