BelWue stellt Proxy auf DNS um

#26

Hallo Wilfried,

hätte es auch gerne mit weniger Änderungen, da aber ohnehin demnächst
OPNsense als Firewall ansteht, lasse ich es mal so.
Bei OPNsense wäre wünschenswert, dass es wieder eine Möglichkeit der
Deaktivierung mittels der Schuko gibt, sonst geht das Gemecker wegen der
Filterung gewünschter Seiten los.

ich denke nicht, dass wir das bieten: den DNS Filter per SchuKo ab zu
schalten.
Es wird wieder einen URL Filter geben: der greift aber nicht bei https
Seiten: deswegen muss der DNS Filter her.
Es wird also zweistufig bleiben: DNS immer, URL Filter abschaltbar.

LG

Holger

#27

Hallo Holger,

OK, war mir nicht so bewusst, dass es zweistufig läuft.

Viele Grüße

Wilfried

#28

Hallo Wilfried,

mir ist nicht klar, was Du in oberen blauem Fenster geändert hast? Ich habe jetzt nur die unbound.conf geändert, es reicht aber nicht, er verwendet den BelWü-DNS nicht.

LG
Max

#29

ok, ich habs gefunden, Holgers Post. Alles auskommentieren…
Und der Filter geht, wenn auch der Boot lange dauert.

LG
Max

#30

Hallo Leute,
das mit dem DNS-Filter ist in Zeiten, in denen 90% des Verkehrs über HTTPS läuft, sicher der richtige Ansatz. Doch wie sieht es bei der BelWue-Lösung mit der Konfigurierbarkeit aus?

  • Kann ich für meine Schule bestimmte Seiten abweichend erlauben (white list) oder verbieten (black list)?
  • Kann ich einzelne Rechner im blauen Netz für alle Seiten freischalten, also auf einen “normalen” DNS umbiegen?
    LG
    Michael.
#31

Hallo Michael,

das mit dem DNS-Filter ist in Zeiten, in denen 90% des Verkehrs über
HTTPS läuft, sicher der richtige Ansatz. Doch wie sieht es bei der
BelWue-Lösung mit der Konfigurierbarkeit aus?

  • Kann ich für meine Schule bestimmte Seiten abweichend erlauben
    (white list) oder verbieten (black list)?

das weiß ich nicht.
Da müßtest du mal bei BelWü anrufen und fragen.

  • Kann ich einzelne Rechner im blauen Netz für alle Seiten
    freischalten, also auf einen “normalen” DNS umbiegen?

… nun ja: wenn du Port 53udp von Blau nach Rot erlaubst, dann kann in
Blau jeder den DNS verwenden, den er mag.
Welcher das ist kannst du optional vorgeben indem du im DHCP eben einen
anderen als den BelWü FilterDNS angibst.
Ungetestet, sollte aber klappen.

LG

Holger

#32

Hallo an alle,
Bei uns steht nun die Umstellung auf DNS Filterung an.
ich weiß, ich bin spät dran, aber man hat ja auch noch anderes zu tun…
Nach der Lektüre dieses Threads habe ich folgendes mitgenommen:

  • Der IP-Fire ist listenreich dazu zu bringen, den belwue-DNS zu akzeptieren, allein mit Eintragen dieses DNS ist es nur mit etwas Glück getan, sonst irgendwie an unbound rumfummeln, Anleitung ist oben.
  • Den Port 53 grün nach rot sperren, damit man keinen anderen DNS erreicht.
  • Kollegen per Knopfdruck zu ermöglichen, die Filterung abzuschalten ist nicht möglich, nur wer Zugang zur Firewall hat, kann die Firewallregel für Port 53 abschalten muss dann aber auch noch lokal einen anderen DNS eintragen.

Bitte korrigiert mich, wenn ich da was falsch verstanden habe. Vor allem Punkt 3 macht mir Sorgen. Es wäre ja noch akzeptabel, wenn ich tätig werden müsste, um für eine Hitlerreden-Recherche von Seminarkursschülern die Firewall zu ändern, aber dann noch erklären müssen, dass sie einen anderen DNS brauche - nöö, das ist nicht praktikabel. Hat da nicht jemand eine einfachere Lösung gefunden?

Danke für Vorschläge

#33

Hallo Uwe,

  • Kollegen per Knopfdruck zu ermöglichen, die Filterung abzuschalten
    ist nicht möglich, nur wer Zugang zur Firewall hat, kann die
    Firewallregel für Port 53 abschalten muss dann aber auch noch lokal
    einen anderen DNS eintragen.

… ich würde sagen: Filter Abschalten ist nicht mehr möglich: das ist zu
aufwändig.

Der Vorteil der DNS Filterung ist, dass sie auch https filtert.
Der NAchteil ist, dass es viel unschärfer ist.
Ich nehme also an,dass du eher keine “zuviel” gesperrten Seiten
bekommst: eher “zuwenig”…

LG

Holger

