Die schützende Mauer (I)

Eine Netzwerk-Firewall – egal welcher Herkunft – ist nur so gut wie der Fachmann, der davor sitzt und sie „firmenindividuell“ konfiguriert.

So eine Firewall kann je nach interner Subnetz-Bildung und eigener unternehmerischer Qualität nicht nur in der Anschaffung, sondern auch bezüglich der jährlichen Kosten ganz schön ins Geld gehen. Dennoch: ganz alleine macht weder eine kommerzielle Sophos alles richtig, noch eine Fortigate oder eine Cisco. Hersteller-gebundene Hardware-Appliances bieten dem externen Betreuer zur Konfiguration und Wartung eine öffentlich erreichbare Plattform beim Hersteller, um alle Firewalls, die bei Kunden aufgestellt wurden, zentral verwalten zu können.

Aus eigener Erfahrung habe ich gelernt, dass auf die Firewalls in der Ferne jedoch nur dann ein Auge geworfen wird, wenn der Kunde sich dazu meldet, Wartungsvertrag hin oder her. Zentralisierte Wolken sind immer ein lohnendes Angriffsziel, wie auch die mittlerweile auf Internet-Plattformen veröffentlichten Zutrittskontrollen für Fenster, Türen und Toren zu Firmengebäuden. Und beim Angreifer reden wir nicht vom pickeligen, antisozialen Bleichgesicht im Hinterzimmer sowohl seiner Eltern als auch ihrer Vorstellung – wir reden von Staaten, die hochqualifiziertes Fachpersonal zahlen, um anderen die Suppe zu versalzen: dagegen gibt es kein „Atom-Abkommen“, keine Weltpolizei und keine Großmacht. Wer weiß also, wer Ihren Netzwerk-Verkehr jetzt schon mitliest, anstelle des Betreuers und wer nächtlich in Ihrer Firma ein und aus geht, neben den Mitarbeitern mit RFID-Chip am Schlüsselbund?

Ebenso aus eigener, langjähriger Erfahrung weiß ich, dass Gespräche mit den an jeder Ecke im Dutzend lauernden Verkäufern sehr lange und sehr häufig stattfinden und immer eine bunte Welt voller Möglichkeiten hinterlassen. Gespräche mit den immer rarer werdenden, kompetenten und engagierten Technikern werden im Vergleich dazu ebenso kurz gehalten wie deren Zeitspanne zur individuellen Implementation und sinnvollen Konfiguration auch des teuersten Equipments. Psychologen erklären das mit einem Schichten-Modell: man versteht sich einfach besser unter seinesgleichen, ob das nun gemeinsamer, guturaler Gesang oder das Gespräch mit dem steten Anklang lauer Lüftchen wedelnder Geldscheine ist. Beste Zeiten für Hacker und andere Fachleute, schlechte Voraussetzungen für Bahnhöfe und Flugplätze, außerdem eine einschneidendere Zäsur als der nächste Corona-Virus in der Entwicklung der Menscheit.

Die freien Firewall-Lösungen stehen den Lösungen des „IT-Channels“ in den vielzähligen Schutzfunktionen sowohl auf dem Netzwerk- als auch auf dem Appliance-Level in nichts nach, im Gegenteil. Eine Klickibunti-Administrierbarkeit wurde dabei in den vergangenen zwei Jahrzehnten parallel zu jener in den mehrere tausend Euro pro Jahr teuren Lösungen ebenso ausgebaut wie eine modulare Erweiterbarkeit. Aus ihrer Natur heraus legen OpenSource-Lösungen ihren Fokus nicht darauf, den Benutzer möglichst in ein proprietäres Korsett zu schnüren: den Kampf mit abgelaufenen Lizenzen oder inkompatiblen VPN-Verbindungen überlassen sie den kommerziellen Lösungen. Frei denkende Programmierer konzentrieren sich auf „KI“, wo sie vom Benutzer gebraucht wird. Wieso „KI“ gerade bei uns in Deutschland gerne mit „Kommerziellem Interesse“ falsch interpretiert wird, muss an unserer Historie liegen.

Quellen u.a.:

Netzwerk-Troubleshooting

