Nieustanny rozwój. Daniel Fenert

Transkrypt

1 Nieustanny rozwój Daniel Fenert

2 Agenda Historia (z fragmentem prehistorii) Teraźniejszość + krótka analiza post-mortem ataku którego byliśmy celem Plany na przyszłość 2

3 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

4 Ewolucja krok 1 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)

5 Ewolucja krok 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

6 Ewolucja krok 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

7 Ewolucja krok 3 c.d

8 Ewolucja krok 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

9 Ewolucja krok 4 c.d

10 Przenosiny do nowego DC 2011 Czas trwania: 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

11 Przenosiny c.d 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

12 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

13 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

14 Firewall 2011 Q Linux (aktualnie Ubuntu) Iptables Quagga Keepalived Przebudowany moduł ixgbe (NAPI) Wyłączony irqbalance (problemy gdy przerzucił przerwania ze wszystkich sieciówek na 1 rdzeń)

15 Firewall - wydajność 2011 Q 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

16 Liczba reguł w łańcuchu iptables vs. wydajność Wysłane [kpps] Odebrane [kpps] Liczba reguł w łańcuchu Uwagi % SI % SI 760 ~ % SI 760 ~ ~ ~ ~ ~ ~ % SI + ksoftirqd, overrun++

17 Routing - L1/L2

18 Routing L3

19 . 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)

20 . 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

21 . 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 ;)

22 Co dalej Q 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

23 Co dalej Q Nowa platforma oparta o Sandy Bridge: E Łącze backupowe zakończone na lekko zmodyfikowanym Peerze I wiele, wiele innych :)

24 Q&A Daniel Fenert

25 Daniel Fenert