Netzwerksicherheit Linuxhotel Juni 2022 (Debian)

• Manuelle IPv4 Konfiguration auf dem Server

ip addr add 100.64.1.2/24 dev server-eth0
ip route add default via 100.64.1.1

• IP Konfiguration fest einstellen in der Datei /etc/network/interfaces

auto server-eth0
iface server-eth0 inet static
        address 100.64.1.2
        netmask 255.255.255.0
        gateway 100.64.1.1

• Manuelle IPv4 Konfiguration auf dem Client

ip addr add 172.16.1.2/24 dev client-eth0
ip route add default via 172.16.1.1

• IP Konfiguration fest einstellen in der Datei /etc/network/interfaces

auto client-eth0
iface client-eth0 inet static
        address 172.16.1.2
        netmask 255.255.255.0
        gateway 172.16.1.1

• vom Server zum Router (auf dem Server):

ping 100.64.1.1
ping 172.16.1.1
ping6 2001:db8:1::1
ping6 fd01::1

• vom Client zum Router (auf dem Client):

ping 172.16.1.1
ping 100.64.1.1
ping6 fd01::1
ping6 2001:db8:1::1

• Geht ein 'ping' vom Server zum Client?

• IPv4 Adresse auf der WAN Schnittstelle des Routers und die Default-Route konfigurieren

root@router-0XX:/# vtysh

Hello, this is FRRouting (version 6.0.2).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

router-0XX# conf t
router-0XX(config)# interface router3-eth0
router-0XX(config-if)# ip address 192.168.1.1/24
router-0XX(config-if)# exit
router-0XX(config-if)# ip route 0.0.0.0/0 192.168.1.2
router-0XX(config)# exit
router-0XX# write
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]

• IPv4 Adresse auf der virtuellen Maschine auf der Netzwerkschnittestelle internet-eth0 konfigurieren

% ip addr add dev internet-eth0 192.168.1.2/24

• Netzwerkschnittstelle internet-eth0 auf der virtuellen Maschine aktivieren

% ip link set dev internet-eth0 up

• Auf der virtuellen Maschine in einer BASH-Shell das NAT einrichten

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

• Auf dem Server ist die Linux Firewall iptables noch nicht installiert. Ab diesem Punkt können wir jedoch Pakete auf dem Router nachinstallieren

% apt install iptables

• Im Router-Container in einer BASH-Shell das NAT einrichten

iptables -A POSTROUTING -t nat -o router3-eth0 -j MASQUERADE

• An diesem Punkt sind sowohl der Router als auch Client und Server mit dem Internet verbunden und können vor dort Software nachinstallieren
• Die Konfiguration der Lab-Umgebung ist abgeschlossen

• prerouting
• input
• output
• forward
• postrouting

• filter (default)
• nat
• mangle
• raw

• ein ! vor einem Regelelement negiert das Regelelement

-i <interface> # Eingangs-Interface
-o <interface> # Ausgangs-Interface
-s <ipaddr>    # Quelladresse
-d <ipaddr>    # Zieladresse
-p <protocol>  # tcp, udp, icmp ...
-dport <port>  # Zielport
-sport <port>  # Quellport
-m <modul> <modulparameter> # Modul laden und benutzen
-j <target>    # Ziel der Regel (ACCEPT, DROP, REJECT ...)

• Targets definieren die Aktion einer Firewall-Regel

-j RETURN # back to calling chain
-j LOG # syslog
-j REJECT [--reject-with <icmp-error-type>]
-j SNAT --to-source <addr>[-addr][:port-port] # nur in Chain POSTROUTING, Table "nat"
-j DNAT --to-destination <addr>[-addr][:port-port] # nur den Chains PREROUTING und OUTPUT, Table "nat"
-j REDIRECT --to-ports port[-port]
-j MASQUERADE --to-ports port[-port]
-j chain-name

--syn # Verbindungsaufbau
--tcp-flags <mask> <active> # Flags: SYN,ACK,FIN,RST,URG,PSH,ALL,NONE
# Beispiel für TCP Protokoll-Flags
--tcp-flags SYN,RST,ACK SYN

--icmp-type <icmp-type>
iptables -p icmp -h  # lists icmp types

• Das iptables Modul state erlaubt es, IP Verbindungen anhand des Verbindungsstatus zu filtern
  • NEW - neue Verbindungen
  • ESTABLISHED - gültige, aktive Verbindung
  • RELATED - bei UDP Kommunikation - zugehörige Verbindungen, z.B. Antworten auf Anfragen
  • INVALID - Pakete ausserhalb einer gültigen Verbindung

-m state --state <state1[,state2,...]>

• Das Modul recent erlaubt es Pakete über einen Zeitraum miteinander in Verbindung zu setzen
• Beispiel: nur 3 SSH Anmeldeversuche per 15 Minuten zulassen

iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 900 --hitcount 3 -j DROP

• Das Linux-Firewall System schreibt Log-Informationen in den Kernel-Log (die Firewall ist Bestandteil des Kernels)

-j LOG --log-level <num>
-j LOG --log-prefix <prefix> # 14 chars
-j LOG --log-tcp-options
-j LOG --log-ip-options

• Masquerading ist eine Form des NAT, bei dem die Quell-IP-Adresse aller ausgehenden Pakete durch die Adresse des ausgehenden Netzwerkinterfaces des Firewall-Systems ersetzt wird

// masquerading auf dem Router anschalten, server und client kommen nun ins Internet
iptables -A POSTROUTING -t nat -o enp0s3 -j MASQUERADE
iptables -L -t nat

• Zu Beginn eines iptables Firewall-Skriptes werden gewisse Grundeinstellungen vorgenommen. Dieses Skript-Fragment kann als Start-Vorlage für ein neues Firewall-Skript benutzt werden

