scripts and texts

documentation/thesis/00-acronyms.tex

@@ -3,6 +3,7 @@
 
 \begin{acronym}[HTTPS] % Give the longest label here so that the list is nicely aligned
   \acro{API}{Application Programming Interface}
+  \acro{ARP}{Address Resolution Protocol}
   \acro{HTML}{HyperText Markup Language}
   \acro{HTTPS}{Hypertext Transfer Protocol Secure}
   \acro{HTTP}{Hypertext Transfer Protocol}

documentation/thesis/02-preliminaries.tex

@@ -6,40 +6,73 @@ In this chapter, the necessary background and foundational concepts underlying t
 \section{\ac{OSI} Model}
 \label{sec:osi}
 
-The \ac{OSI} Basic Reference Model, defined in X.200, provides a conceptual framework for understanding and standardizing communication between open systems. Its central purpose is to describe network communication in a structured and interoperable way by dividing the communication process into seven layers, each with a distinct function and relationship to the adjacent layers. This layered approach makes it possible to separate communication tasks into manageable parts, thereby supporting the design, specification, and implementation of interoperable systems.
+The \ac{OSI} Basic Reference Model provides a conceptual framework for describing communication between open systems in a structured and interoperable way. Instead of treating network communication as a single process, it divides it into seven layers with clearly separated responsibilities. This layered view simplifies the analysis of communication systems and provides a common terminology for discussing protocols and interfaces.
 
-The \ac{OSI} model is not a concrete protocol suite but a reference architecture. In other words, it does not prescribe a specific technology for network communication; instead, it establishes a common conceptual model that can be used to describe how communication functions should be organized. The seven-layer structure is one of its most important features, because it defines a hierarchy of services and interfaces that together form a complete communication system. Each layer performs a defined set of functions and provides services to the layer above while relying on the services of the layer below.
+The \ac{OSI} model is not itself a concrete protocol suite, but rather a reference architecture. It does not prescribe which technologies must be used in practice. Instead, it provides a general structure that can be used to classify communication functions and to explain how different protocols relate to one another. Each layer offers services to the layer above while relying on the services of the layer below.
 
 \subsection{Physical Layer}
 
-The Physical Layer is the lowest layer of the \ac{OSI} model and is concerned with the transmission of raw bit streams over a physical medium. It defines the electrical, mechanical, procedural, and functional characteristics of the physical connection. In practical terms, this layer deals with how bits are represented as signals and how they are transmitted across cables, optical fibers, or wireless links. It therefore forms the foundation of all higher-level communication, since no data can be exchanged without a functioning physical transmission path.
+The Physical Layer is concerned with the transmission of raw bit streams over the physical medium. It defines how signals are represented and transferred, for example over cables, optical fibers, or wireless links. It therefore forms the foundation of all higher-level communication.
 
 \subsection{Data Link Layer}
 
-The Data Link Layer provides reliable transfer of data over a direct physical connection between two adjacent nodes. Its role is to organize raw bits from the Physical Layer into structured units and to support local communication across a single link. This layer is also responsible for controlling access to the transmission medium and for detecting and correcting errors that may occur during local transmission. By doing so, it helps ensure that data can be transferred efficiently and with a defined degree of reliability between neighboring systems.
+The Data Link Layer organizes the raw bits received from the Physical Layer into structured units and supports communication between adjacent nodes on the same link. It is responsible for local addressing, medium access control, and error detection on the local transmission path.
 
 \subsection{Network Layer}
 
-The Network Layer extends communication beyond a single local link by providing routing and path selection across multiple interconnected networks. It is responsible for addressing and delivering data from a source to a destination that may be separated by several intermediate systems. This layer therefore introduces the concept of logical network-wide communication, which is essential for interconnection across larger infrastructures. In the \ac{OSI} architecture, the Network Layer plays a central role in enabling internetwork communication by determining how information should travel through the network.
+The Network Layer enables communication beyond a single local link. It provides logical addressing and routing functions that allow data to be forwarded across interconnected networks from a source to a destination.
 
 \subsection{Transport Layer}
 
