BelWue stellt Proxy auf DNS um

amu · 26. August 2018 um 11:08

Hallo Holger,

danke für den Hinweis mit DNSSEC.

Ich hatte natürlich auch die Meldung

Die habe ich aber erstmal ignoriert, weil die mit den alten BelWü-Servern auch schon kam, die Namensauflösung aber trotzdem immer funktioniert hat (über welchen externen Nameserver auch immer das dann lief, ist mir nicht klar…)

Viele Grüße

Andreas

wilfried · 28. August 2018 um 12:21

Hallo Holger,

laut Belwü werden wir uns DNSSEC bei 129.143.4.3 wohl verabschieden müssen.
Zitat aus einer Antwortmail:
“Bei unserem Jugendschutz-DNS-Server liegt es leider in der Natur eines DNS-Filters, dass er DNS-Antworten fälschen muss, und daher kann er nicht mit DNSSEC arbeiten.”

Nun gibt es auf der angeführten Seite mehrere Möglichkeiten, um DNSSEC zu deaktivieren. Welche Lösung ist zu bevorzugen?

Viele Grüße

Wilfried

baumhof · 28. August 2018 um 13:29

Hallo Wilfried,

ich hab das so gemacht, wie Dominik es beschrieben hat:

In der /etc/init.d/unbound (auf IPFire)
alles im Bereich test_nameservers auskommentiert, außer einer Zeile mit
return=2