#!/bin/sh

# default policy
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# bestehene Regeln löschen (Firewall Reset)
iptables -F
iptables -F -t nat

# Loopback Interface erlauben
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

• Dieses kleine Skript stellt den Ursprungszustand der Linux-Firewall wieder her (alles ist erlaubt). Die Default-Policy wird auf "ACCEPT" (erlauben) gesetzt und die Inhalte die Filter- und NAT-Tabellen der Chains gelöscht.

#!/bin/sh

iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT
iptables -P FORWARD ACCEPT

# bestehene Regeln löschen (Firewall Reset)
iptables -F
iptables -F -t nat

• Dieses "Sicherheitsnetz"-Skript startet ein neues Firewall-Regelwerk ./firewall.sh. Vorher wird im Hintergrund das Firewall-Stopp-Skript gestartet, welches die Firewall nach 60 Sekunden wieder auf den ausgangszustand zurücksetzt:

(sleep 60 && ./firewall-stopp.sh) & ./firewall.sh

• Mit dieser Befehlsfolge kann ein neues Firewall-Regelwerk getestet werden

• Diese Tests sollen funktionieren
  • SSH von der virtuellen Maschine zum Router (192.168.1.1)
  • "ping" vom Router in das Internet (z.B. 8.8.8.8)
  • "ping" von der virtuellen Maschine zum Router
• dieser Test sollten nicht funktionieren
  • DNS Anfrage von der virtuellen Maschine zum Router (auf dem Router läuft ein BIND 9 DNS Server) dig @<ip-des-routers> chaos txt authors.bind. Diese Anfrage sollte ein Timeout ergeben, das Paket an Port 53 der Firewall sollte verworfen werden (im Journal nachschauen)

• Der Router läuft in einem Linux-Container. Linux-Container haben keinen Zugriff auf die Kernel-Logs
  • IPTables Logs werden in das Kernel-Log geschrieben und sind im Container nicht sichtbar
• Lösung:
  • Das Paket ulogd2 installieren und starten

    router% apt install ulogd2
    router% systemctl start ulogd
    

  • IPTables Log-Regeln müssen nun nach NFLOG (NetFilter Log) anstatt LOG schreiben:

    # Pakete verwerfen und ins Syslog schreiben
    iptables -A INPUT -j NFLOG --nflog-prefix "FW Drop:"
    iptables -A INPUT -j DROP
    

  • Die Log-Datei befindet sich unter /var/log/ulog/syslogemu.log

    # tail -f /var/log/ulog/syslogemu.log
    Jun 20 13:11:51 router-012 FW Drop: IN=router3-eth0 OUT= MAC=7a:1c:aa:f4:78:f8:b2:8c:51:a2:42:58:08:00 SRC=192.168.1.2 DST=192.168.1.1 LEN=81 TOS=00 PREC=0x00 TTL=64 ID=27464 PROTO=UDP SPT=53048 DPT=53 LEN=61 MARK=0
    Jun 20 13:11:56 router-012 FW Drop: IN=router3-eth0 OUT= MAC=7a:1c:aa:f4:78:f8:b2:8c:51:a2:42:58:08:00 SRC=192.168.1.2 DST=192.168.1.1 LEN=81 TOS=00 PREC=0x00 TTL=64 ID=27545 PROTO=UDP SPT=53048 DPT=53 LEN=61 MARK=0
    Jun 20 13:12:01 router-012 FW Drop: IN=router3-eth0 OUT= MAC=7a:1c:aa:f4:78:f8:b2:8c:51:a2:42:58:08:00 SRC=192.168.1.2 DST=192.168.1.1 LEN=81 TOS=00 PREC=0x00 TTL=64 ID=28587 PROTO=UDP SPT=53048 DPT=53 LEN=61 MARK=0
    

#!/bin/sh

# default policy
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# bestehene Regeln löschen (Firewall Reset)
iptables -F
iptables -F -t nat

# Loopback Interface erlauben
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# bestehende eingehende Verbindungen aus dem Internet erlauben
iptables -A INPUT  -i router3-eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# bestehende eingehende Verbindungen aus dem Client/Server-Netz erlauben
iptables -A INPUT  -i router1-eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i router2-eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# bestehende ausgehende Verbindungen erlauben
iptables -A OUTPUT  -m state --state RELATED,ESTABLISHED -j ACCEPT

# neue ausgehende Verbindungen erlauben
iptables -A OUTPUT  -m state --state NEW -j ACCEPT

# NATPT fuer ausgehende Verbindungen
iptables -A POSTROUTING -t nat -o router3-eth0 -j MASQUERADE

# SSH eingehend erlauben
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# icmp eingehend erlauben
iptables -A INPUT -p icmp -j ACCEPT

# Pakete verwerfen und ins Syslog schreiben
iptables -A INPUT -j LOG --log-prefix "FW Drop:"
iptables -A INPUT -j DROP

• aktives (Filter-Tabelle-) Regelwerk mit Regel-Nummern, Zählern und Interface-Abhängigkeiten anzeigen

iptables -L -v -n --line-numbers

[...]
# DNS eingehend erlauben
iptables -A INPUT -i router3-eth0 -p tcp --dport 53 -m state --state NEW -j ACCEPT
iptables -A INPUT -i router3-eth0 -p udp --dport 53 -m state --state NEW -j ACCEPT
[...]

• Empfehlungen für ICMPv4 Filter in Firewalls "Recommendations for filtering ICMP messages" https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering Dieses Dokument erklärt die verschiedenen ICMPv4 Meldungen, und ob diese in einer Gateway/Router-Firewall oder Host-Firewall geblockt werden können/sollten. Das Dokument gibt Empfehlungen welche ICMPv4 Meldungen per Rate-Limit in der Menge kontrolliert werden sollten.

