Author: Andreas Worbs

DDoS Protection bei Artfiles

Die zusätzliche DDoS-Protection können wir Ihnen in fast allen von uns angebotenen Tarifen anbieten. Im Webhosting erhalten Sie zum Schutz Ihrer Domains eine eigene IPv4-Adresse, in einem af.stack, Dedicated Server oder Rackspace Tarif können Sie alternativ auch ein eigenes Prefix erhalten.

DDoS – was ist das eigentlich?

DDoS – jede, die mit Servern oder Domains zu tun hat, wird dieses Wort vermutlich schonmal gehört haben. Aber was ist ein DDoS?

DDoS steht für Distributed Denial of Service und bezeichnet das gezielte Außerbetriebsetzen von Diensten. Hierbei agieren viele unterschiedliche Server zusammen gegen das gewünschte Ziel, dabei soll meist eine Domain oder ein ganzer Server mit so vielen Anfragen überhäuft werden, dass diese nicht mehr erreichbar sind.

Die Art der Angriffe kann dabei variieren, lassen sich jedoch eingruppieren in Angriffe auf Netzwerkebene (Layer 3/4) oder Anwendungsebene (Layer 7).

Einschub: Die Layer beziehen sich auf das in der IT gängige OSI-Modell. Ausführliche Erklärungen hierzu finden Sie z.B. bei Wikipedia.

Auf Netzwerkebene sind z.B. SYN-Floods eine beliebte Art von Attacken. Hierbei macht man sich den Threeway-Handshake des TCP-Protokolls zu Nutze, dabei sendet der Client erst ein Paket mit dem SYN-Flag an den Server, dieser antwortet mit einem SYNACK und der Client bestätigt nochmal mit einem ACK. Erst dann ist eine Verbindung über das TCP-Protokoll aufgebaut. D.h. bei einem Angriff erhält der Server meist Hunderttausende oder Millionen an Paketen mit diesem SYN-Flag und müsste diese theoretisch alle beantworten, was durch die schiere Masse an Paketen gar nicht mehr möglich ist und somit können auch legitime Anfragen nicht mehr beantwortet werden – die Angreifer haben ihr Ziel erreicht.

Auf Anwendungsebene sind Angriffe sehr viel schwieriger auszumachen, da sich die Angreifer zumeist “normale” Anfragen schicken. Das Prinzip ist aber wieder dasselbe, es werden z.B. so viele Anfragen an eine Domain geschickt, dass der Webserver diese Anfragen nicht mehr abarbeiten kann bzw. nur sehr langsam, wodurch dann auch hier wieder legitime Anfragen nicht mehr durchkommen.

Was können wir dagegen tun?

Unser Netzwerk kommuniziert mit anderen Netzwerken über leistungsstarke Juniper Router, die ohne Probleme größere Mengen an Paketen oder Bandbreiten abarbeiten können, jedoch greifen hier keine Abwehrmaßnahmen. Diese sind auf den dahinterliegenden Firewalls möglich. In der Colocation haben wir mehrere Firewalls, welche aus zwei redundanten Servern bestehen und natürlich rund um die Uhr gemonitort werden. Diese Redundanz erlaubt es uns z.B. Limits auf einem Server entsprechend anzupassen und angegriffene Kundennetze auf einem Server zu isolieren.

Die Abwehr von DDoS-Angriffen auf unseren Firewalls ist natürlich nur bis zu einem gewissen Grad möglich und hier kommt dann unser Partner Path Network in Spiel.

Wie läuft das denn mit Path Network?

Seit August 2023 ist Path Network unser Partner für DDoS-Protection. Path Network ist spezialisiert auf die schnelle Erkennung und Abwehr von DDoS-Angriffen, dabei spielt es keine Rolle, um welche Art von Angriff es sich handelt und ist damit die ideale Ergänzung zu unseren bestehenden Services.

