Lähiverkon salakuuntelu

Petri Virkkula <pvirkkul@iki.fi>

Yhteenveto

Lähiverkon salakuuntelulla voi hyökkääjä usein saada selville arkaluontoisia tietoja, tai salasanoja joiden avulla hän voi jatkaa hyökkäystään uudesta tietokoneesta käsin. Useat keskittimet sisältävät optioita (esim. "salakuuntelun esto") joiden voisi kuvitella estävän salakuuntelun. Tässä dokumentissa kerrotaan kuinka tämänkaltaiset estot voidaan kiertää ARP-yhteyskäytäntöä hyödyntämällä.


Sisällys

Kuvaluettelo


Sanasto

ARP
Address Resolution Protocol. Yhteyskäytäntö jolla selvitetään IP-osoitetta vastaava MAC-osoite.
broadcast
Lähetystapa jossa vastaanottajina ovat kaikki verkon laitteet, käytännössä rajoittuen kaikkiin aliverkon laitteisiin.
IP
Internet Protocol. Yhteyskäytäntö joka hoitaa pakettien reitityksen lähettäjältä vastaanottajalle.
MAC
Media Acces Control. OSI:n siirtokerroksen alempi puolisko.
MITM
Man-In-The-Middle. Hyökkäystapa jossa salakuuntelija uskottelee tietojen lähettäjälle olevansa oikea vastaanottaja, ja vastaanottajalle olevansa oikea lähettäjä.
OSI
Open Systems Interconnection. Avoin viitekehys tietoliikennejärjestelmille.
unicast
Lähetystapa jossa kohteena on yksi verkon laite.


1. Johdanto

Verkkoliikenteen salakuuntelu on varsinkin lähiverkoissa suuri ongelma. Hyökkääjät pyrkivät salakuuntelun avulla saamaan selville luottamuksellisia tietoja, luottokorttien numeroita yms. Lisäksi salakuuntelun avulla voidaan saada selville myös salasanoja tietokoneisiin joita voidaa käyttää hyökkäyksen jatkamiseen.

Perinteisissä väylämuotoisissa verkoissa salakuuntelu on ollut helppoa, koska kaikki samaan fyysiseen verkkosegmenttiin liitetyt koneet ovat vastaanottaneet kaiken liikenteen. Salakuuntelua on rajoittanut, muttei täysin estänyt, fyysisiä verkkosegmenttejä erottaneet sillat ja reitittimet.

Uudemmissa verkkoratkaisuissa käytetään usein keskittimiä, jolloin muodostuu fyysisesti tähtimäinen verkko, vaikkain toiminta on yhdenmukaisuuden takia edelleen loogisesti väylä. Kuvassa 1 on esimerkki tälläisestä verkkotopologista.

Esimerkki verkkotopologia
Kuva 1: Esimerkki verkkotopologia

Keskittimiin on laitettu salakuuntelun esto-optioita. Esimerkiksi Hewlett-Packardin AdvanceStack tuoteperheen keskittimissä on optio, jolle on optimisesti annettu nimi salakuuntelun esto ("Eavesdrop Preventation") [AS-SECURITY].

Tässä dokumentissa käsitellaan kuinka IP-liikenteen salakuuntelu on edelleen mahdollista vaikka käytössä olisikin edellämainittuja salakuuntelun estoja. Salakuuntelu onnistuu edelleen hyväksikäyttämällä ARP-yhteyskäytäntöä. Kuvattu menetelmä edellyttää että verkkotopologia samankaltainen kuvassa 1 olevan kanssa, sekä sitä että ko. verkossa on olevilla laitteilla on sama verkko-osoite.

2. Taustatietoa

2.1 ARP

ARP-yhteyskäytännön avulla IP-yhteyskäytäntö selvittää IP-osoitetta vastaava MAC-osoite [RFC826, Comer1991]. ARP:n käyttö ei ole kuitenkaan rajoittunut vain IP-yhteyskäytännön yhteyteen [RFC1700], mutta tässä dokumentissa käsitellän ainoastaan sen käyttöä IP:n yhteydessä. ARP-yhteyskäytäntö sijaitsee OSI-mallissa verkkokerroksessa, käyttäen apunaan siirtoyhteyskerroksen palveluja. ARP on Internet standardi [RFC2200].

