DDoS oikeastiko ongelma? Sami J. Mäkinen

Transkriptio

1 DDoS oikeastiko ongelma? 1

2 DDoS, häh? Distributed denial of service, hajautettu palvelunestohyökkäys Ei aina DDoS vaan joskus vain DoS Perusidea on aina samansuuntainen, pyritään ylikuormittamaan järjestelmä tai jokin sen osa niin hyvin, että palvelu romahtaa kokonaan tai osittain. Voidaan luokitella: brutaali DoS ja älykäs DoS Raja on häilyvä, kuten aina... 2

3 Brutaali DoS Tuupataan paketteja/pyyntöjä/liikennettä/bittejä kohteeseen ihan niin paljon kuin ikinä pystytään. Hyökkääjän resursseista ja kohteen resursseista ja kyvyistä riippuen voi onnistua tai ehkä ei. Tarpeeksi brutaali hyökkäys vie kaiken WAN-yhteyden kapasiteetin. Onnistunut torjunta on näissä tapauksissa hankalaa, mutta tietyin rajoituksin mahdollista. Palomuurin, kuormanjakajan tms. laitteen tilataulun täyttyminen on seuraava todennäköinen riski, jos hyökkäys ei saanut yhteyksiä tukkoon. 3

4 DoS-torjunta, keinoja.. Tarvitaan hyvä ja tarkka näkyvyys infraan ja sen kuormitukseen. Pitää olla riittävästi mittareita ja käsitys siitä, mikä on normaalia, ja normaalia vaihtelua. Suomeksi: tarvitaan asiantuntijoita. Mittausväli mieluummin 1 min kuin 5 min. Hälyt. Kaupasta (kalliilla) ostettu IDP-appliance on hyvä, mutta sopivan valitsemiseen ja erityisesti asetusten jatkuvaan säätämiseen tarvitaan perehtymistä. (ks. lihavointi yllä) Itse virkattu IDS-järjestelmän kaltainen valmiste on älyttömän paljon parempi kuin ei IDS-järjestelmää. 4

5 ...eri tilanteisiin Yhteydet tukkiva DoS on ikävä tilanne, eikä siinä tukkeutuneen yhteyden päässä paljoa hyödytä pyristellä. Sumaa pitää päästä raivaamaan ennen viimeistä pullonkaulaa. Ei niin kuvitteellinen esimerkki: oma ASn ja IPosoitteet, oma BGP-reititys ja omat reitittimet operaattoreita vasten. Jos vain jokin tietty kohdeosoite (ks. aiempi kohta hyvä näkyvyys infraan) kärsii hyökkäyksestä, tehdään ns. Blackhole-mainostus. Pelastetaan edes sivulliset. 5

6 Öh, mustaan aukkoon? Hyökkäyksen kohteena oleva prefix mainostetaan kullekin operaattorille sopivalla (etukäteen selvitetyllä ja testatulla) BGP communityllä. Tällöin kukin operaattori pudottaa ao. prefixiin kohdistuvan liikenteen heti reunalla, ja linkkien tukkeutumisen todennäköisyys kutistuu yleensä dramaattisesti. Kikka n:o 6 vanha IP blackholeen, pikainen DNS-muutos ja katsotaan seuraako DoS-liikenne perässä vai ei. Jos kohteena oli IP-osoite eikä DNS-nimi, hyvällä tuurilla palvelu saatiin pelastettua ja käyttäjille homma pelaa kunhan DNS-tiedot päivittyvät kaikkialle. Seuranta on tärkeää! 6

7 Purkki kyykyssä? Yleisesti ottaen reititin jaksaa välittää mitä tahansa liikennettä linjanopeudella, koska sen ei tarvitse käsitellä yhteyksiä eikä tilatietoja. Se näkee vain paketteja. Yleensä pullonkaulaksi muodostuu palomuuri, kuormanjakaja tai näiden takana oleva palvelin. Kaikissa näissä on yhteisenä tekijänä tilatiedon tarve ja käsittely. Siis pelastetaan sillä, joka jaksaa paremmin, sellainen joka ei ehkä jaksa, kun osuu turbiiniin. 7

8 Reititin on kaveri Moderni ja suorituskykyinen reititin välittää yleensä paketit raudalla eikä cpu:lla. Raja on häilyvä. Asiallinen reititin jaksaa pääsynhallinnan (ACL) mekanismeilla sekä sallia/kieltää liikennettä että rajoittaa erikseen määritellyn liikenteen kaistaa. Hyvä nyrkkisääntö on sallia tunnetusti tarpeellinen UDP-liikenne (DNS, OpenVPN jne) ja sen jälkeen sallia rajoitetusti muu UDP, esim. max. 1Mbps. Myös ICMP kannattaa yleensä rajoittaa samoin. Ehkä sama TCP SYN-paketeille, jos rauta osaa? 8

