OPNsense Forum
International Forums => German - Deutsch => Topic started by: guest15032 on March 05, 2017, 12:21:52 pm
-
Hi zusammen,
ich habe auf meiner OPNsense den transparenten Web Proxy sowie dabei auch das Caching aktiviert. Der transparente Proxy ist nur für HTTP aktiviert. Soweit funktioniert auch alles ganz gut.
In Verbindung mit einigen Sperrlisten (ich habe z.B. die aus dem offiziellen Tutorial genommen) sind mir aber dann folgende Gedanken gekommen:
Den Proxy für TLS/SSL aktivieren, halte ich für einen Bruch der Sicherheit (as es ja auch tatsächlich ist, da ein eigenes Zertifikat genutzt wird). So lange ich dies also nicht aktiviere, sind auch sämtliche damit verbundenen Konfigurationen sinnlos, z.B. die Firewall Regeln für HTTPS (also das Blocken des Proxy Bypassing, usw.). Außerdem ist es in Folge dessen ja auch so, dass das Caching und die ACLs doch auch nur bei unverschlüsselten Verbindungen zum Tragen kommen.
Da ja inzwischen doch der Großteil aller "wichtigen" Seiten per TLS/SSL ausliefert, frage ich mich einfach ganz stumpf:
Welchen Sinn macht denn eine Konfiguration von ACLs und dem Caching, wenn ich sowieso auf einen transparenten HTTPS Proxy verzichte, aus Sicherheitsgründen? Ok, beim Caching ist das evtl. noch nicht so wichtig, es wird trotzdem ne Menge über HTTP gecached. Aber die ACL machen doch erst dann Sinn, wenn ich auch die Auslieferung über beide Protokolle über den Proxy schicke, oder verstehe ich das hier falsch?
Noch eine Frage an die Allgemeinheit: Wer von Euch hat denn einen HTTPS Proxy aktiv und hat damit ein gutes Gefühl?
Gruß
Chris
-
1. Es gibt immer noch genug Seiten, die HTTP only sind - leider auch Webshops, bei denen Passwörter und Bestellungen übertragen werden. Die kann man nach wie vor Cachen. Auch Updates kommen oft über HTTP, da deren Integrität über GPG-Signaturen sichergestellt ist (falls du eine übliche Linuxdistribution verwendest. Wenn du mehrere Hosts hast, kann das schon mal was bringen ;) Es sind ja nicht nur Webseiten, die HTTP verwenden, da HTTP heute auch ein "Trägerprotokoll" für andere Protokolle ist.
2. Du musst nicht zwangsweise die HTTPS-Verbindung unterbrechen, wenn du das nicht willst, kannst dann aber nur noch auf Basis von IP-Adressen und Hostnamen filtern (Stichwort SNI). Das Problem dabei ist, dass nur ein Bruchteil der Richtlinie geprüft werden kann und zum Beispiel Dateitypen (zum Beispiel ausführbare Dateien) nicht gesperrt werden können.
Ich breche HTTPS bei mir aus dem Grund auf, weil ich genau wissen will, was da Blödsinn treibt und mir auch den HTTP-Request anschauen können will (Debugging etc.). Man sieht auch welche Android Apps wohin nach Hause telefonieren und kann die Endpunkte gezielt sperren. So ein transparenter Proxy kann die Apps sauber halten (Adblocking) und Datenabfluss verhindern (Anti-Tracking).
3. Ich habe es in bestimmten Netzen im Einsatz, bei denen ich den Herstellern der Anwendungen nicht traue. Im LAN derzeit nicht. Meine Erfahrung zeigt, dass es nicht sonderlich einfach ist, das so einzurichten wie es passt, da es leider immer wieder Probleme gibt. Firefox unter Android verwendet bei mir nicht den Systemzertifikatspeicher -> funktioniert nicht; Google Apps muss man die Server durch lassen, weil die sonst aus irgendeinem Grund nicht funktionieren, ...
Vom Gefühl her würde ich sagen, dass die Sicherheit dadurch nicht gemindert wird, sofern keiner mein Root-Zertifikat klaut und damit selbst einen MitM platziert. Dafür kann ich meinen ganzen Traffic am Proxy/ICAP Server analysieren und weiß, was für Daten übertragen werden.
Das könnte insbesondere bei werbefinanzierten Apps zu interessanten Erkenntnissen führen.
-
Hey hey,
Im Grunde "brichst" du deine Sicherheit nicht, solange wie niemand an dein Root-Zertifikat kommt, welches du für den HTTPS-Proxy verwendest. Vielleicht noch als kleine Ergänzung um dir entweder die Angst vor dem HTTPS Proxy zu nehmen oder deine Paranoia gegenüber Antiviren Software anzutreiben:
SSL Interception wird bei fast jedem Antiviren Hersteller per Default bereits angewendet um HTTPS Traffic zu überprüfen. Dann schalte ich doch lieber den Software-Antivirus aus und nutze meine selbst gebastelte ICAP und HTTPS Proxy Lösung als Ersatz oder? :)
Schöne Grüße
Oxy
-
Moin,
das Thema SSL-Interception sehe ich generell als sehr kritisch an.
1. Ist so etwas für ein reines Sperren von Webseiten oder Kategorien gar nicht nötig (auch mit der OPNsense).
Wenn ich z.B. Facebook oder Twitter nicht erlauben möchte, kann ich das Sperren ohne den Traffic aufzubrechen und ggf. zu analysieren.
2. Informiert Ihr alle Nutzer Eures Netzwerks darüber, dass Ihr Sie ggf. belauscht!? Klar, wenn es nur ein privates Netz ist, mögt nur Ihr selbst davon betroffen sein. Aber schnell kann so etwas ja kritisch werden, wenn man z.B. ein Gästenetz anbietet. Ein guter Artikel dazu -> https://kowabit.de/der-firewall/
3. Auch führende Entwickler äußern sich grundsätzlich kritisch zu Techniken wie SSL-Interception -> https://www.heise.de/security/artikel/Ex-Firefox-Entwickler-raet-zur-De-Installation-von-AV-Software-3609009.html
Über die dahinterliegenden Gründe kann man sicherlich Diskutieren, aber vieles klingt für mich durchaus nachvollziehbar.
Für uns im Unternehmen hat das schlussendlich dazu geführt, dass wir SSL-Interception nach kurzer Testphase wieder deaktiviert haben. Dazu kam dann auch, dass diverse Anwendungen sehr wohl bemerken, dass die SSL-Verschlüsselung gebrochen wurde und entsprechend nicht mehr funktionieren (So sollte es auch sein!!!). Das Pflegen der Außnahmelisten war entsprechend aufwändig und führt das Ganze dann eh wieder ins Absurde.
Privat bzw. zu Hause ist das für mich eh kein Thema! Da weiß ich ja auf welchen Webseiten ich mich herumtreibe bzw. welches Apps ich nutze.
Gruß
Dirk
-
Guten Morgen,
@monstermania hat mir einiges schon vorweg genommen. ;)
Es gibt immer noch genug Seiten, die HTTP only sind -
Ja, da hast Du völlig recht. Insofern sehe ich das Caching da auch nicht als unnütz an.
da HTTP heute auch ein "Trägerprotokoll" für andere Protokolle ist.
Ja, auch hier Zustimmung. ;)
Ich breche HTTPS bei mir aus dem Grund auf, weil ich genau wissen will, was da Blödsinn treibt und mir auch den HTTP-Request anschauen können will (Debugging etc.). Man sieht auch welche Android Apps wohin nach Hause telefonieren und kann die Endpunkte gezielt sperren. So ein transparenter Proxy kann die Apps sauber halten (Adblocking) und Datenabfluss verhindern (Anti-Tracking).
Das ist aus reiner Informationssicht nachvollziehbar. Ich hatte zu diesem Grund vor einiger Zeit mal mit einem Proxy auf meinem Rechner rumgespielt, noch bevor ich die Firewall angeschafft hatte. Ich hatte den Datenverkehr über den Proxy geleitet um zu sehen, was Whatsapp und Co. da alles durchreichen. Allerdings ist das hier eben der Punkt: Einen Proxy temporär zu nutzen, um solche Verbindungen mal zu untersuchen, mache ich gerne. TLS/SSL Proxy dauerhaft auf der Firewall aktivieren, hinterlässt mir kein gutes Gefühl.
Vom Gefühl her würde ich sagen, dass die Sicherheit dadurch nicht gemindert wird, sofern keiner mein Root-Zertifikat klaut und damit selbst einen MitM platziert. Dafür kann ich meinen ganzen Traffic am Proxy/ICAP Server analysieren und weiß, was für Daten übertragen werden.
Auch das kann ich zwar nachvollziehen aber - für mich persönlich - nicht so ganz legitimieren. Ich sehe hier eben den Bruch im Sicherheitsprotokoll. Ganz unabhängig davon, dass ich ebenfalls festgestellt habe, dass diverse Software nicht mehr korrekt funktioniert (bei mir machte z.B. Chrome Probleme).
Im Grunde "brichst" du deine Sicherheit nicht, solange wie niemand an dein Root-Zertifikat kommt, welches du für den HTTPS-Proxy verwendest. Vielleicht noch als kleine Ergänzung um dir entweder die Angst vor dem HTTPS Proxy zu nehmen oder deine Paranoia gegenüber Antiviren Software anzutreiben:
SSL Interception wird bei fast jedem Antiviren Hersteller per Default bereits angewendet um HTTPS Traffic zu überprüfen. Dann schalte ich doch lieber den Software-Antivirus aus und nutze meine selbst gebastelte ICAP und HTTPS Proxy Lösung als Ersatz oder?
Genau das ist es, was mir im Kopf umher geht, und was monstermania auch gepostet hat: Diese Interception ist, laut diverser Fachleute (die ich für urteilsfähig halte) absolut falsch. Natürlich ist es klar, dass eine Untersuchung des Datenverkehrs nicht wirklich anders zu bewerkstelligen ist, vor allem wenn man auf ein Sicherheitsprodukt vertrauen möchte. Aber diese gängige Praxis reißt eben riesige Löcher in genau die Stelle, in die ich ja vertrauen möchte und sollte!
ich nutze seit Jahren keine Antiviren Software mehr (zumal mein OS das zum Großeil auch überflüssig macht) und verlasse mich auf meinen Sachverstand und meine Intuition. Kritische Dinge, wenn sie denn mal vorkommen, mache ich dann in einer VM, usw. Was ich in den letzten Wochen gelesen habe zu genau diesen Themen (Antivirus und TLS/SSL) macht mich nicht nur hellhörig sondern bestätigt auch mein Gefühl, das ich schon zuvor hatte.
1. Ist so etwas für ein reines Sperren von Webseiten oder Kategorien gar nicht nötig (auch mit der OPNsense).
Wenn ich z.B. Facebook oder Twitter nicht erlauben möchte, kann ich das Sperren ohne den Traffic aufzubrechen und ggf. zu analysieren.
Wie genau ist das gemeint? Worauf genau bezieht sich das (technisch)?
2. Informiert Ihr alle Nutzer Eures Netzwerks darüber, dass Ihr Sie ggf. belauscht!? Klar, wenn es nur ein privates Netz ist, mögt nur Ihr selbst davon betroffen sein. Aber schnell kann so etwas ja kritisch werden, wenn man z.B. ein Gästenetz anbietet. Ein guter Artikel dazu -> https://kowabit.de/der-firewall/
Den Artikel habe ich auch vor Augen und noch einige andere. Selbst wenn es nur das eigene Netz zu Hause ist, leidet hier ja eben schon die Funktionaliät diverser Software. Hab da z.B. auch diverse Zertifikatsfehler gesehen, usw.
3. Auch führende Entwickler äußern sich grundsätzlich kritisch zu Techniken wie SSL-Interception -> https://www.heise.de/security/artikel/Ex-Firefox-Entwickler-raet-zur-De-Installation-von-AV-Software-3609009.html
Über die dahinterliegenden Gründe kann man sicherlich Diskutieren, aber vieles klingt für mich durchaus nachvollziehbar.
Exakt. ich denke auch, dass es definitiv diskutabel ist. Aber runtergebrochen ist es, zumindest hier im Fokus auf AV Hersteller, doch gut nachvollziehbar, dass die Hersteller ihre Produkte den Bach runterfließen sehen und natürlich jede Kritik ablehnen. Dabei sind die technischen Punkte, also die tatsächlich problematischen bis kritischen Fehler in den TLS/SSL Interceptions, dermaßen gewichtig.
Ich stehe dem insgesamt sehr kritisch gegenüber und bin aktuell der Meinung, dass ich der Sicherheit in das Protokoll Vorzug gebe vor der "Annehmlichkeit", dass ich auch verschlüsselten Datenverkehr selbst unter Kontrolle habe. ich empfinde es irgendwie als absurd, die Verschlüsselung aufzuheben, um selbst dann doch wieder zu verschlüsseln, weil man den Datenverkehr an genau dieser Stelle untersuchen möchte. Aus Sicht der Neugier, um zu wissen, was da alles passiert, verstehe ich es vollkommen. Ein kleiner Teufelskreis im Moment...
-
Es ist durchaus legitim, TLS-Unterbrechung abzulehnen. Nur hat man genau dann das Problem, dass man damit wieder die Kontrolle über den Content verliert. Filterung auf Basis von Hostnamen ist ja trotzderm möglich. Das Problem ist dann aber, wenn es granular werden muss.
Nur so als Beispiel: Wenn eine Webseite example.com Werbung von example.net nachladen will und dazu erstmal https://example.net/check.js (https://example.net/check.js)
ladt und die Webseite damit damit nicht mehr geht, man aber https://example.net/ads.js (https://example.net/ads.js) sperren will, geht das mit hostbasierten Filtern nicht mehr, da diese Information bereits verschlüsselt übertragen wird.
Auch ein über ICAP angebundener Virenscanner würde nicht funktionieren, wenn TLS nicht terminiert wurde.
Vielleicht hilft aber das hier: In dem Fall hat man zwei TLS-Verbindungen. Wenn beide sicher sind, ist alles OK. Wenn der Server ein ungültiges Sicherheitszertifikat verwenden würde, würde der Proxy in OPNsense die Verbindung verweigern (der Client bekommt eine Fehlerseite angezeigt). Die Verbindung nach außen kann sogar sicherer sein, als die innen, wenn zum Beispiel bis zum Proxy TLS 1.0 gesprochen wird, und der Proxy nach außen dann eine mit TLS 1.2 gesicherte Verbindung aufbaut.
Was den Einsatz in Betrieben angeht: Hier muss klar gesagt werden, dass es hier durchaus zu Problemen mit gewissen Gesetzen in manchen Ländern geben kann (unter Auflagen erlaubt, generell verboten). Hier sollte aber ein Jurist zur Verfügung stehen, der um diese Fragen kümmern kann, damit diese Fragen geklärt sind.
Ich mache es bei mir zu Hause. Es sollten also nur meine Daten betroffen sein ;)
-
Was den Einsatz in Betrieben angeht: Hier muss klar gesagt werden, dass es hier durchaus zu Problemen mit gewissen Gesetzen in manchen Ländern geben kann (unter Auflagen erlaubt, generell verboten). Hier sollte aber ein Jurist zur Verfügung stehen, der um diese Fragen kümmern kann, damit diese Fragen geklärt sind.
Ich mache es bei mir zu Hause. Es sollten also nur meine Daten betroffen sein ;)
Eben. Und genau hier muss man unterscheiden. Bei mir auf Arbeit ist SSL-Interception NICHT erlaubt worden (juristisch). Zuhause frage ich meine Mitbewohner (Familie, Freunde, WG-Kumpels) ggf. schriftlich um Erlaubnis und kümmer mich dann halt darum den Traffic sauber zu halten. Man darf hier nicht vergessen, dass man selber ja nicht die NSA spielt oder einen "auf Google macht". Man analysiert ja nicht um herauszufinden, wie lustig der WG-Kumpel wieder sein Leben im Internet verbringt.
Zuhause läuft ganz klar entweder gar keine Antiviren Software (Ersatz durch ICAP Lösung) oder man schaltet HTTPS Untersuchung zu mindestens aus in der Antiviren Software.
Weiterhin wird SSL doch "nur" im internen Netz gebrochen eben genau für z.B. ICAP. Es ist ja nicht so, dass nach der OPNsense nach außen dann unverschlüsselt kommuniziert wird. (Oder irre ich mich?? :o ;D)
Genau das ist es, was mir im Kopf umher geht, und was monstermania auch gepostet hat: Diese Interception ist, laut diverser Fachleute (die ich für urteilsfähig halte) absolut falsch.
3. Auch führende Entwickler äußern sich grundsätzlich kritisch zu Techniken wie SSL-Interception -> https://www.heise.de/security/artikel/Ex-Firefox-Entwickler-raet-zur-De-Installation-von-AV-Software-3609009.html
Über die dahinterliegenden Gründe kann man sicherlich Diskutieren, aber vieles klingt für mich durchaus nachvollziehbar.
Das ist ja alles ganz richtig, jedoch ist man doch selber kein AV Hersteller. Die Kritik gegenüber den Antiviren Herstellern ist doch folgender: Die AV Vertreiber können deinen HTTPs Traffic mitlesen und verstehen, weil sie MITM spielen (meist ohne Wissen des Endkundens) jedoch eigentlich selbst völlig unsichere Software dafür bereitstellen, denen man für solch heikle Aktionen gar nicht genug vertrauen darf.
Nun vertrau ich doch mir selber viel mehr als irgend einem AV Hersteller.
Da brech ich doch lieber selber das Protokoll und habe unter Kontrolle was passiert, anstatt dem AV Hersteller das ohne mein Wissen zu überlassen? :)
Auch ein über ICAP angebundener Virenscanner würde nicht funktionieren, wenn TLS nicht terminiert wurde.
@fabian aber HTTP Traffic kann doch immer noch untersucht werden oder? HTTPS Traffic logischer Weise nicht, aber wenn man sich dafür entscheidet SSL zu vertrauen, will man das ja auch gar nicht.
Also als Beispiel: Ich nutze einen HTTP Proxy auf der OPNsense und nutze zusätzlich einen ICAP Server...
Wie wäre da die Vorgehensweise bei ICAP? HTTPS traffic ignorieren und nur HTTP Traffic untersuchen oder gibt es dort nur "entweder" "oder"?? Würde ICAP also in diesem Falle gar nicht funktionieren und Fehler ausspucken oder kann man ICAP so einrichten, dass HTTPS Traffic ignoriert wird? :)
-
Ein kurzer Gedankenanstoß noch zu SSL Termination auf "der anderen Seite" (also beim Client):
Wessen Proxy ist so eingestellt, dass er falsche, kaputte, unbekannte, unsaubere Zertifikate oder nicht vollständige Zertifikatsketten ablehnt? Wie bekomme ich als Client hinter dem Proxy mit, dass meine Verbindung zu "vielleicht-eine-bank.de" ein unsauberes Zertifikat retour liefert - da der Proxy die Verbindung öffnet (und ggf. das Zert annimmt, damit nicht so viele Fehler zum Client durchschlagen) und neu verschlüsselt, sieht für mich alles toll aus.
-> man nimmt dem Benutzer bzw. dessen Browser und sonstigen Tools durch re-encryption die Möglichkeit, selbst angemessen auf Probleme zu reagieren!
Anderes Beispiel: Zertifikatskette gebrochen oder ggf. nicht mehr sauber, Zertifikat als zurückgezogen gemeldet etc. Ist der Proxy genauso aktuell wie der Browser der sich automatisch updated? Hoffentlich, denn mein Browser lehnt z.B. Zertifikate von unsauberen CAs oder fehlerhaften Intermediates ab. Durch Re-encrypt sehe ich da nur meine 20 Jahre Eigenbau CA die erlaubt wird...
Da bin ich ebenso kritisch!
Grüße
-
Also als Beispiel: Ich nutze einen HTTP Proxy auf der OPNsense und nutze zusätzlich einen ICAP Server...
Wie wäre da die Vorgehensweise bei ICAP? HTTPS traffic ignorieren und nur HTTP Traffic untersuchen oder gibt es dort nur "entweder" "oder"?? Würde ICAP also in diesem Falle gar nicht funktionieren und Fehler ausspucken oder kann man ICAP so einrichten, dass HTTPS Traffic ignoriert wird? :)
Für die Konfiguration von ICAP ist es unerheblich, ob TLS unterbrochen wird oder nicht. Wenn der Traffic lesbares HTTP ist (darunter fällt auch aufgebrochenes HTTPS), wird wird es verarbeitet.
Wessen Proxy ist so eingestellt, dass er falsche, kaputte, unbekannte, unsaubere Zertifikate oder nicht vollständige Zertifikatsketten ablehnt? Wie bekomme ich als Client hinter dem Proxy mit, dass meine Verbindung zu "vielleicht-eine-bank.de" ein unsauberes Zertifikat retour liefert - da der Proxy die Verbindung öffnet (und ggf. das Zert annimmt, damit nicht so viele Fehler zum Client durchschlagen) und neu verschlüsselt, sieht für mich alles toll aus.
Squid (Proxy in OPNsense Blockiert in dem Fall den Zugriff komplett)
Anderes Beispiel: Zertifikatskette gebrochen oder ggf. nicht mehr sauber, Zertifikat als zurückgezogen gemeldet etc. Ist der Proxy genauso aktuell wie der Browser der sich automatisch updated?
Das hat nix mit Browser-Updates zu tun. Für das gibt es OCSP und CRLs.
Hoffentlich, denn mein Browser lehnt z.B. Zertifikate von unsauberen CAs oder fehlerhaften Intermediates ab.
Das kommt darauf an, welche Zertifikate im Trust-Store sind. Wenn ein intermediate-Zertifikat probleme macht, muss es von der darüberliegenden CA per CRL oder OCSP gesperrt werden. Damit hat sich das erledigt.
Sollte das nicht passieren, kann es sein, dass es die ausstellende CA bald nicht mehr gibt, da ihr dann recht schnell von Browser und Betriebssystemherstellern entzogen werden und sie damit keinen Cent mehr wert ist. Daher werden die sich hüten, falsche Zertifkate auszustellen und bei Bedarf nicht zu sperren. Ein Beispiel gibts hier: https://de.wikipedia.org/wiki/DigiNotar
-
Daher werden die sich hüten, falsche Zertifkate auszustellen und bei Bedarf nicht zu sperren. Ein Beispiel gibts hier:
Zu dem Satz sage ich nur (wiederholt): Symantec (und ihre unheilige Ehe mit Blue Coat). Wie oft wurden jetzt schon angebliche Demo, Test und sonstige Zerts von gültigen! CAs von Symantec unterschrieben die für Google und Co ausgestellt waren und absolut gültig waren? Zu Tests mit Laufzeiten von 3 Jahren und mehr? *hust hust*
Ich sehe das Zertifikat nicht mehr und habe also keine Chance sowas zu bemerken. Genauso wie HPKP und HSTS unterwandert werden.
-
Zu dem Satz sage ich nur (wiederholt): Symantec (und ihre unheilige Ehe mit Blue Coat). Wie oft wurden jetzt schon angebliche Demo, Test und sonstige Zerts von gültigen! CAs von Symantec unterschrieben die für Google und Co ausgestellt waren und absolut gültig waren? Zu Tests mit Laufzeiten von 3 Jahren und mehr? *hust hust*
Ich sehe das Zertifikat nicht mehr und habe also keine Chance sowas zu bemerken. Genauso wie HPKP und HSTS unterwandert werden.
Als ich das gelesen habe, habe ich dieses Zertifikat auf eine Blacklist gesetzt. Es sei dir dennoch freigestellt, Symantec aus dem Keystore zu verbannen.
In dem Fall hast du sogar einen Vorteil: machst du es auf dem Proxy, wird der effekt im ganzen Netzwerk sichtbar (keiner kann eine Webseite besuchen, deren Zertifikat von Symantec unterschrieben wurde).
-
Das hat mit freigestellt o.ä. einfach nichts zu tun. :) Du möchtest die Lösung, sei dir gegönnt. Ich mag sie nicht, denn man sieht so etwas schlicht nicht mehr. Bzw. einer muss sich dauerhaft damit beschäftigen, das kontrollieren und umsetzen, damit es für alle sauber funktioniert. Macht er das nicht, haben alle gleichzeitig ein Problem weil sie durch den Proxy immer heile Welt vorgegaukelt bekommen. Und genau aus dem Grund sind die Experten gegen SSL Interception auf Client Seite, weil immer Dinge verschleiert werden, die damit gar nicht erst beim Client ankommen, sondern vorher schon umgebaut werden. Man kann sich also nicht darauf verlassen.
Das kann nett sein, wenn man es zur Kontrolle nutzt (dannn hat man aber eh noch diverse Bestimmungen am Hals zwecks Datenschutz) oder zur Sicherung/Sicherheit. Nur wessen Sicherheit wird denn erhöht? Meine Clients bzw. Nutzer sind sicherer, wenn sie selbst aufgeklärt sind was diverse Szenarien anrichten und was das bedeutet, anstatt ihnen beim Surfen einfach vorzugaukeln alles wäre schick. Wenn ich bei jeder Seite einfach immer meine Dummy-CA sehe, wie soll man da jemand beibringen mal ein Zertifikat mit Argwohn zu beäugen, dass vielleicht nur vorgibt korrekt zu sein bzw. das einfach nicht passt (Stichwort Phishing). Das Problem bei sowas ist, dass Leute davon ausgehen dass das dann immer so ist und auch so sorglos agieren, wenn sie nicht mehr hinter dieser Proxy-"geschützten" Lösung sind. Und das halte ich persönlich für grenzwertig und eher schutzsenkend als -fördernd.
But I agree to disagree on this topic :)
-
Phishing-Seiten haben ein gültiges Sicherheitszertifikat, weil sie eine eigene Domain haben und sich diese auch überprüfen lassen können. Da hilft das also genau gar nichts.
User überprüfen TLS-Zertifikate? Muss irgendwie an mir vorbei gegangen sein, denn meiner Erfahrung nach wird immer dann reagiert, wenn es zu einer Warnung kommt. Hauptsache der Browser zeigt an, dass alles passt...
Außerdem funktioniert es nicht mehr, dass irgendwer zum Beispiel Rechnung.js aus einer E-Mail auf macht und die dann https://example.com/ransomware.exe runter lädt und ausführt und du dich infolge dessen um die Organisation des nächten Restore des Backups kümmern darfst.
Aber das ist natürlich ein ganz anderes Thema.
-
Phishing-Seiten haben ein gültiges Sicherheitszertifikat, weil sie eine eigene Domain haben und sich diese auch überprüfen lassen können. Da hilft das also genau gar nichts.
Doch, weil ich das Zertifikat _selbst_ prüfen kann. Bank: EV Zertifikat mit grünem Balken. Phisher: meist / immer irgendein Guffel-DV Zertifikat. Kein grüner Balken bei der Bank? Oh wait!
-> funktioniert nicht mehr, ich kann nicht mehr in das Zert reinsehen für wen es ausgestellt wurde. Und bei allem größer Class 2 steht da nicht nur "domain.tld" sondern eine komplette Anschrift die validiert sein muss.
User überprüfen TLS-Zertifikate? Muss irgendwie an mir vorbei gegangen sein, denn meiner Erfahrung nach wird immer dann reagiert, wenn es zu einer Warnung kommt. Hauptsache der Browser zeigt an, dass alles passt...
Nennt sich Erziehung, Aufklärung und Training. Wenn jemand bei einer Bank oder anderen Seite, bei der EV bspw. Pflicht ist keinen grünen Balken sieht, werden sie mißtrauisch. Sowas kann man lernen oder informierend weiter geben.
Außerdem funktioniert es nicht mehr, dass irgendwer zum Beispiel Rechnung.js aus einer E-Mail auf macht und die dann https://example.com/ransomware.exe runter lädt und ausführt und du dich infolge dessen um die Organisation des nächten Restore des Backups kümmern darfst.
Wird meist eh nur auf Windows Systemen funktionieren und dort ist in den meisten Umgebungen ein halbwegs ordentlicher Virenschutz (leider) immer noch Pflicht. Und ich bezweifle mal ganz stark, dass ein eingeschleifter ClamAV mit seiner recht schwachen Scan-Leistung da besser sein sollte als ein richtiger Client der mehrfach am Tag mit Signaturen versorgt wird. Und hier rede ich von einem reinen Virenscanner. Keinem Internet Security Suite Mistding, das sich selbst wieder wie eine Krake in Verbindungen eingräbt wo sie nichts zu suchen hat (Ja, ich schaue zu dir, Kaspersky, Symantec und Co.).
Bleibt jedoch der Punkt, dass der Proxy an der Stelle meines Erachtens mehr Ärger bringt als er potentiell beseitigen soll plus Schutzmechanismen bzw. Prüfmechanismen aushebelt, die anders besser funktionieren. Wie sich ein Proxy bspw. auf HPKP und HSTS auswirkt, hast du bspw. nicht beachtet in deinen Ausführungen. Diese werden - zumindest laut meinem letzten Stand - nicht weitergereicht. Ein Client bekommt also bspw. nicht mit, dass eine Verbindung auf SSL gefordert wird und HTTP gar nicht mehr erlaubt ist. Und sendet somit evtl. Daten versehentlich im Klartext.
Aber wie schon gesagt, ich sehe das anders und lege das nur dar, warum. Ich zwinge niemand meine Meinung auf. TLS ist problematisch genug ordentlich durch-/umzusetzen (schon auf Hostingseite), sich dann noch mit Proxies dazwischen in den Fuß zu schießen halte ich eben für kontraproduktiv. Und wir als Hoster haben schon oft genug gehört "dass die Seite auf dem Server nicht funktioniert", was dann eben doch wieder ein Proxy Problem in der eigenen Hoheit war. Insofern kenne ich beide Seite zu genüge ;)
-
User überprüfen TLS-Zertifikate? Muss irgendwie an mir vorbei gegangen sein, denn meiner Erfahrung nach wird immer dann reagiert, wenn es zu einer Warnung kommt. Hauptsache der Browser zeigt an, dass alles passt...
Nennt sich Erziehung, Aufklärung und Training.
Da kann ich aus meiner Perspektive nur ganz pessimistisch sagen: Es ist zu spät für Aufklärung und Training.
Nicht unbedingt, weil die Leute nicht wissen wollen worauf sie achten sollen, sondern ganz einfach weil sie nicht länger verstehen wie das Gerät funktioniert was vor ihnen sitzt. Es kommt logischer Weise immer auf den Menschen an, dem man etwas erzählt, aber wenn man den.. naja "etwas unbeholfenen" 90% Social Media nutzenden Mob als Beispiel betrachtet dann ist schlicht und ergreifend "Training" verschwendete Zeit.
Menschen werden nämlich Träge wenn man ihnen jeden Tag sagt, worauf sie zu achten haben und worauf nicht.
Praktisches Beispiel hierbei: Freunde und Familie.
An vielen Ecken hört man auch "Taskmanager? Ich will die Kiste nutzen und nicht auseinander nehmen." oder "Netzwerk funktioniert doch mit dem Gerät von der xyz-Firma. Gegen die NSA können wir eh nichts machen also brauch ich mich auch nicht um Datenschutz oder Sicherheit kümmern".....
MAC und iOS boomen nicht ohne Grund. Und das bestimmt nicht, weil sie besonders konfigurierfreudig sind. ;D
Locky ist seit 2015 bekannt und die Art der phishing Mails haben sich auch bei den anderen Trojaner Abkömmlingen nicht geändert. Trotzdem versagt der normale Nutzer, wenn durch frühere Hacks halt eine Email zusammen geschustert wird mit personalisierten Daten die tatsächlich stimmen.
Da kann man noch so viel trainieren und erzählen. Da ist Hopfen und Malz halt verloren. :P
Und jetzt mal ganz ehrlich, frag doch mal deinen Nachbarn was "HTTPS" bedeutet?
Da erkennt niemand irgendwas, auch wenn das Bank Logo geändert wird. "Das war dann halt so gewollt von der Bank".
Wird meist eh nur auf Windows Systemen funktionieren und dort ist in den meisten Umgebungen ein halbwegs ordentlicher Virenschutz (leider) immer noch Pflicht. Und ich bezweifle mal ganz stark, dass ein eingeschleifter ClamAV mit seiner recht schwachen Scan-Leistung da besser sein sollte als ein richtiger Client der mehrfach am Tag mit Signaturen versorgt wird.
Naja die Kombi macht es doch. Das steht sogar in der OPNsense Doku so drinne. Hehe ;) 8)
Siehe:
The Anti Virus Engine can protect you against malicious websites and infected file downloads, it does not protect the local clients. Therefore it is always a good idea to install a client based solution as well to protect against other forms of infection such as through emails or usb stick.
EDIT: Mich hier aber bitte nicht falsch verstehen. Ich bin auf jeden Fall gegen das Aufbrechen von SSL im Betrieb oder in der Firma, jedoch finde ich die Idee für Zuhause "ganz interessant", würde mir den Stress aber nicht machen wollen. :)
-
Außerdem funktioniert es nicht mehr, dass irgendwer zum Beispiel Rechnung.js aus einer E-Mail auf macht und die dann https://example.com/ransomware.exe runter lädt und ausführt und du dich infolge dessen um die Organisation des nächten Restore des Backups kümmern darfst.
Sorry, aber wenn es so weit kommt, dass solche Mails Deine User erreichen, hat man als Admin echt schlechte Arbeit geleistet!
Emails mit solchen Inhalten sollte ein Mailgateway herausfiltern bevor es überhaupt die User erreicht.
Und zum Thema 'ransomware.exe' sei nur angemerkt, dass es unter Windows schon seit Jahren wirksame Mittel dagegen gibt, dass sich irgendwelche obskuren Dateien einfach so durch einen User ausführen lassen. Stichwort "Software Restriction Policies".
Ich behaupte mal, wenn ein Netzwerkadmin sein Handwerk versteht, verliert auch Ransomware viel von seinem Schrecken. So schlecht ist Windows da gar nicht aufgestellt.
Man muss halt nur die gebotenen Möglichkeiten nutzen!
-
"Software Restriction Policies".
Das funktioniert aber nur auf Arbeit oder wie willst du der alten Dame von gegenüber erklären wie sie sich diese Policies einrichtet? "Ransomware.exe" funktioniert, weil die Menschen über die Jahre aufgehört haben kritisch über ihr Handwerk nachzudenken (Gebrauch des Rechners) und nur noch konsumieren.
Selbst den Windows Script Host kriegt nicht jeder deaktiviert, trotz diverser Anleitungen im Netz.
Das Verständnis fehlt leider... :(
-
Sorry, aber wenn es so weit kommt, dass solche Mails Deine User erreichen, hat man als Admin echt schlechte Arbeit geleistet!
Emails mit solchen Inhalten sollte ein Mailgateway herausfiltern bevor es überhaupt die User erreicht.
Das stimmt so nicht. Es gibt Dienste, die darauf abzielen, Malware so zu packen, dass die NICHT erkannt wird. Das kann dann zum Beispiel auch ein Makro in einem Office-Dokument sein, das auf eine art unleserlich gemacht wurde, dass es Schutzprogramme erst in x Stunden schaffen, dieses zu erkennen. In der Zeit kann die Malware sich ausbreiten und nach dieser Zeit gibt es ein neues Sample. In dem Fall kann immerhin schlimmeres verhindert werden und man kann der Quelle nachgehen und den Fall untersuchen.
-
@Oxy
Finde ich persönlich zu pessimistisch und wir/ich reden hier nicht nur von der Generation Ü40/50. Und die Social Media Generation (Y) ist durchaus in der Lage sowas wahrzunehmen. Wenn sie darauf keinen Bock hat ist das was anderes ;) Aber alle als hoffnungsloses Pack abzustempeln finde ich schon einen extrem pessimistischen Ausblick.
EDIT: Mich hier aber bitte nicht falsch verstehen. Ich bin auf jeden Fall gegen das Aufbrechen von SSL im Betrieb oder in der Firma, jedoch finde ich die Idee für Zuhause "ganz interessant", würde mir den Stress aber nicht machen wollen. :)
Gerade zu Hause finde ich es eben nicht wirklich sinnvoll, denn da ist Aufklärung das wirkungsvollste Mittel und da auch - zumindest in meinem Umfeld bislang - nie vergeudet gewesen. Selbst meine Eltern die auf Ende 60 zugehen, sind in der Lage zu bemerken, dass mit der Bankseite oder dem Zertifikat was nicht stimmt :) Würde man denen das unterschieben, würden sie genau nix bemerken. Das Zert/den Balken nehmen sie wahr. Dass da ein Logo kleiner oder unschärfer ist - meh, das fällt nicht auf. Und inzwischen ist in den aktuellen Browsergenerationen der Klick aufs Schloß etc. so viel einfacher, an die Infos zum Zert zu kommen.
Grüße
-
Das stimmt so nicht. Es gibt Dienste, die darauf abzielen, Malware so zu packen, dass die NICHT erkannt wird. Das kann dann zum Beispiel auch ein Makro in einem Office-Dokument sein, das auf eine art unleserlich gemacht wurde, dass es Schutzprogramme erst in x Stunden schaffen, dieses zu erkennen. In der Zeit kann die Malware sich ausbreiten und nach dieser Zeit gibt es ein neues Sample. In dem Fall kann immerhin schlimmeres verhindert werden und man kann der Quelle nachgehen und den Fall untersuchen.
Ja und!?
1. Muss der User immer noch die Ausführung von Makros aktivieren. Ein reines öffnen des Dokuments reicht nicht.
2. Warum muss man überhaupt die alten Office Dateitypen annehmen (doc,xls, usw.)!? Oder warum überhaupt Office-Dokumente annehmen!?
3. Da wären wir wieder bei den 'SRP'. ;) Mir doch egal, was für eine Datei da heruntergeladen wird oder zusammengebaut wird. Aus dem Userprofil heraus dürfen schlichtweg keine Dateien gestartet werden...
@Oxy
Ja, was willst Du uns damit sagen!?
Wenn ich Auto fahren will brauche ich einen Führerschein, sonst darf ich nicht auf die Straße. Und trotzdem gibt es genug Leute, die täglich eindeutig nachweisen, dass Sie nicht verantwortungsbewusst mit Ihrem Auto umgehen.
Gegen Dummheit ist nun einmal kein Kraut gewachsen. Da hilft dann auch keine Firewall/Proxy/Anti-Virensoftware!
Da hilft nur Schmerz (Verlust)! Egal ob nun durch Geld und oder Daten um einen Lerneffekt zu erreichen.
Für mich ist eine Firewall ein Werkzeug um meine Daten zu schützen bzw. zu kontrollieren was aus meinem Netz wohin connecten will und nicht um eine DAU-Lösung für das Netzwerk zu schaffen.
-
Ja und!?
1. Muss der User immer noch die Ausführung von Makros aktivieren. Ein reines öffnen des Dokuments reicht nicht.
2. Warum muss man überhaupt die alten Office Dateitypen annehmen (doc,xls, usw.)!? Oder warum überhaupt Office-Dokumente annehmen!?
3. Da wären wir wieder bei den 'SRP'. ;) Mir doch egal, was für eine Datei da heruntergeladen wird oder zusammengebaut wird. Aus dem Userprofil heraus dürfen schlichtweg keine Dateien gestartet werden...
1. passiert oft genug wie die Nachrichten in der Vergangenheit gezeigt haben und sollte hier nur als Platzhalter dienen
2.
1. im Geschäftlichen Umfeld gibt es hoffentlich Kunden und da weiß man je nach Geschäftsfeld nie, was die schicken
2. Personalabteilungen: Bewerbungen als Word-Anhänge
-
Das war meine rein subjektive Meinung anhand meines sozialen Umfelds und den Leuten mit denen ich so über das Weltgeschehen quatsche.
Finde ich persönlich zu pessimistisch und wir/ich reden hier nicht nur von der Generation Ü40/50. Und die Social Media Generation (Y) ist durchaus in der Lage sowas wahrzunehmen. Wenn sie darauf keinen Bock hat ist das was anderes ;) Aber alle als hoffnungsloses Pack abzustempeln finde ich schon einen extrem pessimistischen Ausblick.
Genau da liegt das Problem. Die Ü40 würden gern noch, können aber nicht mehr und die U40 haben schlicht und ergreifend keinen bock. Wenn ich meine Eltern im Netz sensibilisieren möchte treffe ich da auf Ohren die tatsächlich interessiert sind, jedoch nicht mehr alles verstehen. Bei der U40 Generation trifft man (meiner Meinung nach) mittlerweile leider Gottes auf völliges Desinteresse, solange Chips und Bier bereit steht und Counterstrike funktioniert.
Da hilft nur Schmerz (Verlust)! Egal ob nun durch Geld und oder Daten um einen Lerneffekt zu erreichen.
Ich krieg Gänsehaut bei den vielen Yahoo Mail Accounts die noch von Kumpels und Bekannten benutzt werden oder wenn man mit einem ungepatchtem alten Android System in öffentliche WLANs ein und aus geht. Mit den Ü40 lässt sich da bei weiten mehr Erreichen in Punkto Sensibilisierung. Lerneffekt ist hier trotzdem Fehlanzeige oder? :)
Ja, was willst Du uns damit sagen!?
Ich will damit sagen, dass ich mehr und mehr das Gefühl bekomme, dass der Großteil der Bevölkerung sich der IT (In diesem Fall Security und besonders Privacy) mehr und mehr abwendet und geschlagen gibt und zu absoluten Anwendern, bzw. Konsumenten für Social Media, Gaming und Streaming mutieren.
Früher konnte ich mich mit jedem X-beliebigen Menschen über Windows und die Hardware eines Rechners unterhalten. Jetzt kann man froh sein, wenn der gegenüber grundlegendes Interesse an einem technischen Gespräch zeigt und nicht sofort abschaltet, wenns nich Cool und flippig is das Thema.
Ich lass mich lieber eines besseren Belehren und diskutiere daher gerne und viel, um neue Blickwinkel auf ein Problem zu erhalten.
Mir macht einfach die "Reise" etwas angst und ich hoffe, hoffe wirklich @JeGr dass ich hier zu pessimistisch denke und am Ende nicht recht behalte. *Daumen Drück* 8)
Sooo genug rumgejammert. ::) Das hat ja auch gar nichts mehr mit der eigentlichen Frage zu tun, von daher war das jetzt hier dazu auch alles. SSL Interception werde ich Zuhause für mich allein privat mal umsetzen einfach aus Jucks und Laune um zu schauen, was mich erwartet. Anderen Mitbewohnern oder dem Konzern würde ich es jedoch abraten. Mein Fazit also aus dieser Diskussion. :)
Lasst euch nicht ärgern
Schöne Grüße
Oxy ;D
-
Ich würde auch sagen, das Topic sollte als geschlossen angesehen werden - ich frage mal an, ob der Thread ab hier gesperrt werden kann.
-
Topic bleibt offen. Wir kommen auch so aus miteinander. :)
Grüsse
Franco
-
Jo, zum eigentlichen Thema sind wohl alle Argumente ausgetauscht. ;)
Ich glaube aber sowieso, dass es sich hier eigentlich um die falsche Plattform für eine solche Diskussion handelt. Alle die hier aktiv sind, haben sich ja schon mit dem Thema Netzwerksicherheit auseinander gesetzt bzw. tun das gerade!
Grundsätzlich kann ich aber den Eindruck bestätigen, dass die Generation der 'Silversurfer' bewusster im Umgang mit Internet & Co. ist, vor allem was den Sicherheitsaspekt angeht. Da wird dann aber auch leichter eingesehen, dass man mit der technischen Entwicklung nicht mehr Schritt halten kann und nutzt dann gern Geräte von Apple. Die werden dann immerhin durch den Hersteller gepflegt.
Die jüngere Klientel geht da m.E. eher unbedarft heran. Wobei ich aber das Gefühl habe, dass wir in Deutschland eh schon mehr auf Datensicherheit achten als Andere.
Wir haben in der Firma häufiger mit Chinesen zu tun, und die gehen zumeist sehr leichtfertig mit Datensicherheit um. Evtl. auch weil man in China ohnehin ständiger Überwachung unterliegt. Die Chinesen, sind teilweise echt verwirrt, wenn man Ihnen die Gründe erklärt, warum z.B. kein WeChat auf den Firmensmartphones erlaubt ist.
Und immer schön darüber nachdenken, dass westliche Sicherheitsbehörden auch nur Abhören, spionieren und ggf. SSL-Verschlüsselungen 'brechen' um die Bürger zu schützen! ;D
Fangen wir also zu unserem eigenen 'Schutz' schon mal damit an unsere internen Netzwerke zu bespitzeln.
-
Hi,
nachdem hier ja fleißig diskutiert wurde, wärme ich meinen Thread noch mal kurz auf, da ich noch zum Topic Fragen habe.
Auch hier wieder eine Verständnisfrage:
Wie genau blockt ihr denn, mit eurem Proxy, entsprechende Domains/IPs? Es gibt ja im Backend, auf der Proxy Seite, zwei entsprechende Funktionsansichten (zumindest verstehe ich diese als zusammenhängend):
- Forward Proxy -> Access Control List
- Remote Access Control Lists
Hier meine ich gelesen zu haben, dass die Listen auch bei der Evaluierung der ACL Rechte gemerged werden. Was für mich bedeutet, dass beide Listen/Funktionen dafür da sind, um z.B. unliebsame IPs/Hosts zu blocken.
Wie genau setzt ihr das also um? Habt Ihr da mal Beispiele, wie Ihr z.B. Werbung blockt? Ich habe da im Moment beispielsweise diese Block Liste für Werbung: http://pgl.yoyo.org/adservers/serverlist.php?hostformat=nohtml
Und weiterhin frage ich mich, wie genau wertet OPNsense diese Liste aus, und wie funktioniert das Blocken der Hosts? Werden diese dann (wie ich es von Linux bisher kenne) einfach als Hosteinträge in die lokale Hosts Datei geschrieben und dann z.B. auf localhost (127.0.0.1) oder auf die 0.0.0.0 umgeleitet?
Und als letzte Frage: Wie und wo testet Ihr Eure Blocklisten? Ich habe dafür bisher auch kaum gute Testseiten gefunden und ich bilde mir ein, dass sonstige Werbung auf gängigen Seiten (z.B. heise.de) nocht von der Firewall geblockt wird, wobei da natürlich zu ermitteln wäre, ob die Werbeprovider in den Blocklisten sind (was ich noch nicht getan habe). ;)
Gruß
Chris
-
Wie genau blockt ihr denn, mit eurem Proxy, entsprechende Domains/IPs? Es gibt ja im Backend, auf der Proxy Seite, zwei entsprechende Funktionsansichten (zumindest verstehe ich diese als zusammenhängend):
- Forward Proxy -> Access Control List
- Remote Access Control Lists
Hier meine ich gelesen zu haben, dass die Listen auch bei der Evaluierung der ACL Rechte gemerged werden. Was für mich bedeutet, dass beide Listen/Funktionen dafür da sind, um z.B. unliebsame IPs/Hosts zu blocken.
Die listen werden hintereinander angewendet. Zuerst die Forward Proxy-Regeln, dann die Remote-Regeln. Welche zuerst dran kommt, ist maximal eine Performancefrage.
Wie genau setzt ihr das also um? Habt Ihr da mal Beispiele, wie Ihr z.B. Werbung blockt? Ich habe da im Moment beispielsweise diese Block Liste für Werbung: http://pgl.yoyo.org/adservers/serverlist.php?hostformat=nohtml (http://pgl.yoyo.org/adservers/serverlist.php?hostformat=nohtml)
Und weiterhin frage ich mich, wie genau wertet OPNsense diese Liste aus, und wie funktioniert das Blocken der Hosts? Werden diese dann (wie ich es von Linux bisher kenne) einfach als Hosteinträge in die lokale Hosts Datei geschrieben und dann z.B. auf localhost (127.0.0.1) oder auf die 0.0.0.0 umgeleitet?
Ich halte das lieber möglichst sicher (doppelt hält besser). Ich sperre sowohl im DNS (alle Namen werden entsprechend auf 0.0.0.0 aufgelöst) als auch im Proxy (Remote ACL). Ich verwende für mein privates Gerät die Shalla Liste (Anmerkung: Kostenlos für Privatnutzer). Die Datei /etc/hosts würde nicht viel brigen, da diese nur für das eigene Gerät gilt. Daher sind die DNS-Namen bei mir im DNS Resolver gesperrt.
Und als letzte Frage: Wie und wo testet Ihr Eure Blocklisten? Ich habe dafür bisher auch kaum gute Testseiten gefunden und ich bilde mir ein, dass sonstige Werbung auf gängigen Seiten (z.B. heise.de) nocht von der Firewall geblockt wird, wobei da natürlich zu ermitteln wäre, ob die Werbeprovider in den Blocklisten sind (was ich noch nicht getan habe). ;)
Gesperrt können über Hostnamen nur die externen Werbedienstleister werden. Von den Seitenbetreibern selbst ausgespielte Werbung kann, wenn überhaupt, nur über die volle URL von Squid blockiert werden. Wenn man dann noch Werbung, die vom Webseitenbetreiber selbst ausgespielt wird und nicht leicht erkennbar ist, sperren will, braucht man einen ICAP-Service, der diese gezeilt entfernt. Das wird aber üblicherweise nicht gemacht und geht sogar über den Funktionsumfang üblicher Adblocker im Browser hinaus.
-
Hi fabian,
Ich halte das lieber möglichst sicher (doppelt hält besser). Ich sperre sowohl im DNS (alle Namen werden entsprechend auf 0.0.0.0 aufgelöst) als auch im Proxy (Remote ACL). Ich verwende für mein privates Gerät die Shalla Liste (Anmerkung: Kostenlos für Privatnutzer). Die Datei /etc/hosts würde nicht viel brigen, da diese nur für das eigene Gerät gilt. Daher sind die DNS-Namen bei mir im DNS Resolver gesperrt.
Ok, Danke. Das beantwortet dann auch teils meine Frage (denn darauf bezog sich das mit der Hosts Datei). Ich meinte in meinem Beitrag damit, ob die OPNsense das in eine eigene Hosts Datei schreibt, also eine auf der Firewall. Aber das hilft mir schon sehr weiter.
Dazu muss ich dann noch direkt weiter fragen, da Du vom DNS Resolver sprichst. Auf meiner Firewall ist ja der DNS Forwarder momentan aktiv (was glaube ich ja Default ist, damit DNS überhaupt funktioniert). Der benutzt ja die DNS Server, die ich in den General Settings eingetragen habe. Wenn ich jetzt den DNS Resolver auch aktiviere, welchen Vorteil habe ich dann davon? Denn auf der Seite mit den Resolver Einstellungen heißt es ja:
If the DNS Resolver is enabled, the DHCP service (if enabled) will automatically serve the LAN IP address as a DNS server to DHCP clients so they will use the DNS Resolver. If Forwarding, is enabled, the DNS Resolver will use the DNS servers entered in System: General setup or those obtained via DHCP or PPP on WAN if the "Allow DNS server list to be overridden by DHCP/PPP on WAN" is checked.
Auf der Seite mit dem bereits aktiven Forwarder heißt es:
If the DNS forwarder is enabled, the DHCP service (if enabled) will automatically serve the LAN IP address as a DNS server to DHCP clients so they will use the forwarder. The DNS forwarder will use the DNS servers entered in System: General setup or those obtained via DHCP or PPP on WAN if the "Allow DNS server list to be overridden by DHCP/PPP on WAN" is checked. If you don't use that option (or if you use a static IP address on WAN), you must manually specify at least one DNS server on the System: General setup page.
Also im Endeffekt verwendet der Resolver ja dann trotzdem den Forwarder? Was bringt dann der Resolver? Als DNS Server habe ich ja jetzt schon mit dem Forwarder die IP meines jeweiligen Interfaces (LAN/WLAN), daran wird sich mit dem Resolver dann ja auch nichts ändern. Oder ist der Resolver nur genau für diesen Fall jetzt sinnvoll, damit man eigene Block Listen einpflegen kann, die dann aufgelöst werden, bevor der Forwarder den Request an die jeweiligen DNS Server weiterschickt?
Und nochmal fürs Verständnis: Stören sich dann beide Funktionen nicht? Denn bei beiden Modulen heisst es ja, dass der DHCP Service die IP des Interfaces als DNS Server ausliefert, so dass der DHCP Client dann entsprechend den Forwarder oder den Resolver nutzt. Wie wird das denn dann entschieden? Da gibt es dann vermutlich eine feste Reihenfolge, also z.B.:
DHCP Client -> Resolver -> Forwarder -> DNS Server ?
Hoffe es ist verständlich, was ich meine.
Da ich in der OPNSense Doku nicht wirklich viel dazu finde, welche Einstellungen empfiehlst Du für jeweils den DNS Forwarder und Resolver? Da gibt es ja einige Optionen, die ich nicht alle einwandfrei verstehe (und die auch alle bisher nicht aktiviert sind).
Das Blocken auf DNS Resolver Seite, würde dann in etwa so laufen wie hier angedeutet: https://devinstechblog.com/block-ads-with-dns-in-opnsense/ ?
Gesperrt können über Hostnamen nur die externen Werbedienstleister werden. Von den Seitenbetreibern selbst ausgespielte Werbung kann, wenn überhaupt, nur über die volle URL von Squid blockiert werden. Wenn man dann noch Werbung, die vom Webseitenbetreiber selbst ausgespielt wird und nicht leicht erkennbar ist, sperren will, braucht man einen ICAP-Service, der diese gezeilt entfernt. Das wird aber üblicherweise nicht gemacht und geht sogar über den Funktionsumfang üblicher Adblocker im Browser hinaus.
Ja, das schließt sich dann wieder an das an, was ich oben geschrieben habe. Danke schön. :)
Gruß
Chris
-
Ich habe das Skript leicht anpassen müssen, weil es unter Umständen nicht funktioniert. Bei mir war /var eine RAM-Disk und daher ist die Datei beim Booten immer weg gewesen. Ich habe die Datei also wo anders hin gespeichert. Außerdem musste ich die line endings mit dos2unix konvertieren, da es sonst nicht lief.
Zum Thema DNS:
Der forwarder leitet die Anfrage des Clients, wenn er selber keinen Eintrag hat, an den nächsten DNS-Server weiter (außer, wenn der Eintrag schom im Cache ist). Er kann aber die Namen nicht selber auflösen. Das muss ein Resolver machen. Wenn du den Forwarder verwendest, betreibt also jemand anderer den Resolver für dich (üblicherweise dein Provider, Google (8.8.8.8, 8.8.4.4) oder irgend eine Organisation).
Da beide den gleichen Port verwenden, musst du selber entscheiden, ob du den Forwarder oder den Resolver verwenden willst. In den meisten Fällen ist das Geschmacksache.
-
Hi fabian,
Danke.
Ich führe das Thema DNS in einem separaten Thread weiter, da mich das dann doch mehr beschäftigt: https://forum.opnsense.org/index.php?topic=4823.0
Gruß
Chris
-
Zur Diskussion, die hier bezüglich TLS/SSL Aufbrechung geführt wurde, noch eine sehr aktuelle Ergänzung, siehe den Heise Artikel hier: https://www.heise.de/newsticker/meldung/US-CERT-warnt-vor-HTTPS-Inspektion-3660610.html
Gruß
Chris
-
Hatte ich auch grade gelesen. Wär mal interessant das von Zuhause zu testen mit der dort angegebenen Webseite.
Hier auf Arbeit scheint alles i.O. zu sein. :)
Am Ende kommt es dann also auf die Implementation an.
Heißt: Weißt du nicht zu 120% was du tust, lass es lieber.
Auf jeden Fall ne schöne Erkenntnis, auch im Bezug auf Antiviren Software.
-
Heißt: Weißt du nicht zu 120% was du tust, lass es lieber.
Mir würde es schon reichen, wenn ich immer 100%ig wüsste was ich genau tue! ;)
Gerade im Firewallbereich sehe ich mich aber nur als ambitionierten Amateur frei nach dem Motto "my english is not the yellow from the egg but it goes". ;D
Aber den Artikel fand ich auch erwähnenswert. Bestärkt mich nur darin auch weiterhin auf SSL-Interception zu verzichten.
-
War nur um zu bekräftigen wie wichtig dieses Thema dann doch ist. ;D
-
Schaut ganz so aus, als müssten wir hier beim Proxy nachbessern...
-
Und erledigt: https://github.com/opnsense/core/pull/1498/files
Scheinbar prüft LibreSSL die CRL nicht - wie ich das ausbessern kann, weiß ich nicht. Das wäre eigentlich Aufgabe der TLS-Bibliothek.
-
Außer dem Artikel von heise kann ich dazu noch empfehlen:
https://www.linkedin.com/pulse/9-reasons-intercept-https-marnix-dekker
sowie Kris' Blog
http://blog.koehntopp.info/index.php/1280-10-reasons-not-to-do-https-interception/