fehlender Jugendschutzfilter an Schüler-Rechnern

[kapp]

Liebes Netzwerkteam,

im Unterricht Medienbildung bei Simone Gönnenwein in der 5b konnten Schüler durch die Eingabe von XXX im Browser Porno-Seiten aufrufen. Das hätte doch durch einen Jugendschutzfilter verhindert werden müssen, oder? Könnt ihr das bitte überprüfen? Wäre es möglich, den Browserverlauf zu rekonstruieren, um herauszufinden, ob die Schüler bewusst nach Sex-Seiten gesucht haben oder ob das ein "Zufallstreffer" war? Wir haben durch diesen Vorfall in unserer gemeinsamen Klasse Stress mit den Eltern und auch die Schüler sind z. T. verstört.

Danke fürs drum Kümmern, liebe Grüße,
Christoph Kappler & Simone Gönnenwein

[bau]

alle DNS-Anfragen gehen im päd. Netz über den DNS-Filter von BelWUE.
Dieser ist aber nur so gut, wie ein Filter eben sein kann.
Zudem zeigt google in der Bildersuche Thumbnails an - dagegen würde nur helfen, google ganz abzuschalten.

Fazit für die Eltern:
Einen umfasenden technischen Schutz kann es nicht geben - nichts kann die Pädagogik ersetzen!

[bau]

Für einen Test:
www.sex.de sollte auf der Landind-Page von BelWUE landen.

Wichtig: Lehrer gehen über einen anderen Proxyserver raus, damit sie eben NICHT im Filter landen :-)

[Rüdiger Kupper]

Gerade im Klassenraum getestet, als Schüler (Nutzer "schuelte", Proxy: ​https://proxys.kg-fds.de)

Suchbegriff "xxx" eingeben in Chrome oder Firefox
-> man erhält einschlägige Suchergebnisse und man kann diese Seiten auch aufrufen!!

Das sieht für mich aus, als sie da *überhaupt* kein Filter dazwischen?! Das ist wirklich kritisch, gibt es bei BelWü dazu irgendwelche Informationen?

[bau]

Ja, da scheint aktuell die Namensauflösung nicht mehr zu filtern, ich bekomme für sex.de:

[root@ipfire ~]# nslookup sex.de
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   sex.de
Address: 35.180.180.134

Aber der BelWUE-Filter DNS macht es schon richtig:

[root@ipfire ~]# nslookup sex.de 129.143.4.3
Server:         129.143.4.3
Address:        129.143.4.3#53

Non-authoritative answer:
Name:   sex.de
Address: 129.143.4.3
Name:   sex.de
Address: 2001:7c0::53:3

In den Einstellungen (auf dem ipFire: setup) steht aber der korrekt Nameserver drin??

[bau]

Was soll das denn, der ipFire will schon wieder den Name-Server von BelWUE nicht anerkennen?

Unbound möchte unbedingt einen DNSSEC-Nameserver, das hatte ich aber schonmal gepactched:

[root@ipfire ~]# /etc/init.d/unbound test-name-server 129.143.4.3
129.143.4.3 is not DNSSEC-aware
129.143.4.3 supports TCP fallback
EDNS buffer size for 129.143.4.3: 4096

Ich habe nun in der /etc/init.d/unbound in der Funktion test_name_server() gepatched:

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

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

        return 2

Jetzt ist also jeder Nameserver DNSSEC.
Zusätzlich muss aber in /etc/unbound.conf das ganze DNSSEC-Zeugs ausgeschaltet werden:

        # DNSSEC
        auto-trust-anchor-file: "/var/lib/unbound/root.key"
        val-permissive-mode: yes
        val-clean-additional: yes
        val-log-level: 1

        # Hardening Options
        harden-glue: no
        harden-short-bufsize: no
        harden-large-queries: no
        harden-dnssec-stripped: no
        harden-below-nxdomain: no
        harden-referral-path: no
        harden-algo-downgrade: no
        use-caps-for-id: no

[bau]

Jetzt ergibt die sex.de Abfrage:

[root@ipfire ~]# nslookup sex.de 
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   sex.de
Address: 129.143.4.3
Name:   sex.de
Address: 2001:7c0::53:3

[Rüdiger Kupper]

Werden die Änderungen beim nächsten Update wieder überschrieben?
Die saubere Lösung wäre natürlich, BelWü passen ihren Server an aktuelle Sicherheitsstandards an.

[Rüdiger Kupper]

Andere Frage: wenn der BelWü-DNS nicht angenommen wurde, wieso wurden die Namen dann überhaupt aufgelöst? Gibt es einen Fallback?

[bau]

Jup, unbound benutzt dann irgendeinen fallback aus den Tiefen seiner Konfiguration.

Das Problem besteht seit Jahren und wird von BelWUE seither nicht gelöst - da habe ich wenig Hoffnung.