- Introduction
- Deployment
- Configuration
- OS Support
- Integration
- Troubleshooting
- Enterprise Edition Reference Manual
- 127. Man Pages
- 128. Configuration
- 129. Language
- 130. Extension Modules
- 131. Input Modules
- 131.1. Process Accounting (im_acct)
- 131.2. AIX Auditing (im_aixaudit)
- 131.3. Azure (im_azure)
- 131.4. Batched Compression (im_batchcompress)
- 131.5. Basic Security Module Auditing (im_bsm)
- 131.6. Check Point OPSEC LEA (im_checkpoint)
- 131.7. DBI (im_dbi)
- 131.8. Event Tracing for Windows (im_etw)
- 131.9. External Programs (im_exec)
- 131.10. Files (im_file)
- 131.11. File Integrity Monitoring (im_fim)
- 131.12. Go (im_go)
- 131.13. HTTP(s) (im_http)
- 131.14. Internal (im_internal)
- 131.15. Java (im_java)
- 131.16. Kafka (im_kafka)
- 131.17. Kernel (im_kernel)
- 131.18. Linux Audit System (im_linuxaudit)
- 131.19. macOS ULS (im_maculs)
- 131.20. Mark (im_mark)
- 131.21. EventLog for Windows XP/2000/2003 (im_mseventlog)
- 131.22. EventLog for Windows 2008/Vista and Later (im_msvistalog)
- 131.23. Null (im_null)
- 131.24. ODBC (im_odbc)
- 131.25. Packet Capture (im_pcap)
- 131.26. Perl (im_perl)
- 131.27. Named Pipes (im_pipe)
- 131.28. Python (im_python)
- 131.29. Redis (im_redis)
- 131.30. Windows Registry Monitoring (im_regmon)
- 131.31. Ruby (im_ruby)
- 131.32. TLS/SSL (im_ssl)
- 131.33. Systemd (im_systemd)
- 131.34. TCP (im_tcp)
- 131.35. Test Generator (im_testgen)
- 131.36. UDP (im_udp)
- 131.37. Unix Domain Sockets (im_uds)
- 131.38. Windows Performance Counters (im_winperfcount)
- 131.39. Windows Event Collector (im_wseventing)
- 131.40. ZeroMQ (im_zmq)
- 132. Processor Modules
- 133. Output Modules
- NXLog Manager
- NXLog Add-Ons
131.25. Packet Capture (im_pcap)
This module provides support to passively monitor network traffic by generating logs for various protocols. It uses the libpcap and winpcap libraries to capture network traffic.
Note
|
Multiple instances of im_pcap are not supported currently. |
131.25.1. Configuration
The im_pcap module accepts the following directives in addition to the common module directives.
- Dev
-
This optional directive can only occur once. It specifies the name of a network device/interface on which im_pcap will capture packets. This directive is mutually exclusive with the File directive.
- Fields
-
The names of protocol fields to be included in the output. If no field names are present in the protocol configuration then all fields for the protocol will be present in the output. If any field names are present in the configuration for a protocol, then only those named fields will be present in the output. Refer to NXLog Pcap Protocols for details of the fields supported for each protocol.
- File
-
This optional directive can only occur once. It specifies the path to the file which contains capture packet data. The file path do not need to be enclosed in quotation marks, although both single quoted and double quoted paths are accepted. This directive is mutually exclusive with the Dev directive.
- Protocol
-
This is an optional group directive. It specifies the protocol, port number and protocol-specific fields which should be captured. May be used multiple times in the module definition, to specify multiple protocols. If no Protocol directive is specified, then all protocols will be captured. It has the following sub-directives:
- Type
-
Defines the name of a protocol to capture. Allowed types are;
ethernet
,ipv4
,ipv6
,ip
,tcp
,udp
,http
,arp
,vlan
,icmp
,pppoe
,dns
,mpls
,gre
,ppp_pptp
,ssl
,sll
,dhcp
,null_loopback
,igmp
,vxlan
,sip
,sdp
,radius
,modbus
,profinet
,dnp3
,bacnet
,iec104
. - Port
-
A list of custom port numbers to capture for the protocol specified in the Type directive. If omitted, standard port number(s) corresponding to the protocol will be used. Refer to NXLog Pcap Protocols for details of the default ports for each protocol.
NoteThe list of port numbers must be separated by a comma. Spaces and tabs between the values are accepted.
- Filter
-
An optional directive that defines a filter, which can be used to further limit the packets that should be captured and handled by the module. Filters do not need to be enclosed in quotation marks, although both single quoted and double quoted filters are accepted. If this directive is not used, then no filtering will be done.
NoteFiltering is done by the libpcap
library. See the Manpage of PCAP-FILTER in the libpcap documentation for the syntax. Not all protocols are supported for libpcap filtering.
131.25.2. Examples
In this example, the configuration illustrates how the Protocol group directive can be defined multiple times within the same module instance. Three types of network packets are to be captured: HTTP requests; TCP for the source and destination ports of all visible TCP traffic; and Ethernet to log the MAC addresses of packet sources and their destinations. The events are formatted to JSON while writing to a file.
This approach has two distinct advantages. It produces events that include all fields of all three protocols, which enables correlation between protocols that yield source and destination information with those protocols that do not provide such fields. Additionally, it achieves this goal using a single module instance instead of multiple instances, which reduces system resource consumption.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<Extension _json>
Module xm_json
</Extension>
<Input pcap>
Module im_pcap
Dev any
<Protocol>
Type http
Field http.request.uri
Field http.request.method
Field http.response.code
Field http.response.phrase
</Protocol>
<Protocol>
Type tcp
Field tcp.src_port
Field tcp.dst_port
Field tcp.flag
</Protocol>
<Protocol>
Type ethernet
Field eth.src_mac
Field eth.dest.mac
</Protocol>
</Input>
<Output file>
Module om_file
File "tmp/output"
Exec to_json();
</Output>
In this example, each of the three protocols are managed by a separate module instance. The events are formatted to JSON while being written to each of their respective files. This approach can be used when there is a need to analyze each protocol in isolation from each other. Because three input instances are used, more system resources will be consumed when compared to the multi-protocol, single-instance approach.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
<Extension _json>
Module xm_json
</Extension>
<Input pcap_tcp>
Module im_pcap
Dev any
<Protocol>
Type tcp
Field tcp.src_port
Field tcp.dst_port
Field tcp.flag
</Protocol>
</Input>
<Input pcap_http>
Module im_pcap
Dev any
<Protocol>
Type http
Field http.request.uri
Field http.request.method
Field http.response.code
Field http.response.phrase
</Protocol>
</Input>
<Input pcap_eth>
Module im_pcap
Dev any
<Protocol>
Type Ethernet
Field eth.src_mac
Field eth.dest.mac
</Protocol>
</Input>
<Output tcp_file>
Module om_file
File "tmp/tcp_output"
Exec to_json();
</Output>
<Output http_file>
Module om_file
File "tmp/http_output"
Exec to_json();
</Output>
<Output eth_file>
Module om_file
File "tmp/eth_output"
Exec to_json();
</Output>