Netzwerksicherheit Linuxhotel September 2018 (CentOS 7)

1 Informationen zum Kurs

2 Sicherheit in TCP/IP Netzwerken

3 Forwarding und Routing unter Linux

  • CentOS 7 VMs
  • Benutzer: nutzer, Password: villa
  • Root-Shell per sudo -s und dem Passwort villa
  • IP Adressen der Router
    • 01: 192.168.1.179 (Martin)
    • 02: 192.168.1.102 (Florian)
    • 03: 192.168.1.93 (Stefan)
    • 04: 192.168.1.178 (Falk)
    • 05: 192.168.1.89 (Roger)
    • 06: 192.168.1.101 (Carsten)
+--------+	       	  +--------+
| Client |	   	  | Server |
|        |	   	  |        |
|   eth0 | 	   	  |   eth0 |
+---+----+		  +----+---+
    |        Router	       |
    |       +------+       |
    | eth2  |      | eth1  |
    +-------+      +-------+
	    +---+--+
		|eth0 (externe Netze/Laptops)
  • MAC Adresse des Client: 08:00:00:00:0C:XX
  • MAC Adresse des Servers: 08:00:00:00:0F:XX
ssh nutzer@<ip-adresse>
sudo -s
ip address show

3.1 Editoren auf den virtuellen Maschinen

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

4 TMUX - terminal multiplexer

  • Auf dem Router
yum install tmux
tmux
Aktion Tastaturkombination
Neues Terminal CTRL+B C
nächstes Terminal CTRL+B N
voheriges Terminal CTRL+B P
Terminal horizontal teilen CTRL+B "
Terminal vertikal teilen CTRL+B %
zwischen geteilten Terminals wechseln CTRL+B <cursor>
zwischen geteilten Terminals wechseln CTRL+B O
Terminal schliessen CTRL+B x
Tmux abhängen (detach) CTRL+B d
Tmux anhängen tmux attach
TMUX Kommandozeile CTRL+B :
Tastenkommandos in alle Fenster (Kommandozeile) set synchronize-panes

4.1 Zugang zum Server und zum Client

  • von einer MAC-Adresse zu einer IPv6 Adresse
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 anfuegen und als IPv6 Adresse schreiben
fe80::a27:ff:feff:e8ae
  • vollständige IPv6 Adresse
fe80:0000:0000:0000:0a27:00ff:feff:e8ae
  • ausprobieren: im tmux je eine neue Pane für Server und Client erstellen, und dort an die beiden anderen VMs verbinden
  • Client:
ip link set up dev eth1
ping6 fe80::a00:ff:fe00:c0x%eth1
ssh nutzer@fe80::a00:ff:fe00:c0x%eth1
  • Server
ip link set up dev eth2
ping6 fe80::a00:ff:fe00:f0x%eth2
ssh nutzer@fe80::a00:ff:fe00:f0x%eth2
  • Hostnamen der Server VM äendern
hostnamectl set-hostname server0x
bash
  • Hostnamen der Client VM äendern
hostnamectl set-hostname client0x
bash

5 Quagga Router

  • wir arbeiten auf dem Router-VM Rechner
  • "tmux" starten und in "tmux" arbeiten
  • auf dem Router Server den Hostnamen aendern (als root)
hostnamectl set-hostname router0X
  • um den neuen Hostnamen zu sehen, die Root-Shell beenden und per sudo -s eine neuen Root-Shell öffnen
  • die Software 'quagga' installieren (auf dem Router)
yum install quagga
  • Rechte auf dem Konfigurationsverzeichnis anpassen und den Quagga-Dienst starten
systemctl enable --now zebra
systemctl status zebra
touch /etc/quagga/ospfd.conf
chown quagga /etc/quagga/ospfd.conf
systemctl enable --now ospfd
systemctl status ospfd
ps aux | grep quagga
quagga    3214  0.0  0.0  24712   732 ?        Ss   21:58   0:00 /usr/lib/quagga/zebra --daemon -A 127.0.0.1
root      3232  0.0  0.1  14228   976 pts/1    S+   21:58   0:00 grep --color=auto quagga
  • Quagga Kommanozeile aufrufen (auf dem Router)
vtysh
router0X#
router0x# conf terminal
router0x(config)# interface eth1
router0x(config-if)# ipv6 address fd0x::1/64
router0x(config-if)# ipv6 nd prefix fd0x::/64 900 300
router0x(config-if)# no ipv6 nd suppress-ra
router0x(config-if)# no shutdown
router0x(config-if)# exit
router0x(config)# interface eth2
router0x(config-if)# ipv6 address 2001:db8:x::1/64
router0x(config-if)# ipv6 nd prefix 2001:db8:x::/64 900 300
router0x(config-if)# no ipv6 nd suppress-ra
router0x(config-if)# no shutdown
router0x(config-if)# exit
router0x(config)# exit
router0x# conf terminal
router0x(config)# interface eth1
router0x(config-if)# ip address 172.16.x.1/24
router0x(config-if)# exit
router0x(config)# interface eth2
router0x(config-if)# ip address 100.64.x.1/24
router0x(config-if)# exit
router0x(config)# end
router0x# write
  • vom Router SSH auf den Server (neues TMUX Fenster oeffnen)
ssh nutzer@2001:db8:x::a00:ff:fe00:f0x
  • manuelle IP Konfiguration auf dem Server
sudo -s
ip addr add 100.64.x.2/24 dev eth0
ip route add default via 100.64.x.1
  • IP Konfiguration fest einstellen
vi /etc/sysconfig/network-scripts/ifcfg-eth0
---
DEVICE=eth0
STARTMODE=auto
BOOTPROTO=none
ONBOOT=yes
IPADDR=100.64.x.2
NETMASK=255.255.255.0
GATEWAY=100.64.x.1
USERCTL=no
  • vom Router per SSH auf den Client (neues TMUX Fenster oeffnen)
ssh nutzer@fd0x::a00:ff:fe00:c0x
  • manuelle IP Konfiguration auf dem Client