[code]
test_name_server() {
local ns=${1}
local args

# Return codes:
# 0	DNSSEC validating
# 1	Error: unreachable, etc.
# 2	DNSSEC aware
# 3	NOT DNSSEC-aware

aukommentiert HIB August 2018

# Exit when the server is not reachable

ns_is_online ${ns} || return 1

	return=2

# Determine the maximum edns buffer size that works

local edns_buffer_size=$(ns_determine_edns_buffer_size ${ns})

if [ -n “${edns_buffer_size}” ]; then

args="${args} +bufsize=${edns_buffer_size}"

fi

amu · 28. August 2018 um 21:26

Hallo Holger,

da fehlt wohl noch das schließende [/code]

Viele Grüße

Andreas

baumhof · 28. August 2018 um 22:00

Hallo Andreas,

da fehlt wohl noch das schließende [/code]

hoppla: ich hab meinen Post nicht noch mal angeschaut…
Seltsam: in meiner Mail ist das [/code] durchaus drin.
Mal sehen, wo das abbricht …
Ich schicke meinen Post gleich nochmal.

LG

Holger

baumhof · 28. August 2018 um 22:03

Jetzt nochmal:

Hallo Wilfried,

ich hab das so gemacht, wie Dominik es beschrieben hat:

In der /etc/init.d/unbound (auf IPFire)
alles im Bereich test_nameservers auskommentiert, außer einer Zeile mit
return=2

test_name_server() {
	local ns=${1}
	local args

# Return codes:
# 0	DNSSEC validating
# 1	Error: unreachable, etc.
# 2	DNSSEC aware
# 3	NOT DNSSEC-aware
# aukommentiert HIB August 2018
# Exit when the server is not reachable
#ns_is_online ${ns} || return 1
		return=2

# Determine the maximum edns buffer size that works
#local edns_buffer_size=$(ns_determine_edns_buffer_size ${ns})
#if [ -n "${edns_buffer_size}" ]; then
#	args="${args} +bufsize=${edns_buffer_size}"
#fi
#local errors
#for rr in DNSKEY DS RRSIG; do
#if ! ns_forwards_${rr} ${ns} ${args}; then
#errors="${errors} ${rr}"
#fi
#done
#if [ -n "${errors}" ]; then
#echo >&2 "Unable to retrieve the following resource records from ${ns}:
${errors:1}"
#return 3
#fi
#if ns_is_validating ${ns} ${args}; then
# Return 0 if validating
#return 0
#else
# Is DNSSEC-aware
#return 2
#fi
}

Und in der /etc/unbound/unbound.conf

val-permissive-mode: no
auf
val-permissive-mode: yes
gesetzt.

Danach IPfre rebootet.

LG

Holger

wilfried · 29. August 2018 um 14:17

Hallo,

es läuft jetzt. Ich habe aber, wie einst von Dominik bei der opndns-Problematik herausgefunden, alle “Schalter” betätigen müssen. Hinweis: Von den betroffenen Dateien vorher Sicherheitskopien anzufertigen, kann nicht schaden.

Zunächst in der Datei /etc/init.d/unbound:

und dann in der Datei /etc/unbound/unbound.conf sowohl val-permissive-mode als auch harden-dnssec-stripped:

conf

Danach wird gefiltert und safesearch ist aktiviert. Ich habe den IPFire neu gestartet, wahrscheinlich reicht auch ein:

/etc/init.d/unbound restart.

Nützliche Befehle: /etc/init.d/unbound test–name-server 129.143.4.3 und auch nslookup www.google.de 129.143.4.3

Verbleibende Probleme:
Beim Neustart des IPFire gibt es die DNSSec-Pause nicht mehr, dafür hängt er bei mir ca. 3 Minuten an der Meldung:
Setting up default gateway (Router-IP Belwü)
Das ist nicht so tragisch, schlimmer ist, dass sich der jetzt sehr gut funktionierende Webfilter bei mir (und wahrscheinlich aus technischen Gründen bei allen) nicht mehr über die Schulkonsole ausschalten lässt.

Viele Grüße

Wilfried

Alex · 30. August 2018 um 18:33

Hallo zusammen,

ich habe auch auf die DNS-Filterung umgestellt (mittels setup auf dem IPFire). Danach stand bei mir der DNS-Server auch auf “local recursor”. Ich habe dann den IPFire nochmal neu gebootet, und jetzt scheint alles OK. Ich habe keine von den von euch beschriebenen Änderungen in den config-files vorgenommen, und erhalte auch nach mehrmaligem Boot immer dieses Bild:
belwue-dns
Stimmt damit was nicht, oder ist das Zufall dass das bei mir klappt?

LG Alex

amu · 30. August 2018 um 20:22

Hallo Alex,

Gute Frage…

Ich hatte allerdings keinen Reboot gemacht, sondern nur ein /etc/init.d/unbound restart.

Ohne die Änderungen an der unbound.conf und dem Startscript kommt bei mir dann ein

Stopping Unbound DNS Proxy...                                          [  OK  ]
Starting Unbound DNS Proxy...                                          [  OK  ]
Ignoring broken upstream name server(s): 129.143.4.3                   [ WARN ]
Falling back to recursor mode

Mit den Änderungen:

Stopping Unbound DNS Proxy...                                          [  OK  ]
Starting Unbound DNS Proxy...                                          [  OK  ]
Configuring upstream name server(s): 129.143.4.3                       [  OK  ]

Welche Version von ipfire hast du denn? (Bei mir ist’s core update 119)

Das DNSSEC-Problem gibt es wohl erst seit 106:

Viele Grüße

Andreas

baumhof · 30. August 2018 um 20:23

Hallo Alex,

ich habe auch auf die DNS-Filterung umgestellt (mittels setup auf dem
IPFire). Danach stand bei mir der DNS-Server auch auf “local recursor”.
Ich habe dann den IPFire nochmal neu gebootet, und jetzt scheint alles
OK. Ich habe keine von den von euch beschriebenen Änderungen in den
config-files vorgenommen, und erhalte auch nach mehrmaligem Boot immer
dieses Bild:
belwue-dns
Stimmt damit was nicht, oder ist das Zufall dass das bei mir klappt?

… ich war nach dem Umstellen so frei und hab einfach mal, bei
abgeschlateten URL Filter im IPFire, die Seite www.sex.com angesurft …
das hat funktioniert.
Du könntest es ja auch so testen …
Ich wußte dann, dass zwar die 129.143.4.3 eingetragen war, aber
offensichtlich nicht verwendet wurde.
Welcher DNS da verwendet wurde, ist mir nicht bekannt.
Nach den beschriebenen Änderungen konnte ich mit der Seite die
Sperrseite von BelWü provozieren.

LG

Holger

Alex · 30. August 2018 um 20:25

Ich habe Core 121.

LG Alex

Alex · 30. August 2018 um 20:27

Hallo Holger,
das habe ich natürlich auch probiert: Der Belwue-Filter funktioniert.
Dann lass ich das jetzt mal so ohne weitere Änderungen.

LG Alex

amu · 30. August 2018 um 20:38

Hallo Alex,

ich hatte (um die Reboot-Zeit nach dem Update auf 119 zu verkürzen) damals noch das hier gemacht:

Keine Ahnung, ob das evtl. damit zu tun haben könnte. Vielleicht teste ich das mal bei Gelegenheit…

Viele Grüße

Andreas

Alex · 30. August 2018 um 20:59

Die 3-Minuten Ehrenrunde hab ich auch, stört mich aber nicht, die Tage von ipfire sind in Bezug auf linuxmuster 7 ja wohl eh gezählt.

LG Alex

wilfried · 31. August 2018 um 06:37

Hallo Alex,

das hat soweit bei mir auch ohne Änderungen in den Dateien funktioniert. Der Härtetest ist aber zum Beispiel bei google “porn” einzugeben und dann bei den Ergebnissen auf “Bilder” zu klicken. Hier funktioniert die Filterung nur, wenn safesearch voreingestellt ist, und zwar so, dass es der Nutzer nicht abschalten kann. Diese Fuktion habe ich erst nach Änderung der Dateien erhalten.

Viele Grüße

Wilfried

amu · 31. August 2018 um 08:24

Hallo zusammen,

ich habe nun folgendes festgestellt:

Mache ich die folgende Änderung rückgängig:

dann gibt es beim Booten des ipfires wieder die lange Wartezeit und folgende Meldung:

Dann funktioniert aber der Jugendschutzfilter (Umleitung und Google-Safesearch) auch ohne diese Anpassungen an der unbound-Konfiguration:

Viele Grüße

Andreas

Alex · 31. August 2018 um 09:55

Hallo Wilfried,
ich habe den „porn“-Bildertest jetzt auch durchgeführt: Einmal mit deinen Änderungen, und einmal ohne die Änderungen (dazwischen immer den IPFire neu gestartet). Die Ergebnisse der Bildersuche sind absolut identisch - und sie sind gefiltert.

Für mich ist damit alles gut: Der Belwue-DNS tut was er soll, und das mit den Standard-Configeinstellungen vom IPFire. Das ist mir am liebsten weil ich nicht im Blick haben muss ob diese Einstellungen bei einem Core-Update wieder überschrieben werden (ich habe zur Zeit Core 122).

LG Alex

amu · 31. August 2018 um 09:59

Ich habe aus demselben Grund jetzt auch alles wieder zurück auf die ipfire-Standardeinstellungen gesetzt, damit funktioniert bei mir die Filterung auch (derzeit noch core 119). Einziges „Problem“ ist eben die Verzögerung beim Booten bis DNSSEC in den „permissive mode“ geht.

Viele Grüße

Andreas

wilfried · 31. August 2018 um 10:16

Hallo Alex,

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.

Viele Grüße

Wilfried

baumhof · 31. August 2018 um 12:38

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