Netzwerksicherheit Linuxhotel Dezember 2019 (Debian)

• emacs
• vi (vim)
• mg (Micro Emacs)
• jove
• nano
• joe
• weitere Editoren können/dürfen nachinstalliert werden

• Zeit: 15 Minuten
• Server und Client VM sind nicht direkt vom Laptop erreichbar
• auf dem Router läuft kein DHCP-Server, d.h. Server and Client bekommen keine IPv4-Adresse per DHCP
• wir haben auf dem Router IPv6 Router-Advertisements angeschaltet, der Router "ruft" nun in das Nettzwerk-Segment des Servers und des Clients die jeweilige IPv6-Netzwerk-Adresse
• IPv6-fähige Betriebssysteme konfiguieren automatisch eine IPv6 Adresse aus diesen Adressbereichen (SLAAC Stateless Address Auto-Configuration)
• von einer MAC-Adresse zu einer IPv6 Adresse: wie aus der Ethernet-MAC-Adresse unter IPv6 mit SLAAC eine IPv6-Adresse entsteht

08:00:27:ff:e8:ae

• von 48bit auf 64bit erweitern per "FFFE"

08:00:27:FF:FE:ff:e8:ae

• Bit 7 invertieren

0A:00:27:FF:FE:ff:e8:ae

• Link-Lokaler IPv6 Prefix anfügen und als IPv6 Adresse schreiben

fe80::a27:ff:feff:e8ae

• vollständige IPv6 Adresse

fe80:0000:0000:0000:0a27:00ff:feff:e8ae

• MAC Adresse des Client: 08:00:00:00:0C:XX
• MAC Adresse des Servers: 08:00:00:00:0F:XX

• Zeit: 5 Minuten
• Geht ein 'ping' vom Server zum Client?
• Antwort: ohne IP-Forwarding - nein
• Forwarding anschalten (in der Quagga Shell auf dem Router)

vtysh
router0x# conf terminal
router0x(config)# ip forwarding
router0x(config)# ipv6 forwarding
router0x(config)# exit
route0x# write

• ping vom Client zum Server testen, sollte nun funktionieren

• Zeit: 10 Minuten
• Geht ein 'ping' von Router ins Internet (1.0.0.1)? (auf dem Router ausführen)

ping 1.1

• geht ein 'ping' vom Server oder Client ins Internet (1.0.0.1)? (auf dem Server oder dem Client ausführen)

ping 1.1

• Lösung: iptables Masquerading NAT (auch Cone-NAT oder NATPT/NAT-Port-Translation oder NAT44/NAT-IPv4-zu-IPv4 genannt)
• auf dem Router in einer BASH-Shell (nicht im Quagga)

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

• nach dem Eintragen des NAT nochmals Testen, ob ein 'ping' vom Client und Server in das Internet funktioniert

• BIND 9 auf dem Router installieren, um eine Server Anwendung auf dem Router zu haben

apt install bind9 dnsutils
systemctl start bind9

• Erstelle eine Host-Firewall-Regeln für den Router
  • ausgehend alle Verbindungen erlauben
  • eingehend auf enp0s3, enp0s8 und enp0s9 nur SSH (Port 22) und ICMPv4 erlauben
  • Verworfene Pakete in das syslog (Journal) schreiben
  • wer möchte kopiert seine Lösung in das Etherpad https://pad.linuxhotel.de/p/Firewall&Netzwerksecurity_20191209
• Log-Ausgaben anschauen

journalctl -e  # an das Ende des Journal-Log springen
journalctl -f  # an das Ende des Journals springen und neue Einträge sofort anzeigen (wie tail -f)

• Zeitzone anpassen

timedatectl set-timezone Europe/Berlin

• Programm ntpdate installieren

apt install ntpdate

• Uhrzeit und Datum via NTP setzen

ntpdate pool.ntp.org

• Zeit: 10 Minuten
• Erweitere die Firewall, so das DNS-Anfragen (Port 53 UDP und TCP) vom Laptop zum Router möglich sind
• Firewall-Regeln neu laden und dann die Firewall testen (UDP und TCP Transport, vom Laptop aus)

apt install dnsutils
dig @<ip-des-routers> txt chaos authors.bind
dig +tcp @<ip-des-routers> txt chaos version.bind

• Test der Firewall vom Laptop aus (d.h. diese Befehle direkt auf dem Laptop ausführen)

apt install nmap
nmap -sT -v -A 192.168.1.yyy # <ip-der-firewall>

• Route für das Client-Segment dem Laptop hinzufügen, dann ein Scan des Client-Netzes hinter der Firewall

ip route add 172.16.x.0/24 via <ip-des-Firewall-Routers>
nmap -sT -v -A 172.16.x.0/24 # <ip-netz-hinter-der-firewall>

• iptables Regeln im Linux-Kernel können mit dem Befehl iptables-save in eine (Text-)Datei gesichert werden. Die Regeln aus einer Sicherungs-Datei können über den Befehl iptables-restore wieder hergestellt werden

router0x$ iptables-save > /etc/iptables.rules

• Datei /usr/local/sbin/iptables-flush

#!/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

• Datei ausführbar machen

chmod +x /usr/local/sbin/iptables-flush

• Datei /etc/systemd/system/iptables.service

[Unit]
Description=IPTables Packet Filtering Framework
DefaultDependencies=no
After=systemd-sysctl.service
Before=sysinit.target
[Service]
Type=oneshot
ExecStart=/sbin/iptables-restore /etc/iptables.rules
ExecReload=/sbin/iptables-restore /etc/iptables.rules
ExecStop=/usr/local/sbin/iptables-flush
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

• Systemd-Unit-Dateien neu laden

systemctl daemon-reload

• iptables Unit ausprobieren

systemctl start iptables
iptables -L
systemctl stop iptables
iptables -L

• Firewall beim Neustart anschalten

systemctl enable iptables

• Firewall-Regeln aus dem Speicher sichern. Hiermit werden manuelle Änderungen an den Firewall-Regeln permanent gespeichert. Dies ist optional und nicht in allen Fällen erwünscht!
• Datei /usr/local/sbin/iptables-flush

#!/bin/sh
# Firewall-Regeln sichern
iptables-save > /etc/iptables.rules

# Default-Policy öffnen
iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT
iptables -P FORWARD ACCEPT

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

• Zeit: 15 Minuten
• Neue Verbindungen auf allen Netzwerkschnittstellen des Routers erlauben

# bestehende eingehende Verbindungen aus dem Internet erlauben
iptables -A INPUT  -i enp0s3 -m state --state RELATED,ESTABLISHED -j ACCEPT

• ersetzen durch

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

• Erstelle Regeln, welche dem Client erlauben, per DNS Port 53 (UDP/TCP) auf den DNS-Resolver im Linuxhotel (192.168.1.5) zuzugreifen

[...]
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 172.16.x.0/24 -d 192.168.1.5 -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -s 172.16.x.0/24 -d 192.168.1.5 -p tcp --dport 53 -j ACCEPT
[...]

• DNS-Resolver in der /etc/resolv.conf auf der Client VM eintragen

client0x$ echo "nameserver 192.168.1.5" > /etc/resolv.conf

• Test der Namensauflösung (Name des DNS-Servers auf der IP-Adresse 1.1.1.1)

ping one.one.one.one

• eine Regel in der Chain FORWARD für icmp (IPv4) hinzufügen, damit der ping auch das Internet erreicht

iptables -A FORWARD -m state --state ESTABISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -s 172.16.x.0/24 -p icmp -j ACCEPT
iptables -A FORWARD -m state --state NEW -d 172.16.x.0/24 -p icmp -j ACCEPT

