Tag Archives for " epasts "

22. May, 2020

CERT ieteikumi aizsardzībai pret izejošo e-pastu viltošanu

Email List Value Asset

Lai pasargātu citus saņēmējus un sava uzņēmuma vai organizācijas reputāciju, būtiski ir nodrošināt iespēju citiem pārliecināties par saņemtā e-pasta autentiskumu, ja tas izsūtīts jūsu uzņēmuma vai organizācijas vārdā, kā arī liegt iespēju trešajām pusēm izsūtīt šādus e-pastus. Arī šeit izmantojamas DMARK, SPF un DKIM tehnoloģijas.

DMARC

Katrā domēnā jābūt izveidotam DMARC ierakstam, jo šī tehnoloģija veic būtiskus uzlabojumus e-pastu standartos, kurus savādāk nav iespējams panākt dēļ atpakaļsaderības.

DMARC ierakstam jābūt sintaktiski korektam. T.sk. jāņem vērā, ka pirmais tegs vienmēr norāda DMARC versiju (dmarc-version), bet izvēlētai politikai (dmarc-request) vienmēr jābūt otrajā vietā (RFC 7489, 6.4. punkts).

Ieviešana

Ieviešana jāsāk ar SPF vai DKIM tehnoloģijām, jo DMARC pieprasa, ka katrs leģitīmi izsūtītais epasts ir aizsargāts vismaz ar vienu no tām.

Ir ieteicams izmantot DKIM + DMARC vai SPF + DKIM + DMARC kombināciju, jo SPF + DMARC (bez DKIM) var sagādāt piegādes traucējumus vairākos scenārijos (visbiežākie – epastu pārsūtīšana un meilinglistes).

Lai gan DKIM + DMARC konfigurācija no drošības perspektīvas ir tikpat droša kā SPF + DKIM + DMARC (un dažreiz pat drošāka dēļ tā, ka SPF ierakstos nākas iekļaut mazāk uzticamus serverus), praksē bieži vien nav iespējams izvairīties no SPF. Tā kā SPF ir vecāka tehnoloģija, kas arī ir daudz vienkāršāk ieviešama salīdzinājumā ar DKIM (sūtītāja pusē pietiek ar DNS ieraksta izveidošanu), tad tā šobrīd ir arī daudz biežāk izplatīta nekā DKIM vai DMARC. Līdz ar to, aizsargājot savus izejošos e-pastus tikai ar DKIM un DMARC, pastāv risks, ka daļa saņēmēju nespēs tos korekti validēt un tādēļ faktiski viņiem sūtītie e-pasti vispār netiks pasargāti no viltošanas.

Ja ir tehniskās iespējas apstrādāt DMARC atskaites (aggregate and forensic reports), vēlams sākt DMARC ieviešanu ar politiku ‘p=none’, lai iespējamās neapzinātās kļūdas neietekmē e-pastu piegādi. Pieprasītas piegādes atskaites  tiek apkopotas ar mērķi identificēt trūkumus tekošajā SPF, DKIM vai DMARC konfigurācijā. Tās ieviešot, jāņem vērā:

  • Pēc noklusējuma “aggregate” (“rua”) atskaites tiek izsūtītas tikai par e-pastiem, kas vienlaicīgi neizturēja abas pārbaudes – SPF un DKIM.
  • Ja tiek ieviestas abas šīs tehnoloģijas, tad noderīgāk ir saņemt informāciju par e-pastiem, kas nav izgājuši jebkuru no šīm pārbaudēm, to var panākt ar ‘fo=1’ tegu.
  • E-pasta adreses jānorāda ar ‘mailto:’ prefiksu.
  • Pēc noklusējuma atskaites atļauts sūtīt tikai uz šī paša domēna adresēm, ja ir nepieciešams tās izsūtīt uz cita domēna e-pastu, tam domēnam ir jāapstiprina šī darbība, ieviešot “External Domain Verification” DNS ierakstus. Piemēram TXT ieraksts “viens.lv._report._dmarc.divi.lv” ar saturu “v=DMARC1;” norāda, ka ‘divi.lv’ ir ar mieru saņemt ‘viens.lv’ domēna DMARC atskaites

p=none

