WLAN am Campus Süd stellenweise nicht verfügbar

Sporadische Verbindungsprobleme im kabelgebundenen KIT-Netzzugang möglich - UPDATE (09.04.24)

Spamfilter der zentralen Mailserver gestört, Mails ungeprüft zugestellt - BEHOBEN

ERGÄNZUNG, 17.7.24
Der Wechsel zu Nextcloud Office (Collabora) folgt der kontinuierlichen Weiterentwicklung von Nextcloud in diesem Bereich.

BESCHREIBUNG
Anstelle des Online-Editors "OnlyOffice" wird ab diesem Zeitpunkt in bwSync&Share der Online-Editor "Nextcloud Office (Collabora)" zur Verfügung gestellt.


BETROFFEN
Landesdienst bwSync&Share - http://www.scc.kit.edu/dienste/bwSyncAndShare.php

AUSWIRKUNG
Die Umstellung und die damit verbundene Downtime sollte nur wenige Minuten dauern. Danach steht allen Nutzenden in bwSync&Share nur noch der Online Editor "Collabora Office" zur Verfügung.

DETAILS
Ab dem Abend des 11. Juli 2024 stellt bwSync&Share "Nextcloud Office (Collabora)" als Online Editor bereit, um Dokumente im Webbrowser zu bearbeiten. Der Wechsel erfolgt für die Nutzenden nahtlos von OnlyOffice, das in bwSync&Share bisher zur Verfügung steht.
Für alle Nutzenden bedeutet der Wechsel auf die neue Office-Lösung die Umstellung auf eine neue Oberfläche, wenn sie Dokumente online im Browser editieren.

Die Umstellung erfolgt am Donnerstag, den 11. Juli 2024, um 18:00 Uhr.

Bis zu diesem Zeitpunkt öffnen sich Dokumente im gewohnten OnlyOffice. Nach der Umstellung startet "Nextcloud Office (Collabora)" automatisch, sobald eine Datei im Webbrowser geöffnet wird.
SUPPORT
Sollte es im Zuge der Umstellung Fragen geben, stellen die Nutzenden diese bitte über das jeweilige Ticketsystem der Heimateinrichtung ein.

HINWEIS
Durch die Einbindung von "Nextcloud Office (Collabora)" ändert sich nichts am grundsätzlichen Betrieb vor Ort am KIT. Auch diese Lösung für das Webediting wird, wie bisher OnlyOffice, weiterhin vollständig vor-Ort in unserer SCC-Infrastruktur betrieben. Durch die Nutzung von "Nextcloud Office (Collabora)" werden keine Daten auf Fremdsysteme übermittelt. Daher ändert die Umstellung der lokalen Office-Lösung am vorhanden Betriebs- und Datenschutzmodell des Dienstes bwSync&Share nichts.

BESCHREIBUNG
Die Beantragung von Berechtigungen im User Portal (UP) über PDF-Formulare in Papierform wird eingestellt. Zukünftig erfolgt die Beantragung von Berechtigungen im SAP-Umfeld über ein digitales Formular.

BETROFFEN
Mitarbeiter*innen und OE-Leitungen, die Berechtigungen im SAP-System beantragen und genehmigen möchten.

AUSWIRKUNG
PDF-Formulare zur Beantragung von Berechtigungen werden ab dem 22.7.24 nicht mehr akzeptiert/bearbeitet.
Stattdessen müssen die Berechtigungen ab dem 10.7.24 direkt im User Portal (UP) über das digitale Formular "Berechtigungen beantragen" beantragt werden.

HINWEIS
Weitere Informationen erhalten Sie per Mail oder können Sie in den Service News nachlesen.

BESCHREIBUNG
Bei den M365 Diensten MS Teams, SharePoint Online und OneDrive wurde die Standardeinstellungen beim Teilen von Dokumenten geändert.

Neue Einstellung: Teilen von Dokumenten für ausgewählte Personen mit Anzeige-Berechtigung

Bisherige Einstellung: Teilen von Dokumenten für alle Nutzer*innen in der Organisation (KIT) mit Bearbeiten-Berechtigung

BETROFFEN
Betroffen sind Personen, die MS Teams zum Teilen von Dokumenten verwenden oder Personen, die bereits für OneDrive oder SharePoint Online eine Lizenz am KIT erhalten haben.

AUSWIRKUNG nach Durchführung
Bestehende Berechtigungen auf Freigaben oder geteilten Dokumenten bleiben erhalten.
Es ändert sich lediglich die Voreinstellung beim neuen Teilen von Dokumenten.


BITTE BEACHTEN
Prüfen Sie die Einstellung bestehender Freigaben und passen diese bei Bedarf an!

Weitere Informationen finden Sie unter: https://www.scc.kit.edu/downloads/ISM/M365/SharedDocuments_ChangeDefaultSettings.pdf