mit Methodik (nicht kreuz & quer, sondern mit Plan) und Intuition:

  • Divide and Conquer
    – Prinzip des optimalen Zahlenratens: in der Mitte anfangen, nach oben oder nach unten korrigieren („agile Wegfindung“); ausgehend von der Mitte entscheidet man, ob es sich um ein Netzwerk- oder Anwendungsproblem handelt
    – beginnend in der Mitte des OSI-Modells, Test der Netzwerkebene (Layer 3), z.B. mit Ping
    – dann je nach Ergebnis schichtweise nach unten (Data Link Layer, Physical Layer) oder nach oben (Transport Layer, Application Layer) vorarbeiten
  • Follow the Path
    – dem Weg der Kommunikation von Quelle zum Ziel folgen
    – wird eingesetzt, wenn ausgeschlossen werden kann, dass der Fehler auf den Kommunikations-Endpunkten (Server, Client) liegt
  • Spot the differences
    – Vergleich SOLL-IST-Zustand
    – Vergleich mit verschiedenen, alternierenden Konfigurationen
  • Top-Down
    vom OSI-Modell ausgehend wird versucht, zunächst ein Problem in der Anwendungsschicht (Application Layer 5 bis 7) auszuschließen und sich weiter von oben nach unten zu arbeiten
  • Bottom-Up
    wie Top-Down, nur vom Physical Layer 1 hochwärts

„Netzwerk-Troubleshooting“ weiterlesen

Serverdienste II

Ports als (virtuelle) Schnittstellen zur Außenwelt des Rechners, bestehend aus 16-bit Zahlen, sind auf den OSI-Schichten 5 bis 7 zu finden.

Die Gruppeneinteilung der IANA (Internet Assigned Numbers Authority):

  • 0 bis 1.023: Well Known Services (durch ICANN, Internet Corporation for Assigned Names and Numbers, ein Unternehmen mit ca. 300 Mitgliedern, definiert)
  • 1.024 bis 49.151: registrierte Ports
  • 49.152 bis 65.535: dynamische/private Ports

Die Adressvergabe für öffentliche IP-Adressen hat die IANA an die ARIN (American Registry for Internet Numbers) übertragen, die diese Aufgabe wiederum an  weitere NICs (Network Information Center) bzw. Domain Name Registries delegiert, die Domains über Registrare zuteilen. So wird dem Endkunden (Domain-Registrant) ein Markt mit konkurrierenden Registraren eröffnet.

Serverdienste

„Serverdienste II“ weiterlesen

Namensauflösung

oder: Die wilden 13 Rootserver des DNS

DNS-NamensauflösungMerke:

  • Forward-Lookup: Auflösung DNS-Name in IP-Adresse
  • Reverse-Lookup (PTR): Auflösung IP-Adresse in DNS-Name
  • rekursiver DNS-Request: erwartet direkte, vollständige Antwort oder Auflösungsfehler; der angefragte Nameserver muss eine konkrete Rückmeldung liefern
  • iterativer DNS-Request: durch Annäherungsverfahren (Iteration) Abfrage verschiedener DNS-Server von TLD bis DNS-Zone (entspricht in der Regel einer Domain); der angefragte Nameserver kann mit einem Verweis auf den nächsten zu befragenden Nameserver antworten

DNS-Eintragstypen (RRs):

  • A (host): Auflösung von Hostname zu IPv4-Adresse
  • AAAA: Auflösung von Hostname zu IPv6-Adresse
  • CNAME (Canonical Name): Alias auf einen A- oder AAAA-Eintrag
  • NS: zeigt auf einen Nameserver (NS), der für die Zone verantwortlich ist
  • MX: zeigt auf einen Mailserver (Mail Exchanger, MX), der für die Zone verantwortlich ist
  • PTR: nur in Reverse-Lookup-Zonen, ein Pointer auf einen Namen

Eine Zonendatei startet mit einem SOA-Eintrag („Start of Authority“,  Beginn der Zuständigkeit). Das Zeichen @ ist Platzhalter für die Domäne in der Zonendatei. Der erste Punkt in der folgenden Administrator-eMail-Adressangabe wird immer durch das @-Zeichen ersetzt.

An anderen Stellen bildet der „.“ den Root-Punkt (oberste Ebene). Der Punkt am Ende der Zeilen IN NS – Einträgen u.a. verhindert die Suche nach dem jeweiligen NS-Namenseintrag zuzüglich der Domäne der Zonendatei.
IP-Adressen sind in NS-Records nicht erlaubt. Wird ein eigener Nameserver verwendet, muss zusätzlich der passende A-Record definiert und Glue bei der Domainregistation angeben bzw. die Nameserver vorher bei den Registraren registriert werden.

Überprüfung:

$ nslookup
> localhost
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: localhost.intern.gebsattel.rocks
Address: 213.133.103.43
> router.intern.generica.net
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: router.intern.generica.net
Address: 192.168.15.254

