Re: Ncat: Update and Feature Request

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

eldraco wrote:
> Nice work!, I love ncat beeing alive again. Thank you!

No problem, I'm glad you like it.

It's late here and I have class tomorrow, so I'll have to look more in-depth
into these issues later.

> Feedback:
> 0- Debian 4.0 unstable with libssl-dev preinstalled. Ncat svn revision 9002
> 1- ncat compiled like a charm, the only warning printed was :
>       config.status: WARNING:  Makefile.in seems to ignore the --datarootdir 
> setting

Ncat doesn't need that option, so it ignores it.  I have the same warning in
my config.log for Nmap.

> 2- ncat binary and man page installed correctly

Great.

> 3- Executing "ncat localhost" (no port specified) prints:
>       "Unable to connect to remote host"
>     But debian's nc prints out a more detailed error text: "nc localhost"
>       "no port[s] to connect to"

Yes, good idea.

> 4- Connecting to localhost with "ncat localhost 22" prints out the following 
> as the first line: "Connected to 127.0.0.1:22", wich is a bit odd to me, 
> because I'm used to see just what the other side of the channel sends unless 
> I specify the -v or something. I would like ncat to be 'quiet' by default, 
> what do you think? What if the other side of the channel sends "Connected to 
> 127.0.0.1:23" as a kind-of deceptive measure?

This is a good idea as well.  It kind of irritated me at first, but I grew to
like it when testing without wanting the rest of the -v output.  I'll remove it.

> 5- Maybe this is a bug: Connecting to an ssh server, the ssh server closes the 
> connection sending a FIN packet (because I didn't speak the ssh protocol 
> right) but ncat doesn't respond with a FIN-ACK packet, it seems to believe 
> the connection is still up, and keep sending packets. After the four "string" 
> sent to the ssh server, ncat dies because is "Unable to connect to remote 
> host". I'm attaching the nc -vvv output [ncat-internet-ssh-FIN-bug-1.txt] and 
> a tcpdump capture [ncat.internet.ssh.FIN-bug-1.pcap]

OK I'll look into this.  The host doesn't have to respond with a FIN/ACK if
it's going to continue sending data (it just sends an ACK), but it sounds like
Ncat doesn't know when to stop.

> 6- 'ncat -l 9000 > /tmp/test' and 'ncat localhost 9000 < /bin/ls' works fine, 
> but, 'ncat -l 9000 < /bin/ls' doesn't work at all. It prints:
>
>       ncat -l 9000 < /bin/ls
>       write: Broken pipe
>
>       Ncat man page state this shoud work:
>       Send a file over TCP port ?9899? to host ?example.org?. (this also works in 
> reverse and turns Ncat into a "one file" server!)
>          HOST1$ ncat -l 9899 > outputfile
>          HOST2$ ncat example.org 9899 < inputfile

Hmm.. it doesn't error out for me.  It doesn't work correctly for me because
it reads all of stdin and exits from EOF before I get a chance to connect to
it, so there exists a bug for sure, but I'm not getting the broken pipe.

> 7- Ncat is in the PATH but trying ncat --exec "ncat www.google.com.ar 80" -l 
> 9000  and later "ncat localhost 9000" doesn't work for me, it ends 
> with "execv: No such file or directory". I'm attaching the -vvv output 
> [ncat-exec-bug-1.txt]. But if I give the full path it works fine!, like this:  
> ncat --exec "/usr/local/bin/ncat www.google.com.ar 80" -l 9000
>
> Note that ncat --exec "/bin/bash" -l 9000 and the like, does work fine too.

The -e/--exec option requires the full path because it execs it based on it,
but you can use the -c/--sh-exec I added to execute the program via /bin/sh so
it doesn't require the full path.

> 8- New feature request: --allow and --deny works fine but I'm still able to 
> state that port as 'open' because ncat does respond to me. Is there a way to 
> make ncat show it's open port as 'closed' when the Ip is denied? This would 
> really be useful to hide our ncat from people scanning our servers (perhaps 
> using nmap?!)

Sorry, that would require something lower level.

