» »

Backdoor-i v Cisco (in drugih) napravah

Backdoor-i v Cisco (in drugih) napravah

1
2
3 4

SeMiNeSanja ::

@jukoz - na živec mi gre, ko se v debato vmeša nekdo, ki od vsega firewalling-a pozna zgolj podatek o pps in ceni, ni pa nikoli niti pokukal ne v upravljanje npr. Cisco Firepower. Ker če bi, bi mu bilo jasno, da primerja hruške in banane.

Firewall je danes še vse kaj drugega kot zgolj filtriranje na osnovi porta, source-a in destionation-a. Točno to pa je edino, kar OpenSource zadeve počno. Vse ostalo je na Opensource routerjih dodano iz drugih projektov, da se skuša vsaj na daleč malo približat funkcionalnosti, katero imajo današnje naprende komercialne požarne pregrade. Ključni problem pa so kakovostne signature, na katerih stvari potem padejo.

Dpool ::

@SeMiNeSanja: Pridobljene signature na kakrsenkoli način, niso garancija varnosti. Kot sem že prej omenil, varnostno operativni centri (SOC) z namenom obstajajo in delujejo. Tam se izvaja aktivna triaža, forenzika in analiza incidentov v omrežju oz. na end-pointih.

Kar se tiče SW, bom zmeraj pregledal OpenSource zahteve, razen če stranka izključno ne zahteva uporabe specifičnega komercialnega izdelka, katerega potem seveda tudi ona plača / licencira. OpenSource je fantastična zadeva, ki ti omogoči osnoven framework nad katerim potem ti gradiš specifične komponente, ki so zate pomembne in ki si jih skozi leta izkušenj na svojem področju spoznal, da jih je koristno vključit, če že niso. Kadar pa SOC analitiki zaznajo kakšen incident, ki je morebiti prišel mimo firewall-a ali kakšnih drugih end-point zaščit, potem se tako ali tako analizira takšen malware in se njegova signatura vnese v lokalno bazo in seveda deli tudi online z ostalimi, da si posodobijo svoje baze signatur.

Druga plat:
Če koga zanima trenutno so top comercial izdelki za end-point security CarbonBlack in PaloAlto - temu seveda primerna cena. Zakaj se odločiti za to, namesto OpenSource? Pač produkt je razvit in ti ga samo prevzameš in deluje. Imaš urejen UI in vse je že lepo povezano. Mogoče je tudi konfigurirati določena pravila. Seveda to niso tipični firewall-i, ki bi gledali samo porte in IPje. Tukaj se izvaja tudi določene Machine Learning zadeve, in spremljanje sumljivih akcij kakor je klic "cmd.exe" ali kaj podobnega.

Ne morem pa dovolj poudariti kako pomemben je v danšanjem svetu SOC storitev, kar pa se bojim da v SLO nismo še dovolj napredni za njo - znotraj podjetij; torej da bi se podjetje odločilo za najem SOC storitev. Ampak žal tudi TOP-THE-BEST zaščite podležejo 0-day vulnerabilities ter nepripravljenosti delavcev znotraj podjetij na Social Engineering napade - tukaj samo lahko pomaga SOC, kjer analitiki zmeraj spremljajo dogajanja v omrežjih in na end-pointih in kadar se zazna incident (zagon nekega malware) se sprozi takoj proces Incident Response, ki potem prepreči nadaljno škodo podjetju.

Zgodovina sprememb…

  • spremenil: Dpool ()

aleksander10 ::

Najprej definiraj SoC (kaj je vse tam notri in kako vse to skupaj komunicira), potem pa lahko naprej debatiramo.

Da pa vehemntno vržeš dva produkta na "mizo" in rečeš da sta top, je pa malo smešno. Security niso prodkuti, ampak skuepk rešitev, ki med seboj komunicirajo in to kar je napisal SeMiNeSanja o open zadevaj je več ali manj pravilno in se 100% strinjam.
Aleksander

"A friend is someone who gives you total freedom to be yourself. (J.M.)"

SeMiNeSanja ::

To je nekako tako, kot v zdravstvu.
Imaš 'komercialo', ki prisega na dosežke šolske medicine in farmacije.
Potem pa imaš še 'OpenSource', ki prisega na zeli z vrta in travnikov, nihala, bioenergijo,.....

Kateri 'OpenSource' zdravilec je že kdaj priznal, da njegova zel ni nujno najboljše, kar ti bo pomagalo? Koliko najhujših bolnikov vsak dan oberejo za lepe denarce z obljubami, da je njihov zvarek vsemogoč?

Ne glede na to, je veliko zelišč zelo koristnih - če so uporabljena na pravi način.
Postanejo pa lahko nevarna, če precenjujemo njihovo moč in jih uporabljamo na napačen način..
Tudi 'komerciala' uporablja številne zeli, vendar ponavadi v nekoliko drugačni, učinkovitejši obliki, kot zdravlilci.

Povsem enako velja za OpenSource.

------

Drugače pa je tu še problematika 'gledišča'. Nekdo, ki se ukvarja z omrežji na nivoju enega ISP, pod pojmom 'varnost omrežja' razume popolnoma nekaj drugega, kakor nekdo, ko se s tem ukvarja na nivoju omrežij v podjetjih. Potem pa se še tu delijo zadeve na največja podjetja in SME področje.

Ko govorimo o zelo velikih podjetjih (od naših nobeno ne spada v to kategorijo!) imamo opravka z precej drugačnimi zahtevami, kakor če govorimo o SME segmentu, sploh v segmentu od 5-50 uporabniki.
Pri nas so praktično vsa omrežja tipa SME (razen ISP omrežij), vendar se v zgornjem koncu (200+ uporabnikov) že kar veselo posega po Enterprise rešitvah - čeprav bi v večini primerov SME rešitev veliko bolj koristila. Verjame se marketingu in sledi logiki "dražje = boljše". Lastnih testiranj, kaj katera rešitev dejansko nudi, pa praktično nihče ne izvaja. Zato potem tudi nihče ne ve, kaj trg dejansko ponuja, kje so razlike med rešitvami, kje je razlika do OpenSource.

Sploh pa je tako, da moram običajno OpenSource freak-e najprej naučiti kaj je egress filtriranje in kako se ga implementira (kaj sme zapuščati omrežje). Večina njih namreč še vedno pod 'varnostjo' razume, da se filtrira zgolj dohodni promet - tistega, ko napišeš par port forward pravil. Egress filtriranje je pač malenkost bolj zahtevno, če ga hočeš spodobno izvesti.

SoC ali Security Operations Center imamo kje v Sloveniji? Nimajo ga ne ISP-ji, ne podjetja - ker zadeva spada v Enterprise okolja. Glede na to, da je 95% podjetij pod 100 uporabniki, pa mislim, da nima smisla sploh razpredat o enterprise zadevah.

V SME okoljih ni SoC tisto, kar v svetu vse več veljave pridobiva, temveč MSSP - Managed Security Services Provider-ji. Ti so tisti, ki so specializirani, da manjšim, pa do srednje velikim podjetjem "pošlihtajo" in upravljajo varnost. Vendar tudi od teh imajo samo največji nekakšen 24/7 delujoč SoC, ki bi dobesedno bdel nad omrežji njihovih strank.

Skratka.... o čem se sploh pogovarjamo? Enterprise fantaziji ali vsakdanji realnosti 95% tu prisotnih? Lahko je nekaj nakladat, če si malo nekje nekaj prebral - malo drugače pa je dejansko spraviti varnost SME omrežij na optimalen nivo z omejenimi sredstvi in resursi.
Če se s tem ukvarjaš že 20 let, ti je seveda jasno, da obstajajo različna podjetja, različni scenariji, različne potrebe.

Me pa prav zanima, koliko časa se ti brihtneži, ki se oglašajo, s tem področjem specializirano ukvarjajo - ker njim to očitno ni jasno in bi OpenSource rinili čisto povsod, ne glede na ceno. Malo kdo namreč upa sploh točno navesti, kakšna je bila celokupna cena, ki jo je morala stranka letno plačati za eno zares celovito postavitev in vzdrževanje Opensource rešitve, ki bi bila vsaj približno podobne funkcionalnosti kot neka napredna komercialna. Če je taka postavitev dejansko celovita in maksimalno izkoriščena, pa da se zadevo še kakšne 4x/leto posodablja, resno dvomim, da bo vse skupaj še lahko izpod cene komercialne rešitve.
Ceneje je predvsem tam, kjer se postavlja 'oskubljeno' funkcionalnost, minimalno granularna pravila, posodablja pa mogoče 1x/leto (ali še to ne) in tam, kjer se ne ukvarja s specifiko posamezne stranke - vsem naložiš enako kofiguracijo in voila. Copy & Paste. Saj stranka ne ve......

Ampak ni lepšega, kot nategniti stranko, da bo dobila superduper zadevo kar zastonj. Zakaj bi pri komercialni rešitvi pokasiral samo provizijo in nekaj malega za konfiguracijo, če lahko postaviš OpenSource in računaš ure in ure za nameščanje, optimizacijo, troubleshooting in potem spet pri vsaki posodobitvi isto zgodbo?

Zaslužiš na koncu 2x toliko, kot če bi prodal in skonfiguriral komercialno rešitev - kakovost pa dosega mogoče 50% komercialne. Včasih smo temu rekli "nateg stranke".
Ampak ja... deklarirano pa je kao da je 'zastonj', 'velikanski prihranek', samo še svetniški sij ti manjka.

jukoz ::

Ponovno, rant čez druge ponudnike je popolnoma nepotreben. In mi tudi ni jasno, kaj sanjate o nekih signaturah za prepoznavanje prometa če gre večina čez HTTPS.
SeMiNeSanja, ti nekaj bentiš čez odprtokodne rešitve in kako niso primerne za enterprise rešitve, obenem pa govoriš da je 95% podjetij teh rešitev ne rabi.

Po mojih izkušnjah, čez odprtokodne rešitve na veliko bentijo tisti, ki jih ne obvladajo in nimajo časa/želje/sposobnosti da bi jih.
Povsem normalno je, da nimaš časa/želje/sposobnosti ukvarjati se s tem. Tako kot jaz ne šraufam mojega avta in ga peljem k serviserju. Ampak ti, SeMiNeSanja, se pa obnašaš kot kakšen VW fan in vpiješ, kako so tudi drugi goljufali na izpustih in kako je električni pogon zanič in dizel najboljša stvar.
Tako kot ti obvladaš WatchGuard opremo (in verjetno še kaj), kdo drug obvlada druge zadeve. Tudi pf.

Prosim razloži mi, kako boš stranki pojasnil, da je varnostni produkt, ki ga zagovarjaš in so ga kupili, dober, če ti v javnost pridejo (oz jih proizvajalec da sam) informacije in exploiti za točno te naprave.
Kako se lahko nekdo, ki prodaja npr. Juniper, zagovarja? Juniper je imel hardcodan root account. Vse kar je stalo na njihovih FWjih je bilo dostopno vsem, ki so te informacije imeli. Kot stranka take opreme ne bi kupil več, tako kot ne bi kupil VW dizla.
Vsi bentimo čez IoT in zanič varnostjo. Kaj je pa nepopatchan FW z znamimi backdoori?

Pa da se vrnemo na temo in na moje prejšnje vprašanje:
Switche, ki so na seznamih Vault7 srečujemo vsepovsod. Ti switchi usmerjajo promet tako iz omrežja za goste kot drugih omrežij. In to opremo smo srečali že vsepovsod, verjetno tudi pri drugih uporabnikih slo-techa. Ima torej še kdo kakšne izkušnje? Ste jih posodobili? Zamenjali?

Ko smo že pri tem, kako velika pa je vaša zvestoba znamki. Pri PCjih je kar pogosto da so določena podjetja HP, Dell, IBM/Lenovo, ... shopi. Kaj pa pri mrežni opremi?

SeMiNeSanja, aleksander10? Dpool?

SeMiNeSanja ::

@Jukoz - RESNE firme v poslovnem delu omrežja (trusted network) dekriptirajo https in ga pregledujejo popolnoma enako kot http. Tiste zgodbe o MITM pa trosijo tisti, ki to bodisi niso sposobni s svojo opremo izvajati (ker tega ne podpira ali ker ji padejo performanse na nivo neuporabnosti), ali pa še niso pristali v letu 2018.
Čim pa promet enkrat dekriptiraš, pa so signature še kako pomembne.

Po domače: če že imaš požarno pregrado - zakaj jo imaš? Da ti greje zrak v serverski omari? Da kuri elektriko? Da lahko rečeš "ja imamo požarno pregrado..."?

Ali jo imaš mogoče zato, da si boš z njeno pomočjo skušal omrežje maksimalno zaščititi pred morebitnimi nevšečnostmi, ki tam zunaj prežijo nate in pred nevšečnostmi, ki jih tvoji uporabniki hote ali nehote skušajo privleči nanj?

Če imaš požarno pregrado, ki ne dela https dekripcije, si praktično vrgel denar proč, saj gre danes že tolikšen del prometa preko https, da bi ti v tem primeru (ne-preglegovanje https prometa) skoraj povsem enakovredno funkcijo opravil navaden router z nekaj port forward pravili!

Govorjenje zoper https dekripcijo kaže predvsem na globoko nerazumevanje tega, za kaj se danes pri varovanju omrežja sploh gre. Zanimivo, da je vsakomur jasno, da mora varnostnik pogledat v torbe, če hoče zagotavljati varnost. Ko si pa na omrežju, naj pa varnostnik (požarna pregrada) zagotavlja varnost z zavezanimi očmi (prez pregledovanja https prometa) ?!? Kaj je treba naresti, da se bo že enkrat razumelo, da to ne gre?

------

Zvestoba znamki...?
Vsekakor je bistveno bolj zasidrana pri mrežni opremi, kot pa na PC železnini.

