Datensparsamkeit, eigener RevProxy, https-Zertifikate, böses Internet

Themen, die in keine andere Kategorie passen

Moderator: Co-Administratoren

Antworten
Familienvater
Beiträge: 7151
Registriert: 31.12.2006, 15:18
System: Alternative CCU (auf Basis OCCU)
Wohnort: Rhein-Main
Danksagung erhalten: 34 Mal

Datensparsamkeit, eigener RevProxy, https-Zertifikate, böses Internet

Beitrag von Familienvater » 29.12.2019, 17:20

Moin,

sicherlich nutzen einige von Euch einen Reverse-Proxy mit Authentifizierung als "Gateway" von der weiten Welt in die eigenen vier Wände.
Weil wir um unsere Daten besorgt sind, nutzen wir zu recht HTTPS, wenn wir von unterwegs nach Hause surfen wollen, und damit es gleich und von überall "Grün" wird, nutzen wir kostenlose Zertifikate von Let's Encrypt. Damit unbefugte "nichts" zu sehen bekommen, haben wir sichere Benutzernamen und lange Passwörter für die Authentifizierung am Reverse-Proxy, für jedes Interne Ziel ggf. sogar eigene Zugangsdaten, das selbst bei einem Leak erstmal nur ein Ziel erreichbar ist.
Dabei geben wir aber evtl. durch falsche/schlechte Konfiguration ungewollt einiges an interessanten Daten an potentielle Angreifer bzw. deren Suchmaschinen raus, was einigen nicht klar sein dürfte.

