Zum Inhalt

blog.meerfarbig.net Beiträge

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

Deploying RPKI Validation / RPKI invalid == reject!

We recently deployed RPKI invalid == reject! on our eBGP Routers after RPKI Validation was already enabled for about one year with Local-Pref 10 for invalids. To fulfill the purpose of RPKI and help to make the internet a more secure place someone must start to deploy those security mechanisms. I hope we see a lot more networks to follow in future.
Following for example bgpstream on Twitter you get an idea how many hijacks are created day per day by intention or on human error. Help to prevent installing those on your tables (if RPKI is enabled for those prefixes) is quite easy:

First of all one would need a working RPKI Validator. RIPE provides a good one which is easy to install: https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources

Routers will need a Connection to the Validator to get the database:

routing-options validation 
group rpki-validator {
    session x.x.x.x {
        refresh-time 120;
        hold-time 180;
        port 8282;
        local-address x.x.x.x;
    }
}

Check if connection works:

show validation session     
Session                                  State   Flaps     Uptime #IPv4/IPv6 records
x.x.x.x                               Up          0 66w0d 10:49:31 45816/8263
show validation database

To get our routes checked and apply the validation-state / reject the invalids we create a policy which can be added to our BGP Peer(s) Import statement:

show policy-options policy-statement rpki 
term validation {
    from {
        protocol bgp;
        validation-database valid;
    }
    then {
        validation-state valid;
        next policy;
    }
}
term validationunveri {
    from {
        protocol bgp;
        validation-database unknown;
    }
    then next policy;
}
term validationinvalid {
    from {
        protocol bgp;
        validation-database invalid;
    }
    then {
        validation-state invalid;
        reject;
    }
}

 

Make sure that iBGP Sessions will exchange the validation states via a community on other routers or import rpki policy on iBGP sessions.

What to expect:
After the deployment you’ll see (depending on peer) about 4700 invalids which will be rejected. About 50% of them are covered by less specifics so you won’t loose connectivity to those. The rest will be dropped but after running the reject policy for about one week we didn’t receive any complaints about reachability issues.

(IPv4 Distribution only), everything works as well for IPv6.

Looking forward that the green piece of cake will grow.

So long 🙂 Get things running!

[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“.

Spider KVM unter macOS

Um die Remote Console unserer Spider KVM’s unter macOS zu öffnen gehen Sie bitte wie folgt vor:

-> System Preferences öffnen
-> Java Controlpanel öffnen
-> Dort unter Security -> Exception Site List die Adresse der Spider eintragen (https://spider1.meerfarbig.net oder https://spider2.meerfarbig.net)

Java Control Panel 2018-01-08 11-18-51

-> Einloggen auf der Spider
-> „KVM Console“ klicken und downloaden

Spider 2018-01-08 11-19-52

-> Datei behalten/keep und öffnen

Monosnap 2018-01-08 11-20-06

-> Erneut die System Preferences öffnen und unter „Security und Privacy“ das öffnen der Datei erlauben „open anyway“.

Security & Privacy 2018-01-08 11-20-26

Die Remote Console sollte nun funktionieren.

ESXi MegaCLI installieren

Um auf einem ESXi Server der Version 5 oder 6 den Raidstatus eines LSI Controllers via MegaCLI anzuzeigen oder andere Raidoperationen durchzuführen sind folgende Schritte nötig:

– Aktivieren von SSH auf dem ESXi Host
– Das Softwarepaket via Shell installieren

esxcli software vib install -v http://mirror.meerfarbig.de/tmp/vmware-esx-MegaCli-8.07.07.vib –no-sig-check

– Abfragen des Raidstatus

/opt/lsi/MegaCLI/MegaCli -LDInfo -Lall -Aall

Router Upgrade

Willkommen im Team!
Ab kommenden Donnerstag wird unser Netzwerk durch eine Juniper MX240 unterstützt. Wir schaffen somit eine weitere Redundanz sowie Expansionsmöglichkeiten für unsere Außenanbindung.

meerfarbig GmbH & Co. KG - AS34549