Ewolucja krok 4 2005 - 2010

Nieustanny rozwój

Daniel Fenert
[email protected]
Agenda

Historia (z fragmentem prehistorii)

Teraźniejszość + krótka analiza post-mortem
ataku którego byliśmy celem

Plany na przyszłość
2
Prehistoria
początki XXI wieku

Szkielet i większość sieci
1Gbps, część serwerów
podpięta jeszcze na 100Mbps

Core sieci stanowią 2xCisco 7200, Cisco LightStream
1010 oraz firewall (standardowy pecet, Linux, 2 karty
1Gbps). Wewnątrz sieci tylko statyczny routing
3
Ewolucja krok 1
2005 - 2010

Przejście z całością sieci na 1Gbps

Routery „Peer” powoli zastępują leciwe i nie
bezproblemowe Cisco 7200

Jeden firewall zostaje zamieniony na redundatną parę
serwerów FW. Pomiędzy Peerami a FW pojawia się
OSPF

Sprzęt na serwerach Peer: core2duo, 1GB ramu,
2x1Gbps, Linux (Debian)

Sprzęt na serwerach FW: core2duo, 4GB ramu,
2x1Gbps, Linux (Debian)
Ewolucja krok 2
2005 - 2010

Zwiększanie wydajności i przepustowości bez dużej
ingerencji w serwery

Serwery Peer: dokładamy 4-portowe karty Intela,
reszta bez zmian

Serwery FW: wymiana procesorów na Core2Quad,
dołożenie 4-portowych kart Intela
Ewolucja krok 3
2005 - 2010

Konfiguracja sprzętowa Peer i FW pozostaje, ale
zwiększamy ilość

3xPeer oraz 4xFW, każdy z FW obsługuje w
przybliżeniu ¼ przestrzeni adresowej/ruchu.

Redundancja FW staje się skomplikowana

Redundantne swiche w core w wersji budżetowej (Dell
PC6248), pierwszy link 10Gbps do DRC
Ewolucja krok 3 c.d.
2005 - 2010
Ewolucja krok 4
2005 - 2010

Nowa platforma oraz nowe procesory Intela pozwalają
zmniejszyć ilość FW (uprościć zarządzanie) oraz
zwiększyć wydajność Firewalli

Specyfikacja: Dell PE610, 2x Xeon X5550, 12GB ramu

Serwery Peer nadal wystarczają i działają w
niezmienionej formie
Ewolucja krok 4 c.d.
2005 - 2010
Przenosiny do nowego DC
2011

Czas trwania: 27.4.2011 - 12.12.2011

Zdecydowana część migracji sprzętu bez
zauważalnych przerw dla klientów

Średnia prędkość transferu podczas jedynej migracji
„off-line” (przejazd przez Kraków) - 18,7Gbit/s
Przenosiny c.d.
2011
Problem, na który się natknęliśmy:

2 niezależne trasy światłowodowe od dwóch różnych
operatorów pomiędzy DC nie zawsze wystarczają podczas remontu na Ruczaju koparka rozkopała
studzienkę teletechniczną w której były obydwa linki…
Duże zmiany
2011
Cel: zwiększenie wydajności, likwidacja ostatnich SPOFów
w sieci

Zakup 2 routerów Juniper MX80 oraz redundantnej
pary Juniper EX4500. Żegnamy się (na chwilę ;) z
Peerami

Upgrade szkieletu sieci do 10Gbps, wymiana kart w
FW na 2x10Gbps

Po 2 switche ToR/szafę

Wszystkie serwery podłączone redundantnie do
switchy ToR
Duże zmiany
2011
Co nas, linuksowców, zaskoczyło:

Brak możliwości zlimitowania
ilości pps (choćby globalnie
per interfejs, nie mówiąc już o
minimalnie bardziej skomplikowanych limitach (np.
hashlimit w iptables)

Czas zestawienia sesji bgp z pełnym feedem - rząd
wielkości różnicy
Firewall
2011 – Q3 2012

Linux (aktualnie Ubuntu)

Iptables

Quagga

Keepalived

Przebudowany moduł ixgbe (NAPI)

Wyłączony irqbalance (problemy gdy przerzucił
przerwania ze wszystkich sieciówek na 1 rdzeń)
Firewall - wydajność
2011 – Q3 2012

Obsługa pakietu kierowana przez driver na określony
rdzeń procesora na podstawie ip/portu

Wydajność z jednego rdzenia na używanym sprzęcie
(Xeon X5550, Intel X520 - ixgbe): bez problemów do
900K pps, powyżej tego pojawiają się straty.

W najgorszym przypadku (cały ruch skupia się na
jednym rdzeniu) to jest maksymalna wydajność
firewalla

Optymalizacja łańcuchów iptables jest bardzo ważna

Warto dropować ruch już w tablicy raw
Liczba reguł w łańcuchu iptables vs. wydajność
Wysłane [kpps]
Odebrane [kpps]
Liczba reguł w
łańcuchu
Uwagi
760
760
1
2% SI
760
760
40
10% SI
760
~760
60
91% SI
760
~750
70
75% SI + ksoftirqd,
overrun++
760
~745
80
760
~680
100
760
~520
200
760
~320
300
760
~214
700
Routing - L1/L2
Routing – L3
.
DDOS

Rzekomy szantaż: Bitch, please
;)
Zbieg wielu wydarzeń znacznie wydłużył analizę i moment
powstrzymanie ataku:

Kilka minut przed atakiem zakończyły się testy jflow
na MX80 (na potrzeby ticketu JTAC – skoki obciążenia
procesora po włączeniu jflow)

Problemy z samoczynnym restartem TFEB w routerach
MX80 (kolejny ticket JTAC – problem występował co
kilka/naście dni od kilku tygodni)
.
DDOS c.d.

Atak w większości wykonany z jednego adresu IP na
jeden docelowy adres i port
Efekty:

Straty pakietów między FW a MX, rozpinanie sesji
iBGP, przełączenia FW master<->failover
.
DDOS c.d.
Wniosek końcowy:

Ataki których byliśmy celem zawsze miały źródło poza
Polską: na sieci znamy się lepiej niż cały świat ;)
Co dalej…
Q4 2012 - …

Jflow już (prawie – JTAC naszym przyjacielem ;) działa
i w kilka sekund jesteśmy w stanie wyciągnąć wszelkie
potrzebne informacje o ruchu

Rozbudowana sieć out-of-band z niezależnym łączem
internetowym. Monitoring przez sieć OoB

Obejście braku limitowania pps w Juniperach – prefix
action policer na klasę /24, snmp trap informujący o
przekroczeniach limitu
Co dalej…
Q4 2012 - …

Nowa platforma oparta o Sandy Bridge: E5-2667

Łącze backupowe zakończone na lekko
zmodyfikowanym Peerze

I wiele, wiele innych :)
Q&A
Daniel Fenert
[email protected]
Daniel Fenert
[email protected]