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.
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.
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].
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]
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.
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ä.
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.
***** | [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 |
*** | 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 |