• Firewall-Regeln für ICMPv6 werden in RFC 4890: "Recommendations for Filtering ICMPv6 Messages in Firewalls" beschrieben https://datatracker.ietf.org/doc/html/rfc4890
• Unbedingt benötigte ICMPv6 Kommunikation
  • Destination Unreachable (Type 1) - All codes
  • Packet Too Big (Type 2)
  • Time Exceeded (Type 3) - Code 0 only
  • Parameter Problem (Type 4) - Codes 1 and 2 only
  • Echo request / Echo reply (needed for Teredo)
• oft benötigte ICMPv6 Meldungen
  • Time Exceeded (Type 3) - Code 1
  • Parameter Problem (Type 4) - Code 0
  • Mobile IPv6 (nur wenn eingesetzt)
    • Home Agent Address Discovery Request (Type 144)
    • Home Agent Address Discovery Reply (Type 145)
    • Mobile Prefix Solicitation (Type 146)
    • Mobile Prefix Advertisement (Type 147)
• selektiv Filtern (nur erlauben wenn diese Funktionen benutzt werden)
  • Node Information Query (Type 139)
  • Node Information Response (Type 140)
  • Router Renumbering (Type 138)
  • ICMPv6 mit experimentellen Nachrichten-Typen (100, 101, 200, and 201)
  • Erweiterungs-Nachrichten-Typen (Types 127 and 255)
• alles andere Blocken, insbesondere
  • Seamoby Experimental (Type 150)
  • Unallocated Error messages (Types 5-99 inclusive and 102-126 inclusive)
  • Unallocated Informational messages (Types 154-199 inclusive and 202-254 inclusive)
• Liste der ip6tables ICMPv6 Codes

ip6tables -p ipv6-icmp -h

• Auf dem Server OpenSSH Server installieren und den SSH Dienst starten

server% apt install openssh-server
server% systemctl start sshd

• Auf dem Server einen Benutzer nutzer anlegen (adduser nutzer)
• Auf dem Server für den Benutzer nutzer ein Passwort vergeben (passwd nutzer)
• SSH vom Client zum Server testen

client# apt install openssh-client
client# ssh nutzer@100.64.1.2

• HTTP vom Client zum Server testen
  • auf dem Server ist ein NGINX Webserver mit der Default Willkommensseite installiert und gestartet
• auf dem Client einen Text-Modus Browser starten
  • die Dateien im Heimverzeichnis des Benutzers "root" auf dem Server sollten angezeigt werden (wenn keine Datei "index.html" vorliegt)

client# links 100.64.1.2

• DNS vom Server ins Internet testen

server# apt install dnsutils
server# dig @1.1.1.1 kernel.org a

• HTTP/HTTPS vom Client ins Internet testen

client% echo "nameserver 1.1.1.1" > /etc/resolv.conf
client% links kernel.org
client% links https://notes.defaultroutes.de

• Auf dem Client "nmap" installieren und von dort den Router und den Server notes.defaultroutes.de (im Internet) scannen (was lässt die Firewall von innen nach aussen durch)

client% apt install nmap
client% nmap -sT 172.16.1.2
client% nmap -sT 100.64.1.1
client% nmap -sT 100.64.1.2
client% nmap -sT notes.defaultroutes.de

• Bei einem Scan vom Server/Client oder von der Firewall in das Internet dürfen nur die Ports 53, 80 und 443 als offen angezeigt werden. Rechner in den Client und Server Netzen dürfen nur über diese Ports mit der Aussenwelt kommunizieren. Ein SSH vom Server ins Internet darf nicht möglich sein.

#!/bin/sh

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# bestehene Regeln löschen (Firewall Reset)
iptables -F
iptables -F -t nat

# Loopback Interface erlauben
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# bestehende ausgehende/geroutete Verbindungen erlauben
iptables -A OUTPUT  -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# bestehende eingehende Verbindungen erlauben
iptables -A INPUT  -m state --state RELATED,ESTABLISHED -j ACCEPT

# NATPT fuer ausgehende Verbindungen
iptables -A POSTROUTING -t nat -o router3-eth0 -j MASQUERADE

# SSH eingehend zur Firewall/Router erlauben
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# SSH vom Router zum Server-Netz erlauben
iptables -A OUTPUT -o router2-eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT

# SSH vom Router zum Client-Netz erlauben
iptables -A OUTPUT -o router1-eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT

# SSH vom Client-Netz zum Server-Netz/Internet erlauben
iptables -A FORWARD -i router1-eth0 -p tcp --dport 22 -m state --state NEW -j ACCEPT

# HTTP vom Client zum Server erlauben
iptables -A FORWARD -s 172.16.1.2 -d 100.64.1.2 -p tcp --dport 80 -m state --state NEW -j ACCEPT

# DNS ausgehend zulassen
iptables -A OUTPUT -o router3-eth0 -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -o router3-eth0 -m state --state NEW -p tcp --dport 53 -j ACCEPT

# DNS vom Client/Server zulassen
iptables -A FORWARD -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp --dport 53 -m state --state NEW -j ACCEPT

# HTTP/HTTPS vom Router/Client/Server zulassen
iptables -A FORWARD -o router3-eth0 -m state --state new -p tcp --dport 80  -j ACCEPT
iptables -A FORWARD -o router3-eth0 -m state --state new -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT  -o router3-eth0 -m state --state new -p tcp --dport 80  -j ACCEPT
iptables -A OUTPUT  -o router3-eth0 -m state --state new -p tcp --dport 443 -j ACCEPT

# icmp erlauben
iptables -A INPUT -p icmp -j ACCEPT

