BGP zdalnie sterowany filtr czarnej dziury (RTBH) dla Juniper

Próbuję znaleźć najbardziej elegancki sposób na wdrożenie filtru RTBH dla tras otrzymanych od klienta.

Filtr powinien:

1. Akceptuj tylko własne prefiksy klientów z listy prefiksów
2. Akceptuj tylko / 32 prefiksy
3. Tylko przedrostki ze społecznością Blackhole
4. Ustaw następny przeskok na następny przeskok RTBH (192.0.2.1)

Na początek przejrzałem dokument „ Konfigurowanie warunków dopasowania w warunkach zasad routingu ” firmy Juniper.

Najpierw pomyślałem o połączeniu prefix-list-filtertylko pasujących tras z listy prefiksów klientów i route-filterograniczeniu akceptowanych prefiksów do / 32, tak jak:

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

Ale potem natknąłem się na te informacje w dokumencie:

Jeśli skonfigurujesz zasadę, która zawiera kombinację filtrów trasy, list prefiksów i filtrów adresów źródłowych, są one oceniane zgodnie z logiczną operacją LUB lub wyszukiwaniem najdłuższej trasy.

Jak rozumiem to (i uważam, że to trochę niejasne), jeśli mogę użyć prefix-list-filter, route-filteri / lub source-address-filterw tym samym okresie będzie ona oceniana z najdłuższego meczu lub pomiędzy nimi, co sprawia, że podejście to bezużyteczne .

Wymyśliłem następujący filtr. hostroutes-onlyTermin odwraca wszystkie prefiksy krótszy niż / 32 do następnej polityki. Następnie prefixestermin pasuje, jeśli / 32 znajduje się w zasięgu klienta, pasuje do jego ścieżki i ma ustawioną społeczność blackhole:

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

Czy to jest najbardziej elegancki sposób na poradzenie sobie z tym? Jakieś inne rozwiązania?

Nie ma powodu, aby ograniczać klienta tylko do blackhole / 32, zezwalać mu na czerpanie z nich wszystkiego.

Coś takiego:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Pamiętaj, aby ustawić „accept-remote-nexthop” w ustawieniach BGP, aby następny przeskok mógł zostać zmieniony na coś innego niż adres łącza.

Zdecydowanie popieram również to, że dostawcy zaczynają wspierać różne społeczności blackhole niż tylko „full blackhole”. Zwłaszcza jeśli prowadzisz działalność w więcej niż jednym kraju, zwykle atak odbywa się z tranzytu i często klient faktycznie chce uzyskać dostęp do peerów krajowych, więc warto wdrożyć kilka poziomów blackhhole:

1. Pełny
2. Poza krajem lokalnym (lokalny IXP, widoczni są wszyscy klienci AS +)
3. Poza obszarem lokalnym (jeśli dotyczy, jak dla mnie może to być „Nordics”)
4. Włącz / wyłącz określony router równorzędny w blackhole

Z przyjemnością podam przykład, jak zaimplementować coś takiego w JNPR DCU / SCU, pod warunkiem, że routery równorzędne to JNPR, ale jest to możliwe tylko w przypadku społeczności, nieco bardziej niezręczne.

Jeśli absolutnie chcesz ograniczyć opcje swojego klienta, możesz dodać to:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

W ten sposób powinno być logiczne ORAZ. Ale tak naprawdę nie widzę wartości w tworzeniu złożoności w celu zmniejszenia ekspresji konfiguracji.