‘p=none’ DMARC ierakstos norāda, ka e-pastam jātiek piegādātam neatkarīgi no SPF un DKIM pārbaužu rezultātiem.

‘p=none’ konfigurācija bez ‘rua’ tega, visticamāk, ir kļūda, jo domēns, kuram izveidots šāds ieraksts, nav pasargāts no e-pastu viltošanas, kā arī e-pasta administratori nesaņem informāciju par tekošās konfigurācijas trūkumiem.

Turklāt, ja domēnam ir izveidots SPF ar striktu politiku (‘-ALL’), bet DMARC ierakstā ir norādīts ‘p=none’, e-pasti tiks apstrādāti dažādi, atkarībā no saņēmēja:

  • ja saņēmēja serveris spēj pārbaudīt SPF, bet ne DMARC vai arī izmanto SPF pārbaužu rezultātus e-pastu filtrēšanai arī pie DMARC politikas ‘p=none’: SPF tiks pārbaudīts un kļūdu gadījumā e-pasts netiks piegādāts (kas var notikt arī ar leģitīmiem e-pastiem dēļ pāradresācijas vai meilinglistēm)
  • ja saņēmēja serveris spēj pārbaudīt DMARC un pieņem lēmumus tikai balstoties uz to: e-pasts tiks piegādāts neatkarīgi no SPF validācijas rezultātiem (bet SPF kļūdu gadījumā par tām tiks ziņots, ja DMARC politikā ir ieslēgta atskaišu funkcionalitāte)

Šādi var veidoties grūti diagnosticējamas problēmas, kā arī tas var radīt viltus drošības sajūtu.

Jāņem vērā

Izmantojot SPF + DKIM + DMARC konfigurāciju, tik un tā jārēķinās ar to, ka daļa sūtītāju būs spējīgi validēt tikai SPF. Tas rada divas problēmas, kas jāņem vērā:

  1. Saņēmēji, kas neatbalsta DMARC, validēs SPF pēc tā oriģinālās specifikācijas, neizmantojot DMARC ieviesto papildus prasību par Envelope Sender’ un Originator (parasti ‘From’ header’is) alignment. Tas nozīmē, ka šādi saņēmēji de-facto nav pasargāti no e-pastu viltošanas (bet sūtītājs šajā gadījumā arī nevar neko iesākt lietas labā).
  2. Ja visi uzņēmuma e-pasti tiek korekti pasargāti ar DKIM, tad daļa no tiem varētu arī noteiktos apstākļos nākt no serveriem, kas nav iekļauti SPF ierakstā. Tas var notikt kļūdas pēc vai arī uzsākot e-pastu izsūtīšanu no jaunas vietas (kas ir pasargāta ar DKIM, bet serveri netika ievietoti SPF ierakstā). Šajā gadījumā saņēmēji, kas spēj validēt DMARC, turpinās saņemt visus e-pastus, bet tie saņēmēji, kas spēj validēt tikai pliku SPF, daļu e-pastu var nesaņemt. Šādi piegādes traucējumi var nebūt pamanīti uzreiz un tad, kad tas ir pamanīts, to cēloni var būt visai grūti izskaidrot.

(Vēlams) DKIM

DKIM noteikti jālieto kopā ar DMARC. Bez tā sūtītājam nav iespējams signalizēt saņēmējam, ka visiem tā e-pastiem jābūt korekti parakstītiem ar DKIM. Līdz ar to krāpnieki var vienkārši viltot e-pastus, nepievienojot DKIM pavisam, – saņēmējam šajā gadījumās nāksies pieņemt e-pastus, jo DKIM trūkums (bez DMARC) netiks uzskatīts par problēmu.

Būtiska DKIM priekšrocība, salīdzinājumā ar SPF: DKIM parakstīti e-pasti paliek valīdi arī tad, ja tie tiek pārsūtīti, pie nosacījuma, ka to saturs netiek mainīts. Tas ir svarīgi, lai e-pasti tiktu piegādāti arī tad, ja saņēmējiem ir izveidotas dažāda veida pāradresācijas, vai arī, ja epasti tiek sūtīti uz meilinglistēm (par tām vairāk sk. zemāk).

