feat(netflow): flow detail enhancements #975

New issue

Closed

opened 2026-03-28 04:30:26 +00:00 by mfreeman451 · 0 comments

mfreeman451 commented

2026-03-28 04:30:26 +00:00

Owner

Imported from GitHub.

Original GitHub issue: #2746
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/issues/2746
Original created: 2026-02-09T03:55:46Z

Is your feature request related to a problem?

In the flow details modal view, we should be mapping protocol numbers to strings/services:

https://datatracker.ietf.org/doc/html/rfc5237

Should be done in web-ng UI layer with a simple map

Mapping the protocol numbers to IANA names is a great first step. Since you are looking to enhance the analyst's experience, here are several high-value enrichments you can add to this view, specifically focusing on TCP flags and flow context.

1. Decoding TCP Flags

The current view shows tcp_flags: 0. For TCP flows, this is usually a cumulative bitmask of all flags seen during the life of the flow. Showing the integer is difficult for humans to parse; you should decode it into readable string badges.

The Mapping Logic:
- 0x01 (1): FIN
- 0x02 (2): SYN
- 0x04 (4): RST
- 0x08 (8): PSH
- 0x10 (16): ACK
- 0x20 (32): URG
- 0x40 (64): ECE
- 0x80 (128): CWR
UI Recommendation: Instead of just a string, use small "badges" or "chips." For example, if the value is 18 (SYN + ACK), show: [SYN] [ACK].
Security Context: If you see SYN without an ACK and bytes_out: 0, you can automatically flag it as a "Connection Attempt" or "Potential Scan."

2. Service/Port Mapping

Your Destination Port is 9000.

Enrichment: Use the IANA Service Name Registry to map ports to known services.
Implementation: Next to 9000, add (Portainer / Ceph / VPP). This immediately tells the analyst if the traffic is expected (e.g., "Why is our backup server talking to a web UI port?").

3. Flow Directionality & State

Looking at your Volume section, there is a major clue: bytes_in: 25,032,326 but bytes_out: 0.

Enrichment: Label this as a "Unidirectional Flow".
Why it matters: In a healthy TCP/UDP exchange, you usually expect some level of bi-directional traffic. A large unidirectional UDP flow (as seen in your screenshot) from a DigitalOcean IP to a private IP is highly characteristic of a UDP Flood (DDoS) or a Media Stream. Highlighting this asymmetry helps catch data exfiltration or attacks.

4. MAC Address (OUI) Lookup

You have the MAC addresses: 5c:83:82:ca:cf:e6 and f4:92:bf:75:c7:29.

Enrichment: Add a vendor prefix lookup (OUI).
Example: 5c:83:82 belongs to DigitalOcean (KVM/QEMU Virtual NIC). Knowing the hardware manufacturer helps verify if the device is what it claims to be (e.g., seeing "Apple" on a server IP would be a red flag).

5. Advanced Security Enrichment

ASN Classification: You've identified AS14061 (DigitalOcean). Add a classification label like "Hosting/Data Center". Traffic coming from "Hosting" vs. "Consumer ISP" carries very different risk profiles.
Internal Asset Context: For the destination 192.168.2.22, if you have an internal CMDB or DHCP logs, resolve this to a Hostname (e.g., PROD-DB-01) and OS Type.
Reputation Quick-Links: Add "External Search" icons next to the source IP that link directly to VirusTotal, AbuseIPDB, or Cisco Talos with the IP pre-filled in the URL.

6. Throughput Calculation

Since you have total bytes and (presumably) a flow duration from the raw fields:

Enrichment: Calculate the bps (bits per second).
Context: 25MB over 10 minutes is a slow background task. 25MB over 1 second is a significant spike that warrants immediate attention. Show this as a "Flow Rate" in the Volume block.

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