Jos IP-pakettia lähettävä laite ei tiedä kohdekoneen tai reitittimen Ethernet-osoitetta, joutuu se lähettämään ARP-pyynnön. Tämä palvelupyyntö lähtetään käyttämällä Ethernet broadcastia. ARP-pyyntö sisältää lähettäjän Ethernet- ja IP-osoitteen sekä kyselyn kohteena olevan IP-osoitteen. [RFC826]

Kun verkossa oleva laite saa ARP-kyselyn, ensimmäinen operaatio on tallettaa palvelupyynnön Ethernet- ja IP-osoitteen muodostama pari omaan sisäiseen tauluunsa, mahdollisesti päivittäen ennestään taulussa oleva IP-numeroa vastaava Ethernet-osoite. Vasta tämän jälkeen katsotaan pitääkö kyselyyn vastata eli kysyttiin siinä kyselyn vastaanottaneen laitteen Ethernet-osoitetta. Jos kysyttiin kyselyyn vastataan käyttämällä unicastia. [RFC826]

ARP-kysely voidaan lähettää myös käyttämällä unicastia. Tällöin tarkoituksena on lähinnä selvittää se että onko vastaanottava laite edelleen toiminnassa. Toiminta unicast-kyselyn vastaanotossa on aivan sama kuin broadcast-kyselyn vastaanotossa (eli ensin otetaan talteen kyselyn tekijän tiedot). Unicast-kyselyitä ei tosin tehdä käytännössä lähes koskaan. [RFC826]

Yleensä laitteiden käyttöjärjestelmä sallii ylläpitäjän asettaa myös kiinteästi IP-osoitetta vastaava Ethernet-osoite ARP-taulukoihin. Näitä tietoja ei koskaan poisteta, toisin kuin verkosta saatuja tietoja, jotka tuhotaan määrätyn ajan jälkeen laskettuna siitä kun ko. tieto oli viimeksi päivitetty [RFC1122].

2.2 Keskittimet

Keskittimien perustoiminto on kopioida vastaanotettu kaikkiin portteihin lukuunottamatta siihen josta se oli vastaanotettu [Halsall1996]. Tällöin keskitin toimii aivan samoin kuin moniporttitoistin, ollen OSI-mallin fyysisessä kerroksessa.

Kehittyneemmät keskittimet toimivat kytkimen tavoin. Tällöin vastaanotetut kehykset siirretään vain siihen porttiin johon vastaanottaja on kytkettynä. Tämä merkitsee sitä että keskitin onkin OSI-mallin siirtoyhteyskerroksessa.

Joka portille erikseen voidaan määrittää sallittu Ethernet-osoite. Tämä osoite voidaan asettaa kiinteästi, tai keskitin asettaa sen ensimmäiseksi osoitteeksi jota ko. portissa käytetään. Viimeisenä vaihtoehtona on sallia kaikki Ethernet-osoitteet, eli sallia keskittimen päivittää edellä mainittua sallittua Ethernet-osoitetta aina havaitessaan uuden osoitteen. [AS-SECURITY]

Keskittimissä oleva "salakuuntelun esto" optio oleva estää portteihin kytkettyjen laitteiden näkemästä kehyksiä joitä ei ole näille laitteille osoitettu. Esto tapahtuu käyttämällä kytkentäisyyttä tai sitten välittämällä kehyksen tieto-osassa roskaa muille paitsi oikealle vastaanottajalle. Tämä suojaustoimenpide tehdään Ethernet-kehyksessä olevan vastaanottajan osoitteen ja portteihin määritellyn sallitun Ethernet-osoitteen perusteella. [AS-SECURITY]

Keskittimissä on myös hyökkäyksen havaitsemisoptio. Tämä optio hälyttää ylläpidon jos keskittimen portista tulee kehyksiä joiden lähettäjän osoite ei ole sallittu. [AS-SECURITY]

3. Hyökkäys

Keskittimen salakuuntelun eston kiertäminen on MITM-hyökkäyksen variaatio. Kun hyökkääjä haluaa haluaa kuunnella kahden tietyn laitteen välistä IP-verkkoliikennettä hänen tarvitsee lähettää ARP-paketti kummallekin laitteelle. Paketeilla valehdellaan IP-osoitetta vastaava Ethernet-osoite, siten että kumpikin laite laite lähettää toiselle osapuolelle tarkoitetut kehykset hyökkääjän laitteelle joka välittää kehykset oikealle laitteelle käyttäen oikeaa Ethernet-osoitetta. Hyökkääjän laite saa näin kaikki näiden kahden laitteen välisen liikenteen itselleen. Hyökkäyksen ei tarvitse edes rajoittua salakuunteluun, pakettien sisältöä voidaan aivan vapaasti muuttaa ennen jatkolähetystä.