ip addr add 172.16.x.2/24 dev eth0
ip route add default via 172.16.x.1
  • IP Konfiguration fest einstellen
vi /etc/sysconfig/network-scripts/ifcfg-eth0
---
DEVICE=eth0
STARTMODE=auto
BOOTPROTO=none
ONBOOT=yes
IPADDR=172.16.x.2
NETMASK=255.255.255.0
GATEWAY=172.16.x.1
USERCTL=no
  • Testen der Verbindungen
    • vom Server zum Router (auf dem Server):
ping 100.64.x.1
ping 172.16.x.1
ping6 2001:db8:x::1
ping6 fd0x::1
  • vom Client zum Router (auf dem Client):
ping 172.16.x.1
ping 100.64.x.1
ping6 fd0x::1
ping6 2001:db8:x::1

5.1 Routing

  • 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

5.2 Verbindung in das Internet

  • 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 oder NAT44)
  • auf dem Router in einer BASH-Shell (nicht im Quagga)
iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

6 iptables/nftables Firewall

6.1 iptables

6.1.1 Chains

  • prerouting
  • input
  • output
  • forward
  • postrouting

6.1.2 Tables

  • filter (default)
  • nat
  • mangle
  • raw

6.1.3 Befehle

  1. Regeln auflisten
    iptables -L <chain> [-t <table>]
    iptables -L <chain> [-t <table>] -v -n
    
  2. Regeln einer Chain/Tabelle loeschen
    iptables -F <chain> [-t <table>]
    
  3. Default Policy setzen
    iptables -P <chain> [DROP|ACCEPT]
    
  4. Chain anlegen/loeschen
    iptables -N <chainname>
    iptables -X <chainname>
    
  5. Regeln anlegen/einfuegen/loeschen
    iptables -A <chain> <Regel>
    iptables -I <chain> <pos> <Regel>
    iptables -R <chain> <pos> <Regel>
    iptables -D <chain> <pos>/<Regel>
    

6.1.4 Regeln

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 ...)

6.1.5 Targets

-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 POSTROUTING, Table "nat"
-j DNAT --to-destination <addr>[-addr][:port-port] # nur PREROUTING und OUTPUT, Table "nat"
-j REDIRECT --to-ports port[-port]
-j MASQUERADE --to-ports port[-port]
-j chain-name

6.1.6 Protokoll "tcp"

--syn # Verbindungsaufbau
--tcp-flags <mask> <active> # SYN,ACK,FIN,RST,URG,PSH,ALL,NONE
--tcp-flags SYN,RST,ACK SYN

6.1.7 Protokoll "icmp"

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

6.1.8 Modul "state"

  • NEW
  • ESTABLISHED
  • RELATED
  • INVALID
-m state --state <state1[,state2,...]>

6.1.9 Modul 'recent'

  • Nur 3 SSH Anmeldeversuche per 15 Minuten
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

6.1.10 Logging

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

6.1.11 Masqerading

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

6.1.12 Beispiel einer 'iptables' Script Preamble

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

6.1.13 Beispiel eines Firewall-Stopp-Script

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

6.1.14 Firewall Regeln testen mit "Sicherheitsnetz"

  • Firewall-Regeln nach 1 Minute zurücksetzen
(sleep 60 && ./firewall-stopp.sh) &
./firewall.sh

6.2 Aufgabe Host-Firewall mit iptables

  • Erstelle eine Host-Firewall-Regeln für den Router
    • ausgehend alle Verbindungen erlauben
    • eingehend auf eth0, eth1 und eth2 nur SSH (Port 22) und ICMPv4 erlauben
    • Verworfene Pakete in das syslog (Journal) schreiben
    • wer möchte kopiert seine Lösung in das Etherpad
  • 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)

6.2.1 Tests

  • Diese Tests sollen funktionieren
    • SSH vom Laptop zum Router
    • "ping" vom Router zum Internet-GW 192.168.1.5
    • "ping" vom Laptop zum Router
  • dieser Test sollten nicht funktionieren
    • DNS Anfrage von Laptop 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)

6.2.2 eine mögliche Lösung

#!/bin/sh

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

# bestehene Regeln loeschen (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 eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# bestehende eingehende Verbindungen aus dem Client/Server-Netz erlauben
iptables -A INPUT  -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i eth2 -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 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 --line-numbers

6.3 Firewall testen mit "nmap"

  • Test der Firewall vom Laptop aus (d.h. diese Befehle direkt auf dem Laptop ausführen)
yum install nmap
nmap -sT -v -A -O 192.168.1.yyy # <ip-der-firewall>
ip route add 172.16.x.0/24 via <ip-des-Firewall-Routers>
nmap -sT -v -O 172.16.x.0/24 # <ip-netz-hinter-der-firewall>

6.4 iptables Regeln sichern

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

6.5 iptables systemd unit

  • 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=Packet Filtering Framework
DefaultDependencies=no
After=systemd-sysctl.service
Before=sysinit.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables-restore /etc/iptables.rules
ExecReload=/usr/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
  • Test durch Reboot der Firewall-Maschine (Router)
router0x# reboot

6.6 Anpassung des Firewall-Flush-Skripts

  • 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

6.7 Anpassung: vom Client zum Linuxhotel DNS-Resolver

  • SSH vom Router auf Client/Server erlauben, dafür die Zeilen
# bestehende eingehende Verbindungen aus dem Internet erlauben
iptables -A INPUT  -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
  • ersetzen durch
# bestehende eingehende Verbindungen 
iptables -A INPUT  -m state --state RELATED,ESTABLISHED -j ACCEPT
  • Testen, das der Client (VM) derzeit nicht DNS-Namensauflösung über den DNS-Resolver im Linuxhotel Netzwerk machen kann
ssh nutzer@172.16.x.2
dig @192.168.1.5 linuxhotel.de a ## <-- Timeout
  • Erstelle Regeln, welche dem Client erlauben, per DNS Port 53 (UDP/TCP) auf den DNS-Resolver im Linuxhotel (192.168.1.17) 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
  • Test auf dem Client (VM)
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
  • DNS-Resolver in der /etc/resolv.conf auf der Client VM eintragen
