TLS pärandprotokollid ja TLS 1.3 mõju ID-kaardi kasutusele

Eelmises postituses kirjutasin PHP pärandvarast, täna teen juttu sarnasesse staatusesse jõudnud krüptograafilistest protokollidest. Täpsemalt tuleb jutt TLS (Transport Layer Security) protokolli versioonidest 1.0 ja 1.1, mis kinnitati standarditena vastavalt 1999. ja 2006. aastal.

Kui mäletate, siis eelmisel suvel arutasime Zone veebimajutusteenuse osas TLS versiooni 1.0 vaikimisi keelamist, kuna selle kasutamine ei vasta kehtivatele e-kaubanduse infoturbestandarditele (PCI DSS). Jätsime selle kasutamise kliendi otsustada. Järgmise sammuna lõpetame 1. aprillist 2019 oma veebimajutuses TLS versiooni 1.0 ja 1.1 vaikimisi toetamise. Lubame kliendil pärandprotokollide tuge ajutiselt ise “käsitsi” sisse lülitada.

Mõnedes ringkondades küsitakse, miks selliseid vanu krüptoprotokolle sellelgi moel veel toetada? Ka meile oleks palju lihtsam nende standardite toetamisest üldse loobuda, kuid reaalsuses sõltuvad tänagi mitmed meie kliendid seadmetest ja tarkvarast, mis valminud sajandivahetuse paiku või eelmisel aastakümnel ja nad vajavad üleminekuks aega. Samuti ei näita riskihinnangud nendes vanemates protokollides olevate nõrkuste reaalset ärakasutamist.

Globaalne progress on siiski meile ette andnud konkreetse tähtaja TLS 1.0 ja TLS 1.1 standarditest lõplikuks loobumiseks. Nimelt on suuremate veebilehitsejate arendajad teatanud, et brauseritest kaovad need versioonid lõplikult 2020. aasta märtsis. Võtame samuti selle tähtaja endale orientiiriks ja hiljemalt 2020. aasta märtsist ei saa TLS pärandversioone meie juures ka “käsitsi” sisse lülitada.

Aktuaalsete TLS versioonidena on meil täna toetatud TLS versioonid 1.2 ja osaliselt ka 1.3, mis on ametlikeks standarditeks saanud vastavalt 2008. ja 2018. aastal. Kuna viimase näol on tegemist verivärske standardiga, siis ei ole selle tugi veel kogu meie tarkvarasse jõudnud.

Mis toob mind ühe laiemalt teadvustamist vajava teema juurde. Nimelt selgus meil TLS 1.3 implementeerimise käigus huvitav asjaolu, mis võib lisaks meie klientidele mõjutada oluliselt kõiki Eesti internetikasutajaid:

TLS 1.3 standardi kasutuselevõtul lõpetab Eesti ID-kaardiga autentimine veebiserveri kataloogi tasandil töötamise!

Põhjuseks fakt, et suuremate veebilehitsejate tootjatest pole veel ükski juurutanud TLS 1.3 protokolli kätluse järgset autentimist (post-handshake authentication). Brauseritootjatel ei paista selle vastu olevat ka suuremat huvi – Chrome vastava bugiraporti leiab lehelt https://bugs.chromium.org/p/chromium/issues/detail?id=911653 ja Firefoxi oma https://bugzilla.mozilla.org/show_bug.cgi?id=1511989.

Sellest kitsaskohast saab ümber kahel moel:

• loobuda TLS 1.3 kasutamisest;
• viia ID-kaardiga autentimine kataloogi tasandilt üle veebiserveri virtuaalhosti tasandile.

Mõlemad meetodid on kirjeldatud Apache vastavas bugiraportis https://bz.apache.org/bugzilla/show_bug.cgi?id=62975.

Kuni brauseritootjad uut autentimismeetodit ei implementeeri, jääb eelpoolkirjeldatud ID-kaardi kasutusstenaarium sõltuma tänaseks kümme aastat vana TLS versiooni 1.2 edasisest püsimisest.

Omalt osalt otsustasime eeltoodu põhjal, et lubame TLS 1.3 kasutuse esialgu ainult oma uutes serverites. Nii ei tee me katki klientide olemasolevaid kasutuslugusid. Juhendame neid selle probleemiga tegelema hiljemalt siis, kui nad oma uuele serveriplatvormile üle viime.