Če zamenjaš proizvajalca na mrežni opremi se spremeni veliko več, kot če menjaš od HP na Dell PC-je. Če smo pri požarnih pregradah, se že sam konceptualni pristop razlikuje od proizvajalca do proizvajalca. Lahko se srečaš s popolnoma drugačno logiko.
Popolnoma drugačno je upravljanje. To pomeni, da je treba ljudi naučiti delati z novo rešitvijo. Lahko traja nekaj časa, da se na novi opremi znajdejo vsaj približno tako kot na stari. Da o možnih napakah, ki jih to lahko ima za posledico sploh ne govorimo.
Potem imaš še razliko v funkcionalnosti. Če aktualna rešitev podpira funkcionalnosti a,b in c, predlagana nova rešitev pa samo a in b - ob tem, da smo funkcionalnost c na veliko izkoriščali.....verjetno ne bo nikogar premamilo v menjavo.
Včasih pa se gre tudi zgolj za 'dvorne dobavitelje'. Kar tisti reče, da je 'dobro', to se bo potem tudi kupilo in uporabljalo. Ostalo potem nima veze. Se bodo že znašli.

jype ::

SeMiNeSanja je izjavil:

RESNE firme v poslovnem delu omrežja (trusted network) dekriptirajo https in ga pregledujejo popolnoma enako kot http
Vidim, da o računalniški varnosti ne veš ničesar.

misek ::

SeMiNeSanja je izjavil:

RESNE firme v poslovnem delu omrežja (trusted network) dekriptirajo https in ga pregledujejo popolnoma enako kot http.
Zanimivo branje tudi za nepoznavalce. Me je pa presenetil ta stavek: lahko kaj več o tem kako to deluje? V čem je potem sploh poanta https?

jukoz ::

To kar bi delal SeMiNeSanja, deluje pri kakšnih farmacevtih in podobno.
Na svojem kompu imaš naložen root cert od požarne pregrade. Požarna pregrada prestreza HTTPS promet, ga dešifrira, preveri in pošlje naprej. Man In The Middle torej (MITM).

Ti greš na facebook/gmail/tvojobanko/kamorkoližepačsajjevseHTTPS, njihov strežnik ponudi ponudi njihov cert, FW ga zamenja in se ti predstavi kot facebook. Ti mu pošlješ podatke, FW jih pa nato zapakira in pravilno pošlje facebooku.

SeMiNeSanja ti torej lahko gleda kaj delaš na facebooku, banki, gmailu, ...

jukoz ::

Če root certa FWja nimaš, ti bo vsak brskalnik javil da je cert za facebook napačen in ti ne bo pustil prijave. Naključni obiskovalec omrežja (recimo tvoj tečefon) bo torej ugotovil da je nekaj narobe, s tem bodo to izvedeli tudi vsi ostali uporabniki in imaš v podjetju cel halo.

To pa seveda ne gre v nobenem normalnem podjetju, ker ne moreš ti kar veselo prisluškovat uporabnikom na mreži.

V podjetjih/organizacijah, kjer je varnost zelo pomembna, se lahko grejo MITM. Ampak se morajo uporabniki strinjat s tem. V praksi se seveda ne, zato jim moraš kot mrežni admin blokirati 90% interneta, saj bi jim ga moral drugače prestrezati. Za to se v takih organizacijah strogo loči, kaj se na kakšnem omrežju/računalniku lahko dela in kaj ne. V praksi to pomeni, da resno delo opravijo na enih PCjih/omrežju, vse ostalo pa se vključi na omrežje za goste oz manj nadzorovana omrežja.

V večini podjetij je torej nemogoče legalno preverjati HTTPS promet in so tudi antivirus in signature na požarni pregradi povsem nepomembne. Za varnost je torej potrebno poskrbeti drugje, predvsem na klientih.

Zgodovina sprememb…

  • spremenilo: jukoz ()

misek ::

Hvala za razlago.

jukoz ::

SeMiNeSanja je izjavil:


Govorjenje zoper https dekripcijo kaže predvsem na globoko nerazumevanje tega, za kaj se danes pri varovanju omrežja sploh gre. Zanimivo, da je vsakomur jasno, da mora varnostnik pogledat v torbe, če hoče zagotavljati varnost. Ko si pa na omrežju, naj pa varnostnik (požarna pregrada) zagotavlja varnost z zavezanimi očmi (prez pregledovanja https prometa) ?!? Kaj je treba naresti, da se bo že enkrat razumelo, da to ne gre?

To lahko delajo varnostniki v Kazakstanu:
https://www.theregister.co.uk/2015/12/0...

Legalno tega ne moreš delat, če nimaš privolitve uporabnikov. Lahko delaš delaš white-liste, ampak če white-listaš google/facebook/dropbox/karkoližepač, nisi naredil nič. Škodljivo programsko opremo boš dobil od tam in jo torej lahko preverjaš samo na klientih.

Pa sploh ne vem kaj rineš s to dekripcijo HTTPS prometeta sem not. Ravno zaradi tega nočem imeti nekih filozofskih debat, temveč o tem, ali se oprema nadgrajuje in menja.

jukoz ::

misek je izjavil:

Hvala za razlago.


Glej, fora dekripcije HTTPSja je v tem, da je to fajn v zelo zelo nadzorovanem omrežju. Nadzorniku jederske elektrarne lahko mirno gledaš kaj počne. Ampak on itak ne sme početi nič pametnega po internetih. Če mu dovoliš nekontroliran dostop do nekaj strani, ti bo pa tam pobral viruse in si spet na istem. In mu že v osnovi totalno omejiš dostop to česarkoli.

Lahko torej kupiš zelo "pametno" požarno pregrado ki pregleduje promet. Na njej določiš 90% vsega prometa kot nepregledanega (google, facebook, twiter, dropbox, outlook.com) ali pa dostope blokiraš. Na klientih pa v vsakem primeru naložiš antivirusni program, na mailih držiš antivirusni program, segmentiraš omrežje in oddeliš kritične od nekritičnih itd. Ampak to moraš narediti tako ali tako.

"Pametna" požarna pregrada pride prav v tem, da ti prepreči da gre uporabnik na kakšno sumljivo stran. Ampak že tu ti večino opozoril da brskalnik.

SeMiNeSanja ::

Kot sem rekel: proti https dekripciji lajajo predvsem tisti, ki jo niso sposobni izvajati na primeren način.

Uporabniki na omrežju pa nimajo kaj biti 'presenečeni'. Kot prvo, mobiteli nimajo kaj iskati na 'trusted' delu omrežja (tistemu poslovnemu delu z višjo stopnjo varovanja). Kdor že tega v osnovi ni razumel, ta sploh nima kaj pametovati o varnosti. BYOD krama sodi na svoje podomrežje oz. VLAN, podobno kot Guest omrežje (alternativno BYOD priklapljaš na Guest omrežje).
To omrežje pač ne boš pregledoval tako natančno, razen na tistih portih, katerim dovoljuješ izmenjavo prometa z Trusted omrežjem.

Ko pa je govora o Trusted omrežju, pa je podjetje tisto, ki diktira, kaj bodo pravila igre, ne pa zaposleni. Resno podjetje pa zasebni Facebook? Se hecaš? Mogoče potem še Torrente pa kakšen Tor, da si lahko zaposleni še kakšne prepovedane substance naročajo? Še kakšen VPN do doma? Zakaj pa ne potem kar takoj dati zaposlenim DomainAdmin gesla? Ga napišeš zunaj na oglasno desko, da se slučajno ne bo kdo počutil omejenega v svoji 'svobodi'.

Torej.... smo nazaj pri vprašanju: ZAKAJ IMAŠ POŽARNO PREGRADO ?

Če jo imaš zgolj zaradi lepšega, potem je čisto vseeno, če prišparaš tiste par tisočakov in tja postaviš navaden router.
Če jo pa imaš zaradi ZAŠČITE omrežja, potem pa je tvoja naloga da uporabnikom razložiš:
a) kakšne grožnje prežijo na omrežje podjetja
b) kaj lahko uporabnik naredi, da se jim poskusi izogniti
c) kaj lahko ti narediš, da pomagaš uporabniku pri tem
d) kakšen vpliv to ima na njegovo zasebnost in 'svobodo' na omrežju podjetja

Vse ostalo so pa zgolj lame izgovori tistih, ki se jim ne ljubi stvari spraviti v red.
Bistveno lažje je tam, kjer jim to že standardi predpisujejo. Tam pač ni takih izgovorov o MITM in podobnem.

Samo je res zanimivo: ko so bili na pohodu izsiljevalski virusi, je bilo vsakomur jasno, da je https boleča točka, preko katere ti lahko marsikaj spravijo na računalnik.
Čim se je malo polegel prah okoli teh virusov, pa https kar na enkrat ni več problem. Do naslednje štale?

Zasebnost.... Na neštetih koncih se v podjetju logira takšen ali drugačen promet. Požarne pregrade ga tudi logirajo, vendar je tu treba reči, da MITM skeptiki ljudi prepričujejo, da admin potem vidi kar vse, kar si počel na Facebook&Co, kar pa je skrajno grda laž. Največ kar lahko vidi, so URL-ji, nikakor pa ne dejanske vsebine.
In resno: koliko adminov je tako premaknjenih, da bodo šli vohuniti za uporabniki, katere URL-je so na Facebook klikali, sploh če se jim večina ne bo odprla, ker nimajo ustreznih session cookie-jev ali uporabnikovih gesel?
Admin, ki bi imel takšne kriminalne namene, ti bo kar lepo namestil vohunski programček na PC in te direktno stalkal. Čemu bi se še zajebaval tu z neko požarno pregrado?

Zanimivo, da nihče ne dela panike glede tega, da lahko admin bere maile zaposlenih, pa se je to že nevem kolikokrat dogajalo.

SeMiNeSanja ::

Pa še to:

V praksi je Adminom že to težko, da bi vsako jutro ob kavi pregledali rekapitulirano varnostno poročilo požarne pregrade. Marsikateri admin ne pogleda niti tedenskih ali mesečnih poročil. Reagirajo zgolj na 'Alarme', ki so nastavljeni za določene dogodke.

Deloma jih lahko razumeš, ker je zadeva:
a) dolgočasna
b) so preobremenjeni s še 1000 drugimi rečmi

Tu pa se skuša ustvarjati vtis, da admini nimajo drugega početi, kot vohljati za uporabniki.
Zagotovo se najdejo tudi gnila jajca od adminov, ki točno to počno. Ampak ti imajo boljša orodja, kot požarne pregrade za ta namen.

jukoz ::

SeMiNeSanja je izjavil:

Pa še to:

V praksi je Adminom že to težko, da bi vsako jutro ob kavi pregledali rekapitulirano varnostno poročilo požarne pregrade. Marsikateri admin ne pogleda niti tedenskih ali mesečnih poročil. Reagirajo zgolj na 'Alarme', ki so nastavljeni za določene dogodke.

Deloma jih lahko razumeš, ker je zadeva:
a) dolgočasna
b) so preobremenjeni s še 1000 drugimi rečmi

Tu pa se skuša ustvarjati vtis, da admini nimajo drugega početi, kot vohljati za uporabniki.
Zagotovo se najdejo tudi gnila jajca od adminov, ki točno to počno. Ampak ti imajo boljša orodja, kot požarne pregrade za ta namen.


Na tole ti hitro odgovorim, ostalo kasneje:

V veliki večini niso problem, admini, ampak razni direktorji in lastniki podjetja, ki radi vohljajo za zaposlenimi. Če je podjetje veliko, ni panike. Pri majhnem, torej do 50 ljudi, smo pa že prevečkrat srečali raznorazne ki bi malo gledali za zaposlenimi. Ja, seveda, vi kar, samo obvestite zaposlene. Jih niste... Šment, ker ko vam bodo odnašali podatke ven, jim na sodišču ne boste dokazali nič, vas pa dobo tožili zaradi vdora v zasebnost. Oni plus vsi ostali zaposleni.

SeMiNeSanja ::

Ne vem, kako imajo to pošlihtano drugi proizvajalci - na WGRD-u se lahko vklopi psevdonimizacija logiranih podatkov. Potem pa naj direktor gleda kolikor hoče, če ima 'ključ' do deanonimizacije v rokah sindikalni zastopnik.

Drugo so 'realtime' podatki, kjer pa res moraš biti obseden, da sediš zraven in buliš, kaj se dogaja. Realtime je namenjen odpravljanju težav diagnostiki in precej neprimeren za 'stalking'.

Kot že rečeno - za pravi stalking obstajajo veliko boljše rešitve, ki jih direktno na PC namestiš, ki snemajo ekran, tipke in ves promet - s tem tudi gesla, ki jih uporabnik vtipkava. Teh zadev se je za bati, ker jim je vdiranje v zasebnost dejansko EDINI namen.

c3p0 ::

SeMiNeSanja je izjavil:


Zasebnost.... Na neštetih koncih se v podjetju logira takšen ali drugačen promet. Požarne pregrade ga tudi logirajo, vendar je tu treba reči, da MITM skeptiki ljudi prepričujejo, da admin potem vidi kar vse, kar si počel na Facebook&Co, kar pa je skrajno grda laž. Največ kar lahko vidi, so URL-ji, nikakor pa ne dejanske vsebine.


Vse lepo in prav, dokler ne odkrijejo nekih stranskih vrat ali ranljivosti v tem tvojem appliancu. Takrat si hekerju dal na voljo vse podatke, saj ves promet veselo dešifriraš in serviraš svoje self-signed certe, katerim uporabnik slepo zaupa. Eno je radoveden admin ali direktor, bat pa se je potrebno tega drugega. Kaj pa potem?

SeMiNeSanja ::

c3p0 je izjavil:

Vse lepo in prav, dokler ne odkrijejo nekih stranskih vrat ali ranljivosti v tem tvojem appliancu. Takrat si hekerju dal na voljo vse podatke, saj ves promet veselo dešifriraš in serviraš svoje self-signed certe, katerim uporabnik slepo zaupa. Eno je radoveden admin ali direktor, bat pa se je potrebno tega drugega. Kaj pa potem?

Pojdimo na realna tla - kje je večja verjetnost:

a) da hacker odkrije še neznan backdoor in ga uspešno zlorabi
ali
b) da hacker tvojega uporabnika našunta, da bo kliknil na nek zlonameren link, preko katerega bo prevzel nadzor nad tvojim omrežjem

