1NETSNIFF-NG(8) User Manuals NETSNIFF-NG(8)
2
6 netsniff-ng - the packet sniffing beast
7
9 netsniff-ng [-d netdev] [-p pcap-file] [-r pcap-file] [-i pcap-file]
10 [-f bpf-file] [-t pkt-type] [-b cpu-range] [-B cpu-range]
11 [-S ring-size] [-e regex] [-IMHQnsqlxCXNvh]
12
14 netsniff-ng is is a free (GPL), performant Linux network sniffer for
15 packet inspection.
16 The gain of performance is reached by zero-copy mechanisms, so that the
18 kernel does not need to copy packets from kernelspace to userspace.
19 For this purpose netsniff-ng is libpcap independent, but nevertheless
21 supports the pcap file format for capturing, replaying and performing
22 offline-analysis of pcap dumps. Furthermore we are focussing on
23 building a robust, clean and secure analyzer and utilities that
24 complete netsniff-ng as a support for penetration testing.
25 netsniff-ng can be used for protocol analysis, reverse engineering and
27 network debugging.
28
30 -d <netdev>, --dev <netdev>
31 <netdev> defines the packet capturing device. This can for instance
32 be a typical device like eth0 or wlan0. Running netsniff-ng without
33 a given device parameter, it looks for up and running networking
34 devices and selects the first device that has been found.
35 -p <pcap-file>, --dump <pcap-file>
37 netsniff-ng stores the captured packets into the given <pcap-file>.
38 It understands the PCAP specification, so that dumps can be read or
39 postprocessed with other tools, too. Usually, this option should be
40 combined with --silent and --bind-cpu to win some performance.
41 -r <pcap-file>, --replay <pcap-file>
43 The given <pcap-file> will be replayed via a memory mapped
44 kernelspace TX_RING. A BPF filter may be combined to only replay
45 parts of the PCAP formatted file.
46 -i <pcap-file>, --read <pcap-file>
48 <pcap-file> will be read in and printed to the console in order to
49 perform an offline analysis. Same here: a BPF may be combined to
50 only show relevant parts of the PCAP formatted file. Next to this,
51 packet printing that are enabled on the normal mode are supported,
52 too.
53 -f <bpf-file>, --filter <bpf-file>
55 Attaches a Berkeley Packet Filter to the socket in order to
56 pre-filter traffic within the kernel. Example files are given
57 within /etc/netsniff-ng/rules/. The section BERKELEY PACKET FILTER
58 describes how to write filter files.
59 -t <pkt-type>, --type <pkt-type>
61 A <pkt-type> specification allows to post-filter packets within
62 userspace context (therefore slower than BPF). The following types
63 are supported: host - only show incoming packets to our host,
64 broadcast - only show Broadcast packets, multicast - only show
65 Multicast packets, others - only show packets from other hosts
66 (promiscuous mode), outgoing - only show outgoing packets from our
67 host
68 -b <cpu-range>, --bind-cpu <cpu-range>
70 Force system scheduler to schedule netsniff-ng only on specific
71 CPUs. Parameters may be 0 for using only CPU0, 0,1 for using CPU0
72 and CPU1 or even 0-4 for using a whole CPU range. If you have a
73 customized init process that leaves out a special CPU you could
74 bind netsniff-ng on that free CPU for maximal performance. On the
75 other hand, you can avoid scheduling netsniff-ng on CPUs which are
76 reserved for other critical tasks. This can also be combined with
77 taskset(1) in order to reschedule other processes on other CPUs to
78 let netsniff-ng run on its own CPU.
79 -B <cpu-range>, --unbind-cpu <cpu-range>
81 Force system scheduler to not schedule netsniff-ng on specific
82 CPUs. The parameter syntax is equivalent to -b and also the
83 semantics are inverted to -b.
84 -S <ring-size>, --ring-size <size>
86 This manually sets the desired ring size for RX_RING or TX_RING.
87 You should only use this option, if you know what you are doing,
88 because choosing a ring size which is too large for your system,
89 the kernel does neither warn you nor throws an error. It simply
90 kills other processes to grab their space. The parameter can be
91 defined in KB, MB or GB as 10MB for a 10 Megabyte ring size.
92 -I, --info
94 Shows information about available networking devices.
95 -M, --no-promisc
97 Forbids the NIC to enter the promiscuous mode. The promiscuous mode
98 is activated by default. It is a configuration of a network card
99 that makes the card pass all traffic it receives to the central
100 processing unit rather than just frames addressed to it. Well, do
101 not ask yourself why you cannot see traffic by others within a
102 switched network. Unlike old hubs, switches are some kind of
103 intelligent devices with internal ARP tables for each port in order
104 to reduce traffic load and prevent sniffing other connections. If
105 you really intent to sniff others traffic, go read about ARP cache
106 poisoning / MITM.
107 -H, --prio-norm
109 This option prevents to automatically high priorize itself.
110 Normally, netsniff-ng will be scheduled with high priority thus it
111 use the full CPU timeslice.
112 -Q, --notouch-irq
114 If netsniff-ng will be bound to a single CPU, say CPU0, then it
115 automatically rebinds the NIC interrupt affinity to that CPU, too
116 for a better performance. This feature is intended to be enabled on
117 non-wireless interfaces. notouch-irq forbids netsniff-ng to move
118 the IRQ affinity.
119 -n, --non-block
121 Lets netsniff-ng run in non-blocking mode. Generally, you won’t
122 need this feature very often unless there is some interest in
123 performance behaviour analysis. This will bypass the ring polling
124 mechanism thus CPU load will most certainly rise to 100 percent.
125 -s, --silent
127 Does not print packets to the terminal.
128 -q, --less
130 Prints one-liner information summary per packet.
131 -l, --payload
133 Shows only the payload information of the packet.
134 -x, --payload-hex
136 Shows only the payload information of the packet in hexadecimal
137 format.
138 -C, --c-style
140 Instead of printing packet in usual hex format, a copy-and-paste C
141 like format will be printed to the terminal.
142 -X, --all-hex
144 Shows not only the payload in hexadecimal format, but the whole
145 packet.
146 -N, --no-payload
148 Shows only the packet header, not the payload.
149 -e <regex>, --regex <expr>
151 Regular expression printing is useful for grepping ASCII text out
152 of packets, say certain HTML code for instance. Beware, that this
153 has a impact on performance. Regular expressions that comply with
154 the POSIX extended regular expression format are allowed.
155 -v, --version
157 Shows version number and exits.
158 -h, --help
160 Shows help and exits.
161
163 The Berkeley Packet Filter or BSD Packet Filter was first introduced in
164 1993 by Steven McCanne and Van Jacobson at the USENIX. Its purpose is
165 to filter packets within the kernel as early as possible, so that only
166 the relevant packets will be brought to the user-level process.
167 The Linux kernel has adapted this feature, which nowadays is available
169 in PF_PACKET. BPF therefore uses a register-based filter-machine that
170 is efficient on todays RISCs. Since most applications of a packet
171 filter reject far more packets than they accept and, thus, good
172 performance of the packet filter is critical to good overall
173 performance [1]. This should also be kept in mind during development of
174 filters.
175 If you don’t want to write your own filters, we currently ship some
177 examples within /etc/netsniff-ng/rules/ that can be used with
178 netsniff-ngs -f option. Furthermore tcpdump -dd provides filter
179 creation that netsniff-ng can read, but be warned - most certainly you
180 might need to edit the return value, which defines the packet snaplen
181 for your needs. Read section NOTES for more information about this. In
182 future versions netsniff-ng will also ship its own filter compiler for
183 a simple usage.
184 If you are an advanced user and if you would like to have full control
186 of what should be filtered and what not, then writing your own filter
187 could be a suitable choice. Hence, in the following the language
188 specification will be described in short with given examples on how to
189 use it.
190 The BPF pseudo-machine consists of an accumulator, an index register
192 (X), a scratch memory store and an implicit program counter. Operations
193 on this machine can be categorized into (all the following refering to
194 [1]):
195 1. Load instructions: Load instructions copy a value into the
197 accumulator or index register. The source can be an immediate
198 value, packet data at a fixed offset, packet data at a variable
199 offset, the packet length, or the scratch memory store.
200 2. Store instructions: Store instructions copy either the accumulator
202 or index register into the scratch memory store.
203 3. ALU instructions: ALU instructions perform arithmetic or logic on
205 the accumulator using the index register or a constant as an
206 operand.
207 4. Branch instructions: Branch instructions alter the flow of
209 control, based on comparison test between a constant or x register
210 and the accumulator.
211 5. Return instructions: Return instructions terminate the filter and
213 indicated what portion of the packet to save. The packet is
214 discarded entirely if the filter returns 0.
215 6. Misc instructions: Misc instructions comprise everything else -
217 currently, register transfer instructions.
218 The instruction format is of fixed length that is defined as the
220 following:
221 +-----------+------+------+------+
223 | opcode:16 | jt:8 | jf:8 | k:32 |
224 +-----------+------+------+------+
225 The opcode field indicates the instruction type and addressing modes.
227 The jt and jf fields are used by the conditional jump instructions and
228 are the offsets from the next instruction to the true and false
229 targets. The K field is a generic field used for various purposes.
230 All values are 32 bit words.
232 The Linux kernel has adapted this within linux/filter.h:
234 struct sock_filter { /* Filter block */
236 __u16 code; /* Actual filter code */
237 __u8 jt; /* Jump true */
238 __u8 jf; /* Jump false */
239 __u32 k; /* Generic multiuse field */
240 };
241 struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
243 unsigned short len; /* Number of filter blocks */
244 struct sock_filter __user *filter;
245 };
246 The instruction set is similar to assembler syntax. There are several
248 instruction classes which are similar to the previous categorization:
249 LD 0x00 Copy indicated value into accumulator
251 LDX 0x01 Copy indicated value into index register
252 ST 0x02 Copy accumulator value into the scratch memory store
253 STX 0x03 Copy index register value into the scratch memory store
254 ALU 0x04 Perform arithmetic or logic operation on the accumulator
255 JMP 0x05 Perform a branch instruction
256 RET 0x06 Return/exit from filter program
257 MISC 0x07 Data transfer between index register and accumulator
258 Next to classes, there are class-specific fields which are usually
260 combined with bitwise OR:
261 LD/LDX specific fields:
263 Size:
265 W 0x00 Unsigned Word (32 Bit)
266 H 0x08 Unsigned Halfword (16 Bit)
267 B 0x10 Unsigned Byte
268 Mode:
270 IMM 0x00 Literal value stored in K
271 ABS 0x20 Byte, halfword or word at offset K in the packet
272 IND 0x40 Byte, halfword or word at offset X + K in the packet
273 MEM 0x60 Word at offset K in the scratch memory store
274 LEN 0x80 Length of the packet
275 MSH 0xa0 4*([K]&0xf): four times the value of the low four bits
276 of the byte at offset K in the packet
277 ALU/JMP operations perform the indicated operation using the
279 accumulator and operand, and store the result back into the
280 accumulator. Division by zero terminates the filter.
281 ALU/JMP specific fields:
283 Operation:
285 ADD 0x00 Addition
286 SUB 0x10 Subtraction
287 MUL 0x20 Multiplication
288 DIV 0x30 Division
289 OR 0x40 Bitwise OR
291 AND 0x50 Bitwise AND
292 LSH 0x60 Left Shift
293 RSH 0x70 Right Shift
294 NEG 0x80 Negation
295 (Jump, to an offset by the current instruction + JT/JF + 1)
297 JA 0x00 Jump to the current instruction + K + 1
299 JEQ 0x10 Jump if K or X equals accumulator
300 JGT 0x20 Jump if K or X is greater than accumulator
301 JGE 0x30 Jump if K or X is greater or equals the accumulator
302 JSET 0x40 Jump if K or X bitwise AND the accumulator > 0
303 Source:
305 K 0x00 Value stored in K
306 X 0x08 Value stored in the index register
307 RET specific fields:
309 Return val:
311 A 0x10 Value stored in the accumulator
312 K 0x00 Value stored in K
313 X 0x08 Value stored in the index register
314 The index register cannot use the packet addressing modes. Instead, a
316 packet value must be loaded into the accumulator and transferred to the
317 index register, via tax. This is not a common occurrence, as the index
318 register is used primarily to parse the variable length IP header,
319 which can be loaded directly via the 4*([k]&0xf) addressing mode.
320 MISC specific fields:
322 Operation:
324 TAX 0x00 Transfer value from accumulator into index register
325 TXA 0x80 Transfer value from index register to accumulator
326 Example filter:
328 netsniff-ngs filter parser treats all lines that doesn’t match a format
330 of { 0xYY, X, X, 0xYYYYYYYY }, (X: decimal value, Y: hex value) as
331 comments.
332 /etc/netsniff-ng/rules/arp.bpf:
334 1: { 0x28, 0, 0, 0x0000000c },
336 2: { 0x15, 0, 1, 0x00000806 },
337 3: { 0x06, 0, 0, 0xffffffff },
338 4: { 0x06, 0, 0, 0x00000000 },
339 The first instruction line is a load instruction, because we have
341 LD|H|ABS which results in 0x28. So the 16 Bit valued halfword at the
342 packet offset 0xc will be copied into the accumulator. This is the
343 Ethernet type field. Instruction line 2 belongs to the class JMP, more
344 specific JMP|JEQ and takes the value which is stored in K (0x806, the
345 Ethernet type identifier for ARP). If 0x806 equals the value that has
346 been loaded into the accumulator, the instruction pointer points to the
347 current instruction plus jt value (which is 0) plus 1. So we end up at
348 instruction line 3, which is the return opcode as RET|K. By using
349 0xffffffff as K, we tell the kernel that we would like to have a packet
350 snaplen of 0xffffffff, which means that we end up with the complete
351 (uncut) packet. 0xffffffff will be replaced by the real packet length
352 if the kernel detects packets less than a length of 0xffffffff. Well,
353 on the other hand we would trap into the jf value if we don’t have an
354 ARP packet. There, the instruction pointer will point to line 4 where
355 we tell the kernel to drop the packet. The length of 0 simply means: Do
356 not hand over the packet to the BPF attached socket.
357 In pretty-print this filter looks like:
359 (000) ldh [12]
361 (001) jeq #0x806 jt 2 jf 3
362 (002) ret #-1
363 (003) ret #0
364 Source: [1] http://www.tcpdump.org/papers/bpf-usenix93.pdf
366
368 This section will provide some figures about the performance of the
369 RX_RING and TX_RING. An IBM HS21 Blade with 2 x Intel Xeon E5430
370 (2.66GHz), 8 GB RAM, Broadcom NetXtreme BCM5704S Gigabit Ethernet cards
371 and a 2.6.31-14 kernel (Ubuntu Server 9.10) has been used for testing
372 purpose. The IXIA 400 has been used on the opposite side for traffic
373 generation (Gigabit wire speed). Date: 17 Sep 2010.
374 TX_RING, 1GbE:
376 The test was about flushing as much frames as possible of a fixed size.
378 The IXIA was the counterpart that showed the incoming figures. Figures
379 have been rounded to thousands.
380 Pkt size, TX_RING pps
382 64 422,000
383 128 422,000
384 250 402,000
385 500 239,000
386 750 162,000
387 1,000 122,000
388 1,500 82,000
389 RX_RING, 1GbE:
391 The test included the reception of frames into the ring buffer, a
393 counter increment per frame and the summation of the frame length.
394 Figures have been rounded to thousands.
395 64-Byte fixed
397 Pkt rate (IXIA), % of BW, RX_RING pps
398 100,000 6.75 100,000
399 175,000 11.76 175,000
400 250,000 16.80 250,000
401 500,000 33.60 338,000
402 1,000,000 67.20 354,000
403 1,488,000 100.00 303,000
404 250-Byte fixed
406 Pkt rate (IXIA), % of BW, RX_RING pps
407 100,000 21.60 100,000
408 175,000 37.80 175,000
409 250,000 54.00 244,000
410 463,000 100.00 381,000
411 500-Byte fixed
413 Pkt rate (IXIA), % of BW, RX_RING pps
414 100,000 41.60 100,000
415 175,000 72.80 169,000
416 240,000 100.00 226,000
417 1,500-Byte fixed
419 Pkt rate (IXIA), % of BW, RX_RING pps
420 82,000 100.00 82,000
421 IMIX distribution (64:7, 570:4, 1518:1)
423 Pkt rate (IXIA), % of BW, RX_RING pps
424 100,000 29.99 100,000
425 175,000 52.35 175,000
426 250,000 74.80 240,000
427 334,000 100.00 303,000
428 Tolly distribution (64:55, 78:5, 576:17, 1518:23)
430 Pkt rate (IXIA), % of BW, RX_RING pps
431 100,000 40.50 100,000
432 175,000 70.90 174,000
433 247,000 100.00 193,000
434
436 Dump packets on eth0 into a file:
437 netsniff-ng --dev eth0 --dump out.pcap --silent --bind-cpu 0
439 Replay a PCAP file via eth0:
441 netsniff-ng --dev eth0 --replay out.pcap --bind-cpu 0
443 Only show ICQ related packets:
445 netsniff-ng --filter /etc/netsniff-ng/rules/icq.bpf
447 Show only packet headers of a PCAP file:
449 netsniff-ng --read out.pcap --no-payload
451 Show only packets that match a regular expression:
453 netsniff-ng --regex "foo.*bar"
455 Show only outgoing packets in hex format from wlan0:
457 netsniff-ng --dev wlan0 --all-hex --type outgoing
459
461 If you try to create custom socket filters with tcpdump -dd, you have
462 to edit the ret opcode of the resulting filter, otherwise your payload
463 will be cut off:
464 0x6, 0, 0, 0xFFFFFFFF instead of 0x6, 0, 0, 0x00000060
466 The Linux kernel now takes skb→len instead of 0xFFFFFFFF. If you do not
468 change it, the kernel will take 0x00000060 as buffer length and packets
469 larger than 96 Byte will be cut off (filled with zero Bytes)!
470 Read http://dev.netsniff-ng.org/#4 for further technical details.
472
474 This program is distributed under the terms of the GNU General Public
475 License as published by the Free Software Foundation. See COPYING for
476 details on the License and the lack of warranty.
477
479 The latest version of this program can be found at
480 http://pub.netsniff-ng.org/netsniff-ng/.
481
483 Bugs, what bugs? ;-) Okay, seriously ...
484 The TX_RING is part of the kernel since 2.6.31. Needs kind of a
486 compatibility mode for older kernels.
487 Currently, we don’t have a BPF compiler built-in, so that either the
489 user needs to use filter definitions from /etc/netsniff-ng/rules,
490 tcpdump -dd or write his own filter by hand.
491 Please send problems, bugs, questions, desirable enhancements, etc. to
493 bugs@netsniff-ng.org.
494
496 git clone git://github.com/danborkmann/netsniff-ng.git
497
499 netsniff-ng was originally written by Daniel Borkmann
500 (daniel@netsniff-ng.org).
501 Current authors:
503 Daniel Borkmann (daniel@netsniff-ng.org), Emmanuel Roullit
505 (emmanuel@netsniff-ng.org)
506 http://www.netsniff-ng.org/
508 The manpage has been written by Daniel Borkmann.
510
512 bpf(4), pcap(3), tcpdump(8)
513
515 To my alma mater:
516 Leipzig University of Applied Science,
518 Faculty of Computer Science, Mathematics and Natural Sciences
519netsniff-ng 0.5.5.0 10/09/2010 NETSNIFF-NG(8)