Nieustanny rozwój Daniel Fenert daniel.fenert@netart.pl
Agenda Historia (z fragmentem prehistorii) Teraźniejszość + krótka analiza post-mortem ataku którego byliśmy celem Plany na przyszłość 2
Prehistoria Szkielet i większość sieci 1Gbps, część serwerów podpięta jeszcze na 100Mbps początki XXI wieku 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 Przejście z całością sieci na 1Gbps 2005-2010 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 760 ~745 80 760 ~680 100 760 ~520 200 760 ~320 300 760 ~214 700 75% SI + ksoftirqd, overrun++
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 daniel.fenert@netart.pl
Daniel Fenert daniel.fenert@netart.pl