Zadeve iz scenarija a) so preklemansko redke. Tudi če je tak backdoor namerno vgrajen s strani neke tričrkovne agencije, se ga ne bo uporabljalo množično, saj bi to drastično dvignilo verjetnost razkritja.
Ko pride do razkritja, je kar precej vika in krika, popravki so dokaj hitro na voljo. Če si vsaj malo na tekočem, kaj se dogaja okoli proizvodov, ki jih uporabljaš (=vestno opravljaš svoje delo), boš naložil popravke in gremo dalje.

So pa takšne ranljivosti dokaj pogoste na raznih routerčkih, ki se potem veselo pridružujejo botnetom. Glavni problem je tu ne-posodabljanje opreme, saj je marsikatera raljivost že dolgo znana in odpravljena.
Zanimivo pri tem je predvsem to, da bi ti routerčki lahko ravno tako zaigrali klasični MITM in naplahtali marsikaterega uporabnika. Certifikati pa....lih par dni je tega, ko je nek malware nameščal neke DLink-ove certifikate....


Scenarij pod varianto b) pa je popolnoma vskdanja zadeva. Nekaj tega se prepreči v brskalniku, nekaj prestreže AV,......nekaj pa pride skozi in ti naredi tako ali drugačno štalo. Če ne pride na http pa pride na smtp oz. povlečeš preko imap ali pop3. Kako učinkovito zadeve 'delujejo', pa smo lahko videli v primeru izsiljevalskih virusov.

Torej, kaj je zdaj bolj pomembno - da nas je strah zadev, ki se dejansko vsak dan dogajajo, ali neke zadeve, ki bi se hipotetično lahko zgodila, če se vse zaroti proti nam (ob tem, da sploh ni dokaza, da se je to že kdaj sploh zgodilo! Da je bila odkrita ranljivost, namreč še zdaleč ne pomeni, da je bila tudi dejansko uspešno zlorabljena s strani malopridnežev!)?

Skratka, malo zdrave kmečke pameti vklopiti, pri teh zadevah ne škoduje.

jukoz ::

Pod verjetnost a) pašejo vse tiste zadeve iz prvega posta. Vsi ti backdoori so sedaj javni.
Če admin nima časa/volje/dostopa do popravkov, so vsi podatki ki jih zbira na voljo napadalcu.

In v današnjem svetu širjenja informacij nekdo napiše PoC, nekdo ga spakira v malo lepšo obliko, na koncu pa 11 letnice in letniki vdirajo naokoli:
https://mashable.com/2017/05/17/teddy-b...

SeMiNeSanja ::

jukoz je izjavil:

Pod verjetnost a) pašejo vse tiste zadeve iz prvega posta. Vsi ti backdoori so sedaj javni.
Če admin nima časa/volje/dostopa do popravkov, so vsi podatki ki jih zbira na voljo napadalcu.


Sorry, vendar to danes spada pod kategorijo MALOMARNOST.
Podjetje (in Admin) je že po zakonu dolžno varovati osebne podatke. Zaradi lastnega poslovnega interesa pa tudi vse ostale.
Če torej ne posodablja ključnih elementov, kjer se ponavadi 'zatakne', se temu ne da reči drugače, kot groba malomarnost.

Upam, da se ne išče opravičila za raznorazne malomarnosti?

Dpool ::

SeMiNeSanja je izjavil:


SoC ali Security Operations Center imamo kje v Sloveniji? Nimajo ga ne ISP-ji, ne podjetja - ker zadeva spada v Enterprise okolja. Glede na to, da je 95% podjetij pod 100 uporabniki, pa mislim, da nima smisla sploh razpredat o enterprise zadevah.


Da, imamo. Tudi sam sem zaposlen kot SOC Analitik v podjetju, ki nudi to storitev. Imajo pa tudi nekatera podjetja znotraj svojega enterprise-a SOC ekipo, ampak po naših izkušnjah so to bolj sys-admini, ki se sedaj ukvarjajo s cyber threats, pozabljajoč, da je cela znanost za tem in potrebno je kar nekaj certifikacij, da pričneš spoznavati to okolje. Šele potem pridejo izkušnje, ki pa so poglavitnega pomena v tej stroki.

Mogoče ne poznaš najbolje to zvrst varnostnega okolja oz. trenutno stanje, zato v globlje debate se ne bom podajal. Upam pa, da morda kdaj tudi v SLO se zbudi zavest o vse večjem narastku kiber kriminala in ransomware-a, ki pa žal ne pozna meja in tudi ni potrebno da govori naš jezik, ni važno če jih je 10 zaposlenih ali 10.000 - če si lahka tarča, si primeren zaslužek, pač pri 10 zaposlenih se bodo pogajal za 100.000 EUR, pri večjih podjetjih pa za miljone za dekripcijo njihovih podatkov.

Zgodovina sprememb…

  • spremenil: Dpool ()

SeMiNeSanja ::

In potem svizec zavije čokolado, ali kako je že šlo tisto?

Me prav zanima, katero podjetje naj bi to bilo, ki ima tzv. 'SoC' na 'enterprise' novoju.

Me je pa spomnilo na primer podjetja, ki jih je že 2x doletel ransomware, pa so se odločili, da jim bo znano SLO podjetje, vodilno na področju network security-ja prevzelo skrb, postavilo nove požarne pregrade in skrbelo za varnost. Kvazi SoC?... (presnet, pa ni navaden helpdesk še SoC!).

No, rezultat tega je bil, da jih je v manj kot 6 mesecih po najemu 'napredne varnostne storitve' ponovno doletela okužba z ransomware-om.

TO je realnost. Ne pa tista samohvala 'imamo SoC, sem analitik,...' - samo upam, da ne delaš ravno za tisto podjetje, ki je bilo omenjeno v zgornji zgodbi.

Kdorkoli najema varnost kot storitev, se mora zavedati, da zagotovo ne bo dobil več, kot je plačal. Prej manj.
Ko ti nekaj ne bo delalo, boš v čakalni vrsti, enako kot pri ISP. "počakajte na prostega operaterja". Hočeš da bodo 'skakali' ko jih pokličeš? Plačaj. Pa ne malo!

Enako velja tudi za opremo, ki ti jo bodo namestili. Malo denarja, malo muzike. Štos pa je, da stranke ponavadi sploh nimajo pojma o tem, kaj na področju network security-ja pomeni malo ali veliko muzike, kaj šele kako to prepoznati.
Glavno da stvari 'delujejo' - čim bolje...... če so pa delovale 'predobro', pa se žal ugotovi šele ko je prepozno.

c3p0 ::

Dobili ransomware, plačali? Kje pa je bil backup? Nobena, še tako z buzzwordi nabita draga škatla z lepim displayem, te ne obvaruje pred vsem.

Če jim to vodilno podjetje ni uredilo niti rednih varnostnih kopij...

SeMiNeSanja ::

c3p0 je izjavil:

Dobili ransomware, plačali? Kje pa je bil backup? Nobena, še tako z buzzwordi nabita draga škatla z lepim displayem, te ne obvaruje pred vsem.

Če jim to vodilno podjetje ni uredilo niti rednih varnostnih kopij...

Mislim da so imeli vse backup-e - vendar so v taki dejavnosti, da so lahko za en dan zaprli štacuno, da so nazaj naložili backup-e.
Stranka, ki se je pripeljala do njihovih vrat in se je morala obrniti zaradi 'tehničnih težav', je šla drugam opraviti to storitev. Naslednje leto pa najbrž niti ne bo probala, če mogoče nimajo 'tehničnih težav'.

Ni problem le odkupnina. Tudi izpadi poslovanja so lahko precej velik problem. Še toliko večji, če imaš več podružnic po sloveniji, pa samo enega informatika. Predenj ta sploh pride do podružnice in prečne z reševanjem problemov je že en kup škode. O izgubi ugleda pa da sploh ne govorimo.

Zagotovo je ni rešitve, ki bo 100,0% zagotavljala, da se ne bo moglo nič zgoditi. Ampak če ti na NSS Labs testih uspejo vsi boljši proizvajalci priti do cca. 97-98%, potem se očitno vendarle nekaj da naresti.
Ogromno sicer narediš že s pametno segmentacijo omrežja. Če potem lahko še preprečiš uporabnikom, da prenašajo izvršljivo kodo (exe, zip, cab, dll,...) s spleta, pa si že ogromno naredil. Ravno tu se pa zatakne - kako boš preprečil prenašanje izvršljive kode, če se jo tako zlahka skrije v https? Edino z dekripcijo https in nič drugače. Endpoint AV proizvodi se namreč nič kaj dodsti ne sprašujejo, od kje je prišla EXE datoteka ali nek DLL. Če ne ustreza nobeni znani signaturi pač ne bo delal panike. Če imaš srečo, se bo zganil, ko bo zadeva hotela zagnati kripto procese. Ampak glede na videno, se to v pre-mnogih primerih ni zgodilo...

So pa ransomware-i uporabljali celo Tor omrežje za prenos komponent. Tudi nekoliko čudno, da se dovoljuje uporabo Tor-a na poslovnem omrežju, mar ne? Ampak takšna je realnost neštetih konfiguracij routerjev in požarnih pregrad: Na noter je par port forward pravil, na ven pa je vse dovoljeno. Konfiguracija za 20minut, toliko da steče wizard, pa da še dodaš tiste tri port forwarde.

Stranki se ne sanja, kaj ima za eno konfiguracijo. Tudi sprašuje ne, saj ji vse 'dela'.
Sem že videl WatchGuard požarno pregrado v nekem HR podjetju, kjer so jo kupili od Italianov, ki so jo tudi postavili. So me iz podjetja prosili, če jim lahko pomagam narest nadgradnjo, češ da imajo Italiani neke težave...
Se prijavim na napravo in debelo gledam. Podjetje je kupilo cel niz varnostnih storitev (IPS, AV, Antispam,...) - pa jim niso niti eno od njih aktivirali.
Raje nisem vprašal, koliko so jim računali za postavitev, ker je to huje od navadnega šalabajzerstva.

Sem hudo alergičen na take, ki se delajo preveč pametne glede security-ja, ker sem že vsega preveč videl. Tudi ko imaš pri roki ozvrstno orodje, s katerim res lahko 'loviš' zadeve, ki jih nočeš spustiti na omrežje ni tako enostavno zadeve optimalno nastaviti. Potem pa naj poslušam, ko pride mimo nek Jype, ki se zadere "naj živi OpenSource", zraven še doda, da jaz nimam pojma o security-ju.
Ponavadi ravno taki na koncu naredijo največjo štalo, ker 'plavajo' v povsem drugih vodah in so mogoče enkrat konfiguriral nek pfSense ali kaj podobnega. Potem so pa že kao guruji in lahko ocenjujejo, kolko kdo obvlada?

Si rečeš ok...saj so pa mogoče strokovnjaki na področju aplikacijske varnosti. Ampak sem v karieri tudi že na take programerje naletel, da sem se samo za glavo držal. Najboljša cvetka je bil 'majster', ki je hotel javni spletni server za stranke postaviti kar na interni MS domenski strežnik, da bo imel lažje delo z direktnim dostopom do SQL baze podjetja. Hja....saj ne more iti nič narobe, mar ne?
No, upam, da je Jype, malo boljši od tega. Programiranje sicer ni moje področje, ampak žal, moraš tudi kdaj programerje učiti, kaj je popolni no-go, ko se gre za najbolj osnovne koncepte varnosti.

V bistvu pa mislim, da je glavni problem v tem, da se vsi preveč zapirajo v nek svoj krog in si nataknejo plašnice, da ja nebi kaj preveč novega spoznali.
Že samo požarne pregrade imajo precej različne pristope do problematike in upravljanja, pa to le redko koga zanima. Ali so nekaj podedovali ali pa nekje slišali da je nekaj 'wau' in potem temu slepo sledijo, ne da bi pogledali levo ali desno.
Morali bi biti veliko bolj odprti do spoznavanja tistih 'grdih podrobnosti', ki na koncu dejansko odločajo o tem, katera rešitev je idealna za neko določeno potrebo.
Kar naj se oglasijo tisti, ki so v zadnjem letu čepeli v uporabniškem vmesniku vsaj štirih različnih vrst požarnih pregrad. Mislim, da bo zelo hitro postalo zelo tiho tukaj.

Toda kaj veš o neki rešitvi, če jo nisi nikoli videl od blizu? Zgolj marketinško nabijanje. Absolutni svetovni prvak tega je PaloAlto, samo kar je zanimivo, da leto za letom na NSS Labs testih pogrne na nos. A nič ne de, še kar se širijo govorice, da je kao najboljša požarna pregrada...?!?

Za mene je najboljša tista, ki mi nudi največ svobode konfiguriranja v podrobnosti, ki jih drugi preprosto ignorirajo.
Za nekoga drugega je najboljša tista, ki 'deluje' tudi če nima kaj dosti pojma o tem, kaj se v ozadnju dogaja. Ki dela kot antivirus, po principu postavi in pozabi. Zelo vprašljiv kriteri, a žal je vse več takih uporabnikov, ki si želijo nekakšno 'pametno instant rešitev', s katero se ne bo treba ukvarjati več, kakor z routerjem doma ali npr. switchem.

Ne vem, ali je to posledica pomanjanja znanja na področju omrežne varnosti, ali preprosto ljudje nimajo več časa in volje, da bi se še s to 'nadlogo' ukvarjali.
Saj ni problem.... dokler gre....

Dpool ::

Ne morem vedeti o katerem podjetju govori sogovornik. Tudi nevem o katerem incidentu natanko, tako da tezko kaj povem. Je pa res, da ni podjetje v katerem delam, saj trenutno smo bolj zastopani v tujini - kot sem prej omenil, slovenski trg zaostaja z znanjem in dogajanjem v kiber kriminalu. Delno tudi ta tema to potrjuje - ce mi je dovoljeno sklepati, da sodelujejo v tej debati slovenski strokovanjaki za kibernetsko varnost.

