On Tue, Jul 12, 2005 at 11:46:58AM +0100, Chris Gibson wrote:
>
> I've appended a copy of the initial documentation for Ncat, which is basically
> the initial formation of the man page.
This looks great! I can think of many ways that I'll use this.
> etc are still open to interpretation. I am also aware that the list of switches
> does not go in alphabetical order. I'm in the process of fixing this
> issue :)
I'm not sure they need to be alphabetized anyway. The advantage to
alphabetizing is that people can easily locate a specific option. But
most people read man pages in a terminal window, where they can easily
search for an option (the '/' command in my man pager). Maybe see if
you can group them by functionality. For example, it makes sense to
have options -o (ASCII output to file) and -x (hex output to file)
together, even though they are far apart alphabetically.
> Proxy incoming connections on port `8081' through proxy-
> host.com on port 1080 to otherhost.net on port `9899' using
> the user `foobar'
> ncat -l 8081 --exec "ncat --socks-proxy proxy-
> host.com:1080,otherhost.net:9899 --socks-user foobar"
I think the target host and port should be specified at the end of the
command line as usual rather than in the --socks-proxy argument. For
example:
No proxy:
ncat otherhost.net 9899
With proxy:
ncat --socks-proxy proxy-host.com:1080 otherhost.net 9899
Also, you should be able to chain proxies together. So a --socks-user
option doesn't work very well. If you are going to support proxy
authentication (sounds like a good idea, actually), you should be able
to specify the proxy in URL-style format:
user:pass_at_host:port
If no pass given, then prompt. If no username given, go anon (if the
protocol allows it) or maybe a default that other applications use.
But not the Ncat user's real user name.
> HOST1$ ncat --secured -l 9899 > fat_file
> HOST2$ ncat --send-only --secured --idle-ms 8000 foobar
> 9899 < mylargefile
How will --secured prompt for the password in the HOST2 case? I
suppose you could offer a password command-line argument (as an
alternative to the default prompting, with a big security warning in
the man page), or write code to grab the passphrase from the terminal
rather than stdin if you detect that the differ (the former is
probably easier).
> -i, --idle-ms [TIME]
> Set the delay interval for lines sent.
> Passing this command limits the number of
> lines that Ncat will send in the specified
> period. This is specified in milliseconds
> for maximum flexibility. This may be useful
> for low bandwidth sites, or have other uses
> such as annoying iptables --limit options?
> Minimum fixed value of 500ms.
Why have such a minimum? If someone wants to wait 100ms between
lines, I say more power to them.
> -o, --output [FILE]
> ASCII text dump with timestamps of protocol
> chatter from your session.
>
> -x, --hex-dump [FILE]
> Hexdump of the session. (I think?) This can
> be used by other applications to 'replay'
> the session.
I would be interested in seeing examples of what these look like.
> -i, --idle-ms [TIME]
> -t, --idle-timeout [TIME]
I don't like how these are named so similarly yet do completely
different things. Maybe the first one should be --line-delay or some
such. Also, maybe --idle-timeout should be -w instead of -t since
that is what Netcat uses. On the other hand, you use milliseconds
(which I like), while nc uses seconds. So maybe using the same
argument would be confusing. And -t may be easier to remember for non
nc users. OK, nevermind :).
> -a, --address [HOST]
> Set the address for Ncat to bind to
> locally.
nc uses -s for this and Nmap uses -S. Also --address is a little
ambiguous since ncat takes many types of addresses. If you don't want
to use capital letters (which I suppose is reasonable), then -S won't
do. And -s is already used for --secure. I would suggest either
renaming secure and using -s, or using -b and --bind.
> --socks-proxy [SOCKS-PROXY-HOST]:[SOCKS-PROXY-
> PORT],[HOST]:[PORT]
See my notes above.
> --socks-user [NAME]
> Set the SOCKS4 username you wish to supply
> during a --socks-proxy based connection.
> Without this option the default will be to
> supply your login username during the
> SOCKS4 connection.
I don't think it should have such a default. It would be too easy for
people to disclose their username accidentally. Also as discussed
above, I think authentication credentials should be included in the
--socks-proxy option so that chaining works. The --socks-proxy option
text should note this chaining capability.
On an unrelated note, I think this man page would benefit from a
paragraph or four of introduction/summary at the beginning.
> --ssl Use in conjunction with your normal socket
> operations (either --listen or --connect)
> to cause Ncat to either connect using SSL
> or to listen on a port as an SSL server.
If --connect exists, then it should be documented in the man page.
Personally, I'm not sure it is needed.
> --broker <[PORT],[PORT],[PORT],...>
> Not sure how this is going to work yet. So
> this space is intentionally left blank:
You may not know the specifics yet, but you can document what it is
for. Allowing multiple parties to connect to a central (ncat) server
and communicate with each other. Thus, Ncat can broker communication
between systems that are behind a NAT or otherwise unable to directly
connect.
> --deny <[HOST],[HOST],[HOST],...>
> Issue Ncat with a list of hosts that will
Note that these can be CIDR netblocks too (e.g. 192.168.0.0/16).
> --allow <[HOST],[HOST],[HOST],...>
> The list of hosts specified will be the
Ditto.
I'm looking forward to the new Ncat, and I hope this helps!
-Fyodor
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Received on Jul 13 2005
Intro