> rhel01.intern.generica.net
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: rhel01.intern.generica.net
Address: 192.168.15.10
> gebsattel.rocks
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: gebsattel.rocks
Address: 213.133.103.43
> set q=mx
> gebsattel.rocks
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
gebsattel.rocks mail exchanger = 10 webmail.generica.net.

Andere Namensdienste:

  • NetBIOS (Network Basic Input Output System): altes, immer noch aktives Protokoll unter Windows (Subkomponente NBNS: NetBIOS Name Service); flacher Namensraum, max. 15 Zeichen, das 16. Zeichen bezeichnet den Dienst des angegebenen Namens (host, Gruppe o.ä.), Namensauflösung per Broadcast (!)
  • WINS (Windows Internet Name Service): veralteter Windows-Namensdienst ohne aktuelle Bedeutung, MS-Extrawurst („proprietär“) analog zum Standard DNS
  • NIS (Interoperable Naming Service): Spitzname „Yellow Pages“, weitgehend durch LDAP und Kerberos ersetzt
  • LDAP (Lightweight Directory Access Protocol): Namens- und Verzeichnisdienst, Basis für MS-Extrawurst („proprietär“) Active Directory u.v.a.
  • JNDI (Java Naming and Directory API): Namens- und Verzeichnisdienst, Einsatz bei Datenbank-Systemen, ermöglicht Interaktion mit DNS, NIS, LDAP etc.
  • LLMNR (Link Local Multicast Name Resolution): Namensauflösung im lokalen Netzsegment (Link Local), existiert unnötigerweise seit Windows Vista, ist ein reiner IPv6-Dienst und ersetzt NBNS unter IPv6, ist dabei aber noch gesprächiger (!!)

Wo kommt’s her…

…wo geht’s hin?

Die Abschaffung der Klassengesellschaft! Aufgrund von rund 600.000 Einträgen in der Tabelle eines „durchschnittlichen“ Routers im Internet zu Zeiten der Klassennetze und keiner einheitlichen Vergabe von IP-Adressen an Institutionen und Organisationen wurden folgende Lösungen gefunden:

CIDR (Classless Inter-Domain Routing): RFCs 1518/1519 führten ein hierarchisches Routing, VLSM (Variable Length Subnet Mask) und die Präfix-Schreibweise (Anzahl der gesetzten Bits in der Subnetzmaske) ein. Das ermöglicht die beliebige, optimale Aufteilung des Ausgangsnetzwerk ohne viel „IP-Adressen-Verschnitt“ und Optimierung durch Routen-Zusammenfassung (Supernetting und Route Summarization).

Subnetz-Maske mit VLSM

Bit-Hilfstabelle

Fazit: Klassennetze sind seit Einführung des VLSM ebenso nur noch Subnetze!

RFC 1918 legt private Adressbereiche fest, als letzte Angabe in CIDR-Schreibweise (Netzanteil/Subnetz-Bits):

  • Klasse A: 10.0.0.0 – 10.255.255.255 / 255.0.0.0 – 10/8
  • Klasse B: 172.16.0.0 – 172.31.255.255 / 255.255.0.0 – 172.16/12
  • Klasse C: 192.168.0.0 – 192.168.255.255 / 255.255.255.0 – 192.168/16

Das Klasse A – Netz 127.0.0.0 / 255.0.0.0 ist als Loopback-Netz bei jedem System reserviert und wird nicht über die physische NIC, sondern direkt in der TCP/IP-Logik verwaltet. „localhost“ löst bekanntlich über 127.0.0.1 („die loopback-Adresse“) auf.

„Aus dem Internet“ kommen Antworten auf Anfragen nur per NAT (Network Address Translation) zurück zum System im internen Netzwerk.

Bekommt das System weder per DHCP noch manuell eine IP-Adresse und Subnetzmaske, greift Zeroconf (RFC 3927) [bzw. die Microsoft-Extrawurst APIPA (Automatic Private IP-Adressing)] und das System weist sich selbst eine zufällige, nicht besetzte IP-Adresse aus dem Klasse B – Netz 169.254.0.0 / 255.255.0.0 zu.

Daneben gibt es noch die unspezifische IP-Adresse 0.0.0.0 / 0.0.0.0, die den gesamten Adressbereich umfasst und sowohl im Rahmen der DHCP-Aushandlung als Client-Startadresse eingesetzt wird, als auch als Ziel für die Default-Route.