Ne bom sodeloval vec v debati. Priznam, me prizadene, ce kdo napise da SOC Analitiki ne delamo nic in da se naj ne bi trudili ob svojem delu. Nevem sicer koliko res poznate SOC, ampak delamo 24/7, zmeraj na prezi za incidenti... in zmeraj pripravljeni se efektivno odzvati na incident. Posodabljamo nase storitve, udelezujemo se svetovno znanih konferenc na to tematiko (BlackHat, Defcon), opravljamo SANS certifikate (so vodilni na tem podrocju) iz nase stroke - poleg omenjenega 24/7 dela se vedno se trudimo siriti nasa obzorja in ostati relevantni z aktualnimi trendi. Kaj sele odsotnost po 1 mesec v tujini, kar je navadno zahteva stranke za on-boarding proces..
Taksen zapis, ki ga citiram, je res zaljivo napisati ob vsem tem - upam, da izhaja le iz ne pravih izkusenj / znanja v / o SOCu:

Kdorkoli najema varnost kot storitev, se mora zavedati, da zagotovo ne bo dobil več, kot je plačal. Prej manj.
Ko ti nekaj ne bo delalo, boš v čakalni vrsti, enako kot pri ISP. "počakajte na prostega operaterja". Hočeš da bodo 'skakali' ko jih pokličeš? Plačaj. Pa ne malo!


No s tem pa tudi zakljucim moj dopis v tej temi. Fantje, se opravicujem, ce je kdo dobil obcutek, da sem ga napadel z mojimi odgovori v tej temi - osebno sem resnicno mnenja, da ko enkrat pade pozarni zid je edino kar te lahko obvaruje nekdo, ki neprestano spremlja dejanja v vasem omrezju in je izurjen, da se odzove na njih.

Lepo bodite.

Zgodovina sprememb…

  • spremenil: Dpool ()

SeMiNeSanja ::

@Dpool - si že slišal za pregovor 'izjeme potrjujejo pravilo'?

Namesto da si kao užaljen, bi lahko zatrdil, da se kaj takega vašim strankam ne more zgoditi, ker ste kvazi 'boljši'.

Ampak moraš pa vedeti, da se ponudnika varnostnih storitev nikoli ne zapomnijo po tem, koliko incidentov je preprečil. Zapomnijo se ga po incidentih, ki jih ni uspel preprečiti.

Ne smeš pa tudi ne biti malenkosten, ker je govora o dveh popolnoma različnih zadevah. Enkrat o varnostnih rešitvah, drugič pa o ponudnikih varnostnih storitev.
Oboje nikakor ni za metati v isti koš. Pri nas imaš en kup ponudnikov storitev, ki med drugim malo za povrhu, ponujajo tudi (občasno) upravljanje varnosti.

Zares specializiranih na tem področju pa je zelo malo podjetij. Še manj je takih, bi bi dejansko 24/7 NADZIRALA omrežja svojih strank. Ali so vaši 'zamočili' v tisti zgodbi z izsiljevalskim virusom, ali pa je bil to kdo drug (ni samo eno podjetje aktivno v tujini) ne vem.

Tudi ne vem, zakaj stvar jemlješ osebno. Sploh pa je problem 'nadzornih centrov' v tem, da običajno pade alarm, ko se je štala že zgodila, pa so potem samo še gasilci.

Preventiva se dela drugje in veliko prej, ne pa v nadzornih centrih.

Dpool ::

Sem doumel tvoj post kot direktni odziv name, vsaj tisti del ki sem ga citiral.

Skratka, kot si sam omenil, vmes ste debatirali o tematiki varnostnih resitev in ne o storitvah. Jaz sem nekako uskocil v pogovor not z omembo storitve, tako da sem morda prevec razkropil debato.

Idealni scenarij je zagotovo nepremostljiva varnostna resitev. Ampak mi opazamo, da najvecje tveganje so zal na koncu end-point uporabniki na racunalnikih (Social Engineering metode).

Kar se tice Open Source - morda sem v prvem postu prevec ga hvalil, kajti dejstvo je, da pocasne posodobitve, riziko da projekt preprosto zamre in 'community podpora' niso ravno material s cemer se lahko pohvalis pred stranko. Tako da ja SeMiNeSanja, v teh pogledih imas zagotovo prav.

SeMiNeSanja ::

Dpool je izjavil:

Ampak mi opazamo, da najvecje tveganje so zal na koncu end-point uporabniki na racunalnikih (Social Engineering metode).

Točno ta del pa je tisti, s katerim se jaz že 20 let ubadam - kaj lahko narediš na požarni pregradi, da boš čim bolj uspešno prestregel in nevtraliziral neumnosti, ki jih počno uporabniki - ne da bi to uporabnike preveč resno omejevalo.

Bistvo tega pa je, da si nemočen, če nimaš 'rentgenskega pogleda' v to, kar uporabnik počne na spletu - če ne delaš dekripcije HTTPS prometa.

Seveda imaš potem še tiste variante, kjer social engineering 'preskoči' zadeve, ki jih lahko detektiraš s kakršnokoli tehnologijo. Klasični primer so tista nujna sporočila direktorja računovodji, da je treba nakazati nevem kakšen znesek na nek xy račun. Tukaj je edino kar pomaga izobraževanje uporabnikov, njihovo seznanjanje z vsemi mogočimi variantami zlorab.
Pa še to je dokaj neplodno, če jih potem ne testiraš.

V angleško govorečem prostoru to očitno zelo uspešno dela KnowBe4.
Na WatchGuardu imaš samodejno preusmeritev na KowBe4 kwiz o Phishingu, če DNS filter zazna, da je uporabnik kliknil URL, ki je znan kot Phishing site. Prav luštna zadeva.

Žal KnowBe4 ne pokriva slovenščine, tako da ni ravno široko uporaben na našem prostoru....

Dpool ::

SeMiNeSanja je izjavil:



Seveda imaš potem še tiste variante, kjer social engineering 'preskoči' zadeve, ki jih lahko detektiraš s kakršnokoli tehnologijo. Klasični primer so tista nujna sporočila direktorja računovodji, da je treba nakazati nevem kakšen znesek na nek xy račun.


Verjames ali ne - ta je najbolj pogosto izmed vseh incidentov. Zgodi se tudi, da koncni uporabnik 'sledi navodilom' v e-mailu, cetudi ga nas sistem zazna kot phishing (Email spoofing) in se temu primerno tudi markira (zamenjava 'Subject' fielda v nekaj kot [WARNING: Possible email compromise]).

SeMiNeSanja je izjavil:


V angleško govorečem prostoru to očitno zelo uspešno dela KnowBe4.
Na WatchGuardu imaš samodejno preusmeritev na KowBe4 kwiz o Phishingu, če DNS filter zazna, da je uporabnik kliknil URL, ki je znan kot Phishing site. Prav luštna zadeva.

Žal KnowBe4 ne pokriva slovenščine, tako da ni ravno široko uporaben na našem prostoru....


Zanimivo, si bom ogledal jutri KnowBe4.

SeMiNeSanja ::

Če si že sposoben zaznati 'Possible email compromise', bi ga bilo najbolj poslati v karanteno, pa da ga najprej pregleda kakšen admin in potem sprosti.
Žal pa imaš tu potem lahko že resne probleme z zasebnostjo.

Druga, manj problematična opcija je, da se tak mail pošlje v uporabnikovo spam karanteno, če seveda imaš to možnost.
Tako ga začasno umakneš pred uporabnikovo miško. (Če je res tako zelo nujno, se bo šef že oglasil po telefonu, če bo že kaj z nakazilom)
Bistvo je v tem, da uporabnik tisti mail zagleda šele naslednji dan na listi spam maila, ki ga hraniš v karanteni (poglej in briši oz. reši, če smo po pomoti kaj označili kot spam).
Tako bo uporabnik bistveno bolj pozoren, ker ve, da ima opravka z zbirko vprašljivih zadev.
Tudi šef je ta čas že lahko 'dosegljiv', tako da se lažje preveri pristnost.
Fora namreč pogosto deluje le, če šef ni dosegljiv za preverbo pristnosti.
Ne vem, ali barabe tako dobro sledijo šefom, da vedo, kdaj niso dosegljivi, ali poskušajo na slepo....

jukoz ::

SeMiNeSanja je izjavil:

jukoz je izjavil:

Pod verjetnost a) pašejo vse tiste zadeve iz prvega posta. Vsi ti backdoori so sedaj javni.
Če admin nima časa/volje/dostopa do popravkov, so vsi podatki ki jih zbira na voljo napadalcu.


Sorry, vendar to danes spada pod kategorijo MALOMARNOST.
Podjetje (in Admin) je že po zakonu dolžno varovati osebne podatke. Zaradi lastnega poslovnega interesa pa tudi vse ostale.
Če torej ne posodablja ključnih elementov, kjer se ponavadi 'zatakne', se temu ne da reči drugače, kot groba malomarnost.

Upam, da se ne išče opravičila za raznorazne malomarnosti?


Pri sveti kravi, pa kljub temu imamo nepopatchane opreme kolikor hočeš. In v dveh straneh še nismo prišli do odgovora zakaj.

SeMiNeSanja je izjavil:


No, rezultat tega je bil, da jih je v manj kot 6 mesecih po najemu 'napredne varnostne storitve' ponovno doletela okužba z ransomware-om.


Ne štekam, a jim je kdo garantiral da jih ne bo? Če so jo imeli že 2x in nato še enkrat, jim tehnika očitno ne bo pomagala, samo izobraževanje za uporabnike. Razen če ne delajo škode namenoma.

Zgodovina sprememb…

  • spremenilo: jukoz ()

jukoz ::

SeMiNeSanja je izjavil:


Zagotovo je ni rešitve, ki bo 100,0% zagotavljala, da se ne bo moglo nič zgoditi. Ampak če ti na NSS Labs testih uspejo vsi boljši proizvajalci priti do cca. 97-98%, potem se očitno vendarle nekaj da naresti.
Ogromno sicer narediš že s pametno segmentacijo omrežja. Če potem lahko še preprečiš uporabnikom, da prenašajo izvršljivo kodo (exe, zip, cab, dll,...) s spleta, pa si že ogromno naredil. Ravno tu se pa zatakne - kako boš preprečil prenašanje izvršljive kode, če se jo tako zlahka skrije v https? Edino z dekripcijo https in nič drugače. Endpoint AV proizvodi se namreč nič kaj dodsti ne sprašujejo, od kje je prišla EXE datoteka ali nek DLL. Če ne ustreza nobeni znani signaturi pač ne bo delal panike. Če imaš srečo, se bo zganil, ko bo zadeva hotela zagnati kripto procese. Ampak glede na videno, se to v pre-mnogih primerih ni zgodilo...


Pri naših strankah dekripcija HTTPS zaradi narave dela in zakonodaje odpade. Ne da se white-listat 90% vsega prometa in potem trditi da smo karkoli dosegli. Kaj ti potem ostane, razen antivirusa? PCji so zaklenjeni do določene mere, userji vejo da ne smejo poklikati vsakega exe-ja, omrežje je segmentirano, mrežni diski primerno zaščiteni, backupi 100% preverjeni in delujoči. Ali bodo dobili crypto viruse? Verjetno, enkrat že.

SeMiNeSanja je izjavil:


So pa ransomware-i uporabljali celo Tor omrežje za prenos komponent. Tudi nekoliko čudno, da se dovoljuje uporabo Tor-a na poslovnem omrežju, mar ne? Ampak takšna je realnost neštetih konfiguracij routerjev in požarnih pregrad: Na noter je par port forward pravil, na ven pa je vse dovoljeno. Konfiguracija za 20minut, toliko da steče wizard, pa da še dodaš tiste tri port forwarde.


Odlično, primer slabe prakse. Ne filtrira se prometa na omrežju. Sej s to temo bomo počasi še kam prišli.

Dpool je izjavil:

Priznam, me prizadene, ce kdo napise da SOC Analitiki ne delamo nic in da se naj ne bi trudili ob svojem delu. Nevem sicer koliko res poznate SOC, ampak delamo 24/7, zmeraj na prezi za incidenti... in zmeraj pripravljeni se efektivno odzvati na incident. Posodabljamo nase storitve, udelezujemo se svetovno znanih konferenc na to tematiko (BlackHat, Defcon), opravljamo SANS certifikate (so vodilni na tem podrocju) iz nase stroke - poleg omenjenega 24/7 dela se vedno se trudimo siriti nasa obzorja in ostati relevantni z aktualnimi trendi. Kaj sele odsotnost po 1 mesec v tujini, kar je navadno zahteva stranke za on-boarding proces..

Kaj pa delate 24/7? Kaj pa je to efektivni odziv? Dej prosim malo več opiši, pa kako velike so vaše stranke oz kako velika omrežja imajo. Je to na nivoju od 500 zaposlenih naprej?

Zgodovina sprememb…

  • spremenilo: jukoz ()

jukoz ::

Dpool je izjavil:


Kar se tice Open Source - morda sem v prvem postu prevec ga hvalil, kajti dejstvo je, da pocasne posodobitve, riziko da projekt preprosto zamre in 'community podpora' niso ravno material s cemer se lahko pohvalis pred stranko. Tako da ja SeMiNeSanja, v teh pogledih imas zagotovo prav.


Sam sem pri komercialnih rešitvah zelo alergičen na marketing v stilu zelenih padajočih pismenk in osebe ki to gleda in pritisne na gumb z napisom "VIRUS". Imam v omari lepo pametno požarno pregrado z ledico ki zasveti VIRUS ob nekem dogodku. Verjetno. Ni bila nikoli priklopljena.

Glede odprtokodnih rešitev, jim pa ravno počasnih posodobitev ni mogoče očitati. Če je projet velik tudi zamrl ne bo oz se bo hitro našel sponzor zanj. Moram pa reči, da je community ravno to, kar se mora stranki prodajati kot najboljši garant, da projekt ne bo zamrl. Če se recimo Cisco stranke odločijo da jih gredo tožit, ker ponuja backdoore v svojih produktih, bo Cisco umrl. Odptokoden projet ne more.

Dpool je izjavil:


