| SPDX-FileCopyrightText | SPDX-License-Identifier | title | author | footer | description | keywords | color | class | style | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
© 2024 Menacit AB <[email protected]> |
CC-BY-SA-4.0 |
Logging course: Network traffic logging |
Joel Rangsmo <[email protected]> |
© Course authors (CC BY-SA 4.0) |
Introduction to network traffic logging |
|
#ffffff |
|
section.center {
text-align: center;
}
table strong {
color: #d63030;
}
table em {
color: #2ce172;
}
|
Capturing/Sniffing of network traffic allows us to implement inspection-based logging.
Freely available tools like tcpdump and WireShark/TShark are easy to use on your own computer/server.
$ tcpdump -v -n -A -i "enp2s0" -- port 80
tcpdump: listening on enp2s0,
link-type EN10MB (Ethernet),
snapshot length 262144 bytes
[...]
11:16:57.522596 IP (tos 0x0, ttl 64, id 33090,
offset 0, flags [DF], proto TCP (6), length 127)
198.18.100.3.45924 > 93.184.216.34.80: Flags [P.],
[...]
GET / HTTP/1.1
Host: example.com
User-Agent: curl/7.81.0
Most enterprise-grade switches supports configuration of a "span/mirror/tap" port.
Just connect a computer and start sniffing.
Public-cloud features like Azure Virtual Network TAP and AWS Traffic Mirroring provide similar capabilities.
Enables fairly low-friction logging implementations!
Sounds good! What's the problem?
Require many CPU cycles and lots of storage I/O operations to handle gigabits of traffic.
You'll also need quite a bit of disk space to store all that data.
These days, most interesting network traffic is encrypted.
Interception boxes exist to decrypt, inspect and re-encrypt data streams.
These interceptors require tricky and risky configuration changes on all networked systems.
Full network capture and storage is limited to highly sensitive environments with limited traffic.
Network Intrusion Detection System.
Look for suspicious network traffic using IoCs.
Functionality typically provided by enterprise-grade firewalls, dedicated appliances and open-source software (Snort, Suricata, Zeek/Bro IDS, etc.)
Doesn't require storage of traffic.
Often extended to act as an Intrusion Prevention System.
Don't just detect attacks, block them.
Sounds great, but introduces some availability risks.
Requires lots of computing resources.
Limited by wide-spread use of encryption.
Mayhaps we don't need to store all traffic, but only metadata?
Let me introduce
Network flow logging.
Limit collection and storage to information about network communication and not its content.
Many solutions define a flow as the same peers, protocol and (when applicable) port.
Highly configurable open-source software.
Only requires a span/mirror/tap port and commodity hardware.
Proprietary protocol developed by Cisco for traffic meta-data logging.
Typically implemented in hardware, resulting in low overhead.
Routers logging traffic (called "exporters") send flow information to a "collector" over the network.
May optionally use sampling to minimize transfer/processing/storage costs.
Formally/Openly standardized by IETF as
Internet Protocol Flow Information eXport.
More or less the same as NetFlow.
If you wanna play with it but don't have an "enterprise-grade" switch, try softflowd.
That's neat, but how is this useful?
Understand how systems really communicate with each other.
Can we decommission this server or does anything still seem to be using it?
Is traffic really reaching the web server or is it blocked somewhere during the path?
Which database server was the application using during a performance incident?
Detect and investigate suspicious traffic patterns.
A laptop has been infected with malware, did it try to communicate with anything?
Has any device performed port scanning in our network?
Has any of our systems communicated with a known bad host?
Complements host-based logging.
Makes more or less sense depending on your network architecture/security model.
Remember that you may need permission to capture/log network traffic.