# Pakete verwerfen
iptables -A INPUT   -j NFLOG --nflog-prefix "FW INP Drop:"
iptables -A FORWARD -j NFLOG --nflog-prefix "FW FRW Drop:"
iptables -A OUTPUT  -j NFLOG --nflog-prefix "FW OUT Drop:"
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
iptables -A OUTPUT -j DROP

• Alternative, wenn das Ziel eine Anwendung auf der Firewall-Maschine ist (z.B. für einen "stealth" reverse Proxy)

iptables -A PREROUTING -t nat -i router3-eth0 -p tcp --dport 80 \
    -j REDIRECT --to-port 3128

flush ruleset

# Variable "any" definieren
define any = 0::0/0

table inet filter {
   chain forward {
     type filter hook forward priority 0;
     policy drop;

     # Bestehende Verbindungen erlauben
     ct state established, related accept
     # SSH von Client zum Server
     oif router2-eth0 ip saddr 172.16.1.2 tcp dport 22 ct state new accept
     oif router2-eth0 ip6 saddr fd01::/64 tcp dport 22 ct state new accept
     # HTTP vom Client zum Server
     iif router1-eth0 oif router2-eth0 tcp dport 80 accept
     # DNS vom Client/Server in das Internet erlauben
     iif { router1-eth0, router2-eth0 } oif router3-eth0 tcp dport 53 accept
     iif { router1-eth0, router2-eth0 } oif router3-eth0 udp dport 53 accept
     # HTTP und HTTPS vom Client/Server in das Internet
     iif { router1-eth0, router2-eth0 } oif router3-eth0 tcp dport { 80, 443 } accept
     counter log prefix "nft forward drop: " group 0 drop
   }
   chain input {
        type filter hook input priority 0;

        # set default policy to "drop"
        policy drop;
        # accept any localhost traffic
        iif lo accept
        # accept traffic originated from us
        ct state established,related accept
        # Allow SSH towards the Firewall
        tcp dport 22 ct state new accept
        # Accept neighbour discovery otherwise IPv6 connectivity breaks.
        ip6 saddr $any icmpv6 type { nd-neighbor-solicit,
                                     nd-router-advert,
                                     nd-neighbor-advert }  accept
        # Accept essential icmpv6
        ip6 saddr $any icmpv6 type { echo-reply,
                                     echo-request,
                                     packet-too-big,
                                     destination-unreachable,
                                     time-exceeded,
                                     parameter-problem } accept
        # count and drop any other traffic
        counter log prefix "nftables drop: " group 0 drop
  }
  chain output {
        type filter hook output priority 0;
        policy drop;

        # Von der Firewall SSH zum Server erlauben
	oif router2-eth0 tcp dport ssh accept;

        ip6 daddr $any icmpv6 type { nd-neighbor-solicit,
                                     nd-router-advert,
                                     nd-neighbor-advert }  accept
        # Accept essential icmpv6
        ip6 daddr $any icmpv6 type { echo-reply,
                                     echo-request,
                                     packet-too-big,
                                     destination-unreachable,
                                     time-exceeded,
                                     parameter-problem } accept

        # count and drop any other traffic
        counter log prefix "nft output drop: " group 0 drop
  }
}
table ip nat {
        chain prerouting {
                type nat hook prerouting priority 0;
        }
        chain postrouting {
                type nat hook postrouting priority 0;
                oif router3-eth0 masquerade
        }
}

• eBPF Programme werden für eine virtuelle CPU Architektur übersetzt
• Der Programmcode wird in den Linux Kernel geladen und dort geprüft
• Auf einigen CPU Architekturen (amd64, AARCH64) wird der eBPF Bytecode in nativen Maschinencode re-compiliert (Just in Time Compiler = JIT)

• Der express data path (XDP) innerhalb des Linux-Kernels ist eine Infrastruktur, um auf unterster Ebene Kontrolle über Netzwerk-Pakete auszuüben
  • Der normale Datenfluss im Linux Netzwerk-Stack kann via XDP umgangen werden
  • eBPF Programme können in den eXpress Data Path (XDP) geladen werden

• XDP eBPF Programm können auf verschiedenen Ebenen in den Linux Kernel geladen werden
  • Offload XDP: direkt in die Netzwerk-Hardware (ASIC/FPGA, benötigt Unterstützung für XDP in der Hardware, z.B. vorhanden in den Netronome Netzwerkadaptern)
  • Native XDP: In den Linux Kernel Netzwerk-Treiber der Netzwerkschnittstelle (benötigt Unterstützung durch den Treiber)
  • Generic XDP: In den Linux Kernel Netzwerk-Stack (weniger Performance, aber ohne besondere Unterstützung von Hardware oder Treibern möglich)

• eBPF Programme können auf verschiedene Weise erstellt werden
  • Als Low level eBPF Assembler Code
  • Mit einem High Level Compiler (mit Hilfe von LLVM): C / GO / Rust / Lua / Python …
  • Spezialisierte eBPF Script-Sprachen: z.B. bpftrace

• BCC ist die BPF Compiler Sammlung
  • Website https://github.com/iovisor/bcc
  • BCC übersetzt C oder Python Quellcode in eBPF Programme und kann diese in den Linux Kernel laden

• Die Syscalls eines BIND 9 Prozesses auswerten mit dem Programm syscount

# syscount-bpfcc -p `pgrep named` -i 10
Tracing syscalls, printing top 10... Ctrl+C to quit.
[07:34:19]
SYSCALL                   COUNT
futex                       547
getpid                      121
sendto                      113
read                         56
write                        31
epoll_wait                   31
openat                       23
close                        20
epoll_ctl                    20
recvmsg                      20

• Die Linux Capabilities von laufenden Prozessen anzeigen