client0x$ echo "nameserver 192.168.1.5" > /etc/resolv.conf

6.8 Aufgabe - Regeln für Paket-Installation:

  • welche weiteren Regeln müssen in der Firewall eingetragen werden, um Paketinstallationen auf dem Client per yum install zu erlauben
  • erstelle die Regeln und teste das Paket links zu installieren (ein Text-Webbrowser) (yum install links)

6.9 Lösung - Regeln für Paket-Installation:

[...]
iptables -A FORWARD -s 172.16.x.0/24  -p tcp --dport 80  -j ACCEPT
iptables -A FORWARD -s 172.16.x.0/24  -p tcp --dport 443 -j ACCEPT
[...]

6.10 Verbindungen auf dem Router anschauen per iftop

router0x$ yum install iftop
router0x$ iftop -i eth0
  • Taste p schaltet die Anzeige der UDP/TCP Ports an
  • Taste n schaltet DNS-Rückwärtsauflösung für IP-Adressen aus

6.11 Aufgabe: Routing-Firewall

  • 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 (80) und HTTPS (443) vom Client/Server ins Internet zulassen (fuer 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

6.11.1 Tests

  • SSH vom Client zum Server
client0x# ssh root@100.64.x.2
  • HTTP vom Client zum Server testen
    • auf dem Server einen Webserver-Prozess starten
server0x# python -m SimpleHTTPServer 80
  • 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)
client0x# sudo yum install links
client0x# links 100.64.x.2
  • DNS vom Server ins Internet testen
server0x# dig @192.168.1.17 kernel.org a
  • http/https vom Server/Client ins Internet testen
echo "nameserver 192.168.1.5" > /etc/resolv.conf
links www.linuxhotel.de
links https://notes.defaultroutes.de
  • auf dem Server/Client "nmap" installieren und von dort den Router und das Linuxhotel GW scannen (was laesst die Firewall von innen nach aussen durch)
yum install nmap
nmap -sT 172.16.x.1
nmap -sT 172.16.x.2
nmap -sT 100.64.x.1
nmap -sT 100.64.x.2
nmap -sT 192.168.1.5
  • bei einem Scan vom Server/Client oder von der Firewall in das Linuxhotel Netz oder ins 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.

6.11.2 Eine mögliche Lösung

#!/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 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 eth0 -j MASQUERADE

# DHCPv4 ausgehen erlauben
iptables -A OUTPUT -p udp --dport 68 -m state --state NEW -j ACCEPT

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

# SSH vom Router zum Server erlauben
iptables -A OUTPUT -o eth2 -p tcp --dport 22 -j ACCEPT

# SSH vom Router zum Client erlauben
iptables -A OUTPUT -o eth1 -p tcp --dport 22 -j ACCEPT

# SSH vom Client-Netz zum Server erlauben
iptables -A FORWARD -i eth1 -p tcp --dport 22 -j ACCEPT

# HTTP vom Client zum Server
iptables -A FORWARD -s 172.16.x.2 -d 100.64.x.2 -p tcp --dport 80 -j ACCEPT

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

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

# HTTP/HTTPS vom Router/Client/Server zulassen
iptables -A FORWARD -o eth0 -m state --state new -p tcp --dport 80  -j ACCEPT
iptables -A FORWARD -o eth0 -m state --state new -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT  -o eth0 -m state --state new -p tcp --dport 80  -j ACCEPT
iptables -A OUTPUT  -o 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 LOG --log-prefix "FW INP Drop:"
iptables -A FORWARD -j LOG --log-prefix "FW FRW Drop:"
iptables -A OUTPUT  -j LOG --log-prefix "FW OUT Drop:"
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
iptables -A OUTPUT -j DROP

6.12 Beispiel Destination-NAT (DNAT)

  • 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 eth0 -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 testen
ip route add 100.64.x.0/24 via 192.168.1.xxx
links 100.64.x.2
  • 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 eth0 -p tcp --dport 80 \
    -j DNAT --to-destination 172.16.x.2

6.13 Firewall Monitoring

6.13.1 Templater installieren

  • auf dem Router als Benutzer root
yum install git automake autoconf gcc make
mkdir ~/src
cd ~/src
git clone https://github.com/rondilley/tmpltr.git
cd tmpltr
./bootstrap
autoreconf -i
./configure
make
make install

6.13.2 iptables Log mit "tmpltr" auswerten

  • iptables Log mit tmpltr auswerten
export PATH=$PATH:/usr/local/bin
journalctl |  grep "kernel: FW" | tmpltr - | sort -n |  sed -e 's/%s.*||//'
  • Templates abspeichern, dann "ignore" Datei bearbeiten. z.B. Log-Ausgaben zu Multicast-DNS oder OSPF (Multicast-IP 224.0.0.5) ausfiltern.
journalctl |  grep "kernel: FW" | tmpltr -w fw.ignore -
  • Log mit "ignore" Datei auswerten
journalctl |  grep "kernel: FW" | tmpltr -t fw.ignore - | sort -n |  sed -e 's/%s.*||//'

6.14 Shorewall

systemctl stop iptables
systemctl disable iptables
  • Installation unter CentOS
