Zum Inhalt

Kategorie: Security

Dedicated Server and ARIN IP (hijack) Announce

Wir bekamen kürzlich eine Anfrage für einen dedizierten Server mit dem Zusatz ob wir auch ARIN IPs dazu announcen könnten was wir erstmal auch angeboten haben.
Nach Rechnungsstellung und Bezahlung der Rechnung via PayPal bekamen wir dann eine LOA zugesandt die auf den zweiten Blick doch etwas merkwürdig aussah:

Erstmal mag man sich fragen: Okay, das sind jetzt aber doch einige Netze. Dazu ein schlecht aufgelöstes Logo und eine nicht so originelle Signatur aber öffnen wir doch mal diese ARIN Datenbank und schauen uns Beispielsweise das Netz 66.240.203.0/24 an:

Auf den ersten Blick zu diesem /24 sehen wir, dass NET66 – 66.0.0.0/8 ARIN zugeordnet ist und eine Direct-Allocation 66.240.192.0/18 an CARINET (CariNet, Inc.) erfolgt ist aber eben auch, dass das betreffende 66.240.203.0/24 CANTECH-LLC (Net Type:Reassigned) zugeordnet ist. Öffnen wir nun das Objekt: CANTECH-LLC (NET-66-240-203-0-1) sieht es wie folgt aus:

Voila: Origin AS34549 – sollte ja irgendwie als Beweis reichen, dass wir das Netz announcen dürfen oder? Es wurde sogar ein Objekt für 203.240.66.in-addr.arpa. angelegt: Beide NS haben die gleiche IP und liegen bei OVH. In den POC Records stehen überall die Daten die der Besteller bei uns auch angegeben hat – allerdings fehlt überall die Spur von der Firma „Thrace LLC“ die uns ja eigentlich die LOA ausgestellt hat??? Fragen wir doch vielleicht mal bei Carinet Abuse nach:


AHA! Kam mir doch gleich komisch vor ABER: (Ich hoffe auf etwas Hilfe) – Wie kann es sein, dass jemand so etwas in der ARIN Datenbank ohne Zustimmung von Carinet erstellen kann? Daniel von Carinet habe ich diese Frage eben auch gestellt und hoffe auf eine Antwort. Das Schema ist für alle Netze in der LOA relativ gleich und betrifft nicht nur Carinet sondern auch andere Unternehmen die auf diese Weise wohl Teile Ihrer Netzbereiche entführt bekommen. Ich habe deren Abuse Mailadressen größtenteils angeschrieben.


Update #01 – 24.12.2019 – 00:27


Update #02 – 24.12.2019 – 00:35

Rätsel gelöst: Es gibt wohl ARIN Point of Contact (POC) Records, deren (E-Mail) Domains expired sind. Die Domains werden dann neu registriert, ein ARIN Account wird erstellt und man kann verknüpfte Netze zu dieser POC E-Mail ändern.

RPKI Validation / Change Prefix ASN / Wie man es nicht macht @LibertyGlobal

Heute morgen bekamen wir diverse Mails von Kunden die von Unitymedia Ihre Server bei uns nicht mehr erreichen konnten.
Nach dem Erhalt diverser Source-IPs schaute man sich die installierten Routen zu Unitymedia an (hier z.B. 46.5.0.0/17):

46.5.0.0/17 [BGP ] 10:12:43, localpref 100
AS path: 1299 6830 I, validation-state: invalid
> to 62.115.154.120 via xe-1/2/0.104
[BGP ] 10:12:57, MED 0, localpref 100
AS path: 3257 6830 I, validation-state: invalid
> to 78.152.37.242 via ae0.1201

Ein kurzer Check auf unserem als auch auf dem RIPE RPKI Validator bestätigte dieses Ergebnis:

Was war passiert: Das Netz 46.5.0.0/17  (und diverse andere) wurde vormals von AS29562 Unitymedia BW GmbH announced und hatte dort einen korrekten ROA Eintrag. Vor ca. 12 Stunden wurden wohl mehrere Netze (inkl. 46.5.0.0/17) von AS29562 nach AS6830 Liberty Global migriert ohne entsprechende ROA Einträge dafür anzulegen.

Was machen unsere Router in so einem Fall: Wir prüfen alle Routen auf deren ROA Einträge um Route-Leaks vorzubeugen. In solch einem Fall wird die neue Route via AS6830 rejected/nicht installiert da AS6830 laut ROA nicht berechtigt ist diesen Prefix(e) zu announcen.

Bislang hat sich an diesem Zustand auch nichts geändert. Wir haben diverse Prefixe die nun via AS6830 announced werden unserem Ignore Filter zugeführt damit Kunden hinter Unitymedia Ihre Systeme erreichen können.

ASN History von z.B. 46.5.0.0/17

RPKI Status on RIPEstat:

Wenn seitens des Liberty Global NOCs alles ordentlich für den Umzug vorbereitet gewesen wäre, hätte es auch zu keiner Beeinträchtigung geführt.

 

Update #1: 16.04.2019, 11:50 Uhr

Alle ROAs scheinen aktualisiert:

46.5.0.0/17 *[BGP/170] 10:55:29,
AS path: 3257 6830 I, validation-state: valid
> to 78.152.37.242 via ae0.1201
[BGP/170] 10:55:15
AS path: 1299 6830 I, validation-state: valid
> to 62.115.154.120 via xe-1/2/0.104
[BGP/170] 00:39:56
AS path: 3320 6830 I, validation-state: valid
> to 80.157.131.225 via xe-2/2/0.60

[SECURITY] CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 – BIOS Updates

Wie Sie in der letzten Woche vermutlich mitbekommen haben gibt es aktuell eine Sicherheitslücke von der fast alle von uns eingesetzten Intel CPUs betroffen sind.

Bislang kann die Lücke unter Linux mit einem einfachen System Update inkl. Reboot behoben werden was sich ggf. auf die Performance des Systems auswirkt.

Um den Fehler mit einem Microcode Update auf Hardwareseite zu beheben wird es in den nächsten Tagen von Supermicro neue BIOS Versionen geben.

Eine Liste der bislang verfügbaren BIOS Updates kann hier eingesehen werden: https://www.supermicro.com/support/security_Intel-SA-00088.cfm?pg=X10#tab

Gerne führen wir für Sie ein BIOS Update durch oder stellen einen USB Stick mit der aktuellen Version am Server bereit. Für viele der eingesetzten Boards gibt es (Stand heute) allerdings von Supermicro noch kein Update bzw. der Status ist noch „pending“.

meerfarbig GmbH & Co. KG - AS34549