-The Transport Layer provides end-to-end communication services between application entities in different systems. Its purpose is to support the transfer of data across the complete communication path, independent of the underlying network structure. This layer may provide functions such as segmentation, reassembly, flow control, and error recovery, depending on the service required. It ensures that data can be delivered between hosts in a way that is suitable for the needs of the communicating applications.
+The Transport Layer provides end-to-end communication services between application entities in different systems. Depending on the protocol and service model, this can include segmentation, reassembly, flow control, and error recovery.
 
 \subsection{Session Layer}
 
-The Session Layer is responsible for managing communication sessions between application processes. It establishes, maintains, and terminates sessions, allowing two systems to organize their dialogue in a coordinated manner. This includes controlling the interaction between applications and supporting synchronization during communication. The session concept is important because many communication tasks require a structured exchange rather than isolated data transfers.
+The Session Layer is responsible for establishing, managing, and terminating communication sessions between applications. It structures the dialogue between communicating systems and can support synchronization during longer exchanges.
 
 \subsection{Presentation Layer}
 
-The Presentation Layer provides services related to the representation of data. Its function is to ensure that information sent by one system can be interpreted correctly by another system, even when the two systems use different internal data formats. This layer may therefore handle data translation, formatting, and representation issues. By separating presentation concerns from application logic, the \ac{OSI} model allows the communication process to remain flexible and independent of specific machine representations.
+The Presentation Layer deals with the representation of data. It ensures that information exchanged between systems can be interpreted correctly even when internal data formats differ. Typical functions include formatting, translation, and related representation issues.
 
 \subsection{Application Layer}
 
-The Application Layer is the highest layer of the \ac{OSI} model and provides services directly to user-oriented application processes. It represents the point at which network communication becomes visible to the software used by the end user. This layer supports communication functions that are needed by applications and forms the interface between the communication system and the application domain. In the \ac{OSI} framework, it completes the layered communication path by enabling services that are directly relevant to user interaction.
+The Application Layer is the highest layer of the model and contains the communication functions used directly by application processes. It forms the interface between the communication system and the software that uses network services.
 
 \subsection{Layered Structure and Function}
 
-A key principle of the \ac{OSI} Basic Reference Model is that each layer has a specific scope of responsibility and interacts primarily with the layers immediately above and below it. This design reduces complexity by distributing communication tasks across separate functional levels. It also promotes standardization, because each layer can be specified and analyzed independently within the overall architecture. As a result, the model provides a clear conceptual basis for understanding how communication systems are structured and how interoperability can be achieved.
+A key principle of the \ac{OSI} model is that each layer has a defined scope of responsibility and interacts mainly with the layers directly above and below it. This reduces complexity and supports standardization by allowing communication functions to be discussed separately while still being part of one overall architecture.
 