Hintergrund:
Natürlich habe ich ein VPN-Zugang zu meinem Netzwerk (und das ist auch der wahrscheinlich sicherste Zugang), aber VPN mal eben schnell, von einem "fremden" Rechner usw, ist nicht wirklich praktikabel, der Reverse-Proxy ist da wesentlich praktischer, um mal eben schnell von Schwagers Rechner beim Familienkaffee zu Hause was zu machen, oder das Gratis-WLAN im Hotel/Ausland erlaubt kein VPN, nur https..
Ab dem Enthusiasten reicht auch theoretisch die max. eine verfügbare IPv4 nicht mehr aus, um sich einfach auf verschiedene Rechner zu Hause "durchzuverbinden", also werden per DynDns ggf. mehrere verschiedene Hostnamen, oder sogar per Wildcard alles unterhalb von myhome.dyndns.xyz als "Ziel" nutzbar gemacht.
Da ein Wildcard-SSL-Zertifikat für die meisten von uns wahrscheinlich schwierig zu bekommen ist (man muss auf den Nameserver für die eigene (sub)Domain dazu per API zugreifen können, um entsprechende Challanges zu ermöglichen), war bis vor kurzem mein Weg, das ganze halt über ein "MultiHost"-Zertifikat (SAN=Subject Alternative Name, Aliase) zu machen. Geht schnell, ist wenig Aufwand, und tut es eigentlich.
Bis dann die Einschläge kommen... Mein Rechner-Zoo hinter dem ReverseProxy ist (hoffentlich) öffentlich nirgendwo in normalen Suchmaschinen wie Google zum Bespidern eingetragen, also kommen eigentlich erstmal nur IP-scannende "Bots" vorbei. Die bekommen aber bei jedem Zugriff auf den https-Port natürlich "ungefragt" das große Zertifikat mit n-Hostnamen für die es gültig ist präsentiert, beispielsweise ccu.myhome.dyndns.xyz, iobroker.myhome.dyndns.xyz, nextcloud.myhome.dyndns.xyz, openhab.myhome.dyndns.xyz usw. Und irgendwann habe ich im Log des Reverse-Proxy gesehen, kommen da nicht nur Anfragen für die IP (als Hostname) rein, sondern gezielt Anfragen nach z.B. meiner Nextcloud-Instanz, aus den USA, aus China, von "überall". Klar, ich "brülle" ja meine Rechnernamen im Zertifikat nach draußen, war nur eine Frage der Zeit, bis die Bots sich das zu nutze machen. Und es gibt gewisse "Dienste", die kann/will ich nicht hinter der Authentifizierung des ReverseProxy verstecken, da muss man direkt drauf zugreifen können, nextcloud ist z.B. so ein "Ding". Da hoffe ich einfach, das ich das Systems durch tägliche Updates "sicher" genug halte, so das keine Löcher da sind (ich habe auch schlecht geschlafen, als auf einmal von nextcry berichtet wurde).
Irgendwann hatte ich schonmal den Bad-Bot Blocker (https://github.com/mitchellkrogza/nginx ... ot-blocker) auf dem RevProxy eingerichtet, aber auch der verhindert nur, das ein Bad Bot mehr Inhalt bekommt, das Zertifikat bekommt der Bad Bot trotzdem, und damit Hostnamen für potentielle Angriffsziele.
Nach dem ich mich mehr damit beschäftigt habe, habe ich was von SNI gelesen (nein, nicht Siemens-Nixdorf), Server Name Indication. Ein Mechanismus, der sowieso bei den meisten Browsern seit Jahren Aktiv ist, und den "anzufragenden Hostnamen" bereits in der ersten TLS-Anfrage an den https-Server mit schickt (allerdings im Klartext, aber das macht der Browser wenn er es kann sowieso, aber wirklich nur der FQDN-Hostname), damit kann der entsprechend Konfigurierte ReverseProxy (oder auch Webserver) das passende Zertifikat zu der Anfrage nutzen, und damit dann die TLS-Verhandlung durchführen.
Ich habe jetzt also meinen Reverse-Proxy mal wieder umkonfiguriert, und für jedes Weiterleitungsziel (Hostname, z.B. ccu.myhome.dyndns.xyz) ein eigenes Zertifikat bei Let's Encrypt erstellt. Außerdem für die Default-Instanz vom Reverse-Proxy, die genutzt wird, wenn kein passender Server-Konfig-Block gefunden wird, habe ich ein Selbst-Signiertes Zertifikat erstellt, mit allerhand wüsten Worten drin, aber garantiert keinerlei nützlichen Informationen, und genau dieses selbstsignierte Zertifikat bekommt nun jeder präsentiert, der nicht weiß, wohin er will. Fragt jemand z.B. nur nach dem IP-Hostnamen, bekommt er keinerlei Details zu anderen real existierenden Hostnamen des Systems, und nginx dankt entsprechend konfiguriert auch für die Anfrage direkt mit einem return 444 (kommentarlos die Verbindung beenden).
Es gibt neben dem Spider für die "böse" Suchmaschine, deren Name hier nicht genannt werden soll, auch jedemenge andere "böse" Spider, die alle gefundenen Daten in einem großen Data-Warehouse zusammenführen, und das ganze auch noch gegen mäßige Gebühr für bis zu 6 Monate rückwirkend durchsuchbar machen (ich meine jetzt nicht die NSA). Damit ist es möglich, im Idealfall zu einer IPv4-Adresse auch noch nach Tagen zusätzliche Infos zu bekommen, welche Hostnamen waren im Zertifikat usw. Und damit wird ggf. eine IP-Adresse zu einem Namen, und damit "jagbar".

Wer also "datensparsamst" im Internet präsent sein möchte, sollte sich mal darüber einen Kopf machen, und seine RevProxy-Logs anschauen.
Jemand, der nur eine CCU betreibt, der braucht auch kein großes Besteck, aber um meinen Rechner-Zoo besser im überblick zu haben, nutze ich inzwischen z.B. Graylog (bei normalem Hausgebrauch in unserer Größenordnung gibt es die Lizenz kostenlos), da schicken bei mir alle Maschinen ihr Syslog hin, und da wird es entsprechend meiner Regeln aufbereitet, und so brauche ich nicht mehr n-Logfiles auf 5 Rechnern sichten, ich habe eine entsprechende Ansicht erstellt, die nach entsprechender Konfiguration auch noch die IPs gleich per GeoLocation verortet, und das ganze auf einer Weltkarte visualisiert, sieht dand z.B. so aus

Woher kommen die Anfragen auf meinem Reverse-Proxy der letzten 30 Tage:
2019-12-29_11h04_05.png
Teilweise sperre ich inzwischen auch IPs oder sogar ganze Netze in meinem Router, wenn mir da zuviele Anfragen von im Log auftauchen. Hilft ggf. auch nur im Nachhinein, vorher wurde mein Mailserver schon mit 3000 Anfragen in 15 min. gequält und die Gegenseite hat auf Granit gebissen, ob da jemals wieder was von kommt, weiß ich auch nicht, andererseits sehe ich, das bestimmt 50 Anfragen pro Tag direkt vom Router schon "beantwortet" werden, ohne das die es jemals wieder bis zum RevProxy oder Mailserver schaffen.

Mit ein paar Zeilen in der nginx-Rev-Proxy-Config wird z.B. auch mein Nextcloud-Server von 23 Uhr bis 7 Uhr morgens "unerreichbar", und man bekommt da nur eine "Down for Maintenance"-Seite vom RevProxy angezeigt, in der Zeit braucht hoffentlich niemand was von meinem Server, aber nachts kommen immer die bösen Spider :-)