Hyökkäyksessä ongelmallisinta on ARP:in toiminnan määritelmässä oleva ominaisuus. Tämä ominaisuus on se että ARP-taulua päivitetään myös kyselyissäkin olevilla tiedoilla [RFC826]. Kyselyt lähetetään pääsääntöisesti käyttäen broadcastia. Jos jompikumpi salakuunneltavista laitteista lähettää kyselyn verkkoon, niin toinen laite saa oikean kyselyn lähettäjän Ethernet-osoitteen, vaikka kysely ei sitä koskisikaan. Tästä syystä hyökkääjän pitääkin lähettää tämänkaltaisen kyselyn jälkeen ARP-paketti salakuunneltaville laitteille käyttäen unicastia jotta tilanne korjaantuu.

Jos kuvassa 1 olevaan verkkotopologiaan lisätään kytkimiä lisääntyvät ongelmat. Ainakin Hewlett-Packardin kytkimissä on optio jolla rajoitetaan ARP-broadcasteja [AS-SWCONF]. Kytkimen saatua ARP-pyynnön broadcastina se ei välitä sitä eteenpäin jos ko. kytkin pystyy itse antamaan siihen vastauksena [AS-SWCONF]. Tämän option tarkoituksena on vähentää broadcast-liikennettä verkossa, mutta samalla se vaikeuttaa varsinkin yhteyksien alkujen salakuuntelua, koska broadcastattu ARP-pyyntö useimmiten merkitsee uuden yhteyden alkua. Yhteyden alku on tärkeä koska tunnistautuminen (eli salasanan välitys) tapahtuu pääsääntöisesti tällöin.

4. Suojautuminen

Yksinkertaisin tapa estää tässä dokumentissa kuvattu hyökkäys on olla käyttämättä dynaamista ARP-yhteyskäytäntöä. Sen sijaan laitteiden omistajat asettavat kiinteästi ARP-tauluun niiden laitteiden Ethernet-osoitteet joita he käyttävät. Jos ei ole paljoa aliverkon sisäistä liikennettä, niin pelkästään reitittimen Ethernet-osoitteen kiinteästi asettaminen auttaa. Kiinteiden Ethernet-osoitteiden käyttäminen tuottaa ongelmia esimerkiksi silloin kun reitittimen Ethernet-osoite muuttuu. Tällööin jokaisessa verkon laitteessa erikseen joudutaan päivittämään ARP-tauluja. Tämä on usein liian hankalaa.

Hyökkäyksen havaitseminen on mahdollista kuuntelemalla kaikkea verkkoliikennettä. Ongelmana on se että jokaisessa fyysisessä Ethernet-segmentissä pitäisi olla oma kuuntelupisteensä. Valvontajärjestelmä pitää yllä Ethernet- IP-osoitepareista. Huomatessaan että jokin laite käyttää väärää osoitetta järjestelmä tekee hälytyksen. Tämänkaltaista valvontajärjestelmää voisi hyödyntää muuhunkin, kuten esimerkiksi BOOTP- ja DHCP-yhteyskäytäntöjen. palvelimena, väärien verkkoasetusten havannoijana (esimerkiksi väärä verkkopeite (netmask) näkyy IP-broadcast-osoitteen virheellisyytenä), jne. Eräs tämänkaltainen tuote on Network Flight Recorder [NFR].

Paras suojautumiskeino on käyttää tietoliikenteen salausta ja vahvaa todennusta. Tällöin hyökkääjä ei hyödy siitä että hän saa kohdekoneille tarkoitettuja kehyksiä.

5. Yhteenveto

Salakuuntelun estäminen ei yleensä toimi siten kuin toivotaan. Estojen kiertämiseksi löytyy lähes aina keinoja joita hyökkääjät hyödyntävät nopeammin kuin uusia suojautumiskeinoja keksitään. Keskittimissä oleva salakuuntelun esto ei millään lailla estä teknisesti asiansatuntevaa hyökkääjää. Se kyllä vaikeuttaa kylläkin salakuuntelua, ja mahdollistaa salakuunteluyritysten havaitsemisen.

