YouTube: https://www.youtube.com/watch?v=xlXUAgLjYCU&index=36&list=PLnKL6-WWWE_VNp6tUznu7Ca8hBF8yjKj2

1. www.comp.com.pl
BGP Flowspec czyli jeden ze
sposobów ochrony klientów
przed złym Internetem
Warszawa, marzec 2017

2. Czym jest DDoS?
DDoS (ang. distributed denial of service, rozproszona odmowa usługi) – atak na system
komputerowy lub usługę sieciową w celu uniemożliwienia działania poprzez zajęcie
wszystkich wolnych zasobów, przeprowadzany równocześnie z wielu komputerów (np.
zombie).
Źródło: wikipedia
Kilka przykładów z 2016 roku:
• DYN – 100,000 hostów
• Brian Krebs – ruch osiągnął 620Gbps; dwukrotność ataku, jakiego kiedykolwiek
doświadczył Akamai
• Strony kampanii prezydenckich Clinton i Trumpa
• Olimpiada w Rio – ruch osiągnął 540Gbps
• Atak na rosyjskie banki na początku listopada 2016 – 24,000 hostów z 30 krajów

3. Jak z nim walczyć?
• Static Discard Routes
• Firewall Filters
• Destination Remotely Triggered Black Hole (D/RTBH)
• Source Remotely Triggered Black Hole (S/RTBH)
Operator ISP
Internet
Klient

4. Realna alternatywa
BGP FlowSpec:
• Zdefiniowany w ramach RFC 5575
• Dwa nowe AFI/SAFI:
• AFI/SAFI = 1/133: Unicast Traffic Filtering
Applications
• AFI/SAFI = 1/134: VPN Traffic Filtering
Applications
• Informacje o flowach są weryfikowane w zakresie
zgodności z tablicą routingu przed utworzeniem
odpowiadającego filtra firewall
• Akcja jaka ma być zastosowana dla danego
ruchu jest określona przy pomocy BGP Extended
Community
Community Akcja
0x8006 traffic-rate
0x8007 traffic-action
0x8008 redirect
0x8009 traffic-marking
Typ Przenoszona informacja
1 Destination Prefix
2 Source Prefix
3 IP Protocol
4 Source or Destination Port
5 Destination Port
6 Source Port
7 ICMP Type
8 ICMP Code
9 TCP flags
10 Packet length
11 DSCP
12 Fragment Encoding
Wspiera IPv4 oraz IPv6!

5. Jak wdrożyć?
• Inter-domain DDoS mitigation
• Filtry są generowane i wysyłane do sieci operatora, gdzie następuje ich
automatyczna implementacja; brak działań ze strony operatora; zalecana weryfikacja
filtrów wysyłanych przez klienta
• Ważna jest rozsądna ochrona przed filtrami generowanymi przez klienta
• Intra-domain DDoS mitigation
• Filtry są generowane wewnątrz sieci operatora po uprzednim kontakcie klienta ze
służbami operatora; brak konieczności weryfikacji; pełna kontrola nad generowanymi
filtrami; najczęściej z wykorzystaniem Route Reflector
• Wymagana jest koordynacja między klientem a operatorem
• Scrubbing Center
• Dzięki akcji redirect odsyłamy ruch do dedykowanego VRF, gdzie ruch może być
„oczyszczony” dzięki dedykowanym do tego urządzeniom

6. Jak weryfikujemy dane od klienta?
RFC 5575 określa warunki jakie musi spełniać filtr przed jego zastosowaniem:
1. Adres docelowy (blokowany) zagnieżdżony w specyfikacji filtra jest zgodny z najlepiej
pasującym prefiksem unicast pochodzącym z tego samego źródła (originator).
2. Nie ma bardziej szczegółowych prefiksów pochodzących z innego sąsiadującego AS, niż
te, z którymi porównywaliśmy się w kroku 1.
Jako opcję możemy wyłączyć weryfikację filtrów opisaną powyżej lub też jasno określić
akceptowane adresację w ramach filtrów.

7. Best Practices
• Inter-domain
• Limit dla prefiksów (flow route) odbieranych od klienta – 1?
• Polityka jasno określająca akceptowane prefiksy (community, długość prefiksu – host
route?) odbierane od klienta
• Maksymalna liczba prefiksów w tablicy routingu
• Intra-domain & Scrubbing Center
• Nie przyjmujemy prefiksów od urządzeń PE na RR
• Maksymalna liczba prefiksów w tablicy routing na PE

8. Przykład konfiguracji – klient
routing-options {
flow {
route block {
match {
destination 100.100.101.100/32;
protocol tcp;
destination-port 443;
}
then discard;
}
term-order standard;
}
}
protocols {
bgp {
group eBGP {
family inet {
flow;
}
export flowspec;
neighbor 100.100.100.101 {
peer-as 64512;
}
}
}
}
policy-options {
policy-statement flowspec {
term 1 {
from rib inetflow.0;
then accept;
}
term 2 {
then reject;
}
}
}

