Policy: Anti-Schadcode-DNS?

Infrastruktur
1

Moin,

durch Meldungen des BSI (CERT BUND) gerade drauf gestoßen … Auch in unseren Netzen gibt es verzeinzelt infizierte (Windows-) Systeme; nun gibt es aber mit Quad9 ja einen öffentlichen Nameserver, der genau an dieser Stelle einsetzt und Malware-Domains blockiert:

wusel@cohen:~$ dig a  jadlhpajcajbgcc.ru @9.9.9.9

; <<>> DiG 9.16.27-Debian <<>> a jadlhpajcajbgcc.ru @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2181
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;jadlhpajcajbgcc.ru.		IN	A

;; Query time: 20 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Jul 06 17:19:57 CEST 2022
;; MSG SIZE  rcvd: 47

wusel@cohen:~$ dig a  jadlhpajcajbgcc.ru @1.1.1.1

; <<>> DiG 9.16.27-Debian <<>> a jadlhpajcajbgcc.ru @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15092
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;jadlhpajcajbgcc.ru.		IN	A

;; ANSWER SECTION:
jadlhpajcajbgcc.ru.	273	IN	A	199.21.76.81

;; Query time: 40 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jul 06 17:20:05 CEST 2022
;; MSG SIZE  rcvd: 63

Ich wäre insofern dafür, daß unsere Nameserver im Mesh die v4- und v6-Adressen von Quad9 als Resolver rausgeben, statt Cloudflare, Google oder unseren eigenen. Ich erhoffe mir damit ein gewisses Ausbremsen entsprechender Malware. Comments?

1 „Gefällt mir“
2

Wir bremsen die Nutzung zwar. Aber ich sehe keinen großen Erfolg darin, denn unser Netz wird in den meisten Fällen nur vorübergehend genutzt. Einen halben Tag später verbreitet der Computer dann wieder Schadsoftware über andere Netzte

Von der Telekom weiß ich, dass sie die Anschlussinhaber darauf hinweist (schriftlich per Post). Das ist bei uns aber nicht möglich sein

Um Erfolge zu erzielen müsste man im Falle einer entdeckten Infektion eigentlich den kompletten Traffic blockieren, und den User auf eine Info Seite umleiten. Hier könnte man ihn dann die Option geben den Traffic trotz Infektion wieder frei zu schalten

Nun etwas weiter gedacht werden die Malwarebetreiber das DNS Problem was ihnen in den Weg gelegt wird aber mit Verschlüsselung umgehen. Daher ist mein bedenken, wir machen uns die Arbeit, erzielen aber keinen Nennenswerten Effekt jetzt, und schon gar nicht in der Zukunft.

3

Moin,

Wir bremsen die Nutzung zwar. Aber ich sehe keinen großen Erfolg darin, denn unser Netz wird in den meisten Fällen nur vorübergehend genutzt. Einen halben Tag später verbreitet der Computer dann wieder Schadsoftware über andere Netzte

… was dann ein Problem jener Betreiber ist. Der Knackpunkt ist halt, daß, wenn aus einem Netz heraus Malware agiert, dieses Netz früher oder später auf entsprechenden RBLs landet. Schon weil wir auch andere Dienste – nicht zuletzt Mail – in den Netzen betreiben, sollten wir da Mißbrauch eingrenzen, wo dies simpel möglich ist. IMHO, daher bringe ich das Thema ja auf :wink:

Von der Telekom weiß ich, dass sie die Anschlussinhaber darauf hinweist (schriftlich per Post). Das ist bei uns aber nicht möglich sein

Nö. Wir bekommen im Zweifel entsprechende Nachrichten über CERT-BUND:

  Betroffene Systeme in Ihrem Netzbereich:

  Format: ASN | IP | Timestamp (UTC) | Malware | SRC port | DST ip | DST port | DST host | Proto
  23456 | 111.222.333.221 | 2022-07-05 10:03:51 | flubot | 46934 | 63.251.126.10 | 80 | pkrfjejtrdvtkcv.ru | tcp
  23456 | 333.222.111.247 | 2022-07-05 07:42:34 | flubot | 42614 | 199.21.76.81 | 80 | jadlhpajcajbgcc.ru | tcp

Für uns zweckfrei, da wir keine Möglichkeit haben zu ermitteln, wer am 2022-07-05 um 10:03:51 über Gateway 111.222.333.221 zu 63.251.126.10 Port 80 sich verbunden hat.

Um Erfolge zu erzielen müsste man im Falle einer entdeckten Infektion eigentlich den kompletten Traffic blockieren, und den User auf eine Info Seite umleiten. Hier könnte man ihn dann die Option geben den Traffic trotz Infektion wieder frei zu schalten

Dazu müßten wir zeitnah von den Großen Unbekannten, die diese Information – welches Ziel ist böse – haben, eben jene bekommen um dann auf den Gateways über iptables Nutzung zu loggen und über das Logfile diese Quell-IP zu blocken.

Schon nicht trivial, in Zeiten von dynamischen MAC-Adressen im WLAN (ja, danke auch, Apple!) aber vollkommen zweckfrei. Beim nächsten Reconnect mit neuer MAC gibt’s neue IP und die Sperrung läuft leer.

Nun etwas weiter gedacht werden die Malwarebetreiber das DNS Problem was ihnen in den Weg gelegt wird aber mit Verschlüsselung umgehen. Daher ist mein bedenken, wir machen uns die Arbeit, erzielen aber keinen Nennenswerten Effekt jetzt, und schon gar nicht in der Zukunft.

Naja, die „Arbeit“ besteht in der Änderung von Sign in · GitLab, dort:

nameservers:
  # FoeBud
  - "85.214.20.141"
  # Cloudflare
  - "1.1.1.1"
  # dnscache.berlin.ccc.de
  - "2001:678:760:cccb::53"
  # Cloudflare
  - "2606:4700:4700::1001"

… und einem Ansible-Lauf. Da kostete diese Antwort schon mehr Zeit :wink:

Ciao,
-kai

4

Vor diesem Hintergrund würde ich sagen, ja auf jeden Fall einrichten.

Das hatte ich eben nicht auf dem Schirm. Hatte eher an den Schutz der Enduser gedacht, wo ich halt sage hilft wenig da auch andere Netzte genutzt werden.

5

Ja, da hilft das nur bedingt bis gar nicht. Aber ich denke, das ist auch nicht unsere Aufgabe; Schutz der eigenen Infrastruktur hingegen schon.

6

Cloudflare hat auch einen entsprechenden DNS-Dienst, der Malware filtert. Nennt sich „1.1.1.1 for Famlies“. Da gibt es 2 Ausprägungen: „Block Malware“ und „Block Malware and adult content“. Du willst vermutlich ersteres :slight_smile:

https://developers.cloudflare.com/1.1.1.1/setup/

1 „Gefällt mir“