Attention! Trotz aller Layer-3-Logik der Broadcast-Domäne findet der Austausch von IP-Paketen in einem Subnetz über die MAC-Adressen der NICs statt – deswegen auch die ARP-Tabelle, in der vor jedem Austausch (auch ICMP/ping!) erst geklärt wird, welche MAC-Adressen als Ziel- und Quelladressen hinter den IP-Adressen stecken.

Beim Routing über das Gateway heißt das, dass ein externes System zur Kommunikation die MAC-Adresse der Schnittstelle des Gateways für seine IP-Adresse bekommt!

Der IP-Header

Ein „Word“, der Header eines IP-Paketes:

IP-Header: ein Word

(alle Zeilen im Screenshot untereinander stehen im IP-Header hintereinander)

Die Länge des IP-Headers kann bis 32 Bit gefüllt werden (mit Options and Padding), ist aber meistens 20 Bit lang.

Protocol: welches Protokoll wird von IP transportiert. Mögliche Werte z.B.:

  • TCP: 6
  • UDP: 17
  • ICMP: 1

Type of Service (ToS-Feld): DSCP (Differenciated Services Code Point) – bestimmte Art der Interpretation dieses Feldes, die die Priorisierung regelt und die verschiedenen Bits, die gesetzt sind, entsprechend auswertet

Identification, Flags, Fragment Offset: nur relevant, wenn das IP-Paket fragmentiert wurde

TTL (Time to Live, Wert zwischen 0 und 255): Anzahl der möglichen Sprünge über Router, wird von jedem Router um -1 auf 0 reduziert, bevor das Paket verworfen wird zur Vermeidung von Endlos-Zirkulation bei Routing-Schleifen . Bei 0 liefert der Router eine TTL-exceeded-Meldung zurück.

Durch die IP-Adresse aus vier Bytes (z.B. 010.000.027.001) wird ein System im Netzwerk logisch adressiert, die physische Adresse eines Systems ist die MAC-Adresse.

Kommunikation über IP-Adressen ist eine Ende-zu-Ende-Kommunikation.

Ein Oktett: ein Byte sind 8 Bits, Wertebereich 0-255.
Die IP-Adresse wird durch die Subnetzmaske (RFC 950) vervollständigt. Die Subnetzmaske besteht aus Netzanteil (Bereich, in dem das System angesiedelt ist) und Hostanteil (der eindeutige Identifizierer des Systems innerhalb des Subnetzes), verknüpft mit logischer UND-Operation zur Netzadresse:

Die Subnetzmaske
Reservierte Adressen:

  • die Subnetz-Adresse – alle Bits im Hostanteil stehen auf 0 (z.B. 10.0.27.0 bei 255.255.255.0) – ist die erste verfügbare Adresse im Netz und bezeichnet alle Systeme, die IP-Adressen in diesem Subnetz haben: Einsatz beim Routing als Ziel.
  • die Broadcast-Adresse – alle Bits im Hostanteil stehen auf 1 (z.B. 10.0.27.255 bei 255.255.255.0) – ist die letzte verfügbare Adresse im Netz und wird benutzt, um alle Systeme, die IP-Adressen in diesem Subnetz haben, anzusprechen: ein Rundruf an alle Systeme.

Subnetze werden benötigt, um die Netzwerklast zu reduzieren und Bandbreite zu sparen. V.a. Windows ist sehr gesprächig und nutzt z.B. Broadcast sehr exzessiv: das Internet wäre ohne Subnetze „dicht“! Zudem werden Verantwortlichkeiten für Netzsegmente aufgeteilt. Durch Subnetting ist ein Schutz von Systemen möglich.

Die Netzklassen (Classful Networks):
(einzige Festlegung der Netzwerk-Größe vor Einführung der Subnetzmasken mit RFC 950)

Netzklassen 1 Netzklassen 2

Und: wer hat’s erfunden? https://tools.ietf.org/html/ !!

Spickzettel-Download

All experts are turkeys…

Bezug nehmend auf den immer wieder äußerst beachtenswerten Vortrag von Pragmatic Dave fällt mir nach stundenlangem Lernen in Kursen immer deutlicher auf, wie viel Idiotie wir Experten uns schuldig machen. Und wie „das Internet“ als freie Kommunikations- und Wissenstechnologie und die OpenSource-Philosophie als Fortsetzung des menschlichen Strebens nach Freiheit uns davon heilt!