Imported from GitHub. Original GitHub issue: #2746 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/issues/2746 Original created: 2026-02-09T03:55:46Z --- **Is your feature request related to a problem?** In the flow details modal view, we should be mapping protocol numbers to strings/services: <img width="1023" height="757" alt="Image" src="https://github.com/user-attachments/assets/1bbdad16-be71-447c-99e8-dddb35d6cd26" /> https://datatracker.ietf.org/doc/html/rfc5237 Should be done in `web-ng` UI layer with a simple map --- Mapping the protocol numbers to IANA names is a great first step. Since you are looking to enhance the analyst's experience, here are several high-value enrichments you can add to this view, specifically focusing on TCP flags and flow context. ### 1. Decoding TCP Flags The current view shows `tcp_flags: 0`. For TCP flows, this is usually a cumulative bitmask of all flags seen during the life of the flow. Showing the integer is difficult for humans to parse; you should decode it into readable string badges. * **The Mapping Logic:** * `0x01` (1): **FIN** * `0x02` (2): **SYN** * `0x04` (4): **RST** * `0x08` (8): **PSH** * `0x10` (16): **ACK** * `0x20` (32): **URG** * `0x40` (64): **ECE** * `0x80` (128): **CWR** * **UI Recommendation:** Instead of just a string, use small "badges" or "chips." For example, if the value is `18` (`SYN` + `ACK`), show: `[SYN] [ACK]`. * **Security Context:** If you see `SYN` without an `ACK` and `bytes_out: 0`, you can automatically flag it as a **"Connection Attempt"** or **"Potential Scan."** ### 2. Service/Port Mapping Your Destination Port is `9000`. * **Enrichment:** Use the IANA Service Name Registry to map ports to known services. * **Implementation:** Next to `9000`, add `(Portainer / Ceph / VPP)`. This immediately tells the analyst if the traffic is expected (e.g., "Why is our backup server talking to a web UI port?"). ### 3. Flow Directionality & State Looking at your **Volume** section, there is a major clue: `bytes_in: 25,032,326` but `bytes_out: 0`. * **Enrichment:** Label this as a **"Unidirectional Flow"**. * **Why it matters:** In a healthy TCP/UDP exchange, you usually expect some level of bi-directional traffic. A large unidirectional UDP flow (as seen in your screenshot) from a DigitalOcean IP to a private IP is highly characteristic of a **UDP Flood (DDoS)** or a **Media Stream**. Highlighting this asymmetry helps catch data exfiltration or attacks. ### 4. MAC Address (OUI) Lookup You have the MAC addresses: `5c:83:82:ca:cf:e6` and `f4:92:bf:75:c7:29`. * **Enrichment:** Add a vendor prefix lookup (OUI). * **Example:** `5c:83:82` belongs to **DigitalOcean (KVM/QEMU Virtual NIC)**. Knowing the hardware manufacturer helps verify if the device is what it claims to be (e.g., seeing "Apple" on a server IP would be a red flag). ### 5. Advanced Security Enrichment * **ASN Classification:** You've identified `AS14061 (DigitalOcean)`. Add a classification label like **"Hosting/Data Center"**. Traffic coming from "Hosting" vs. "Consumer ISP" carries very different risk profiles. * **Internal Asset Context:** For the destination `192.168.2.22`, if you have an internal CMDB or DHCP logs, resolve this to a **Hostname** (e.g., `PROD-DB-01`) and **OS Type**. * **Reputation Quick-Links:** Add "External Search" icons next to the source IP that link directly to **VirusTotal**, **AbuseIPDB**, or **Cisco Talos** with the IP pre-filled in the URL. ### 6. Throughput Calculation Since you have total bytes and (presumably) a flow duration from the raw fields: * **Enrichment:** Calculate the **bps (bits per second)**. * **Context:** 25MB over 10 minutes is a slow background task. 25MB over 1 second is a significant spike that warrants immediate attention. Show this as a "Flow Rate" in the Volume block. * **Describe the solution you'd like** A clear and concise description of what you want to happen. **Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered. **Additional context** Add any other context or screenshots about the feature request here.