• Zeit: 10 Minuten
• erweitere die Firewallregeln um neue Regeln in der FORWARD chain, so das direkte SSH-Verbindungen vom Laptop zur Client-VM und zur Server-VM möglich sind.

• Zeit: 15 Minuten
• welche weiteren Regeln müssen in der Firewall eingetragen werden, um Paketinstallationen auf dem Client per apt install zu erlauben?
• erstelle die Regeln und teste die Pakete dnsutils und links zu installieren (ein Text-Webbrowser) (apt install links dnsutils)
• Testen, ob die DNS-Namensauflösung von der Client (VM) über den DNS-Resolver im Linuxhotel-Netzwerk funktioniert
• SSH vom Router zum Server

ssh nutzer@172.16.x.2

• DNS Abfrage testen

client0x$ dig @192.168.1.5 linuxhotel.de A
; <<>> DiG 9.9.6-P1 <<>> @192.168.1.5 linuxhotel.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12224
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;linuxhotel.de.                 IN      A

;; ANSWER SECTION:
linuxhotel.de.          3599    IN      A       217.69.87.63

;; Query time: 47 msec
;; SERVER: 192.168.1.5#53(192.168.1.17)
;; WHEN: Tue Jan 19 04:38:16 CET 2016
;; MSG SIZE  rcvd: 58

router0x$ apt install iftop
router0x$ iftop -i enp0s3

• Taste p schaltet die Anzeige der UDP/TCP Ports an
• Taste n schaltet DNS-Rückwärtsauflösung für IP-Adressen aus

• Zeit: 30 Minuten
• Erstelle erweiterte Regeln für das Routing des Router
  • SSH von Client/Firewall zum Server erlauben
  • HTTP (Port 80) vom Client zum Server erlauben
  • DNS von Client und vom Server ins Internet erlauben
  • HTTP(s) (80/443) vom Client/Server ins Internet zulassen (für Software Updates)
  • Masquerading NAT für Verbindungen ins 'Internet'
  • vom Router DHCP ins Linuxhotel-Netz erlauben (Port 67/68 UDP)
  • keine anderen ausgehenden Verbindungen erlauben

• Emacs ORG-Mode http://orgmode.org/
• Emacs ORG-Mode Babel http://orgmode.org/worg/org-contrib/babel/intro.html
• weitere Inspiration zum Thema: Kristof Provost (FreeBSD Projekt): Automated Firewall Testing, Video FosDEM 2019 https://papers.freebsd.org/2019/fosdem/provost-automated_firewall_testing/
• emacs und ruby installieren

apt install emacs-nox ruby

• Org-Babel-Dokument (, am Anfang der Zeilen entfernen, sind notwendig um Org-Mode innerhalb von einem Org-Mode Dokument einzubetten)

#+Title: Firewall-Dokumentation
#+Language: de

* Babel anschalten                                                 :noexport:
#+BEGIN_EXAMPLE                                                                                          
(org-babel-do-load-languages 'org-babel-load-languages                                                   
  '((ruby . t)                                                                                           
))                                                                                                       
#+END_EXAMPLE                                                                                            

#+BEGIN_SRC ruby :exports results
require 'time'
"Dieser Firewalltest wurde am #{Time.now}
 auf Rechner #{`hostname`} erstellt"
#+END_SRC

#+RESULTS:
: Dieser Firewalltest wurde am 2016-11-30 09:10:09 +0100
:  auf Rechner csmobile4.home.strotmann.de
:  erstellt

* Firewall Regeln

Dies sind unsere aktuellen Firewall Regeln

** INPUT Chain

*** Filter Tabelle

#+BEGIN_SRC ruby :exports results
`sudo iptables -L INPUT -t filter -v -n --line-numbers`
#+END_SRC

#+RESULTS:
#+begin_example
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
2        0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
3        0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
4        0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
5    63268   28M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
6      591 41163 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
7     2655  631K INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0
8     2655  631K INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
9     2655  631K INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
10       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
11     516 84169 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
#+end_example

* Firewall Tests

 * Können wir das Internet über Port 80 erreichen?

#+BEGIN_SRC ruby :exports both
`nmap -sT linuxhotel.de -p 80`
#+END_SRC