Testet Eure Konfig, nutzt öffentliche Prüftools für Eure SSL-Konfig (https://www.ssllabs.com/ssltest/, Häkchen nicht vergessen bei 'Do not show the results on the boards'), nutzt für Eure Tests z.B. auch Opera mit seiner kostenlosen VPN-Funktion, um Eure Systeme "von Außen" zu sehen, damit kann man wunderbar testen, welche Zertifikate einem "Anfrager" präsentiert werden, und kann auf den eigenen URLs rumsurfen, ob auch wirklich überall das Authentifikationsfenster kommt, und nicht doch versehentlich Inhalt.

Natürlich nicht vergessen:
Nutzt sichere Passwörter, und idealerweise überall ein anderes Passwort, denn es wird der Tag kommen, an dem auch ein WebServer mit Euren ungehashten Daten "Inkontinent" wird...
Die CCU gehört immer noch nicht per PortForwading ins Internet, nur per VPN oder "gescheit Konfiguriertem" ReverseProxy, und die vom Internet erreichbaren Systeme müssen Up-To-Date gehalten werden, und natürlich sollte man idealerweise mehr Ahnung haben als nur Google-Copy-Paste!
Nutzt öffentlich verfügbare "Port-Scanner" (z.B. https://www.heise.de/security/dienste/p ... ?scanart=1), um Eure Router-Konfig zu testen (ging vor Wochen durch die Presse: Fehlerhafte Telekom-Router-Firmware hat nicht nur Port 443 eingehend weitergeleitet, sondern gleich 440-449, da war dann auch der File-Server vom Doktor plötzlich im Internet)

Auf das das kommende Jahrzehnt besser wird :-)
Der Familienvater


gzi
Beiträge: 450
Registriert: 12.01.2015, 23:37
System: CCU
Hat sich bedankt: 15 Mal
Danksagung erhalten: 14 Mal

Re: Datensparsamkeit, eigener RevProxy, https-Zertifikate, böses Internet

Beitrag von gzi » 09.01.2020, 22:14

@Familienvater: Finde es gut, dass Du das Thema aufgreifst! ich verstehe aber nicht, warum Du mehrere DNS Namen brauchst und warum ccu.myhome.dyndns.xyz bei dir ein WeiterleitungsZIEL ist?

Mein Router hat EINEN DNS Namen , der Proxy läuft im (W)LAN und leitet unterschiedliche Ports, die im Router alle auf den Proxy gemappt sind, auf unterschiedliche Server im LAN - darunter die CCU - weiter. Der Proxy braucht nur ein Zertifikat. Im Proxy läuft fail2ban damit es Angreifer nicht gar zu leicht haben.

MFA wär noch optimal, aber den Google Authenticator mag ich nicht und was anderes, was man mit wenig Aufwand unter Linux nutzen könnte, hab ich noch nicht gefunden.

gzi
Lichtsteuerung, Heizungssteuerung, Überwachung (Feuer, Wasser, Einbruch, Stromausfall, Heizungsausfall, Wetter, Kamera), Alarmierung (optisch, akustisch, mail, SMS, voice call) - CCU, diverse HM- und HMIP Aktoren und Sensoren, Rauchmeldeanlage, UPS, GSM-Alarmwähler, Zugriff aus dem Internet via HTTPS und htdigest authentication, kein Datenkraken-Interface (Google, Amazon, China-Cloud, BND, NSA...) - HomeMatic Sicherheits-Kompendium - Checkliste für Auswahl von IP Kameras - Vergleich aktueller HomeMatic Zentralen - und alle Antworten für das gesamte Universum und den Rest

Familienvater
Beiträge: 7151
Registriert: 31.12.2006, 15:18
System: Alternative CCU (auf Basis OCCU)
Wohnort: Rhein-Main
Danksagung erhalten: 34 Mal

Re: Datensparsamkeit, eigener RevProxy, https-Zertifikate, böses Internet

Beitrag von Familienvater » 10.01.2020, 15:18

Hi,
gzi hat geschrieben:
09.01.2020, 22:14
ich verstehe aber nicht, warum Du mehrere DNS Namen brauchst
...
Mein Router hat EINEN DNS Namen , der Proxy läuft im (W)LAN und leitet unterschiedliche Ports, die im Router alle auf den Proxy gemappt sind, auf unterschiedliche Server im LAN - darunter die CCU - weiter.
Weil man ggf. in einem gratis Hotel-WLAN z.B. keinen Connect auf https://xyz.mydns.xxx:1234 machen kann, die erlauben ausgehend nur Port 80 und Port 443, und dann ist man mit seinem Latein ganz schnell am Ende.

Und da ich min. 2 offiziell von außen erreichbare "Dienste" anbieten will/muss, die ggf. auch nur mit Standard-Ports funktionieren (oder Konfigurationsorgien benötigen), finde ich es angenehmer, wenn ich eben per SNI direkt "durchwählen" kann.

Es ist inzwischen auch ruhiger geworden, ob es nur an den Einzel-Zertifikaten liegt, kann ich nicht sagen, auf jeden Fall habe ich "massiv" weniger direkte Anfragen nach allen möglichen Hostnamen, weil PortScaner beim ersten Mal nur noch mein selbst generiertes/signiertes Zertifikat zu sehen bekommen. Ich habe aber inzwischen auch radikal im Router Firewall-Regeln integriert, die "unendlich" viele "angeblich gute" Scanner-IPs blocken, einfach weil sich censys, shadowserver, ipip, binaryedge, netsystemsresearch, rapid7, netcraft, intrinsec, cloudsystemnetworks, internet_census usw. quasi die Klinke in die Hand gegeben haben, und jeder von diesen "gutartigen" Diensten täglich anklingelt, um seine Datenbanken aktuell zu halten und anderen die Ergebnisse gegen Gebühr zur Vverfügung zu stellen. Das war ein bisschen Arbeit, die zu sperrenden Netzblöcke rauszufinden, weil nur die wenigsten offiziell ihre Scan-IP-Ranges zum Blocken rausrücken, aber wenn die oft genug da waren, hat man genügend Futter, um einen komplettes Netz per reverse DNS in Hostnamen aufzulösen, die Ergebnisse zu filtern, und Firewall-Regeln draus zu machen. Das hilft nicht gegen "dynamische Eintagsfliegen", aber es beruhigt mich in gewisser Weise, das praktisch nur noch Scans auf die IP als Hostname durchkommen, und die kann ich nur verhindern, indem ich den Stecker komplett ziehen würde.

Anbei noch mal ein Screenshot von allem, was so beim Portscannen erwischt bzw. vom IP-Filter geblockt wurde, das sind nur 24h!
2020-01-10_15h12_45.png
Der Familienvater

Antworten

Zurück zu „OffTopic“