-The significance of the \ac{OSI} model lies in its ability to describe communication in a modular and systematic way. Rather than treating network communication as a single undivided process, the model breaks it into coordinated functions that are easier to define, implement, and study. This makes the \ac{OSI} Basic Reference Model particularly valuable in technical writing, education, and system analysis. Even where modern protocols do not follow the model exactly, the \ac{OSI} structure remains an important reference for explaining communication principles.
+For the present thesis, the \ac{OSI} model is mainly used as a conceptual orientation for the discussion of communication layers and network functions. Even though the implemented system is better described using the practical \ac{TCP}/\ac{IP} stack, the \ac{OSI} structure remains useful for introducing the general principles of layered communication.
+
+\section{Linux Kernel Networking}
+\label{sec:linux-kernel-networking}
+
+In Linux, networking is handled by a subsystem that spans user space sockets, protocol implementations, filtering and routing logic, network devices, device drivers, and the network interface card. A packet therefore does not move directly from an application to the transport medium or the other way around. Instead, it passes through a sequence of kernel-controlled processing stages on the egress and ingress paths \cite{stephan2024packetpath,linuxkernelnetworkingdocs}.
+
+A central data structure of this subsystem is \texttt{sk\_buff}. In Linux, \texttt{sk\_buff} is the main networking structure representing a packet, but it does not itself contain the packet bytes. Instead, it stores metadata and pointers to associated buffers that hold headers and payload. This design allows Linux to add, inspect, and remove headers efficiently by moving pointers rather than copying the entire packet, and it also enables efficient cloning when multiple processing stages need access to the same packet data \cite{linuxkernelskbuffdocs,stephan2024packetpath}.
+
+\subsection{Layers of a Packet}
+
+On an Ethernet-based system, a packet on the wire is processed as a stack of protocol layers. At the data link layer, the frame contains the Ethernet header with source and destination \ac{MAC} addresses and an EtherType field. Above this follows the network-layer header, for example an IPv4 header. On top of that is the transport-layer header, such as \ac{TCP} or \ac{UDP}. The remaining bytes form the payload delivered to the application. In Linux, lower-layer headers are added on the egress path when the packet moves toward the wire, whereas they are validated and stripped on the ingress path when the packet moves toward the socket \cite{stephan2024packetpath}. When a Linux system operates as a bridge, forwarding decisions are made at Layer 2 on the basis of the destination \ac{MAC} address, that is, before local delivery to higher layers becomes necessary \cite{linuxkernelbridgedocs}.
+
+\subsection{Egress Path}
+
+The egress path begins in user space when an application writes data to a socket, for example by using \texttt{write()}, \texttt{send()}, or \texttt{sendto()}. For IPv4 communication, such a socket is typically an \texttt{AF\_INET} socket. The system call enters the kernel and reaches the socket layer, where \texttt{sock\_sendmsg()} retrieves the socket context and forwards the packet to the transport-layer handler. At this point, Linux may already apply security-related checks through Linux Security Modules \cite{stephan2024packetpath}.
+
+At the transport layer, Linux constructs the transport header and prepares the packet for transmission. For \ac{TCP}, the kernel segments data if necessary, writes it into \texttt{sk\_buff} structures, enqueues it in the socket write queue, builds the \ac{TCP} header, and enforces protocol mechanisms such as maximum segment size, congestion control, and retransmission timers. For \ac{UDP}, the processing path is simpler: the kernel builds the datagram and corresponding transport header with less state and less locking overhead \cite{stephan2024packetpath}.
+
+After transport-layer preparation, the packet enters the IP layer. Here Linux determines the route, typically by consulting the Forwarding Information Base if no suitable destination information is already cached in the packet context. Once a route is available, the kernel builds the IP header and passes the packet through netfilter hook stages such as \texttt{LOCAL\_OUT} and \texttt{POST\_ROUTING}. If necessary, Linux also resolves the next-hop destination at Layer 2, for example by using the neighbor subsystem and the \ac{ARP} to obtain the destination \ac{MAC} address. After that, the Ethernet header is added to the packet \cite{stephan2024packetpath}.
+
+The fully constructed frame then enters the network device transmission path. Linux passes it to \texttt{dev\_queue\_xmit()}, where traffic control and queueing disciplines can process it on egress. After queueing and possible post-processing such as checksum handling or VLAN tagging, the kernel calls the driver transmission function \texttt{ndo\_start\_xmit}. The driver places the packet into the transmit ring of the network interface card, maps the packet buffer for Direct Memory Access, and the hardware finally transmits the frame onto the physical medium \cite{stephan2024packetpath}.
+
+\subsection{Ingress Path}
+
+The ingress path begins when the network interface card receives an Ethernet frame from the physical medium. The hardware checks link-layer conditions such as the \ac{MAC} filter and moves the received bytes into system memory by Direct Memory Access. It then notifies the operating system, which allocates an \texttt{sk\_buff} and stores metadata such as the receiving interface, protocol information, and packet type. At this stage, Linux knows the position of the Ethernet header and can record it as the \texttt{mac\_header} of the packet \cite{stephan2024packetpath,linuxkernelskbuffdocs}.
+
+The packet is then passed into the receive path through functions such as \texttt{netif\_receive\_skb()}. During this stage, Linux can hand the packet to virtual interfaces, VLAN handling, or a receive handler associated with a master device. This is particularly relevant for bridge configurations, because an interface that is part of a Linux bridge can have its received frame intercepted for Layer-2 forwarding logic instead of immediate local delivery \cite{stephan2024packetpath,linuxkernelbridgedocs}.
+
+If the packet is processed as an IP packet, Linux continues with \texttt{ip\_rcv()}. There, the kernel validates essential IP header fields such as version, length, and checksum, sets the pointer to the transport header, and applies the netfilter \texttt{PRE\_ROUTING} hook. The routing logic then decides whether the packet should be forwarded, locally delivered, or treated as multicast traffic. For local delivery, Linux may first reassemble fragmented packets and then applies the \texttt{LOCAL\_IN} hook before stripping the IP header and handing the packet to the appropriate transport-layer protocol handler \cite{stephan2024packetpath}.
+
+At the transport layer, Linux validates the \ac{TCP} or \ac{UDP} header and associates the segment or datagram with the correct socket. For \ac{TCP}, this includes checksum validation, socket lookup, state-machine handling, and enqueuing the packet in the socket receive queue. For \ac{UDP}, the processing path is simpler, but it also includes checksum validation, socket lookup, and datagram consumption. Finally, when the user-space process executes a receiving system call such as \texttt{read()} or \texttt{recv()}, the kernel dequeues the data from the socket receive queue and copies it to user space \cite{stephan2024packetpath}.
+
+For the present thesis, this complete packet path is particularly important because the developed system relies on Linux kernel mechanisms at multiple points of the communication path. The system captures traffic at Layer 2, uses bridge-based forwarding, observes and correlates packets while they traverse ingress and egress processing stages, and manipulates traffic by attaching filtering and processing logic within the kernel-controlled forwarding path.