yum install shorewall
  • /etc/shorewall/zones - firewall "zonen" (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             eth0                    dhcp
loc             eth1
dmz             eth2
  • /etc/shorewall/masq - Masquerading und SNAT
#INTERFACE:DEST         SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/   SWITCH  ORIGINAL
#                                                                                       GROUP           DEST
eth0:                   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          eth0            -
ACCEPT          -               eth0
ACCEPT          eth1            -
ACCEPT          -               eth1
ACCEPT          eth2            -
ACCEPT          -               eth2
  • /etc/shorewall/shorewall.conf - Globale Konfiguration des Shorewall Programms
[...]
STARTUP_ENABLED=yes

LOGFILE=/var/log/shorewall
[...]
  • 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

6.15 Firewall Unittest und Dokumentation mit Emacs-Org-Mode und Babel

yum 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-Tests
#+Language: de

* Babel anschalten                                                 :noexport:
#+BEGIN_EXAMPLE                                                                                          
(org-babel-load-languages                                                                                
(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 undere 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

6.16 nftables Firewall

systemctl stop shorewall
shorewall clear
iptables -L
iptables -L -t nat
  • "nftables" auf dem Router installieren
yum install nftables
  • root-Shell öffnen, ntf Version abfragen
sudo -s
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/inet-filter 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;

                # 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)
                udp 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
        }
}
  • Filter include "/etc/nftables/inet-filter" in der Datei /etc/sysconfig/nftables.conf einkommentieren
  • nftables Firewall laden
systemctl start nftables
  • Regelwerk anzeigen
nft list ruleset
  • Log-Ausgaben anzeigen
journalctl -f | grep nftables
  • eigenen Router vom Laptop aus mit nmap scannen (einmal mit nftables Firewall, einmal mit der nftables Firewall ausgeschaltet. Gibt es einen Unterschied?)
nmap -sT 192.168.1.xxx # <--- IP Adresse des Routers

7 Einführung in Krypto

8 OpenVPN

  • Programm tcpdump installieren
yum install tcpdump
  • OpenVPN installieren
yum install openvpn
  • Schlüssel erzeugen und per gesicherten Kanal auf beide Endpunkte des VPN-Tunnels bringen (z.B. per Secure Copy "scp")
client0x# cd /etc/openvpn
client0x# openvpn --genkey --secret static.key
client0x# scp static.key root@100.64.x.2:/etc/openvpn/
  • Server-Konfiguration /etc/openvpn/server.conf (auf dem Server-Rechner)
dev tun
ifconfig 10.0.x.1 10.0.x.2
secret /etc/openvpn/static.key
  • Client-Konfiguration /etc/openvpn/client.conf (auf dem Client-Rechner)
remote 100.64.x.2
dev tun
ifconfig 10.0.x.2 10.0.x.1
secret /etc/openvpn/static.key
  • Treiber für Tunnel-Interface laden und OpenVPN start (Server)
modprobe tun
openvpn /etc/openvpn/server.conf &
  • Auf dem Server einen Webserver (Port 8000) starten
python -m SimpleHTTPServer 8000
  • OpenVPN start (Client)
modprobe tun
openvpn /etc/openvpn/client.conf &
  • Tunnel-Interfaces anzeigen
ip a
  • Testen (mit tcpdump auf dem Router die Pakete anschauen tcpdump -i eth1 port 80 und tcpdump -i eth1 icmp )
client0x# ping 10.0.x.1
client0x# links http://10.0.x.1:8000

9 WireGuard

  • Wir haben 5 virtuelle Maschinen im Internet (vm01-vm05.defaultroutes.de),
  • Benutzer root, Passwort netsec09!
  • Plan: VPN vom Router zur VM im Internet, alle Pakete vom Router sollen über das VPN und die VM im Internet gesendet werden

9.1 Wireguard CentOS 7 Installation (VPN-Client/VPN-Server)

  • Installationsinformationen für Wireguard https://www.wireguard.com/install/
  • Die wg-quick Funktion von Wireguard ist derzeit unter CentOS/RedHat 7.x nicht benutzbar (Kernel zu alt -> https://lists.zx2c4.com/pipermail/wireguard/2018-June/003081.html). Wir benutzen hier eine alternative Routing-Lösung.
  • die Router-VM ist unser Wireguard-Client
  • Derzeit ist Wireguard noch nicht in den Linux-Kernel eingezogen, soll aber in Version 4.20/5.00 in den Kernel kommen
  • Wireguard Repository Quellen laden, EPEL-Repository hinzufügen und Wireguard-Pakete installieren
sudo -s

curl -Lo /etc/yum.repos.d/wireguard.repo \
 https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo

yum install epel-release

yum install wireguard-dkms wireguard-tools

9.2 Konfiguration Wireguard auf dem VPN-Server (Gateway)

  • Firewall ausschalten (oder besser: eine Regel für den Wireguard Port (UDP) erstellen)
systemctl stop firewalld
  • Verzeichnis für die Wireguard-Dateien erstellen
mkdir /etc/wireguard
cd /etc/wireguard
  • einen privaten Schlüssel für den Wireguard-Dienst erstellen
wg genkey > private.key
  • Berechtigungen auf dem privaten Schlüssel anpassen
chmod 0400 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

9.3 Konfiguration Wireguard auf dem VPN-Client

  • der Router ist unser VPN-Client
  • Verzeichnis für die Wireguard-Dateien erstellen
mkdir /etc/wireguard
cd /etc/wireguard
  • einen privaten Schlüssel für den Wireguard-Dienst erstellen
wg genkey > private.key
  • Berechtigunen auf dem privaten Schlüssel anpassen
chmod 0400 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
[Interface]
ListenPort = <port>
PrivateKey = <private-key>

[Peer]
PublicKey = <public-key>
AllowedIPs = 0.0.0.0/0
Endpoint = <ip-of-vpn-server>:<port>
  • Konfiguration laden
wg setconf wg0 /etc/wireguard/wg0.conf

9.4 Client auf dem Server erlauben

  • auf dem VPN-Server, die Wireguard-Configuration speichern
wg showconf wg0 > /etc/wireguard/wg0.conf
chmod 0600 /etc/wireguard/wg0.conf
  • Konfigurationsdatei anpassen (Abschnitt Peer)
[Interface]
ListenPort = <port>
PrivateKey = <private-key>

[Peer]
PublicKey = <public-key-of-client>
AllowedIPs = 10.0.0.1/32
  • Konfiguration laden
wg setconf wg0 /etc/wireguard/wg0.conf

9.5 IP-NATPT auf dem Server und IPv4-Forwarding anschalten

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

9.6 VPN Test

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

9.7 DNS Resolver auf einen Resolver im Internet setzen

  • der DNS-Resolver des Linuxhotels ist über den Tunnel nicht erreicbar, 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

9.8 Routing auf dem Client

  • 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
[...]

9.9 Wireguard auf dem Client ausschalten

  • 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

10 SSH VPN

  • Auf dem Router Wireguard stoppen
  • OpenVPN stoppen (auf dem Server und dem Client)
pkill openvpn
  • SSH-VPN Tunnel auf dem Server erlauben
server0x# $EDITOR /etc/ssh/sshd_config
---
PermitTunnel yes
---
systemctl restart sshd
  • auf dem Server Anmeldung per Passwort für Root freischalten
$EDITOR /etc/ssh/sshd_config
---
[...]
PermitRootLogin yes
[...]
---
systemctl restart sshd
  • auf dem Client ein SSH-VPN Tunnel zum Server
client0x$ sudo ssh -NTCf -w 0:0 100.64.x.2
  • auf dem Server geben wir dem Tunnel eine IP-Adresse aus dem Server-Segment
sudo ip link set tun0 up
sudo ip addr add 100.64.1x.100/32 peer 100.64.1x.200 dev tun0
  • auf dem Client auch (IP Adressen vertauscht)
sudo ip link set tun0 up
sudo ip addr add 100.64.1x.200/32 peer 100.64.1x.100 dev tun0
  • nun sollten wir die jeweilige Gegenseite per 'ping' erreichen
  • über Routing kann nun, ähnlich wie in der Wireguard-Übung, die IP-Kommunikation eines der Rechner (oder eines Netzes) über den SSH-VPN-Tunnel gesendet werden.
  • Alternative für ein SSH-VPN: sshuttle https://github.com/apenwarr/sshuttle

11 SSL/TLS

11.1 TLS-Einführung

11.2 x509 Zertifikate

11.2.1 x509 Zertifikate mit OpenSSL

  • RSA-Privaten Schluessel erstellen (2048 bit)
mkdir ~/tls
cd ~/tls
openssl genrsa -aes128 -out mykey.private 2048
less mykey.private
openssl rsa -text -in mykey.private | less
  • oeffentlichen RSA-Schluessel erzeugen
openssl rsa -in mykey.private -pubout -out mykey.public
less mykey.public
openssl rsa -text -pubin -in mykey.public | less
  • Certificate signing request (CSR) erstellen
openssl req -new -key mykey.private -out mycert.csr
less mycert.csr
openssl req -text -in mycert.csr -noout | less
  • CSR mit Konfigurationsdatei / mehrere Domain-Namen. Hier im Beispiel eine Datei mit dem Namen mycert.conf erstellen:
[req]
prompt = no
distinguished_name = dn
req_extensions = ext

[dn]
CN = ubu01do.strotmann.de
emailAddress = carsten@strotmann.de
O = Linuxhotel
L = Essen
C = DE

[ext]
subjectAltName = DNS:www.ubu01do.strotmann.de,DNS:ubu01do.strotmann.de
  • Certificate Signing Request mittels der Konfigurationsdatei erstellen
openssl req -new -config mycert.conf -key mykey.private -out mycert.csr
  • Self-Signed-Certificate erstellen (selbst signieren, ohne CA)
openssl x509 -req -days 365 -in mycert.csr -signkey mykey.private -out mycert.crt
  • x.509 Cert per OpenSSL anzeigen
openssl x509 -text -in mycert.crt -noout
  • Alternatives Kommando zum Erstellen eines Self-Signed Certificate: Self-Signed-Cert ohne CSR (Signing Reuqest Zwischenschritt)
openssl req -new -x509 -config mycert.conf -days 365 -key mykey.private -out mycert.crt

11.3 NGINX Webserver mit SSL

  • NGINX installieren (CentOS VPS), Passwort netsec09 (root)
ssh root@vm0X.defaultroutes.de
  • NGINX Webserver installieren
yum install nginx
  • OpenSSL Schlüssel erstellen und selbst signieren, als Common-Name den Namen des Servers eintragen vm0x.defaultroutes.de
  • RSA-Privaten Schluessel erstellen (2048 bit)
openssl genrsa -out vm0X.defaultroutes.de.private 2048
  • oeffentlichen 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 = ext

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

[ext]
subjectAltName = DNS:vm0X.defaultroutes.de,DNS:www.vm0X.defaultroutes.de
  • Self-Signed-Cert ohne CSR (Certificate Signing Request)
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)
cp vm0X.defaultroutes.de.crt vmX.defaultroutes.private /etc/tls
  • SSL/TLS Konfiguration, Datei /etc/nginx/nginx.conf
[...]
        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
nginx -t
  • NGINX Webserver neu starten
systemctl restart nginx
systemctl status nginx
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

11.4 Optionale Aufgabe HTTP zu HTTPS Redirect

  • Um alle Anfragen auf Port 80 (ohne Verschlüsselung) auf eine verschlüsselte Verbindung umzulenken, bauen wir in der NGINX-Konfiguration ein Redirect von HTTP auf HTTPS
server {
        listen 80 default_server;
        listen [::]:80 default_server;
        # redirect zum HTTPS Server
        return 301 https://$server_name/$request_uri;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name vmX.defaultroutes.de;
        location / {
                try_files $uri $uri/ =404;
        }
}
server {
        # SSL configuration
        #
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl_certificate    /etc/tls/vmX.defaultroutes.de.crt;
        ssl_certificate_key /etc/tls/vmX.defaultroutes.de.private;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name _;
        location / {
                try_files $uri $uri/ =404;
        }
}

11.5 Let's Encrypt und das ACME Protokoll

11.5.1 Let's Encrypt Zertifikate mit acme.sh

  • Abhängigkeiten git und socat installieren. socat wird nur für die standalone Web-Challenge, nicht aber für die DNS-Challenge benötigt
yum install git socat
  • acme.sh per git aus dem Repository laden
git clone https://github.com/Neilpang/acme.sh
  • acme.sh installieren
cd acme.sh
./acme.sh --install --cert-home /etc/tls --home /etc/acme
  • NGINX stoppen (da wir acme.sh hier im standalone Modus betreiben und acme.sh einen eigenen Server auf Port 80 startet)
systemctl stop nginx
  • Test: ein Zertifikat für den Namen vmXX.defaultroutes.de per standalone Webservice anfordern (Port 80 auf dem Server muss frei sein)
cd ~
source ~/.bashrc
acme.sh  --issue  -d vmXX.defaultroutes.de  --standalone --cert-home /etc/tls
[Tue Mar 20 11:27:00 UTC 2018] Standalone mode.
[Tue Mar 20 11:27:01 UTC 2018] Registering account
[Tue Mar 20 11:27:01 UTC 2018] Registered
[Tue Mar 20 11:27:02 UTC 2018] ACCOUNT_THUMBPRINT='B4YKRQUJv42qkv9SH_2JP-FD_JsEyKkmgt7wRVsug3c'
[Tue Mar 20 11:27:02 UTC 2018] Creating domain key
[Tue Mar 20 11:27:02 UTC 2018] The domain key is here: /etc/acme/.acme.sh/vmXX.defaultroutes.de/vmXX.defaultroutes.de.key
[Tue Mar 20 11:27:02 UTC 2018] Single domain='vmXX.defaultroutes.de'
[Tue Mar 20 11:27:02 UTC 2018] Getting domain auth token for each domain
[Tue Mar 20 11:27:02 UTC 2018] Getting webroot for domain='vmXX.defaultroutes.de'
[Tue Mar 20 11:27:02 UTC 2018] Getting new-authz for domain='vmXX.defaultroutes.de'
[Tue Mar 20 11:27:02 UTC 2018] The new-authz request is ok.
[Tue Mar 20 11:27:03 UTC 2018] Verifying:vmXX.defaultroutes.de
[Tue Mar 20 11:27:03 UTC 2018] Standalone mode server
[Tue Mar 20 11:27:06 UTC 2018] Success
[Tue Mar 20 11:27:06 UTC 2018] Verify finished, start to sign.
[Tue Mar 20 11:27:07 UTC 2018] Cert success.
-----BEGIN CERTIFICATE-----
MIIFDTCCA/WgAwIBAgISBGvqztwcY0p9jGrx/psiyxfLMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODAzMjAxMDI3MDdaFw0x
[...]
qIOIRUmRSuTLXDWjih7kTKSLzDr8NEsvIm9qh8EmUsPEYDqye0lU2hV1evaHZXkQ
pQOxfr9yf0eGvS5jj2kW1AVi2Dz3880c0M0jUJH7JyMOs3KrVk2VorGfVTctlx8c
4g==
-----END CERTIFICATE-----
[Tue Mar 20 11:27:07 UTC 2018] Your cert is in  /etc/tls/vmXX.defaultroutes.de/vmXX.defaultroutes.de.cer
[Tue Mar 20 11:27:07 UTC 2018] Your cert key is in  /etc/tls/vmXX.defaultroutes.de/vmXX.defaultroutes.de.key
[Tue Mar 20 11:27:08 UTC 2018] The intermediate CA cert is in  /etc/tls/vmXX.defaultroutes.de/ca.cer
[Tue Mar 20 11:27:08 UTC 2018] And the full chain certs is there:  /etc/tls/vmXX.defaultroutes.de/fullchain.cer
  • die Pfade zu den ACME-Zertifikaten in der NGINX-Configuration /etc/nginx/nginx.conf anpassen und NGINX neu starten
$EDITOR /etc/nginx/nginx.conf
systemctl start nginx
  • Webseite vm0X.defaultroutes.de testen. Dort sollte nun keine Zertifikatswarnung mehr erscheinen und das Schloss-Symbol in der URL-Leiste des Browsers sollte grün werden

11.6 TLS mit Caddy

  • wir arbeiten auf der VM im Internet
  • NGINX (und andere Server auf Port 80/443) stoppen
systemctl stop nginx
  • Webseite https://caddyserver.com
  • 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
  • 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 starten
./caddy
  • Webseite im Firefox testen https://vm0x.defaultroutes.de/ Zertifikat anschauen

11.7 HSTS - HTTP Strict Transport Security (RFC 6797)

  • Signalisiert zum Browser das dieser Server für eine Zeitspanne TLS unterstützen wird
    • Browser 'lernen' und speichern die HSTS-Informationen
    • erster Besuch auf einer TLS-gesicherten Seite ist noch nicht durch HSTS geschützt
    • HSTS Zertifikatsfehler sind fatal (der Benutzer hat keine Möglichkeit des 'click-through' um den Zertifikatsfehler zu umgehen und die Seite trotzdem zu laden)
    • Beispiel-Konfiguration für NGINX
add_header Strict-Transport-Security max-age=15768000; # HSTS fuer 6 Monate

11.8 TLS Crypto hardening

  • TLS Protokol 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 Protokol Auswahl bei Nginx
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # not possible to do exclusive
  • Cipher Auswahl (nginx)
ssl_prefer_server_ciphers on;
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';
  • Beispiel TLS-Handshake bei Postfix Mailserver
Jun  7 18:18:43 m3 postfix/smtp[32096]: Untrusted TLS connection established to mx02.t-online.de[194.25.134.9]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jun  7 18:18:43 m3 postfix/smtp[32095]: Verified TLS connection established to mx01.emig.gmx.net[212.227.17.5]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

12 stunnel

12.1 Tunnel, wenn sowohl Client als auch Server kein TLS sprechen

  • Installation (auf Client und Server)
$ yum 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 verschluesselt sind)
$ links http://localhost
  • per tcpdump auf dem Router testen, das kein HTTP oder HTTPS Verkehr zu sehen ist
