IT Infrastruktur selber betreiben - wie und warum

Transkript

1 IT Infrastruktur selber betreiben - wie und warum Andrea Widmann aw@kalpha.de Selbständige werden durch ihre Berufsethik und den Gesetzgeber oft dazu gezwungen Daten, die berufsbezogen erhoben werden, besonderer Sorgfalt zukommen zu lassen. Daten: sollen gesichert werden. im Zugriff gehalten werden. Austausch mit anderen möglich sein. Seite 1

2 Zur Historie I Als Kind bereits den ersten Computerkontakt. Meine Datensammlung reicht bis nach dem Abitur zurück. Bisher noch keinen eigenen Datenverlust erlebt. Als Mailboxbetreiberin festgestellt, dass andere, wenn möglich, Mail- und Datenverkehr mitgelesen/mitgeschnitten haben. Was ging, wurde gemacht! Aus Hackererfahrung erkannt, wie leicht es sein kann an die Daten anderer zu kommen. Seite 2

3 Zur Historie II Eigentlich sind Dropbox, OneDrive & co. sind schon praktische Lösungen. Wenn andere Leute aber schon damals die Daten anderer abgeschnorchelt haben, warum sollten es die Betreiber der System heute nicht auch tun? Die Erfahrung lehrte: Wenn Daten über die IT-Systeme anderer Leute laufen, werden diese genutzt (von den "anderen Leuten"). Die kritische Frage lautet dabei jedoch inwieweit und zu welchen Zwecken diese Daten verwendet werden. Es gibt keine Sicherheit, dass nicht irgendwann die eigenen Daten von irgend jemand missbraucht werden. Seite 3

4 Nicht jeder will selbst Hand anlegen Viele gehen deutlich unbekümmerter mit dem IT-Thema um, als ich es tue. Das beruht sicherlich darauf, dass man nicht weiß wie man dem Abhilfe schaffen kann. Es kann nicht jedermanns Aufgabe sein, sich in die IT-Fragestellungen einzuarbeiten. Andere lassen dafür einen Fachmann ran. Dieser Vortrag ist für die gedacht, die trotzdem selbst Hand anlegen wollen und sich zutrauen eine entsprechende Lösung selbst zu realisieren. Seite 4

5 Meine Lösung I Webserver für meine statische Webseite. Warum statisch? Hacking von Content Management Systemen. Statische Webseiten lassen sich nahezu instant auf einen anderen Webserver umziehen. Owncloud-Server, jederzeit über das Internet erreichbar. Synchronisierung aller wichtigen Daten via Owncloud-Client. NAS (aka Samba-Server), ebenfalls auf Debian für private Daten und zur Lagerung nicht mehr dauerhaft benötigter Daten. Seite 5

6 Meine Lösung II Datensicherung: Rsync, gesteuert über Cronjob oder per Hand ausgelöst. Inkrementelle Sicherung separat ein Mal wöchentlich auf externe Festplatten. Vollständige Sicherung separat ein Mal monatlich. Ggf. Verschlüsselung via VeraCrypt und/oder PGP. Zugriff von außen via VPN, insbesondere, wenn ich in öffentlichen WLANs unterwegs bin. Seite 6

7 Hardware I Achtung, jetzt wird es schräg: Ursprünglich waren zwei Server X86erMaschinen. Laut & kostenintensiv. Nur kleine Lösung. Umstellung auf Raspberry Pi Kleinstcomputer: Raspberry Pi: Seite 7

8 Hardware II Zur Vermeidung von Problemen: Booten von externen USB-Festplatten. SD-Karte nicht mounten. kein NTFS, sondern EXT4 als Dateisystem. Tausch der Festplatten alle 18 Monate. Einsatz von smartmontools. Vor dem ersten produktiven Einsatz immer ein Image des aktuellen Systems ziehen. Mögliche Hitzeentwicklung im Serverraum beachten. Seite 8

9 Realisierung I Auf Wunsch eigene Domain. Auf Wunsch statische IP-Adresse. Ggf. DynDNS-Anbieter. Portweiterleitungen im Router: 80 für die HTTP-Seite 443 für die HTTPS-Seite Betriebssystem Debian Jessie aka Raspbian Jessie Lite. SSH in raspi-config aktivieren. Seite 9

10 Realisierung II - NAS Alle Server haben Samba installiert aufgrund einfacherem Datenaustausch. Nur einer wird bei mir als NAS genutzt. Meine smb.conf (zur Sicherheit modifiziert und gekürzt): [alle] comment = Alle User path = /wo_ich_auch_immer_meinen_mountpunkt_habe/data/sambashare/allusers valid users force group = users create mask = 0660 directory mask = 0771 writable = yes [homes] comment = Home Folders browseable = no valid users = %S writable = yes create mask = 0700 directory mask = 0700 Seite 10

11 Realisierung II NAS und Webserver Auf meinem Samba-Server läuft zugleich mein Webserver für die HTTP-Seiten. Nicht die SSL-abgesicherte HTTPS-Seite. Warum die Trennung? Wartungsarbeiten, Umleitung auf anderen Server. Hackingangriffe passieren zumeist automatisiert. Bei mir bisher immer auf Port 80 passiert. Genutzter Webserver: Apache Alternativ: Nginx Seite 11

12 Realisierung III - Webserver Meine modifizierte Beispieldateien für die /etc/apache2/sites-available/000-default.conf und die /etc/apache2/sites-available/default-ssl.conf befinden sich im Handout, das man sich bei mir per Mail anfordern kann. Seite 12

13 Realisierung III SSL-Zertifikat Ich verwende ein SSL-Zertifikat, das ich nicht selbst signiert habe. Es schreckt User ab, wenn sie die Meldung im Browser sehen. Macht einen unprofessionellen Eindruck. Mein kostenloses SSL-Zertifikat stammt von WoSign. Alternativ ginge auch Let's Encrypt. Seite 13

14 Realisierung III - Cloud Physisch ein anderer Server / Raspberry Pi. Selbe Grundinstallation (Raspbian etc.), aufgestockt auf das LAMP-Paket. LAMP: Linux, Apache, MySQL (bei mir MariaDB), PHP. Zusätzlich Owncloud. Kein MyPHP, da beliebtes Hackingziel, selbst wenn "versteckt". Datensicherung der DB automatisiert via mysqldump. Seite 14

15 Weiteres Zugriff von unterwegs via VPN, realisiert per FritzBox. Genutzte Tools: smartmontools fail2ban modifizierte.htaccess 6G-Firewall (weitere Anpassung der.htaccess) Rsync zur Datensicherung VeraCrypt PGP XMPP-Server (Prosody) Sprachkommunikationsserver (Murmur/Mumble) Seite 15