# capable-bpfcc | grep named
07:36:17  0      29378  (named)          24   CAP_SYS_RESOURCE     1
07:36:17  0      29378  (named)          24   CAP_SYS_RESOURCE     1
07:36:17  0      29378  (named)          12   CAP_NET_ADMIN        1
07:36:17  0      29378  (named)          21   CAP_SYS_ADMIN        1
07:36:17  0      29378  named            6    CAP_SETGID           1
07:36:17  0      29378  named            6    CAP_SETGID           1
07:36:17  0      29378  named            7    CAP_SETUID           1
07:36:17  109    29378  named            24   CAP_SYS_RESOURCE     1

• bpftrace ist eine kleine Skripting-Sprace ähnlich wie awk oder dtrace
  • Website https://bpftrace.org
• bpftrace Programme binden sich an eBPF-Probes und führen Funktionen aus, wann immer ein System-Ereignis gemeldet wird (systemcall, function-call)
• bpftrace hat Hilfs-Strukturen eingebaut um direkt mit eBPF Datanstrukturen arbeiten zu können
• bpftrace erlaubt es eBPF Programme im Vergleich zu BCC kompakter zu schreiben

• Es gibt hunderte kleine eBPF Programme welche es dem Benutzer erlauben tief in den Linux Netzwerk Stack zu schauen the Linux network stack
  • Die BCC Beispielprogramme
  • Die bpftrace Beispielprogramme
  • Die Programme aus dem eBPF Büchern und den dazugehörigen Webseiten

• Das BCC Programm gethostlatency misst die Latenz der client-seitigen DNS Namensauflösung durch Systemaufrufe wie getaddrinfo oder gethostbyname

# gethostlatency-bpfcc
TIME      PID    COMM                  LATms HOST
10:21:58  19183  ping                 143.22 example.org
10:22:18  19184  ssh                    0.03 host.example.de
10:22:18  19184  ssh                   60.59 host.example.de
10:22:35  19185  ping                  23.44 isc.org
10:22:49  19186  ping                4459.72 yahoo.co.kr

• netqtop - Gibt Statistiken über die Warteschlangen einer Netzwerkschnittstelle aus. Mit diesem Programm können Informationen bei der Überlastung einer Netzwerkschnittstelle gesammelt werden.

# netqtop-bpfcc -n eth0 -i 10
Mon Nov 15 07:43:29 2021
TX
 QueueID    avg_size   [0, 64)    [64, 512)  [512, 2K)  [2K, 16K)  [16K, 64K)
 0          297.82     2          48         1          4          0
 Total      297.82     2          48         1          4          0

RX
 QueueID    avg_size   [0, 64)    [64, 512)  [512, 2K)  [2K, 16K)  [16K, 64K)
 0          70.95      43         34         0          0          0
 Total      70.95      43         34         0          0          0
-----------------------------------------------------------------------------

• Dieses Programm zeig den Status von TCP Verbindungen im System (A = accept, C = connected, X = closed) sowie der Quell- und Ziel IP-Adressen und -Ports.

# tcptracer-bpfcc -p $(pgrep named)
Tracing TCP established connections. Ctrl-C to end.
T  PID    COMM             IP SADDR            DADDR            SPORT  DPORT
C  29404  isc-net-0000     4  127.0.0.1        127.0.0.1        41555  953
A  29378  isc-socket-0     4  127.0.0.1        127.0.0.1        953    41555
X  29404  isc-socket-0     4  127.0.0.1        127.0.0.1        41555  953
X  29378  isc-socket-0     4  127.0.0.1        127.0.0.1        953    41555
C  29378  isc-net-0000     4  46.101.109.138   192.33.4.12      43555  53
C  29378  isc-net-0000     4  46.101.109.138   192.33.4.12      33751  53
X  29378  isc-socket-0     4  46.101.109.138   192.33.4.12      43555  53
X  29378  isc-socket-0     4  46.101.109.138   192.33.4.12      33751  53
C  29378  isc-net-0000     4  46.101.109.138   193.0.14.129     38145  53
C  29378  isc-net-0000     4  46.101.109.138   192.33.14.30     40905  53
X  29378  isc-socket-0     4  46.101.109.138   193.0.14.129     38145  53
X  29378  isc-socket-0     4  46.101.109.138   192.33.14.30     40905  53

• tcpconnlat gibt die Latenz einer TCP-basierten Verbindung aus, hier eine ausgehende DNS Anfrage über TCP eines BIND 9 resolvers (in Beispiel eine Abfrage von microsoft.com txt, wobei die Antwort zu groß für ein 1232 Byte UDP Paket ist)
  • isc-net-0000 ist der interne Name des BIND 9 Threads

# tcpconnlat-bpfcc
PID    COMM         IP SADDR            DADDR            DPORT LAT(ms)
29378  isc-net-0000 4  46.101.109.138   193.0.14.129     53    37.50
29378  isc-net-0000 4  46.101.109.138   192.52.178.30    53    14.01
29378  isc-net-0000 4  46.101.109.138   199.9.14.201     53    8.48
29378  isc-net-0000 4  46.101.109.138   192.42.93.30     53    1.90
29378  isc-net-0000 4  46.101.109.138   40.90.4.205      53    14.27
29378  isc-net-0000 4  46.101.109.138   199.254.48.1     53    19.21
29378  isc-net-0000 4  46.101.109.138   192.48.79.30     53    7.66
29378  isc-net-0000 4  46.101.109.138   192.41.162.30    53    7.97
29396  isc-net-0000 4  127.0.0.1        127.0.0.1        53    0.06

• udplife ist ein bpftrace um die UDP Roundtrip-Time (hier DNS round trip time) einer UDP Kommunikation auszugeben (Programm von Brendan Gregg, siehe Links)