#+RESULTS:
:
: Starting Nmap 7.12 ( https://nmap.org ) at 2016-11-30 09:16 CET
: Nmap scan report for linuxhotel.de (217.69.87.63)
: Host is up (0.030s latency).
: rDNS record for 217.69.87.63: namebased-hostings.villa-vogelsang.de
: PORT   STATE SERVICE
: 80/tcp open  http
:
: Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds

• Firewall-Regeln für ICMPv6 werden in RFC 4820: "Recommendations for Filtering ICMPv6 Messages in Firewalls" beschrieben
• 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

#!/bin/sh

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

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

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

# Pakete mit RH0 (Routing Header 0, Source Routing) blocken
ip6tables -A INPUT -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A OUTPUT -m rt --rt-type 0 -j DROP

# bestehende eingehende Verbindungen aus dem Internet erlauben
ip6tables -A INPUT  -i enp0s3 -m state --state RELATED,ESTABLISHED -j ACCEPT

# bestehende eingehende Verbindungen aus dem Client-Netz erlauben
ip6tables -A INPUT  -i enp0s8 -m state --state RELATED,ESTABLISHED -j ACCEPT

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

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

# Link-Lokaler Multicast eingehend erlauben
ip6tables -A INPUT -s ff02::/16 -j ACCEPT

# Link-Lokale Kommunikation im Subnet erlauben
ip6tables -A INPUT -s fe80::/10 -j ACCEPT

# ICMPv6
ip6tables -A INPUT -p icmpv6 --icmpv6-type 1 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 2 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 3/0 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 4/1 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 4/2 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -m limit --limit 900/minute -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-reply   -m limit --limit 900/minute -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT
# ICMPv6 redirect erlauben (notwendig fuer Router-Fallback)
ip6tables -A INPUT -p icmpv6 --icmpv6-type redirect -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 -j LOG --log-prefix "ICMPv6:"

• Zugriff vom Laptop zum Webserver auf der Server VM (in das Firewall-Skript an passender Stelle einbauen)

# HTTP vom Internet auf Server zulassen
iptables -A FORWARD -i enp0s3 -m state --state new -p tcp --dport 80 -j ACCEPT

• Auf dem Server eine kleine Webseite erzeugen und den Webserver starten

echo "dies ist der Server" > ~/index.html
cd ~
python -m SimpleHTTPServer 80

• Auf dem Laptop eine Route auf den Server setzen und dann per Firefox auf die URL http://100.64.x.2 gehen

ip route add 100.64.x.0/24 via 192.168.1.xxx

• Auf dem Client (der hier die Rolle eines Backup-Webserver einnimmt) eine kleine Webseite erzeugen und den Webserver starten

echo "dies ist der Client" > ~/index.html
cd ~
python -m SimpleHTTPServer 80

• Backup DNAT um Anfragen an den Webserver 100.64.x.2 auf den Client "umzuleiten"

# HTTP per DNAT von Server auf den Client "umbiegen"
iptables -A PREROUTING -t nat -i enp0s3 -p tcp --dport 80 \
    -j DNAT --to-destination 172.16.x.2

• 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 enp0s3 -p tcp --dport 80 \
    -j REDIRECT --to-port 3128

• ShoreWall ist ein Wrapper um iptables. Mit ShoreWall ist es möglich, auch komplexte Firewall-Regelwerke übersichtlich(er) zu verwalten
• Webseite: http://www.shorewall.net
• es ist sehr unwarscheinlich, das ShoreWall für das neue nftables angepasst wird
• iptables Firewall stoppen (über das eigene Firewall-Stop Skript)

systemctl stop iptables
systemctl disable iptables

• Installation von ShoreWall unter Debian

apt install shorewall

• Definition der Firewall-Zonen in der Datei /etc/shorewall/zones - firewall "zonen" (max. 5 Zeichen)

#ZONE   TYPE    OPTIONS                 IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
net     ipv4
loc     ipv4
dmz     ipv4

• /etc/shorewall/interfaces - Interface zu Host Zuordnung

?FORMAT 2
###############################################################################
#ZONE           INTERFACE               OPTIONS
net             enp0s3                    dhcp
loc             enp0s8
dmz             enp0s9

• /etc/shorewall/masq - Masquerading und SNAT

#INTERFACE:DEST         SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/   SWITCH  ORIGINAL
#                                                                                       GROUP           DEST
enp0s3:                 100.64.x.0/24,172.16.x.0/24

• /etc/shorewall/policy - generische Policy zwischen Zonen

#SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
loc             net             ACCEPT
net             all             DROP            info
# THE FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info

• /etc/shorewall/rules - Ausnahmen zu der Policy zwischen Zonen (Firewallregeln)

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE          USER/   MARK    CONNLIMIT       TIME            HEADERS         SWITCH          HELPER
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW
# Kaputte Pakete stoppen
#
Invalid(DROP)   net             all             tcp

# DNS Firewall -> Internet
#
DNS(ACCEPT)     $FW             net
#
#
# SSH von Lokal zu DMZ, Firewall
#
SSH(ACCEPT)     loc             $FW
SSH(ACCEPT)     loc             dmz
#
# SSH von der Firewall zum Client, Server
##
SSH(ACCEPT)     $FW             loc
SSH(ACCEPT)     $FW             dmz
#
#
# SSH von Internet zu Firewall
#
SSH(ACCEPT)     net             $FW
#
# DNS aus der DMZ ins Internet
#
DNS(ACCEPT)     dmz             net
# Kein "ping" auf die Firewall
#
Ping(DROP)      net             $FW
#
# ping zwischen loc, firewall, dmz
#
Ping(ACCEPT)    loc             $FW
Ping(ACCEPT)    dmz             $FW
Ping(ACCEPT)    loc             dmz
Ping(ACCEPT)    dmz             loc
Ping(ACCEPT)    dmz             net
ACCEPT          $FW             net             icmp
ACCEPT          $FW             loc             icmp
ACCEPT          $FW             dmz             icmp

• /etc/shorewall/stoppedrules - Regeln aktiv wenn die Firewall gestoppt wird/ist

ACCEPT          enp0s3            -
ACCEPT          -               enp0s3
ACCEPT          enp0s8            -
ACCEPT          -               enp0s8
ACCEPT          enp0s9            -
ACCEPT          -               enp0s9

• /etc/shorewall/shorewall.conf - Globale Konfiguration des Shorewall Programms
• wir ändern hier die ShoreWall Log-Datei in eine eigene, dedizierte Log-Datei unter /var/log/shorewall. Diese Log-Datei sollte per log-rotate überwacht und rotiert werden (dafür ist eine Konfiguration des Programms logrotate notwendig)

[...]
STARTUP_ENABLED=yes

LOGFILE=/var/log/shorewall
[...]

• Shorewall Start erlauben in der Datei /etc/default/shorewall.

[..]
startup=1
[..]

• Shorewall Regeln und Konfiguration prüfen

shorewall check

• Shorewall starten

touch /var/log/shorewall
shorewall start

• die von Shorewall erzeugten iptables Regeln anzeigen

iptables -L
iptables -L -t nat 

• Shorewall stoppen (ACHTUNG! Stoprules sind aktiv)

shorewall stop

• Shorewall Regeln löschen (Firewall wird ausgeschaltet)

shorewall clear

• Shorewall Regeln/Verbindungen anzeigen

shorewall ls
shorewall ls connections
shorewall ls policies
shorewall ls routing

• Shorewall über Systemd starten/anschalten/stoppen

systemctl enable shorewall
systemctl start shorewall
systemctl stop shorewall

• Folien http://notes.defaultroutes.de/nftables.html
• PDF-Druck Version für Chrome http://notes.defaultroutes.de/nftables.html?print-pdf
• auf der Router-VM arbeiten
• Shorewall stoppen wenn aktiv

systemctl stop shorewall
systemctl disable shorewall
shorewall clear
iptables -L
iptables -L -t nat

• "nftables" auf dem Router installieren (bei Debian 10 ist "nftables" schon installiert und aktiv)

apt install nftables

• root-Shell öffnen, ntf Version abfragen

nft -v

• das nftables Ruleset auflisten (sollte am Anfang leer sein)

nft list ruleset

• ein nft Ruleset für eine Host-Firewall, per Editor in die Datei /etc/nftables.conf schreiben

# Regelsatz löschen
flush ruleset

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

table inet filter {
        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

                # activate the following line to accept common local services
                tcp dport { 22, 80, 443 } ct state new accept

                # NTP multicast
                ip6 daddr ff02::1010 udp dport 123 accept

                # mDNS (avahi)
                ip6 daddr ff02::fb udp dport 5353 accept
                ip  daddr 224.0.0.251 udp dport 5353 accept

                # DHCPv6
                ip6 saddr $any udp dport 546 accept

                # IPP (CUPS)
                tcp dport 631 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: " drop
        }
}

• nftables Firewall laden

systemctl start nftables

• Regelwerk anzeigen

nft list ruleset

• Log-Ausgaben anzeigen, es sollten nun Pakete mit dem Log-Prefix "nftables drop:" im Log erscheinen

journalctl -f | grep nftables

• eigenen Router vom Laptop aus mit nmap scannen (einmal mit nftables Firewall eingeschaltet, danach mit der nftables Firewall ausgeschaltet. Gibt es einen Unterschied?)

nmap -sT 192.168.1.xxx # <--- IP Adresse des Routers

• Beipsiel der nmap Ausgabe