#34

Hallo Allerseits,

ich habe über die Herbstferien die Umstellung auf den “Jugendschutzfilter-DNS-Server” von Belwue vorgenommen

und habe jetzt große Probleme beim Zugriff auf Webseiten.

Hier die durchgeführten Schritte:

  1. DNSSEC im IP-Fire deaktiviert:

a) Im IP-Fire in der Datei /etc/init.d/unbound im Bereich test_nameservers alles auskommentiert bis auf "return 2“.

b) Im IP-Fire in der Datei /etc/unbound/unbound.conf die Optionen

val-permissive-mode: yes und

harden-dnssec-stripped:no

gesetzt

  1. Im IPFire mit setup den DNS-Server auf 129.143.4.3 gesetzt.

  2. IPFire neu gestartet.

  3. Namensauflösungen getestet mit nslookup und dig:

a) Client: geht ohne Probleme und schnell

b) Server: geht ebenfalls ohne Probleme und schnell

c) IPFire: geht nur teilweise, bricht teilweise mit einem Fehler ab und dauert sehr lange???

——————————————————————

Im Schulnetz wirkt sich das ebenfalls sehr seltsam aus:

  1. Wird eine Seite das erste Mal aufgerufen, dauert es ewig, bis sie geladen wird.

  2. Werden von einem Rechner aus ein paar Seiten gleichzeitig aufgerufen,

wird der Aufruf der Seiten teilweise abgebrochen.

Werden die Seiten GANZ LANGSAM nacheinander aufgerufen geht es.

  1. Der Up-und Download von Dateien ist aber gar kein Problem. (> 60 MBit in beide Richtungen)

  2. Ändere ich im Firefox-Profil die Proxy-Einstellungen zwischen „No Proxy“, „Automatisch Erkennen“, „vom System übernehmen“ und „Manuell festlegen“ geht es mal nur mit der einen und mal nur mit der anderen Einstellung,

mit der momentanen Tendenz, dass man „No Proxy“ einstellen muss, weil es sonst nicht geht.

Vor der Umstellung mit den oben beschriebenen Schritten war der Aufruf der Seiten zwar auch zu zäh für unsere gute Netzanbindung, was auch hier mit DNS-Problemen (DNSSEC) zu tun hatte,

aber die Seiten wurden zumindest zuverlässig überhaupt geöffnet.

——————————————————————

Der derzeitige Zustand ist nicht zumutbar, da sich die Seiten so unzuverlässig mal öffnen

und mal nicht und dann etwas später doch wieder.

Daher bin ich für jeden Hinweis oder Tipp dankbar.

——————————————————————

Zum System:

KVM-Virtualisierung auf Ubuntu-Server mit IPFire Core 110 und Linuxmuster.net-Server 6.2

(ja, an die höheren Cores habe ich mich erstmal nicht mehr herangetraut,

nachdem ich nur Ärger nach dem Update von 102 auf 110 hatte)

Schönen Gruß,

Sebastian

1 Like
#35

Hallo Sebastian,

Läuft der unbound-Server auf dem Ipfire? Um das zu prüfen auf der Konsole des IPFire folgenden Befehl absetzen:

/etc/init.d/unbound status

Grüße,
Sven

#36

Hallo Sven,
ja. Der Aufruf ergibt:
[root@ipfire ~]# /etc/init.d/unbound status
unbound is running with Process ID(s) 4442.
Schönen Gruß,
Sebastian

#37

Hallo Holger,
ich bin gerade auch dabei, den IPFire umzustellen. Hab das erstmal auf die lange Bank geschoben, muss jetzt jedoch ran.

Welche andere DNS hast du hier definiert?

Seit ihr hier weitergekommen? Wie seit ihr mit den grünen WLAN-Clients verfahren?

Grüße und Danke
Marcus

#38

Hallo Marcus,

Wollen wir das nicht, definieren wir einen anderen DNS für Blau (und
erlauben Port 53udp von Blau nach Rot). Das werde ich wohl erstmal so
machen.

Welche andere DNS hast du hier definiert?

den nicht filternden BelWü DNS: also 129.143.4.2 (aus dem Kopf …).

Bei den grünen WLAN Clients ist das nicht so einfach…
Das müssen wir testen (und noch ein wenig drüber nachdenken).

Seit ihr hier weitergekommen? Wie seit ihr mit den grünen WLAN-Clients
verfahren?

WLAN Clients in Grün sind keine BYOD Geräte sondern Schuleigene.
Diese bekommen die CA eingespielt.
Haben sie das noch nciht, dann wird die Sperrseite nicht angezeigt:
Filterung funktioniert aber.
Vorerst kann ich damit leben, bis alle die CA haben.

LG

Holger

#39

Hallo Holger,

den nicht filternden BelWü DNS: also 129.143.4.2 (aus dem Kopf …).

Vielen Dank für den hint.