# udplife.bt
Attaching 8 probes...
PID   COMM       LADDR           LPORT RADDR           RPORT   TX_B   RX_B MS
29378 isc-net-00 46.101.109.138  0     199.19.57.1     16503     48    420 268
29378 isc-net-00 46.101.109.138  0     51.75.79.143    81        49     43 13
29378 isc-net-00 46.101.109.138  0     199.6.1.52      16452     48    408 24
29378 isc-net-00 46.101.109.138  0     199.249.120.1   81        44     10 9
29378 isc-net-00 46.101.109.138  0     199.254.31.1    32891     64     30 273
29378 isc-net-00 46.101.109.138  0     65.22.6.1       32891     64     46 266

• Eine master thesis von Tom Carpay (mit Unterstützung von NLnet Labs)
• eBPF Funktionen welche von Tom Carpay getestet wurden
  • Umschreiben von DNS Query-Names via eBPF
  • DNS Response-Rate Limiting im Linux Kernel unabhängig von DNS Server Produkt
• https://www.nlnetlabs.nl/downloads/publications/DNS-augmentation-with-eBPF.pdf

• Ein BIND 9 DNS Resolver mit einer Forward-Zone konfiguriert.

zone "dnslab.org" {
        type forward;
        forwarders { 1.1.1.1; 8.8.8.8; };
};

• Das BIND 9 Logging System ist sehr mächtig, hat jedoch keine Funktion um DNS Forwarding Entscheidungen zu loggen
• Ziel: Ein bpftrace Skript erstellen um BIND 9 DNS Forwarding-Entscheidungen auszugeben

• Der BIND 9 Quellcode ist auf dem ISC Github Server offen verfügbar und durchsuchbar: https://gitlab.isc.org
• Eine Suche im BIND 9 Quellcode nach forwarding findet die Funktion dns_fwdtable_find in /lib/dns/forward.c. Das schaut erfolgversprechend aus:

• Die Funktion dns_fwdtable_find nimmt als Eingangsparameter einen Domain-Namen und liefert den Wert 0 wenn der Namen via Forwarding aufgelöst werden muss, und einen Wert > 0 wenn Forwarding nicht verwendet wird
  • Ein bpftrace one-liner gibt uns die Information ob diese Funktion für diese Aufgabe benutzbar ist:

bpftrace -e 'uretprobe:/lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so:dns_fwdtable_find { print(retval) }'

• Nun da wir die Funktion für die Aufgabe gefunden und verifiziert haben können wir ein bpftrace Skript schreiben
• Das Skript wird
  • Den Domain Namen, welcher der Funktion dns_fwdtable_find übergeben wird, beim Eintritt in die Funktion speichern
  • Den Rückgabewert der Funktion (retval) auf den Wert Null (0) prüfen und den Domain Namen ausgeben wenn Forwarding benutzt wird

• Der Domain-Name welcher auf Forwarding geprüft werden soll wird der Funktion als Datenstruktur (struct) vom Typ dns_name_t übergeben
  • Es ist leider kein einfacher Zeiger auf eine Zeichenkette, welche wir ausdrucken können
• Eine Suche durch die Dokumentation des ISC BIND 9 Quellcodes findet die Datenstruktur dns_name_t. Das 2te Feld ist ein unsigned char * ndata, dies scheint der Domain-Name zu sein
• Die Definition des Datenstruktur dns_name_t befindet sich in der Datei lib/dns/include/dns/name.h
• bpftrace beutzt eine der Programmiersprache C ähnliche Syntax, daher können wir die Definition der Datenstruktur aus dem BIND 9 Quellcode direkt in das bpftrace Skript importieren
  • Die verkettete Liste und das Feld isc_buffer_t wird für unser Skript nicht benötigt und da diese Felder keine eingebauten Datentypen beschreiben kommentieren wir diese aus:

#!/usr/bin/bpftrace

struct dns_name {
        unsigned int   magic;
        unsigned char *ndata;
        unsigned int   length;
        unsigned int   labels;
        unsigned int   attributes;
        unsigned char *offsets;
//      isc_buffer_t  *buffer;
//      ISC_LINK(dns_name_t) link;
//      ISC_LIST(dns_rdataset_t) list;
};
[...]

• Die BEGIN Pseudo-Probe wird beim Start des Skriptes aktiv und gibt eine Nachricht auf das Terminal aus um dem Benutzer darüber zu informieren das das Skript erfolgreich gestartet wurde

[...]
BEGIN
{
  print("Waiting for forward decision...\n");
}
[...]

• Diese Probe wird aktiv wenn die Funktion im BIND 9 aufgerufen wird
  • Es ist eine uprobe (User-Space Entry-Probe)
  • Die Probe instrumentalisiert die Funktion dns_fwdtable_find in der dynamischen Bibliotheks-Datei /lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so
  • Das 2te Argument des Funktionsaufrufs (arg1) wird in ein struct dns_name gecastet und das Feld ndata referenziert
  • Der Inhalt des Feldes wird in der Variable @dns_name[tid] (indiziert mit der Thread ID (tid) des laufenden BIND 9 Threads im Prozess) gespeichert

[...]
uprobe:/lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so:dns_fwdtable_find
{
  @dns_name[tid] = ((struct dns_name *)arg1)->ndata
}
[...]

• Die 3te Probe wird beim Verlassen der Funktion aktiv (uretprobe - User-space Funktion Return Probe)
  • Gleiche Bibliotheks-Datei und Funktion wie zuvor
• Ist der Rückgabewert der Dunktion Null 0 (Domain Name muss über Forwarding aufgelöst werden) wird der Wert der Variable @dns_name[tid] in eine Zeichenkette gewandelt und ausgegeben
• Die Variable @dns_name[tid] wird nicht weiter benötigt und gelöscht

uretprobe:/lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so:dns_fwdtable_find
{
 if (retval == 0) {
    printf("Forwarded domain name: %s\n", str(@dns_name[tid]));
 }
 delete(@dns_name[tid]);
}