9 Reititin ei korvaa muuria Koska ei ole tilatietoa, reitittimen suodatus ei tietenkään korvaa asiallista palomuuria. Liikenteen karkea suodatus on silti juuri siitä syystä parasta tehdä reitittimessä, koska kaikkein lapsellisimmat ICMP/UDPpommitukset tyssäävät siihen, eikä palomuuri ylirasitu. Yleensä jälkien peittäminen ja hyökkäyksen vahvistaminen (DDoS amplifier) onnistuu helpoiten icmp:llä ja varsinkin udp:llä. Muistisääntö: reititin = pannujauhatus palomuuri = suodatinjauhatus Erinomaiset nuotiokahvit tehdään aina pannulla! 9

10 Resurssien rajaaminen Kuormanjakajissa ja palomuureissa kannattaa mahdollisuuksien mukaan käyttää rajoituksia sessioiden määrälle per policy tai per ip-osoite. Jaetussa ympäristössä (virtualisointi tai muutenvaansamapalvelin-ratkaisu) kannattaa aina kiinnittää parametreihin ja resurssien ylärajoihin huomiota. Muistinkäyttö Prosessoriaika Yhteyksien määrä Kaistankulutus 10

11 Ylikapasiteettia? Vaikka talousmiehille ylimääräinen turha kapasiteetti on iljetys, DoS-tilanteessa se on ihanaa. Vaikka jaettu ympäristö (virtualisointi yms jne) omalla tavallaan lisää riskejä, oikein mitoitettuna se voi myös vähentää niitä, koska yksittäisellä palvelulla tai (virtuaali)palvelimella on tilaa keulia. Oikea mitoitus ei tässä asiayhteydessä yleensä ole se, mitä lähin talousmies haluaa ehdottaa. Aina kannattaa hieman liioitella. 11

12 Varautuminen? Jos mitään ei olla tehty ja pelikaani ehti jo lopsahtaa turbiiniin, ollaan yleensä heikoilla. [tähän kuuluisi kuva: Mohammed Saeed al-sahaf] Asiantunteva suunnittelu. Ammattitaitoinen deploy. Penetraatiotestaus. Kuormitustestaus. HA-testaus. Tahallinen pahanteko itse, ennenkuin joku muu ehtii. LOIC ja muut vastaavat työkalut. 12

13 Hajauttaminen? Leveämmälle skaalaaminen tarkoittaa yleensä, että hyökkääjäkin tarvitsee isomman tussarin, tai enemmän tussareita saadakseen kaiken nurin. Isommassa skaalassa (globaalisti) tietysti toimivat BGP anycast käytetään laajasti DNS-infrassa Managed DNS (tai GSLB tai...) eri paikoista kysyjille annetaan erilaisia vastauksia palvelun IP-osoitteeksi. Pääasiallinen tavoite on saada pienempi latenssi, tehokkaampi palvelu ja nopeampi tietoliikenne, ja sivutuotteena saatiin parempi DoS-sietokyky. Perinteinen DR-ratkaisu saattaa ihan hyvin riittää. 13

14 Itse aiheutettu DoS? Jipii. Asiakkaat ja mutkikkaat järjestelmät keskinäisine riippuvuuksineen. Tässä on muutamia tuulesta temmattuja fiktiivisiä esimerkkejä, joita on dramatisoitu. Nimet on muutettu. Kertoja elää. Suositun uutissaitin etusivulla skaalaamaton kuva (kyllä selain skaalaa!) tai vaikkapa kymmeniä megatavuja painava wav-tiedosto ladattavaksi. Kuuntele haastattelu. Redirect-looppi suositulla sivustolla jollain alasivulla, jossa käy paljon lukijoita. Tehdään sovelluspalvelimelle raskaan puoleinen käyttäjäsessioiden hallinta, ja sille taustareplikointi siltä varalta, että käyttäjä sittenkin siirtyy palvelinten välillä. Päivitetään loadbalancerin softaversiota ja session affinity hajoaa. Kaboom ja replikointi syö resurssit. Tehdään aivan kaikista sivuelementeistä siis myös staattisista navigointisymboleista dynaamisia siten, että ne tuotetaan sovelluspalvelimen läpi. 14

15 Älykäs DoS? Tämä on toiselta nimeltään Pirullinen DoS (PDoS (c) sjm), koska sitä ei aina ole sellaiseksi helppo tunnistaa. Kyseessä on yleensä tietyn ohjelmistovirheen hyväksikäyttäminen koiruuksiin. Ja tämän tyyppisissä haavoittuvuuksissa yleensä DoS on se vähiten vaarallinen hyökkäys. Näihin hyökkäyksiin ei oikein auta muu kuin hyvin hoidettu tietoturvapäivitysten asentaminen + normaali valvonta, seuranta, hälyt, päivystys, reagointi ja eskalointi. Siis tylsä IT-jalkatyö. Perusedellytys on kuten aina, palvelinten ja käyttöjärjestelmien oikeat asetukset. Raskaassa palvelinkäytössä esim. tcp-stackin parametreja ja kaikenlaista muutakin kannattaa hieman säätää. Hyvin säädetty IDP voi ihan hyvin pelastaa. Hyvällä tuurilla. 15

16 Kysyttävää? Kommentteja? Sami J. Mäkinen Chief Systems Architect Cybercom Finland Oy, Data Center 16

17 Anteeksi & Kiitos!