Mis puudutab aga ID-kaarti, siis ilmselt tuleks otsustajatel Riigi Infosüsteemide Ametis (RIA) tõsiselt ja operatiivselt mõelda selle üle, kas ei oleks aeg leida veebiserveris kasutajate autentimiseks lahendusi, mis ei sõltuks ajale jalgu jäänud või tarkvaraarendajate põlualla sattunud meetoditest. Ja kui teispidi mõelda, siis oleks ju ka tore, kui meie rahvusliku PKI funktsionaalsus ei sõltuks Google Chrome arendajate suvast.

Meie veebimajutuse tarkvaraplatvorm uueneb

Täna (2019.03.01) alustasime veebimajutusteenuse klientide lisamist Zone uuele serveriplatvormile, mille aluseks on spetsiaalselt meie klientide vajadusi arvesse võttes loodud uus Linux operatsioonisüsteemi distributsioon.

Uue platvormi vundamendiks on Container Linuxi arendatav tehnoloogia, mis omakorda jagab oma “geneetilist” pagasit Gentoo Linuxi ja Google arendatava Chrome OS operatsioonisüsteemiga. Kuigi oma eluteed alustas see projekt meil sisemiselt koodnime “Ashrak” all, jääb see produktsioonis kandma nime ZoneOS.

Olemasolevaid veebisaite tänane sündmus ei mõjuta, sellest on kohe mõjutatud vaid uued lisatavad veebisaidid.

Oleme pingutanud selle nimel, et üleminek uuele platvormile toimuks võimalikult sujuvalt, mistõttu oleme üritanud vältida suurte muudatuste tegemist. Mõned väiksemad muutused sai siiski tehtud, mida meie platvormi kasutavatel arendajatel ja integraatoritel on hea teada:

  • uuenesid paljud teegid ja utiliidid, mille värskendamine kasutajaid oluliselt ei mõjuta;
  • kasutusele tuli uus Node.js versioon, milleks on 10.15.1
  • krüpteeritud HTTPS protokolli teenindamiseks kunagi kasutatud eraldi DocumentRoot kaust “domeen.tld/secure/htdocs” kadus ära – maailm on edasi liikunud ja krüpteeritud ühendused on de facto uus normaalsus – edaspidi teenindatakse ka HTTPS päringuid vaikimisi “domeen.tld/htdocs” kaustast
  • PHP.INI failid asuvad edaspidi “domeen.tld/phpini/” all asuvates alamkaustades “http”, “https” ja “global” – see viimane mõjutab mõlemat protokolli
  • domeen.tld/cgi-bin/” kataloog ja tugi CGI skriptide käivitamisele kaovad ära – klientide poolne nõudlus ja vajadus selle võimekuse järel puudub ning selle säilitamine (eriti ilma aktiivse kasutuseta) on seotud turvariskiga
  • PHP versioone alla 5.6 ei ole uuel platvormil võimalik ka erandina pakkuda, esiteks kujutavad need endast turvariski ja lisaks pärsivad teiste teekide ja rakenduste uuendamist
  • serveripoolne veebilehe külastusstatistika asub edaspidi “domeen.tld/stats/webalizer/“ all olevates kaustades, Webalizeri külastusstatistika täpse seadistamise võimalus kadus ära – seda ei kasutanud sisuliselt mitte keegi
  • Virtuaalserveri haldusliidesest kaob uut platvormi kasutavatel klientidel,  “Veebiserver -> Monitooring” alamleht ära – see naaseb mõne aja pärast palju kvaliteetsemate andmetega
  • Virtuaalserveri haldusliidesest kaob “Statistika ja andmemaht -> Andmesidemaht” leht ära, kuna meil pole juba ammu üheski Virtuaalserveri teenuspaketis andmemahule piiranguid.

Muidu on nagu ikka – uus on kiirem, turvalisem ja muidu parem. Esimeste vanemat platvormi kasutavate serverite üleviimisega uuele operatsioonisüsteemile tahame alustada juba aprillis, kuid kõikide klientide üleviimine saab kestma ilmselt aasta lõpuni.

Päris katsejänestena ei pea uuele platvormile lisatavad kliendid end tundma, kuna uuel operatsioonisüsteemil põhinevad juba nii meie uus e-posti platvorm kui ka viimase poole aasta jooksul lisatud andmebaasiserverid ja muud infrastruktuuriga seotud serverid. Sellegipoolest on tagasiside ja tähelepanekud väga oodatud.