#!/usr/bin/bpftrace

struct dns_name {
        unsigned int   magic;
        unsigned char *ndata;
        unsigned int   length;
        unsigned int   labels;
        unsigned int   attributes;
        unsigned char *offsets;
//      isc_buffer_t  *buffer;
//      ISC_LINK(dns_name_t) link;
//      ISC_LIST(dns_rdataset_t) list;
};

BEGIN
{
  print("Waiting for forward decision...\n");
}
uprobe:/lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so:dns_fwdtable_find
{
  @dns_name[tid] = ((struct dns_name *)arg1)->ndata
}

uretprobe:/lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so:dns_fwdtable_find
{
 if (retval == 0) {
    printf("Forwarded domain name: %s\n", str(@dns_name[tid]));
 }
 delete(@dns_name[tid]);
}

• Immer wenn ein Domain-Namen im BIND 9 Resolver aufgelöst wird, wird auch das bpftrace Skript aktiv
  • In diesem Beispiel werden alle Anfragen an die Domain dnslab.org per Forwarding weitergeleitet, jedoch nicht die Anfragen an ietf.org

• Mittels eBPF können sehr effiziente Firewall-Systeme gebaut werden
  • eBPF kann Netzwerk-Verkehr stoppen, bevor dieser den Linux TCP/IP Stack oder die Anwendung erreicht
  • Da eBPF pro Netzwerk-Paket ein volles Programm ausführt können komplexe Filter definiert werden
    • Filter auf Basis von DNS Query Namen
    • DNSSEC Daten in der Antwort verfügbar?
    • Quell-IP des antwortenden autoritativen DNS Servers (blockieren bekannter "bösartiger" DNS Server)
    • EDNS data (DNS Pakete mit DNS Cookies bevorzugen)
    • …

• Dieses Beispiel zeigt einen simplen eBPF Netzwerk-Filter
  • Der Filter blockiert jeglichen UDP Verkehr an ein Interface (hier das Loopback-Interface) mit der Ausnahme von UDP DNS Paketen (Port 53)
  • Dies Hilft bei der Abwehr von non-DNS DDoS Angriffen gegen einen autoritativen DNS Resolver

• Installiere die BCC Tools und die Linux Kernel Header für den aktuell laufenden Kernel (wenn die Linux Kernel Header nicht gefunden werden, ist der laufende Kernel nicht mehr aktuell. In diesem Fall die virtuelle Maschine neu starten/reboot und danach die Linux Kernel Header installieren)

% apt install bpfcc-introspection  bpfcc-tools python3-bpfcc
% apt install linux-headers-$(uname -r)

• BIND 9 DNS Server installieren

  virtuelle maschine% apt install bind9
  

• Speichere den folgenden C Quellcode in die Datei drop-non-dns-udp.c. Dieses eBPF Programm wird
  • für jeden Netzwerkpaket ausgeführt
  • gibt den Text got a packet für jedes Paket aus
  • extrahiert die IP und UDP Header aus dem Netzwerkpaket
  • wenn weder der UDP Quell-Port noch der UDP Ziel-Port den Wert 53 beinhalten (DNS) wird der Return-Code XDP_DROP zurückgegeben und damit das Paket verworfen. Eine Nachricht informiert über das Verwerfen des Pakets
  • alle anderen Netzwerk-Pakete werden mit dem Rückgabewert XDP_PASS an den Linux TCP/IP Stack weitergeleitet
  • XDP Programme in Produktions-Qualität sollten statt der Funktion bpf_trace_printk die ePBF Map-Strukturen zum Informationsaustausch mit dem User-Space Programm benutzen

#define KBUILD_MODNAME "filter"
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/in.h>
#include <linux/udp.h>

int udpfilter(struct xdp_md *ctx) {
  bpf_trace_printk("got a packet\n");
  void *data = (void *)(long)ctx->data;
  void *data_end = (void *)(long)ctx->data_end;
  struct ethhdr *eth = data;
  if ((void*)eth + sizeof(*eth) <= data_end) {
    struct iphdr *ip = data + sizeof(*eth);
    if ((void*)ip + sizeof(*ip) <= data_end) {
      if (ip->protocol == IPPROTO_UDP) {
        struct udphdr *udp = (void*)ip + sizeof(*ip);
        if ((void*)udp + sizeof(*udp) <= data_end) {
          if ((udp->dest != ntohs(53)) && (udp->source != ntohs(53))) {
            if (udp->dest != udp->source) {
              bpf_trace_printk("drop udp src/dest port %d/%d\n", ntohs(udp->source), ntohs(udp->dest));
              return XDP_DROP;
            }
          }
        }
      }
    }
  }
  return XDP_PASS;
}

• Speichere das eBPF Ladeprogramm (geschrieben in Python) in die Datei drop-non-dns-udp.py.
  • Dieses Ladeprogramm compiliert das obige ePBF Programm, lädt dieses in den Linux-Kernel und verbindet es mit der Loopback Netzwerk-Schnittstelle (lo)
  • Während des Übersetzen des C-Quellcodes in eBPF werden Warnungen welche wir für dieses Beispiel ignorieren können
  • Der virtio Netzwerk-Treiber auf den virtuellen Lab-Maschinen erlaubt keine eBPF Programme auf den Netzwerk-Schnittstellen eth0 und eth1, daher testen wir mit der Loopback lo Schnittstelle

#!/usr/bin/env python3

from bcc import BPF
import time

device = "lo"
b = BPF(src_file="drop-non-dns-udp.c")
fn = b.load_func("udpfilter", BPF.XDP)
b.attach_xdp(device, fn, 0)

try:
  b.trace_print()
except KeyboardInterrupt:
  pass