Verjames ali ne - ta je najbolj pogosto izmed vseh incidentov. Zgodi se tudi, da koncni uporabnik 'sledi navodilom' v e-mailu, cetudi ga nas sistem zazna kot phishing (Email spoofing) in se temu primerno tudi markira (zamenjava 'Subject' fielda v nekaj kot [WARNING: Possible email compromise]).


Socialni inženiring se prepreči na dva načina - s strogo določenimi postopki kako se kaj dela (naprimer nakazilo denarja) in z izobraževanjem uporabnikov.

Seznami scam strani pa držijo tudi brskalniki in uporabnika opozorijo (če seveda ni primoran uporabljati IE).

Zgodovina sprememb…

  • spremenilo: jukoz ()

Dpool ::

jukoz je izjavil:


Kaj pa delate 24/7? Kaj pa je to efektivni odziv? Dej prosim malo več opiši, pa kako velike so vaše stranke oz kako velika omrežja imajo. Je to na nivoju od 500 zaposlenih naprej?


Navadno je to po narocilu stranke ali zeli 24/7 ali 8/5 storitev. Tisti, ki se pac odlocijo za 24/7 izvajamo triazo vseskoz z dezurstvi. Za tako storitev se odlocajo vecje stranke, tako kot si omenil od 500 endpointov in naprej in so iz tujine. Kadar ni aktivnega incidenta razresujemo 'Minor' severity level incidente, kot so sumljive povezave, sumljivi dostopi do nekaterih datotek, nekaj kar machine learning pove, da je neobicajno za tega uporabnika - pri tem pa je poudarek, da je severity po Threat Intelligence kriteriju, Minor. Teh je ponavadi ogromno. V SW projektih lahko primerjate z MINOR Bugi, katere navadno razresis ko 'imas cas', bistveno ne bo vplival na potek aplikacije, ampak je vredu ce se popravi, ko je cas, se jih pa nabere.
Poleg tega pa se update-amo orodja, ki jih uporabljamo in izvajamo obcasno pen-teste.

Kadar se pa sprozi nek incident ki je visje ravni, sprozimo protokol Incident Response. Sedaj kaj je efektivna metoda, ni specificno jasno, vsaka SOC ekipa prilagodi metode za svojo ekipo (glede ne razpolozljivost sredstev). Cilj je, da se prepreci skoda, po potrebi se endpoint izolira ali celo odstrani iz omrezja. Nato sledi analiza malware-a, da poskusamo ugotoviti kaj je nepridiprav poskusal storiti in okrepimo obrambo na tem podrocju. Na koncu pa good-old-fashioned reporting za C-level ljudi.

To je recimo v skromnem opisan Incident Response cikel. Je pa to zelo obsiren pojem in je kar nekaj dobrih knjig in certifikacij na to tematiko, kjer se to vse podrobneje definira.

jukoz ::

SeMiNeSanja je izjavil:

Kot sem rekel: proti https dekripciji lajajo predvsem tisti, ki jo niso sposobni izvajati na primeren način.


Dekripcija se izvaja tako, da se požarna pregrada predstavi odjemalcu kot ciljni strežnik, ciljnemu strežniku pa kot odjemalec. Vmes pogleda kaj se dogaja. Ne da se je izvajati na drugačen način in torej ni debate ali je primerna ali ne. No, se bom popravil. Imaš bedne Antivirusne programe, ki ti naložijo svoj root cert in dekriptirajo ves promet in gledajo kaj je notri. Seveda imajo white-liste, kaj se ne gleda, ampak npr Klik od NLBja ni notri, za to se uporabniki na slo-techu sprašujejo kaj je NLB spet zasrala.

SeMiNeSanja je izjavil:


Uporabniki na omrežju pa nimajo kaj biti 'presenečeni'. Kot prvo, mobiteli nimajo kaj iskati na 'trusted' delu omrežja (tistemu poslovnemu delu z višjo stopnjo varovanja). Kdor že tega v osnovi ni razumel, ta sploh nima kaj pametovati o varnosti. BYOD krama sodi na svoje podomrežje oz. VLAN, podobno kot Guest omrežje (alternativno BYOD priklapljaš na Guest omrežje).
To omrežje pač ne boš pregledoval tako natančno, razen na tistih portih, katerim dovoljuješ izmenjavo prometa z Trusted omrežjem.

Ko pa je govora o Trusted omrežju, pa je podjetje tisto, ki diktira, kaj bodo pravila igre, ne pa zaposleni. Resno podjetje pa zasebni Facebook? Se hecaš? Mogoče potem še Torrente pa kakšen Tor, da si lahko zaposleni še kakšne prepovedane substance naročajo? Še kakšen VPN do doma? Zakaj pa ne potem kar takoj dati zaposlenim DomainAdmin gesla? Ga napišeš zunaj na oglasno desko, da se slučajno ne bo kdo počutil omejenega v svoji 'svobodi'.

Ima svako jakih. Sem delal v resnih podjetjih, kjer je facebook/youtube/... seveda dovoljen. Predvsem pa wetransfer, ker drugače ne bi mogli narediti nič, saj ne bi mogli izmenjat podatkov v zunajimi partnerji. Bi bil pa tudi revolt med zaposlenimi oz bi se jim zmešalo brez youtube/facebook/Novičarskih portalov. Se jim pa brkljanje po internetih seveda beleži in kdor ne dosega rezultatov, bo tudi za facebookanje dobil sankcije.

SeMiNeSanja je izjavil:


Torej.... smo nazaj pri vprašanju: ZAKAJ IMAŠ POŽARNO PREGRADO ?

Če jo imaš zgolj zaradi lepšega, potem je čisto vseeno, če prišparaš tiste par tisočakov in tja postaviš navaden router.
Če jo pa imaš zaradi ZAŠČITE omrežja, potem pa je tvoja naloga da uporabnikom razložiš:
a) kakšne grožnje prežijo na omrežje podjetja
b) kaj lahko uporabnik naredi, da se jim poskusi izogniti
c) kaj lahko ti narediš, da pomagaš uporabniku pri tem
d) kakšen vpliv to ima na njegovo zasebnost in 'svobodo' na omrežju podjetja

Če uporabnikom razložiš vse to zgoraj, so to sposobni dojeti in upoštevati, ne rabiš Dekripcije HTTPS, ker se bodo lepo obnašali.

SeMiNeSanja je izjavil:


Vse ostalo so pa zgolj lame izgovori tistih, ki se jim ne ljubi stvari spraviti v red.
Bistveno lažje je tam, kjer jim to že standardi predpisujejo. Tam pač ni takih izgovorov o MITM in podobnem.

Sej tu je problem - standardov in predpisov ni. Lastnik podjetja reče, da na njegovi opremi in omrežju ne bo nobenih zasebnih zadev in ima seveda pravico vpogleda. Pravo pa pravi drugače. In če jim tega ne dopoveč, potem si jih dobro zafrknil,ž.

SeMiNeSanja je izjavil:


Samo je res zanimivo: ko so bili na pohodu izsiljevalski virusi, je bilo vsakomur jasno, da je https boleča točka, preko katere ti lahko marsikaj spravijo na računalnik.
Čim se je malo polegel prah okoli teh virusov, pa https kar na enkrat ni več problem. Do naslednje štale?

Predvsem se je povečal nadzor nad backupi. Kar naenkrat se je našlo kaj vse mora še iti na mrežne diske, da bo ja arhivirano. Dekripcije HTTPS se ni nikjer aktivirala, ker bi za to potrebovali dovoljenje zaposlenih, česar pa ne bi dali. Ne da se ker silit ljudi ali pa jih odpustiti. Spoh pa ne dandanes.

SeMiNeSanja je izjavil:


Zasebnost.... Na neštetih koncih se v podjetju logira takšen ali drugačen promet. Požarne pregrade ga tudi logirajo, vendar je tu treba reči, da MITM skeptiki ljudi prepričujejo, da admin potem vidi kar vse, kar si počel na Facebook&Co, kar pa je skrajno grda laž. Največ kar lahko vidi, so URL-ji, nikakor pa ne dejanske vsebine.
In resno: koliko adminov je tako premaknjenih, da bodo šli vohuniti za uporabniki, katere URL-je so na Facebook klikali, sploh če se jim večina ne bo odprla, ker nimajo ustreznih session cookie-jev ali uporabnikovih gesel?
Admin, ki bi imel takšne kriminalne namene, ti bo kar lepo namestil vohunski programček na PC in te direktno stalkal. Čemu bi se še zajebaval tu z neko požarno pregrado?

Zanimivo, da nihče ne dela panike glede tega, da lahko admin bere maile zaposlenih, pa se je to že nevem kolikokrat dogajalo.


Mailov ne smejo brat kar tako.

In ja, z MITM lahko dobiš vse podatke, kaj nekdo dela na FB, od prijavnih naprej. Zato je pa to tako problematično. Če uporabnik pričakuje zasebnost in mu to zagotavlja ponudnik, se ti FW nima kaj mešati v to. Razen če se je uporabnik s tem seveda strinjal.

Dpool je izjavil:

jukoz je izjavil:


Kaj pa delate 24/7? Kaj pa je to efektivni odziv? Dej prosim malo več opiši, pa kako velike so vaše stranke oz kako velika omrežja imajo. Je to na nivoju od 500 zaposlenih naprej?


Navadno je to po narocilu stranke ali zeli 24/7 ali 8/5 storitev. Tisti, ki se pac odlocijo za 24/7 izvajamo triazo vseskoz z dezurstvi. Za tako storitev se odlocajo vecje stranke, tako kot si omenil od 500 endpointov in naprej in so iz tujine. Kadar ni aktivnega incidenta razresujemo 'Minor' severity level incidente, kot so sumljive povezave, sumljivi dostopi do nekaterih datotek, nekaj kar machine learning pove, da je neobicajno za tega uporabnika - pri tem pa je poudarek, da je severity po Threat Intelligence kriteriju, Minor. Teh je ponavadi ogromno. V SW projektih lahko primerjate z MINOR Bugi, katere navadno razresis ko 'imas cas', bistveno ne bo vplival na potek aplikacije, ampak je vredu ce se popravi, ko je cas, se jih pa nabere.
Poleg tega pa se update-amo orodja, ki jih uporabljamo in izvajamo obcasno pen-teste.

Kadar se pa sprozi nek incident ki je visje ravni, sprozimo protokol Incident Response. Sedaj kaj je efektivna metoda, ni specificno jasno, vsaka SOC ekipa prilagodi metode za svojo ekipo (glede ne razpolozljivost sredstev). Cilj je, da se prepreci skoda, po potrebi se endpoint izolira ali celo odstrani iz omrezja. Nato sledi analiza malware-a, da poskusamo ugotoviti kaj je nepridiprav poskusal storiti in okrepimo obrambo na tem podrocju. Na koncu pa good-old-fashioned reporting za C-level ljudi.

To je recimo v skromnem opisan Incident Response cikel. Je pa to zelo obsiren pojem in je kar nekaj dobrih knjig in certifikacij na to tematiko, kjer se to vse podrobneje definira.



OK, torej ti en bot reče - tale in tale zadeva je sumljiva. In nato se odzoveš. Ker je veliko uporabnikov, je tudi veliko dogodkov, zato 24/7 dežurstvo. Če ni nič, urejate ostale zadeve. Sem mislil da se temu reče normalno dežurstvo. V manjših podjetjih (pod 500 userjev) to delajo IT oddelki, če so seveda dovolj kvalificirani.

Zgodovina sprememb…

  • spremenilo: jukoz ()

SeMiNeSanja ::

jukoz je izjavil:


Pri sveti kravi, pa kljub temu imamo nepopatchane opreme kolikor hočeš. In v dveh straneh še nismo prišli do odgovora zakaj.


Kaj pa bi rad slišal? Da je toliko nepopatchanega, ker ni policajev, ki bi te zaradi tega kaznovali?
99% omrežij pač ne podlega nekim revizijam, ki bi se spuščale v takšne 'podrobnosti'. Dokler se kaj ne zalomi, tako ni problema.

Dodaten problem je lahko tudi 'inventura'. Marsikje sploh ne vedo kaj vse imajo v hiši in kaj od tega je nepopatchano ali celo EoL.

EoL krame imaš tudi še ogromno, ki se jo ne bo zamenjalo, dokler ne bo crknila. Saj dela....zakaj drezat...?
Malo pa pozabljajo, da je taka zadeva že oddelala svoje in lahko kadarkoli odpove. S tem pa predstavlja tudi nevarnost za nepredviden izpad, ne le varnostno tveganje.

jukoz je izjavil:


Pri naših strankah dekripcija HTTPS zaradi narave dela in zakonodaje odpade. Ne da se white-listat 90% vsega prometa in potem trditi da smo karkoli dosegli. Kaj ti potem ostane, razen antivirusa? PCji so zaklenjeni do določene mere, userji vejo da ne smejo poklikati vsakega exe-ja, omrežje je segmentirano, mrežni diski primerno zaščiteni, backupi 100% preverjeni in delujoči. Ali bodo dobili crypto viruse? Verjetno, enkrat že.


Zaradi narave dela in zakonodaje? Si lahko bolj konkreten?
Načeloma noben zakon ne prepoveduje dekripcije prometa. Ampak to je dejansko precej načelno, tako da moraš preveriti od primera do primera kaj je dopustno ali ne, kaj je sorazmerno in kaj ne.

Sicer pa je marsikdo že sam od sebe izklopil dekripcijo, čim jo je zagnal - ker mu je ubila performanse naprave. Marsikdo kupuje rešitve glede na 'firewall throughput', kar pa je maximum, ki ga lahko dosežeš, če izklopiš vse varnostne storitve. Več ko jih vklopiš, boj zamoriš mašino. Antivirus + https pa lahko zadevo dokončno pokoplje, če ni bila pravilno dimenzionirana.

Ko pa potem gledaš cenike dovolj zmogljivih naprav, da bi 'zmlele' npr. 1Gbps se pri določenih proizvajalcih znajdeš že v cenovnih razredih, ki enostavno niso več dosegljivi marsikateremu IT proračunu.

