Verbindungsprobleme mit Exchange Online geloest

[Patric Eichelberger]

Lieber Daniel

Herzlichen Dank fürs kompetente und umfangreiche Aufklären. Ich hatte
mich etliche male darüber genervt die letzten beiden Tage und
beschuldigte schon MS...

LG
Patric

On 9/1/21 5:06 AM, Daniel Baumann wrote:
> Hallo zusammen
> 
> In den letzten Tagen gab es zunehmend Verbindungsprobleme aus dem BFH
> Netzwerk zu den Exchange Mailservern in der Microsoft Cloud. Dies hat
> sich von einzelnen Verbindungsproblemen bis hin zur vollstaendigen
> Unbenutzbarkeit der E-Mail Dienste entwickelt.
> 
> Ursache war dass die Universitaet Bern, ueber welche wir ans schweizer
> Hochschulnetz (SWITCH) und ans Internet angebunden sind, die Microsoft
> Mailserver auf unserer Netzwerk-Anbindung gesperrt hat.
> 
> Seit gestern Dienstag, 11:45 Uhr ist diese Sperre wieder entfernt und
> E-Mail ist uneingeschraenkt verfuegbar.
> 
> Im Folgenden die Hintergrund-Informationen und weiteren Massnahmen.
> 
> 
> 1. DNS Round Robin
> ==================
> 
> Wenn ein Mailclient (egal ob Thunderbird, Outlook oder was anderes;
> betrifft alle die auf Exchange Online migriert worden sind) sich mit den
> Microsoft Mailservern verbindet, so tut er das mit outlook.office356.com
> und/oder outlook.office.com.
> 
> Diese DNS Eintraege sind sogenannte Round-Robin, d.h. es gibt mehre IP
> Adressen die fuer diesen Eintrag zwecks Load Balancing zu Performance
> und Redundanz hinterlegt sind:
> 
> ---schnip---
> $ kdig outlook.office365.com
> outlook.ha.office365.com.	10	IN	A	52.97.201.194
> outlook.ha.office365.com.	10	IN	A	52.97.201.242
> outlook.ha.office365.com.	10	IN	A	52.97.186.146
> outlook.ha.office365.com.	10	IN	A	52.97.201.210
> outlook.ha.office365.com.	10	IN	A	52.98.168.178
> outlook.ha.office365.com.	10	IN	A	52.98.163.18
> outlook.ha.office365.com.	10	IN	A	52.97.232.194
> outlook.ha.office365.com.	10	IN	A	52.97.201.226
> ---schnap---
> 
> Ein Client kann sich dann frei auswaehlen, welche der Adressen er
> verwenden moechte, in der Regel wird einfach die erste Antwort genommen
> (die in aller Regel von den antwortenden DNS Servern immer rotiert wird,
> damit nicht immer die gleiche Adresse zuoberst steht).
> 
> 
> 2. Internet Anbindung via Universitaet Bern
> ===========================================
> 
> Die BFH verfuegt ueber keinen direkten Anschluss ans Internet, sondern
> ueber eine redundante Anbindung (2x 10gbit) ans schweizer Hochschulnetz
> (SWITCH) und damit ans Internet via die Universitaet Bern.
> 
> D.h. in unserem Rechenzentrum in Bern gehen zwei Glasfaserkabel zur
> unibe, und von da weiter nach Zuerich. Der gesamte Traffic passiert
> dabei den unibe Border-Router. Das ist fuer uns oekonomischer weil
> dadurch die Anschlussgebuehren fuer SWITCH signifikant tiefer sind.
> 
> Als zusaetzlicher Service verhindert die Universitaet Bern so indirekt
> einen Teil der Attacken (DoS, DDoS) aus dem Internet gegen unsere
> Systeme weil wir denselben Uplink benutzen. Solche legitimen Sperrungen
> von Adressen oder Adressbereichen sind nur jeweils kurzfristig fuer ein
> paar Stunden notwendig und kommen insgesamt sehr selten vor (ein, zwei
> mal pro Jahr). Das macht die unibe seit vielen Jahren unaufgefordert so
> und dafuer sind wir sehr dankbar, das hat in den letzten 10 Jahren ein
> paar mal groesseren Schaden/Ausfaelle auf unserer Seite verhindert.
> 
> 
> 3. Aktuelle Sperrung der Microsoft Server
> =========================================
> 
> Die Netzwerkverantwortlichen der unibe haben in den letzten Tagen ein
> erhoehtes Traffic-Aufkommen zu den Microsoft Mailservern bemerkt.
> 
> Das ist einerseits erklaerbar durch die weitere Migration unserer User
> auf Exchange Online, andererseits durch Ende der Ferienzeit und
> vermehrter Vorort-Praesenz der Mitarbeitenden.
> 
> Leider hat unibe selbststaendig entschieden, immer mehr Mailserver von
> Microsoft zu blockieren. Schlussendlich waren gestern so 8 von den 10
> verfuegbaren Mailservern geblockt.
> 
> Der Effekt war dass ein Client fuer jede Verbindung jeweils sich
> "durchprobieren" musste, bis er einen der 2 noch funktionierenden Server
> erwischt hat. Das aeusserte sich in extrem langsamem Zugriff oder keinem
> Zugriff auf Mails, und ebenso eingeschraenkten Mailversand.
> 
> Allerdings war das Verhalten jederzeit diskret, d.h. wenn eine Mail
> versendet werden konnte, wurde sie auch versendet. Ansonsten gab es auf
> dem Client eine entsprechende Fehlermeldung dass der Mailserver nicht
> erreicht werden kann und man konnte es nochmal probieren.
> 
> Verstaerkt wird der Effekt dadurch dass die DNS Records eine
> Time-to-Life (TTL) von nur 5 Sekunden haben, d.h. ein Client fragt bei
> praktisch jeder Verbindung nochmal neu nach Adressen an. Somit konnte
> ein Client nicht davon profitieren, einmal einen funktionierenden
> Mailserver erwischt zu haben, sondern das "2 aus 10"-Durchprobieren
> faengt (spaetestens) alle 5 Sekunden wieder von vorne an.
> 
> Die Sperrung dieser Server wurde durch die unibe manuell (also nicht
> aufgrund oder Teil eines automatischen Systems) und ohne Kommunikation
> zur BFH vorgenommen. Wir haben darauf ensprechend reagiert, siehe unten.
> 
> 
> 4. Debugging (Drop vs. Reject, resp. Inbound vs. Outbound)
> ==========================================================
> 
> Grundsaetzlich kann man Traffic auf zwei Arten sperren - man kann
> entweder still die Netzwerkpakete verwerfen (drop) oder aktiv
> zurueckweisen (reject).
> 
> In konventionellen Netzen wird haeufig noch gedropt, was dazufuehrt dass
> Netzwerk-Clients in (lange) Timeouts laufen. Dafuer werden die
> Netzwerkgeraete minimal weniger belastet weil ein Verwerfen weniger
> Prozessierungs-Aufwand generiert als ein aktives Zurueckweisen.
> 
> In der heutigen Zeit ist ein drop, ausser in Nischenfaellen von sehr
> grossen Distributed-Denial-of-Service (DDoS) Attacken, nicht mehr
> empfehlenswert und auch nicht mehr noetig. Aktuelle Systeme koennen
> Rejects problemlos abarbeiten. Ein aktives Reject ist daher immer zu
> bevorzugen, weil dadurch unmittelbar die Netzwerkteilnehmer die
> Verbindung abbrechen und Fehler sich sofort bemerkbar machen. Dies
> insbesondere dann wenn mehrere Systeme hintereinander arbeiten, so dass
> sich keine langen Timeout-Ketten bilden koennen.
> 
> Wuerden alle "reject statt drop" machen, waere das Internet (oder das
> jeweilige Teilnetz) fuer alle besser/schneller. Im neuen BFH Netzwerk
> machen wir grundsaetzlich ueberall reject, im alten Netzwerk haben wirs
> seit der Uebernahme im Mai 2020 ueberall dort wo sinnvoll moeglich und
> an den neuralgischen Punkten ebenfalls auf reject umgestellt.
> 
> Analog zu "reject statt drop" wird konventionell leider haeufig auch nur
> eingehender Traffic (inbound) gesperrt, statt beide Richtungen zu
> sperren. Weil dadurch ausgehender Traffic (outbound) zu den gesperrten
> Adressen immer noch moeglich ist, verhaelt es sich fuer alle
> Netzwerkteilnehmer wie bei einem Drop: sie laufen in ein Timeout rein
> weil sie auf die (nicht eintreffende) Antwort warten muessen.
> 
> Wuerden Sperrungen auf Router-Ebene auf inbound und outbound Traffic
> gemacht (auch hier sind heutigen Systeme mehr als nur performant genug,
> Traffic in beide Richtungen sperren zu koennen), waere der Effekt der
> Sperrung der Mailserver gewesen, dass gar kein Mail mehr funktioniert
> haette.
> 
> Das waere zum Debuggen wesentlich einfacher gewesen. Zusammen mit der
> Erwartungshaltung dass wir komplett ungefiltertes Internet von der unibe
> erhalten, haben wir zuerst doppelt-und-dreifach unsere eigenen Systeme
> ausgeschlossen (Firewall, Border, etc.), ein "Rueckwaertskanal"-Problem
> im Peering zwischen Microsoft und SWITCH vermutet (das ist auch das was
> man per traceroute sieht: traffic hin zu MS funktioniert, aber zwischen
> MS und SWITCH kommt nichts mehr zurueck weil MS via SWITCH nicht
> zustellen kann weil unibe nicht annimmt).
> 
> Dashalb haben wir erst als Letztes mit der unibe im Verlauf des Dienstag
> Vormittags Kontakt aufgenommen. Diese haben dann schlussendlich schnell
> reagiert und die Sperrung ensprechend wieder entfernt.
> 
> 
> 5. Massnahmen
> =============
> 
>   * Wir haben der unibe unsere Erwartungshaltung zu ungefiltertem
>     Internet kommuniziert, ebenso die Anforderung nach zeitnaher
>     Kommunikation bei Eingriffen und dem Wunsch nach mehr Feingefuehl
>     bei (vermeintlich legitimen) Sperrungen - die gesperrten Adressen
>     waren klar ersichtlich aus dem Microsoft SaaS Bereich.
> 
>     Wir haben gleichzeitig der unibe auch unseren Dank ausgesprochen
>     fuer die legitimen, temporaeren Sperrung in Notfall-Situationen in
>     den letzten Jahren (DoS, DDoS) und den ansonsten bisher immer sehr
>     guten Service und Zusammenarbeit.
> 
>     unibe wird nun die internen Prozesse ueberarbeiten und uns
>     informieren.
> 
>   * Wir haben die vollstaendige Liste aller gesperrten Adressen und
>     Ports verlangt und erhalten. Wir werden diese in den naechsten Tagen
>     bereinigen (d.h. alles entsperren lassen was nicht gesperrt sein
>     muss; wir haben bereits einige weitere illegitime Sperrungen von
>     Systemen gefunden).
> 
>   * Langfristig: in Hinblick auf den Campus Biel ist eine
>     Diversifizierung der Internet-Anbindung durch einen eigenen,
>     separaten Internet-Aufgang im dort neu aufzubauenden Rechenzentrum
>     in Biel vorgesehen.
> 
>     Dadurch kann nicht nur eine Performance-Verbesserung fuer die
>     Standorte in Biel erreicht werden, sondern auch eine Verbesserung
>     fuer die Gesamt-BFH durch Provider-Unabhaengigkeit und oertliche
>     Redundanz geschaffen werden.
> 
> 
> 6. Fun Fact
> ===========
> 
> Die Sperrung der Microsoft Mailserver hat nich nur die BFH betroffen,
> sondern neben der unibe (definitiv) selbst auch (vermutlich) alle der
> unibe Internet-anbindungstechnisch angehaengten Institutionen wie PH
> Bern und das Insel Spital.
> 
> Die Einschraenkung war fuer alle Teilnehmenden gleichermassen
> verheerend. Trotzdem waren wir offenbar die ersten die den Effekt der
> Sperrung bemerkt haben. Ob wir die Ersten sind die grossflaechig auf
> Exchange Online setzen, oder ob alle in den Ferien oder im Homeoffice
> sind, oder einfach keine E-Mails lesen/verschicken.. wissen wir
> natuerlich nicht :)
> 
> 
> Wir danken fuer euer Verstaendnis.
> 
> Gruesse,
> Daniel
>