Wir sind mit 3 GRE-Tunneln an das globale Anycast-Netzwerk von Path Network angeschlossen. Je ein GRE-Tunnel terminiert in den Rechenzentren Wendenstraße 408, Colo1 und Colo2 sowie im Lumen Rechenzentrum S198, so dass auch bei Wartungsarbeiten immer mindestens ein Tunnel zur Verfügung steht. Der Traffic, der zu uns reinkommt, nimmt dabei immer den nächstgelegenen PoP (Point of Presence), im Normalfall ist dies Frankfurt am Main, die Alternativ-PoPs wären Amsterdam oder Warschau, was sich jedoch nur minimalst auf die Latenz auswirken würde.

Jeder PoP von Path Network  – von denen es mehr als 20 rund um die Welt gibt – hat dabei ein Minimal-Setup von 300G, Frankfurt knapp 1T, d.h. es steht ausreichend Bandbreite zur Verfügung, um auch größere Attacken abzufangen.

Durch die uns nun zur Verfügung stehenden API können wir Ihnen zukünftig dann auch noch weitere Funktionen im DCP anbieten, wie z.B. das Anlegen von eigenen Rate-Limits oder Blocklisten sowie eigene Firewallregeln. Dies ist quasi die nächste Abwehrbarriere um unliebsamen Traffic vom eigenen Server fernzuhalten, auch wenn es kein DDoS-Angriff ist.

Weitere Informationen finden Sie auch unter https://www.artfiles.de/network/products/ddos/ oder sprechen Sie uns gerne an!

Artfiles ist MANRS Mitglied