Tako imaš že določene 'naravne ovire', ki ti onemogočajo uvedbo dekripcije https, če si 'prilepljen' na proizvajalca v višjem cenovnem segmentu.

Drugače pa vedno znova naletiš na bajke o tem, kaj vse vidiš, kaj nekdo počne na facebook-u. Če bi uporabnikom pokazal, kaj dejansko lahko VIDIŠ, bi tudi marsikateri rekel "Pejt se solit, to pa kar buli, če nimaš boljšega dela!". Pri tem je tista solata spodaj zgolj od cca. ene strani. Kako veselo šele izgleda, če imaš eno resno Facebook 'seanso' pred sabo. Resnično ne vem, komu se da brklat po temu. Še najmanj pa kakšnemu 'firbčnemu direktorju', ki se ga najpogosteje navaja kot tistega najbolj kritičnega 'firbca'. Bi ga moral najprej pošteno učiti regexp, da bi si vsaj malo lahko pomagal z logi. Čeprav tudi potem ne vem, kaj bi dejansko uspel 'ekstrahirat'.

Kako že rečejo? Strah ima velike oči?

2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Access-Control-Allow-Origin:*" header="Access-Control-Allow-Origin: https://www.facebook.com\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=2&partition=-2&clientid=5f35187f&cb=avdv&idle=58&qp=y&cap=8&tur=6300&qpmade=1532984916465&pws=fresh&isq=7&msgs_recv=2&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy&state=active" sent_bytes="999" rcvd_bytes="425" elapsed_time="50.321809 sec(s)" app_id="5" app_cat_id="3" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=2&partition=-2&clientid=5f35187f&cb=h279&idle=108&qp=y&cap=8&tur=6300&qpmade=1532984916465&pws=fresh&isq=7&msgs_recv=2&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Referer:*" header="Referer: https://www.facebook.com/\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP App match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-002E" proxy_act="HTTP-Client.1" app_cat_name="Social networks" app_cat_id="24" app_name="Facebook Message" app_id="40" app_beh_name="Communication" app_beh_id="2" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=2&partition=-2&clientid=5f35187f&cb=h279&idle=108&qp=y&cap=8&tur=6300&qpmade=1532984916465&pws=fresh&isq=7&msgs_recv=2&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:07 Allow 192.168.111.135 192.168.111.1 dns/udp 50498 53 1-Trusted Firebox DNS Forwarding 70 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="AAAA" question="6-edge-chat.facebook.com" 	Traffic
2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Access-Control-Allow-Origin:*" header="Access-Control-Allow-Origin: https://www.facebook.com\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:07 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=2&partition=-2&clientid=5f35187f&cb=h279&idle=108&qp=y&cap=8&tur=6300&qpmade=1532984916465&pws=fresh&isq=7&msgs_recv=2&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" sent_bytes="987" rcvd_bytes="521" elapsed_time="0.195544 sec(s)" app_id="5" app_cat_id="3" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:08 Allow 192.168.111.135 192.168.111.1 dns/udp 52430 53 1-Trusted Firebox DNS Forwarding 66 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="connect.facebook.net" 	Traffic
2018-07-30 23:11:08 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=8z43&idle=108&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:08 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Referer:*" header="Referer: https://www.facebook.com/\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:08 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP App match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-002E" proxy_act="HTTP-Client.1" app_cat_name="Social networks" app_cat_id="24" app_name="Facebook Message" app_id="40" app_beh_name="Communication" app_beh_id="2" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:08 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=8z43&idle=108&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:09 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="www.facebook.com" arg="/tr/?id=199327623815850&ev=fb_page_view&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985068596&sw=2752&sh=1720" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:09 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="www.facebook.com" arg="/tr/?id=199327623815850&ev=fb_page_view&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985068596&sw=2752&sh=1720" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:09 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="www.facebook.com" arg="/tr/?id=199327623815850&ev=fb_page_view&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985068596&sw=2752&sh=1720" sent_bytes="842" rcvd_bytes="345" elapsed_time="0.148402 sec(s)" app_id="3" app_cat_id="24" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:09 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="www.facebook.com" arg="/tr/?id=101984190133976&ev=PageView&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985068801&sw=2752&sh=1720&v=2.8.24&r=stable&ec=0&o=28&it=1532985068572&exp=button_click_send_beacon" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:09 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="www.facebook.com" arg="/tr/?id=101984190133976&ev=PageView&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985068801&sw=2752&sh=1720&v=2.8.24&r=stable&ec=0&o=28&it=1532985068572&exp=button_click_send_beacon" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:09 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="www.facebook.com" arg="/tr/?id=101984190133976&ev=PageView&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985068801&sw=2752&sh=1720&v=2.8.24&r=stable&ec=0&o=28&it=1532985068572&exp=button_click_send_beacon" sent_bytes="912" rcvd_bytes="345" elapsed_time="0.151875 sec(s)" app_id="3" app_cat_id="24" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:10 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="www.facebook.com" arg="/tr/?id=101984190133976&ev=Microdata&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985070313&cd[Schema.org]=%5B%5D&cd[OpenGraph]=%7B%7D&cd[Meta]=%7B%22title%22%3A%22Siol.net%22%2C%22meta%3Akeywords%22%3A%22Novice%2C%20Slovenija%" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:10 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="www.facebook.com" arg="/tr/?id=101984190133976&ev=Microdata&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985070313&cd[Schema.org]=%5B%5D&cd[OpenGraph]=%7B%7D&cd[Meta]=%7B%22title%22%3A%22Siol.net%22%2C%22meta%3Akeywords%22%3A%22Novice%2C%20Slovenija%" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:11 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="www.facebook.com" arg="/tr/?id=101984190133976&ev=Microdata&dl=https%3A%2F%2Fsiol.net%2F&rl=https%3A%2F%2Fsiol.net%2F&if=false&ts=1532985070313&cd[Schema.org]=%5B%5D&cd[OpenGraph]=%7B%7D&cd[Meta]=%7B%22title%22%3A%22Siol.net%22%2C%22meta%3Akeywords%22%3A%22Novice%2C%20Slovenija%" sent_bytes="1715" rcvd_bytes="345" elapsed_time="0.174588 sec(s)" app_id="3" app_cat_id="24" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:11 Allow 192.168.111.135 192.168.111.1 dns/udp 58184 53 1-Trusted Firebox DNS Forwarding 67 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="AAAA" question="staticxx.facebook.com" 	Traffic
2018-07-30 23:11:11 Allow 192.168.111.135 192.168.111.1 dns/udp 58654 53 1-Trusted Firebox DNS Forwarding 67 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="staticxx.facebook.com" 	Traffic
2018-07-30 23:11:11 Allow 192.168.111.135 192.168.111.1 dns/udp 65443 53 1-Trusted Firebox DNS Forwarding 62 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="www.facebook.com" 	Traffic
2018-07-30 23:11:12 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:8:face:b00c:0:1 https/tcp 45715 443 1-Trusted 0-T-2 ProxyInspect: HTTPS domain name match   (HTTPS-proxy.Out-00) HTTPS-Client.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client.1" rule_name="Default" sni="staticxx.facebook.com" cn="*.facebook.com" ipaddress="2a03:2880:f012:8:face:b00c:0:1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:14 Allow 192.168.111.135 192.168.111.1 dns/udp 51910 53 1-Trusted Firebox DNS Forwarding 75 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="star-z-mini.c10r.facebook.com" 	Traffic
2018-07-30 23:11:15 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45723 443 1-Trusted 0-T-2 ProxyInspect: HTTPS domain name match   (HTTPS-proxy.Out-00) HTTPS-Client.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client.1" rule_name="Default" sni="www.facebook.com" cn="*.facebook.com" ipaddress="2a03:2880:f112:86:face:b00c:0:50fb" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="www.facebook.com" arg="/ajax/bz" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Referer:*" header="Referer: https://www.facebook.com/janez.novak.10?fref=pymk\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="POST" dstname="www.facebook.com" arg="/ajax/bz" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:55 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Content-Security-Policy:*" header="content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self';\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:55 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Access-Control-Allow-Origin:*" header="Access-Control-Allow-Origin: https://www.facebook.com\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:55 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="POST" dstname="www.facebook.com" arg="/ajax/bz" sent_bytes="1606" rcvd_bytes="1413" elapsed_time="0.308420 sec(s)" app_id="3" app_cat_id="24" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:58 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Access-Control-Allow-Origin:*" header="Access-Control-Allow-Origin: https://www.facebook.com\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:58 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=8z43&idle=108&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" sent_bytes="957" rcvd_bytes="425" elapsed_time="50.196011 sec(s)" app_id="5" app_cat_id="3" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:58 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=60a6&idle=159&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:58 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Referer:*" header="Referer: https://www.facebook.com/\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:58 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP App match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-002E" proxy_act="HTTP-Client.1" app_cat_name="Social networks" app_cat_id="24" app_name="Facebook Message" app_id="40" app_beh_name="Communication" app_beh_id="2" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:58 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=60a6&idle=159&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:11:59 Allow 192.168.111.135 192.168.111.1 dns/udp 60097 53 1-Trusted Firebox DNS Forwarding 70 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="6-edge-chat.facebook.com" 	Traffic
2018-07-30 23:12:02 Allow 192.168.111.130 84.255.209.79 dns/udp 54208 53 1-Trusted Firebox DNS Forwarding 79 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" dst_ip_nat="192.168.111.1" src_user="Nekdo@nekje.si" record_type="A" question="star.c10r.facebook.com" 	Traffic
2018-07-30 23:12:02 Allow 192.168.111.130 84.255.209.79 dns/udp 54215 53 1-Trusted Firebox DNS Forwarding 79 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" dst_ip_nat="192.168.111.1" src_user="Nekdo@nekje.si" record_type="A" question="star.c10r.facebook.com" 	Traffic
2018-07-30 23:12:02 Allow 2b0a:134:20a6:bb00::135 2a01:260:f000:a:face:b00c:0:a7 https/tcp 45591 443 1-Trusted 0-T-2 HTTPS Request   (HTTPS-proxy.Out-00) HTTPS-Client.1 proc_id="https-proxy" rc="548" msg_id="2CFF-0000" proxy_act="HTTPS-Client.1" tls_profile="TLS-Client-HTTPS.Standard.1" tls_version="TLS_V12" sni="scontent.flju1-1.fna.fbcdn.net" cn="*.flju1-1.fna.fbcdn.net" cert_issuer="CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US" cert_subject="CN=*.flju1-1.fna.fbcdn.net,O=Facebook\x5c, Inc.,L=Menlo Park,ST=California,C=US" action="allow" app_id="0" app_cat_id="0" sent_bytes="602846" rcvd_bytes="602846" geo_src="SVN" geo_dst="SVN" 	Traffic
2018-07-30 23:12:02 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:8:face:b00c:0:1 https/tcp 45592 443 1-Trusted 0-T-2 HTTPS Request   (HTTPS-proxy.Out-00) HTTPS-Client.1 proc_id="https-proxy" rc="548" msg_id="2CFF-0000" proxy_act="HTTPS-Client.1" tls_profile="TLS-Client-HTTPS.Standard.1" tls_version="TLS_V12" sni="static.xx.fbcdn.net" cn="*.facebook.com" cert_issuer="CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US" cert_subject="CN=*.facebook.com,O=Facebook\x5c, Inc.,L=Menlo Park,ST=California,C=US" action="allow" app_id="0" app_cat_id="0" sent_bytes="238067" rcvd_bytes="238067" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:02 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:8:face:b00c:0:1 https/tcp 45588 443 1-Trusted 0-T-2 HTTPS Request   (HTTPS-proxy.Out-00) HTTPS-Client.1 proc_id="https-proxy" rc="548" msg_id="2CFF-0000" proxy_act="HTTPS-Client.1" tls_profile="TLS-Client-HTTPS.Standard.1" tls_version="TLS_V12" sni="static.xx.fbcdn.net" cn="*.facebook.com" cert_issuer="CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US" cert_subject="CN=*.facebook.com,O=Facebook\x5c, Inc.,L=Menlo Park,ST=California,C=US" action="allow" app_id="0" app_cat_id="0" sent_bytes="2483388" rcvd_bytes="2483388" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:03 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45779 443 1-Trusted 0-T-2 ProxyInspect: HTTPS domain name match   (HTTPS-proxy.Out-00) HTTPS-Client.1 proc_id="https-proxy" rc="592" msg_id="2CFF-0003" proxy_act="HTTPS-Client.1" rule_name="Default" sni="edge-chat.facebook.com" cn="*.facebook.com" ipaddress="2a03:2880:f012:1:face:b00c:0:1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:03 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45779 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="edge-chat.facebook.com" arg="/chat?region=ash" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:03 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45779 443 1-Trusted 0-T-2 ProxyAllow: HTTP App match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-002E" proxy_act="HTTP-Client.1" app_cat_name="Social networks" app_cat_id="24" app_name="Facebook Message" app_id="40" app_beh_name="Communication" app_beh_id="2" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:03 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45779 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="edge-chat.facebook.com" arg="/chat?region=ash" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:03 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45779 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="edge-chat.facebook.com" arg="/chat?region=ash" sent_bytes="981" rcvd_bytes="212" elapsed_time="0.135447 sec(s)" app_id="40" app_cat_id="24" reputation="4" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:48 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Access-Control-Allow-Origin:*" header="Access-Control-Allow-Origin: https://www.facebook.com\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:48 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=60a6&idle=159&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" sent_bytes="957" rcvd_bytes="425" elapsed_time="50.167509 sec(s)" app_id="5" app_cat_id="3" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:48 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=beu8&idle=209&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:48 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Referer:*" header="Referer: https://www.facebook.com/\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:48 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP App match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-002E" proxy_act="HTTP-Client.1" app_cat_name="Social networks" app_cat_id="24" app_name="Facebook Message" app_id="40" app_beh_name="Communication" app_beh_id="2" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:48 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f012:1:face:b00c:0:1 https/tcp 45605 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="GET" dstname="6-edge-chat.facebook.com" arg="/pull?channel=p_1080763749&seq=3&partition=-2&clientid=5f35187f&cb=beu8&idle=209&qp=y&cap=8&pws=fresh&isq=7&msgs_recv=3&uid=1080763749&viewer_uid=1080763749&sticky_token=162&sticky_pool=ash4c09_chat-proxy" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:48 Allow 192.168.111.135 192.168.111.1 dns/udp 49387 53 1-Trusted Firebox DNS Forwarding 70 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="6-edge-chat.facebook.com" 	Traffic
2018-07-30 23:12:48 Allow 192.168.111.135 192.168.111.1 dns/udp 64144 53 1-Trusted Firebox DNS Forwarding 70 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="AAAA" question="6-edge-chat.facebook.com" 	Traffic
2018-07-30 23:12:51 Allow 192.168.111.135 192.168.111.1 dns/udp 58523 53 1-Trusted Firebox DNS Forwarding 68 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="star.c10r.facebook.com" 	Traffic
2018-07-30 23:12:51 Allow 192.168.111.135 192.168.111.1 dns/udp 60950 53 1-Trusted Firebox DNS Forwarding 68 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="AAAA" question="star.c10r.facebook.com" 	Traffic
2018-07-30 23:12:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAvScan: HTTP request URL match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="599" msg_id="1AFF-000B" proxy_act="HTTP-Client.1" rule_name="Default" dstname="www.facebook.com" arg="/ajax/bz" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Referer:*" header="Referer: https://www.facebook.com/janez.novak.10?fref=pymk\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP Request categories   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP-Client.1" cats="Social Web - Facebook" op="POST" dstname="www.facebook.com" arg="/ajax/bz" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:54 Allow 192.168.111.135 192.168.111.1 dns/udp 60942 53 1-Trusted Firebox DNS Forwarding 62 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="A" question="www.facebook.com" 	Traffic
2018-07-30 23:12:54 Allow 192.168.111.135 192.168.111.1 dns/udp 63477 53 1-Trusted Firebox DNS Forwarding 62 128 (Internal Policy)  proc_id="firewall" rc="100" msg_id="3000-0148" src_user="Nekdo@nekje.si" record_type="AAAA" question="www.facebook.com" 	Traffic
2018-07-30 23:12:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Content-Security-Policy:*" header="content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self';\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 ProxyAllow: HTTP header match   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP-Client.1" rule_name="Access-Control-Allow-Origin:*" header="Access-Control-Allow-Origin: https://www.facebook.com\x0d\x0a" geo_src="SVN" geo_dst="IRL" 	Traffic
2018-07-30 23:12:54 Allow 2b0a:134:20a6:bb00::135 2a03:2880:f112:86:face:b00c:0:50fb https/tcp 45577 443 1-Trusted 0-T-2 HTTP request   (HTTPS-proxy.Out-00) HTTP-Client.1 proc_id="http-proxy" rc="525" msg_id="1AFF-0024" proxy_act="HTTP-Client.1" op="POST" dstname="www.facebook.com" arg="/ajax/bz" sent_bytes="2498" rcvd_bytes="1413" elapsed_time="0.273453 sec(s)" app_id="3" app_cat_id="24" reputation="1" geo_src="SVN" geo_dst="IRL" 	Traffic

