document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #3018 from martin2011qi/master

Browse Source 
translated
辛苦了
This commit is contained in:
Xingyu.Wang 2015-07-11 15:44:49 +08:00
commit 1370e34a2f
2 changed files with 743 additions and 745 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

745
sources/tech/20150401 ZMap Documentation.md
View File

@ -1,745 +0,0 @@
translating...
ZMap Documentation
================================================================================
1. Getting Started with ZMap
1. Scanning Best Practices
1. Command Line Arguments
1. Additional Information
1. TCP SYN Probe Module
1. ICMP Echo Probe Module
1. UDP Probe Module
1. Configuration Files
1. Verbosity
1. Results Output
1. Blacklisting
1. Rate Limiting and Sampling
1. Sending Multiple Probes
1. Extending ZMap
1. Sample Applications
1. Writing Probe and Output Modules
----------
### Getting Started with ZMap ###
ZMap is designed to perform comprehensive scans of the IPv4 address space or large portions of it. While ZMap is a powerful tool for researchers, please keep in mind that by running ZMap, you are potentially scanning the ENTIRE IPv4 address space at over 1.4 million packets per second. Before performing even small scans, we encourage users to contact their local network administrators and consult our list of scanning best practices.
By default, ZMap will perform a TCP SYN scan on the specified port at the maximum rate possible. A more conservative configuration that will scan 10,000 random addresses on port 80 at a maximum 10 Mbps can be run as follows:
$ zmap --bandwidth=10M --target-port=80 --max-targets=10000 --output-file=results.csv
Or more concisely specified as:
$ zmap -B 10M -p 80 -n 10000 -o results.csv
ZMap can also be used to scan specific subnets or CIDR blocks. For example, to scan only 10.0.0.0/8 and 192.168.0.0/16 on port 80, run:
zmap -p 80 -o results.csv 10.0.0.0/8 192.168.0.0/16
If the scan started successfully, ZMap will output status updates every one second similar to the following:
0% (1h51m left); send: 28777 562 Kp/s (560 Kp/s avg); recv: 1192 248 p/s (231 p/s avg); hits: 0.04%
0% (1h51m left); send: 34320 554 Kp/s (559 Kp/s avg); recv: 1442 249 p/s (234 p/s avg); hits: 0.04%
0% (1h50m left); send: 39676 535 Kp/s (555 Kp/s avg); recv: 1663 220 p/s (232 p/s avg); hits: 0.04%
0% (1h50m left); send: 45372 570 Kp/s (557 Kp/s avg); recv: 1890 226 p/s (232 p/s avg); hits: 0.04%
These updates provide information about the current state of the scan and are of the following form: %-complete (est time remaining); packets-sent curr-send-rate (avg-send-rate); recv: packets-recv recv-rate (avg-recv-rate); hits: hit-rate
If you do not know the scan rate that your network can support, you may want to experiment with different scan rates or bandwidth limits to find the fastest rate that your network can support before you see decreased results.
By default, ZMap will output the list of distinct IP addresses that responded successfully (e.g. with a SYN ACK packet) similar to the following. There are several additional formats (e.g. JSON and Redis) for outputting results as well as options for producing programmatically parsable scan statistics. As wells, additional output fields can be specified and the results can be filtered using an output filter.
115.237.116.119
23.9.117.80
207.118.204.141
217.120.143.111
50.195.22.82
We strongly encourage you to use a blacklist file, to exclude both reserved/unallocated IP space (e.g. multicast, RFC1918), as well as networks that request to be excluded from your scans. By default, ZMap will utilize a simple blacklist file containing reserved and unallocated addresses located at `/etc/zmap/blacklist.conf`. If you find yourself specifying certain settings, such as your maximum bandwidth or blacklist file every time you run ZMap, you can specify these in `/etc/zmap/zmap.conf` or use a custom configuration file.
If you are attempting to troubleshoot scan related issues, there are several options to help debug. First, it is possible can perform a dry run scan in order to see the packets that would be sent over the network by adding the `--dryrun` flag. As well, it is possible to change the logging verbosity by setting the `--verbosity=n` flag.
----------
### Scanning Best Practices ###
We offer these suggestions for researchers conducting Internet-wide scans as guidelines for good Internet citizenship.
- Coordinate closely with local network administrators to reduce risks and handle inquiries
- Verify that scans will not overwhelm the local network or upstream provider
- Signal the benign nature of the scans in web pages and DNS entries of the source addresses
- Clearly explain the purpose and scope of the scans in all communications
- Provide a simple means of opting out and honor requests promptly
- Conduct scans no larger or more frequent than is necessary for research objectives
- Spread scan traffic over time or source addresses when feasible
It should go without saying that scan researchers should refrain from exploiting vulnerabilities or accessing protected resources, and should comply with any special legal requirements in their jurisdictions.
----------
### Command Line Arguments ###
#### Common Options ####
These options are the most common options when performing a simple scan. We note that some options are dependent on the probe module or output module used (e.g. target port is not used when performing an ICMP Echo Scan).
**-p, --target-port=port**
TCP port number to scan (e.g. 443)
**-o, --output-file=name**
Write results to this file. Use - for stdout
**-b, --blacklist-file=path**
File of subnets to exclude, in CIDR notation (e.g. 192.168.0.0/16), one-per line. It is recommended you use this to exclude RFC 1918 addresses, multicast, IANA reserved space, and other IANA special-purpose addresses. An example blacklist file is provided in conf/blacklist.example for this purpose.
#### Scan Options ####
**-n, --max-targets=n**
Cap the number of targets to probe. This can either be a number (e.g. `-n 1000`) or a percentage (e.g. `-n 0.1%`) of the scannable address space (after excluding blacklist)
**-N, --max-results=n**
Exit after receiving this many results
**-t, --max-runtime=secs**
Cap the length of time for sending packets
**-r, --rate=pps**
Set the send rate in packets/sec
**-B, --bandwidth=bps**
Set the send rate in bits/second (supports suffixes G, M, and K (e.g. `-B 10M` for 10 mbps). This overrides the `--rate` flag.
**-c, --cooldown-time=secs**
How long to continue receiving after sending has completed (default=8)
**-e, --seed=n**
Seed used to select address permutation. Use this if you want to scan addresses in the same order for multiple ZMap runs.
**--shards=n**
Split the scan up into N shards/partitions among different instances of zmap (default=1). When sharding, `--seed` is required
**--shard=n**
Set which shard to scan (default=0). Shards are indexed in the range [0, N), where N is the total number of shards. When sharding `--seed` is required.
**-T, --sender-threads=n**
Threads used to send packets (default=1)
**-P, --probes=n**
Number of probes to send to each IP (default=1)
**-d, --dryrun**
Print out each packet to stdout instead of sending it (useful for debugging)
#### Network Options ####
**-s, --source-port=port|range**
Source port(s) to send packets from
**-S, --source-ip=ip|range**
Source address(es) to send packets from. Either single IP or range (e.g. 10.0.0.1-10.0.0.9)
**-G, --gateway-mac=addr**
Gateway MAC address to send packets to (in case auto-detection does not work)
**-i, --interface=name**
Network interface to use
#### Probe Options ####
ZMap allows users to specify and write their own probe modules for use with ZMap. Probe modules are responsible for generating probe packets to send, and processing responses from hosts.
**--list-probe-modules**
List available probe modules (e.g. tcp_synscan)
**-M, --probe-module=name**
Select probe module (default=tcp_synscan)
**--probe-args=args**
Arguments to pass to probe module
**--list-output-fields**
List the fields the selected probe module can send to the output module
#### Output Options ####
ZMap allows users to specify and write their own output modules for use with ZMap. Output modules are responsible for processing the fieldsets returned by the probe module, and outputing them to the user. Users can specify output fields, and write filters over the output fields.
**--list-output-modules**
List available output modules (e.g. tcp_synscan)
**-O, --output-module=name**
Select output module (default=csv)
**--output-args=args**
Arguments to pass to output module
**-f, --output-fields=fields**
Comma-separated list of fields to output
**--output-filter**
Specify an output filter over the fields defined by the probe module
#### Additional Options ####
**-C, --config=filename**
Read a configuration file, which can specify any other options.
**-q, --quiet**
Do not print status updates once per second
**-g, --summary**
Print configuration and summary of results at the end of the scan
**-v, --verbosity=n**
Level of log detail (0-5, default=3)
**-h, --help**
Print help and exit
**-V, --version**
Print version and exit
----------
### Additional Information ###
#### TCP SYN Scans ####
When performing a TCP SYN scan, ZMap requires a single target port and supports specifying a range of source ports from which the scan will originate.
**-p, --target-port=port**
TCP port number to scan (e.g. 443)
**-s, --source-port=port|range**
Source port(s) for scan packets (e.g. 40000-50000)
**Warning!** ZMap relies on the Linux kernel to respond to SYN/ACK packets with RST packets in order to close connections opened by the scanner. This occurs because ZMap sends packets at the Ethernet layer in order to reduce overhead otherwise incurred in the kernel from tracking open TCP connections and performing route lookups. As such, if you have a firewall rule that tracks established connections such as a netfilter rule similar to `-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT`, this will block SYN/ACK packets from reaching the kernel. This will not prevent ZMap from recording responses, but it will prevent RST packets from being sent back, ultimately using up a connection on the scanned host until your connection times out. We strongly recommend that you select a set of unused ports on your scanning host which can be allowed access in your firewall and specifying this port range when executing ZMap, with the `-s` flag (e.g. `-s '50000-60000'`).
#### ICMP Echo Request Scans ####
While ZMap performs TCP SYN scans by default, it also supports ICMP echo request scans in which an ICMP echo request packet is sent to each host and the type of ICMP response received in reply is denoted. An ICMP scan can be performed by selecting the icmp_echoscan scan module similar to the following:
$ zmap --probe-module=icmp_echoscan
#### UDP Datagram Scans ####
ZMap additionally supports UDP probes, where it will send out an arbitrary UDP datagram to each host, and receive either UDP or ICMP Unreachable responses. ZMap supports four different methods of setting the UDP payload through the --probe-args command-line option. These are 'text' for ASCII-printable payloads, 'hex' for hexadecimal payloads set on the command-line, 'file' for payloads contained in an external file, and 'template' for payloads that require dynamic field generation. In order to obtain the UDP response, make sure that you specify 'data' as one of the fields to report with the -f option.
The example below will send the two bytes 'ST', a PCAnwywhere 'status' request, to UDP port 5632.
$ zmap -M udp -p 5632 --probe-args=text:ST -N 100 -f saddr,data -o -
The example below will send the byte '0x02', a SQL Server 'client broadcast' request, to UDP port 1434.
$ zmap -M udp -p 1434 --probe-args=hex:02 -N 100 -f saddr,data -o -
The example below will send a NetBIOS status request to UDP port 137. This uses a payload file that is included with the ZMap distribution.
$ zmap -M udp -p 1434 --probe-args=file:netbios_137.pkt -N 100 -f saddr,data -o -
The example below will send a SIP 'OPTIONS' request to UDP port 5060. This uses a template file that is included with the ZMap distribution.
$ zmap -M udp -p 1434 --probe-args=file:sip_options.tpl -N 100 -f saddr,data -o -
UDP payload templates are still experimental. You may encounter crashes when more using more than one send thread (-T) and there is a significant decrease in performance compared to static payloads. A template is simply a payload file that contains one or more field specifiers enclosed in a ${} sequence. Some protocols, notably SIP, require the payload to reflect the source and destination of the packet. Other protocols, such as portmapper and DNS, contain fields that should be randomized per request or risk being dropped by multi-homed systems scanned by ZMap.
The payload template below will send a SIP OPTIONS request to every destination:
OPTIONS sip:${RAND_ALPHA=8}@${DADDR} SIP/2.0
Via: SIP/2.0/UDP ${SADDR}:${SPORT};branch=${RAND_ALPHA=6}.${RAND_DIGIT=10};rport;alias
From: sip:${RAND_ALPHA=8}@${SADDR}:${SPORT};tag=${RAND_DIGIT=8}
To: sip:${RAND_ALPHA=8}@${DADDR}
Call-ID: ${RAND_DIGIT=10}@${SADDR}
CSeq: 1 OPTIONS
Contact: sip:${RAND_ALPHA=8}@${SADDR}:${SPORT}
Content-Length: 0
Max-Forwards: 20
User-Agent: ${RAND_ALPHA=8}
Accept: text/plain
In the example above, note that line endings are \r\n and the end of this request must contain \r\n\r\n for most SIP implementations to correcly process it. A working example is included in the examples/udp-payloads directory of the ZMap source tree (sip_options.tpl).
The following template fields are currently implemented:
- **SADDR**: Source IP address in dotted-quad format
- **SADDR_N**: Source IP address in network byte order
- **DADDR**: Destination IP address in dotted-quad format
- **DADDR_N**: Destination IP address in network byte order
- **SPORT**: Source port in ascii format
- **SPORT_N**: Source port in network byte order
- **DPORT**: Destination port in ascii format
- **DPORT_N**: Destination port in network byte order
- **RAND_BYTE**: Random bytes (0-255), length specified with =(length) parameter
- **RAND_DIGIT**: Random digits from 0-9, length specified with =(length) parameter
- **RAND_ALPHA**: Random mixed-case letters from A-Z, length specified with =(length) parameter
- **RAND_ALPHANUM**: Random mixed-case letters from A-Z and digits from 0-9, length specified with =(length) parameter
### Configuration Files ###
ZMap supports configuration files instead of requiring all options to be specified on the command-line. A configuration can be created by specifying one long-name option and the value per line such as:
interface "eth1"
source-ip 1.1.1.4-1.1.1.8
gateway-mac b4:23:f9:28:fa:2d # upstream gateway
cooldown-time 300 # seconds
blacklist-file /etc/zmap/blacklist.conf
output-file ~/zmap-output
quiet
summary
ZMap can then be run with a configuration file and specifying any additional necessary parameters:
$ zmap --config=~/.zmap.conf --target-port=443
### Verbosity ###
There are several types of on-screen output that ZMap produces. By default, ZMap will print out basic progress information similar to the following every 1 second. This can be disabled by setting the `--quiet` flag.
0:01 12%; send: 10000 done (15.1 Kp/s avg); recv: 144 143 p/s (141 p/s avg); hits: 1.44%
ZMap also prints out informational messages during scanner configuration such as the following, which can be controlled with the `--verbosity` argument.
Aug 11 16:16:12.813 [INFO] zmap: started
Aug 11 16:16:12.817 [DEBUG] zmap: no interface provided. will use eth0
Aug 11 16:17:03.971 [DEBUG] cyclic: primitive root: 3489180582
Aug 11 16:17:03.971 [DEBUG] cyclic: starting point: 46588
Aug 11 16:17:03.975 [DEBUG] blacklist: 3717595507 addresses allowed to be scanned
Aug 11 16:17:03.975 [DEBUG] send: will send from 1 address on 28233 source ports
Aug 11 16:17:03.975 [DEBUG] send: using bandwidth 10000000 bits/s, rate set to 14880 pkt/s
Aug 11 16:17:03.985 [DEBUG] recv: thread started
ZMap also supports printing out a grep-able summary at the end of the scan, similar to below, which can be invoked with the `--summary` flag.
cnf target-port 443
cnf source-port-range-begin 32768
cnf source-port-range-end 61000
cnf source-addr-range-begin 1.1.1.4
cnf source-addr-range-end 1.1.1.8
cnf maximum-packets 4294967295
cnf maximum-runtime 0
cnf permutation-seed 0
cnf cooldown-period 300
cnf send-interface eth1
cnf rate 45000
env nprocessors 16
exc send-start-time Fri Jan 18 01:47:35 2013
exc send-end-time Sat Jan 19 00:47:07 2013
exc recv-start-time Fri Jan 18 01:47:35 2013
exc recv-end-time Sat Jan 19 00:52:07 2013
exc sent 3722335150
exc blacklisted 572632145
exc first-scanned 1318129262
exc hit-rate 0.874102
exc synack-received-unique 32537000
exc synack-received-total 36689941
exc synack-cooldown-received-unique 193
exc synack-cooldown-received-total 1543
exc rst-received-unique 141901021
exc rst-received-total 166779002
adv source-port-secret 37952
adv permutation-gen 4215763218
### Results Output ###
ZMap can produce results in several formats through the use of **output modules**. By default, ZMap only supports **csv** output, however support for **redis** and **json** can be compiled in. The results sent to these output modules may be filtered using an **output filter**. The fields the output module writes are specified by the user. By default, ZMap will return results in csv format and if no output file is specified, ZMap will not produce specific results. It is also possible to write your own output module; see Writing Output Modules for information.
**-o, --output-file=p**
File to write output to
**-O, --output-module=p**
Invoke a custom output module
**-f, --output-fields=p**
Comma-separated list of fields to output
**--output-filter=filter**
Specify an output filter over fields for a given probe
**--list-output-modules**
Lists available output modules
**--list-output-fields**
List available output fields for a given probe
#### Output Fields ####
ZMap has a variety of fields it can output beyond IP address. These fields can be viewed for a given probe module by running with the `--list-output-fields` flag.
$ zmap --probe-module="tcp_synscan" --list-output-fields
saddr string: source IP address of response
saddr-raw int: network order integer form of source IP address
daddr string: destination IP address of response
daddr-raw int: network order integer form of destination IP address
ipid int: IP identification number of response
ttl int: time-to-live of response packet
sport int: TCP source port
dport int: TCP destination port
seqnum int: TCP sequence number
acknum int: TCP acknowledgement number
window int: TCP window
classification string: packet classification
success int: is response considered success
repeat int: is response a repeat response from host
cooldown int: Was response received during the cooldown period
timestamp-str string: timestamp of when response arrived in ISO8601 format.
timestamp-ts int: timestamp of when response arrived in seconds since Epoch
timestamp-us int: microsecond part of timestamp (e.g. microseconds since 'timestamp-ts')
To select which fields to output, any combination of the output fields can be specified as a comma-separated list using the `--output-fields=fields` or `-f` flags. Example:
$ zmap -p 80 -f "response,saddr,daddr,sport,seq,ack,in_cooldown,is_repeat,timestamp" -o output.csv
#### Filtering Output ####
Results generated by a probe module can be filtered before being passed to the output module. Filters are defined over the output fields of a probe module. Filters are written in a simple filtering language, similar to SQL, and are passed to ZMap using the **--output-filter** option. Output filters are commonly used to filter out duplicate results, or to only pass only sucessful responses to the output module.
Filter expressions are of the form `<fieldname> <operation> <value>`. The type of `<value>` must be either a string or unsigned integer literal, and match the type of `<fieldname>`. The valid operations for integer comparisons are `= !=, <, >, <=, >=`. The operations for string comparisons are =, !=. The `--list-output-fields` flag will print what fields and types are available for the selected probe module, and then exit.
Compound filter expressions may be constructed by combining filter expressions using parenthesis to specify order of operations, the `&&` (logical AND) and `||` (logical OR) operators.
**Examples**
Write a filter for only successful, non-duplicate responses
--output-filter="success = 1 && repeat = 0"
Filter for packets that have classification RST and a TTL greater than 10, or for packets with classification SYNACK
--output-filter="(classification = rst && ttl > 10) || classification = synack"
#### CSV ####
The csv module will produce a comma-separated value file of the output fields requested. For example, the following command produces the following CSV in a file called `output.csv`.
$ zmap -p 80 -f "response,saddr,daddr,sport,seq,ack,in_cooldown,is_repeat,timestamp" -o output.csv
----------
response, saddr, daddr, sport, dport, seq, ack, in_cooldown, is_repeat, timestamp
synack, 159.174.153.144, 10.0.0.9, 80, 40555, 3050964427, 3515084203, 0, 0,2013-08-15 18:55:47.681
rst, 141.209.175.1, 10.0.0.9, 80, 40136, 0, 3272553764, 0, 0,2013-08-15 18:55:47.683
rst, 72.36.213.231, 10.0.0.9, 80, 56642, 0, 2037447916, 0, 0,2013-08-15 18:55:47.691
rst, 148.8.49.150, 10.0.0.9, 80, 41672, 0, 1135824975, 0, 0,2013-08-15 18:55:47.692
rst, 50.165.166.206, 10.0.0.9, 80, 38858, 0, 535206863, 0, 0,2013-08-15 18:55:47.694
rst, 65.55.203.135, 10.0.0.9, 80, 50008, 0, 4071709905, 0, 0,2013-08-15 18:55:47.700
synack, 50.57.166.186, 10.0.0.9, 80, 60650, 2813653162, 993314545, 0, 0,2013-08-15 18:55:47.704
synack, 152.75.208.114, 10.0.0.9, 80, 52498, 460383682, 4040786862, 0, 0,2013-08-15 18:55:47.707
synack, 23.72.138.74, 10.0.0.9, 80, 33480, 810393698, 486476355, 0, 0,2013-08-15 18:55:47.710
#### Redis ####
The redis output module allows addresses to be added to a Redis queue instead of being saved to file which ultimately allows ZMap to be incorporated with post processing tools.
**Heads Up!** ZMap does not build with Redis support by default. If you are building ZMap from source, you can build with Redis support by running CMake with `-DWITH_REDIS=ON`.
### Blacklisting and Whitelisting ###
ZMap supports both blacklisting and whitelisting network prefixes. If ZMap is not provided with blacklist or whitelist parameters, ZMap will scan all IPv4 addresses (including local, reserved, and multicast addresses). If a blacklist file is specified, network prefixes in the blacklisted segments will not be scanned; if a whitelist file is provided, only network prefixes in the whitelist file will be scanned. A whitelist and blacklist file can be used in coordination; the blacklist has priority over the whitelist (e.g. if you have whitelisted 10.0.0.0/8 and blacklisted 10.1.0.0/16, then 10.1.0.0/16 will not be scanned). Whitelist and blacklist files can be specified on the command-line as follows:
**-b, --blacklist-file=path**
File of subnets to blacklist in CIDR notation, e.g. 192.168.0.0/16
**-w, --whitelist-file=path**
File of subnets to limit scan to in CIDR notation, e.g. 192.168.0.0/16
Blacklist files should be formatted with a single network prefix in CIDR notation per line. Comments are allowed using the `#` character. Example:
# From IANA IPv4 Special-Purpose Address Registry
# http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
# Updated 2013-05-22
0.0.0.0/8 # RFC1122: "This host on this network"
10.0.0.0/8 # RFC1918: Private-Use
100.64.0.0/10 # RFC6598: Shared Address Space
127.0.0.0/8 # RFC1122: Loopback
169.254.0.0/16 # RFC3927: Link Local
172.16.0.0/12 # RFC1918: Private-Use
192.0.0.0/24 # RFC6890: IETF Protocol Assignments
192.0.2.0/24 # RFC5737: Documentation (TEST-NET-1)
192.88.99.0/24 # RFC3068: 6to4 Relay Anycast
192.168.0.0/16 # RFC1918: Private-Use
192.18.0.0/15 # RFC2544: Benchmarking
198.51.100.0/24 # RFC5737: Documentation (TEST-NET-2)
203.0.113.0/24 # RFC5737: Documentation (TEST-NET-3)
240.0.0.0/4 # RFC1112: Reserved
255.255.255.255/32 # RFC0919: Limited Broadcast
# From IANA Multicast Address Space Registry
# http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
# Updated 2013-06-25
224.0.0.0/4 # RFC5771: Multicast/Reserved
If you are looking to scan only a random portion of the internet, checkout Sampling, instead of using whitelisting and blacklisting.
**Heads Up!** The default ZMap configuration uses the blacklist file at `/etc/zmap/blacklist.conf`, which contains locally scoped address space and reserved IP ranges. The default configuration can be changed by editing `/etc/zmap/zmap.conf`.
### Rate Limiting and Sampling ###
By default, ZMap will scan at the fastest rate that your network adaptor supports. In our experiences on commodity hardware, this is generally around 95-98% of the theoretical speed of gigabit Ethernet, which may be faster than your upstream provider can handle. ZMap will not automatically adjust its send-rate based on your upstream provider. You may need to manually adjust your send-rate to reduce packet drops and incorrect results.
**-r, --rate=pps**
Set maximum send rate in packets/sec
**-B, --bandwidth=bps**
Set send rate in bits/sec (supports suffixes G, M, and K). This overrides the --rate flag.
ZMap also allows random sampling of the IPv4 address space by specifying max-targets and/or max-runtime. Because hosts are scanned in a random permutation generated per scan instantiation, limiting a scan to n hosts will perform a random sampling of n hosts. Command-line options:
**-n, --max-targets=n**
Cap number of targets to probe
**-N, --max-results=n**
Cap number of results (exit after receiving this many positive results)
**-t, --max-runtime=s**
Cap length of time for sending packets (in seconds)
**-s, --seed=n**
Seed used to select address permutation. Specify the same seed in order to scan addresses in the same order for different ZMap runs.
For example, if you wanted to scan the same one million hosts on the Internet for multiple scans, you could set a predetermined seed and cap the number of scanned hosts similar to the following:
zmap -p 443 -s 3 -n 1000000 -o results
In order to determine which one million hosts were going to be scanned, you could run the scan in dry-run mode which will print out the packets that would be sent instead of performing the actual scan.
zmap -p 443 -s 3 -n 1000000 --dryrun | grep daddr
| awk -F'daddr: ' '{print $2}' | sed 's/ |.*//;'
### Sending Multiple Packets ###
ZMap supports sending multiple probes to each host. Increasing this number both increases scan time and hosts reached. However, we find that the increase in scan time (~100% per additional probe) greatly outweighs the increase in hosts reached (~1% per additional probe).
**-P, --probes=n**
The number of unique probes to send to each IP (default=1)
----------
### Sample Applications ###
ZMap is designed for initiating contact with a large number of hosts and finding ones that respond positively. However, we realize that many users will want to perform follow-up processing, such as performing an application level handshake. For example, users who perform a TCP SYN scan on port 80 might want to perform a simple GET request and users who scan port 443 may be interested in completing a TLS handshake.
#### Banner Grab ####
We have included a sample application, banner-grab, with ZMap that enables users to receive messages from listening TCP servers. Banner-grab connects to the provided servers, optionally sends a message, and prints out the first message received from the server. This tool can be used to fetch banners such as HTTP server responses to specific commands, telnet login prompts, or SSH server strings.
This example finds 1000 servers listening on port 80, and sends a simple GET request to each, storing their base-64 encoded responses in http-banners.out
$ zmap -p 80 -N 1000 -B 10M -o - | ./banner-grab-tcp -p 80 -c 500 -d ./http-req > out
For more details on using `banner-grab`, see the README file in `examples/banner-grab`.
**Heads Up!** ZMap and banner-grab can have significant performance and accuracy impact on one another if run simultaneously (as in the example). Make sure not to let ZMap saturate banner-grab-tcp's concurrent connections, otherwise banner-grab will fall behind reading stdin, causing ZMap to block on writing stdout. We recommend using a slower scanning rate with ZMap, and increasing the concurrency of banner-grab-tcp to no more than 3000 (Note that > 1000 concurrent connections requires you to use `ulimit -SHn 100000` and `ulimit -HHn 100000` to increase the maximum file descriptors per process). These parameters will of course be dependent on your server performance, and hit-rate; we encourage developers to experiment with small samples before running a large scan.
#### Forge Socket ####
We have also included a form of banner-grab, called forge-socket, that reuses the SYN-ACK sent from the server for the connection that ultimately fetches the banner. In `banner-grab-tcp`, ZMap sends a SYN to each server, and listening servers respond with a SYN+ACK. The ZMap host's kernel receives this, and sends a RST, as no active connection is associated with that packet. The banner-grab program must then create a new TCP connection to the same server to fetch data from it.
In forge-socket, we utilize a kernel module by the same name, that allows us to create a connection with arbitrary TCP parameters. This enables us to suppress the kernel's RST packet, and instead create a socket that will reuse the SYN+ACK's parameters, and send and receive data through this socket as we would any normally connected socket.
To use forge-socket, you will need the forge-socket kernel module, available from [github][1]. You should git clone `git@github.com:ewust/forge_socket.git` in the ZMap root source directory, and then cd into the forge_socket directory, and run make. Install the kernel module with `insmod forge_socket.ko` as root.
You must also tell the kernel not to send RST packets. An easy way to disable RST packets system wide is to use **iptables**. `iptables -A OUTPUT -p tcp -m tcp --tcp-flgas RST,RST RST,RST -j DROP` as root will do this, though you may also add an optional --dport X to limit this to the port (X) you are scanning. To remove this after your scan completes, you can run `iptables -D OUTPUT -p tcp -m tcp --tcp-flags RST,RST RST,RST -j DROP` as root.
Now you should be able to build the forge-socket ZMap example program. To run it, you must use the **extended_file** ZMap output module:
$ zmap -p 80 -N 1000 -B 10M -O extended_file -o - | \
./forge-socket -c 500 -d ./http-req > ./http-banners.out
See the README in `examples/forge-socket` for more details.
----------
### Writing Probe and Output Modules ###
ZMap can be extended to support different types of scanning through **probe modules** and additional types of results **output through** output modules. Registered probe and output modules can be listed through the command-line interface:
**--list-probe-modules**
Lists installed probe modules
**--list-output-modules**
Lists installed output modules
#### Output Modules ####
ZMap output and post-processing can be extended by implementing and registering **output modules** with the scanner. Output modules receive a callback for every received response packet. While the default provided modules provide simple output, these modules are also capable of performing additional post-processing (e.g. tracking duplicates or outputting numbers in terms of AS instead of IP address)
Output modules are created by defining a new output_module struct and registering it in [output_modules.c][2]:
typedef struct output_module {
const char *name; // how is output module referenced in the CLI
unsigned update_interval; // how often is update called in seconds
output_init_cb init; // called at scanner initialization
output_update_cb start; // called at the beginning of scanner
output_update_cb update; // called every update_interval seconds
output_update_cb close; // called at scanner termination
output_packet_cb process_ip; // called when a response is received
const char *helptext; // Printed when --list-output-modules is called
} output_module_t;
Output modules must have a name, which is how they are referenced on the command-line and generally implement `success_ip` and oftentimes `other_ip` callback. The process_ip callback is called for every response packet that is received and passed through the output filter by the current **probe module**. The response may or may not be considered a success (e.g. it could be a TCP RST). These callbacks must define functions that match the `output_packet_cb` definition:
int (*output_packet_cb) (
ipaddr_n_t saddr, // IP address of scanned host in network-order
ipaddr_n_t daddr, // destination IP address in network-order
const char* response_type, // send-module classification of packet
int is_repeat, // {0: first response from host, 1: subsequent responses}
int in_cooldown, // {0: not in cooldown state, 1: scanner in cooldown state}
const u_char* packet, // pointer to struct iphdr of IP packet
size_t packet_len // length of packet in bytes
);
An output module can also register callbacks to be executed at scanner initialization (tasks such as opening an output file), start of the scan (tasks such as documenting blacklisted addresses), during regular intervals during the scan (tasks such as progress updates), and close (tasks such as closing any open file descriptors). These callbacks are provided with complete access to the scan configuration and current state:
int (*output_update_cb)(struct state_conf*, struct state_send*, struct state_recv*);
which are defined in [output_modules.h][3]. An example is available at [src/output_modules/module_csv.c][4].
#### Probe Modules ####
Packets are constructed using probe modules which allow abstracted packet creation and response classification. ZMap comes with two scan modules by default: `tcp_synscan` and `icmp_echoscan`. By default, ZMap uses `tcp_synscan`, which sends TCP SYN packets, and classifies responses from each host as open (received SYN+ACK) or closed (received RST). ZMap also allows developers to write their own probe modules for use with ZMap, using the following API.
Each type of scan is implemented by developing and registering the necessary callbacks in a `send_module_t` struct:
typedef struct probe_module {
const char *name; // how scan is invoked on command-line
size_t packet_length; // how long is probe packet (must be static size)
const char *pcap_filter; // PCAP filter for collecting responses
size_t pcap_snaplen; // maximum number of bytes for libpcap to capture
uint8_t port_args; // set to 1 if ZMap requires a --target-port be
// specified by the user
probe_global_init_cb global_initialize; // called once at scanner initialization
probe_thread_init_cb thread_initialize; // called once for each thread packet buffer
probe_make_packet_cb make_packet; // called once per host to update packet
probe_validate_packet_cb validate_packet; // called once per received packet,
// return 0 if packet is invalid,
// non-zero otherwise.
probe_print_packet_cb print_packet; // called per packet if in dry-run mode
probe_classify_packet_cb process_packet; // called by receiver to classify response
probe_close_cb close; // called at scanner termination
fielddef_t *fields // Definitions of the fields specific to this module
int numfields // Number of fields
} probe_module_t;
At scanner initialization, `global_initialize` is called once and can be utilized to perform any necessary global configuration or initialization. However, `global_initialize` does not have access to the packet buffer which is thread-specific. Instead, `thread_initialize` is called at the initialization of each sender thread and is provided with access to the buffer that will be used for constructing probe packets along with global source and destination values. This callback should be used to construct the host agnostic packet structure such that only specific values (e.g. destination host and checksum) need to be be updated for each host. For example, the Ethernet header will not change between headers (minus checksum which is calculated in hardware by the NIC) and therefore can be defined ahead of time in order to reduce overhead at scan time.
The `make_packet` callback is called for each host that is scanned to allow the **probe module** to update host specific values and is provided with IP address values, an opaque validation string, and probe number (shown below). The probe module is responsible for placing as much of the verification string into the probe, in such a way that when a valid response is returned by a server, the probe module can verify that it is present. For example, for a TCP SYN scan, the tcp_synscan probe module can use the TCP source port and sequence number to store the validation string. Response packets (SYN+ACKs) will contain the expected values in the destination port and acknowledgement number.
int make_packet(
void *packetbuf, // packet buffer
ipaddr_n_t src_ip, // source IP in network-order
ipaddr_n_t dst_ip, // destination IP in network-order
uint32_t *validation, // validation string to place in probe
int probe_num // if sending multiple probes per host,
// this will be which probe number for this
// host we are currently sending
);
Scan modules must also define `pcap_filter`, `validate_packet`, and `process_packet`. Only packets that match the PCAP filter will be considered by the scanner. For example, in the case of a TCP SYN scan, we only want to investigate TCP SYN/ACK or TCP RST packets and would utilize a filter similar to `tcp && tcp[13] & 4 != 0 || tcp[13] == 18`. The `validate_packet` function will be called for every packet that fulfills this PCAP filter. If the validation returns non-zero, the `process_packet` function will be called, and will populate a fieldset using fields defined in `fields` with data from the packet. For example, the following code processes a packet for the TCP synscan probe module.
void synscan_process_packet(const u_char *packet, uint32_t len, fieldset_t *fs)
{
struct iphdr *ip_hdr = (struct iphdr *)&packet[sizeof(struct ethhdr)];
struct tcphdr *tcp = (struct tcphdr*)((char *)ip_hdr
+ (sizeof(struct iphdr)));
fs_add_uint64(fs, "sport", (uint64_t) ntohs(tcp->source));
fs_add_uint64(fs, "dport", (uint64_t) ntohs(tcp->dest));
fs_add_uint64(fs, "seqnum", (uint64_t) ntohl(tcp->seq));
fs_add_uint64(fs, "acknum", (uint64_t) ntohl(tcp->ack_seq));
fs_add_uint64(fs, "window", (uint64_t) ntohs(tcp->window));
if (tcp->rst) { // RST packet
fs_add_string(fs, "classification", (char*) "rst", 0);
fs_add_uint64(fs, "success", 0);
} else { // SYNACK packet
fs_add_string(fs, "classification", (char*) "synack", 0);
fs_add_uint64(fs, "success", 1);
}
}
--------------------------------------------------------------------------------
via: https://zmap.io/documentation.html
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
[1]:https://github.com/ewust/forge_socket/
[2]:https://github.com/zmap/zmap/blob/v1.0.0/src/output_modules/output_modules.c
[3]:https://github.com/zmap/zmap/blob/master/src/output_modules/output_modules.h
[4]:https://github.com/zmap/zmap/blob/master/src/output_modules/module_csv.c

743
translated/tech/20150401 ZMap Documentation.md Normal file
View File

@ -0,0 +1,743 @@
ZMap 文档
================================================================================
1. 初识 ZMap
1. 最佳扫描习惯
1. 命令行参数
1. 附加信息
1. TCP SYN 探测模块
1. ICMP Echo 探测模块
1. UDP 探测模块
1. 配置文件
1. 详细
1. 结果输出
1. 黑名单
1. 速度限制与抽样
1. 发送多个探测
1. ZMap 扩展
1. 示例应用程序
1. 编写探测和输出模块
----------
### 初识 ZMap ###
ZMap被设计用来针对IPv4所有地址或其中的大部分实施综合扫描的工具。ZMap是研究者手中的利器，但在运行ZMap时，请注意，您很有可能正在以每秒140万个包的速度扫描整个IPv4地址空间 。我们建议用户在实施即使小范围扫描之前，也联系一下本地网络的管理员并参考我们列举的最佳扫描习惯。
默认情况下，ZMap会对于指定端口实施尽可能大速率的TCP SYN扫描。较为保守的情况下，对10,000个随机的地址的80端口以10Mbps的速度扫描，如下所示：
$ zmap --bandwidth=10M --target-port=80 --max-targets=10000 --output-file=results.csv
或者更加简洁地写成：
$ zmap -B 10M -p 80 -n 10000 -o results.csv
ZMap也可用于扫描特定子网或CIDR地址块。例如，仅扫描10.0.0.0/8和192.168.0.0/16的80端口，运行指令如下：
zmap -p 80 -o results.csv 10.0.0.0/8 192.168.0.0/16
如果扫描进行的顺利，ZMap会每秒输出类似以下内容的状态更新：
0% (1h51m left); send: 28777 562 Kp/s (560 Kp/s avg); recv: 1192 248 p/s (231 p/s avg); hits: 0.04%
0% (1h51m left); send: 34320 554 Kp/s (559 Kp/s avg); recv: 1442 249 p/s (234 p/s avg); hits: 0.04%
0% (1h50m left); send: 39676 535 Kp/s (555 Kp/s avg); recv: 1663 220 p/s (232 p/s avg); hits: 0.04%
0% (1h50m left); send: 45372 570 Kp/s (557 Kp/s avg); recv: 1890 226 p/s (232 p/s avg); hits: 0.04%
这些更新信息提供了扫描的即时状态并表示成：完成进度% (剩余时间); send: 发出包的数量 即时速率 (平均发送速率); recv: 接收包的数量 接收率 (平均接收率); hits: 成功率
如果您不知道您所在网络支持的扫描速率，您可能要尝试不同的扫描速率和带宽限制直到扫描效果开始下降，借此找出当前网络能够支持的最快速度。
默认情况下，ZMap会输出不同IP地址的列表（例如，SYN ACK数据包的情况）像下面这样。还有几种附加的格式（如，JSON和Redis）作为其输出结果，以及生成程序可解析的扫描统计选项。 同样，可以指定附加的输出字段并使用输出过滤来过滤输出的结果。
115.237.116.119
23.9.117.80
207.118.204.141
217.120.143.111
50.195.22.82
我们强烈建议您使用黑名单文件，以排除预留的/未分配的IP地址空间（如，组播地址，RFC1918），以及网络中需要排除在您扫描之外的地址。默认情况下，ZMap将采用位于 `/etc/zmap/blacklist.conf`的这个简单的黑名单文件中所包含的预留和未分配地址。如果您需要某些特定设置，比如每次运行ZMap时的最大带宽或黑名单文件，您可以在文件`/etc/zmap/zmap.conf`中指定或使用自定义配置文件。
如果您正试图解决扫描的相关问题，有几个选项可以帮助您调试。首先，您可以通过添加`--dryrun`实施预扫，以此来分析包可能会发送到网络的何处。此外，还可以通过设置'--verbosity=n`来更改日志详细程度。
----------
### 最佳扫描习惯 ###
我们为针对互联网进行扫描的研究者提供了一些建议，以此来引导养成良好的互联网合作氛围
- 密切协同本地的网络管理员，以减少风险和调查
- 确认扫描不会使本地网络或上游供应商瘫痪
- 标记出在扫描中呈良性的网页和DNS条目的源地址
- 明确注明扫描中所有连接的目的和范围
- 提供一个简单的退出方法并及时响应请求
- 实施扫描时，不使用比研究对象需求更大的扫描范围或更快的扫描频率
- 如果可以通过时间或源地址来传播扫描流量
即使不声明，使用扫描的研究者也应该避免利用漏洞或访问受保护的资源，并遵守其辖区内任何特殊的法律规定。
----------
### 命令行参数 ###
#### 通用选项 ####
这些选项是实施简单扫描时最常用的选项。我们注意到某些选项取决于所使用的探测模块或输出模块（如，在实施ICMP Echo扫描时是不需要使用目的端口的）。
**-p, --target-port=port**
用来扫描的TCP端口号（例如，443）
**-o, --output-file=name**
使用标准输出将结果写入该文件。
**-b, --blacklist-file=path**
文件中被排除的子网使用CIDR表示法（如192.168.0.0/16），一个一行。建议您使用此方法排除RFC 1918地址，组播地址，IANA预留空间等IANA专用地址。在conf/blacklist.example中提供了一个以此为目的示例黑名单文件。
#### 扫描选项 ####
**-n, --max-targets=n**
限制探测目标的数量。后面跟的可以是一个数字（例如'-n 1000`）或百分比（例如，`-n 0.1％`）当然都是针对可扫描地址空间而言的（不包括黑名单）
**-N, --max-results=n**
收到多少结果后退出
**-t, --max-runtime=secs**
限制发送报文的时间
**-r, --rate=pps**
设置传输速率，以包/秒为单位
**-B, --bandwidth=bps**
以比特/秒设置传输速率（支持使用后缀G，M或K（如`-B 10M`就是速度10 mbps）的。设置会覆盖`--rate`。
**-c, --cooldown-time=secs**
发送完成后多久继续接收（默认值= 8）
**-e, --seed=n**
地址排序种子。如果要用多个ZMap以相同的顺序扫描地址，那么就可以使用这个参数。
**--shards=n**
将扫描分片/区在使其可多个ZMap中执行（默认值= 1）。启用分片时，`--seed`参数是必需的。
**--shard=n**
选择扫描的分片（默认值= 0）。n的范围在[0，N)，其中N为碎片的总数。启用分片时，`--seed`参数是必需的。
**-T, --sender-threads=n**
用于发送数据包的线程数（默认值= 1）
**-P, --probes=n**
发送到每个IP的探测数（默认值= 1）
**-d, --dryrun**
用标准输出打印出每个包，而不是将其发送（用于调试）
#### 网络选项 ####
**-s, --source-port=port|range**
发送数据包的源端口
**-S, --source-ip=ip|range**
发送数据包的源地址。可以仅仅是一个IP，也可以是一个范围（如，10.0.0.1-10.0.0.9）
**-G, --gateway-mac=addr**
数据包发送到的网关MAC地址（用以防止自动检测不工作的情况）
**-i, --interface=name**
使用的网络接口
#### 探测选项 ####
ZMap允许用户指定并添加自己所需要探测的模块。 探测模块的职责就是生成主机回复的响应包。
**--list-probe-modules**
列出可用探测模块（如tcp_synscan）
**-M, --probe-module=name**
选择探探测模块（默认值= tcp_synscan）
**--probe-args=args**
向模块传递参数
**--list-output-fields**
列出可用的输出模块
#### 输出选项 ####
ZMap允许用户选择指定的输出模块。输出模块负责处理由探测模块返回的字段，并将它们交给用户。用户可以指定输出的范围，并过滤相应字段。
**--list-output-modules**
列出可用输出模块（如tcp_synscan）
**-O, --output-module=name**
选择输出模块（默认值为csv）
**--output-args=args**
传递给输出模块的参数
**-f, --output-fields=fields**
输出列表，以逗号分割
**--output-filter**
通过指定相应的探测模块来过滤输出字段
#### 附加选项 ####
**-C, --config=filename**
加载配置文件，可以指定其他路径。
**-q, --quiet**
不再是每秒刷新输出
**-g, --summary**
在扫描结束后打印配置和结果汇总信息
**-v, --verbosity=n**
日志详细程度（0-5，默认值= 3）
**-h, --help**
打印帮助并退出
**-V, --version**
打印版本并退出
----------
### 附加信息 ###
#### TCP SYN 扫描 ####
在执行TCP SYN扫描时，ZMap需要指定一个目标端口和以供扫描的源端口范围。
**-p, --target-port=port**
扫描的TCP端口（例如 443）
**-s, --source-port=port|range**
发送扫描数据包的源端口（例如 40000-50000）
**警示！** ZMAP基于Linux内核使用SYN/ACK包应答，RST包关闭扫描打开的连接。ZMap是在Ethernet层完成包的发送的，这样做时为了减少跟踪打开的TCP连接和路由寻路带来的内核开销。因此，如果您有跟踪连接建立的防火墙规则，如netfilter的规则类似于`-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT`，将阻止SYN/ACK包到达内核。这不会妨碍到ZMap记录应答，但它会阻止RST包被送回，最终连接会在超时后断开。我们强烈建议您在执行ZMap时，选择一组主机上未使用且防火墙允许访问的端口，加在`-s`后（如 `-s '50000-60000' ` ）。
#### ICMP Echo 请求扫描 ####
虽然在默认情况下ZMap执行的是TCP SYN扫描，但它也支持使用ICMP echo请求扫描。在这种扫描方式下ICMP echo请求包被发送到每个主机，并以收到ICMP 应答包作为答复。实施ICMP扫描可以通过选择icmp_echoscan扫描模块来执行，如下：
$ zmap --probe-module=icmp_echoscan
#### UDP 数据报扫描 ####
ZMap还额外支持UDP探测，它会发出任意UDP数据报给每个主机，并能在无论UDP或是ICMP任何一个不可达的情况下接受应答。ZMap支持通过使用--probe-args命令行选择四种不同的UDP payload方式。这些都有可列印payload的‘文本’，用于命令行的十六进制payload的‘hex’，外部文件中包含payload的‘file’，和需要动态区域生成的payload的‘template’。为了得到UDP响应，请使用-f参数确保您指定的“data”领域处于汇报范围。
下面的例子将发送两个字节'ST'，即PC的'status'请求，到UDP端口5632。
$ zmap -M udp -p 5632 --probe-args=text:ST -N 100 -f saddr,data -o -
下面的例子将发送字节“0X02”，即SQL服务器的 'client broadcast'请求，到UDP端口1434。
$ zmap -M udp -p 1434 --probe-args=hex:02 -N 100 -f saddr,data -o -
下面的例子将发送一个NetBIOS状态请求到UDP端口137。使用一个ZMap自带的payload文件。
$ zmap -M udp -p 1434 --probe-args=file:netbios_137.pkt -N 100 -f saddr,data -o -
下面的例子将发送SIP的'OPTIONS'请求到UDP端口5060。使用附ZMap自带的模板文件。
$ zmap -M udp -p 1434 --probe-args=file:sip_options.tpl -N 100 -f saddr,data -o -
UDP payload 模板仍处于实验阶段。当您在更多的使用一个以上的发送线程（-T）时可能会遇到崩溃和一个明显的相比静态payload性能降低的表现。模板仅仅是一个由一个或多个使用$ {}将字段说明封装成序列构成的payload文件。某些协议，特别是SIP，需要payload来反射包中的源和目的地址。其他协议，如端口映射和DNS，包含范围伴随每一次请求随机生成或Zamp扫描的多宿主系统将会抛出危险警告。
以下的payload模板将发送SIP OPTIONS请求到每一个目的地：
OPTIONS sip:${RAND_ALPHA=8}@${DADDR} SIP/2.0
Via: SIP/2.0/UDP ${SADDR}:${SPORT};branch=${RAND_ALPHA=6}.${RAND_DIGIT=10};rport;alias
From: sip:${RAND_ALPHA=8}@${SADDR}:${SPORT};tag=${RAND_DIGIT=8}
To: sip:${RAND_ALPHA=8}@${DADDR}
Call-ID: ${RAND_DIGIT=10}@${SADDR}
CSeq: 1 OPTIONS
Contact: sip:${RAND_ALPHA=8}@${SADDR}:${SPORT}
Content-Length: 0
Max-Forwards: 20
User-Agent: ${RAND_ALPHA=8}
Accept: text/plain
就像在上面的例子中展示的那样，对于大多数SIP正常的实现会在在每行行末添加\r\n，并且在请求的末尾一定包含\r\n\r\n。一个可以使用的在ZMap的examples/udp-payloads目录下的例子 (sip_options.tpl).
下面的字段正在如今的模板中实施：
- **SADDR**: 源IP地址的点分十进制格式
- **SADDR_N**: 源IP地址的网络字节序格式
- **DADDR**: 目的IP地址的点分十进制格式
- **DADDR_N**: 目的IP地址的网络字节序格式
- **SPORT**: 源端口的ascii格式
- **SPORT_N**: 源端口的网络字节序格式
- **DPORT**: 目的端口的ascii格式
- **DPORT_N**: 目的端口的网络字节序格式
- **RAND_BYTE**: 随机字节(0-255)，长度由=(长度) 参数决定
- **RAND_DIGIT**: 随机数字0-9，长度由=(长度) 参数决定
- **RAND_ALPHA**: 随机大写字母A-Z，长度由=(长度) 参数决定
- **RAND_ALPHANUM**: 随机大写字母A-Z和随机数字0-9，长度由=(长度) 参数决定
### 配置文件 ###
ZMap支持使用配置文件代替在命令行上指定所有的需求选项。配置中可以通过每行指定一个长名称的选项和对应的值来创建：
interface "eth1"
source-ip 1.1.1.4-1.1.1.8
gateway-mac b4:23:f9:28:fa:2d # upstream gateway
cooldown-time 300 # seconds
blacklist-file /etc/zmap/blacklist.conf
output-file ~/zmap-output
quiet
summary
然后ZMap就可以按照配置文件和一些必要的附加参数运行了：
$ zmap --config=~/.zmap.conf --target-port=443
### 详细 ###
ZMap可以在屏幕上生成多种类型的输出。默认情况下，Zmap将每隔1秒打印出相似的基本进度信息。可以通过设置`--quiet`来禁用。
0:01 12%; send: 10000 done (15.1 Kp/s avg); recv: 144 143 p/s (141 p/s avg); hits: 1.44%
ZMap同样也可以根据扫描配置打印如下消息，可以通过'--verbosity`参数加以控制。
Aug 11 16:16:12.813 [INFO] zmap: started
Aug 11 16:16:12.817 [DEBUG] zmap: no interface provided. will use eth0
Aug 11 16:17:03.971 [DEBUG] cyclic: primitive root: 3489180582
Aug 11 16:17:03.971 [DEBUG] cyclic: starting point: 46588
Aug 11 16:17:03.975 [DEBUG] blacklist: 3717595507 addresses allowed to be scanned
Aug 11 16:17:03.975 [DEBUG] send: will send from 1 address on 28233 source ports
Aug 11 16:17:03.975 [DEBUG] send: using bandwidth 10000000 bits/s, rate set to 14880 pkt/s
Aug 11 16:17:03.985 [DEBUG] recv: thread started
ZMap还支持在扫描之后打印出一个的可grep的汇总信息，类似于下面这样，可以通过调用`--summary`来实现。
cnf target-port 443
cnf source-port-range-begin 32768
cnf source-port-range-end 61000
cnf source-addr-range-begin 1.1.1.4
cnf source-addr-range-end 1.1.1.8
cnf maximum-packets 4294967295
cnf maximum-runtime 0
cnf permutation-seed 0
cnf cooldown-period 300
cnf send-interface eth1
cnf rate 45000
env nprocessors 16
exc send-start-time Fri Jan 18 01:47:35 2013
exc send-end-time Sat Jan 19 00:47:07 2013
exc recv-start-time Fri Jan 18 01:47:35 2013
exc recv-end-time Sat Jan 19 00:52:07 2013
exc sent 3722335150
exc blacklisted 572632145
exc first-scanned 1318129262
exc hit-rate 0.874102
exc synack-received-unique 32537000
exc synack-received-total 36689941
exc synack-cooldown-received-unique 193
exc synack-cooldown-received-total 1543
exc rst-received-unique 141901021
exc rst-received-total 166779002
adv source-port-secret 37952
adv permutation-gen 4215763218
### 结果输出 ###
ZMap可以通过**输出模块**生成不同格式的结果。默认情况下，ZMap只支持**csv**的输出，但是可以通过编译支持**redis**和**json** 。可以使用**输出过滤**来过滤这些发送到输出模块上的结果。输出模块的范围由用户指定。默认情况如果没有指定输出文件，ZMap将以csv格式返回结果，ZMap不会产生特定结果。也可以编写自己的输出模块;请参阅编写输出模块。
**-o, --output-file=p**
输出写入文件地址
**-O, --output-module=p**
调用自定义输出模块
**-f, --output-fields=p**
输出以逗号分隔各字段的列表
**--output-filter=filter**
在给定的探测区域实施输出过滤
**--list-output-modules**
列出可用输出模块
**--list-output-fields**
列出可用的给定探测区域
#### 输出字段 ####
ZMap有很多区域，它可以基于IP地址输出。这些区域可以通过在给定探测模块上运行`--list-output-fields`来查看。
$ zmap --probe-module="tcp_synscan" --list-output-fields
saddr string: 应答包中的源IP地址
saddr-raw int: 网络提供的整形形式的源IP地址
daddr string: 应答包中的目的IP地址
daddr-raw int: 网络提供的整形形式的目的IP地址
ipid int: 应答包中的IP识别号
ttl int: 应答包中的ttl（存活时间）值
sport int: TCP 源端口
dport int: TCP 目的端口
seqnum int: TCP 序列号
acknum int: TCP Ack号
window int: TCP 窗口
classification string: 包类型
success int: 是应答包成功
repeat int: 是否是来自主机的重复响应
cooldown int: 是否是在冷却时间内收到的响应
timestamp-str string: 响应抵达时的时间戳使用ISO8601格式
timestamp-ts int: 响应抵达时的时间戳使用纪元开始的秒数
timestamp-us int: 时间戳的微秒部分(例如 从'timestamp-ts'的几微秒)
可以通过使用`--output-fields=fields`或`-f`来选择选择输出字段，任意组合的输出字段可以被指定为逗号分隔的列表。例如：
$ zmap -p 80 -f "response,saddr,daddr,sport,seq,ack,in_cooldown,is_repeat,timestamp" -o output.csv
#### 过滤输出 ####
在传到输出模块之前，探测模块生成的结果可以先过滤。过滤被实施在探测模块的输出字段上。过滤使用简单的过滤语法写成，类似于SQL，通过ZMap的**--output-filter**选项来实施。输出过滤通常用于过滤掉重复的结果或仅传输成功的响应到输出模块。
过滤表达式的形式为`<字段名> <操作> <值>`。`<值>`的类型必须是一个字符串或一串无符号整数并且匹配`<字段名>`类型。对于整数比较有效的操作是`= !=, <, >, <=, >=`。字符串比较的操作是=，!=。`--list-output-fields`会打印那些可供探测模块选择的字段和类型，然后退出。
复合型的过滤操作，可以通过使用`&&`（逻辑与）和`||`（逻辑或）这样的运算符来组合出特殊的过滤操作。
**示例**
书写一则过滤仅显示成功，过滤重复应答
--output-filter="success = 1 && repeat = 0"
过滤出包中含RST并且TTL大于10的分类，或者包中含SYNACK的分类
--output-filter="(classification = rst && ttl > 10) || classification = synack"
#### CSV ####
csv模块将会生成以逗号分隔各输出请求字段的文件。例如，以下的指令将生成下面的CSV至名为`output.csv`的文件。
$ zmap -p 80 -f "response,saddr,daddr,sport,seq,ack,in_cooldown,is_repeat,timestamp" -o output.csv
----------
响应, 源地址, 目的地址, 源端口, 目的端口, 序列号, 应答, 是否是冷却模式, 是否重复, 时间戳
synack, 159.174.153.144, 10.0.0.9, 80, 40555, 3050964427, 3515084203, 0, 0,2013-08-15 18:55:47.681
rst, 141.209.175.1, 10.0.0.9, 80, 40136, 0, 3272553764, 0, 0,2013-08-15 18:55:47.683
rst, 72.36.213.231, 10.0.0.9, 80, 56642, 0, 2037447916, 0, 0,2013-08-15 18:55:47.691
rst, 148.8.49.150, 10.0.0.9, 80, 41672, 0, 1135824975, 0, 0,2013-08-15 18:55:47.692
rst, 50.165.166.206, 10.0.0.9, 80, 38858, 0, 535206863, 0, 0,2013-08-15 18:55:47.694
rst, 65.55.203.135, 10.0.0.9, 80, 50008, 0, 4071709905, 0, 0,2013-08-15 18:55:47.700
synack, 50.57.166.186, 10.0.0.9, 80, 60650, 2813653162, 993314545, 0, 0,2013-08-15 18:55:47.704
synack, 152.75.208.114, 10.0.0.9, 80, 52498, 460383682, 4040786862, 0, 0,2013-08-15 18:55:47.707
synack, 23.72.138.74, 10.0.0.9, 80, 33480, 810393698, 486476355, 0, 0,2013-08-15 18:55:47.710
#### Redis ####
Redis的输出模块允许地址被添加到一个Redis的队列,不是被保存到文件,允许ZMap将它与之后的处理工具结合使用。
**注意!** ZMap默认不会编译Redis功能。如果您想要将Redis功能编译进ZMap源码中，可以在CMake的时候加上`-DWITH_REDIS=ON`。
### 黑名单和白名单 ###
ZMap同时支持对网络前缀做黑名单和白名单。如果ZMap不加黑名单和白名单参数，他将会扫描所有的IPv4地址（包括本地的，保留的以及组播地址）。如果指定了黑名单文件，那么在黑名单中的网络前缀将不再扫描；如果指定了白名单文件，只有那些网络前缀在白名单内的才会扫描。白名单和黑名单文件可以协同使用；黑名单运用于白名单上（例如：如果您在白名单中指定了10.0.0.0/8并在黑名单中指定了10.1.0.0/16，那么10.1.0.0/16将不会扫描）。白名单和黑名单文件可以在命令行中指定，如下所示：
**-b, --blacklist-file=path**
文件用于记录黑名单子网，以CIDR（无类域间路由）的表示法，例如192.168.0.0/16
**-w, --whitelist-file=path**
文件用于记录限制扫描的子网，以CIDR的表示法，例如192.168.0.0/16
黑名单文件的每行都需要以CIDR的表示格式书写一个单一的网络前缀。允许使用`#`加以备注。例如：
# IANA（英特网编号管理局）记录的用于特殊目的的IPv4地址
# http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
# 更新于2013-05-22
0.0.0.0/8 # RFC1122: 网络中的所有主机
10.0.0.0/8 # RFC1918: 私有地址
100.64.0.0/10 # RFC6598: 共享地址空间
127.0.0.0/8 # RFC1122: 回环地址
169.254.0.0/16 # RFC3927: 本地链路地址
172.16.0.0/12 # RFC1918: 私有地址
192.0.0.0/24 # RFC6890: IETF协议预留
192.0.2.0/24 # RFC5737: 测试地址
192.88.99.0/24 # RFC3068: IPv6转换到IPv4的任意播
192.168.0.0/16 # RFC1918: 私有地址
192.18.0.0/15 # RFC2544: 检测地址
198.51.100.0/24 # RFC5737: 测试地址
203.0.113.0/24 # RFC5737: 测试地址
240.0.0.0/4 # RFC1112: 预留地址
255.255.255.255/32 # RFC0919: 广播地址
# IANA记录的用于组播的地址空间
# http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
# 更新于2013-06-25
224.0.0.0/4 # RFC5771: 组播/预留地址ed
如果您只是想扫描因特网中随机的一部分地址，使用采样检出，来代替使用白名单和黑名单。
**注意！**ZMap默认设置使用`/etc/zmap/blacklist.conf`作为黑名单文件，其中包含有本地的地址空间和预留的IP空间。通过编辑`/etc/zmap/zmap.conf`可以改变默认的配置。
### 速度限制与抽样 ###
默认情况下，ZMap将以您当前网络所能支持的最快速度扫描。以我们对于常用硬件的经验，这普遍是理论上Gbit以太网速度的95-98%，这可能比您的上游提供商可处理的速度还要快。ZMap是不会自动的根据您的上游提供商来调整发送速率的。您可能需要手动的调整发送速率来减少丢包和错误结果。
**-r, --rate=pps**
设置最大发送速率以包/秒为单位
**-B, --bandwidth=bps**
设置发送速率以比特/秒(支持G,M和K后缀)。也同样作用于--rate的参数。
ZMap同样支持对IPv4地址空间进行指定最大目标数和/或最长运行时间的随机采样。由于针对主机的扫描是通过随机排序生成的实例，限制扫描的主机个数为N就会随机抽选N个主机。命令选项如下：
**-n, --max-targets=n**
探测目标上限数量
**-N, --max-results=n**
结果上限数量（累积收到这么多结果后推出）
**-t, --max-runtime=s**
发送数据包时间长度上限（以秒为单位）
**-s, --seed=n**
种子用以选择地址的排列方式。使用不同ZMap执行扫描操作时将种子设成相同的值可以保证相同的扫描顺序。
举个例子，如果您想要多次扫描同样的一百万个互联网主机，您可以设定排序种子和扫描主机的上限数量，大致如下所示：
zmap -p 443 -s 3 -n 1000000 -o results
为了确定哪一百万主机将要被扫描，您可以执行预扫，只列印数据包而非发送，并非真的实施扫描。
zmap -p 443 -s 3 -n 1000000 --dryrun | grep daddr
| awk -F'daddr: ' '{print $2}' | sed 's/ |.*//;'
### 发送多个数据包 ###
ZMap支持想每个主机发送多个扫描。增加这个数量既增加了扫描时间又增加了到达的主机数量。然而，我们发现，增加扫描时间（每个额外扫描的增加近100％）远远大于到达的主机数量（每个额外扫描的增加近1％）。
**-P, --probes=n**
向每个IP发出的独立扫描个数（默认值=1）
----------
### 示例应用程序 ###
ZMap专为向大量主机发启连接并寻找那些正确响应而设计。然而，我们意识到许多用户需要执行一些后续处理，如执行应用程序级别的握手。例如，用户在80端口实施TCP SYN扫描可能只是想要实施一个简单的GET请求，还有用户扫描443端口可能是对TLS握手如何完成感兴趣。
#### Banner获取 ####
我们收录了一个示例程序，banner-grab，伴随ZMap使用可以让用户从监听状态的TCP服务器上接收到消息。Banner-grab连接到服务上，任意的发送一个消息，然后打印出收到的第一个消息。这个工具可以用来获取banners例如HTTP服务的回复的具体指令，telnet登陆提示，或SSH服务的字符串。
这个例子寻找了1000个监听80端口的服务器，并向每个发送一个简单的GET请求，存储他们的64位编码响应至http-banners.out
$ zmap -p 80 -N 1000 -B 10M -o - | ./banner-grab-tcp -p 80 -c 500 -d ./http-req > out
如果想知道更多使用`banner-grab`的细节,可以参考`examples/banner-grab`中的README文件。
**注意！** ZMap和banner-grab（如例子中）同时运行可能会比较显著的影响对方的表现和精度。确保不让ZMap充满banner-grab-tcp的并发连接，不然banner-grab将会落后于标准输入的读入，导致屏蔽编写标准输出。我们推荐使用较慢扫描速率的ZMap，同时提升banner-grab-tcp的并发性至3000以内（注意 并发连接>1000需要您使用`ulimit -SHn 100000`和`ulimit -HHn 100000`来增加每个问进程的最大文件描述）。当然，这些参数取决于您服务器的性能，连接成功率（hit-rate）；我们鼓励开发者在运行大型扫描之前先进行小样本的试验。
#### 建立套接字 ####
我们也收录了另一种形式的banner-grab，就是forge-socket， 重复利用服务器发出的SYN-ACK，连接并最终取得banner。在`banner-grab-tcp`中，ZMap向每个服务器发送一个SYN，并监听服务器发回的带有SYN+ACK的应答。运行ZMap主机的内核接受应答后发送RST，因为有没有处于活动状态的连接与该包关联。程序banner-grab必须在这之后创建一个新的TCP连接到从服务器获取数据。
在forge-socket中，我们以同样的名字利用内核模块，这使我们可以创建任意参数的TCP连接。这样可以抑制内核的RST包，并且通过创建套接字取代它可以重用SYN+ACK的参数，通过这个套接字收发数据和我们平时使用的连接套接字并没有什么不同。
要使用forge-socket，您需要forge-socket内核模块，从[github][1]上可以获得。您需要git clone `git@github.com:ewust/forge_socket.git`至ZMap源码根目录，然后cd进入forge_socket 目录，运行make。以root身份安装带有`insmod forge_socket.ko` 的内核模块。
您也需要告知内核不要发送RST包。一个简单的在全系统禁用RST包的方法是**iptables**。以root身份运行`iptables -A OUTPUT -p tcp -m tcp --tcp-flgas RST,RST RST,RST -j DROP`即可，当然您也可以加上一项--dport X将禁用局限于所扫描的端口（X）上。扫描完成后移除这项设置，以root身份运行`iptables -D OUTPUT -p tcp -m tcp --tcp-flags RST,RST RST,RST -j DROP`即可。
现在应该可以建立forge-socket的ZMap示例程序了。运行需要使用**extended_file**ZMap输出模块：
$ zmap -p 80 -N 1000 -B 10M -O extended_file -o - | \
./forge-socket -c 500 -d ./http-req > ./http-banners.out
详细内容可以参考`examples/forge-socket`目录下的README。
----------
### 编写探测和输出模块 ###
ZMap可以通过**probe modules**扩展支持不同类型的扫描，通过**output modules**追加不同类型的输出结果。注册过的探测和输出模块可以在命令行中列出：
**--list-probe-modules**
列出安装过的探测模块
**--list-output-modules**
列出安装过的输出模块
#### 输出模块 ####
ZMap的输出和输出后处理可以通过执行和注册扫描的**output modules**来扩展。输出模块在接收每一个应答包时都会收到一个回调。然而提供的默认模块仅提供简单的输出，这些模块同样支持扩展扫描后处理（例如：重复跟踪或输出AS号码来代替IP地址）
通过定义一个新的output_module机构体来创建输出模块，并在[output_modules.c][2]中注册：
typedef struct output_module {
const char *name; // 在命令行如何引出输出模块
unsigned update_interval; // 以秒为单位的更新间隔
output_init_cb init; // 在扫描初始化的时候调用
output_update_cb start; // 在开始的扫描的时候调用
output_update_cb update; // 每次更新间隔调用，秒为单位
output_update_cb close; // 扫描终止后调用
output_packet_cb process_ip; // 接收到应答时调用
const char *helptext; // 会在--list-output-modules时打印在屏幕啥
} output_module_t;
输出模块必须有名称，通过名称可以在命令行、普遍实施的`success_ip`和常见的`other_ip`回调中使用模块。process_ip的回调由每个收到的或经由**probe module**过滤的应答包调用。应答是否被认定为成功并不确定（比如，他可以是一个TCP的RST）。这些回调必须定义匹配`output_packet_cb`定义的函数:
int (*output_packet_cb) (
ipaddr_n_t saddr, // network-order格式的扫描主机IP地址
ipaddr_n_t daddr, // network-order格式的目的IP地址
const char* response_type, // 发送模块的数据包分类
int is_repeat, // {0: 主机的第一个应答, 1: 后续的应答}
int in_cooldown, // {0: 非冷却状态, 1: 扫描处于冷却中}
const u_char* packet, // 指向结构体iphdr中IP包的指针
size_t packet_len // 包的长度以字节为单位
);
输出模块还可以通过注册回调执行在扫描初始化的时候（诸如打开输出文件的任务），扫描开始阶段（诸如记录黑名单的任务），在常规间隔实施（诸如程序升级的任务）在关闭的时候（诸如关掉所有打开的文件描述符。这些回调提供完整的扫描配置入口和实时状态：
int (*output_update_cb)(struct state_conf*, struct state_send*, struct state_recv*);
被定义在[output_modules.h][3]中。在[src/output_modules/module_csv.c][4]中有可用示例。
#### 探测模块 ####
数据包由探测模块构造，由此可以创建抽象包并对应答分类。ZMap默认拥有两个扫描模块：`tcp_synscan`和`icmp_echoscan`。默认情况下，ZMap使用`tcp_synscan`来发送TCP SYN包并对每个主机的并对每个主机的响应分类，如打开时（收到SYN+ACK）或关闭时（收到RST）。ZMap允许开发者编写自己的ZMap探测模块，使用如下的API：
任何类型的扫描的实施都需要在`send_module_t`结构体内开发和注册必要的回调：
typedef struct probe_module {
const char *name; // 如何在命令行调用扫描
size_t packet_length; // 探测包有多长(必须是静态的)
const char *pcap_filter; // 对收到的响应实施PCAP过滤
size_t pcap_snaplen; // maximum number of bytes for libpcap to capture
uint8_t port_args; // 设为1，如果需要使用ZMap的--target-port
// 用户指定
probe_global_init_cb global_initialize; // 在扫描初始化会时被调用一次
probe_thread_init_cb thread_initialize; // 每个包缓存区的线程中被调用一次
probe_make_packet_cb make_packet; // 每个主机更新包的时候被调用一次
probe_validate_packet_cb validate_packet; // 每收到一个包被调用一次，
// 如果包无效返回0，
// 非零则覆盖。
probe_print_packet_cb print_packet; // 如果在dry-run模式下被每个包都调用
probe_classify_packet_cb process_packet; // 由区分响应的接收器调用
probe_close_cb close; // 扫描终止后被调用
fielddef_t *fields // 该模块指定的区域的定义
int numfields // 区域的数量
} probe_module_t;
在扫描操作初始化时会调用一次`global_initialize`，可以用来实施一些必要的全局配置和初始化操作。然而，`global_initialize`并不能访问报缓冲区，那里由线程指定。用以代替的，`thread_initialize`在每个发送线程初始化的时候被调用，提供对于缓冲区的访问，可以用来构建探测包和全局的源和目的值。此回调应用于构建宿主不可知分组结构，甚至只有特定值（如：目的主机和校验和），需要随着每个主机更新。例如，以太网头部信息在交换时不会变更（减去校验和是由NIC硬件计算的）因此可以事先定义以减少扫描时间开销。
调用回调参数`make_packet是为了让被扫描的主机允许**probe module**更新主机指定的值，同时提供IP地址、一个非透明的验证字符串和探测数目（如下所示）。探测模块负责在探测中放置尽可能多的验证字符串，以至于当服务器返回的应答为空时，探测模块也能验证它的当前状态。例如，针对TCP SYN扫描，tcp_synscan探测模块会使用TCP源端口和序列号的格式存储验证字符串。响应包（SYN+ACKs）将包含预期的值包含目的端口和确认号。
int make_packet(
void *packetbuf, // 包的缓冲区
ipaddr_n_t src_ip, // network-order格式源IP
ipaddr_n_t dst_ip, // network-order格式目的IP
uint32_t *validation, // 探测中的确认字符串
int probe_num // 如果向每个主机发送多重探测，
// 该值为对于主机我们
// 正在实施的探测数目
);
扫描模块也应该定义`pcap_filter`、`validate_packet`和`process_packet`。只有符合PCAP过滤的包才会被扫描。举个例子，在一个TCP SYN扫描的情况下，我们只想要调查TCP SYN / ACK或RST TCP数据包，并利用类似`tcp && tcp[13] & 4 != 0 || tcp[13] == 18`的过滤方法。`validate_packet`函数将会被每个满足PCAP过滤条件的包调用。如果验证返回的值非零，将会调用`process_packet`函数，并使用包中被定义成的`fields`字段和数据填充字段集。如下代码为TCP synscan探测模块处理了一个数据包。
void synscan_process_packet(const u_char *packet, uint32_t len, fieldset_t *fs)
{
struct iphdr *ip_hdr = (struct iphdr *)&packet[sizeof(struct ethhdr)];
struct tcphdr *tcp = (struct tcphdr*)((char *)ip_hdr
+ (sizeof(struct iphdr)));
fs_add_uint64(fs, "sport", (uint64_t) ntohs(tcp->source));
fs_add_uint64(fs, "dport", (uint64_t) ntohs(tcp->dest));
fs_add_uint64(fs, "seqnum", (uint64_t) ntohl(tcp->seq));
fs_add_uint64(fs, "acknum", (uint64_t) ntohl(tcp->ack_seq));
fs_add_uint64(fs, "window", (uint64_t) ntohs(tcp->window));
if (tcp->rst) { // RST packet
fs_add_string(fs, "classification", (char*) "rst", 0);
fs_add_uint64(fs, "success", 0);
} else { // SYNACK packet
fs_add_string(fs, "classification", (char*) "synack", 0);
fs_add_uint64(fs, "success", 1);
}
}
--------------------------------------------------------------------------------
via: https://zmap.io/documentation.html
译者：[martin2011qi](https://github.com/martin2011qi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
[1]:https://github.com/ewust/forge_socket/
[2]:https://github.com/zmap/zmap/blob/v1.0.0/src/output_modules/output_modules.c
[3]:https://github.com/zmap/zmap/blob/master/src/output_modules/output_modules.h
[4]:https://github.com/zmap/zmap/blob/master/src/output_modules/module_csv.c