tcpdump -nn -i eth1 port 80 or 443 or 8000

12.2 Tunnel, wenn der Client TLS spricht, der Server aber nicht

  • 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

13 DNS-over-TLS

14 DNSSEC

15 Netzwerktrennung mit Proxies

15.1 Content-Filter Proxy privoxy

  • Auf dem Laptop arbeiten
  • In /etc/yum.repos.d/CentOS-Base.repo die Plus- und Extra-Repositories aktivieren (enable=1), EPEL-Release (Extra-Packages-for-RedHat-Linux)
yum install epel-release
  • Privoxy Homepage http://privoxy.org
  • Privoxy horcht auf Port 8118
  • "action" –> was soll mit einer URL passieren (blocken, filtern etc)?
  • "filter" –> wie soll Inhalte umgeschrieben werden?
$ yum install privoxy
$ systemctl enable privoxy
$ systemctl start privoxy
  • Konfiguration
$ vi /etc/privoxy/config
$ vi /etc/privoxy/default.action
$ vi /etc/privoxy/user.action
$ vi /etc/privoxy/default.filter
$ vi /etc/privoxy/user.filter

15.1.1 Aufgabe 1

  • Erstelle eine Action in der Datei /etc/privoxy/user.action, welche alle Bilder der Spiegel.de Webseite blockt