Für ein stabiles Internet, wie Sie es hoffentlich kennen, ist es wichtig Regeln und Sicherheitsmechanismen haben. Eine Initiative, die sich eben dies auf die Fahnen geschrieben hat, ist MANRS (https://www.manrs.org).

MANRS steht für „Mutually Agreed Norms for Routing Security“, frei übersetzt “Einvernehmlich vereinbarte Normen zur Routing Sicherheit“.

Hieraus geht auch das Ziel der Initiative hervor, möglichst viele Teilnehmer sollen diese Normen umsetzen, sei es ein Internetprovider, Cloudanbieter, Streaminganbieter oder Internet Exchanges.

Um z.B. eine Domain aufrufen zu können, werden viele kleine Datenpakete durch das Internet geschickt. Diese Datenpakete müssen dafür mehrere Router passieren, diese Router sorgen dafür, dass das Datenpaket den schnellsten Weg zum Ziel findet. Um den schnellsten Weg zu finden, führt der Router einen „Routing Table“, in dem der Router alle ihm bekannten Wege zum Ziel führt. Dieser „Routing Table“ baut auf den Updates seiner Nachbarroutern auf.

Durch diesen kleinen Exkurs wird vielleicht auch deutlich, warum es wichtig ist, korrekte Daten an die Nachbarrouter zu annoncieren. Werden falsche Daten annonciert, führt der „Routing Table“ falsche Einträge. Letztendlich kann dies für Sie verschiedene Konsequenzen zur Folge haben: Ihre Daten kommen nicht am Ziel an; benötigen sehr viel länger zum Ziel; im schlimmsten Fall landen die Daten bei Kriminellen. Daher ist es wichtig, entsprechende Maßnahmen umzusetzen, um solche Probleme, so gut wie möglich, zu verhindern.

MANRS sieht hierfür 4 übergeordnete Themen vor:

  • Filtering
  • Anti-Spoofing
  • Coordination
  • Global Validation

Für einen kurzen Überblick: https://www.manrs.org/wp-content/uploads/2018/04/MANRS-postcard_FINAL-online.pdf

Für eine ausführliche Erläuterung: https://www.manrs.org/wp-content/uploads/2018/09/MANRS_PDF_Sep2016.pdf

Viele dieser Punkte haben wir schon seit langem umgesetzt, wie z.B. durch die Einführung von RPKI letztes Jahr. Nun haben wir jedoch auch die letzten Maßnahmen eingeführt und vor allem aktualisiert, um alle 4 Themenkomplexe komplett zu erfüllen. Somit können wir nun verkünden, dass wir seit heute offizieller MANRS Teilnehmer sind.

Network Operator Participants

Auch zukünftig werden wir natürlich die Entwicklungen beobachten und entsprechende Maßnahmen ergreifen sofern diese nötig sind. Sollten Sie Fragen haben, melden Sie sich gerne bei uns.

RPKI Validation bei Artfiles

In der IT-Branche ist RPKI in aller Munde und auch wir haben dieses Thema in den letzten Wochen aufgegriffen. Mit der Implementierung leisten wir einen Beitrag zur Routing-Sicherheit und schützen unsere Netze gegen gewollte und ungewollte Attacken.

Ab Dienstag, den 07.01.2020, werden wir die RPKI Validation aktivieren und Routen verwerfen, die nicht korrekt vom Inhaber authorisiert sind. Laut unserem Monitoring werden dies ca. 4500 IPv4 Netze und ca. 800 IPv6 Netze sein.

Invalid Prefixes (Stand: 13.12.2019)

Und nun nochmal genauer

Was ist eigentlich RPKI?

RPKI steht für ‘Resource Public Key Infrastructure’ und bildet einen Baustein in der BGP Sicherheit. BGP ist die Abkürzung für ‘Border Gateway Protocol’ und stellt das zentrale Routingprotokoll dar, um verschiedene Netzwerke miteinander zu verbinden.

Jede Organisation oder Privatperson, die selbst Prefixe (Netze) hochfahren möchte, erhält von der zuständigen RIR (Regional Internet Registry), in unserem Fall dem RIPE, eine sogenannte AS-Nummer. Generell kann nun jeder unterhalb seiner AS-Nummer (oder auch einer x-beliebigen, BGP bietet da keinen Schutz) jedes Prefix annoncieren und dies seinem BGP-Neighbor mitteilen. Ohne Sicherheitsmechanismen nimmt der BGP-Neighbor dieses Prefix in seinen Routing Table auf und teilt wiederum seinen Nachbarn mit, dass er einen Pfad zu diesem Prefix besitzt. Somit könnte der Traffic nun einen anderen Weg nehmen und nicht am eigentlichen Zielort ankommen. Mit RPKI ist es nun möglich, solche Angriffe zu einem großen Teil zu unterbinden. Wichtig hierfür ist das Signieren der eigenen Prefixe sowie das Validieren der externen Prefixe.

Signierung

RPKI setzt zum Signieren auf die Public-Key Verschlüsselung. Hierfür übernimmt das RIPE das Hosten der CA (Certification Authority) und stellt uns Zertifikate für unsere Prefixe aus. So ein Zertifikat nennt sich ROA (Route Origination Authorization) und besteht aus drei Teilen.

  1. Origin AS – Die AS-Nummer, die das Prefix hochfahren darf
  2. Prefix – Das zu signierende Prefix
  3. Prefixlänge – Die Länge des Prefix, z.B. ob das Prefix nur als /24 hochgefahren werden darf oder auch als /23

Beim RIPE kann man unter http://localcert.ripe.net:8088/roas die erstellten ROAs einsehen.

ROA für unser Prefix 80.252.96.0/20

Anhand der erstellten ROAs kann nun jeder Router ein Prüfung vornehmen, ob das an ihn annoncierte Prefix überhaupt annonciert werden darf.

Validierung

Die Validierung der Prefixe läuft so ab, dass zusätzliche Software, der Validator, alle ROAs von den unterschiedlichen RIRs runterlädt und lokal zusammenfasst. Der Router fragt die ROAs nun über das RTR-Protokoll vom Validator ab und führt dann eine Route Origin Validation (ROV) durch und versieht die ihm annoncierten Prefixe mit einem Status:

  • valid
    Das annoncierte Prefix wird vom korrekten AS annonciert und hat die korrekte Länge
  • unknown
    Das annoncierte Prefix hat keinen ROA oder die Verbindung zum Validator ist längere Zeit inaktiv und die lokale Datenbank damit nicht mehr up-to-date
  • invalid
    Das annoncierte Prefix wird vom falschen AS annonciert oder besitzt eine falsche Länge

Auf Basis dieser Validierung kann man auf dem Router nun festlegen, was mit den annoncierten Prefixes geschehen soll.

Als Validatoren setzen wir auf den RIPE RPKI Validator und auf den Routinator3000 von NLnetLabs.

Router sagt Nein

Wir haben unsere Router so konfiguriert, dass Prefixe mit dem Status valid und unknown angenommen werden. Prefixe mit dem Status invalid, werden vom 07.01.2020 an verworfen und nicht in den aktiven Routing Table aufgenommen.

Durch das Verwerfen von invaliden Prefixes kann es nun vorkommen, dass Clients aus diesen Netzen keinen unserer Services mehr nutzen können. Hier möchten wir nochmal betonen, dass das Problem in dem Fall nicht bei uns liegt, sondern beim Provider des Clients, da dort falsche ROAs konfiguriert sind.

Demonstrieren lässt sich dies z.B. an dem Prefix 24.38.100.0/24. Hierfür ist der folgende ROA angelegt.

Der bei ARIN angelegte ROA

Demnach darf nur das AS6128 das Netz announcen. Laut Routing Table wird das Netz jedoch von AS54004 announciert. Damit stimmt das announcierte Prefix nicht mit dem ROA überein und der Status wird auf invalid gesetzt.

Routing Status beim RIPEstat (https://stat.ripe.net/24.38.100.0%2F24#tabId=routing)

Den RPKI Status einer IP können Sie auch unter https://stat.ripe.net/ überprüfen.

Da wir mit einigen Kunden interne BGP-Sessions aufgesetzt haben und wir dort teilweise Prefixe announciert bekommen, die nicht durch einen ROA authorisiert werden können, mussten wir hierfür eine Lösung finden, da jedes an uns announcierte Prefix die Validierung durchlaufen soll, ohne Ausnahme.

Um dies zu gewährleisten, werden die announcierten Prefixes in die kundenspezifische Policy geschrieben und erhalten dort von uns den Status valid. So ist gewährleistet, dass die Prefixes vom Kunden immer valid sind und angenommen werden.

Zusätzlich versehen wir jedes Prefix mit einer Community, was uns z.B. das Monitoring der Prefixes erleichtert.

BGP Communities

Die Zukunft

RPKI trägt einen Teil zur Sicherheit der Netzwerke bei, weitere interessante Sicherheitsmaßnahmen wie z.B. ASPA befinden sich in der Entwicklung und werden von uns aufmerksam verfolgt, um auch zukünftig unser Netzwerk, und damit auch Sie, zu schützen.

Wir hoffen, Ihnen einen kleinen Einblick in die RPKI Implementierung bei Artfiles gegeben zu haben. Sollten Sie Fragen haben, melden Sie sich gerne bei uns.

Email Spam Blacklisting – was es damit auf sich hat und wie wir damit umgehen.

 

Trotzdem die “E-Mail” seit vielen Jahren ein ausgereiftes und vielgenutztes Kommunikationsmedium ist, kann es in seltenen Fällen leider immer noch zu Problemen kommen, wenn es um den Versand oder den Empfang von Mails geht. Da können dann zum Beispiel wichtige E-Mails nicht versandt werden und der Mailserver des Empfängers gibt nur eine kryptische Fehlermeldung von sich und wehrt sich nach Kräften dagegen die Mail anzunehmen. Häufig steht in solchen Fehlermeldungen ein Verweis auf sogenannte Blacklists. Was es damit auf sich hat, ahnen Sie vielleicht schon: Das ewige Problem des Missbrauchs von E-Mails für Werbung, den sogenannten Spam. Im Folgenden wollen wir einmal kurz aufführen, was hier das Problem ist und was wir tun, um solche Probleme möglichst gar nicht erst entstehen zu lassen.

Continue reading “Email Spam Blacklisting – was es damit auf sich hat und wie wir damit umgehen.”