Kuigi šampanja lahtikorkimiseks on veel veidi vara, tahan tänada meie IT ja tarkvaraarenduse valdkondade meeskondi, kelle jaoks on meie uue platvormi näol tegemist viimase 3-4 aasta töö kulminatsiooniga.

Oluline info PHP pärandvara kohta

Aasta 2019 tõi paljude jaoks endaga kaasa ebameeldiva üllatuse, 1. jaanuari seisuga muutusid pärandvaraks (“legacy”) kaks seni väga populaarset PHP versiooni 5.6 ja 7.0, mis enam arendajalt turvauuendusi ei saa.

Pärandvara kasutamine toob endaga kaasa riske, kuna see ei käi kaasas heade tavade ja praktikatega ning võib läbi paljastatud, kuid parandamata turvanõrkuste omandada ründajate kätes vaenuliku funktsiooni, pakkudes tagauksi seda kasutavatesse süsteemidesse.

Pärandvaraks muutunud tarkvaral on loomulikult muidki puuduseid kaasaegse tarkvaraga võrreldes, mida ilmestab juuresolev illustratsioon.

PHP versioone toetatakse arendaja poolt aktiivselt kaks aastat, misjärel pakutakse aasta jagu neile veel turvauuendusi.

Käesoleva aasta seisuga on arendajate poolt turvauuendustega toetatud kolm PHP versiooni:

  • 7.1 (kuni 1.12.2019)
  • 7.2 (kuni 30.11.2020)
  • 7.3 (kuni 6.12.2021).

Vanemate PHP versioonide kasutajad peaksid need vahetama mõne ülal nimetatud versiooni vastu.

Lugejale võib siinkohal tunduda, et ta ei kuule vajadusest kasutusel olevat PHP versiooni vahetada esimest korda, mis on ilmselt tõsi. Kuid sarnaselt paljudele teistele riskide maandamise vajadusest jutlustavatele epistlitele, mis räägivad näiteks vajadusest hoida piirkiirust, paigaldada suitsuandur või vahetada õigeaegselt välja talverehvid, kipuvad paljud seda sõnumit ignoreerima.

Seda ei maksa siiski teha, sest uuenenud pole mitte ainult PHP versioonid, vaid ka küberruum, kus neid rakendatakse. Hiiglaslike hüpetega arenevad nii tehnoloogilised platvormid kui ka ühiskond. Mis toob mind kahe olulise tõdemuseni:

  • esiteks, päris vanu PHP versioone ei ole Zonel peagi võimalik enam töökindlalt pakkuda, isegi kui kasutaja on valmis selleks võtma teatud turvariske nagu seni, põhjuseks on asjaolu, et teegid mida vanemad PHP versioonid vajavad kaovad järjest ajalukku;
  • teiseks, küberruumi reguleerivad üha rangemad ja spetsiifilisemad õigusaktid, mis otsesõnu nõuavad infosüsteemide omanikelt teadaolevate infoturberiskide maandamist – Euroopa Liidu tasandil on kehtestatud isikuandmete kaitse üldmäärus, kohalikul tasandil on vastu võetud küberturvalisuse seadus, peagi hakkab ilmselt kehtima e-Privaatsuse direktiiv, kuigi konkreetseid vahendeid nagu PHP nendes loomulikult ei mainita, rikub teadaolevate nõrkustega tarkvara kasutamine seaduste mõtet ja nende nõudmistele mittevastamine võib tõsisema intsidendi korral endaga kaasa tuua reaalsed, märkimisväärsed sanktsioonid.

Seega, hoiatan ette. Zone kaotab oma järgmise põlvkonna serveriplatvormist juba väga aegunud (ilmselt <= 5.5) PHP versioonide toe ära. Üleminek uuele platvormile hakkab meil juba aprillis, mil hakkame ise järgemööda võtma ühendust nende klientidega, keda see puudutab.

Lisaks võib juhtuda, et mõne tehnoloogiliselt toetatud, kuid tootja poolt juba hüljatud PHP versioonid (ilmselt <=7.0) peame määratlema pärandtarkvarana, mille teenindamisele tuleb kehtestada täiendav teenustasu, et senisest jõulisemalt suunata kliente kasutama turvalisemat, kiiremat ja efektiivsemat tarkvara; ning kompenseerida Zonele pärandtarkvara toetamisega seotud reaalsed kulud ja riskid.