Gadījumā, ja e-pasti tiek sūtīti no vairākiem avotiem (caur e-pastu serveri, web-serveri(em), mārketinga servisiem, sadarbības partneriem, automatizētām sistēmām), tiem visiem jābūt pasargātiem ar DKIM. To var panākt, vai nu pārkonfigurējot visus izejošo e-pastu punktus tādā veidā, lai e-pasti tiktu nosūtīti caur vienotu releju (kas pievienot epastiem DKIM parakstus), vai arī pievienojot DKIM parakstus katrā no vietām, caur kurām epasti tiek izsūtīti. Otrajā gadījumā vēlams katrā no vietām izmantot atsevišķu DKIM atslēgu, ar atsevišķu DKIM selektoru, lai nepieciešamības gadījumā katru no tiem varēu atsaukt individuāli.

Tā kā DKIM neierobežo atslēgu skaitu, kas tiek lietotas vienā domēnā, tad tehniski ir iespējams lietot individuālu atslēgu katram servisam, vai katram lietotājam. Taču praksē liels atslēgu skaits būtiski sarežģī atslēgu pārvaldi, ja vien tā nav automatizēta, kas palielina risku izveidot kļūdainu konfigurāciju, iespaidojot epastu piegādi.

Oversigning

DKIM ļauj norādīt, kuri e-pasta header’i tiek iekļauti, veidojot parakstu. Turklāt individuālu header’i var norādīt vairākas reizes. Tad, ja header’is patiesībā e-pastā sastopams tikai vienu reizi, izskaitļojot DKIM parakstu, otro reizi tas tiks aizstāts ar tukšumu.

Šis ir būtiski, jo DKIM skaita header’us virzienā no apakšas uz augšu. Savukārt daudzos citos kontekstos e-pastu serveri un e-pastu klienti apskata header’us virzienā no augšas uz apakšu. Turklāt, lai gan dažiem no header’iem pēc standartiem ir jābūt sastopamiem tikai vienu reizi, praksē vairums e-pastu serveru pieņem arī nekorektus e-pastus, kuros šie header’i ir sastopami vairākas reizes, pie tam bieži vien uzskatot par korektu to, kas sastopams pirmais.

Šie fakti kopumā ļauj uzbrucējiem veikt ierobežotu e-pastu viltošanu sekojošā veidā. Par pamatu tiek paņemts kāds reāli izsūtīts e-pasts ar valīdu DKIM header’i. Taču tas tiek modificēts, pievienojot papildus header’us, kas vai nu oriģinālajā e-pastā vispār nebija sastopami, vai arī bija sastopami un bija iekļauti DKIM parakstā tik pat reizes, cik reizes tie bija sastopami (vai mazāk).

Lai izvairītos no šīs situācijas, ieteicams iekļaut DKIM parakstāmo header’u sarakstā visus svarīgos header’us, pie tam minot tos par vienu reizi vairāk, nekā tie patiesībā sastopami izsūtāmajā e-pastā. Šajā gadījumā, pievienojot e-pastam papildus header’i, DKIM paraksts nesakritīs un e-pasts tiks atpazīts kā viltojums.

Meilinglistes un garuma tegs (‘l=’)

DKIM piedāvā iespēju ierobežot teksta garumu, kas tiek izmantots, skaitļojot DKIM kriptogrāfisko parakstu. Visbiežāk tas ir noderīgi meilinglistēm, kas pārsūta e-pastus, pievienojot tiem papildus parakstu ar administratīvu informāciju. Tā kā ar DKIM bija parakstīts viss e-pasts, bet šajā gadījumā tika modificēts e-pasta teksts, šis paraksts pēc meilinglistes ieviestās modifikācijas kļūs nederīgs.

Norādot DKIM parakstā teksta garumu, kurš tika parakstīts, meilinglistes var pievienot tam galā papildus tekstu, nebojājot DKIM parakstu.

Diemžēl, šo funkciju ir iespējams izmantot arī ļaundabīgai e-pastu viltošanai. Pirmāmkārtām, ļaundari var vienkārši pievienot tekstu kāda e-pasta galā. Otrāmkārtām, savienojot šo ievainojamību ar iepriekš aprakstīto header’u viltošanu (ja netiek pielietos Oversigning), ir iespējams pilnībā pārrakstīt saņēmējam attēloto tekstu (pievienojot jaunu MIME daļu), vai pievienot e-pastam jaunu pielikumu.