Valvonnalla huomataan suurin osa hyökkäyksistä. Esimerkiksi tässä dokumentissa kuvatun hyökkäyksen havaitsee helposti asianmukaisella ohjelmalla. On vain varmistettava että kyseessäoleva valvontaohjelma tekee hälytyksen ylläpidolle, tai sitten ylläpidon pitää tarkistaa valvontatiedot todella tiheään.

Paras ratkaisu on käyttää kaikissa yhteyksissä salausta. Tällöin ei ole merkitystä saako hyökkääjä vastaanotettua kehyksiä joita ei ole hänelle tarkoitettu.


Lähdeluettelo

***** [RFC826] David C. Plummer, "An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48-bit Ethernet Addresses for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS, Marraskuu 1982, viitattu 29.10.1997.
<URL:ftp://ftp.funet.fi/pub/doc/rfc/rfc826.txt>
**** [RFC1122] R. Braden, editor, "Requirements for Internet Hosts -- Communication Layer", STD 3, RFC 1122, Internet Engineering Task Force Host Requirements Working Group, Lokakuu 1989, viitattu 29.10.1997.
<URL:ftp://ftp.funet.fi/pub/doc/rfc/rfc1122.txt>
** [RFC1700] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, RFC 1700, University of Southern California/Information Sciences Institute, Lokakuu 1994, viitattu 30.10.1997.
<URL:ftp://ftp.funet.fi/pub/doc/rfc/rfc1700.txt>
**** [RFC2200] J. Postel, editor, "Internet Official Protocol Standards", STD 1, RFC 2200, Internet Architecture Board, Kesäkuu 1997, viitattu 29.10.1997.
<URL:ftp://ftp.funet.fi/pub/doc/rfc/rfc2200.txt>
***** [AS-SECURITY] "HP AdvanceStack Assistant User Guide: Using Network Security Tools", Hewlett-Packard Company, viitattu 2.11.1997.
<URL:http://www.hp.com/rnd/support/asawin/prodman/securty.htm>
**** [AS-SWCONF] "HP AdvanceStack Assistant User Guide: Configuring Your Switch", Hewlett-Packard Company, viitattu 2.11.1997.
<URL:http://www.hp.com/rnd/support/asawin/prodman/swconf.htm>
*** [NFR] "Network Flight Recorder in action!", Network Flight Recorder, Inc., viitattu 2.11.1997.
<URL:http://www.nfr.net/products/technology.html>
**** [Comer1991] Douglas E. Comer, "Internetworking With TCP/IP, Vol I: Principles, Protocols, and Architecture, Second Edition", Prentice-Hall, Inc., 1991, ISBN 0-13-474321-0
**** [Halsall1996] Fred Halsall, "Data Communications, Computer Networks and Open Systems, Fourth Edition", Addison-Wesley Publishing Company, 1996, ISBN 0-201-42293-X

Lisätietoja aiheesta

*** J. Postel, editor, "Internet Protocol - DARPA Internet Program Protocol Specification", STD 1, RFC 791, University of Southern California/Information Sciences Institute, Syyskuu 1981, viitattu 30.10.1997.
<URL:ftp://ftp.funet.fi/pub/doc/rfc/rfc791.txt>
** Bill Croft, John Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford University and Sun Microsystems, Syyskuu 1985, viitattu 2.11.1997.
<URL:ftp://ftp.funet.fi/pub/doc/rfc/rfc951.txt>
** R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, Maaliskuu 1997, viitattu 2.11.1997.
<URL:ftp://ftp.funet.fi/pub/doc/rfc/rfc2131.txt>
**** "HP AdvanceStack Assistant User Guide", Hewlett-Packard Company, viitattu 30.10.1997.
<URL:http://www.hp.com/rnd/support/asawin/prodman/gsinfo.htm>
*** "ARP", Optimized Engineering Corporation, viitattu 2.11.1997.
<URL:http://www.optimized.com/tech_cmp/arp.html>
**** "Resolution of Physical Addresses", Optimized Engineering Corporation, viitattu 2.11.1997.
<URL:http://www.optimized.com/tech_cmp/arp_2.html>
* Uyless Black, "Computer Networks; Protocols, Standards and Interfaces", Prentice-Hall International, Inc., 1987, ISBN 0-13-166091-8

[ $Revision: 1.45 $ | $Date: 1997/11/08 19:09:34 $ ]
© Copyright 1997 Petri Virkkula <pvirkkul@iki.fi>
All rights reserved.