Rev | Author | # | Line |
---|---|---|---|
6 | AristotlePagaltzis | 1 | NetCat is a tool for connecting stdin(3)/stdout(3) to a [TCP]/[UDP] connection, giving [Shell] scripts the power to excercise or even provide network services. |
1 | IanMcDonald | 2 | |
6 | AristotlePagaltzis | 3 | It was initially written for [Unix] by someone known only as <i>Hobbit</i> and released as public domain. Development of this tool continued up to version 1.10. nc(1) is the ManPage for this tool, and it can be installed on [Debian] using <tt>apt-get install netcat</tt>. |
1 | IanMcDonald | 4 | |
6 | AristotlePagaltzis | 5 | > It is freely given away to the Internet community in the hope that it will be useful, with no restrictions except giving credit where it is due. No [GPL]s, [Berkeley copyrights | BSDLicense] or any of that nonsense. |
4 | CraigBox | 6 | |
6 | AristotlePagaltzis | 7 | There is now a fully [POSIX]-compatible rewrite known as [GNU Netcat | http://netcat.sourceforge.net/]. It is maintained by Giovanni Giacobbi and has been referred to as "[netcat ran through indent|http://mike.filespanker.com/post/67/]". |
5 | CraigBox | 8 | |
6 | AristotlePagaltzis | 9 | > Netcat is a featured networking utility which reads and writes data across network connections, using the [TCP/IP] [Protocol]. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities. |
5 | CraigBox | 10 | |
6 | AristotlePagaltzis | 11 | To complicate matters, there is also another rewrite called [netcat6 | http://netcat6.sourceforge.net/] to adds support for [IPv6] networks to the original utility. |
5 | CraigBox | 12 | |
7 | JimCheetham | 13 | --- |
14 | |||
15 | From an email exchange on the CLUG List | ||
16 | |||
17 | >> Without thinking too hard, I thought that was what the listener/server-end netcat was supposed to do ... quit when the connection to it dies ... | ||
18 | > | ||
19 | > | ||
20 | > One connection or both connections? Because netcat always uses two... | ||
21 | |||
22 | |||
23 | Well, you might be using netcat for something I've not. The listener end of netcat will shut down when the client end closes the port, this is a given ... however, the client end does not by default close the port when it's stdin reaches EOF ... | ||
24 | |||
25 | From "man nc" | ||
26 | |||
27 | > Your standard input is then sent | ||
28 | > to the host, and anything that comes back across the connection is sent | ||
29 | > to your standard output. This continues indefinitely, until the net- | ||
30 | > work side of the connection shuts down. Note that this behavior is | ||
31 | > different from most other applications which shut everything down and | ||
32 | > exit after an end-of-file on the standard input. | ||
33 | |||
34 | |||
35 | What do you mean, netcat always uses two connections? There's stdin and stdout, for sure, but only one network connection ... perhaps I'm thinking at a lower level than you are. | ||
36 | |||
37 | > Dito for the client - perhaps the client doesn't want to send anything | ||
38 | > (</dev/null) and only receive - you can't do that currently, as the | ||
39 | > client buggers off faster than you can look. | ||
40 | |||
41 | |||
42 | OK, an example must be needed ... I'll start a listener that sends data (rather like a mail server sends out an identification message when you connect), and then connect to it ... Two sessions, A and B ... | ||
43 | |||
44 | <verbatim> | ||
45 | A$ echo "Hello" | nc -l -p 7777 > /tmp/reply | ||
46 | |||
47 | B$ nc localhost 7777 | ||
48 | Hello | ||
49 | </verbatim> | ||
50 | |||
51 | after a couple of seconds to absorb the importance of the word "Hello", I'll type into stdin of B's netcat ... | ||
52 | |||
53 | <verbatim> | ||
54 | Greetings | ||
55 | ^D | ||
56 | </verbatim> | ||
57 | |||
58 | B's netcat doesn't quit, even though I've sent EOF. A's netcat doesn't quit, either. /tmp/reply has been populated though, and I can see its contents from another session ... | ||
59 | |||
60 | <verbatim> | ||
61 | $ od -a /tmp/reply | ||
62 | 0000000 G r e e t i n g s nl | ||
63 | 0000012 | ||
64 | </verbatim> | ||
65 | |||
66 | I can put more stuff into B's netcat, and finally get fed up and terminate it with ^C ... at which point A's netcat listener terminates. | ||
67 | The contents of /tmp/reply haven't changed, though, because the shell redirection has been 'completed' when the EOF at the end of "Greetings" was sent. | ||
68 | |||
69 | If I didn't redirect the netcat listener's stdout, there would still be a stop on output when the EOF came through ... this is what you would see from the shell sesion ... | ||
70 | |||
71 | <verbatim> | ||
72 | A$ echo "hello" | nc -l -p 7777 | ||
73 | Greetings | ||
74 | A$ | ||
75 | |||
76 | (I've made my ^D characters visible below :- | ||
77 | B$ nc localhost 7777 | ||
78 | hello | ||
79 | Greetings | ||
80 | ^D | ||
81 | More Stuff | ||
82 | ^D | ||
83 | B$ | ||
84 | </verbatim> | ||
85 | |||
86 | We're also reminded by ChrisSawtell that there are multiple implementations of netcat out there :- | ||
87 | |||
88 | <pre> | ||
89 | On Fri, 13 Aug 2004 23:35, Volker Kuhlmann wrote: | ||
90 | On Fri 13 Aug 2004 10:43:35 NZST +1200, Christopher Sawtell wrote: | ||
91 | To my knowledge there are at least three netcats. | ||
92 | |||
93 | It appears that there is also some reason for SuSE to put their change | ||
94 | into the netcat they're shipping, and that that particular | ||
95 | implementation isn't totally cleanly implemented. | ||
96 | That's the case for the original l0pht one. | ||
97 | |||
98 | Can you recommend any other one(s)? | ||
99 | Gnu ~NetCat | ||
100 | http://netcat.sourceforge.net/ | ||
101 | Local source mirror | ||
102 | ftp://ftp2.jetstreamgames/gentoo/distfiles/netcat-0.7.1.tar.bz2 | ||
103 | I have built this one and I use it. It works. | ||
104 | Note that it's different from the original L0pht original. | ||
105 | |||
106 | Then there is another one created by an Australian by the name of Mark Pulford | ||
107 | http://www.kyne.com.au/~mark/software/ncat.php | ||
108 | http://www.kyne.com.au/~mark/software/ncat-1.0.1.tar.gz | ||
109 | I have not used this one. I merely know of its existence, but it's probably | ||
110 | well worth trying. I have used another of the author's tools successfully. | ||
111 | |||
112 | The Original L0pht ~NetCat:- | ||
113 | http://www.atstake.com/research/tools/network_utilities/ | ||
114 | http://www.atstake.com/research/tools/network_utilities/nc110.tgz | ||
115 | Local mirror:- | ||
116 | ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/nc110.tgz | ||
117 | This is a 'Swiss Army Knife for the Internet". | ||
118 | It's a real double edged sword too. | ||
119 | |||
120 | There are lots of patches for it around, e.g.:- | ||
121 | ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/nc-v6-20000918.patch.gz | ||
122 | ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/netcat-110-r6-gentoo-deb-patches.tbz2 | ||
123 | |||
124 | I have used this one with both the patches applied. | ||
125 | It worked for me, but not under any difficult conditions, i.e. just moving | ||
126 | files across the local lan. | ||
127 | </pre> | ||
128 | |||
129 | It appears [OpenBSD] has their own version that includes proxy support [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/] | ||
130 | |||
131 | !!Bidirectional netcat ... | ||
132 | While netcat is excellent, one thing it doesn't seem to do is to work as a generic proxy between two applications. The shell doesn't help, providing only unidirectional pipelines ... but with the use of FIFO pipes (sorry, not under [Cygwin]) you can construct something that will do the job. | ||
133 | |||
134 | From http://www.ists.dartmouth.edu/library/classroom/nc-intro.v0.80.php :- | ||
135 | > <verbatim> | ||
136 | > mknod backpipe p | ||
137 | > nc -l -p 80 0<backpipe | tee -a inflow | nc localhost 81 | tee -a outflow 1>backpipe | ||
138 | > </verbatim> | ||
139 | |||
140 | You only have to do the mknod once, in order to create a pipe entity on the filesystem. Have a look in the files =inflow= and =outflow= to see the stored results of your conversation. | ||
141 | |||
142 | I just wanted to document a tip I found for using tcpdump and ethereal over a network. This might be because (for example) one box doesn't run ethereal due to resource restrictions or lack of X libraries. | ||
143 | |||
144 | On the remote machine - | ||
145 | |||
146 | <verbatim> | ||
147 | |||
148 | tcpdump -w - not (host workstation and port 31337) | nc workstation 31337 | ||
149 | |||
150 | </verbatim> | ||
151 | |||
152 | This takes the out put of tcpdump and dumps it in a file, but the file is stdout (-w -). tcpdump is set to *not* log port 31337 on the workstation. stdout is then piped to [netcat] which transmits it over port 31337 to workstation (thats why we are not logging port 31337 on workstation, or we would be logging ourselves logging ourselves logging ourselves....ad infinitum) | ||
153 | |||
154 | on the local machine (with ethereal) | ||
155 | |||
156 | <verbatim> | ||
157 | |||
158 | nc -l -p 31337 | ethereal -i - -k -l | ||
159 | |||
160 | </verbatim> | ||
161 | |||
162 | This again uses netcat to receive the data stream on port 31337 and feeds it to ethereal. Nifty huh? | ||
163 | |||
164 | I have to give credit for this to Adam Boileau on the nzlug list, I thought it was so good I had to record it. |
lib/blame.php:177: Warning: Invalid argument supplied for foreach()