Firewall-Umbau/Moodle-Diskwechsel erfolgreich abgeschlossen

[Daniel Baumann]

Hallo zusammen

1. Kurzfassung
==============

1.1 Firewall
------------

  * wir haben um 18:00 begonnen, auf die alte Firewall-Hardware
    zu migrieren. Dies hat mit Umbauen, Testen, Konfigurieren,
    nochmals Testen, etc. insgesamt 75min gedauert.

  * seit 19:15 laeuft aller Traffic aus und in die BFH.ch Server-Netze,
    sowie VPN und Eduroam, ueber die alte Firewall-Hardware.

  * waehrend des gesamten Umbaues gab es keinen Verbindungsunterbruch.

  * wir bedanken uns bei Jean-Marc B. von BNC, der die Arbeiten an der
    Checkpoint-Firewall durchgefuehrt hat und bei Patrick W. von
    Itris, als (gluecklicherweise unnoetiger) Notfall-Standby fuers
    Cisco-Netz.

1.2 Moodle
----------

  * wir haben Moodle um 18:00 gestoppt und die Disks mit den letzten
    Aenderungen nochmals ge-rsynced.

  * nach dem Einsetzen der zweiten, neuen Disk haben wir diese
    dem RAID-1 Array hinzugefuegt und die Resynchronisation des RAIDs
    gestartet.

  * seit 18:45 ist Moodle wieder online.


2. Bemerkungen zur Firewall
===========================

2.1 Leih-Hardware fuer Firewall
-------------------------------

Ende 2019 musste eine Leih-Hardware fuer die Firewall eingesetzt werden,
weil die alte Firewall-Hardware aus Performance-Gruenden mit der
gestiegenen Bandbreite im BFH.ch Netz nicht mehr umgehen konnte (gab
ja einige Netz-Totalausfaelle im 2019 deswegen).

Da die Leih-Firewall aus diversen Gruenden zurueckgegeben werden muss,
haben wir im Mai 2020 zwei Linux-Standardserver als Firewall fuer allen
Client-Traffic aufgebaut. So kann die alte Firewall-Hardware anstatt der
Leih-Firewall, allerdings nur fuer die Server-Netze, benutzt werden.

2.2 Bandbreite vs. Latenz
-------------------------

Die alte Firewall-Hardware kann zwar mit der wenigen noch verblieben
Bandbreite umgehen (ca. 90% des Traffics aus dem/ins BFH.ch Netz ist
Client Traffic), ist allerdings nicht so performant wie die viel neuere
Leih-Firewall es war.

Deshalb hat die Latenz zu und von den BFH.ch Server-Netzen im Vergleich
zur Leih-Firewall deutlich zugenommen, d.h. Zugriffe auf die BFH.ch
Server fuehlen sich ingesamt "langsamer/traeger" an, man wartet laenger.
Dies ist insbesondere bei Applikationen wie Moodle spuerbar.

2.3 Regeln fuer die Server-Netze
--------------------------------

Grundsaetzlich haetten wir beim Einsetzen der Linux-Firewall als Bypass
zur bestehenden Checkpoint-Firewall einfach den gesamten Traffic ueber
die Linux-Firewall routen koennen.

Wir haben das aus drei Gruenden nicht gemacht:

  1. weil die Zeit zur Uebernahme aller (Ausnahme)-Regeln aus der
     Checkpoint auf die Linux-Firewall (nftables) nicht serioes
     ausgereicht haette.

     Zur Erinnerung: wir haben in Rekordzeit eine Linux-Firewall in
     Enterprise-Qualitaet *zusaetzlich* zur normalen, eh schon mehr als
     100% betragenden, Betrieb- und Engineering-(Ueber)Auslastung
     implementiert. Das "Reverse-Engineering"/Aufraeumen des Regelsatzes
     waere nicht auch noch serioes moeglich gewesen in dieser kurzen
     Zeit.

  2. weil die Zeit nicht gereicht hat, um auch noch ein sogenanntes
     Intrusion Prevention System (IPS) serioes zu evaluieren und
     implementieren.

     Die Checkpoint-Firewall bei uns macht mittels Deep Package
     Inspection einen "Inhaltsfilter" auf dem gesamten Netz das durch
     die Firewall geht und blockiert gewisse Dinge die, basierend auf
     einem Regelsatz, fuer (potentiel) verdaechtig haelt. Der Nutzen von
     IPS ist nicht unumstritten und es gibt einige gewichtige Nachteile
     eines IPS wie es bei Checkpoint eingesetzt wird. Wir
     wollten/konnten diese Diskussion ob fuer die BFH.ch Server dies
     wirklich in dieser Form sinnvoll nicht in dieser so schon mit
     Arbeit ueberladenen Zeit fuehren.

  3. wir haben keine Betriebserfahrung mit einer Linux-Firewall mit
     einer "groesseren" Anzahl von parallelen Sessions.

     Seit Februar 2019 haben wir fuer BFH.science natuerlich bereits
     eine Linux-Firewall (allerdings dort damals aus Zeitgruenden noch
     ohne High-Availability) produktiv im Betrieb. Bei BFH.science ist
     der Workload fuer eine Firewall aber nicht vergleichbar mit BFH.ch:
     die Bandbreiten sind viel Hoeher, die Latenzen viel kleiner, IPv4
     und IPv6 Dualstack.. das funktioniert alles gut, haben
     aber mittlerweile dies auf 5 Jahre alter Server-Hardware und mit
     einer viel geringeren Anzahl paralleler Sessions.

     Ein blinder Big-Bang Change mit einem direkten, vollstaendigen
     Wechsel von der Checkpoint-Firewall auf eine Linux-Firewall ohne
     vorgaengige minimale Betriebserfahrung waere alles andere als
     serioes gewesen und haette im Problemfall zu einem mehrtaegigen,
     vollstaendigen Netzwerk-Ausfall gefuehrt - was fuer unsere
     Nutzenden natuerlich nicht hinnehmbar gewesen waere.