Tööd saab olema paljudel. Täna kasutab veel sadu Zone kliente peagi 20 aastaseks saavat PHP 4. põhiversiooni. Turvaparandusi ei ole selle alamversioonidele välja lastud juba üle 10 aasta (sic!).

Hullem lugu on PHP 5. põhiversiooniga, mis lasti välja 2004. aastal. Selle populaarsed alamversioonid 5.2, 5.4 ja 5.6 muutusid pärandvaraks vastavalt 2011, 2015 ja 2018. Nende versioonide kasutajaid on kahjuks jätkuvalt tuhandeid.

Ülalnimetatud olukord ei ole kuidagi tekkinud Zone osavõtmatusest, oleme järjepidevalt teinud kõik uuemate PHP versioonide populariseerimiseks:

  • uued versioonid on muutunud klientidele kättesaadavaks kohe, kui nad on arendaja poolt välja lastud;
  • oleme tutvustanud oma blogis laiemale üldusele uute PHP versioonide peamiseid eeliseid;
  • avaldame serveriteenuste haldusliideses järjepidevalt meeldetuletusi klientidele, kes kasutavad PHP vanemaid versioone;
  • keelasime uutel klientidel vanemate PHP versioonide kasutuselevõtu;
  • keelasime PHP versiooni vahetajatel tagasipöördumise vanematele versioonidele;
  • oleme teostanud oma serverites löök-inventuure, mille käigus oleme PHP sätted kaasaegsemate vastu ära vahetanud nendel alam- ja põhidomeenidel, kus PHP-d parasjagu reaalselt ei kasutata;
  • jne.

Kõigel sellel on olnud mõju, kuid kahjuks mitte piisavalt suur ja see mis meid siia toonud, kahjuks edasi meid enam ei vii.

Ära seda soovitust jälgi: täna on rahvusvaheline paroolivahetamispäev

Tõepoolest, väidetavasti on 1. veebruar “change your password day” ning seega äärmiselt sobilik hetk rääkida … tõsiselt halbadest infoturbe-nõuannetest.

Me oleme paroolidega seotust kirjutanud korduvalt: nt Hasso pikem lugu Veel kord paroolidest, siis täpselt seal välja toodud halva parooli-nõuande kasutamise tulemusest Nõrgast paroolist häkitud WordPressini 42 katsega ja loomulikult rahvusvahelise mõõtmega “Paha Panda” varastab postkaste.

Häid nõuandeid jagab aga NIST, mille “Special Publication 800-63B” võtab arvesse seniste parooli-reeglite tekitatud ebaturvalised käitumismustrid. Võid selle spikriks kõrvale võtta ja proovida vastata küsimusele:

Millised järgnevatest EI OLE NIST’i nõuded turvalisele paroolile?

(õiged vastused postituse lõpus)

  1. peab olema vähemalt 10 märki pikk
  2. peab olema vähemalt 8 märki pikk
  3. peab olema vähemalt 6 märki pikk, võib koosneda ainult numbritest
  4. peab sisaldama suur- ja väiketähte, numbrit, märki
  5. peab vähemalt X kuu järel vahetama
  6. ei tohi olla sama, mis viimased X parooli
  7. parooli või kasutajanime sisestamise lahtris ei tohi toimida copy ja paste
  8. ei tohi sisaldada nime, järjestikuseid märke, levinud salasõnu

Kasutasin seda nimekirja just turva-teemalisel esinemisel ja tuleb tunnistada, et paljud kuulajad noogutasid täpselt valede kohtade peal. Põhjuseks see, et IT-osakonnad jõustavad endiselt iganenud reegleid ning neid tirazeeritakse endiselt nii paberil kui digitaalses meedias.

Milline on siis hea ja milline halb reegel?

Hea parooli-nõue on selline, mis ei koorma liigselt kasutajat ning ei sunni teda ebaturvalisele optimeerimisele – inimene pole rumal, küll aga evolutsiooniliselt harjunud leidma kõige tõhustamat teed seatud eesmärgi saavutamiseni. Samas peaks see reegel aitama infosüsteemide arendajatel ja haldajatel meid kaitsta.

Näiteks – selleks, et parooli ei saaks N korda proovides ära arvata, peaks rakendus suutma sellist rünnet tuvastada ja takistada (konto ajutiselt lukustama), ent samas vältida teenustõkestusrünnet läbi kontode lukku ajamise.