> 9- Trying "ncat --socks4-server -l 5001" didn't work for me neither. Firefox 
> gets a page, but that page has four null bytes at the beginning. I'm 
> attaching the tcpdump capture file [ncat-socks-1.pcap], and the file firefox 
> makes me 'save' because it didn't know the protocol [firefox-save.bin].
> All the ncat server says is:
> ncat --socks4-server -l 5001 -vvv
> Listening on 0.0.0.0:5001
> DEBUG: SOCKS4 request from 209.68.27.16:
> DEBUG: VN: 4
> DEBUG: CD: 1
> DEBUG: Port: 80
> DEBUG: Addr: 209.68.27.16
> DEBUG: Null: 0

OK, thank you.  I haven't begun messing with this (and it is labeled broken in
the code), but I'll be sure to look at your example when I start.

> 10- ncat: invalid option -- r

Rather than fixing this, I think the -r reference should just be removed
all-together.  --sendonly doesn't have an equivalent, and it's obviously not
even working.

> 11- ncat: unrecognized option `--send-only'

As implemented, there are no hyphens in these options.  The man page is
incorrect, but I prefer the hyphens so I'll change it unless there is any
objection.  The netcat6 package I've used on Ubuntu uses hyphens for these
options as well.

> 12- Performance and cpu compare:
> Being /tmp/b a 10Mb file created from /dev/zero with dd
>
> With nc:
> nc -l -p 9000 > /tmp/a
> nc localhost 9000 < /tmp/b
> Time: pair of seconds. No notable cpu usage
>
> With ncat:
> ncat -l 9000 > /tmp/a
> ncat localhost 9000 < /tmp/b
> Time: Almost 35 seconds. 100% cpu usage all that time.
>
> Also ncat send 1024 packets, and nc send 139. I'm attaching both pcaps 
> [tcpdump-nc-file-transfer.pcap and tcpdump-ncat-file-transfer.pcap]
>
>
> 13- I'm not sure to report this, but during 12- test, I was able to capture 
> every packet with tcpdump from the 'nc' test as soon as the travel across the 
> wire, but with 'ncat' the same tcpdump shows me packets 31 seconds after the 
> connection started. You can see the time problem in the packets into the pcap 
> file attached. Is anyone having the same troubel here? I 
> used: 'tcpdump -n -s0 -i lo', with tcpdump version 3.9.8 and libpcap version 
> 0.9.8

Hmm... I'll look into these.

> 14- ncat --broker --talk -l 9000 works fine except that users start to count 
> from <user4>. Is this ok? It can make you believe that 3 previous users were 
> connected. And i'm sure i'm alone here.

That's because the number is based on the file descriptor value used by the
server.  0 is stdin, so that's used if you're speaking from the server.  The
others start at 4 because 1=stdout, 2=stderr and 3=listening socket.

> well, thats all for now...

That's plenty :)

> cheers and thanks!
>
> eldraco

Thank you for your help and testing!,
Kris Katterjohn


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSIWF/v9K37xXYl36AQLgAg//do4RFTTmPoDkBPsppsJ42veJ/gLDwug1
hLWr/dtsXgES7Ff/qQvFgAPBzwRWfukRfDYLM1qyPvQA2km/CZCueIKo4HJDDP/K
1BgZbzXrUpj319HRUA4abkp91DkwkO4jsqdO/fKhoYF77XCwhw9uT1rAKcH123oJ
6U4JopqJhirfEA/47czBSZhbV/P2HkejX7NX33P4gIJjB1mvzC0LjGH8JvPC4RDE
Ya+xk/YC2EZUAFGpZXdeVD3RYA+GoHYI5i8K7AWTJKyvtpcVZD4zQYBVoNzaEwaQ
x2J0J7f/nIJ9YX9sb0gMpI3gXMpfJhZT8NSGI4kkOnrEh1LZTcKy7T50Vh0f4Y4S
evih5rzNxLxweSxpCMNlvT1SdY4nXcesFm9ldO8CEQsq4hAzORT1S0Tg/S+06gwv
U5/K3f1V5nYdbGXTBE81p+DXjkmOE/o885M2VtNCwd2MBzuLJvOK0dXp8PyCZo65
jUs9DzAA1cUYsqjZMeyrSqYq5vKJtlluXhKSPr8SuvEf+3+/9rWSdGLTN4oevmbR
4ERwmAKSTqy3nLWNSFw8PLb6yzVFJgS0RlGOsCOGh4jQGcBGLDmhgkmKIG6JvzDv
4WsTQBmPjOGPv2Sifld10ECXkrmqa/uo87Q7Lji6Ib2vQU7iUZhj1quZEXsoHToL
g/eOrEx/b7Q=
=duge
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org