Lai pasargātos no šādas e-pastu viltošanas, vēlams izvairīties no ‘l=’ tega izmantošanas, lai tiktu parakstīts viss e-pasta saturs, un, krāpniekiem pievienojot jebkuru tekstu e-pasta galā, lai tiktu invalidēts DKIM paraksts, kas liecinātu par e-pasta viltošanu. Taču, ja ir zināms, ka domēna lietotāji izmanto meilinglistes, kuras modificē sūtītos e-pastus, var gadīties, ka no ‘l=’ tega nav iespējams izvairīties. Šajos gadījumos risku var daļēji mazināt, izmantojot iepriekš minēto ‘oversigning’ stratēģiju.

(Vēlams) SPF

SPF ieviešana jāsāk ar visu izejošo e-pastu avotu apzināšanu.

Var sākt ar ~ALL, bet pilnam efektam jāpāriet uz -ALL.

SPF ierakstiem jābūt sintaktiski korektiem. Biežāk pieļaujamās kļūdas, no kurām jāuzmanās:

  • Vairāki SPF ieraksti vienam domēnam (drīkst būt tikai viens).
  • Pārbaudot SPF ierakstu, tiek pārsniegts DNS pieprasījumu limits (10 pieprasījumi). Jāņem vērā, ka DNS limits attiecas uz pilnu SPF pārbaudi, ieskaitot apakšierakstus, kas tiek iekļauti, izmantojot ‘include’ tegus. Turklāt ‘mx’ tega izmantošana izraisa vismaz divus DNS pieprasījumus (viens atgriež MX servera DNS ierakstu, otrs noskaidro šī DNS ierakstam atbilstošo IP adresi), bet gadījumā, ja ‘mx’ DNS pieprasījumā tiek atgriezti vairāki MX serveri, DNS pieprasījumu skaits var būt daudz lielāks.
  • SPF ieraksts ir pārāk garš. Tipiski, SPF ierakstam jābūt zem 255 rakstu zīmēm. Ja ir nepieciešams garāks SPF ieraksts, to var panākt ar vairākiem TXT tipa ierakstiem, taču jāuzmanās, jo SPF validācijas laikā tie tiks apvienoti vienā ierakstā un šādā formā tiem ir jāveido korekts SPF ieraksts (teiksim, tikai pirmajam TXT ierakstam jāsākas ar ‘v=spf1 ‘). Parasti drošāks risinājums ir izmantot apakšierakstus, lietojot ‘include’ mehānismu.
  • SPF ierakstā minēti neeksistējoši DNS ieraksti. Šīs var būt novecojušas un vairs neizmantotas sistēmas, vai arī tā var būt parasta neuzmanības kļūda. SPF validācijas laikā, sastopot šādu DNS ierakstu, kas nevar tikt pārveidots par IP adresi, rodas kļūda.
  • SPF ierakstā ir izmantots ‘mx’ tegs, kaut gan patiesībā ar epastu izsūtīšanu nodarbojas serveri, kas ir atšķirīgi no ienākošajiem. SPF ierakstā jānorāda tikai serverus, caur kuriem epasti tiek piegādāti uz internetu, bieži vien ienākošie serveri (uz kuriem norāda ‘mx’ DNS ieraksts) nesakrīt ar izejošajiem, tādēļ ‘mx’ tega izmantošana šajos gadījumos ir kļūdaina.
  • SPF ierakstā ir pieminētas daudzas sistēmas, kas patiesībā netiek izmantotas e-pastu izsūtīšanai. Bieži sastopami SPF ieraksti, kuros izmantoti ‘a’ un ‘mx’ mehānismi, minētas daudzas IP adreses un subneti, kaut gan patiesībā visi izejošie e-pasti no organizācijas tiek sūtīti caur vienu vai diviem e-pastu serveriem. SPF ierakstā nav jānorāda visas sistēmas, kas potenciāli var sūtīt e-pastus, bet gan tikai patiesie izejošie e-pasta serveri, caur kuriem organizācijas e-pasti tiek piegādāti uz internetu. E-pastu administratora uzdevums, veidojot SPF ierakstu, ir noskaidrot visus avotus, kas patiesībā nodarbojas ar e-pastu piegādi uz internetu, taču jāizvairās no lieku sistēmu pieminēšanas, jo tas palielina uzbrukuma virsmu.