15.1.2 Lösung 1

{+block{Spiegel Bilder}}                                                                                $
.spiegel.de/images

15.1.3 Aufgabe

15.1.4 Lösung 2

wget "https://forum.xda-developers.com/attachment.php?attachmentid=4427681&d=1519299990"
mv attachment.php\?attachmentid\=4427681\&d\=1519299990 moaab.zip
unzip moaab.zip
echo "{+block{MoaAB Liste}}" > /etc/privoxy/moaab.action
# mit awk (schneller und schoener)
cat hosts | awk '{print "."$2}' >> /etc/privoxy/moaab.action
# mit sed
cat hosts | cut -f2 | sed 's/^\(.*\)$/\.\1/g' >> /etc/privoxy/moaab.action
  • die Datei /etc/privoxy/mooab.action in die Datei /etc/privoxy/config eintragen und per Web-Browser testen

16 OpenVAS

16.1 OpenVAS über Docker installieren

  • Docker installieren (auf dem Laptop)
yum install docker
  • Docker starten
systemctl enable --now docker
  • OpenVAS laden und starten
docker run -d -p 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.

17 Host-to-Host IPSec VPN mit LibreSWAN

  • Installation von StrongSWAN auf Client und Server, Befehle je auf Client und Server ausführen
yum install libreswan