documentation/thesis/ba.bib

@@ -0,0 +1,73 @@
+@article{cerf1974protocol,
+  author = {Cerf, Vinton G. and Kahn, Robert E.},
+  title = {A Protocol for Packet Network Intercommunication},
+  journaltitle = {IEEE Transactions on Communications},
+  volume = {22},
+  number = {5},
+  pages = {637--648},
+  date = {1974-05},
+  doi = {10.1109/TCOM.1974.1092259}
+}
+
+@techreport{rfc791,
+  author = {Postel, Jon},
+  title = {Internet Protocol},
+  type = {RFC},
+  number = {791},
+  institution = {RFC Editor},
+  date = {1981-09},
+  doi = {10.17487/RFC0791}
+}
+
+@techreport{rfc793,
+  author = {Postel, Jon},
+  title = {Transmission Control Protocol},
+  type = {RFC},
+  number = {793},
+  institution = {RFC Editor},
+  date = {1981-09},
+  doi = {10.17487/RFC0793}
+}
+
+@techreport{rfc1122,
+  author = {Braden, Robert},
+  title = {Requirements for Internet Hosts -- Communication Layers},
+  type = {RFC},
+  number = {1122},
+  institution = {RFC Editor},
+  date = {1989-10},
+  doi = {10.17487/RFC1122}
+}
+
+@inproceedings{stephan2024packetpath,
+  author = {Stephan, Alexander and W{\"u}strich, Lars},
+  title = {The Path of a Packet Through the Linux Kernel},
+  booktitle = {Seminar IITM WS 23},
+  date = {2024},
+  doi = {10.2313/NET-2024-04-1\_16},
+  url = {https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2024-04-1/NET-2024-04-1_16.pdf}
+}
+
+@online{linuxkernelnetworkingdocs,
+  author = {{The Linux Kernel Documentation Authors}},
+  title = {Networking --- The Linux Kernel documentation},
+  year = {2026},
+  url = {https://docs.kernel.org/networking/index.html},
+  urldate = {2026-04-18}
+}
+
+@online{linuxkernelskbuffdocs,
+  author = {{The Linux Kernel Documentation Authors}},
+  title = {struct sk\_buff --- The Linux Kernel documentation},
+  year = {2026},
+  url = {https://docs.kernel.org/networking/skbuff.html},
+  urldate = {2026-04-18}
+}
+
+@online{linuxkernelbridgedocs,
+  author = {{The Linux Kernel Documentation Authors}},
+  title = {Ethernet Bridging --- The Linux Kernel documentation},
+  year = {2026},
+  url = {https://docs.kernel.org/networking/bridge.html},
+  urldate = {2026-04-18}
+}

documentation/thesis/notes/preliminaries ideas.md

@@ -0,0 +1,50 @@
+Your project is already much richer than a generic “MITM tool.” From the code, it is really a transparent inline Layer-2 observation and manipulation platform: it creates a Linux bridge with STP disabled, manages bridge member behavior, captures traffic either via `AF_PACKET` or `tc/eBPF`, correlates packet observations with kernel telemetry, applies `nftables`/`NFQUEUE` manipulation, and builds higher-level traffic intelligence on top of that. You can see those pillars in [network_api.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/api/network_api.py:498), [bridge_link_state_manager.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/utilities/bridge_link_state_manager.py:86), [network_sniffer.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/network_sniffer.py:774), [bridge_telemetry.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/utilities/bridge_telemetry.py:22), [packet_tracker.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/utilities/packet_tracker.py:238), [nftables_api.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/api/nftables_api.py:47), [packet_scripting_api.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/api/packet_scripting_api.py:2), and [analysis_api.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/api/analysis_api.py:145). Compared with your current [02-preliminaries.tex](/home/marcus/Desktop/Masterarbeit/mitm-webserver/documentation/thesis/02-preliminaries.tex:1), the thesis would benefit from moving beyond a mainly OSI-focused introduction.
+
+**What I would definitely add to the preliminaries**
+
+- `Transparent Layer-2 MITM / inline bridge systems`: difference between routed MITM, proxying, TAP/SPAN capture, and transparent bridging.
+- `Ethernet switching and Linux bridge internals`: MAC learning, forwarding database, flooding, broadcast domains, unknown unicast, VLAN awareness, STP/RSTP, and why disabling STP matters for your setup.
+- `Stealth / transparency criteria`: what “hidden” means technically in your thesis. For example: no IP hop added, no TTL change, minimal forwarding delay, preserved link properties, no obvious protocol artifacts.
+- `Link-state propagation and fail behavior`: your code actively mirrors link failures and synchronizes MTU / speed / duplex / autoneg, which is unusually relevant for an inline appliance and worth explaining conceptually.
+- `Linux packet-processing path`: NIC, driver, `sk_buff`, bridge forwarding path, netfilter hooks, `tc` ingress/egress, and where capture/manipulation can be attached.
+- `AF_PACKET raw sockets`: why they are suitable for passive L2 capture, and their trade-offs.
+- `nftables and the bridge family`: tables, chains, hooks, priorities, verdicts, and why bridge-family filtering is important in a transparent bridge scenario.
+- `NFQUEUE`: how packets are punted to user space, latency/performance implications, and the difference between passive observation and inline modification.
+- `eBPF at tc`: attach points, maps, helpers, packet metadata access, and why eBPF is useful for low-overhead telemetry and packet correlation.
+- `Packet marking and correlation`: your project uses `skb->mark`-based packet IDs and verdict bits, which is a very strong thesis concept because it ties kernel events to captured packets ([mark_packet_id.c](/home/marcus/Desktop/Masterarbeit/mitm-webserver/tools/ebpf/mark_packet_id.c:20)).
+- `Protocol parsing and enrichment`: Ethernet, ARP, IPv4/IPv6, TCP/UDP/ICMP, plus DPI/enrichment with Scapy and `tshark` ([tshark_manager.py](/home/marcus/Desktop/Masterarbeit/mitm-webserver/backend/src/utilities/tshark_manager.py:690)).
+- `Flow/conversation reconstruction`: packet identity, deduplication, ingress/egress inference, flow IDs, conversations, and discovery traffic classification.
+- `Threat model and limitations`: what kinds of traffic can be observed/manipulated, how encryption limits analysis, and where the bridge can still become detectable.
+
+**Very thesis-relevant concepts that are specific to your implementation**
+
+- `Bridge transparency vs detectability`
+- `Bridge member synchronization`
+- `Event-driven network control via netlink / pyroute2`
+- `Hybrid observation pipeline: raw capture + kernel telemetry + DPI enrichment`
+- `Correlation of data-plane and control-plane evidence`
+- `Programmable packet handling with nftables + NFQUEUE scripts`
+- `Traffic-intelligence extraction from passive observations`
+- `Discovery protocol analysis`: ARP, DHCP, mDNS, SSDP, LLMNR, NBNS, ICMPv6 discovery
+
+**What I would keep short or move to implementation**
+
+- FastAPI, React, WebSockets, Docker, and general UI architecture
+- PostgreSQL schema details
+- systemd service deployment details for scripts
+
+Those matter, but they feel more like implementation chapter material than preliminaries unless your thesis is explicitly about the full software platform architecture.
+
+**A strong chapter structure could be**
+
+1. Communication models: brief OSI and TCP/IP mapping
+2. Ethernet and transparent bridging
+3. Linux bridge architecture and link-state behavior
+4. Linux packet path: raw sockets, netfilter, `tc`, and `sk_buff`
+5. `nftables`, bridge-family filtering, and `NFQUEUE`
+6. eBPF for packet telemetry and correlation
+7. Packet parsing, DPI, and flow reconstruction
+8. Stealth, detectability, and operational limitations
+9. Ethical and legal boundaries of MITM experimentation
+
+If you want, I can turn this directly into a thesis-ready rewrite for [02-preliminaries.tex](/home/marcus/Desktop/Masterarbeit/mitm-webserver/documentation/thesis/02-preliminaries.tex:1) with subsection titles and short starter paragraphs.

frontend/src/pages/Home.tsx

@@ -1,9 +1,162 @@
-import Title from 'antd/lib/typography/Title';
+import { ApartmentOutlined, AreaChartOutlined, HomeOutlined, MonitorOutlined, RightOutlined } from '@ant-design/icons';
+import { Button, Card, Col, List, Row, Space, Typography } from 'antd';
+import type { ReactElement, ReactNode } from 'react';
+import { useNavigate } from 'react-router-dom';
 
-export default function Home() {
+import FirewallIcon from '../icons/FirewallIcon';
+import TerminalIcon from '../icons/TerminalIcon';
+import { PATHS } from '../routes';
+
+const { Title, Paragraph, Text } = Typography;
+
+type SectionCard = {
+  key: string;
+  title: string;
+  route?: string;
+  icon: ReactNode;
+  summary: string;
+  bullets: string[];
+};
+
+const mainSections: SectionCard[] = [
+  {
+    key: 'home',
+    title: 'Home',
+    route: PATHS.HOME,
+    icon: <HomeOutlined style={{ fontSize: 22 }} />,
+    summary: 'Landing page with a overview of the platform and its main functionalities.',
+    bullets: [''],
+  },
+  {
+    key: 'network',
+    title: 'Network',
+    route: PATHS.NETWORK,
+    icon: <ApartmentOutlined style={{ fontSize: 22 }} />,
+    summary: 'Inspect interfaces, routes, and link-state, create brdiges and enable bridge link state propagation.',
+    bullets: [
+      'Shows the current network state and interface details.',
+      'Creates and removes bridges for traffic interception setups.',
+      'Manages bridge link-state watcher behavior and interface reset operations.',
+    ],
+  },
+  {
+    key: 'firewall',
+    title: 'Firewall',
+    route: PATHS.FIREWALL,
+    icon: <FirewallIcon style={{ fontSize: 22 }} />,
+    summary: 'Build and inspect nftables rules that steer or control packet handling.',
+    bullets: [
+      'Display the current nftables ruleset.',
+      'Create tables, chains and rules without writing everything by hand.',
+      'Push packets into NFQUEUEs.',
+    ],
+  },
+  {
+    key: 'sniffing',
+    title: 'Sniffing',
+    route: PATHS.SNIFFING,
+    icon: <MonitorOutlined style={{ fontSize: 22 }} />,
+    summary: 'Start live packet capture sessions and inspect captured traffic across interfaces and bridges.',
+    bullets: [
+      'Start and stop capture sessions per interface or bridge.',
+      'Show capture status to see where packets are currently being collected.',
+      'Displays captured packets for live inspection.',
+    ],
+  },
+  {
+    key: 'scripting',
+    title: 'Scripting',
+    route: PATHS.SCRIPTING,
+    icon: <TerminalIcon style={{ fontSize: 22 }} width={22} height={22} />,
+    summary: 'Manage NFQUEUE Python scripts that can inspect, modify, delay, or drop packets inline.',
+    bullets: [
+      'Upload and download saved scripts and optional requirements.',
+      'Enable and disable scripts as systemd-backed queue workers.',
+      'Example scripts as baseline for developing new use-cases.',
+    ],
+  },
+  {
+    key: 'analysis',
+    title: 'Analysis',
+    route: PATHS.ANALYSIS,
+    icon: <AreaChartOutlined style={{ fontSize: 22 }} />,
+    summary:
+      'Turn captured traffic into higher-level insights such as hosts, paths, conversations, and protocol usage.',
+    bullets: ['Display visualizations from observed traffic.'],
+  },
+];
+
+function OverviewCard({ section, onOpen }: { section: SectionCard; onOpen?: (route: string) => void }): ReactElement {
   return (
-    <div>
-      <Title level={2}>TBD</Title>
+    <Card
+      title={
+        <Space align="center">
+          {section.icon}
+          <span>{section.title}</span>
+        </Space>
+      }
+      extra={
+        section.route && onOpen ? (
+          <Button type="link" onClick={() => onOpen(section.route!)}>
+            Open <RightOutlined />
+          </Button>
+        ) : null
+      }
+      style={{ height: '100%' }}
+    >
+      <Paragraph style={{ minHeight: 66 }}>{section.summary}</Paragraph>
+      <List
+        size="small"
+        dataSource={section.bullets}
+        renderItem={(item) => (
+          <List.Item style={{ paddingInline: 0 }}>
+            <Text>{item}</Text>
+          </List.Item>
+        )}
+      />
+    </Card>
+  );
+}
+
+export default function Home(): ReactElement {
+  const navigate = useNavigate();
+
+  return (
+    <div style={{ padding: 16 }}>
+      <Row gutter={[16, 16]}>
+        <Col span={24}>
+          <Card>
+            <Title level={2} style={{ marginTop: 0 }}>
+              MITM Webserver App Overview
+            </Title>
+            <Paragraph>
+              This application is a proof-of-concept platform for network traffic configuration, interception,
+              manipulation, and analyzation. It combines network setup, firewall control, packet capture, inline NFQUEUE
+              scripting, and higher-level traffic analysis in one app while trying to stay hidden from the communicating
+              entities.
+            </Paragraph>
+          </Card>
+        </Col>
+
+        <Col span={24}>
+          <Card>
+            <Title level={4} style={{ marginTop: 0 }}>
+              Main Pages
+            </Title>
+            <Paragraph>
+              These are the core working areas of the application. Each page supports a different phase of network
+              experimentation, monitoring, or analysis.
+            </Paragraph>
+            <Row gutter={[16, 16]}>
+              {mainSections.map((section) => (
+                <Col xs={24} md={12} xl={8} key={section.key}>
+                  <OverviewCard section={section} onOpen={(route) => navigate(route)} />
+                </Col>
+              ))}
+            </Row>
+          </Card>
+        </Col>
+      </Row>
     </div>
   );
 }

tools/traffic-target.sh

@@ -7,6 +7,8 @@ TCP_ECHO_PORT=9000
 UDP_ECHO_PORT=9001
 IPERF_TCP_PORT=5201
 IPERF_UDP_PORT=5202
+SOCKPERF_TCP_PORT=11111
+SOCKPERF_UDP_PORT=11112
 DNS_PORT=5353
 WORKDIR="/tmp/mitm-traffic-target"
 CERT_DAYS=2
@@ -25,6 +27,8 @@ Options:
   --udp-echo-port <port>   UDP echo port (default: 9001)
   --iperf-tcp-port <port>  iPerf TCP server port (default: 5201)
   --iperf-udp-port <port>  iPerf UDP server port (default: 5202)
+  --sockperf-tcp-port <port> Sockperf TCP server port (default: 11111)
+  --sockperf-udp-port <port> Sockperf UDP server port (default: 11112)
   --dns-port <port>        Lightweight DNS UDP port (default: 5353)
   --workdir <dir>          Working directory (default: /tmp/mitm-traffic-target)
   --help                   Show this help
@@ -72,6 +76,10 @@ parse_args() {
         IPERF_TCP_PORT="${2:-5201}"; shift 2 ;;
       --iperf-udp-port)
         IPERF_UDP_PORT="${2:-5202}"; shift 2 ;;
+      --sockperf-tcp-port)
+        SOCKPERF_TCP_PORT="${2:-11111}"; shift 2 ;;
+      --sockperf-udp-port)
+        SOCKPERF_UDP_PORT="${2:-11112}"; shift 2 ;;
       --dns-port)
         DNS_PORT="${2:-5353}"; shift 2 ;;
       --workdir)
@@ -124,6 +132,12 @@ main() {
   if ! has_cmd iperf3; then
     log 'iperf3 not found, iperf services will be skipped'
   fi
+  if ! has_cmd sockperf; then
+    log 'sockperf not found, sockperf services will be skipped'
+  fi
+  if ! has_cmd netserver; then
+    log 'netserver not found, Flent netperf-based tests may not work'
+  fi
 
   mkdir -p "$WORKDIR"
   trap cleanup EXIT INT TERM
@@ -144,6 +158,15 @@ main() {
     start_bg iperf_udp iperf3 -s -p "$IPERF_UDP_PORT"
   fi
 
+  if has_cmd sockperf; then
+    start_bg sockperf_tcp sockperf server --tcp --port "$SOCKPERF_TCP_PORT"
+    start_bg sockperf_udp sockperf server --udp --port "$SOCKPERF_UDP_PORT"
+  fi
+
+  if has_cmd netserver; then
+    start_bg netserver netserver -D
+  fi
+
   # Lightweight DNS-like UDP responder to generate DNS-shaped traffic.
   # It echoes fixed bytes and is intended only for packet-generation tests.
   start_bg dns_dummy socat "UDP-LISTEN:${DNS_PORT},reuseaddr,fork" SYSTEM:'printf "\\x81\\x80"'
@@ -159,8 +182,16 @@ Ports:
   UDP echo  : ${UDP_ECHO_PORT}
   iPerf TCP : ${IPERF_TCP_PORT}
   iPerf UDP : ${IPERF_UDP_PORT}
+  Sockperf TCP : ${SOCKPERF_TCP_PORT}
+  Sockperf UDP : ${SOCKPERF_UDP_PORT}
   DNS dummy : ${DNS_PORT}
 
+Matching benchmark options:
+  --iperf-tcp-port ${IPERF_TCP_PORT} --iperf-udp-port ${IPERF_UDP_PORT}
+  --sockperf-tcp-port ${SOCKPERF_TCP_PORT} --sockperf-udp-port ${SOCKPERF_UDP_PORT}
+
+For Flent RRUL/netperf-based tests, install netperf/netserver on this host.
+
 Keep this process running. Press Ctrl+C to stop all services.
 
 INFO