Levinud tavad nagu sage vahetamine ja keerukusnõuded annavad aga soovitule vastupidise tulemuse: kasutaja lisab sõnale mõne numbri ja märgi ning siis suurendab sammhaaval numbrit või kasutab selleks aasta-arvu.

Kaks reeglit, mille puhul tasub viidata sellel blogipostile:

  • märgi-põhised keerukusnõuded
  • parooli kohustuslik vahetamine iga X ajavahemiku järel (aga: NIST nõuab vahetamist juhul kui  on kahtlus, et see on lekkinud)

3+2 lihtsat reeglit, mida järgida

  • salasõna asemel räägime sala-fraasist – veidi pikem isekomponeeritud liitsõna või sõnamäng/kalamburism on väga hea (jalgpallisupikulp, lumehangumine, vt insipratsiooni twitter.com/keitivilms)
  • ära kasuta sala-fraasis enda või kasutuskoha nime, levinud (sala)sõnu (Passw0rd!, kalamaja) ja järjestikuseid märgijadasid (q1w2e3r4)
  • oluliste teenuste jaoks (töökoha kasutajakonto, e-post, sotsmeedia) kasuta unikaalset sala-fraasi

Sellega on 98% tööd tehtud, kaks veidi suuremat pühendumist nõudvat soovitust on aga veel:

  • lülita olulistes teenustes (e-post, sotsmeedia) sisse kaheastmeline autentimine (2fa ehk two-factor authentication – nt SMSiga saadetav turvakood)
  • kasuta parooliseifi (LastPass, 1Password, KeepAss) unikaalsete paroolide loomiseks ja haldamiseks, pea meeles ainult üks tugev ehk seifi sala-fraas