tony1 ::

Še glede strojne inšpekcije HTTPS prometa z namenom iskanja malwera: ne drži, da zanjo potrebuješ soglasje zaposlenih. Zaposleni so zaposleni in ne lastniki. Če jim kaj ni prav, lahko grejo delat drugam.

Drži pa, da morajo biti obveščeni o tem, da se to v podjetju počne. To je lahko objavljeno v kakšnem pravilniku, "hišnem redu" firme, ali pa na oglasni deski ipd. In to je vse.

Invictus ::

Ni tako simple...

Sam sem 15 let nazaj lovil nekoga, ki je dnevno spraznil barvno kartušo s printanjem privat slik. In ga dobil.

Pravna služba se je že takrat odločila, da je zakonodaja preveč na strani uporabnika zaradi varstva osebnih podatkov. Danes je še hujše...

Edino kar lahko narediš je, da spremljaš kje ti zaposleni surfajo, in to blokiraš. Tukaj ne morejo nič. Seveda imaš pa danes za surfanje privat pametne telefone na katere težko vplivaš, ker so GSM motilci prepovedani.

It's not USA...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

tony1 ::

Štekam, in če je printer skupni je težko kaj doseči... Lahko bi mu pa ITjevec naložil ČB printer driver in vzel admin pravice :)

Sicer pa glede dekriptiranja https prometa pri nas obstaja vsaj ena odločba Pooblaščenca (o tem je že pred leti pisal Matthai) in jo lahko vsak prebere...

Prav tako ni hudič, da Pooblaščenec ne bi odgovoril s stavkom ali dvema, če ga na to temo random podjetje vpraša za nasvet. Vsaj upam, no...

Invictus ::

tony1 je izjavil:

Štekam, in če je printer skupni je težko kaj doseči... Lahko bi mu pa ITjevec naložil ČB printer driver in vzel admin pravice :)

Saj uporabniki nimajo admin pravic, kaj blužiš... Vsi tiskalniki so bili na mreži...

Saj takrat sem jaz popizdil, ker so razni šefi sektorjev naročali tiskalnike brez naše vednosti, potem so pa nam težili, ker niso delali kot bi hoteli. Itak so večinoma naročali barvne inkjet tiskalnike, ki so bili takrat v vzponu...

Danes je še huje, ker imajo praktično vsi HP tiskalniki wifi, na katerega se brez problema priklopiš, pa ne vidiš, da bi IT sektor to izklopil in malo blokiral...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

SeMiNeSanja ::

Invictus je izjavil:


Danes je še huje, ker imajo praktično vsi HP tiskalniki wifi, na katerega se brez problema priklopiš, pa ne vidiš, da bi IT sektor to izklopil in malo blokiral...

Ti posodim AccessPoint s katerim to prav komot blokiraš? :)

Tudi tu so se stvari v zadnjih letih precej premaknile, vendar moraš biti pripravljen malo globlje poseči v žep.

Sva z Matthai-em se nekaj pripravljala, da bi nekaj na to temo spentljala, pa se časovno še nisva nikamor premaknila.

Bistvo je to, da se accesspoint obnaša kot pes ovčar, ki se nauči katere ovčke so njegove, kje je ograda in kje prežijo nevarnosti. Potem pa ves čas spremlja, kaj počno njegove ovčke. Če hočejo preko ograde, jim pošilja disconnect pakete. Lahko jih postavi v karanteno, da se ne morejo povezati niti v lastni WiFi in podobno.

Če v takem okolju potem prižgeš neavtoriziran WiFi na tiskalniku, ti AP zlepa ne bo pustil, da se povežeš nanj, ker ga bo po default klasificiral kot rouge accesspoint. Pa še odjemalca, ki bi se hotel nanj povezat bo znal postaviti v karanteno, tko da ne bo preveč težko najti lumpa, ki je skušal izigrati pravila.

jukoz ::

SeMiNeSanja je izjavil:



Kaj pa bi rad slišal? Da je toliko nepopatchanega, ker ni policajev, ki bi te zaradi tega kaznovali?
99% omrežij pač ne podlega nekim revizijam, ki bi se spuščale v takšne 'podrobnosti'. Dokler se kaj ne zalomi, tako ni problema.

Dodaten problem je lahko tudi 'inventura'. Marsikje sploh ne vedo kaj vse imajo v hiši in kaj od tega je nepopatchano ali celo EoL.

EoL krame imaš tudi še ogromno, ki se jo ne bo zamenjalo, dokler ne bo crknila. Saj dela....zakaj drezat...?
Malo pa pozabljajo, da je taka zadeva že oddelala svoje in lahko kadarkoli odpove. S tem pa predstavlja tudi nevarnost za nepredviden izpad, ne le varnostno tveganje.


Ni to stvar revizije, ampak pameti. EoL naprave me ne motijo, če niso direktno na netu. EoL NAS, do katerega se dostopa preko VPN ni panike. EoL NAS, na katerem poleg podatkov podjetja visijo gor še interne spletne strani z dokumentacjo, CRMjem in še čem pa. Par tednov nazaj je en spraševal kako rešiti podatke iz crknjenega NASa na nov NAS. Ker ima novi "miljon servicov ki jih ponuja Synology". Sem prepričan da jih bo rabil =)


SeMiNeSanja je izjavil:


Zaradi narave dela in zakonodaje? Si lahko bolj konkreten?
Načeloma noben zakon ne prepoveduje dekripcije prometa. Ampak to je dejansko precej načelno, tako da moraš preveriti od primera do primera kaj je dopustno ali ne, kaj je sorazmerno in kaj ne.

Reševanje različnih težav in komunikacija z zunanjimi partnerji zahteva posvetovanje po različnih medijih, tudi facebook, instagram, twitter, skype, dropbox, viber, whatsapp, ... 95% uporabnikov uporablja privat accounte za to, oz si jih kreira. Noben nima dodatnega dveh usernameov ala ime_priimek in ime_priimek_služba. Teoretično bi sicer lahko organizacija to zahtevala, pa ne. Že to da se uporabnike prepriča da uporabljajo službeni dropbox je veliko (zakaj ga uporabljajo je tako ali tako povsem jasno - ker lokalni admin ne dohiteva uporabnikov z odpiranjem dostopa do javnega NASa).
Če imaš pravilno urejene pravilnike, lahko spremljaš komunikacijo zaposlenih (no, to je tudi omejeno, samo pomisli na e-pošto ko zaposleni odide), ki je izvedena v službene namene. V privat pa ne. 95% uporabnikov je stalno zlogirana v svoj google account da lahko gleda gmail. Svoj privat gmail.

SeMiNeSanja je izjavil:


Sicer pa je marsikdo že sam od sebe izklopil dekripcijo, čim jo je zagnal - ker mu je ubila performanse naprave. Marsikdo kupuje rešitve glede na 'firewall throughput', kar pa je maximum, ki ga lahko dosežeš, če izklopiš vse varnostne storitve. Več ko jih vklopiš, boj zamoriš mašino. Antivirus + https pa lahko zadevo dokončno pokoplje, če ni bila pravilno dimenzionirana.

Ko pa potem gledaš cenike dovolj zmogljivih naprav, da bi 'zmlele' npr. 1Gbps se pri določenih proizvajalcih znajdeš že v cenovnih razredih, ki enostavno niso več dosegljivi marsikateremu IT proračunu.

Tako imaš že določene 'naravne ovire', ki ti onemogočajo uvedbo dekripcije https, če si 'prilepljen' na proizvajalca v višjem cenovnem segmentu.

Oprema se ceni in ne bo problem v nedogled. In kot sem zapisal, dekripcija HTTPS ni problem, če se uporabniki strinjajo. Ker se ne, delaš white-liste. Te white-liste so na koncu 90% vsega prometa. In potem je vse skupaj brez veze.

SeMiNeSanja je izjavil:


Drugače pa vedno znova naletiš na bajke o tem, kaj vse vidiš, kaj nekdo počne na facebook-u. Če bi uporabnikom pokazal, kaj dejansko lahko VIDIŠ, bi tudi marsikateri rekel "Pejt se solit, to pa kar buli, če nimaš boljšega dela!". Pri tem je tista solata spodaj zgolj od cca. ene strani. Kako veselo šele izgleda, če imaš eno resno Facebook 'seanso' pred sabo. Resnično ne vem, komu se da brklat po temu. Še najmanj pa kakšnemu 'firbčnemu direktorju', ki se ga najpogosteje navaja kot tistega najbolj kritičnega 'firbca'. Bi ga moral najprej pošteno učiti regexp, da bi si vsaj malo lahko pomagal z logi. Čeprav tudi potem ne vem, kaj bi dejansko uspel 'ekstrahirat'.

Kako že rečejo? Strah ima velike oči?

Hja, mal bi sicer moral pogledat, ampak bi lahko hitro kaj pametnega izluščil iz spodnjega. Sploh če me zanima kaj specifičnega.
Mimogrede, je login zraven?

tony1 je izjavil:

Še glede strojne inšpekcije HTTPS prometa z namenom iskanja malwera: ne drži, da zanjo potrebuješ soglasje zaposlenih. Zaposleni so zaposleni in ne lastniki. Če jim kaj ni prav, lahko grejo delat drugam.

Drži pa, da morajo biti obveščeni o tem, da se to v podjetju počne. To je lahko objavljeno v kakšnem pravilniku, "hišnem redu" firme, ali pa na oglasni deski ipd. In to je vse.


Ne, zaposleni se morajo strinjati s pregledovanjem prometa. Če lahko razumno pričakujejo zasebnost komunikacije, jim je ne smeš kršiti. In login v gmail je ravno to.
Če ne pa prosim povej kako dobim seznam klicev iz moje telefonske številke. Lahko tudi samo tiste, ki sem jih klical sam. Noben ponudnik telefonije ti jih ne da =)

Zgodovina sprememb…

  • spremenilo: jukoz ()

jukoz ::

Invictus je izjavil:

Ni tako simple...

Sam sem 15 let nazaj lovil nekoga, ki je dnevno spraznil barvno kartušo s printanjem privat slik. In ga dobil.

Pravna služba se je že takrat odločila, da je zakonodaja preveč na strani uporabnika zaradi varstva osebnih podatkov. Danes je še hujše...

Edino kar lahko narediš je, da spremljaš kje ti zaposleni surfajo, in to blokiraš. Tukaj ne morejo nič. Seveda imaš pa danes za surfanje privat pametne telefone na katere težko vplivaš, ker so GSM motilci prepovedani.

It's not USA...


Tako je, lahko blokiraš, ne smeš pa gledat kaj delajo. S telefoni se je pa vse samo izboljšalo - vsi visijo na 4G in ne na tvoji mreži. To tudi svetujemo uporabnikom - privatne zadeve na privat napravah. Če je slab signal v firmi, se jih da na zunanji WiFi in naj tam brkljajo.

SeMiNeSanja je izjavil:

Invictus je izjavil:


Danes je še huje, ker imajo praktično vsi HP tiskalniki wifi, na katerega se brez problema priklopiš, pa ne vidiš, da bi IT sektor to izklopil in malo blokiral...