Domēni, kuri netiek izmantoti e-pastu izsūtīšanai

Jāaizsargā arī organizācijas pārvaldībā esošie domēni, kas netiek izmantoti e-pastu sūtīšanai. Ja tas netiek darīts, e-pastu viltošana ir iespējama un jebkurš no šiem domēniem var tikt izmantots ticamu pikšķerēšanas uzbrukumu veikšanai.

Šajā gadījumā pietiek ar minimālu konfigurāciju, kas liedz sūtīt epastus no jebkuras IP adreses.

Ieteicamā konfigurācija ir sekojoša:

  • DMARC: ‘v=DMARC1; p=reject’
  • SPF: ‘v=spf1 -all’

Jāņem vērā, ka ar vienu DMARC ierakstu nepietiek, jo ir risks, ka daži no e-pastu saņēmējiem nespēj to korekti verificēt. Tā kā SPF atbalsts šobrīd ir sastopams biežāk, tad vēlams veidot abus ierakstus.

Ieviešanas soļi izejošo e-pastu aizsardzībai

  1. DMARC politika “v=DMARC1;  p=none; rua=mailto:[email protected]
    (neietekmē e-pastu piegādi, bet ļauj novērtēt aizsardzības mehānismu efektivitāti vai arī pamanīt kļūdas to konfigurācijā; ierakstu var papildināt ar ‘fo=1’, lai saņemtu arī informāciju par e-pastiem, kas izkrituši tikai vienu no SPF vai DKIM pārbaudēm, nevis tikai abas kopā).
  2. Saņemto DMARC piegādes atskaišu analīze
    (to IP adrešu uzskaite, no kurām patiesībā tiek izsūtīti e-pasti; automatizēto sistēmu inventarizācija).
  3. Testēšanas režīmi DKIM (‘t=y’) un SPF (‘~ALL’) mehānismiem
    (iespēja pamanīt un novērst kļūdas, pirms tās izraisa piegādes traucējumus).
  4. Pārliecināties, ka DMARC alignment prasības tiek izpildītas
    (SPF gadījumā Envelope Sender jāsakrīt ar From lauku, DMARC gadījumā ‘d=’ tegā norādītais domēns sakrīt ar From lauka domēnu).
  5. Saņemto DMARC atskaišu analīze (t.sk. ‘ruf=’, ja tas ir iespējams) & cita veida piegādes kļūdu monitorings
    (jārēķinās, ka daži saņēmēji var sākt filtrēt e-pastus jau šajā solī, pie tam neveicot DMARC atskaišu izsūtīšanu).
  6. Stingru režīmu ieviešana SPF (‘-ALL’) un DKIM (‘p=quarantine’ vai ‘p=reject’)
    (ja iepriekšējos soļos tas vēl nebija izdarīts, šeit noteikti ieteicams ieslēgt arī DMARC atskaišu funkcionalitāti, kā arī ieviest saņemtās informācijas apstrādi).

Vēl par e-pastu drošību:

E-pastu drošība – šifrēšana
E-pastu drošība – lietotāju autentifikācija
E-pastu drošība – aizsardzība pret ienākošo e-pastu viltošanu

Noderīgas saites:

“Dmarc – Defeating E-Mail Abuse”, CERT-EU
https://cert.europa.eu/static/WhitePapers/Updated-CERT-EU_Security_Whitepaper_DMARC_17-001_v1_2.pdf

“Using DMARC”, D. Crocker
https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03

“Interoperability Issues Between DMARC and Indirect Email Flows”
https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-18.xml

“Breakng DKIM – on Purpose and by Chance”, Steffen Ullrich
https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html

“DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust, cert.org
https://www.kb.cert.org/vuls/id/268267/

“Email authentication: SPF, DKIM and DMARC out in the wild”, JonLuca DeCaro
https://blog.jonlu.ca/posts/spf-dkim

“Guidelines on Electronic Mail Security”, NIST
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-45ver2.pdf