Viimase punkti juurde vihjeks, et KeePass on täiesti tasuta ja LastPassis saab erakonto teha tasuta (ja kui su tööandja peaks LastPassi ametlikult kasutusele võtma saad era- ja töökontole ligi ühe sisselogimisega – seejuures mõistagi nii, et tööandja EI SAA sinna ligi 🙂

Ja lõpuks…

See paroolivahetuspäev on Gizmodo klikimeelitustrikk aastast 2012, seeria viimane lugu kannab muideks pealkirja Don’t Change Your Password ning jõuab umbes samade soovitusteni ehk “ära vali lolli parooli”.

Kui su IT-osakond Gizmodot adekvaatseks allikaks ei pea, siis olgu öeldud, et maikuus on tulemas World Password Day ning TheRegister on selle kokku võtnud pealkirjaga It’s World (Terrible) Password (Advice) Day!


Õige vastus – NISTi nõuded EI OLE 1, 4, 5, 6, ja 7.

Nõrgast paroolist häkitud WordPressini 42 katsega

Sattusin puhastama ühte WordPressi, mille puhul oli ilmseks sissetungi-viisiks halduri-õigustes kasutaja parooli ära-arvamine.

Vaatamata sellele, et iga turva-nõuanne hakkab pihta tugeva parooliga ja enamus kasutajaid sedaküsimise peale ka esimese meetmena nimetavad… on nõrga parooli kasutamine endiselt reaalne probleem.

Esimene samm: kasutajanimede kogumine

Seekordne näide põhineb ühe reaalse ründe logifailidel, alustuseks otsitakse WordPressi kasutajanimesid lapates läbi autorite arhiivi:

163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=1 HTTP/1.1" 301
163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=2 HTTP/1.1" 301
163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=3 HTTP/1.1" 404

Kood 301 on edasisuunamine: kui proovida minna lehele https://blog.zone.ee/?author=16, siis on selleks https://blog.zone.ee/author/petskratt/ … ja minu kasutajanimi petskratt on selles kenasti näha.

Teine samm: parooli mõistatamine:

Kui kasutajanimi teada, võib hakata proovima sisselogimist:

163.172.xxx.xxx [10/Dec/2018:20:39:25 +0200] "POST /wp-login.php HTTP/1.1" 200 

Selliseid ridu on logis 41 ning kõigi nende puhul on WordPress väljastanud teate, et parool ja/või kasutajanimi ei klapi.

Ma olen selliseid katseid kogunud ja tüüpiliselt on proovitavad mustrid kasutaja petskratt ja veebilehe zone puhul sellised:

petskratt2017
petskratt2018
P@ssw0rd
petskratt1234
petskratt12345
petskratt@123456
12345678
petskratt@zone
zone2018

Siia sobib kenasti Hasso postitus Veel kord paroolidest ehk kuidas aegunud parooli-nõuded on õpetanud kasutajad justnimelt selliseid lihtsalt ära-arvatavaid paroole kasutama.

Ja niimoodi nad siis huupi lappavad, kuni mõne veebi puhul mõne kasutajaga näkkab. Sedapuhku on juba  42. rida on veidi erinev:

163.172.xxx.xxx [10/Dec/2018:20:39:54 +0200] "POST /wp-login.php HTTP/1.1" 302

302 on jällegi edasi-suunamine ning selle sihiks on /wp-admin … Rohkem IP-aadress 163.172.xxx.xxx logis ei esine, sest töö sai tehtud. 32 sekundiga.

Mõni päev hiljem:

103.76.xxx.xxx [12/Dec/2018:06:06:07 +0200] "POST /wp-login.php HTTP/1.1" 302

Kui 163.172.xxx.xxx oli pärit Prantsusmaa internetiteenusepakkuja võrgust, siis 103.76.xxx.xxx külastab meid Indiast, Tamil Nadu osariigist. Kontrollib logini toimimist ja rohkem teda näha pole.

Kolmas samm: parooli ärakasutamine

Ilmselt läheb toimiv kasutajanimi+parool müüki ning uus omanik asub selle abil saiti lammutama:

46.148.xxx.xxx [17/Dec/2018:22:29:54 +0200] "POST /wp-login.php HTTP/1.1" 302
46.148.xxx.xxx [17/Dec/2018:22:29:54 +0200] "GET /wp-admin/ HTTP/1.1" 200
46.148.xxx.xxx [17/Dec/2018:22:39:29 +0200] "POST /wp-admin/update.php?action=upload-theme
46.148.xxx.xxx [17/Dec/2018:22:39:32 +0200] "GET /wp-content/themes/[...]/db.php?u
46.148.xxx.xxx [17/Dec/2018:23:00:32 +0200] "POST /wp-content/themes/[...]/db.php?u

Ehk siis login, oma teema üleslaadimine, selles oleva db.php tagaukse toimivuse kontroll ja ärakasutamine. Kui huvi, siis see näeb välja selline:

IP 46.148.xxx.xxx viitab Kiievile, aga kuulub sealsele veebimajutusteenusele ja kuigi tegemist võib olla ka VPNi või veebi-proksi kasutajaga viitavad mõned logiread skriptitud tegevusele, näiteks selle üleslaadimis-käsu puhul on logis referrer-väljal http://$st2/wp-admin/theme-install.php?browse=featured.

Mida sellise jama vältimiseks teha?

  • ära kunagi kasuta lihtsat parooli – ei enda kontol ega kolleegile / kliendile konto tegemisel (isegi, kui on plaanis see hiljem ära muuta – tõenäoliselt ei muuda seda keegi)
  • vaata üle veebirakenduse admin’i / halduri õigustes kasutajate nimekiri ja kustuta lahkunud töötajad / endised arendajad jms kasutajad, keda enam vaja ei ole (või pane nende rollik subscriber / lugeja)

Lisalugu: aga kelle parool lekkis?

Kuna selles veebis oli mitu haldurit, siis pakkus mulle suurt huvi konkreetse kasutaja tuvastamine. See ei pruugi alati võimalik olla, aga tasub vaatada wp_user_meta tabelis olevaid session_token kirjeid. Sedapuhku oli kasutaja 2 kohta kirjas järgnev:

a:2:{s:64:"bff45f4a[...]";a:4:{s:10:"expiration";i:1547071064;s:2:"ip";s:11:"77.72.xxx.xxx";s:2:"ua";s:124:"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3198.0 Safari/537.36 OPR/49.0.2711.0";s:5:"login";i:1545861464;}s:64:"a3c7456[...]";a:4:{s:10:"expiration";i:1548253873;s:2:"ip";s:11:"91.90.xxx.xxx";s:2:"ua";s:124:"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3198.0 Safari/537.36 OPR/49.0.2711.0";s:5:"login";i:1547044273;}}

Ülalpool näha oleva 46.148.xxx.xxx loginit ei ole enam näha (sest ta ei ole välja loginud? liiga ammu?), küll aga on näha 2 teist IPd, esimese asukohaks annab MaxMind Stoke-on-Trent’i ja teise omaks Odessa. Huvilised võivad tuvastada ka sisselogimise aja… ning logist on kenasti näha nende askeldamised 🙂