Früher gab es doch einige höchstbezahlte Fachleute, die mit „sh vl br“ uva. auf der Cisco-Kommandozeile Eindruck schinden konnten. Solches Pseudo-Fachwissen über proprietäre Systeme – das auch im Falle von SAP und MS Dynamics NAV (uva.) immer wieder Rechnungen für marginale Leistungen in schwindelerregende Höhen steigen und Firmen mit ihren Investitionen in der Sackgasse landen lässt – ist glücklicherweise überholt: Wissen braucht keine Macht!

IT kann einfach bleiben, wenn der Benutzer das als Voraussetzung festsetzt. Automaten sind nicht dazu erschaffen worden, den Menschen Untertan zu machen und werden das auch nie machen, denn sie wollen nichts.

Maximal der Kapitalismus macht in unserer Zeit und unserer ersten Welt manche Menschen zu Untertanen. Die wollen das aber auch nicht anders: chacun à son goût.

Auf dem Boden bleiben…

Heimarbeit. Pause von Verzweigungen, Schleifen, Funktionen und Eigenschaften. Back to the roots:

ISO-OSI Schichtmodell

Eric Amberg und das CompTIA Network+ Examen. „Aus internen Kreisen“ habe ich heute erfahren, dass es die Lehrer ganz schön schwer haben: die Plattform, auf der sie „virtuelle Klassenzimmer“ einrichten sollen, ist schwer überlastet – und wurde bereits von Schülern gehackt.

So. Suche Haus in Kroatien!
(Kuća tražena na prodaju u Hrvatskoj!)

Wir wiederholen…

Meine Empfehlung: der Kurs „Spring framework 5: Beginner to Guru, den ich im Februar 2019 angefangen habe, um die Basics von JHipster besser zu verstehen.

John Thompson erneuert in diesem Kurs zudem „deprecated Videos. Das mag erst einmal nerven („Bekomme ich den Kurs denn nie zu Ende…), dient aber auch zur Wiederholung.

Zum prinzipiellen Verständnis des Spring frameworks zählen sicher die

SOLID principles of OOP:

I.) Single Responsibility Principle

Single Responsibility Principle

  • Jede Klasse sollte eine Zuständigkeit verwalten
  • Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern
  • Die Klassen sollten klein sein – nie mehr Code als auf einen Bildschirm passt
  • „Göttliche“ Klassen sollten vermieden werden
  • Große Klassen sollten in kleinere Klassen aufgeteilt werden

II.) Open-Close Principle

Open-Close Principle

  • Eine Klasse sollte offen für Erweiterungen sein
  • Eine Klasse sollte geschützt sein vor Änderungen
  • Es sollte möglich sein, das Verhalten einer Klasse zu ändern ohne die Klasse selbst zu ändern
  • Es sollten private Variablen mit Gettern und Settern verwendet werden – letztere Methoden ausschließlich dann, wenn diese gebraucht werden!
  • Es sollten wann immer möglich abstrakte Basisklassen verwendet werden, in denen den erbenden Klassen ggf. abstrakte Methoden zur Implementierung vorgegeben werden

III.) Liskov Substitution Principle (Barbara Liskov, 1998)

Liskov Substitution Principle

  • Objekte innerhalb eines Programms sollten austauschbar sein mit Instanzen ihrer Subtypen ohne die Korrektheit des Programmes zu ändern
  • Ein Verstoß gegen dieses Prinzip kann oft entdeckt werden mit dem „… ist ein …“-Test: ein Quadrat ist ein Rechteck
  • Jedoch: ein Rechteck „ist kein“ Quadrat!

IV.) Interface Segregation Principle

Interface Segregation Principle

  • Interfaces sollten detailliert und client-spezifisch (spezifisch für einen Anwendungsfall) ausgearbeitet sein
  • Eine Vielzahl client-spezifischer Interfaces ist besser als ein „Universal-Interface“
  • Alle Komponenten sollten fokussiert bleiben und Abhängigkeiten untereinander sollten vermieden werden
  • Der Zusammenhang zum Single Responsibility Principle ist offensichtlich: „göttliche“ Interfaces sollten vermieden werden

V.) Dependency Inversion Principle

Dependency Inversion Principle

  • Abstraktionen sollten nicht von Details abhängen
  • Details sollten von Abstraktionen abhängen
  • Es ist wichtig, dass Objekte höherer Ordnung und Objekte niedrigerer Ordnung von derselben abstrakten Interaktion abhängen
  • Dependency Inversion nicht mit Dependency Injection verwechseln! Dependency Injection beschreibt, wie Objekte die weitere Objekte erhalten, von welchen sie abhängig sind