“Trustworthy Email”, NIST
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf

“Email Authentication Best Practices”, CISCO
https://www.cisco.com/c/dam/en/us/products/collateral/security/esa-spf-dkim-dmarc.pdf

“M3AAWG Best Practices for Managing SPF Records”, Messaging, Malware and Mobile Anti-Abuse Working Group https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf

“M3AAWG Trust in Email Begins with Authentication”, Message, Mobile and Malware Anti-Abuse Working Group https://www.m3aawg.org/sites/default/files/document/M3AAWG_Email_Authentication_Update-2015.pdf

“Internet.nl Toolbox – hw-to’s mail security standards”, internet.nl
https://github.com/internetstandards/toolbox-wiki

“How to Combat Fake Emails”, Australian Cyber Security Centre
https://www.cyber.gov.au/publications/how-to-combat-fake-emails

28. February, 2018

Newton epasta klients

Newton Mail 1068x564

Pirms pāris mēnešiem izlasīju Kristapa rakstu par šo epasta klientu  Nolēmu pamēģināt. Un uzreiz tā nopietni. Ikdienā izmantoju 9 dažādus epastus. Nolēmu uzticēt šim klientam visus uzreiz un paskatīties, kā tas tiks galā. Pirmie iespaid pavisam labi. Aplikācija strādā ātri. Uzkaras reti. Visi epasti katreiz pa rokai. Ar visiem pielāgotajiem uzstādījumiem. Ar atskaitēm par to, vai epasts ir piegādāts un izlasīts. Teikšu, ka tas ir ļoti noderīgi. Šis informāciajs atspoguļojums ir ļoti līdzīgs WhatsApp. Tādi paši pelēki un zili ķeksīši. Pilnvērtīgi lietot šo produktu mani visu laiku atturēja cena. It kā nav daudz – 50 eiro uz gadu. Par brīvu varam šo epasta klietnu lietot tikai 14 dienas. Pēc tam jaunu epastu sinhronizācija vairs nenotiek. Taču tad nāca piedāvājums uz pamatīgu atlaidi. Pēc nelielām diskusijām ar uzturētājiem atlaide kļuva vēl prāvāka. Beigu beigās galējo ciparu nav pat īsti vērts vairs pieminēt. Tik daudz par finansēm. Lasīt tālāk

14. April, 2017

”Inbox.lv” savā paspārnē pārņem ”TVNET” e-pasta platformu

Šā gada martā starp augsto tehnoloģiju uzņēmumu SIA INBOKSS un portālu TVNET tika noslēgta vienošanās, saskaņā ar kuru elektroniskais pasta serviss @tvnet.lv turpmāk izmantos Inbox.lv tehnisko platformu.

Šīs izmaiņas nozīmē, ka, sākot ar 14. aprīli, Tvnet.lv e-pasta lietotājs izmantos Inbox.lv izstrādāto un pārvaldīto e-pastu. Pēc šīm pārmaiņām Tvnet.lv e-pasta lietotājam tiks piedāvāta elektroniskā pastkastīte ar 20 reizes lielāku ietilpību nekā iepriekš, bezmaksas tehniskā atbalsta dienesta pakalpojumi, kā arī lejupielādei būs pieejama e-pasta mobilā lietotne.

Tvnet.lv e-pasta lietotājs turpmāk varēs autorizēties Inbox.lv lapā, ievadot savu lietotājvārdu ([email protected] un esošo paroli). Pastkastīšu saturs jau ir pārcelts un saglabāts nemainīgs, apstiprina Inbox.lv pārstāvji.

“E-pasts ir populārākais SIA “Inbokss” produkts, pie kura vairāk nekā 15 gadu laikā esam strādājuši un regulāri uzlabojuši, saglabājot valsts lietotākā elektroniskā pasta statusu. Priecāsimies šo pakalpojumu turpmāk nodrošināt arī Tvnet.lv e-pasta lietotājiem,” piebilst A. Griķis.

Inbox.lv e-pastu šobrīd izmanto 1 000 000 lietotāju, un nu tam pievienosies arī 60 000 Tvnet.lv e-pasta klientu. SIA INBOKSS ir pašmāju augsto tehnoloģiju uzņēmums un interneta vietnes Inbox.lv īpašniece.