17.1 IPSec auf dem Client (Client-VM) einrichten

  • NSS-Datenbank initialisieren
ipsec initnss --nssdir /etc/ipsec.d
  • IPSEC Schlüssel auf dem Client erstellen
ipsec newhostkey --output /etc/ipsec.secrets
Generated RSA key pair with CKAID <ckaid> was stored in the NSS database
  • Schlüssel anzeigen (wird in der Konfiguration benötigt)
ipsec showhostkey --left --ckaid <ckaid>
        # rsakey AwEAAei9b
        leftrsasigkey=0sAwEA[...]sadas==

17.2 IPSec auf dem Server (Server-VM) einrichten

  • NSS-Datenbank initialisieren
ipsec initnss --nssdir /etc/ipsec.d
  • IPSEC Schlüssel auf dem Client erstellen
ipsec newhostkey --output /etc/ipsec.secrets
Generated RSA key pair with CKAID <ckaid> was stored in the NSS database
  • Schlüssel anzeigen (wird in der Konfiguration benötigt)
ipsec showhostkey --right --ckaid <ckaid>
        # rsakey AwEAAei9b
        rightrsasigkey=0sAwEA[...]sadas==

17.3 IPSec Konfigurationsdatei beider IPSec-Recher

  • Konfigurationsdatei für diese IPSec-Verbindung auf beiden Rechnern in der Datei /etc/ipsec.d/host-to-host.conf erstellen:
conn host-to-host
 left=172.16.x.2
 leftrsasigkey=0sAwEAAe[...]
 right=100.64.x.2
 authby=rsasig
 rightrsasigkey=0sAwEAA[...]
 #auto=start, ondemand, add
 auto=add
 ikev2=insist

17.4 IPSec starten

  • auf beiden Rechner IPSec starten und Tunnel host-to-host starten
ipsec start
ipsec auto --add host-to-host
ipsec auto --up host-to-host

17.5 IPSec testen

  • tcpdump auf dem Router darf nur ESP Pakete sehen, keine ICMP Pakete
tcpdump -v -i eth1 icmp   # <-- keine Pakete zu sehen
tcpdump -v -i eth1 esp    # <-- IPSec Pakete sehen
  • Ping vom Server zum Client
ping -c4 172.16.x.2
  • Ping von Client zum Server
ping -c4 100.64.x.2

17.6 IPSec Fehlersuche

  • IPSec Status
ipsec status
  • Verbindungsstatus anschauen
ipsec whack --trafficstatus
  • IPSec Verbindungsinformationen im Kernel
ip xfrm state
  • IPSec Verschlüsselungs-Policy im Kernel anzeigen (welche Verbindungen sind durch IPSec geschützt)
ip xfrm policy
  • ESP, IKEv1 und IKEv2 im tcpdump sehen
tcpdump -n esp or port 500 or port 4500 -i eth0 

17.7 Resourcen

18 TOR

18.0.1 TOR Installieren

  • auf dem Laptop arbeiten
  • In /etc/yum.repos.d/CentOS-Base.repo die Plus- und Extra-Repositories aktivieren (enable=1), EPEL-Release (Extra-Packages-for-RedHat-Linux) und TOR installieren
yum install epel-release
yum install tor
systemctl enable --now tor