9. Przykład konfiguracji – operator
routing-options {
term-order standard;
}
}
protocols {
bgp {
group eBGP {
family inet {
flow;
}
neighbor 100.100.100.102 {
peer-as 64513;
}
}
}
}

10. Praktyka?

11. Firewall on Demand
• Firewall on Demand – aplikacja webowa opracowana w GRNET (licencja GNU)
• Wymagania:
 Serwer linuxowy
 Router z BGP z dostępem przez netconf (ssh)
 Sieć szkieletowa „z uruchomionym BGP flowspec”

12. Podstawowe cechy FoD
• Filtry (reguły) zakładane są przez WWW i rozsyłane z użyciem BGP/flowspec
• Filtry po określonym czasie automatycznie wygasają

13. Zakładanie reguły
• Użytkownicy mogą zakładać filtry (reguły) tylko dla swoich zakresów adresów IP
• Możliwość oddelegowania „podzakresu” IP do innego użytkownika (klienta)
• Powiadomienia emailowe o założeniu/skasowaniu/edycji reguły
route test_Bilbo_QZZFXU {
match {
destination 212.51.192.254/32;
source 0.0.0.0/0;
protocol tcp;
destination-port 80;
}
then discard;
}
}

14. Przegląd reguł FoD

15. Administracja FoD
 Users (Imię, Nazwisko, Email)
 User profiles (prawa do
zakładania reguł)
 Peery (domeny administracyjne)
 Peer ranges (zakresy adresów
IP
 Techc emails, Peer notifys
(wysyłanie maili)
 Flowespec (definicja filtrów i
możliwych akcji)

16. Wady/zalety
Wady:
• Słaba dokumentacja, „rozbudowane życie wewnętrzne”, mało aktywny support
• Błędy
Zalety:
• CLI jest seksy ale nie w sobotę o 4:30 AM
• Możliwość zakładania na routerze filtrów, przez użytkowników bez konieczności dawania
im praw konfiguracyjnych
• Filtry zakładane przez WWW – brak wymogu zaawansowanej wiedzy ze strony
użytkownika
• Możliwość ograniczenia filtrowanych adresów IP do zakresu przypisanego do użytkownika

17. Możliwe warianty implementacji
• „wdrożenie wewnętrzne ISP”:
 router FoD wewnątrz sieci ISP
 brak konieczności konfiguracji filtrów i polityk importu/eksportu (+)
 filtrowanie jedynie w szkielecie ISP (-)
• „proste wdrożenie operatorskie”:
 sesje BGP flowspec do klientów
 konieczność akceptowania przez klientów „naszych” prefiksów flowspec (-)
 konieczność filtrowanie otrzymywanych od klientów prefiksów flowspec (-)
 polityki redystrybucji otrzymanych prefiksów klienckich flowspec do innych klientów (-)
 filtrowanie w szkielecie operatora i w sieciach klientów (+)
• „pełne wdrożenie operatorskie”:
 sesje BGP flowspec do klientów, peerów oraz operatorów upstream
 problem z akceptowaniem przez upstream providera prefiksów flowspec klientów których
źródłem NIE są routery klientów (-)
 filtrowanie w szkielecie operatora, w sieciach klientów oraz upstream ISP (+)

18. THANK YOU
www.comp.com.pl
This presentation (hereinafter "Presentation") was prepared by Comp S.A., with its registered seat in Warsaw, (hereinafter "Company") and for information purposes only. The presentation wasprepared in accordance with the best knowledge available at the time of its preparation and with due diligence, but not all the data have been independently verified, and therefore, there is noguarantee that they are complete and fully reflect the possible actual situation. All statements relating to the future are subject to risks which could cause the actual data to differ in a significant wayfrom those arising from the presentation. The Company does not accept any liability in the event that information contained in the presentation turns out to be untrue or incomplete, and does not makeany representations or warranties, explicit or implied, as to the accuracy or completeness of the information contained in the Presentation. The Company shall not make any updates, modifications orrevisions of any information, data or statements included in the Presentation, unless applicable laws require otherwise. The data contained in the Presentation cannot be treated as an invitation totender, or an offer to purchase any securities or to make any investment decisions. The Presentation is also not an offer or invitation to conduct any other transactions. The Company is notresponsible for any effects of the decisions taken as a result of familiarizing oneself with this Presentation. The only reliable source of information concerning the Company are prospectuses approvedby the competent supervisory authority and the current and periodic reports submitted by the Company in compliance with the disclosure requirements arising from the provisions of applicable law.
Warszawa, marzec 2017