Heute wurde eine kritische Sicherheitslücke in OpenSSH veröffentlicht, die entfernte Codeausführung (Remote Code Execution) als root erlaubt. Die Finder der Lücke, Qualys, beschreiben die Lücke für technisch Interessierte ausführlich in Ihrem Blogpost [1]. Anfällig für die Schwachstelle sind alle Versionen von OpenSSH von 8.5p1 bis exklusive 9.8p1, die glibc verwenden. Das betrifft die meisten Linux-basierten Systeme. Eine Ausnutzbarkeit für entfernte Codeausführung wurde bisher nur für i386-basierte (32 Bit) Versionen nachgewiesen, die Ausnutzbarkeit auf 64 Bit Systemen gilt allerdings als wahrscheinlich und die Verfügbarkeit eines Exploits wird nur eine Frage der Zeit sein. Eine erfolgreiche Ausnutzung benötigt je nach Version und Konfiguration Stunden bis Tage und ca. 10.000 Verbindungen. Das kann zwar auffallen, aber auch schnell im Rauschen ständiger SSH-Scans untergehen, wenn OpenSSH ins Internet geöffnet ist. Daher müssen auf allen Systemen mit OpenSSH, vor allem solchen, die einen OpenSSH-Server ins Internet geöffnet haben, unverzüglich Patches eingespielt werden, sobald diese verfügbar sind. Bitte vergessen Sie nicht, den OpenSSH-Server nach einem Update auch neu zu starten. Bitte denken Sie außerdem daran, etwaige Base Images für Virtualisierungssysteme zu aktualisieren, damit auch neu angelegte VMs geschützt sind. Falls Sie noch ein 32-Bit System mit anfälliger Distribution und ins Internet geöffnetem OpenSSH betrieben, empfehlen wir dringend, das System als kompromittiert zu betrachten.
Hier eine Liste der aktuell bekannten Informationen zu einigen Linux- und BSD-Distributionen:
* Debian: Bookworm (Debian 12) ist betroffen, es steht ein Patch via Bookworm Security zur Verfügung [2]. Bei Bullseye (Debian 11) ist eine OpenSSH-Version mitgeliefert, die älter als 8.5p1 ist, wodurch Bullseye nicht betroffen ist. * Ubuntu: Aktuell gibt es noch kein Advisory der Entwickler, aber es stehen seit Kurzem Patches zur Verfügung. Alle Versionen ab Jammy (22.04) sind betroffen [3,4,5]. Vorherige Versionen sind nicht betroffen. * RHEL: Nur RHEL 9 ist betroffen, vorherige Versionen verwenden eine ältere OpenSSH-Version [6] * OpenBSD: Nicht betroffen laut Qualys-Post [1] * FreeBSD: Alle aktuell unterstützten Versionen betroffen, Patches stehen zur Verfügung [7]
Sollte für Ihre Linux-Distribution noch kein Patch verfügbar sein, kann eine Mitigation angewendet werden. Diese besteht daraus, in der `sshd_config` die Option `LoginGraceTime` auf 0 zu setzen. Auszug aus dem Blogpost von Qualys zu diesem Workaround:
"Finally, if sshd cannot be updated or recompiled, this signal handler race condition can be fixed by simply setting LoginGraceTime to 0 in the configuration file. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from the remote code execution presented in this advisory." ...........
[1] https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt [2] https://security-tracker.debian.org/tracker/CVE-2024-6387 [3] https://launchpad.net/ubuntu/+source/openssh/1:8.9p1-3ubuntu0.10 [4] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.6 [5] https://launchpad.net/ubuntu/+source/openssh/1:9.6p1-3ubuntu13.3 [6] https://access.redhat.com/security/cve/cve-2024-6387#cve-cvss-v3 [7] https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc

BETROFFEN
Service: KIT E-Mails zu Google-Adressen (@gmail.com / @googlemail.com)
Personen: Alle, die Mails an Google-Adressen versenden oder weiterleiten

BESCHREIBUNG/MAßNAHME
Mails an Google-Mailadressen, die vom KIT-Spamfilter als Spam detektiert wurden, werden agressiver als bisher abgewiesen.
Details siehe https://www.scc.kit.edu/dienste/e-mail/2024-google-mail.php

Es wurde ein Fehlverhalten zwischen einem am KIT-Campus Süd eingesetzten Netzwerk-Switchtyps und einem Windows 11 Update (Version 22H2) festgestellt. Durch dieses Fehlverhalten wird der Netzwerkport am Switch automatisch abgeschaltet.
Daraufhin ist die Netzverbindung bzw. der Netzzugriff für das angeschlossene Gerät nicht mehr gegeben.
Für die Freischaltung des Netzzugriffes muss die verwendete Datendose dem IT-Beauftragten / IT-Admin der OE mitgeteilt werden, damit dieser die Freischaltung über das Netze-Team des SCC beantragen kann.

BETROFFEN
Windows 11 Clients mit Updatestand 22H2 (und voraussichtlich höher) in Verbindung mit spezifischem Netzwerk-Switchtyp

WORKAROUND
Damit der Netzwerkport nicht abgeschalten wird, kann der LLDP-Dienst unter Windows deaktiviert werden. Dies kann manuell (computerspezifisch) unter "Netzwerkadaptereigenschaften" erfolgen. Des Weiteren stellt das SCC die Gruppenrichtlinie "SCC-FMC-LLDP_disable" zur Verfügung, welche mit den Computerkonten verknüpft werden kann und automatisch LLDP unter Windows deaktiviert. Eine Freischaltung von bereits gesperrten Ports kann über den IT-Beauftragten/IT-Admin der OE beim Netze-Team beantragt werden.

TECHNISCHE DETAILS
Seit Windows 11 Updatestand 22H2 führt das Versenden von Link Layer Discovery Protokoll-Paketen (kurz LLDP-Paketen) an einem spezifischen Switchingtyp dazu, dass ein Dienst zur Erkennung von Netzwerkschleifen am Switch auslöst, wodurch der Netzwerkport automatisch gesperrt wird.