18.0.2 TOR-Browser

  • den Tor-Browser von Tor-Projekt installieren ( http://www.torproject.org ) oder den Socksv5-Proxy im Browser auf Port 9050 einstellen

18.0.3 TOR-Onion-Services

  • Onion Hidden-Service auf Localhost Port 8000
$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
  • Service staren
python -m SimpleHTTPServer
  • den Onion-Namen herausfinden (Datei /var/lib/tor/hidden_service/hostname) und an einen der Teilnehmer weitergeben
  • einen Onion-Dienst ansprechen (per Socks-Proxy) aus einem Browser

18.1 Sicherheit

  • 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.

18.2 Onion-Dienst mit Client-Authentifizierung

Der Onion-Dienst, wie oben beschrieben, ist erreichbar für jeden Benutzer der den Onion-Namen kennt. Ein Onion-Name besteht derzeit aus 16 Zeichen (80 bit) und kann u.U. erraten werden. Um die Sicherheit des Onion-Dienstes noch weiter zu erhöhen, kann der Dienst mit einer Authentisierung versehen werden. Bei der Authentisierung bekommt jeder Client einen eigenen kryptografischen Schlüssel zugewiesen, und nur wenn dieser Schlüssel beim Verbindungsaufbau mit angegeben wird, ist der Onion-Dienst erreichbar (und sichtbar). Der Schlüssel ist ein Authentisierungs-Cookie aus 16 Bytes (Base64 kodiert) welcher zusätzlich zum Onion-Namen bekannt sein muss.

18.2.1 Authentisierung auf der Seite des Onion-Dienstes (Server)

Die Dienste-Authentisierung wird auf der Server-Seite mit der Konfigurationsdirektive HiddenServiceAuthorizeClient angeschaltet. Diese Direktive nimmt als Parameter den Authentisierungs-Modus (basic oder stealth) und eine per Komma getrennte Liste an Client-Namen. Diese Client-Namen sind nur beschreibener Natur und müssen nicht mit Hostnamen oder Domain-Namen übereinstimmen. Die Direktive gilt für den jeweils voher definierten Onion-Dienst:

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22
HiddenServiceAuthorizeClient stealth client1,client2,client3

Nach einem Neustart des Tor-Dienstes findet sich im Verzeichnis des Onion-Dienstes eine neue Datei mit dem Dateinamen client_keys. Diese Datei enthält die Authentisierungs-Cookies und privaten Schlüssel für jeden angegebenen Client-Rechner:

client-name client1
descriptor-cookie QJVF38CnraTrg8FaAHuvFw==
client-key
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDTcZOJO3Eh4GWva8L9I4MlabqAvujx6oCL3xso00NTX6zWNWZn
[...]
6rEwyC92BYs2rShFsGadG0ET6N6+j7uWNf18Ya+qikCl
-----END RSA PRIVATE KEY-----
client-name client2
descriptor-cookie m6Isl8df2gPV+MBDoYFNLw==
client-key
-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQC/OSyIWcTGD9oZK3vUqeTpSIJkpkJc670/c57iXo6a6L94VW/0
[...]
NFd2QdCnL87ay3gxjTx9APvGdDRf6VaMNaSurciq2Q==
-----END RSA PRIVATE KEY-----

In der Datei hostname im Verzeichnis des Onion-Dienstes befinden sich nun unterschiedliche Onion-Namen für die jeweiligen Clients, zusammen mit den Authentisierungs-Cookies:

iaopwbjmex2splr2.onion QJVF38CnraTrg8FaAHuvFx # client: client1
bdc5ujizach44dwm.onion m6Isl8df2gPV+MBDoYFNLx # client: client2
kura5sy7vsmi6ws6.onion wyThiRFLyqtsppBS0TDoHB # client: client3

Aus dieser Datei muss nun für jeden Client der Onion-Namen und der dazugehörige Cookie in die Konfiguration der Tor-Software auf den jeweiligen Clients kopiert werden.

18.2.2 Authentisierung auf der Client-Seite

Onion-Namen und Cookie werden auf Client-Seite mit der Direktive HidServAuth in die Konfigurationsdatei /etc/tor/torrc eingetragen:

HidServAuth  kura5sy7vsmi6ws6.onion wyThiRFLyqtsppBS0TDoHB # client: client3

Nach einem Neustart der Tor-Software auf dem Client sollte nun der Onion-Dienst von diesem Client aus sichtbar und benutzbar sein.

Ein Verbindungsaufbau zum Dienst ohne den Authentisierungs-Cookie bedingt einen Timeout:

# torify ssh -v kura5sy7vsmi6ws6.onion
OpenSSH_7.5p1, OpenSSL 1.1.0f-fips  25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for *
debug1: Connecting to kura5sy7vsmi6ws6.onion [127.42.42.0] port 22.
[Aug 03 22:26:45] ERROR torsocks[9052]: Connection timed out (in socks5_recv_connect_reply() at socks5.c:536)
debug1: connect to address 127.42.42.0 port 22: Connection timed out
ssh: connect to host kura5sy7vsmi6ws6.onion port 22: Connection timed out

Mit dem korrektem Cookie funktioniert der Verbindungsaufbau:

# torify ssh -v kura5sy7vsmi6ws6.onion
OpenSSH_7.5p1, OpenSSL 1.1.0f-fips  25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for *
debug1: Connecting to kura5sy7vsmi6ws6.onion [127.42.42.0] port 22.
debug1: Connection established.
[...]
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32
debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:UDnhiUeJdxYVlYJHM/cOmP4gh+a6jKO+dfYwH0J8fDc
The authenticity of host 'kura5sy7vsmi6ws6.onion (127.42.42.0)' can't be established.
ECDSA key fingerprint is SHA256:UDnhiUeJdxYVlYJHM/cOmP4gh+a6jKO+dfYwH0J8fDc.
ECDSA key fingerprint is MD5:8e:cc:bf:07:ee:bb:a7:9e:5f:77:f7:10:12:01:01:fa.
Are you sure you want to continue connecting (yes/no)? 

18.3 Vor- und Nachteile von Tor-Onion-Diensten

18.4 Vorteile

  • 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 (einfach) verschlüsselt (1024bit RSA)
  • Datenverkehr ist anonymisiert

18.5 Nachteile

  • Client muss die Tor-Software als Proxy benutzen
  • nur IPv4, kein IPv6 (daran wird gearbeitet)
  • hohe Latenz (Verzögerung) bei den Paketlaufzeiten
  • Tor-Verschlüsselung von 1024bit RSA nicht mehr zeitgemäß (auch daran wird im Tor-Projekt gearbeitet)

19 Anhang

19.1 Literaturliste

19.2 Referenzen:

19.2.1 Linux Zufallszahlen

19.2.2 SSL/TLS

19.2.3 Wireguard