Ti posodim AccessPoint s katerim to prav komot blokiraš? :)

Tudi tu so se stvari v zadnjih letih precej premaknile, vendar moraš biti pripravljen malo globlje poseči v žep.

Sva z Matthai-em se nekaj pripravljala, da bi nekaj na to temo spentljala, pa se časovno še nisva nikamor premaknila.

Bistvo je to, da se accesspoint obnaša kot pes ovčar, ki se nauči katere ovčke so njegove, kje je ograda in kje prežijo nevarnosti. Potem pa ves čas spremlja, kaj počno njegove ovčke. Če hočejo preko ograde, jim pošilja disconnect pakete. Lahko jih postavi v karanteno, da se ne morejo povezati niti v lastni WiFi in podobno.

Če v takem okolju potem prižgeš neavtoriziran WiFi na tiskalniku, ti AP zlepa ne bo pustil, da se povežeš nanj, ker ga bo po default klasificiral kot rouge accesspoint. Pa še odjemalca, ki bi se hotel nanj povezat bo znal postaviti v karanteno, tko da ne bo preveč težko najti lumpa, ki je skušal izigrati pravila.


Kaj je to, nek samoučeči se MAC filtering?

Zgodovina sprememb…

  • spremenilo: jukoz ()

tony1 ::

Če nočeš poiskati odločbe IP, boš moral pač ostati mišljenja, da vsi po vrsti kršijo zakon.

Ne, ni. Gre za pošiljanje WIFI beaconov za odjavo iz APja klientom. Kar je verjetno prepovedano, ker gre za načrtno motenje nelicenčnega radijskega spektra. (In spet bomo brali vpitje.)

Invictus ::

jukoz je izjavil:


Tako je, lahko blokiraš, ne smeš pa gledat kaj delajo. S telefoni se je pa vse samo izboljšalo - vsi visijo na 4G in ne na tvoji mreži. To tudi svetujemo uporabnikom - privatne zadeve na privat napravah. Če je slab signal v firmi, se jih da na zunanji WiFi in naj tam brkljajo.

Sploh zaposleni nimajo kaj brkljat privat zadev v službi.

Tam so zato da delajo...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

jukoz ::

tony1 je izjavil:

Če nočeš poiskati odločbe IP, boš moral pač ostati mišljenja, da vsi po vrsti kršijo zakon.


tony1 je izjavil:


Ne, ni. Gre za pošiljanje WIFI beaconov za odjavo iz APja klientom. Kar je verjetno prepovedano, ker gre za načrtno motenje nelicenčnega radijskega spektra. (In spet bomo brali vpitje.)


0612-73/2009

Par citatov:
stran 2
"Pogodbeni obdelovalec je zavezancu predlagal, da se uporabnikom omrežja zavezanca predstavi, katere omejitve veljajo v omrežju zavezanca in kateri mehanizmi se izvajajo za zaščito in stabilno delovanje. V kolikor se uporabniki ne strinjajo s temi omejitvami, naj bi uporabljali npr. EDUROAM omrežje, kjer teh omejitev ni."

stran 3
"Zunanji izvajalec je RC Fakultete ****** svetoval pripravo varnostne politike, ki bi bila tudi osnova za pravila glede uporabe določenih funkcionalnosti. Ugotovljeno je bilo, da varnostne politike pri zavezancu niso posodobili ob prehodu s starih na nove požarne pregrade. Predstavnik ****** je opozoril, da sama funkcionalnost ni bila izvedena na uporabniku prikriti način, saj je moral uporabnik aktivno sprejeti ponujeni ceritifikat, sicer ni mogel nadaljevati z delom."

stran 5
"S tega vidika je uporaba tovrstne tehnologije lahko sporna, saj prihaja do trenj oziroma tehtanja med različnimi pravicami. Po eni strani pravice uporabnika omrežja zavezanca do razumne meje zasebnosti tudi na delovnem mestu, ki utemeljeno pričakuje zasebnost svoje korespondence in varstva osebnih podatkov, po drugi strani pa prav tako legitimne pravice zavezanca do varovanja svojega premoženja, konkretno varnosti lastnega omrežja, s tem posledično pa potencialno tudi zasebnosti drugih uporabnikov omrežja."

stran 6
"Ob odsotnosti varnostne politike, ki bi opredeljevala postopke ob nadgradnjah programske opreme je v konkretnem primeru prišlo do vključitve dodatne funkcionalnosti požarne pregrade in do obdelave osebnih podatkov, o kateri posamezniki niso bili obveščeni, prav tako pa je verjetno marsikateri uporabnik enostavno sprejel ponujeni certifikat požarne pregrade in s tem omogočil požarni pregradi nadzor vsebine kriptirane komunikacije, ne da bi se resnično zavedal namena in okoliščin nadzora. Iz navedenih vzrokov je bilo potrebno zavezancu naložiti sprejem ustrezne varnostne politike, s katero mora zavezanec utemeljiti razloge za vklop funkcionalnosti varnostne opreme, postopke nadgradnje varnostne opreme ter način obveščanja posameznikov o namenu in načinu delovanja te opreme."

Teorija: SeMiNeSanja direktorčku predstavi super funkcionalnost, da bo lahko odstranil kriptolokerje, ki jih uporabniki pobirajo po facebookih. Obenem ga obvesti, da bo lahko tudi gledal njihov promet in da se morajo zaposleni s tem strinjati. Direktorček je vesel in obvesti uporabnike. Ti se strinjajo in gremo veselo in varno naprej.

Realnost: SeMiNeSanja direktorčku predstavi super funkcionalnost, da bo lahko odstranil kriptolokerje, ki jih uporabniki pobirajo po facebookih. Obenem ga obvesti, da bo lahko tudi gledal njihov promet in da se morajo zaposleni s tem strinjati. Direktorček je vesel in obvesti uporabnike. Ti se delno strinjajo, ampak nočejo da se spremlja njihova zasebna komunikacija na banki, e-pošt in socialnih omrežjih. SeMiNeSanja mora, zato da dosega zasebnost korespondence, whitelistat 90% vsega prometa. Ponovno fašejo kriptolokerje. Lahko pa zablokira dostope do 90% vseh obiskanih strani. In ne dobijo kriptolokerja. So pa zaposleni sitni ker ne morejo gledati youtube in kdaj pa kdaj z jutub2mp3 potegnit kakšne pesmi dol.

Grša realnost: SeMiNeSanja direktorčku predstavi super funkcionalnost, da bo lahko odstranil kriptolokerje, ki jih uporabniki pobirajo po facebookih. Obenem ga obvesti (oz mu proda), da bo lahko tudi gledal njihov promet. Direktorček je vesel in to seveda kupi, uporabnike pa pozabi obvestiti. Uporabnik Matej ugotovi, da mu šnofljajo po mreži in naredi prijavo IPju. IP ugotovi da je bila kršena zasebnost korespondence uporabnikom in direktorčku naloži ustrezne ukrepe. Ker to ni prvič, dobi še kazen.


tony1 je izjavil:


Ne, ni. Gre za pošiljanje WIFI beaconov za odjavo iz APja klientom. Kar je verjetno prepovedano, ker gre za načrtno motenje nelicenčnega radijskega spektra. (In spet bomo brali vpitje.)


Hmm, če se klient hoče povezati na AP in mu zavračaš prijavo, zakaj bi bilo to prepovedano? Če bi mu nek tretji pošiljal deauth verjetno, če mu AP sam pa verjetno ne.

Invictus je izjavil:

jukoz je izjavil:


Tako je, lahko blokiraš, ne smeš pa gledat kaj delajo. S telefoni se je pa vse samo izboljšalo - vsi visijo na 4G in ne na tvoji mreži. To tudi svetujemo uporabnikom - privatne zadeve na privat napravah. Če je slab signal v firmi, se jih da na zunanji WiFi in naj tam brkljajo.

Sploh zaposleni nimajo kaj brkljat privat zadev v službi.

Tam so zato da delajo...


In da postanejo junaki socialističnega dela z izkopom več kot 152 ton premoga. Ali pa stipkajo vsaj 16.000 vrstic kode na dan. Sproducirajo 16 basni, 2 epa in zasadijo 300 gredic rož.

Zgodovina sprememb…

  • spremenilo: jukoz ()

tony1 ::

Tako je, to je prava odločba.

Klient se uspešno poveže na rogue AP1, firmin AP2 pa prejšnjim klientom pošilja odjavne beacone v takšni obliki, kot da jih je poslal rogue AP1. Gre za Rogue AP suppression funkcionalnost.

SeMiNeSanja ::

tony1 je izjavil:

Če nočeš poiskati odločbe IP, boš moral pač ostati mišljenja, da vsi po vrsti kršijo zakon.

Ne, ni. Gre za pošiljanje WIFI beaconov za odjavo iz APja klientom. Kar je verjetno prepovedano, ker gre za načrtno motenje nelicenčnega radijskega spektra. (In spet bomo brali vpitje.)

Je popolnoma legalno, če to delaš za SVOJE naprave, če svoje registrirane uporabnike disconnectaš od SSID-jev in AP-jev, ki niso avtorizirani.

Tu pa lahko tiči največji problem tovrstnih rešitev, ki je v ZDA neki hotelski verigi nakopal kazen v višini $600.000 - starejše rešitve so izredno šibke pri klasifikaciji kaj je moje in kaj ni moje, česa se smem 'dotikati', česa pa ne. Celo tako šibke, da je znan proizvajalec v svojih navodilih odsvetoval vklapljanje samodejne klasifikacije.

Kot rečeno, čas ni obstal, tako da so danes tovrstne rešitve že precej bolj pametne pri avtomatski klasifikaciji AP-jev in odjemalcev. Definitivno pa moraš zelo paziti, kaj delaš...

Kako je pri nas glede morebitnih kazni, če zadeve narobe skonfiguriraš in motiš omrežja sosedov, pa nimam pojma. Predvidevam, da so simbolične v primerjavi z ameriškimi - če te sploh kdaj doleti. Vendar to ne pomeni, da naj zdaj kar vsakdo na slepo vklaplja tovrstno funkcionalnost, tudi če mu jo AP podpira. Treba je zadevo prej dodobra potestirat v okolju, kjer ne moreš povzročiti kakšne resne štale. Šele ko ti je res jasno, kako stvar deluje, pa se jo loti načrtno implementirat v produkcijskem okolju.

Če koga tematika bolj podrobno zanima, si lahko pogleda Whitepaper_Classification_Detection_Prevention.pdf

SeMiNeSanja ::

Tista citirana odločba IP RS je iz 'nekih drugih časov', ko je bil delež https-a prometa kakšne 5-10x nižji kot danes, iz časa, ko se še nismo srečevali z izsiljevalskimi virusi, ko https še ni veljal za rizičnega pri distribuciji zlonamerne kode.

IP RS sicer izhaja iz načela sorazmernosti. Ta pa se je zaradi spremenjenih okoliščin tudi spremenila. Kat je bilo pred petimi leti za nekoga pretirano in paranoično, je danes 'must have', če nočeš jutri potegniti ta kratke.

V glavnem pa je ves problem pri odločbi (kolikor se spomnim...nisem jo šel še 1x prebirat) bil v implementaciji cele zgodbe in papirologiji - nikakor pa v sami tehnologiji.

Danes se v celo zgodbo vpleta še GDPR. Ampak tudi ta ne pravi, da "nenene fuj dekriptirat". Problematika zasebnosti namreč ni omejena le na https. Kar velja za kakršnokoli drugo logiranje prometnih podatkov velja tudi za https. Brez izjeme.

Tista omrežja, o katerih govori Jukoz, pa se mi zdijo kot ena sama velika anarhija, kjer očitno vsakdo lahko počne kar hoče. Najbrž zaposleni lahko tudi kakšen AP od doma prinesejo in ga nekaznovano priklopijo na mrežo, če je signal 'službenega' prešibek?

V takih omrežjih je najbolje, da jih zadane eno totalno sesutje, da jim zakriptirajo vse računalnike od prvega do zadnjega. Tako se uporabnikom nekako začne svitat, da tako pa morda res ne bo šlo naprej (mogoče pa nebi bilo slabo imeti nek 'fake ransomware', da bi fino prestrašil uporabnike?).

RAVNO zato, ker ima danes vsakdo v žepu mobitel, s katerim lahko opravi vse 'nujne' zasebne zadeve, lahko pričakujemo od uporabnikov razumevanje, da naj svoje 'občutljive zasebne stvari' ne počno na službenih računalnikih. Omogočimo jim uporabo guest WiFi omrežja s svojimi zasebnimi napravami, kjer se ne dekriptira prometa. Takointako pa tisti pretirano paranoični uporabljajo internet preko mobilnega omrežja.

Ostalo pa je izobraževanje uporabnikov. Bolj ko so seznanjeni z zadevami, manj je težav in 'upora'.

Drugače pa mogoče v takšnih anarhičnih okoljih tudi nebi škodoval kakšen obisk IP RS. Podjetje je pač dolžno ustrezno varovati zasebne podatke. Pri popolni anarhiji, pa to definitivno ne počne (backup ni varovanje osebnih podatkov!). Kazni sicer ne bo (predvidevam)...bo pa izdal kakšno priporočilo, ki bo odprlo pot do sprememb, tudi takšnih, ki so jih prej uporabniki blokirali. (sem preveč naiven?)
1
2
3 4


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Mikrotik T-2 IPTV IGMP Proxy

Oddelek: Omrežja in internet
3611252 (759) raceboy
»

Spreminjanje HTTP prometa v HTTPS/SSL

Oddelek: Omrežja in internet
51427 (1302) Vaseer
»

Intel GMA 3150 na Windows 8

Oddelek: Operacijski sistemi
61153 (889) rddezh9
»

[C#] Simobilov Glasnik

Oddelek: Programiranje
134150 (1230) Mrch
»

Nemški ponudniki dostopa do interneta morajo na zahtevo izbrisati prometne podatke

Oddelek: Novice / Zasebnost
63872 (3383) SavoKovac

Več podobnih tem