BGP Route Filtering: Prefix-Listen, AS-Path-Filter, Bogon-Ablehnung und GTSM
Eine praktische Referenz zur Absicherung von BGP-Sessions auf Linux mit mehrschichtigen Filtern. Behandelt Prefix-Listen, Bogon-Ablehnung, AS-Path-Filterung, Max-Prefix-Limits und GTSM in BIRD2- und FRR-Syntax mit Verifikationsschritten.
RPKI validiert, ob ein AS berechtigt ist, ein Prefix zu originieren. Es schuetzt nicht vor Route Leaks, Bogon-Injection, Tabellenexplosion durch einen falsch konfigurierten Peer oder gefaelschten BGP-Paketen von nicht direkt verbundenen Hosts. Dieser Artikel behandelt die Filter, die alles abdecken, was RPKI nicht abdeckt.
Jeder Filter wird sowohl in BIRD2- als auch in FRR-Syntax gezeigt, mit IPv4- und IPv6-Beispielen. Jeder Abschnitt erklaert, was der Filter verhindert, zeigt die Konfiguration und beschreibt, wie Sie die korrekte Funktion verifizieren.
Wenn Sie RPKI Origin Validation noch nicht eingerichtet haben, tun Sie das zuerst. Siehe RPKI ROA Setup for BGP.
Fuer die grundlegende BGP-Session-Einrichtung siehe BIRD2 BGP Configuration on Linux (BIRD2) oder FRR BGP Configuration on Linux (FRR). Dieser Artikel setzt voraus, dass Sie bereits eine funktionierende BGP-Session haben und diese absichern moechten.
Warum benoetigt BGP Route Filtering jenseits von RPKI?
BGP Route Filtering ist die Praxis, BGP-Ankuendigungen anhand von Prefix, AS-Path oder Ursprungsattributen zu akzeptieren oder abzulehnen. Es verhindert Route Leaks, Prefix-Hijacks, Bogon-Injection und die Explosion der Routingtabelle. RPKI deckt ausschliesslich die Origin Validation ab. Ohne zusaetzliche Filter ist Ihr Router jeder anderen Kategorie von BGP-Vorfaellen ausgesetzt.
Hier ist, was jede Schicht verhindert:
| Filtertyp | Abgewehrte Bedrohung | Folgen ohne diesen Filter |
|---|---|---|
| Bogon-Prefix-Ablehnung | Privater/reservierter Adressraum im DFZ | Ihr Router leitet Traffic an RFC-1918-Adressen weiter. Black Hole. |
| Ablehnung zu kleiner Prefixes | More-specific Hijacks (/25+, /49+) | Ein Angreifer kuendigt eine /32 an, die einen Teil einer /24 abdeckt, die Sie akzeptieren. Seine Route gewinnt durch Longest Match. |
| AS-Path-Bogon-Filterung | Private/reservierte ASNs in Pfaden | Routen mit AS 65535 oder AS 4200000000 gelangen in Ihre Tabelle. Sie leiten Traffic anhand ungueltiger Pfade weiter. |
| AS-Path-Laengenbegrenzung | Path-Inflation-Angriffe, Tabellen-Bloat | Ein Peer sendet Routen mit 50+ AS-Hops. Ihr Speicher fuellt sich mit nutzlosen Eintraegen. |
| Max-Prefix-Limit | Route Leaks, Session-Ueberlastung | Ein Peer leakt eine vollstaendige Tabelle (1M+ Prefixes) in Ihre Session. Ihrem Router geht der Arbeitsspeicher aus. |
| GTSM (TTL Security) | Gefaelschte BGP-Pakete von entfernten Hosts | Ein Angreifer, der mehrere Hops entfernt ist, injiziert BGP OPEN- oder UPDATE-Pakete in Ihre Session. |
| RPKI Origin Validation | Origin-Hijacks | Jemand originiert Ihr Prefix aus seinem AS. Bereits behandelt in RPKI ROA Setup for BGP. |
Reale Vorfaelle zeigen, warum jede Schicht wichtig ist. Im Jahr 2008 kuendigte Pakistan Telecom more-specific Routen fuer YouTubes Prefixes an, um eine inlaendische Zensuranordnung umzusetzen. Diese Routen gelangten zu internationalen Transit-Providern und erzeugten fuer Stunden ein globales Black Hole fuer YouTube. Ein Bogon- oder Small-Prefix-Filter bei Transit-Providern haette diese Ankuendigungen verworfen. Im Juni 2019 leckte ein kleiner ISP in Pennsylvania (AS396531) versehentlich Routen fuer Cloudflare, Amazon und Linode zu Verizon, welche diese global propagierte. Ein Max-Prefix-Limit haette die Session beendet, bevor sich das Leak ausbreitete.
Wie filtert man Bogon-Prefixes in BIRD2 und FRR?
Bogon-Prefixes sind Adressbereiche, die niemals in der globalen Routingtabelle erscheinen duerfen. Dazu gehoeren privater RFC-1918-Raum, Link-Local-Adressen, Dokumentationsbereiche und reservierte Bloecke. Wenn Sie sie akzeptieren, versucht Ihr Router, Traffic an Adressen weiterzuleiten, die kein legitimes globales Ziel haben, und erzeugt dabei Black Holes.
IPv4-Bogon-Prefixes
| Prefix | Referenz | Zweck |
|---|---|---|
| 0.0.0.0/8 | RFC 1122 | "This"-Netzwerk |
| 10.0.0.0/8 | RFC 1918 | Privater Adressraum |
| 100.64.0.0/10 | RFC 6598 | Carrier-grade NAT |
| 127.0.0.0/8 | RFC 1122 | Loopback |
| 169.254.0.0/16 | RFC 3927 | Link-local |
| 172.16.0.0/12 | RFC 1918 | Privater Adressraum |
| 192.0.2.0/24 | RFC 5737 | TEST-NET-1 |
| 192.88.99.0/24 | RFC 7526 | Veraltetes 6to4 Relay |
| 192.168.0.0/16 | RFC 1918 | Privater Adressraum |
| 198.18.0.0/15 | RFC 2544 | Benchmarking |
| 198.51.100.0/24 | RFC 5737 | TEST-NET-2 |
| 203.0.113.0/24 | RFC 5737 | TEST-NET-3 |
| 224.0.0.0/4 | RFC 5771 | Multicast |
| 240.0.0.0/4 | RFC 1112 | Fuer zukuenftige Nutzung reserviert |
IPv6-Bogon-Prefixes
| Prefix | Referenz | Zweck |
|---|---|---|
| ::/8 | Various | IPv4-kompatibel, Loopback, gemappt |
| 100::/64 | RFC 6666 | Nur Verwerfen (Discard-only) |
| 2001:2::/48 | RFC 5180 | BMWG-Benchmarking |
| 2001:10::/28 | RFC 4843 | ORCHID |
| 2001:db8::/32 | RFC 3849 | Dokumentation |
| 3fff::/20 | RFC 9637 | Dokumentation |
| 2002::/16 | RFC 7526 | Veraltetes 6to4 |
| 3ffe::/16 | RFC 3701 | Ehemaliges 6bone |
| 5f00::/16 | RFC 9602 | SRv6 SIDs |
| fc00::/7 | RFC 4193 | Unique Local Unicast |
| fe80::/10 | RFC 4291 | Link-local Unicast |
| fec0::/10 | RFC 3879 | Veraltetes Site-local |
| ff00::/8 | RFC 4291 | Multicast |
Diese Listen aendern sich, wenn IANA neue Bloecke zuweist oder alte als veraltet markiert. Die Team Cymru Bogon-Referenz stellt einen BGP-Feed von Fullbogons (nicht zugewiesener + reservierter Adressraum) bereit, der sich automatisch aktualisiert. Fuer statische Listen pruefen Sie den NLNOG BGP Filter Guide regelmaessig.
BIRD2-Bogon-Filter
# /etc/bird/bogons.conf - include this from your main bird.conf
define BOGON_PREFIXES_V4 = [
0.0.0.0/8+,
10.0.0.0/8+,
100.64.0.0/10+,
127.0.0.0/8+,
169.254.0.0/16+,
172.16.0.0/12+,
192.0.2.0/24+,
192.88.99.0/24+,
192.168.0.0/16+,
198.18.0.0/15+,
198.51.100.0/24+,
203.0.113.0/24+,
224.0.0.0/4+,
240.0.0.0/4+
];
define BOGON_PREFIXES_V6 = [
::/8+,
0100::/64+,
2001:2::/48+,
2001:10::/28+,
2001:db8::/32+,
3fff::/20+,
2002::/16+,
3ffe::/16+,
5f00::/16+,
fc00::/7+,
fe80::/10+,
fec0::/10+,
ff00::/8+
];
function reject_bogon_prefixes_v4() {
if (net ~ BOGON_PREFIXES_V4) then {
print "REJECTED bogon prefix: ", net, " path: ", bgp_path;
reject;
}
}
function reject_bogon_prefixes_v6() {
if (net ~ BOGON_PREFIXES_V6) then {
print "REJECTED bogon prefix: ", net, " path: ", bgp_path;
reject;
}
}
Das + nach jedem Prefix bedeutet "dieses Prefix und alle spezifischeren Prefixes." 10.0.0.0/8+ trifft auf 10.0.0.0/8, 10.0.0.0/9, 10.1.0.0/16 und so weiter zu. Dies faengt einen Angreifer ab, der eine /24 innerhalb des RFC-1918-Raums ankuendigt.
Rufen Sie diese Funktionen in Ihrem Import-Filter auf:
filter import_from_upstream_v4 {
reject_bogon_prefixes_v4();
# ... other filters ...
accept;
}
protocol bgp upstream_v4 {
local as 64500;
neighbor 198.51.100.1 as 64501;
ipv4 {
import filter import_from_upstream_v4;
export none;
};
}
FRR-Bogon-Filter
! IPv4 bogon prefix-list
ip prefix-list BOGONS_v4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS_v4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS_v4 seq 30 deny 100.64.0.0/10 le 32
ip prefix-list BOGONS_v4 seq 40 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS_v4 seq 50 deny 169.254.0.0/16 le 32
ip prefix-list BOGONS_v4 seq 60 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS_v4 seq 70 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS_v4 seq 80 deny 192.88.99.0/24 le 32
ip prefix-list BOGONS_v4 seq 90 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS_v4 seq 100 deny 198.18.0.0/15 le 32
ip prefix-list BOGONS_v4 seq 110 deny 198.51.100.0/24 le 32
ip prefix-list BOGONS_v4 seq 120 deny 203.0.113.0/24 le 32
ip prefix-list BOGONS_v4 seq 130 deny 224.0.0.0/4 le 32
ip prefix-list BOGONS_v4 seq 140 deny 240.0.0.0/4 le 32
ip prefix-list BOGONS_v4 seq 999 permit 0.0.0.0/0 le 32
! IPv6 bogon prefix-list
ipv6 prefix-list BOGONS_v6 seq 10 deny ::/8 le 128
ipv6 prefix-list BOGONS_v6 seq 20 deny 100::/64 le 128
ipv6 prefix-list BOGONS_v6 seq 30 deny 2001:2::/48 le 128
ipv6 prefix-list BOGONS_v6 seq 40 deny 2001:10::/28 le 128
ipv6 prefix-list BOGONS_v6 seq 50 deny 2001:db8::/32 le 128
ipv6 prefix-list BOGONS_v6 seq 60 deny 3fff::/20 le 128
ipv6 prefix-list BOGONS_v6 seq 70 deny 2002::/16 le 128
ipv6 prefix-list BOGONS_v6 seq 80 deny 3ffe::/16 le 128
ipv6 prefix-list BOGONS_v6 seq 90 deny 5f00::/16 le 128
ipv6 prefix-list BOGONS_v6 seq 100 deny fc00::/7 le 128
ipv6 prefix-list BOGONS_v6 seq 110 deny fe80::/10 le 128
ipv6 prefix-list BOGONS_v6 seq 120 deny fec0::/10 le 128
ipv6 prefix-list BOGONS_v6 seq 130 deny ff00::/8 le 128
ipv6 prefix-list BOGONS_v6 seq 999 permit ::/0 le 128
Die Klauseln le 32 (IPv4) und le 128 (IPv6) treffen auf das Prefix und alle spezifischeren Prefixes zu, genau wie der +-Operator in BIRD2. Die abschliessende permit-Zeile bei seq 999 erlaubt alles, was oben nicht abgelehnt wurde.
Wenden Sie die Prefix-Liste auf Ihren Neighbor an:
router bgp 64500
neighbor 198.51.100.1 remote-as 64501
address-family ipv4 unicast
neighbor 198.51.100.1 prefix-list BOGONS_v4 in
address-family ipv6 unicast
neighbor 2001:db8::1 prefix-list BOGONS_v6 in
Achtung: Der Eintrag 2001:db8::/32 befindet sich in der Bogon-Liste. Verwenden Sie keine Dokumentationsadressen in der Produktion. Ersetzen Sie die oben genannten Neighbor-Adressen durch Ihre tatsaechlichen Peer-IPs.
Ablehnung zu kleiner Prefixes
Routen, die kleiner als /24 (IPv4) oder /48 (IPv6) sind, verbreiten sich im globalen DFZ nicht zuverlaessig. Noch wichtiger ist, dass das Akzeptieren dieser Routen Sie more-specific-Hijack-Angriffen aussetzt. Filtern Sie sie eingehend.
BIRD2:
function reject_small_prefixes_v4() {
if (net.len > 24) then {
print "REJECTED too-small prefix: ", net, " path: ", bgp_path;
reject;
}
}
function reject_small_prefixes_v6() {
if (net.len > 48) then {
print "REJECTED too-small prefix: ", net, " path: ", bgp_path;
reject;
}
}
FRR:
! Add to the same prefix-lists, before the final permit
ip prefix-list BOGONS_v4 seq 150 deny 0.0.0.0/0 ge 25 le 32
ipv6 prefix-list BOGONS_v6 seq 140 deny ::/0 ge 49 le 128
Dies trifft jedes Prefix, das spezifischer als /24 (IPv4) oder /48 (IPv6) ist. Platzieren Sie diese Zeilen vor den seq 999 permit-Eintraegen.
Wie verhindern AS-Path-Filter Route Leaks?
AS-Path-Filter pruefen die Sequenz autonomer Systeme, die eine Route durchlaufen hat. Sie erkennen drei Probleme: Bogon-ASNs, die niemals in einem Pfad erscheinen sollten, ueberlange Pfade, die auf Leaks oder Manipulation hinweisen, und private ASNs, die vor der Ankuendigung nicht entfernt wurden.
Filterung von Bogon-ASNs
Bogon-ASNs sind reservierte Nummern, die niemals in einem BGP-Pfad im oeffentlichen Internet erscheinen sollten:
| ASN-Bereich | Referenz | Zweck |
|---|---|---|
| 0 | RFC 7607 | Reserviert |
| 23456 | RFC 4893 | AS_TRANS (4-Byte-AS-Uebergang) |
| 64496-64511 | RFC 5398 | Dokumentation/Beispiele |
| 64512-65534 | RFC 6996 | Privater Gebrauch (16-bit) |
| 65535 | RFC 7300 | Letzte 16-bit-ASN |
| 65536-65551 | RFC 5398 | Dokumentation/Beispiele (32-bit) |
| 65552-131071 | IANA | Reserviert |
| 4200000000-4294967294 | RFC 6996 | Privater Gebrauch (32-bit) |
| 4294967295 | RFC 7300 | Letzte 32-bit-ASN |
BIRD2:
define BOGON_ASNS = [
0,
23456,
64496..64511,
64512..65534,
65535,
65536..65551,
65552..131071,
4200000000..4294967294,
4294967295
];
function reject_bogon_asns()
int set bogon_asns;
{
bogon_asns = BOGON_ASNS;
if (bgp_path ~ bogon_asns) then {
print "REJECTED bogon ASN in path: ", net, " path: ", bgp_path;
reject;
}
}
Der Operator bgp_path ~ bogon_asns prueft, ob eine ASN im Pfad Mitglied der Menge ist. Eine einzelne Bogon-ASN an beliebiger Stelle im Pfad loest die Ablehnung aus.
FRR:
bgp as-path access-list BOGON_ASNS deny _0_
bgp as-path access-list BOGON_ASNS deny _23456_
bgp as-path access-list BOGON_ASNS deny _6449[6-9]_
bgp as-path access-list BOGON_ASNS deny _6450[0-9]_
bgp as-path access-list BOGON_ASNS deny _6451[01]_
bgp as-path access-list BOGON_ASNS deny _64[5-9][1-9][2-9]_
bgp as-path access-list BOGON_ASNS deny _6[5-9][0-9][0-9][0-9]_
bgp as-path access-list BOGON_ASNS deny _[1-9][0-9][0-9][0-9][0-9]_
bgp as-path access-list BOGON_ASNS deny _[1-3][0-9][0-9][0-9][0-9][0-9]_
bgp as-path access-list BOGON_ASNS permit .*
FRR verwendet Regex-Matching auf dem AS-Path-String. Die Unterstriche _ treffen auf AS-Path-Trennzeichen (Leerzeichen, Anfang, Ende) zu. Dieser Regex-Ansatz ist weniger praezise als das Integer-Set-Matching in BIRD2. Fuer einen einfacheren, aber weniger granularen Ansatz verwenden Sie eine Route-Map mit der as-path access-list:
route-map IMPORT_FILTER deny 10
match as-path BOGON_ASNS
route-map IMPORT_FILTER permit 100
router bgp 64500
address-family ipv4 unicast
neighbor 198.51.100.1 route-map IMPORT_FILTER in
Hinweis: Die obigen Regex-Muster sind vereinfacht. Den gesamten Bereich der privaten 32-bit-ASNs (4200000000-4294967294) per Regex abzubilden ist fehleranfaellig. Fuer Produktionsumgebungen sollten Sie bgpq4 verwenden, um Prefix-Listen und AS-Path-Filter aus IRR-Daten zu generieren. Das ist genauer und automatisierbar.
Begrenzung der AS-Path-Laenge
Ein legitimer BGP-Pfad ueberschreitet selten 10-15 ASNs. Laengere Pfade deuten typischerweise auf ein Route Leak, Pfadmanipulation oder fehlerhaftes Prepending hin. Setzen Sie eine harte Obergrenze.
BIRD2:
function reject_long_paths() {
if (bgp_path.len > 25) then {
print "REJECTED long AS-path (", bgp_path.len, "): ", net, " path: ", bgp_path;
reject;
}
}
FRR:
bgp as-path access-list LONG_PATHS deny ^([0-9]+_){25,}
bgp as-path access-list LONG_PATHS permit .*
route-map IMPORT_FILTER deny 20
match as-path LONG_PATHS
Ein Limit von 25 ist konservativ. Die meisten legitimen Routen haben Pfade unter 10. Wenn Sie eine vollstaendige Tabelle empfangen, pruefen Sie die laengsten Pfade in Ihrer RIB, bevor Sie einen Schwellenwert festlegen:
# BIRD2
birdc 'show route where bgp_path.len > 15' | head -20
# FRR
vtysh -c "show ip bgp regexp ^([0-9]+_){15,}"
Entfernen privater ASNs beim Senden
Wenn Sie iBGP mit privaten ASNs intern betreiben, stellen Sie sicher, dass diese nicht zu Ihren Upstreams gelangen.
BIRD2:
filter export_to_upstream_v4 {
# Strip private ASNs before advertising
bgp_path.delete([64512..65534, 4200000000..4294967294]);
# ... your export policy ...
accept;
}
FRR:
router bgp 64500
address-family ipv4 unicast
neighbor 198.51.100.1 remove-private-AS all
Das Schluesselwort all entfernt jede private ASN, auch wenn oeffentliche ASNs im Pfad vorhanden sind. Ohne all entfernt FRR private ASNs nur, wenn der gesamte Pfad ausschliesslich private ASNs enthaelt.
Was ist das korrekte Max-Prefix-Limit fuer eine BGP-Session?
Ein Max-Prefix-Limit ist ein Sicherheitsventil, das eine BGP-Session beendet, wenn ein Peer mehr Prefixes ankuendigt als der konfigurierte Schwellenwert. Es verhindert die Routingtabellen-Explosion, wenn ein Peer versehentlich eine vollstaendige Tabelle leakt oder kompromittiert wird. Ohne diesen Schutz kann ein einziger falsch konfigurierter Peer Ihren Router in den Speicherueberlauf treiben.
Setzen Sie das Limit basierend auf dem, was Sie von jedem Peer erwarten:
| Peer-Typ | Erwartete Prefixes (IPv4) | Empfohlenes Limit | Empfohlenes Limit (IPv6) |
|---|---|---|---|
| Full-Table-Upstream | ~1.200.000 (Maerz 2026) | 1.500.000 | 300.000 |
| Partial Table / IXP-Peer | Variabel | 1,5x aktueller Zaehler | 1,5x aktueller Zaehler |
| Kunde Single-homed | 1-10 | 50 | 50 |
| Kunde Multi-homed | 10-100 | 200 | 200 |
Pruefen Sie die aktuelle Groesse der vollstaendigen Tabelle auf bgp.potaroo.net, bevor Sie Upstream-Limits setzen. Setzen Sie das Limit auf etwa 1,2x des erwarteten Zaehlers, um normales Wachstum zu absorbieren, ohne falsche Ausloesungen zu verursachen.
BIRD2:
protocol bgp upstream_v4 {
local as 64500;
neighbor 198.51.100.1 as 64501;
ipv4 {
import limit 1500000 action restart;
import filter import_from_upstream_v4;
export none;
};
}
protocol bgp customer_v4 {
local as 64500;
neighbor 203.0.113.10 as 64502;
ipv4 {
import limit 50 action disable;
import filter import_from_customer_v4;
export filter export_to_customer_v4;
};
}
BIRD2 bietet drei Aktionen, wenn das Limit erreicht wird:
action restart- beendet die Session und startet sie nach einer Verzoegerung neu. Am besten fuer Upstreams.action disable- beendet und deaktiviert das Protokoll. Erfordert manuellesbirdc enablezur Wiederherstellung. Am besten fuer Kunden, bei denen ein Limit-Treffer auf ein ernsthaftes Problem hinweist.action block- stoppt den Import neuer Routen, haelt die Session aber aufrecht. Nuetzlich, wenn Sie bestehende Routen beibehalten moechten, waehrend Sie den Vorfall untersuchen.
FRR:
router bgp 64500
neighbor 198.51.100.1 remote-as 64501
address-family ipv4 unicast
neighbor 198.51.100.1 maximum-prefix 1500000 90 restart 5
neighbor 203.0.113.10 remote-as 64502
address-family ipv4 unicast
neighbor 203.0.113.10 maximum-prefix 50 80
In FRR bedeutet maximum-prefix 1500000 90 restart 5: Warnung bei 90% (1.350.000 Prefixes), Session-Beendigung bei 1.500.000, und Neustart der Session nach 5 Minuten. Ohne das Schluesselwort restart beendet FRR die Session und erfordert ein manuelles clear bgp neighbor zur Wiederherstellung.
Max-Prefix-Konfiguration verifizieren
# BIRD2 - check current prefix count and limit
birdc show protocols all upstream_v4 | grep -E "Routes|Limit"
# FRR - check prefix count per neighbor
vtysh -c "show ip bgp summary"
Die Ausgabe zeigt den aktuellen Prefix-Zaehler neben dem konfigurierten Limit. Wenn der Zaehler dem Limit nahe kommt, erhoehen Sie den Schwellenwert, bevor er ausgeloest wird.
Wie schuetzt GTSM BGP-Sessions vor gefaelschten Paketen?
GTSM (Generalized TTL Security Mechanism, RFC 5082) beschraenkt akzeptierte BGP-Pakete auf direkt verbundene Peers, indem das TTL/Hop-Limit-Feld geprueft wird. Wenn aktiviert, werden BGP-Pakete mit TTL 255 gesendet. Der Empfaenger verwirft alle BGP-Pakete mit einem TTL unter 254 (fuer einen direkt verbundenen Peer). Da Router den TTL bei jedem Hop dekrementieren, kann ein Angreifer, der mehr als einen Hop entfernt ist, keine Pakete senden, die mit TTL 255 ankommen.
Dies blockiert Remote-TCP-RST-Injection, SYN-Floods auf BGP-Port 179 und gefaelschte BGP OPEN/UPDATE-Pakete von nicht direkt verbundenen Angreifern. GTSM schliesst sich gegenseitig mit eBGP Multihop auf derselben Session aus. Beide Peers muessen es aktivieren.
BIRD2:
protocol bgp upstream_v4 {
local as 64500;
neighbor 198.51.100.1 as 64501;
ttl security yes;
ipv4 {
import limit 1500000 action restart;
import filter import_from_upstream_v4;
export none;
};
}
FRR:
router bgp 64500
neighbor 198.51.100.1 remote-as 64501
neighbor 198.51.100.1 ttl-security hops 1
hops 1 bedeutet, dass der Peer genau 1 Hop entfernt sein muss (direkt verbunden). Setzen Sie diesen Wert entsprechend der tatsaechlichen Hop-Anzahl. Fuer eBGP-Peers ueber ein IXP-Switching-Fabric ist hops 1 korrekt. Bei Multihop-Sessions (z.B. BGP ueber einen GRE-Tunnel) koennen Sie GTSM nicht verwenden. Nutzen Sie stattdessen MD5-Authentifizierung:
BIRD2 MD5-Alternative:
protocol bgp multihop_peer {
local as 64500;
neighbor 198.51.100.5 as 64503;
multihop 2;
password "your-md5-secret";
# ...
}
FRR MD5-Alternative:
router bgp 64500
neighbor 198.51.100.5 remote-as 64503
neighbor 198.51.100.5 ebgp-multihop 2
neighbor 198.51.100.5 password your-md5-secret
Speichern Sie das MD5-Passwort in einer Datei mit eingeschraenkten Rechten (chmod 600) statt in der Hauptkonfiguration. Fuer FRR referenzieren Sie es aus /etc/frr/frr.conf, das bereits 640 mit dem Eigentuemer frr:frr sein sollte. Fuer BIRD2 halten Sie /etc/bird/bird.conf bei 640 mit dem Eigentuemer bird:bird.
Welche BGP-Filter verlangt MANRS?
MANRS (Mutually Agreed Norms for Routing Security) definiert Basisanforderungen fuer Netzwerkoperatoren. Actions 1, 3 und 4 sind verpflichtend, um MANRS-Teilnehmer zu werden. Hier ist, wie die Filter in diesem Artikel den MANRS-Actions entsprechen.
Action 1: Verhinderung der Verbreitung falscher Routinginformationen.
Dies ist die grundlegende Filteraktion. Sie verlangt explizite Prefix-Level-Filter auf Kundenverbindungen und empfiehlt AS-Path-Filter, um Route Leaks zu verhindern.
| Filter aus diesem Artikel | MANRS-Action-1-Abdeckung |
|---|---|
| Prefix-Listen-Filterung (Bogons) | Verhindert das Ankuendigen/Akzeptieren von reserviertem Adressraum |
| Ablehnung kleiner Prefixes | Blockiert more-specific Routen, die auf Hijacks hinweisen |
| AS-Path-Bogon-Filterung | Lehnt Routen mit privaten/reservierten ASNs ab |
| Max-Prefix-Limits | Stoppt die Verbreitung geleckter vollstaendiger Tabellen |
| Kunden-Prefix-Filter | Nicht in diesem Artikel. Erstellen Sie diese pro Kunde aus IRR mit bgpq4. |
Action 2 (empfohlen): Verhinderung von Traffic mit gefaelschten Quelladressen.
Dies ist kein BGP-Filter. Es geht um BCP 38/84 Source Address Validation (uRPF). Ausserhalb des Umfangs dieses Artikels, aber gleichermassen wichtig.
Action 3: Foerderung globaler operativer Kommunikation.
Halten Sie Ihre Kontaktdaten in PeeringDB und Ihrer RIR-Datenbank aktuell. Kein Filter, aber Operatoren, die korrekte Filter betreiben, pflegen in der Regel auch ihre Kontaktdaten.
Action 4: Foerderung von Routinginformationen auf globaler Ebene.
Veroffentlichen Sie Ihre Routing-Policy in IRR (RIPE, RADB) mit RPSL-Objekten. Erstellen Sie ROAs fuer RPKI. Dies ermoeglicht es Ihren Peers, genaue Prefix-Filter fuer Ihre Ankuendigungen zu erstellen.
Die Kombination aus Bogon-Filterung (Prefixes + ASNs) + Ablehnung kleiner Prefixes + Max-Prefix-Limits + Kunden-Prefix-Listen deckt MANRS Action 1 ab. Ergaenzen Sie RPKI (RPKI ROA Setup for BGP) und IRR-Registrierung fuer Action 4.
Alles zusammengefuehrt: ein vollstaendiger Import-Filter
Hier ist ein kombinierter Import-Filter, der alle oben genannten Techniken verwendet.
BIRD2 vollstaendiger Import-Filter
# /etc/bird/filters.conf
include "/etc/bird/bogons.conf"; # BOGON_PREFIXES_V4, BOGON_PREFIXES_V6, BOGON_ASNS
function import_checks_v4() {
# 1. Reject bogon prefixes
if (net ~ BOGON_PREFIXES_V4) then {
print "REJECT bogon prefix: ", net, " ", bgp_path;
reject;
}
# 2. Reject too-small prefixes
if (net.len > 24) then {
print "REJECT small prefix: ", net, " ", bgp_path;
reject;
}
# 3. Reject bogon ASNs in path
if (bgp_path ~ [0, 23456, 64496..64511, 64512..65534, 65535,
65536..65551, 65552..131071,
4200000000..4294967294, 4294967295]) then {
print "REJECT bogon ASN: ", net, " ", bgp_path;
reject;
}
# 4. Reject excessively long paths
if (bgp_path.len > 25) then {
print "REJECT long path: ", net, " ", bgp_path;
reject;
}
# 5. Reject RPKI invalid (if RPKI is configured)
if (roa_check(rpki4, net, bgp_path.last) = ROA_INVALID) then {
print "REJECT RPKI invalid: ", net, " ", bgp_path;
reject;
}
}
filter import_upstream_v4 {
import_checks_v4();
accept;
}
protocol bgp upstream_v4 {
local as 64500;
neighbor 198.51.100.1 as 64501;
ttl security yes;
ipv4 {
import limit 1500000 action restart;
import filter import_upstream_v4;
export none;
};
}
FRR vollstaendiger Import-Filter
! /etc/frr/frr.conf
! --- Prefix lists (bogons + small prefix rejection) ---
ip prefix-list IMPORT_V4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list IMPORT_V4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list IMPORT_V4 seq 30 deny 100.64.0.0/10 le 32
ip prefix-list IMPORT_V4 seq 40 deny 127.0.0.0/8 le 32
ip prefix-list IMPORT_V4 seq 50 deny 169.254.0.0/16 le 32
ip prefix-list IMPORT_V4 seq 60 deny 172.16.0.0/12 le 32
ip prefix-list IMPORT_V4 seq 70 deny 192.0.2.0/24 le 32
ip prefix-list IMPORT_V4 seq 80 deny 192.88.99.0/24 le 32
ip prefix-list IMPORT_V4 seq 90 deny 192.168.0.0/16 le 32
ip prefix-list IMPORT_V4 seq 100 deny 198.18.0.0/15 le 32
ip prefix-list IMPORT_V4 seq 110 deny 198.51.100.0/24 le 32
ip prefix-list IMPORT_V4 seq 120 deny 203.0.113.0/24 le 32
ip prefix-list IMPORT_V4 seq 130 deny 224.0.0.0/4 le 32
ip prefix-list IMPORT_V4 seq 140 deny 240.0.0.0/4 le 32
ip prefix-list IMPORT_V4 seq 150 deny 0.0.0.0/0 ge 25 le 32
ip prefix-list IMPORT_V4 seq 999 permit 0.0.0.0/0 le 32
! --- AS-path filters (bogon ASNs + path length) ---
bgp as-path access-list BOGON_ASNS deny _0_
bgp as-path access-list BOGON_ASNS deny _23456_
bgp as-path access-list BOGON_ASNS deny _6449[6-9]_
bgp as-path access-list BOGON_ASNS deny _6450[0-9]_
bgp as-path access-list BOGON_ASNS deny _6451[01]_
bgp as-path access-list BOGON_ASNS permit .*
bgp as-path access-list LONG_PATHS deny ^([0-9]+_){25,}
bgp as-path access-list LONG_PATHS permit .*
! --- Route-map combining all checks ---
route-map IMPORT_UPSTREAM deny 10
match as-path BOGON_ASNS
route-map IMPORT_UPSTREAM deny 20
match as-path LONG_PATHS
route-map IMPORT_UPSTREAM permit 100
! --- BGP neighbor configuration ---
router bgp 64500
neighbor 198.51.100.1 remote-as 64501
neighbor 198.51.100.1 ttl-security hops 1
address-family ipv4 unicast
neighbor 198.51.100.1 prefix-list IMPORT_V4 in
neighbor 198.51.100.1 route-map IMPORT_UPSTREAM in
neighbor 198.51.100.1 maximum-prefix 1500000 90 restart 5
In FRR werden sowohl die Prefix-Liste als auch die Route-Map ausgewertet. Die Prefix-Liste laeuft zuerst und verwirft Bogon-Prefixes und kleine Prefixes. Routen, die die Prefix-Liste passieren, treffen dann auf die Route-Map, die AS-Path-Filter prueft. Beide muessen die Route zulassen, damit sie akzeptiert wird.
Wie verifiziert man, dass BGP-Route-Filter funktionieren?
Filter sind nur nuetzlich, wenn sie tatsaechlich ablehnen, was sie sollen. Verifizieren Sie nach jeder Aenderung.
BIRD2-Verifikation
# Check what routes were rejected (requires print statements in filters)
grep "REJECT" /var/log/bird.log | tail -20
# Show the routing table with filter details
birdc show route filtered
# Show routes from a specific protocol
birdc show route protocol upstream_v4
# Count accepted routes per protocol
birdc show protocols all upstream_v4 | grep "Routes:"
# Test a specific prefix against your import filter
birdc show route for 10.0.0.0/8 all
Der Befehl show route filtered zeigt Routen, die empfangen, aber vom Import-Filter abgelehnt wurden. Wenn Ihr Bogon-Filter funktioniert, sollten Sie null Bogon-Prefixes in der akzeptierten Tabelle sehen, und alle empfangenen Bogons in der gefilterten Tabelle.
FRR-Verifikation
# Show accepted routes from a neighbor
vtysh -c "show ip bgp neighbors 198.51.100.1 received-routes"
# Show routes filtered by inbound policy
vtysh -c "show ip bgp neighbors 198.51.100.1 filtered-routes"
# Check the prefix count per neighbor
vtysh -c "show ip bgp summary"
# Test if a specific prefix is accepted
vtysh -c "show ip bgp 10.0.0.0/8"
# Check max-prefix status
vtysh -c "show ip bgp neighbors 198.51.100.1" | grep -A2 "Maximum prefix"
Damit received-routes und filtered-routes funktionieren, muessen Sie Soft-Reconfiguration Inbound fuer den Neighbor aktivieren:
router bgp 64500
address-family ipv4 unicast
neighbor 198.51.100.1 soft-reconfiguration inbound
Dies verbraucht zusaetzlichen Arbeitsspeicher (speichert alle empfangenen Routen vor der Filterung). Bei einer Full-Table-Session ist das ungefaehr das Doppelte des Speichers fuer die RIB. Auf Produktionsroutern mit begrenztem RAM verwenden Sie dies selektiv.
Externe Verifikation
Ihre Filter schuetzen Ihre eigene RIB. Um zu verifizieren, was Sie anderen ankuendigen, nutzen Sie externe Looking Glasses:
- bgp.tools - Suchen Sie Ihre ASN, um zu sehen, welche Prefixes Sie global ankuendigen
- RIPE RIS - BGP-Routinginformationsdienst, zeigt Route-Sichtbarkeit ueber Kollektoren
- Hurricane Electric BGP Toolkit - Prefix- und ASN-Suche
Pruefen Sie diese nach Filter-Aenderungen, um zu bestaetigen, dass Sie nicht versehentlich legitime Routen filtern oder Routen leaken, die Sie nicht ankuendigen sollten.
Fuer automatisiertes Monitoring siehe .
BIRD2 vs. FRR Syntaxvergleich
Kurzreferenz fuer die Uebertragung zwischen den beiden Daemons:
| Filtertyp | BIRD2 | FRR |
|---|---|---|
| Bogon-Prefix | if (net ~ BOGON_PREFIXES) then reject |
ip prefix-list BOGONS deny 10.0.0.0/8 le 32 |
| Kleines Prefix | if (net.len > 24) then reject |
ip prefix-list X deny 0.0.0.0/0 ge 25 le 32 |
| Bogon-ASN | if (bgp_path ~ [64512..65534]) then reject |
bgp as-path access-list X deny _64[5-9][1-9][2-9]_ |
| Pfadlaenge | if (bgp_path.len > 25) then reject |
bgp as-path access-list X deny ^([0-9]+_){25,} |
| Max-Prefix | import limit 50 action disable |
neighbor X maximum-prefix 50 |
| GTSM | ttl security yes |
neighbor X ttl-security hops 1 |
| MD5-Auth | password "secret" |
neighbor X password secret |
| Private AS entfernen | bgp_path.delete([64512..65534]) |
neighbor X remove-private-AS all |
| Filter anwenden | import filter name |
neighbor X prefix-list/route-map name in |
BIRD2 verwendet eine einzelne Filterfunktion, die alle Pruefungen kombiniert. FRR verteilt Pruefungen auf Prefix-Listen (Prefix-Matching), as-path access-lists (Pfad-Matching) und Route-Maps (Kombination mehrerer Match-Bedingungen). Beide Ansaetze funktionieren. BIRDs Ansatz ist bei komplexen Policies lesbarer. FRRs Ansatz ist Cisco-Operatoren vertrauter.
Etwas ist schiefgelaufen?
Session durch Max-Prefix beendet: Pruefen Sie journalctl -u bird oder journalctl -u frr auf die Limit-Treffer-Meldung. Erhoehen Sie das Limit, wenn der Peer legitim gewachsen ist, oder untersuchen Sie, ob es sich um ein Leak handelt. In BIRD2 reaktivieren Sie mit birdc enable upstream_v4. In FRR leeren Sie mit vtysh -c "clear bgp 198.51.100.1".
Legitime Routen werden gefiltert: Pruefen Sie birdc show route filtered oder vtysh -c "show ip bgp neighbors X filtered-routes", um zu sehen, was verworfen wurde. Haeufige Ursache: Ihre Bogon-Liste ist zu aggressiv, oder Ihr Small-Prefix-Schwellenwert lehnt legitime /25-Prefixes eines Kunden ab. Passen Sie den Filter an und laden Sie ihn neu: birdc configure oder vtysh -c "write memory" dann systemctl reload frr.
GTSM lehnt einen gueltigen Peer ab: Beide Seiten muessen GTSM aktivieren. Wenn eine Seite es aktiviert hat und die andere nicht, kommen Pakete mit TTL 1 an und werden von der GTSM-aktivierten Seite verworfen. Pruefen Sie mit tcpdump -i eth0 port 179 -v und beachten Sie den TTL-Wert.
Filter werden nach Aenderung nicht wirksam: In BIRD2 fuehren Sie birdc configure zum Neuladen aus. In FRR, wenn Sie eine Prefix-Liste oder Route-Map aendern, loesen Sie einen Soft Reset aus: vtysh -c "clear bgp 198.51.100.1 in". Ohne dies werden bestehende Routen in der RIB nicht gegen den neuen Filter neu bewertet.
Logs: Beide Daemons loggen standardmaessig ueber das systemd journal.
# BIRD2
journalctl -u bird -f
# FRR
journalctl -u frr -f
Die print-Anweisungen in BIRD2-Filterfunktionen schreiben in das Bird-Log. In FRR aktivieren Sie Debug-Logging mit debug bgp updates in vtysh fuer temporaere Fehlerbehebung. Deaktivieren Sie es danach, da es grosse Mengen an Log-Ausgabe erzeugt.
Dieser Artikel ist Teil der Reihe BGP Bring Your Own IP on a VPS.
Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfaeltigung, Wiederveroeffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.
Bereit, es selbst auszuprobieren?
Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD.
VPS-Angebote ansehen