2.4 Weiteres Vorgehen
---------------------

Wenn die Lockerungen der Corona-Massnahmen einsetzen und eine Mehrheit
der Nutzenden wieder Vorort arbeiten werden, rechnen wir mit deutlich
Hoeherem Netzwerk-Traffic in Richtung neue Linux-Firewalls.

Nach Abwarten der notwendigen Zeit um genuegend Metriken sammeln und die
Performance der Linux-Firewall unter nicht-Homeoffice-Bedingungen
beurteilen zu koennen, werden wir im IT-Board und Architektur-Board ca.
Mitte/Ende Juni die Diskussion fuehren, ob und unter welchen
Voraussetzungen wir die Checkpoint-Firewall vollstaendig und schon
fruehzeitig abloesen koennen (Checkpoint ist EOL im 2021, ein
entsprechender Budget-Posten ist vorgesehen):

  * die Linux-Firewall ist um Groessenordnungen schneller (sowohl
    Bandbreite, insbesondere aber auch Latenz) als die Checkpoint-
    Firewall (unabhaengig von IPS).

    Aktuell ist das Netz fuer alle Clients in Richtung Internet
    und in Richtung BFH.science sehr schnell. Wir wollen, dass auch
    die BFH.ch Server optimal erreichbar sind, von aussen wie von
    innerhalb der BFH.

  * der Betrieb der Linux-Firewall ist durch Team LNI intern
    breit abgestuetzt/sichergestellt und viel einfacher/moderner.

    Fuer jegliche Aenderungen an der Checkpoint-Firewall und das ganze
    damit zusammenhaengende Tagesgeschaeft sind wir auf Externe
    angewiesen, die bei uns das "alte Netz" (bestehend aus Cisco- und
    Checkpoint) betreiben.

    Dies ermoeglicht uns nicht nur eine grundsaetzliche Zeit- und
    Kostenersparnis, sondern auch eine schnelle Umsetzung von Mutationen
    fuer unsere Nutzenden, was bis anhin nie moeglich war.

  * das bestehende Regelset auf der Checkpoint-Firewall hat viele
    Altlasten die wir mit Uebernahme des Netzverantwortung zur
    Erledigung geerbt haben.

    Durch das Neuschreiben der Regeln fuer die Linux-Firewall kann
    dies systematisch und effizient angegangen werden.

  * der aktuelle Hinderungsgrund fuer IPv6 im BFH.ch Netz ist/war
    die Checkpoint Firewall. Mit der Linux-Firewall ist IPv6
    kein Problem und wir kommen unserem Ziel, IPv6 zuegig im BFH.ch
    Netz zur Verfuegung zu stellen, einen Schritt naeher.

  * da wir Linux-basierte Systeme im Gegensatz zu geschlossenen
    Appliances von kommerziellen Herstellern effizienter und effektiver
    in unsere bestehende IT Umgebgung integrieren koennen, ist nicht nur
    ein Self-Service fuer Port-Oeffnungen via Git durch andere Personen
    innerhalb und ausserhalb der IT-Services moeglich (was unseren
    Betriebsaufwand minimiert), sondern es wird auch die Automatisierung
    beim Erstellen von neuen Systemen ermoeglicht.

    (z.B. kann so die Firewall automatisch fuer Port 80 und 443 beim
    Erstellen eines neuen Webserver geoeffnet werden; beim Loeschen des
    Containers koennen die Regeln automatisch wieder entfernt werden).

Wir halten euch auf dem Laufenden wie es weiter geht.


3. Bemerkungen zur Moodle
=========================

3.1 Eingeschraenkte Performance
-------------------------------

Durch die oben erwaehnten Latenz-Vergroesserungen durch den Wechsel auf
die alte Firewall-Hardware ist Moodle bis auf Weiteres dauerhaft
langsamer/traeger als vorher (wieder auf gleichem Stand wie vor Ende
2019, bevor die Leih-Firewall eingesetzt wurde).

Durch den Wechsel auf groessere Disk und das damit zusammenhaengende
Resync des RAID1-Arrays, ist Moodle bis morgen um 10 Uhr speziell was
Disk I/O intensivere Anfragen/Operationen angeht, langsamer.

Wir haben fuer die Nacht die Prioritaet fuer den Resync maximiert und
werden diesen ab 6 Uhr morgens wieder minimieren. So kann einerseits
die Gesamtdauer des Resyncs minimiert werden, andererseits ist trotz
allem ein fluessiges Arbeiten mit Moodle gewaehrleistet.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science