WLAN Clients in Grün sind keine BYOD Geräte sondern Schuleigene.
Diese bekommen die CA eingespielt.
Haben sie das noch nciht, dann wird die Sperrseite nicht angezeigt:
Filterung funktioniert aber.
Vorerst kann ich damit leben, bis alle die CA haben.

Die CA würde ich über das Basisimage in den Firefox einpflegen. Hast du einen anderen Weg, wie du die CA deinen Clients vergibst?

LG

Marcus

#40

Hallo Marcus,

Die CA würde ich über das Basisimage in den Firefox einpflegen. Hast du
einen anderen Weg, wie du die CA deinen Clients vergibst?

so mache ich das auch.
Aber Vorsicht: bei mir sind die Firefox Profile im Home: ich muss also
bei allen usern im Home das Firefoxprofil löschen: sonst erhalten sie
nicht das neue.
Das könnte bei dir auch so sein.

LG

Holger

#41

Hallo Holger,

vielen Dank für den Hint. Das interessiert mich natürlich brennend. Löscht du alle Firefoxprofile von Hand oder scriptest du das?

LG

Marcus

#42

Ein herzliches Hallo an alle,

Bei mir tut der Webfilter auch nur die Hälfte: Direkter Aufruf der Seiten porn.com und sex.de werden gesperrt. Der Google-Porn-Bilder-Test leider nicht.

Ich habe auch alles so gemacht, wie Sebastian es geschrieben hat:

Allerdings habe ich beim Start von IPFire folgende Fehlermeldung:

Kann das damit zusammen hängen und wenn ja, wie bekomme ich die Fehlermeldung weg und den BelWü-Webfilter scharf?

Ich meine, im Moment bin ich schon zufrieden, dass er sperrt und die Sperrseiten gesichert anzeigt (Root-CA war wohl schon installiert).

Längerfristig finde ich, muss durch Medienpädagogik die Sensibilisierung her.

Aber für den Moment bräuchte ich einen scharfen Webfilter.

LG
Marcus

#43

Hallo zusammen,

ich habe jetzt auch auf die DNS-Filterung umgestellt und es scheint bis auf eine Kleinigkeit alles zu funktionieren: Wenn ich Firefox starte erscheint am oberen Bildschirmrand immer die Meldung "Sie müssen sich bei dem Netzwerk anmelden, um auf das Internet zugreifen zu können. " Wenn man die Meldung anklickt wird man auf eine (vom DNS gesperrte) Firefoxseite geleitet, ansonsten kann man die Meldung auch einfach wegblicken bzw. ignorieren, es funktioniert trotzdem alles. Ich habe schon versucht den FF zurückzusetzen, die Chronik zu löschen, die Proxyeinstellungen zu ändern, die Meldung erscheint immer wieder. Wo könnte ich noch suchen?

Viele Grüße
Friedrich

#44

Hallo zusammen,

Ich habe meinen Ipfire letzte Woche gezwungenermaßen neu installieren müssen, dabei habe ich die aktuellste Version, Ipfire 2.21 (x86_64) - Core Update 126, installiert.

Ich kann die Erfahrungen von Alex bestätigen! Bei mir hat die Umstellung auch sofort, ohne sonstige weitere Einstellungen (nichts an der Einstellung bzgl. DNSSEC geändert) geklappt.

VG Daniel

#45

Hi zusammen,

ich habe auch jetzt mal auf DNS-Belwue-Filter umgestellt und meinen IPFire-URL-Filter abgestellt um es zu testen.

In /etc/init.d/unbound reicht es ein return 2 einzufügen.

test_name_server() {
 return 2
 local ns=${1}

in /etc/unbound/unbound.conf hab ich auch

val-permissive-mode: yes
harden-dnssec-stripped:no

gesetzt und unbound restartet.
Zunächst werden schon offene Tabs nicht blockiert, auch mit STRG-Shift-R nicht. Man muss eine Zeit warten, dann wird man auch blockiert, oder man restartet den ipfire, dann muss man sowieso ne Zeit warten.

IPFire (auf KVM) hat sich aber extrem hart aufgehängt. destroy+reboot hat funktioniert mit 3 Min. Wartezeit bei “setting up default gateway”

Danach funktioniert auch, was ihr beschreibt.
WEnn man natürlich nicht google sondern duckduckgo nimmt, bringt einem der safe-search von google auch nichts. Die verlinkten seiten sind allerdings dann gesperrt.

Danach ein Update von Core 130 auf Core 131 und voila, der macht mir alle Einstellungen rückgängig, dann reboot:

  • warten bei “Setting up default gateway”
  • jetzt aber: “Ignoring broken upstream name server: 129.143.4.3” für 3-4 Minuten
  • dann: DNSSEC has been set to permissive mode
  • dann funktioniert der Jugendschutzfilter.

Fazit: keine Änderung am IPFire, bis auf den neuen DNS-Server eintragen und schon ist gut. 3-4 Minuten musste man so oder so warten.

VG, Tobias