Starting Nmap 7.70 ( https://nmap.org ) at 2019-12-10 11:31 CET
Nmap scan report for 192.168.1.166
Host is up (0.00048s latency).
Not shown: 996 filtered ports
PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  closed http
443/tcp closed https
631/tcp closed ipp
MAC Address: 08:00:00:00:00:0A (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 5.08 seconds

• Installationsinformationen für Wireguard https://www.wireguard.com/install/
• Derzeit ist Wireguard noch nicht in den Linux-Kernel eingezogen, soll aber in Version ~5.6 in den Kernel kommen
• der Laptop ist unser Wireguard-Client
• auf dem Laptop und auf dem VPS Server im Internet das Wireguard Repository hinzufügen, Paketlisten updaten und Wireguard-Pakete installieren

echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable.list
printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' > /etc/apt/preferences.d/limit-unstable
apt update
apt upgrade
reboot
apt install wireguard linux-headers-$(uname -r)

• User-Mask für neue Dateien und Verzeichnisse setzen, ein Verzeichnis für die Wireguard-Dateien erstellen

umask 077
mkdir -p /etc/wireguard
cd /etc/wireguard

• einen privaten Schlüssel für den Wireguard-Dienst erstellen

wg genkey > private.key

• Wireguard-Interface erstellen

ip link add dev wg0 type wireguard

• IP-Adresse auf dem neuen Wireguard-Interface wg0 setzen

ip addr add 10.0.0.2/24 dev wg0

• Privaten Schlüssel in das wg0 Interface laden

wg set wg0 private-key ./private.key

• Interface wg0 aktivieren

ip link set wg0 up

• Konfiguration der Schnittstelle anzeigen

wg show wg0

• der Laptop ist unser VPN-Client
• Wireguard installieren. Wurde ein neuer Linux-Kernel installiert, dann nach der Installation von Wireguard den Rechner neu starten, denn die Wireguard-Kernel-Module wurden schon für die neue Kernel-Version gebaut

echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable.list
printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' > /etc/apt/preferences.d/limit-unstable
apt update
apt install wireguard

• Verzeichnis für die Wireguard-Dateien erstellen

umask 077
mkdir /etc/wireguard
cd /etc/wireguard

• einen privaten Schlüssel für den Wireguard-Dienst erstellen

wg genkey > private.key

• Wireguard-Interface erstellen

ip link add dev wg0 type wireguard

• IP-Adresse auf dem neuen Wireguard-Interface wg0 setzen

ip addr add 10.0.0.1/24 dev wg0

• Privaten Schlüssel in das wg0 Interface laden

wg set wg0 private-key ./private.key

• Interface wg0 aktivieren

ip link set wg0 up

• öffentlicher Schlüssel, erlaubte IP-Adressen und IP/Port des VPN-Servers eintragen

wg set wg0 peer <schlüssel> allowed-ips 0.0.0.0/0 endpoint <vpn-server>:<port>

• Konfiguration der Schnittstelle anzeigen

wg show wg0

• Konfiguration in die Konfigurationsdatei speichern

wg showconf wg0 > /etc/wireguard/wg0.conf
chmod 0600 /etc/wireguard/wg0.conf

• Konfigurationsdatei anpassen, Address einfügen und Abschnitt Peer

[Interface]
ListenPort = <port>
PrivateKey = <private-key>
Address = 10.0.0.1/24

[Peer]
PublicKey = <public-key-of-vpn-server>
AllowedIPs = 0.0.0.0/0
Endpoint = <ip-of-vpn-server>:<port>

• auf dem VPN-Server, die Wireguard-Configuration speichern

wg showconf wg0 > /etc/wireguard/wg0.conf
chmod 0600 /etc/wireguard/wg0.conf

• Konfigurationsdatei anpassen (Address und Abschnitt Peer)

[Interface]
ListenPort = <port>
PrivateKey = <private-key>
Address = 10.0.0.2/24

[Peer]
PublicKey = <public-key-of-client>
AllowedIPs = 10.0.0.1/32

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf

• auf dem VPN-Gateway

root@vm0X:/etc/wireguard# wg-quick down wg0
[#] ip link delete dev wg0
root@vm0X:/etc/wireguard# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.0.1/32 dev wg0

• auf dem VPN-Client

root@router05:/etc/wireguard# wg-quick down wg0
[#] ip link delete dev wg0
root@router05:/etc/wireguard# wg-quick up wg0                                                                   
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip link set mtu 1420 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0

• Ping vom VPN-Client Wireguard-IP zum VPN-Server

ping 10.0.0.2

• der DNS-Resolver des Linuxhotels ist über den Tunnel nicht erreichbar, daher müssen wir einen DNS-Resolver im Internet benuzten (oder, besser, einen eigenen DNS-Resolver auf dem VPN-Gateway-Server).

echo "nameserver 1.1.1.1" > /etc/resolv.conf

• Sichtbare IP-Adresse des Client mit und ohne Wireguard prüfen, z.B. per Firefox auf der Seite https://ripe.net
• Route zu einem Host im Internet per mtr testen, mit und ohne Wireguard
• Wireguard aktivieren, mtr auf einen Server im Internet laufen lassen. Dann von Ethernet (Kabel) auf WLAN umschalten, der mtr Trace darf nicht abbrechen, der Wireguard Tunnel überlebt das umschalten

apt install mtr
mtr -t google.com

• die folgenden Schritte sowohl auf dem VPN-Gateway, als auch auf dem Client ausführen
• manuell gestartetes Wireguard beenden

wg-quick down wg0

• Wireguard per Systemd aktivieren

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0
systemctl status wg-quick@wg0
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
   Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2019-05-06 16:18:02 EDT; 1s ago
     Docs: man:wg-quick(8)
	   man:wg(8)
	   https://www.wireguard.com/
	   https://www.wireguard.com/quickstart/
	   https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
	   https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8
  Process: 13492 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
 Main PID: 13492 (code=exited, status=0/SUCCESS)

May 06 16:18:02 router05 systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
May 06 16:18:02 router05 wg-quick[13492]: [#] ip link add wg0 type wireguard
May 06 16:18:02 router05 wg-quick[13492]: [#] wg setconf wg0 /dev/fd/63
May 06 16:18:02 router05 wg-quick[13492]: [#] ip address add 10.0.0.1/24 dev wg0
May 06 16:18:02 router05 wg-quick[13492]: [#] ip link set mtu 1420 up dev wg0
May 06 16:18:02 router05 wg-quick[13492]: [#] wg set wg0 fwmark 51820
May 06 16:18:02 router05 wg-quick[13492]: [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
May 06 16:18:02 router05 wg-quick[13492]: [#] ip -4 rule add not fwmark 51820 table 51820
May 06 16:18:02 router05 wg-quick[13492]: [#] ip -4 rule add table main suppress_prefixlength 0
May 06 16:18:02 router05 systemd[1]: Started WireGuard via wg-quick(8) for wg0.

• Alle Pakete (mit Aussnahme der Wireguard Pakete) sollen durch den VPN-Tunnel gesendet werden. Eine Split-Default-Route sorgt dafür, das wir die original Default-Route nicht verlieren

ip route add <ip-des-VPN-servers>/32 via 192.168.1.5 dev eth0
ip route add  0.0.0.0/1 via 10.0.0.2 dev wg0
ip route add  128.0.0.0/1 via 10.0.0.2 dev wg0

• Test

# tracepath google.com
 1?: [LOCALHOST]                                         pmtu 1420
 1:  10.0.0.2                                             15.453ms 
 1:  10.0.0.2                                             15.446ms 
 2:  no reply
 3:  45.63.118.33                                         18.164ms 
 4:  no reply
 5:  ffm-b12-link.telia.net                               20.718ms 
 6:  ffm-bb4-link.telia.net                               15.889ms 
 7:  ffm-b1-link.telia.net                                16.062ms 
 8:  google-ic-319727-ffm-b1.c.telia.net                  15.997ms asymm 10
[...]

• Routen löschen

ip r del 0.0.0.0/1 via 10.0.0.2 dev wg0
ip r del 128.0.0.0/1 via 10.0.0.2 dev wg0
ip r del <ip-des-vpn-servers> via 192.168.1.5 dev eth0

• Wireguard Interface ausschalten

ip link set dev wg0 down

• BoringTUN: Wireguard Implementation in Rust https://github.com/cloudflare/boringtun
• Route-based VPN on Linux with WireGuard https://vincent.bernat.ch/en/blog/2018-route-based-vpn-wireguard

• Berkeley-DB Development-Dateien laden

yum install libdb-devel

• NBS Quellcode laden und auspacken

cd ~/src
wget http://www.ranum.com/security/computer_security/code/nbs.tar
tar xvf nbs.tar
cd nbs

• NBS Quellcode patchen

sed -i 's/.*extern\tint\terrno;.*/#include <errno.h>/' nbspreen.c

• NBS Quellcode bauen und Programm-Dateien installieren

make
cp nbs nbsmk nbspreen nbsdump /usr/local/bin

• Verzeichnis für NBS Dateien anlegen

mkdir /var/db/nbs

• Datenbank für NBS anlegen

cd /var/db/nbs
nbsmk -d messages.nbs

• Datenbank mit Log-Daten anlernen

nbs -d messages.nbs -i /var/log/messages -s
[...]
NBS completed run (0 sec)
9567 never before seen entries
13630 lines of input processed (70.19% NBS)
9567 total entries in database

• Neuen Log-Eintrag simulieren

logger -t nbstest "Hallo, dies ist ein Test"

• NBS Lauf

nbs -d messages.nbs -i /var/log/messages -s

• Ausgabe

nbs -d messages.nbs -i /var/log/messages -s
Aug 30 08:17:48 notebook32 nbstest: Hallo, dies ist ein Test
NBS completed run (0 sec)
1 never before seen entries
13631 lines of input processed (0.01% NBS)
9568 total entries in database

• die NBS Ausgabe kann auch in eine Datei geschrieben oder angehangen werden

nbs -d /var/db/nbs/messages.nbs -i /var/log/messages -a /var/log/nbs.log

• Log-Templater ist eine Software zur Implementation von AI-Logauswertung
  • http://www.uberadmin.com/Projects/logtemplater/
  • https://github.com/rondilley/tmpltr
• Log-Templater installieren

mkdir ~/src
cd ~/src
yum -y install git automake autoconf gcc make
git clone https://github.com/rondilley/tmpltr.git
cd tmpltr
./bootstrap
autoreconf -i
./configure
make
make install
export PATH=$PATH:/usr/local/bin

• Systemd-Journal für den Dienst sshd mit tmpltr auswerten

journalctl -u sshd | tmpltr - | sort -n |  sed -e 's/%s.*||//'

• Templates abspeichern, dann ignore Datei bearbeiten

journalctl -u sshd | tmpltr -w /var/log/sshd.ignore -

• Log mit ignore Datei auswerten

journalctl -u sshd | tmpltr -t /var/log/sshd.ignore - | sort -n |  sed -e 's/%s.*||//'

• SSH-Fehler produzieren (z.B. Anmeldeversuch mit falschem Passwort) und Log-Datei neu auswerten

ssh bar@localhost
bar@localhost's password:
Permission denied, please try again.
bar@localhost's password:

• Log-Auswerten

[bar@notebook32 tmpltr]# journalctl -u sshd | tmpltr -t /var/log/sshd.ignore - | sort -n |  sed -e 's/%s.*||//'
Opening [-] for read
           1 Aug 31 12:29:25 notebook32 sshd[24691]: Connection closed by ::1 port 40372 [preauth]
           1 Aug 31 12:29:25 notebook32 sshd[24691]: Failed password for bar from ::1 port 40372 ssh2
           1 Aug 31 12:29:23 notebook32 sshd[24691]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "bar"
           1 Aug 31 12:29:23 notebook32 sshd[24691]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost  user=bar

• Neue Log-Einträge in die Ignore-Datei aufnehmen

journalctl -u sshd | tmpltr -t /var/log/sshd.ignore -w /var/log/sshd.ignore.new - && \
  cat /var/log/sshd.ignore.new >> /var/log/sshd.ignore

• Folien: https://notes.defaultroutes.de/tls.html

• der CAA-DNS-Record (RFC 6844) beschreibt, welche Zertifizierungsstelle (CA) für eine Domain x509 Zertifikate ausstellen darf
• der CAA-Record listet den Namen der CA für "normale" und für Wildcard Zertifikate

; <<>> DiG 9.11.11-RedHat-9.11.11-1.fc31 <<>> defaultroutes.de caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64650
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;defaultroutes.de.                  IN      CAA

;; ANSWER SECTION:
defaultroutes.de.           0       IN      CAA     128 issue "letsencrypt.org"
defaultroutes.de.           0       IN      CAA     128 issuewild ";"
defaultroutes.de.           0       IN      CAA     128 iodef "mailto:security@defaultroutes.de"

;; Query time: 35 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Free Dez 06 07:26:59 CET 2019
;; MSG SIZE  rcvd: 146

• der CAA-Record wird von der CA zum Zeitpunkt des Austellen des Zertifikats geprüft
• Goolge hat die Prüfung des CAA-Records für CAs ab September 2017 für verbindlich erklärt
• Mit dem IODEF Parameter können verstösse gegen die Policy an den Besitzer der Domain gemeldet werden, dies ist jedoch bei den meisten CAs nicht implementiert
• Existiert kein CAA-Record im DNS, so darf jede CA ein x509 Zertifikat für die Domain ausstellen
• ein CAA-Record verhindert, das Zertifikate von unbefugten Personen oder von Zertifizierungstsellen mit schlechter Identitätsprüfung des Domain-Besitzers ein Zertifikat austellen kann
• die Domain mit CAA-Records sollte mit DNSSEC abgesichert sein

• NGINX installieren (Debian VPS), Passwort villa (Benutzer: nutzer)

ssh nutzer@vm0X.defaultroutes.de

• NGINX Webserver installieren

apt install nginx

• OpenSSL Schlüssel erstellen und selbst signieren, als Common-Name den Namen des Servers eintragen vm0x.defaultroutes.de
• RSA-Privaten Schlüssel erstellen (2048 bit)

openssl genrsa -out vm0X.defaultroutes.de.private 2048

• öffentlichen RSA-Schluessel erzeugen

openssl rsa -in vm0X.defaultroutes.de.private -pubout -out vm0X.defaultroutes.de.public
openssl rsa -text -pubin -in vm0X.defaultroutes.de.public | less

• OpenSSL Konfigurationsdatei für Zertifikatserstellung vm0X.defaultroutes.de.conf

[req]
prompt = no
distinguished_name = dn
req_extensions = SAN

[dn]
CN = vm0X.defaultroutes.de
emailAddress = teilnehmer@example.com
O = Linuxhotel
L = Essen
C = DE

[SAN]
subjectAltName = DNS:vm0X.defaultroutes.de,DNS:www.vm0X.defaultroutes.de

• Self-Signed-Cert ohne den Zwischenschritt CSR (Certificate Signing Request) erzeugen

openssl req -new -x509 -config vm0X.defaultroutes.de.conf -days 365 \
     -key vm0X.defaultroutes.de.private -out vm0X.defaultroutes.de.crt

• Zertifikat und privaten Schlüssel in das Verzeichnis /etc/tls kopieren (Verzeichnis ggf. erstellen) und die Berechtigungen anpassen

sudo cp vm0X.defaultroutes.de.crt vm0X.defaultroutes.de.private /etc/tls

• SSL/TLS Konfiguration, Datei /etc/nginx/sites-enabled/default

[...]
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl_certificate    /etc/tls/vm0X.defaultroutes.de.crt;
        ssl_certificate_key /etc/tls/vm0X.defaultroutes.de.private;
[...]

• NGINX-Konfiguration testen

sudo nginx -t

• NGINX Webserver neu starten

nginx -s reload
netstat -tulpen # <-- nginx Prozess sollte auf Port 80 und 443 lauschen
lsof -Poni :443 # <-- Alternative zu "netstat -tulpen"

• Mit den Firefox des Laptops auf die Webseite https://vm0X.defaultroutes.de gehen. Es sollte eine Zertifikatswarnung angezeigt werden (weil das Zertifikat über keines der Root-CAs im Browser prüfbar ist). Schaut Euch im Browser die Informationen über das Zertifikat an.
• Benutze openssl s_client auf dem Laptop um das Server-Zertifikat aus dem Webserver zu lesen und lokal zu speichern. Benutze openssl x509 um den Inhalt des Zertifikats anzuzeigen

openssl s_client -connect vm0X.defaultroutes.de:443

• Beipspiel: X509 Zertifikat von einem TLS Server mit SNI (Server Name Indication) abrufen

openssl s_client -connect www.linuxhotel.de:443 -servername www.linuxhotel.de

• Seit Version 1.13 unterstützt NGINX das neue TLS Protokoll 1.3. Die modernen Web-Browser unterstützen ebenfalls TLS 1.3. TLS 1.3 ist ab Version 1.13 aktiviert.
• In der Datei /etc/nginx/nginx.conf

  ssl_protocols             TLSv1.3 TLSv1.2;
  

• Link: Test TLS Versionen https://gf.dev/tls-test
• Middlebox Test https://tls13.mitm.watch/

• in der Datei /etc/nginx/sites-enabled/default

listen 443 ssl http2;
listen [::]:443 ssl http2;

• Test HTTP/2 mit testssl

apt install curl
curl --insecure --tlsv1.3 --http2 https://vm04.defaultroutes.de

• Gegenprobe

curl --verbose --insecure --tls-max 1.1 --tlsv1.1  https://vm04.defaultroutes.de

• Um alle Anfragen auf Port 80 (ohne Verschlüsselung) auf eine verschlüsselte Verbindung (Port 443) umzulenken, konfigurieren wir in der NGINX-Konfiguration (Datei /etc/nginx/sites-enabled/default) ein Redirect von HTTP auf HTTPS

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name vm0X.defaultroutes.de;

        # redirect zum HTTPS Server
        return 301 https://$server_name/$request_uri;
}

server {
        # SSL configuration
        #
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name vm0X.defaultroutes.de;
        ssl_certificate    /etc/tls/vm0X.defaultroutes.de.crt;
        ssl_certificate_key /etc/tls/vm0X.defaultroutes.de.private;
	[...]
}

• NGINX Konfiguration testen und neu Laden

nginx -t
nginx -s reload

• Let's Encrypt Zertifikate lassen sich automatisiert abrufen
• ACME steht für Automatic Certificate Management Environment und wird derzeit in der IETF standardisiert https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
• Es gibt verschiedene ACME-Clients
  • der offizielle ACME-Client von Let's Encrypt (viele Abhängigkeiten) https://github.com/certbot/certbot
  • Google ACME Client ohne Abhängigkeiten https://github.com/google/acme
  • LEGO - ACME Client in Go https://github.com/xenolf/lego
  • dehydrated - ACME Client als Shell-Script https://github.com/lukas2511/dehydrated
  • acme.sh - ACME Client als Shell-Skript mit Schnittstellen zu DNS-Hosting-Providern und nsupdate https://github.com/Neilpang/acme.sh
  • OpenBSD acme-client (sehr sichere Architektur) https://kristaps.bsd.lv/acme-client/

• SSLLabs Tests: https://www.ssllabs.com/ssltest/

• TLS Protokoll Unterstützung testen

openssl s_client -connect www.example.com:443 -tls1_2

• TLS Cipher Untertützung testen

openssl ciphers
openssl s_client -connect www.example.com:443 -cipher RC4-SHA

• TLS Protokoll Auswahl bei Nginx

ssl_protocols TLSv1.2 TLSv1.3;

• Cipher Auswahl vom Webserver vorgeben

ssl_prefer_server_ciphers on;

• die erlaubten krypto Algorithmen

ssl_ciphers 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA';

• Webseite des Caddy Webserver https://caddyserver.com
• wir arbeiten auf dem Debian VPS im Internet
• NGINX (und andere Server auf Port 80/443) stoppen

systemctl stop nginx

• Vorbereitetes Caddy-Paket vom Schulungsserver laden

sudo -s
cd /srv
wget https://notes.defaultroutes.de/caddy.tgz

• Caddy auspacken (Caddy ist in Go geschrieben, ist ein statisches Programm und muss nicht "installiert" werden)

tar xvfz caddy.tgz
rm caddy.tgz
mv caddy /usr/local/bin

• Caddy Konfigurationsdatei vi Caddyfile

vm0x.defaultroutes.de {
        gzip
        tls nutzerXX@linuxhotel.de
        root /srv/website
}

• Webseite erstellen

mkdir /srv/website
echo "Meine erste Caddy-Webseite" > /srv/website/index.html

• Caddy Konfiguration prüfen und bei erfolgreicher Prüfung den Caddy mit HTTP/3 (QUIC) Protokoll starten (danke an Bernd)

caddy -validate  -conf /etc/caddy/Caddyfile && caddy -quic -conf /etc/caddy/Caddyfile

• Caddy starten

caddy -conf /srv/Caddyfile

• Webseite im Firefox testen https://vm0x.defaultroutes.de/ Zertifikat anschauen

• Test der Security-Header einer Webseite mit https://securityheaders.com

• Erstelle eine Action in der Datei /etc/privoxy/user.action, welche alle Bilder einer Webseite ohne HTTPs "undeadly.org" blockt

{+block{Spiegel Bilder}}                                                                                $
.undeadly.org/images

• Erstelle ein Skript, welches eine "action" Datei aus einer der Hosts-Dateien von der unten angebenen Webseite erstellt
• Webseite mit Ad-Block Hosts-Dateien https://github.com/StevenBlack/hosts

echo "{+block{Host Liste}}" > /etc/privoxy/adblock.action
# mit awk (schneller und schoener)
cat hosts | awk '{print "."$2}' >> /etc/privoxy/adblock.action
# mit sed
cat hosts | cut -f2 | sed 's/^\(.*\)$/\.\1/g' >> /etc/privoxy/adblock.action

• die Datei /etc/privoxy/mooab.action in die Datei /etc/privoxy/config eintragen und per Web-Browser testen

• für die Übung die IPTables Firewall auf dem router ausschalten, Masquerading NAT für die Paketinstallation aber angeschaltet lassen
• in einem separaten Terminal-Fenster auf dem Router ein tcpdump für icmp laufen lassen, um die Kommunikation zwischen Client und Server zu beobachten

router# tcpdump -i enp0s8 icmp

• auf dem Client und auf dem Server das Paket strongswan installieren

apt install strongswan

• Host-to-Host Tunnel Mode (Client) /etc/ipsec.conf

config setup

conn %default
     ikelifetime=60m
     keylife=20m
     rekeymargin=3m
     keyingtries=1
     keyexchange=ikev2
     authby=secret

conn host-host
     left=172.16.x.2
     right=100.64.x.2
     auto=add

• Passwort (PSK) Client /etc/ipsec.secrets

: PSK 'sharedsecret'

• Host-to-Host Tunnel Mode (Server) /etc/ipsec.conf

config setup

conn %default
     ikelifetime=60m
     keylife=20m
     rekeymargin=3m
     keyingtries=1
     keyexchange=ikev2
     authby=secret

conn host-host
     left=100.64.x.2  # Konfig auf dem Server
     right=172.16.x.2 # Konfig auf dem Server
     auto=add

• Passwort (PSK) Server /etc/ipsec.secrets

: PSK 'sharedsecret'

• IPSec Daemon starten (auf beiden Rechnern Server/Client)

ipsec restart

• Status der Verbindungen abfragen (derzeit ist noch keine Verbindung aktiv)

ipsec status
ipsec statusall

• IPSec Verbindung starten

ipsec up host-host
ipsec status
ipsec statusall

• ein ping zwischen Client und Server VM sollte weiterhin möglich sein, jetzt aber auf dem Router mit tcpdump nicht mehr sichtbar sein
• IPSec Status aus dem Linux-Kernel anzeigen

ip xfrm state

• auf dem Router sollten wir nun ESP (IPSec Encasulated Security Payload) sehen

# tcpdump -i enp0s8  not port ssh

• vom Laptop per SSH X11 Tunnel auf den Router verbinden

ssh -Y nutzer@192.168.1.xxx <-- IP des Routers

• Wireshark installieren und den Benutzer nutzer der Gruppe wireshark hinzufügen, so das der Benutzer das Recht hat, per Sniffing Netzwerkpakete abzuhören

su -
apt install wireshark
usermod -a -G wireshark nutzer
exit

• SSH Verbindung beenden, neu einloggen (damit die neue Gruppenzugehörigkeit aktiv wird) und Wireshark starten

router0x$ wireshark

• Im Wireshark auf Interface enp0s8/enp0s9 sniffen
• auf dem Server einen Webserver starten

server0$ python -m SimpleHTTPServer

• auf dem Client die Webseite aufrufen

client0x$ links http://100.64.x.2:8000

• Im Wireshark sollten wir zwischen der Client-IP und Server-IP nur ESP-, aber keine HTTP-Pakete
• IPSec stoppen (ipsec down host-host), dann das Experiment ohne IPSec wiederholen. Es sollten nun die HTTP-Pakete im Wireshark sichtbar sein

• um per IPSec geschützte Daten im Wireshark entschlüsseln zu können, werden für jede Richtung (Security Association) benötigt: Quell-Adresse, Ziel-Adresse, SPI, Verschlüsselungs-Algorithmus, Verschlüsselungs-Schlüssel, Authentisierungs-Algorithmus und Schlüssel für die Authentisierung. Diese Daten werden auf einem Linux-Rechner mit aktiver IPSec Verbindung mit dem Befehl ip xfrm state angezeigt:

root@client05:~# ip xfr state
src 172.16.5.2 dst 100.64.5.2
        proto esp spi 0xc3d57e0e reqid 3 mode tunnel
        replay-window 0 flag af-unspec
        auth-trunc hmac(sha256) 0xebd9e051b05a07c89e51d4840ab2df87d8ca107385cee1bc291d0dd442293dd3 128
        enc cbc(aes) 0xd5719f2b10cd766bb7562099c0ee4bb5
        anti-replay context: seq 0x0, oseq 0x5, bitmap 0x00000000
src 100.64.5.2 dst 172.16.5.2
        proto esp spi 0xcf12dd2b reqid 3 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha256) 0xc82360181bc299d6931cc8061508740d5d25216f6b31ca93c436b65d27072c2e 128
        enc cbc(aes) 0x4e8a18060003b6727d8f8509e98310c5
        anti-replay context: seq 0x5, oseq 0x0, bitmap 0x0000001f

• Diese Daten im Wireshark unter Edit -> Preferences -> Protocols -> ESP -> ESP SAs -> Edit eintragen. Alle Felder müssen gefüllt werden. Die Schlüssel werden in der Hexadezimalen Schreibweise mit vorangestelltem 0x (wie vom ip xfrm state Befehl ausgegeben) eingetragen.
• Der Packet Trace im Wireshark wird nun dekodiert, die verschlüsselten Protokolle (z.B. HTTP) können analysiert werden.

• Installation (auf Client und Server)

apt install stunnel

• Client stunnel Konfiguration in /etc/stunnel/stunnel.conf

client  = yes
debug   = info
output  = /var/log/stunnel.log

; These options provide additional security at some performance degradation
options = SINGLE_ECDH_USE
options = SINGLE_DH_USE

[http-to-https]
accept  = 80
connect = 100.64.x.2:8000
cert    = /etc/stunnel/stunnel.pem

• Server stunnel Konfiguration in /etc/stunnel/stunnel.conf

debug = info
output = /var/log/stunnel.log

; These options provide additional security at some performance degradation
options = SINGLE_ECDH_USE
options = SINGLE_DH_USE
[https-8000]
accept  = 8000
connect = localhost:8001
cert = /etc/stunnel/stunnel.pem

• systemd unit in /etc/systemd/system/stunnel.service on the server

### stunnel.service

[Unit]
Description=Stunnel service
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/stunnel /etc/stunnel/stunnel.conf
Restart=always

[Install]
WantedBy=Default.target

• x509 Zertifikat erstellen

$ openssl req -new -nodes -x509 -out /etc/stunnel/stunnel.pem \
  -keyout /etc/stunnel/stunnel.pem
$ chmod 400 /etc/stunnel/stunnel.pem

• Systemd Unit auf dem Server starten

$ systemctl daemon-reload
$ systemctl enable --now stunnel

• Webserver auf dem Server auf Port 8001 starten

server0x$ python -m SimpleHTTPServer 8001

• Start des stunnel auf dem Client

$ stunnel
$ tail /var/log/stunnel.log
$ lsof -i | grep stunnel

• Test der Verbindung, links verbindet sich per HTTP unverschlüsselt, stunnel bietet die TLS Verschlüsselung (per tcpdump auf dem Router schauen das die Pakete SSL/TLS verschlüsselt sind)

$ links http://localhost

• per tcpdump auf dem Router testen, das kein HTTP oder HTTPS Verkehr zu sehen ist

tcpdump -nn -i enp0s8 port 80 or 443 or 8000

• Server stunnel Konfiguration in /etc/stunnel/stunnel.conf anpassen (Abschnitt [https])

debug = info
output = /var/log/stunnel.log

; These options provide additional security at some performance degradation
options = SINGLE_ECDH_USE
options = SINGLE_DH_USE
[https-8000]
accept  = 8000
connect = localhost:8001
cert = /etc/stunnel/stunnel.pem
[https]
accept  = 443
connect = localhost:8001
cert = /etc/stunnel/stunnel.pem

• stunnel auf dem Server neu starten

systemctl restart stunnel

• mit dem links Webbrowser testen (Protokoll HTTPS/TLS). Hier gibt es eine Zertifikats-Warnung, da der stunnel auf dem Server ein Self-Signed Zertifikat verwendet

links https://100.64.x.2

• DNS-over-TLS für einen DNS-Resolver nachrüsten https://kb.isc.org/docs/aa-01386

• HMAC-MD5 Authentisierung der OSPF-Kommunikation einschalten. Es wird ein "Shared-Secret" verwendet, hier das Wort "VILLA". Aus dem Wort und den Daten wird eine Signatur für die OSPF Pakete erzeugt. Auf allen OSPF-Routern (einer Area) muss das gleiche Secret konfiguriert werden.

router0x$ vtysh
router0x# conf terminal
router0x(config)# interface enp0s3
router0x(config-if)# ip ospf authentication message-digest
router0x(config-if)# ip ospf message-digest-key 1 md5 VILLA
router0x(config-if)# exit
router0x# router ospf
router0x(config-router)# area 0 authentication message-digest
router0x(config-router)# exit
router0x(config)# exit
router0x# write
router0x# debug ospf packet all

• Test: einen Server oder Router eines der anderen Teilnehmer per 'ping' erreichen (oder SSH).

• OSPF ist ein eigenes IP Protokoll (wie UDP oder TCP). Die Protokollnummer ist 89, der Protokoll-Name kann in der Datei /etc/protcols gefunden werden

grep ospf /etc/protocols

• Beispiel OSPF Regel

iptables -A INPUT  -p ospf -s <Quell-Netzwerk> -j ACCEPT
iptables -A OUTPUT -p ospf -d 224.0.0.0/24     -j ACCEPT

• Erweitere das IPTables Firewall Regelwerk für OSPF, starte danach den OSPFd Dienst auf dem Router neu un prüfe, ob der Routing-Dienst weiterhin die anderen Router "sehen" kann. Prüfe die Firewall-Logs auf neue Block-Meldungen.

• auf dem Router und auf dem Laptop die Tor-Software installieren

apt install tor

• auf dem Laptop bei installiertem Tor-Dienst den Socksv5-Proxy im Browser auf Port 9050 einstellen
• Alternativ kann der Tor-Browser des Tor-Projekt installiert werden ( http://www.torproject.org ). Der Tor-Browser hat den Tor-Daemon schon eingebaut, dieser muss dann nicht extra installiert sein

• auf dem Router in der Tor-Konfiguration einen Onion Hidden-Service auf Localhost Port 8000 einrichten

$EDITOR /etc/tor/torrc
[...]
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:8000
[...]

• Tor neu starten

systemctl restart tor
systemctl status tor

• auf dem Router einen Webserver Service starten (einfacher Python Webserver auf Port 8000)

python -m SimpleHTTPServer

• auf dem Router den Onion-Namen herausfinden (Datei /var/lib/tor/hidden_service/hostname) und an einen der Teilnehmer weitergeben oder selbst im Firefox (bei eingeschaltetem Socks5-Proxy auf Port 9050)
• den Onion-Dienst mit diesem "Domain"-Namen ansprechen, per Socks-Proxy aus dem Firefox oder mit dem Tor-Browser

• einige Programme (wie ssh oder links) haben keinen Support für Socks5 Proxies
• mit dem Programm torify können Programm für Tor eingerichtet werden

torify links http://<onion-adresse>.onion

• Einige Server-Dienste schalten spezielle Admin-Funktionen frei, wenn der Server über eine Loopback-Adresse (127.0.0.1) angesprochen wird (z.B. der Apache Webserver –> https://www.heise.de/security/meldung/Apache-verpetzt-moeglicherweise-Tor-Hidden-Services-3090218.html). Bei Bennutzung als Tor-Dienst auf einer Loopback-Adresse sind diese Admin-Funktionen von aussen über das Tor-Netzwerk erreichbar. Lösung: den Dienst auf einer nicht-Loopback Adresse konfigurieren, oder die speziellen Admin-Funktionen in der Server-Konfiguration ausschalten.

• seit Version 0.3.5 der Tor-Software wird ein neues, sicheres Protokoll für die Onion-Services verwendet. Die Konfiguration der Authentisierung von Tor-Clients mit der Version 3 der Onion-Services wird im folgenden beschrieben

• DEF CON 27 Conference - Roger Dingledine - The Tor Censorship Arms Race The Next Chapter https://www.invidio.us/watch?v=ZB8ODpw_om8&feature=youtu.be
• HiddenService einrichten https://matt.traudt.xyz/p/FgbdRTFr.html
• Onion-Dienste des Tor-Projektes https://onion.torproject.org/
• Connecting to an authenticated Onion service https://github.com/AnarchoTechNYC/meta/wiki/Connecting-to-an-authenticated-Onion-service

• BIND 9 Installation pruefen

apt install bind9
named -V

• Konfiguration anpassen

vi /etc/bind/named.conf
---
options {
  dnssec-enable yes;
  dnssec-validation auto;
};

• BIND 9 neu starten

systemctl restart bind9
systemctl status bind9

• Testen (AD-Flag muss erscheinen)

router0x# dig @localhost dnssec.works +dnssec +m

• Folien: https://doh.defaultroutes.de/DNS-Sicherheit-Roundtable.html
• PDF-Druck Version für Chrome: https://doh.defaultroutes.de/DNS-Sicherheit-Roundtable.html?print-pdf

• RFC draft für HTTP/3 https://datatracker.ietf.org/doc/draft-ietf-quic-http/
• HTTP over QUIC is the next generation, Video von der Fosdem 2019 https://archive.fosdem.org/2019/schedule/event/http3/
• HTTP/3 and QUIC: the details https://www.invidio.us/watch?v=mDc2kHPtavE

• https://blogs.igalia.com/dpino/2019/01/07/a-brief-introduction-to-xdp-and-ebpf/
• https://github.com/zoidbergwill/awesome-ebpf
• https://www.netronome.com/blog/bpf-ebpf-xdp-and-bpfilter-what-are-these-things-and-what-do-they-mean-enterprise/
• http://www.brendangregg.com/blog/2019-01-01/learn-ebpf-tracing.html
• https://developers.redhat.com/blog/2018/12/03/network-debugging-with-ebpf/
• https://www.ntop.org/wp-content/uploads/2018/10/Sabella.pdf

• Docker installieren (auf dem Laptop)

apt install docker.io

• Docker starten

systemctl enable --now docker

• OpenVAS laden und starten

docker run -d -p 127.0.0.1:443:443 --name openvas mikesplain/openvas

• Logs anzeigen bis OpenVAS geladen ist und die Meldung openvassd 5.1.2 started angezeigt wird:

docker logs -f openvas

• Mit dem Firefox Browser auf https://localhost (Benutzer admin, Passwort admin) am OpenVAS anmelden.
• Mit dem Task Wizard einen neuen Scan starten (unter Scans). IP-Adresse des Laptops des Trainers (192.168.1.213) angeben. Der Scan dauert mehrere Minuten.

• Michael W. Lucas – SSH Mastery https://www.michaelwlucas.com/nonfiction/ssh-mastery
• Michael W. Lucas – PGP & GPG https://www.michaelwlucas.com/nonfiction/pgp-gpg-email-for-the-practical-paranoid
• Christof Paar, Jan Pelzl – Understanding Cryptography ISBN: 3642446493
• Klaus Schmeh – Kryptografie ISBN: 3864900158
• Niels Ferguson, Bruce Schneier, Tadayoshi Kohno – Cryptography Engineering ISBN: 0470474246
• Malcolm Harkins – Managing Risk and Information Security ISBN: 1430251131
• Ross Anderson – Security Engineering (PDF: http://www.cl.cam.ac.uk/~rja14/book.html)
• Steven Bellovin – Thinking Security: Stopping Next Year's Hackers (Addison-Wesley Professional Computing) ISBN-10: 0134277546/ISBN-13: 978-0134277547
• Mastering OpenVPN - Packt
• VPNs Illustrated: Tunnels, VPNs, and IPsec byJon C. Snader
• Linux-Firewalls - Ein praktischer Einstieg, 2. Auflage http://www.oreilly.de/german/freebooks/linuxfire2ger/toc.html
• Applied Crypto Hardening Dokument https://bettercrypto.org/

• http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html
• Defending against Sequence Number Attacks https://tools.ietf.org/html/rfc6528
• ICMPv6 Filtering Recommendations https://www.ietf.org/rfc/rfc4890.txt
• Reflections on Host Firewalls https://tools.ietf.org/html/rfc7288
• RedHat VPN https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_Virtual_Private_Networks.html
• Shorewall http://shorewall.net/three-interface.htm
• Strongswan https://www.strongswan.org/documentation.html
• IPSEC VPN on Centos 7 with StrongSwan https://raymii.org/s/tutorials/IPSEC_vpn_with_CentOS_7.html
• Ubuntu IPSec HowTo (IPSec Tools) https://help.ubuntu.com/community/IPSecHowTo
• Public Key Cryptography — A Comprehensive Guide https://medium.com/blockwhat/public-key-cryptography-a-comprehensive-guide-1e8489e08104