pk/zeek
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
zeek/doc/logs/tunnel.rst
Patrick Kelley 8fd444092b initial
2025-05-07 15:35:15 -04:00

948 lines
35 KiB
ReStructuredText
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

==========
tunnel.log
==========
The purpose of Zeek’s :file:`tunnel.log` is to identify encapsulated traffic. A
common use case in modern networks involves encapsulating IPv6 traffic within
IPv4. It’s also entirely possible to tunnel IPv4 over IPv6. This document will
provide a few examples of how Zeek interprets tunneled traffic. The author
captured the first example on his home network. The remainder appear courtesy
of the PacketLife Web site operated by Jeremy Stretch:
https://packetlife.net/captures/category/tunneling/
For full details on each field in the :file:`tunnel.log` file, please refer to
:zeek:see:`Tunnel::Info`.
Teredo
======
The following example demonstrates Teredo traffic generated by a Microsoft game
console. Teredo is an encapsulation protocol whereby IPv4 carries IPv6 traffic.
https://docs.microsoft.com/en-us/windows/win32/teredo/portal
:program:`tcpdump` and :program:`tshark`
----------------------------------------
Here is :program:`tcpdump` output for the traffic in question::
00:55:58.290539 IP 192.168.4.31.3074 > 40.84.25.61.65444: UDP, length 61
00:55:59.321945 IP 192.168.4.31.3074 > 40.84.25.61.3544: UDP, length 61
00:55:59.337323 IP 40.84.25.61.3544 > 192.168.4.31.3074: UDP, length 109
Here is :program:`tshark` output for the traffic in question::
1 192.168.4.31 3074 40.84.25.61 65444 UDP 103 3074 → 65444 Len=61
2 fe80::ffff:ffff:fffe 3074 ff02::2 3544 ICMPv6 103 Router Solicitation
3 fe80::8000:f227:d7ab:e6c3 3544 fe80::ffff:ffff:fffe 3074 ICMPv6 151 Router Advertisement
Notice that :program:`tshark` shows frames 2 and 3 as IPv6, whereas
:program:`tcpdump` shows them as IPv4.
Let’s take a closer look at frame 2 to see the encapsulation in detail:
.. literal-emph::
Frame 2: 103 bytes on wire (824 bits), 103 bytes captured (824 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Dec 15, 2020 00:55:59.321945000 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1607993759.321945000 seconds
[Time delta from previous captured frame: 1.031406000 seconds]
[Time delta from previous displayed frame: 1.031406000 seconds]
[Time since reference or first frame: 1.031406000 seconds]
Frame Number: 2
Frame Length: 103 bytes (824 bits)
Capture Length: 103 bytes (824 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:teredo:ipv6:icmpv6]
Ethernet II, Src: bc:83:85:56:2f:67, Dst: fc:ec:da:49:e0:10
Destination: fc:ec:da:49:e0:10
Address: fc:ec:da:49:e0:10
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: bc:83:85:56:2f:67
Address: bc:83:85:56:2f:67
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
**Internet Protocol Version 4, Src: 192.168.4.31, Dst: 40.84.25.61**
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 89
Identification: 0xbb91 (48017)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 128
Protocol: UDP (17)
Header checksum: 0x78aa [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.4.31
Destination: 40.84.25.61
**User Datagram Protocol, Src Port: 3074, Dst Port: 3544**
Source Port: 3074
Destination Port: 3544
Length: 69
Checksum: 0x7fdc [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
**Teredo IPv6 over UDP tunneling**
Teredo Authentication header
Client identifier length: 0
Authentication value length: 0
Nonce value: 6aeec3b128884291
Confirmation byte: 00
**Internet Protocol Version 6, Src: fe80::ffff:ffff:fffe, Dst: ff02::2**
**0110 .... = Version: 6**
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 8
Next Header: ICMPv6 (58)
Hop Limit: 255
Source: fe80::ffff:ffff:fffe
Destination: ff02::2
**Internet Control Message Protocol v6**
Type: Router Solicitation (133)
Code: 0
Checksum: 0x7d38 [correct]
[Checksum Status: Good]
Reserved: 00000000
The bolded elements show an ICMPv6 message inside an IPv6 packet, inside a UDP
datagram, inside a IPv4 packet. Frame 3 is similar.
:file:`conn.log`
----------------
The :file:`conn.log` for this traffic contains the following:
.. literal-emph::
{
"ts": 1607993759.321945,
**"uid": "CO9T0A3FPac5ig4hud",**
**"id.orig_h": "192.168.4.31",**
"id.orig_p": 3074,
**"id.resp_h": "40.84.25.61",**
**"id.resp_p": 3544,**
**"proto": "udp",**
**"service": "teredo",**
"duration": 0.015377998352050781,
"orig_bytes": 61,
"resp_bytes": 109,
"conn_state": "SF",
"missed_bytes": 0,
"history": "Dd",
"orig_pkts": 1,
"orig_ip_bytes": 89,
"resp_pkts": 1,
"resp_ip_bytes": 137,
"ip_proto": 17
}
This first :file:`conn.log` entry addresses frames 2 and 3 in the original packet
capture. Zeek identifies Teredo as the service within a UDP datagram. Port 3544
UDP appears to be associated with Teredo per Microsoft’s documentation. Port
3074 UDP appears to be associated with Microsoft game consoles as well, perhaps
due to NAT traversal. Note the ``uid`` field. It will appear again
shortly.
.. literal-emph::
{
"ts": 1607993758.290539,
**"uid": "CUqiKk4m6VpWwcaJ4l",**
**"id.orig_h": "192.168.4.31",**
"id.orig_p": 3074,
**"id.resp_h": "40.84.25.61",**
**"id.resp_p": 65444,**
**"proto": "udp",**
"conn_state": "S0",
"missed_bytes": 0,
"history": "D",
"orig_pkts": 1,
"orig_ip_bytes": 89,
"resp_pkts": 0,
"resp_ip_bytes": 0,
"ip_proto": 17
}
This second :file:`conn.log` entry refers to frame 1 in the packet capture.
Note the ``uid`` field. It will appear again shortly as well.
.. literal-emph::
{
"ts": 1607993759.321945,
"uid": "CoiibpW4Ov0n1xvj",
**"id.orig_h": "fe80::ffff:ffff:fffe",**
"id.orig_p": 133,
**"id.resp_h": "ff02::2",**
"id.resp_p": 134,
**"proto": "icmp",**
"conn_state": "OTH",
"missed_bytes": 0,
"orig_pkts": 1,
"orig_ip_bytes": 48,
"resp_pkts": 0,
"resp_ip_bytes": 0,
"tunnel_parents": [
**"CO9T0A3FPac5ig4hud"**
],
"ip_proto": 1
}
Here Zeek has created a new :file:`conn.log` entry for the ICMPv6 traffic
carried within a tunnel. The UID of the original connection carrying this
traffic appears in the ``tunnel_parents`` field. It refers to the first entry
in the :file:`conn.log`.
.. literal-emph::
{
"ts": 1607993758.290539,
"uid": "C6Gikx4eC6wXR3xOqg",
**"id.orig_h": "fe80::8000:ffff:ffff:fffe",**
"id.orig_p": 133,
**"id.resp_h": "ff02::2",**
"id.resp_p": 134,
**"proto": "icmp",**
"conn_state": "OTH",
"missed_bytes": 0,
"orig_pkts": 1,
"orig_ip_bytes": 48,
"resp_pkts": 0,
"resp_ip_bytes": 0,
"tunnel_parents": [
"CUqiKk4m6VpWwcaJ4l"
]
}
Similar to the previous :file:`conn.log` entry, here is another tunneled ICMPv6
message. This corresponds to the second :file:`conn.log` entry reviewed earlier.
.. literal-emph::
{
"ts": 1607993759.337323,
"uid": "C8h2gZ3EjWUW5xKh2",
**"id.orig_h": "fe80::8000:f227:d7ab:e6c3",**
"id.orig_p": 134,
**"id.resp_h": "fe80::ffff:ffff:fffe",**
"id.resp_p": 133,
**"proto": "icmp",**
"conn_state": "OTH",
"missed_bytes": 0,
"orig_pkts": 1,
"orig_ip_bytes": 88,
"resp_pkts": 0,
"resp_ip_bytes": 0,
"tunnel_parents": [
**"CO9T0A3FPac5ig4hud"**
]
}
Zeek creates a final :file:`conn.log` entry for tunneled traffic. This also
corresponds to the first :file:`conn.log` entry by virtue of its
``tunnel_parent`` value.
:file:`tunnel.log`
------------------
Zeek’s :file:`tunnel.log` offers the following entries for this encapsulated
traffic.
.. literal-emph::
{
"ts": 1607993758.290539,
"uid": "CUqiKk4m6VpWwcaJ4l",
"id.orig_h": "192.168.4.31",
"id.orig_p": 3074,
"id.resp_h": "40.84.25.61",
"id.resp_p": 65444,
**"tunnel_type": "Tunnel::TEREDO",**
**"action": "Tunnel::DISCOVER"**
}
{
"ts": 1607993759.321945,
"uid": "CO9T0A3FPac5ig4hud",
"id.orig_h": "192.168.4.31",
"id.orig_p": 3074,
"id.resp_h": "40.84.25.61",
"id.resp_p": 3544,
**"tunnel_type": "Tunnel::TEREDO",**
**"action": "Tunnel::DISCOVER"**
}
{
"ts": 1607993759.337323,
"uid": "CO9T0A3FPac5ig4hud",
"id.orig_h": "192.168.4.31",
"id.orig_p": 3074,
"id.resp_h": "40.84.25.61",
"id.resp_p": 3544,
**"tunnel_type": "Tunnel::TEREDO",**
**"action": "Tunnel::CLOSE"**
}
{
"ts": 1607993759.337323,
"uid": "CUqiKk4m6VpWwcaJ4l",
"id.orig_h": "192.168.4.31",
"id.orig_p": 3074,
"id.resp_h": "40.84.25.61",
"id.resp_p": 65444,
**"tunnel_type": "Tunnel::TEREDO",**
**"action": "Tunnel::CLOSE"**
}
The ``action`` messages indicate how Zeek is tracking the connections. When it
first identifies a tunnel, it reports ``DISCOVER``. When it assesses that the
tunnel is no longer used, Zeek reports ``CLOSE``.
The take-away from this activity is that Zeek has identified Teredo traffic.
The :file:`tunnel.log` entries abstract the somewhat complicated detailed logs
and produce results that are a bit
friendlier to the analyst. Here we see that the systems involved are opening
and closing Teredo tunnels. If this is not authorized traffic, it is enough to
begin a more detailed investigation.
IP in IP
========
The next example shows transporting IPv4 inside IPv4 traffic. :rfc:`1853` states:
“The IP in IP encapsulation Protocol/Payload number 4 :rfc:`1700` has long
been used to bridge portions of the Internet which have disjoint capabilities
or policies.”
This is another encapsulation method that might surprise an analyst
or network administrator, assuming it is not authorized for use.
:program:`tcpdump` and :program:`tshark`
----------------------------------------
Here is :program:`tcpdump`’s view of the sample traffic:
.. literal-emph::
12:12:06.059907 **IP 10.0.0.1 > 10.0.0.2: IP 1.1.1.1 > 2.2.2.2: ICMP echo request**, id 4, seq 0, length 80 (ipip-proto-4)
12:12:06.067958 **IP 10.0.0.2 > 10.0.0.1: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply**, id 4, seq 0, length 80 (ipip-proto-4)
12:12:06.075906 IP 10.0.0.1 > 10.0.0.2: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 4, seq 1, length 80 (ipip-proto-4)
12:12:06.083920 IP 10.0.0.2 > 10.0.0.1: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 4, seq 1, length 80 (ipip-proto-4)
12:12:06.091909 IP 10.0.0.1 > 10.0.0.2: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 4, seq 2, length 80 (ipip-proto-4)
12:12:06.099922 IP 10.0.0.2 > 10.0.0.1: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 4, seq 2, length 80 (ipip-proto-4)
12:12:06.107906 IP 10.0.0.1 > 10.0.0.2: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 4, seq 3, length 80 (ipip-proto-4)
12:12:06.116057 IP 10.0.0.2 > 10.0.0.1: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 4, seq 3, length 80 (ipip-proto-4)
12:12:06.123910 IP 10.0.0.1 > 10.0.0.2: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 4, seq 4, length 80 (ipip-proto-4)
12:12:06.131919 IP 10.0.0.2 > 10.0.0.1: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 4, seq 4, length 80 (ipip-proto-4)
Here is :program:`tshark`’s view of the first packet:
.. literal-emph::
Frame 1: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jun 21, 2008 12:12:06.059907000 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1214050326.059907000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 134 bytes (1072 bits)
Capture Length: 134 bytes (1072 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:ip:icmp:data]
Ethernet II, Src: c2:00:57:75:00:00, Dst: c2:01:57:75:00:00
Destination: c2:01:57:75:00:00
Address: c2:01:57:75:00:00
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: c2:00:57:75:00:00
Address: c2:00:57:75:00:00
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
**Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2**
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 120
Identification: 0x0014 (20)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 255
Protocol: IPIP (4)
Header checksum: 0xa76b [validation disabled]
[Header checksum status: Unverified]
Source: 10.0.0.1
Destination: 10.0.0.2
**Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2**
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 100
Identification: 0x0014 (20)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 255
**Protocol: ICMP (1)**
Header checksum: 0xb57f [validation disabled]
[Header checksum status: Unverified]
Source: 1.1.1.1
Destination: 2.2.2.2
**Internet Control Message Protocol**
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4305 [correct]
[Checksum Status: Good]
Identifier (BE): 4 (0x0004)
Identifier (LE): 1024 (0x0400)
Sequence number (BE): 0 (0x0000)
Sequence number (LE): 0 (0x0000)
Data (72 bytes)
0000 00 00 00 00 00 09 3b 38 ab cd ab cd ab cd ab cd ......;8........
0010 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................
0020 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................
0030 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................
0040 ab cd ab cd ab cd ab cd ........
Data: 0000000000093b38abcdabcdabcdabcdabcdabcdabcdabcd...
[Length: 72]
Note that both renditions depict the outer and inner IP addresses in use, as
well as the encapsulated ICMP traffic.
:file:`conn.log`
----------------
Zeek creates a single :file:`conn.log` entry for this traffic.
.. literal-emph::
{
"ts": 1214050326.059907,
"uid": "CaG4lb2HwGhNGLo1d2",
**"id.orig_h": "1.1.1.1",**
"id.orig_p": 8,
**"id.resp_h": "2.2.2.2",**
"id.resp_p": 0,
**"proto": "icmp",**
"duration": 0.07201194763183594,
"orig_bytes": 360,
"resp_bytes": 360,
"conn_state": "OTH",
"missed_bytes": 0,
"orig_pkts": 5,
"orig_ip_bytes": 500,
"resp_pkts": 5,
"resp_ip_bytes": 500,
**"tunnel_parents": [**
**"CllZAw139PBBVBawlj"**
]
}
Notice the only :file:`conn.log` entry lists the encapsulated source and
destination IP addresses for the traffic, i.e., ``1.1.1.1`` and ``2.2.2.2``. To
see the outer IP addresses, we need to look for the ``tunnel_parents``
connection in the :file:`tunnel.log`.
:file:`tunnel.log`
------------------
The :file:`tunnel.log` also contains a single entry:
.. literal-emph::
{
"ts": 1214050326.059907,
"uid": "CllZAw139PBBVBawlj",
**"id.orig_h": "10.0.0.1",**
"id.orig_p": 0,
**"id.resp_h": "10.0.0.2",**
"id.resp_p": 0,
**"tunnel_type": "Tunnel::IP",**
**"action": "Tunnel::DISCOVER"**
}
Here we learn that the outer IP addresses are ``10.0.0.1`` and ``10.0.0.2``.
The tunnel type is ``IP``. The action of ``Tunnel::DISCOVER`` means that Zeek
has identified a new tunnel or encapsulation.
IP over IP via GRE
==================
Let’s look at a more common variation of IP within IP. This method uses Generic
Routing Encapsulation, or GRE.
:program:`tcpdump` and :program:`tshark`
----------------------------------------
Here is :program:`tcpdump`’s view of the traffic:
.. literal-emph::
12:06:06.434897 **IP 10.0.0.1 > 10.0.0.2: GREv0, length 104: IP 1.1.1.1 > 2.2.2.2: ICMP echo request**, id 2, seq 0, length 80
12:06:06.442931 **IP 10.0.0.2 > 10.0.0.1: GREv0, length 104: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply**, id 2, seq 0, length 80
12:06:06.450900 IP 10.0.0.1 > 10.0.0.2: GREv0, length 104: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 2, seq 1, length 80
12:06:06.498938 IP 10.0.0.2 > 10.0.0.1: GREv0, length 104: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 2, seq 1, length 80
12:06:06.506904 IP 10.0.0.1 > 10.0.0.2: GREv0, length 104: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 2, seq 2, length 80
12:06:06.514914 IP 10.0.0.2 > 10.0.0.1: GREv0, length 104: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 2, seq 2, length 80
12:06:06.522905 IP 10.0.0.1 > 10.0.0.2: GREv0, length 104: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 2, seq 3, length 80
12:06:06.570925 IP 10.0.0.2 > 10.0.0.1: GREv0, length 104: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 2, seq 3, length 80
12:06:06.578905 IP 10.0.0.1 > 10.0.0.2: GREv0, length 104: IP 1.1.1.1 > 2.2.2.2: ICMP echo request, id 2, seq 4, length 80
12:06:06.586923 IP 10.0.0.2 > 10.0.0.1: GREv0, length 104: IP 2.2.2.2 > 1.1.1.1: ICMP echo reply, id 2, seq 4, length 80
Here is :program:`tshark`’s view of the first packet:
.. literal-emph::
Frame 1: 138 bytes on wire (1104 bits), 138 bytes captured (1104 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jun 21, 2008 12:06:06.434897000 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1214049966.434897000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 138 bytes (1104 bits)
Capture Length: 138 bytes (1104 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:gre:ip:icmp:data]
Ethernet II, Src: c2:00:57:75:00:00, Dst: c2:01:57:75:00:00
Destination: c2:01:57:75:00:00
Address: c2:01:57:75:00:00
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: c2:00:57:75:00:00
Address: c2:00:57:75:00:00
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
**Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.2**
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 124
Identification: 0x000a (10)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 255
Protocol: Generic Routing Encapsulation (47)
Header checksum: 0xa746 [validation disabled]
[Header checksum status: Unverified]
Source: 10.0.0.1
Destination: 10.0.0.2
**Generic Routing Encapsulation (IP)**
Flags and Version: 0x0000
0... .... .... .... = Checksum Bit: No
.0.. .... .... .... = Routing Bit: No
..0. .... .... .... = Key Bit: No
...0 .... .... .... = Sequence Number Bit: No
.... 0... .... .... = Strict Source Route Bit: No
.... .000 .... .... = Recursion control: 0
.... .... 0000 0... = Flags (Reserved): 0
.... .... .... .000 = Version: GRE (0)
Protocol Type: IP (0x0800)
**Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2**
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 100
Identification: 0x000a (10)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 255
Protocol: ICMP (1)
Header checksum: 0xb589 [validation disabled]
[Header checksum status: Unverified]
Source: 1.1.1.1
Destination: 2.2.2.2
**Internet Control Message Protocol**
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xbfd4 [correct]
[Checksum Status: Good]
Identifier (BE): 2 (0x0002)
Identifier (LE): 512 (0x0200)
Sequence number (BE): 0 (0x0000)
Sequence number (LE): 0 (0x0000)
Data (72 bytes)
0000 00 00 00 00 00 03 be 70 ab cd ab cd ab cd ab cd .......p........
0010 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................
0020 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................
0030 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................
0040 ab cd ab cd ab cd ab cd ........
Data: 000000000003be70abcdabcdabcdabcdabcdabcdabcdabcd...
[Length: 72]
Note that both renditions depict the outer and inner IP addresses in use, as
well as the encapsulated ICMP traffic. This time, in contrast with the previous
example, the inner traffic follows a GRE header.
:file:`conn.log`
----------------
Zeek creates a single :file:`conn.log` entry for this traffic:
.. literal-emph::
{
"ts": 1214049966.434897,
"uid": "Cxg76d2N73I9DhmZ5l",
**"id.orig_h": "1.1.1.1",**
"id.orig_p": 8,
**"id.resp_h": "2.2.2.2",**
"id.resp_p": 0,
**"proto": "icmp",**
"duration": 0.15202593803405762,
"orig_bytes": 360,
"resp_bytes": 360,
"conn_state": "OTH",
"missed_bytes": 0,
"orig_pkts": 5,
"orig_ip_bytes": 500,
"resp_pkts": 5,
"resp_ip_bytes": 500,
"tunnel_parents": [
**"C2ELkSIprfG0oMEae"**
]
}
As with the previous example, the only :file:`conn.log` entry lists the encapsulated
source and destination IP addresses for the traffic, i.e., ``1.1.1.1`` and
``2.2.2.2``. To see the outer IP addresses, we need to look for the
``tunnel_parents`` connection in the :file:`tunnel.log`.
:file:`tunnel.log`
------------------
The :file:`tunnel.log` also contains a single entry:
.. literal-emph::
{
"ts": 1214049966.434897,
"uid": "C2ELkSIprfG0oMEae",
**"id.orig_h": "10.0.0.1",**
"id.orig_p": 0,
**"id.resp_h": "10.0.0.2",**
"id.resp_p": 0,
**"tunnel_type": "Tunnel::GRE",**
**"action": "Tunnel::DISCOVER"**
}
We see again that the outer IP addresses are ``10.0.0.1`` and ``10.0.0.2``. The
tunnel type is ``GRE``, unlike the previous ``IP``. The action of
``Tunnel::DISCOVER`` means that Zeek has identified a new tunnel or
encapsulation.
IPv4 in PPP in GRE in IPv4 in IPv6
==================================
We’ve saved the most complicated example for last.
In this example, we see the following very complicated protocol stack::
Ethernet II
802.1Q virtual LAN (VLAN)
IPv6
IPv4
GRE
Point-to-Point Protocol (PPP)
IPv4
UDP
Domain Name System
I am not sure what created this trace, although I suspect it may be from a
mobile asset.
:program:`tcpdump` and :program:`tshark`
----------------------------------------
Here is :program:`tcpdump`’s view of the sample traffic::
03:35:03.821897 IP6 2402:f000:1:8e01::5555 > 2607:fcd0:100:2300::b108:2a6b: IP 16.0.0.200 > 192.52.166.154: GREv1, call 6016, seq 430001, ack 539254, length 119: IP 172.16.44.3.40768 > 8.8.8.8.53: 42540+ AAAA? xqt-detect-mode2-97712e88-167a-45b9-93ee-913140e76678. (71)
03:35:04.035791 IP6 2607:fcd0:100:2300::b108:2a6b > 2402:f000:1:8e01::5555: IP 192.52.166.154 > 16.0.0.200: GREv1, call 17, seq 539320, length 190: IP 8.8.8.8.53 > 172.16.44.3.40768: 42540 NXDomain 0/1/0 (146)
Here is :program:`tshark`’s view of the first packet:
.. literal-emph::
Frame 1: 197 bytes on wire (1576 bits), 197 bytes captured (1576 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Dec 3, 2014 03:35:03.821897000 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1417577703.821897000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 197 bytes (1576 bits)
Capture Length: 197 bytes (1576 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:vlan:ethertype:ipv6:ip:gre:ppp:ip:udp:dns]
**Ethernet II, Src: 00:12:1e:f2:61:3d, Dst: c5:00:00:00:82:c4**
Destination: c5:00:00:00:82:c4
Address: c5:00:00:00:82:c4
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: 00:12:1e:f2:61:3d
Address: 00:12:1e:f2:61:3d
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: 802.1Q Virtual LAN (0x8100)
**802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 100**
000. .... .... .... = Priority: Best Effort (default) (0)
...0 .... .... .... = DEI: Ineligible
.... 0000 0110 0100 = ID: 100
Type: IPv6 (0x86dd)
**Internet Protocol Version 6, Src: 2402:f000:1:8e01::5555, Dst: 2607:fcd0:100:2300::b108:2a6b**
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 139
Next Header: IPIP (4)
Hop Limit: 246
Source: 2402:f000:1:8e01::5555
Destination: 2607:fcd0:100:2300::b108:2a6b
**Internet Protocol Version 4, Src: 16.0.0.200, Dst: 192.52.166.154**
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 139
Identification: 0x8caf (36015)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 64
**Protocol: Generic Routing Encapsulation (47)**
Header checksum: 0x75fe [validation disabled]
[Header checksum status: Unverified]
Source: 16.0.0.200
Destination: 192.52.166.154
Generic Routing Encapsulation (PPP)
Flags and Version: 0x3081
0... .... .... .... = Checksum Bit: No
.0.. .... .... .... = Routing Bit: No
..1. .... .... .... = Key Bit: Yes
...1 .... .... .... = Sequence Number Bit: Yes
.... 0... .... .... = Strict Source Route Bit: No
.... .000 .... .... = Recursion control: 0
.... .... 1... .... = Acknowledgment: Yes
.... .... .000 0... = Flags (Reserved): 0
.... .... .... .001 = Version: Enhanced GRE (1)
Protocol Type: PPP (0x880b)
Payload Length: 103
Call ID: 6016
Sequence Number: 430001
Acknowledgment Number: 539254
**Point-to-Point Protocol**
Address: 0xff
Control: 0x03
Protocol: Internet Protocol version 4 (0x0021)
**Internet Protocol Version 4, Src: 172.16.44.3, Dst: 8.8.8.8**
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 99
Identification: 0x0000 (0)
Flags: 0x4000, Don't fragment
0... .... .... .... = Reserved bit: Not set
.1.. .... .... .... = Don't fragment: Set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 60
Protocol: UDP (17)
Header checksum: 0x5667 [validation disabled]
[Header checksum status: Unverified]
Source: 172.16.44.3
Destination: 8.8.8.8
**User Datagram Protocol, Src Port: 40768, Dst Port: 53**
Source Port: 40768
Destination Port: 53
Length: 79
Checksum: 0x2d23 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
**Domain Name System (query)**
Transaction ID: 0xa62c
Flags: 0x0100 Standard query
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data: Unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
xqt-detect-mode2-97712e88-167a-45b9-93ee-913140e76678: type AAAA, class IN
Name: xqt-detect-mode2-97712e88-167a-45b9-93ee-913140e76678
[Name Length: 53]
[Label Count: 1]
Type: AAAA (IPv6 Address) (28)
Class: IN (0x0001)
Both :program:`tcpdump` and :program:`tshark` show the three levels of IP
addresses used in this complicated frame.
:file:`conn.log`
----------------
Let’s see what Zeek makes of this complicated exchange.
.. literal-emph::
{
"ts": 1417577703.821897,
"uid": "CiJXLc43tlknoHbXH9",
**"id.orig_h": "172.16.44.3",**
"id.orig_p": 40768,
**"id.resp_h": "8.8.8.8",**
"id.resp_p": 53,
"proto": "udp",
"service": "dns",
"duration": 0.21389389038085938,
"orig_bytes": 71,
"resp_bytes": 146,
"conn_state": "SF",
"missed_bytes": 0,
"history": "Dd",
"orig_pkts": 1,
"orig_ip_bytes": 99,
"resp_pkts": 1,
"resp_ip_bytes": 174,
**"tunnel_parents": [**
**"CBvCtfO5sjjyQb2V4"**
]
}
We see Zeek has burrowed all the way down to the innermost IP address,
``172.16.44.3``, making a DNS request to ``8.8.8.8``.
:file:`tunnel.log`
------------------
Zeek’s :file:`tunnel.log` contains two entries for this session.
.. literal-emph::
{
"ts": 1417577703.821897,
"uid": "CPnYZx2edh7O2ueTm4",
**"id.orig_h": "2402:f000:1:8e01::5555",**
"id.orig_p": 0,
**"id.resp_h": "2607:fcd0:100:2300::b108:2a6b",**
"id.resp_p": 0,
**"tunnel_type": "Tunnel::IP",**
**"action": "Tunnel::DISCOVER"**
}
{
"ts": 1417577703.821897,
"uid": "CBvCtfO5sjjyQb2V4",
**"id.orig_h": "16.0.0.200",**
"id.orig_p": 0,
**"id.resp_h": "192.52.166.154",**
"id.resp_p": 0,
**"tunnel_type": "Tunnel::GRE",**
**"action": "Tunnel::DISCOVER"**
}
Zeek displays the two outer IP addresses, and ties them to the inner address
using the ``uid`` field. The ``uid`` matches the ``tunnel_parents`` field in
the :file:`conn.log`.
:file:`dns.log`
---------------
For completeness, let’s take a look at the :file:`dns.log` Zeek created for
this activity.
.. literal-emph::
{
"ts": 1417577703.821897,
"uid": "CiJXLc43tlknoHbXH9",
**"id.orig_h": "172.16.44.3",**
"id.orig_p": 40768,
**"id.resp_h": "8.8.8.8",**
**"id.resp_p": 53,**
"proto": "udp",
"trans_id": 42540,
"query": "xqt-detect-mode2-97712e88-167a-45b9-93ee-913140e76678",
"qclass": 1,
"qclass_name": "C_INTERNET",
"qtype": 28,
**"qtype_name": "AAAA",**
"rcode": 3,
"rcode_name": "NXDOMAIN",
"AA": false,
"TC": false,
"RD": true,
"RA": false,
"Z": 0,
"rejected": false
}
Here is a AAAA query, meaning the client wants the IPv6 address for the domain
listed in the query. As you might guess, the DNS server reply (not shown here)
is for a root name server.
Conclusion
==========
Zeek’s :file:`tunnel.log` is a useful way to accomplish two tasks. First, the
presence of a :file:`tunnel.log` in your collection of Zeek outputs means Zeek
has detected and reported on encapsulated traffic. If you do not expect to see
such activity in your environment, it is worth investigating. Second, the
:file:`tunnel.log` provides a means to show the outermost IP addresses
associated with the activity reported in the :file:`conn.log` when
encapsulation is present.
Reference in New Issue View Git Blame Copy Permalink