IDS – Tutkitko ennen kuin hutkit? Osa 2

TNNetin IDS-palvelu

TNNet ei luonnollisestikaan ole maan ainoa IDS-palvelua tarjoava yritys, vaan samankaltaista palvelua tarjoavat lähes kaikki palomuurivalmistajat. TNNetin vahvuus muihin verrattuna on avoimeen lähdekoodiin perustuva palvelu sekä se, että kyseessä on aidosti palvelu, jolla saa palvelua. Asiakkaan ei siis tarvitse istua huuli pyöreänä kuvaajiensa edessä ja ihmetellä, että onkohan verkossa nyt tapahtunut jotain.

Avoimen lähdekoodin suurimmat edut ovat palvelun hinta ja kustomoitavuus. Palvelun hintaa eivät nosta lisenssimaksut laitevalmistajille. Lisäksi palvelu ei ole ”kaikille sama”, vaan sitä voidaan muokata kunkin asiakkaan tietoverkon mukaan.

Kaupallisissa tuotteissa on myös usein sivuutettu mahdolliset ristiriidat Suomen lainsäädännön kanssa. Useat kaupalliset tuotteet on tehty Amerikassa heidän paikallisia säädäntöjään noudattaen. Suomessa kuitenkin ihmisten tietoliikenteen seuraamista koskevat rajoitteet ovat tarkempia siitä, mitä dataa saa kerätä ja miten sen saa esittää. Suomessa ei esimerkiksi saisi seurata yksittäisen käyttäjän liikennettä sillä tasolla, että näkee käykö hän Facebookissa.

Lisäksi kaupalliset palvelut sortuvat melko usein niin sanotun ”turhan tiedon” keruuseen. Onko yrityksen liiketoiminnalle aidosti tärkeää tietää, kuinka paljon ihmiset käyvät Facebookissa ja Iltalehdessä? Olisihan se kiva tietää, mutta ei se varsinaisesti tietoturvauhka ole, eikä edes täysin lain puitteissa. Pahimmassa tapauksessa työntekijän vapaan surfailun estäminen haittaisi työntekoa, sillä luovassa työssä työn tauottaminen ja muiden asioiden ajattelu ovat erittäin tarpeellista. Jos on koko ajan kiire työntää kelkkaa, ei tule ajatelleeksi, että pyörät voisivat auttaa.

TNNetin palvelussa on pidetty huoli siitä, että asiakkaan ei tarvitse pelätä mahdollisia GDPR-uhkasakkoja tai muita seuraamuksia palvelun käytöstä, päinvastoin, TNNetin palvelua käyttämällä asiakas täyttää GDPR:n luonnetta panostamalla omaan tietoturvaansa. Lisäksi palvelun tarkoituksena on tuottaa aidosti kiinnostavaa dataa, jolla saadaan mahdollisia tietoturvauhkia kiinni. Toki teknisesti olisi mahdollista myös esittää kuvaaja Facebookin käytöstä, tämä tosin vaatisi asiakkaan konsultoinnin lain edellyttämistä proseduureista.

Miksi kaksi konetta ovat generoineet lähes kaiken liikenteen Internetiin? Miksi DNS-kyselyitä on noin paljon? (Kuva Jari Lehtosen sisäverkosta.)

IDS-pähkinä

Otetaanpa vielä blogin loppuun tosielämän aivopähkinä, joka voisi olla täysin autenttinen tilanne myös asiakkaan sisäverkosta. Blogia kirjoittaessani havaitsin omasta sisäverkostani alla olevan kuvanmukaiset hälytykset.

Ylin rivi herätti mielenkiintoni. (Kuva Jari Lehtosen sisäverkosta.)

Miksi ylimmän rivin hälytyksiä on tullut noin paljon? Mikä laitteeni on .100 loppuisessa IP-osoitteessa? Miksi Googlen DNS-palvelut (8.8.8.8) liikennöivät verkkooni, kun en edes käytä niitä?

Ensimmäinen ongelmahan oli .100 loppuisen laitteen tunnistaminen. Kyseessä on DHCP-alueen ensimmäinen osoite, joten sehän voisi käytännössä olla mikä laite tahansa. Onneksi IDS-palvelu ylläpitää myös DHCP-lokia, josta löytyi laitteen MAC-osoite ja hostname. Molemmat näistä viittasivat Samsungin Android puhelimeeni.

Miksi sitten Googlen DNS-palvelimet liikennöivät verkkoni suuntaan, kun käytän aivan muita nimipalvelimia? Nopealla 1+1 laskulla päättelin, että Androidihan on Googlen tekemä käyttöjärjestelmä, joten Googlen DNS-palvelut lienevät pakotettuna puhelimiin automaattisesti.

Entä mikä tuo itse hälytys on? Tässä oli turvauduttava syytetyn muihin palveluihin, eli Googlen hakukoneeseen. Hakutulokset paljastavat nopeasti, mikä kyseinen haavoittuvuus tarkalleen on, mille laitteille se on haitallinen ja miten sen voisi estää. Havaitsin, että haavoittuvuus ei koske Android puhelimia, vaan ainoastaan tiettyjä Microsoftin järjestelmiä, joten tästä ei aiheutunut välitöntä katastrofia.

Miten tällaisen hälytyksen voisi estää jatkossa, jos siitä ei kerran ole haittaa? Hälytyksen voisi esimerkiksi poistaa kokonaan, jolloin sitä ei generoituisi enää ollenkaan, mutta tämä ei ole toimiva ratkaisu, jos verkossa olisikin haavoittuvuuden alainen laite. Googlen DNS:n liikenteen voisi estää kokonaan tuolle kohde IP:lle? Ei kestävä ratkaisu, sillä DCHP-alueella osoitteet voivat muuttua. Toki liikenteen voisi estää DHCP-alueelle tai koko verkkoon. Yksi vaihtoehto olisi lukita puhelimen MAC-osoitteelle oma IP ja estää liikenne ainoastaan siihen, tämä ratkaisu kestää niin kauan kuin puhelin pysyy samana.

Mikä näistä sitten olisi paras ratkaisu? Se on keskustelu, joka käydään aina asiakkaan ja TNNetin asiantuntijan välillä. Tässä tapauksessa asiantuntijan ja asiakkaan henkilökohtaisen monologin tuloksena oli estää Googlen nimipalvelinten liikenne kokonaan sisäverkkoon, sillä tiedän oman DHCP:ni jakavan muita nimipalvelimia.

Jos blogi herätti kysymyksiä, ajatuksia tai muita tuntemuksia, niin ottakaa rohkeasti yhteyttä suoraan minuun jari.lehtonen@tnnet.fi tai myyntiimme myynti@tnnet.fi.


Kirjoittaja
Jari Lehtonen
Järjestelmäasiantuntija

 

Lue lisää muista blogiartikkeleista tästä