b.remove_xdp(device, 0)

• Das Ladeprogramm ausführbar machen

% chmod +x drop-non-dns-udp.py

• Das Python Lade-Programm ausführen (die Warnungen können bei diesem Beispiel ignoriert werden)

% ./drop-non-dns-udp.py

• Verbinde Dich mit der Lab-Maschine mit einer neuen Sitzung (via tmux oder mit einem weiteren Login)
• Starte DNS Anfragen an den BIND 9 DNS Server über die Loopback Schnittstelle. Diese Anfragen sollten nicht geblockt werden.

% dig @localhost isc.org

• Senden wir UDP Pakete (DNS oder andere Protokolle) an einen Port ungleich 53 so werden diese Pakete noch vor dem Linux TCP/IP Stack verworfen

% dig -p 5353 @localhost isc.org

• Die XDP Firewall ist ein neues Projekt welches mittels XDP und eBPF eine generische Firewall erzeugt
  • Source-Code https://github.com/gamemann/XDP-Firewall
  • Eine Beispiel-Regel um DNS Pakete auf Port 53 zu blocken

interface = "eth0";
updatetime = 15;

filters = (
    {
        enabled = true,
        action = 0,
        udp_enabled = true,
        udp_dport = 53
    }
);

Von David Calavera, Lorenzo Fontana (November 2019)

Von Brendan Gregg (Dezember 2020)

Von Brendan Gregg (Dezember 2019)

• https://medium.com/@nicklaus_park/levelup-0x02-bug-bounter-hunter-methodology-v3-8f5b802af2ad
• https://danielmiessler.com/study/amass/
• https://github.com/OWASP/Amass/blob/master/doc/tutorial.md
• https://github.com/OWASP/Amass
• https://www.shellinthecity.com/bug-bounty-hunter-methodology/
• https://foremandrafts.github.io/posts/2019-3-30-hackerrecon

wget https://github.com/OWASP/Amass/releases/download/v3.13.4/amass_linux_amd64.zip
unzip amass_linux_amd64.zip
cd ~/amass_linux_amd64
sudo cp amass /usr/local/bin

• Scan von Domain-Namen

amass enum -ip -d example.com,example.de -active -brute  -src

• AMASS Ergebnisse mit NMAP prüfen

amass enum -d example.com,example.de | tee ./example.domains
nmap -iL example.domains -sL -sn -oN - --dns-servers 172.22.1.1 | grep -v "Failed" | grep -v "Other addresses" | cut -d ' ' -f 5 | tee example_activehosts_ipv4.txt
nmap -6 -iL example.domains -sL -sn -oN - --dns-servers 172.22.1.1 | grep -v "Failed" | grep -v "Other addresses" | cut -d ' ' -f 5 | tee example_activehosts_ipv6.txt
sudo nmap -O -v -sV -sC -p80,8080,443,8443,8181 -Pn -iL example_activehosts_ipv4.txt
sudo nmap -6 -O -v -sV -sC -p80,8080,443,8443,8181 -Pn -iL example_activehosts_ipv6.txt

• es gibt mehrere Wege, ein Schlüsselpaar (ED25519) für einen Onion-Service zu erstellen

• alternativ kann ein Schlüsselpaar mit OpenSSL erstellt werden
• zuerst der private Schlüssel

openssl genpkey -algorithm x25519 -out key.private.pem
cat key.private.pem | grep -v " PRIVATE KEY" | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > private.key

• und dann der öffentliche Schlüssel

openssl pkey -in key.private.pem -pubout | grep -v " PUBLIC KEY" | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > public.key

• auf der Seite des Tor-Onion-Dienstes, im Unterverzeichnis authorized_clients des Dienstes eine Datei mit der Endung .auth anlegen. In unserem Beispiel wir die Datei /var/lib/tor/hidden_service/authorized_clients/nutzer.auth angelegt

cd /var/lib/tor/hidden_service/authorized_clients/
$EDITOR nutzer.auth

• diese Datei enthält des öffentlichen Schlüssel des Clients im Format descriptor:x25519:<public-key>
• den Tor-Dienst neu starten

systemctl restart tor

• Nun kann nur noch ein Client, welcher den entsprechenden privaten Schlüssel zu den öffentlichen Schlüsseln des Dienstes hat, auf den Dienst zugreifen. Alle anderen Clients können nicht sehen, ob der Dienst existiert.

• auf dem Tor-Client ein Verzeichnis für die Client-Schlüssel anlegen (hier /var/lib/tor/auth) und die Rechte für die Tor-Software setzen

mkdir /var/lib/tor/auth
chmod 700 /var/lib/tor/auth
chown toranon /var/lib/tor/auth/

• in diesem Verzeichnis eine Text-Datei mit der Endung .auth_private anlegen. In diese Datei den privaten Schlüsseln für jeden Tor-Dienst eintragen (je eine Zeile pro Dienst). Jeder Eintrag hat das Format <onion-address>:descriptor:x25519:<base32-encoded-private-key>

$EDITOR /var/lib/tor/auth/nutzer.auth_private

• das Verzeichnis mit den Authentisierungs-Datei(en) auf dem Client in die Konfiguration der Tor-Software eintragen. Datei /etc/tor/torrc:

ClientOnionAuthDir /var/lib/tor/auth

• keine Änderungen an der (Heim-)Firewall notwendig. Keine Port-Forwardings etc.
• kein DynDNS notwendig, um eine wechselne IP-Adresse mit einen Namen zu verbinden. Der Onion-Name wird immer im Tor-Netz gefunden
• Datenverkehr ist verschlüsselt (Curve25519)
• Datenverkehr ist anonymisiert

• Client muss die Tor-Software als Proxy benutzen
• hohe Latenz (Verzögerung) bei den Paketlaufzeiten