Papildus e-pasta pakalpojumam vietnē pieejami arī tādi produkti kā failu glabāšana, iepazīšanās un dažādi citi izklaides pakalpojumi.

26. October, 2016

MyKronoz Smartwatch ZeClock Premium Silver

mykronoz smartwatch zeclock premium silver o mlx01045 1024x683


Viedpulksteņi mēdz būt dažādi. Sāksim ar apcerējumu, kas īsti ir viedpulkstenis. Tie iedalās divās kategorijās – pilnie viedpulksteņi, kuru darbina Android Wear, un nepilnie viedpulksteņi, kas darbojas ar savu speciālu aplikāciju telefonā.
Šoreiz būs stāsts par otrās klases pārstāvi –  MyKronoz Smartwatch ZeClock Premium Silver. Nosakuums jau pamatīgs. Arī izskats pieklājīgs. Gluži kā klasiskais pulkstenis. Bet te sākas aizķeršanās. Tam telefonā ir speciāla aplikācija, kas ļauj kontrolēt dažas funkcijas. Nu ko dod, ka zini, ka ir īsziņa, bet nevari to izlasīt? Ir epasts – bet kāds? To šī iekārta nemāk pateikt. Ar zvaniem gan viss ir skaisti – rāda zvanītāja vārdu, varam pacelt, atteikt, sarunāties. It kā jau sākumam pietiek. Tomēr ir pāris tracinoši sīkumi – paziņojumu skaits automātiski nedzēšas, ja esi tos apskatījis telefonā. Paziņojumu sadaļā redzam tikai skaitu. Sms mums ir tik, epasti tik.Nevarētu teikt, arī, ka vibrozvans ir pietiekami spēcīgs, lai to vienmēr sajustu. Vistrakāk tomēr gāja ar lādēšanu. Nezinu, vai man nepaveicās, bet uzlāde sākās pēc ilgstošas spraušanas iekšā un ārā no “dokstacijas”. Arī tad nebija garantija, ka uzlādēsies. Gadījās pa nakti atstāt lādējamies un no rīta viena strīpiņa baterejā. Vidēji vairāk par 14 stundām batereja nespēja izturēt mani. Ja par pozitīvo – tad materiāls siksniņai un korpusam ļoti patīkams, kaut arī siksniņa tāda pacieta. Un tā arī nesapratu, vai būtu iespēja nomainīt siksniņu, ja būtu tāda vajadzība. Rezultātā, nolēmu, ka šī iekārta ar mani vairs nesdarbosies. Es esmu parāk aizņemts cilvēks, lai čakarētos ar pulksteņa neveiksmīgu lādēšanu un citiem trūkumiem. Vēl viena tracinoša lieta bija tā, ka pulkstenis uzskatīja sevi par bluetooth austiņu un visa skaņa visu laiku tika raidīta uz viņu.  Katram izejošajam/ienākošajam zvanam sākumā bija jāpārslēdz skaņa atpakaļ uz klausuli. Tracinoši.

13. February, 2015

Atsākusies kriptēšans vīrusa izplatība

your personal files are encrypted

Atsākta CTB-Locker datorvīrusa izplatīšana no «julianus.su», brīdina IT drošības incidentu novēršanas institūcija «Cert.lv». Šoreiz vēstule noformēta kā parādu piedziņa. Epasts tiek izsūtīts kā «Julianus Inkasso notice» par it kā pirmstiesas brīdinājumu par parādu piedziņu un saiti uz «lietu».Datora inficēšanās ar ļaunatūru notiek, lietotājam apmeklējot leģitīmas interneta vietnes. Lai inficētos, interneta lietotājam nav jāveic nekādas papildu darbības. Dators tiek inficēts automātiski, ļaunatūrai atrodot izmantojamas Java, Adobe Flash spraudņu, kā arī citas interneta pārlūka ievainojamības.

Pēc datora inficēšanas datorvīruss šifrē lietotāja datus, par atšifrēšanas atslēgu pieprasot izpirkuma maksu.

CTB Locker datorvīrusa inficēšanas riskam pakļauti Microsoft Windows operētājsistēmas lietotāji.]]>


en_GBEnglish (UK)