» »

Locky Virus

Locky Virus

1
2
»

darkolord ::

Slaba stran vitualiziranih rešitev je pomanjkanje strojne enkripcije, katero mora prevzeti CPU, ki ni specializiran za to opravilo.
Današnji CPUji imajo hardware acceleration za AES. Sem naredil benchmark na mojemu pa kriptira in dekriptira s 4 GB/s.

SeMiNeSanja ::

darkolord je izjavil:

Slaba stran vitualiziranih rešitev je pomanjkanje strojne enkripcije, katero mora prevzeti CPU, ki ni specializiran za to opravilo.
Današnji CPUji imajo hardware acceleration za AES. Sem naredil benchmark na mojemu pa kriptira in dekriptira s 4 GB/s.

V nekaterih okoljih zna biti 4Gbps premalo. Če npr. nekdo zahteva, da je ves WiFi promet kriptiran z SSL ali IPSec, se v malo večjem podjetju hitro prebije tudi 4Gbps.

Ampak realno gledano, pri 50 uporabnikih, te 'problematike' nebi smeli zaznati...

Invictus ::

jukoz je izjavil:

Od nekdaj - ker imajo pravico do zasebnosti tudi na delovnem mestu. Če se ji odrečejo sami je eno, prisiliti v to jih pa ne moreš.

Admin, ki mi to ni všeč, pa gre lahko delati drugam =)

Ko boš vedel kaj je to DPI, potem ne boš pisal bedarij ...

SeMiNeSanja je izjavil:


Iz prakse lahko rečem, da administratorji še veliko premalo gledajo analitiko prometa. Zato pogosto ne opazijo nenavadnega dogajanja na mreži in na koncu samo še igrajo vlogo gasilca.

Lahko potrdim.

Večina adminov misli da je ping serverja, če je živ, višek tehnologije nadzora ...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Zgodovina sprememb…

  • spremenil: Invictus ()

darkolord ::

SeMiNeSanja je izjavil:

darkolord je izjavil:

Slaba stran vitualiziranih rešitev je pomanjkanje strojne enkripcije, katero mora prevzeti CPU, ki ni specializiran za to opravilo.
Današnji CPUji imajo hardware acceleration za AES. Sem naredil benchmark na mojemu pa kriptira in dekriptira s 4 GB/s.

V nekaterih okoljih zna biti 4Gbps premalo. Če npr. nekdo zahteva, da je ves WiFi promet kriptiran z SSL ali IPSec, se v malo večjem podjetju hitro prebije tudi 4Gbps.

Ampak realno gledano, pri 50 uporabnikih, te 'problematike' nebi smeli zaznati...
4 GB/s. 32 Gbps.

Zgodovina sprememb…

  • spremenilo: darkolord ()

SeMiNeSanja ::

darkolord je izjavil:

SeMiNeSanja je izjavil:

darkolord je izjavil:

Slaba stran vitualiziranih rešitev je pomanjkanje strojne enkripcije, katero mora prevzeti CPU, ki ni specializiran za to opravilo.
Današnji CPUji imajo hardware acceleration za AES. Sem naredil benchmark na mojemu pa kriptira in dekriptira s 4 GB/s.

V nekaterih okoljih zna biti 4Gbps premalo. Če npr. nekdo zahteva, da je ves WiFi promet kriptiran z SSL ali IPSec, se v malo večjem podjetju hitro prebije tudi 4Gbps.

Ampak realno gledano, pri 50 uporabnikih, te 'problematike' nebi smeli zaznati...
4 GB/s. 32 Gbps.

Sorry - nisem bil pozoren na GB vs. Gbps.
Kako si pa 32Gbps stlačil čez network interface? Verjetno si to testiral med virtualnimi lani?

Spock83 ::

Kako se zbriše ta virus/trojanc? Sem poskeniral s Kaspersy Rescue DVDjem in našel par trojancev. Upam da je to to. No nekaj malega je bilo tudi v registru. Poskenirano z Malwarebytes.
Na srečo sem zadevo sem vrnil z shadow copy. Avast je bil začuda onemogočen. Drugače tak free antivirusnik bi ga moral zaznati oz blokirat izvajanje macrotov?

SeMiNeSanja ::

Če googlaš 'Locky removal' boš našel cel kup tutorialov.

Seveda bo odstranjevanje malenkost pozno, če ti je že zaklenil datoteke, ti pa nimaš backup-a.

jukoz ::

Invictus je izjavil:

jukoz je izjavil:

Od nekdaj - ker imajo pravico do zasebnosti tudi na delovnem mestu. Če se ji odrečejo sami je eno, prisiliti v to jih pa ne moreš.

Admin, ki mi to ni všeč, pa gre lahko delati drugam =)

Ko boš vedel kaj je to DPI, potem ne boš pisal bedarij ...

SeMiNeSanja je izjavil:


Iz prakse lahko rečem, da administratorji še veliko premalo gledajo analitiko prometa. Zato pogosto ne opazijo nenavadnega dogajanja na mreži in na koncu samo še igrajo vlogo gasilca.

Lahko potrdim.

Večina adminov misli da je ping serverja, če je živ, višek tehnologije nadzora ...


Thank you for your valuable feedback =)

Bi mi vseeno lahko kdo podal razlago (tudi link bo zelo dobrodošel) kako izvajati DPI na HTTPS prometu brez da bi dešifriral in ponovno šifriral komunikacijo (in bil FW s tem MITM)?

darkolord ::

Ne gre drugače.

SeMiNeSanja ::

jukoz je izjavil:


Thank you for your valuable feedback =)

Bi mi vseeno lahko kdo podal razlago (tudi link bo zelo dobrodošel) kako izvajati DPI na HTTPS prometu brez da bi dešifriral in ponovno šifriral komunikacijo (in bil FW s tem MITM)?

SEVEDA se https promet dešifrira - in tudi nazaj zašifrira.

Pri tipičnem MITM se uporabnika 'nategne' in njegov promet do 'napadalca' poteka kot navaden http promet.

KER se promet nazaj zašifrira in to ne na način, da bi se 'nategnilo' uporabnika, temveč tako, da uporabnik točno ve, kdo je bil vmes, da je bila to 'dovoljena' kontrola, si mora namestiti certifikat požarne pregrade ali podjetja, če smo na požarno pregrado namestili poseben certifikat podjetja. S tem se zagotovi, da ne more v promet posegati neka nepooblaščena tretja oseba, ne da bi uporabnik to zaznal.
Ravno tako se s tem zagotovi pravilno prikazovanje varnih spletišč z veljavnimi certifikati (zelena ključavnica v brskalniku) in ostalih ne-varnih spletišč z ne-veljavnimi certifikati (načeloma to že preveri požarna pregrada ampak prav je tudi, da se uporabniku pravilno prikaže v brskalniku).

Uporabnik, ki ne bo imel nameščenega ustreznega certifikata požarne pregrade bo pri vseh https komunikacijah dobil obvestilo o neveljavnih certifikatih. V tem primeru je seveda pravilno, da ne uporablja komunikacije ampak se pozanima za vzrok (lahko bi se šlo tudi za kaj drugega?) in namesti potrebni certifikat.

Enačenje DPI z MITM je na istem nivoju, kot inkvizicijsko preganjanje tistih, ki so trdili, da jemlja ni ravna plošča, da je krogla in bog ne daj, da si še trdil, da se vrti okoli sonca.

Stvar gre na isti nivo, kot če bi nekoga obtoževal, da je morilec, ker ima v kuhinji kuhinjske nože.

DPI NI zgolj pregledovanje kriptiranega https prometa. Pri požarnih pregradah DPI stoji za vse, kar preverja promet bolj detajlirano, kot navadna SPI požarna pregrada (port, source, destination). Marsikatera požarna pregrada izvaja DPI kontrolo prometa - pa ni sposobna dešifrirati in pregledovati https prometa! Zato je tako enačenje z MITM, ki se nanaša eksplicitno na https dekripcijo, popolni nonsense.

Z vidika varnosti je ua zporabnika pomembno, da je https promet pred in za požarno pregrado kriptiran in vanj ne more posegati nepooblaščena tretja oseba. Na sami požarni pregradi pa da same vsebine komunikacije, uporabniška imena (razen če se nahajajo v samem url-ju strani) in gesla (nikoli!) ne logiramo, oz. te možnosti sploh nimamo na voljo, tudi če bi jo želeli vključiti.

Danes poteka več kot 1/3 prometa preko https. Jutri bi že polovica, nekega dne morda ves spletni promet. Ne samo tisti do preverjenih spletišč - tudi tisti do spletišč s škodljivo kodo. Ravno zato, ker marsikdo niti ni zmožen preverjati https prometa in ustrezno blokirati izvršljive in potencialno nevarne datoteke, bo uporaba https protokola za distribucijo nesnage naraščala hitreje, kot uporaba https protokola na navadnih spletiščih - ker zagotavlja visoko verjetnost uspešne dostave na računalnik uporabnika.

Če si odgovorna oseba podjetja ali admin omrežja, pred tem dejstvom ne smeš vtakniti glave v pesek. Če se je pred 30 leti trobilo, da je AV na računalnikih nujno potreben in marsikomu ni bilo jasno zakaj, se zdaj zgodba ponavlja z DPI inšpekcijo in https dekripcijo. Če obstaja metoda, da se polovi škodljivo kodo predenj pride do računalnikov, ne sme biti nobenega pomisleka, da se jo uporabi.

Če ti pa tvoji uporabniki ne verjamejo, da se to dela dobronamerno in ne zato, da bi se jih špioniralo, potem imaš v podjetju zelo velike težave - pa ne z omrežjem, ampak z zaupanjem zaposlenih v poštenost vodstva podjetja. Tudi jaz nebi hodil k zdravniki, ki bi ga sumil, da mi naroča naj se razgalim, da bi se naslajal nad mojim golim telesom. V takem primeru delavci sumijo, da je vodstvo tisti perverzni zdravnik in morebiten 'upor' zoper poglobljeno kontroliranje prometa predstavlja samo vrh ledene gore problemov, ki so se v podjetju nakopičili. Pogosto jih lahko reši edino menjava vodstva, saj ta ne uživa zaupanja zaposlenih.

jukoz ::

SeMiNeSanja> SEVEDA se https promet dešifrira - in tudi nazaj zašifrira.

Hvala darklord in SeMiNeSanja.

SeMiNeSanja> ...

Hvala za skrb. Vseeno bi te prosil nekaj: glede na to da prodajaš opremo tudi za SMEje bi te prosil če lahko podaš okviren odstotek SME kupcev, pri katerih se naprednejše rešitve za spremljanje uporabnikov uporabljajo primarno za _spremljanje_ uporabnikov in ne za njihovo zaščito. Je to 20%? Je to 50%? Veš o čem govorim.

SeMiNeSanja ::

jukoz je izjavil:

SeMiNeSanja> SEVEDA se https promet dešifrira - in tudi nazaj zašifrira.

Hvala darklord in SeMiNeSanja.

SeMiNeSanja> ...

Hvala za skrb. Vseeno bi te prosil nekaj: glede na to da prodajaš opremo tudi za SMEje bi te prosil če lahko podaš okviren odstotek SME kupcev, pri katerih se naprednejše rešitve za spremljanje uporabnikov uporabljajo primarno za _spremljanje_ uporabnikov in ne za njihovo zaščito. Je to 20%? Je to 50%? Veš o čem govorim.

Razloži, kaj razumeš pod 'spremljanje uporabnikov'....

Do mene ni prišel še niti eden kupec, ki bi prvenstveno iskal orodje, s katerim bi lahko videl, po katerih spletiščih zaposleni brskajo med delovnim časom.

Prej obratno - večinoma jih opozarjam, da naj zaboga tudi malo pogledajo in spremljajo statistike, da lahko temu ustrezno prilagodijo 'nasvete uporabnikom' ali pa postavijo kakšne dodatne omejitve (saj ni treba vsega takoj prepovedat - lahko daš tudi 1/2 ure kvoto na Facebook). Zelo veliko 'normalizacije' prometa se da namreč doseči tudi po mehki plati. Ampak ne moreš pa stran gledat in pustiti, da se stvari razvijajo v napačno smer.
Če si prepovedal Dropbox v podjetju, potem tudi moraš izvajati nadzor nad tem, da ga ni kdo namestil. Saj ga ni treba koj kresniti po betici - morda se sploh ni zavedal, da stvar ni zaželjena. Ampak brez spremljanja ne boš vedel, da ga je kdo namestil, še manj pa kdo.

Če imaš dovolj fleksibilno rešitev, ti bo omogočala različne možnosti nastavitev, da ujameš tisti pravi balans med tem, kaj je uporabnikom treba omogočiti, kaj je še dopustno, če na eno oko zamižiš, kaj pa nikakor ne moreš dopustiti (npr. torrente, neke uporabnikove nepooblaščene VPN povezave, remote desktope brez nadzora,...). Ker zadeve niso statične, pač ne gre brez rednega spremljanja. Ne moreš enkrat nastaviti in vse skupaj pozabiti.

Tudi mi ni znan primer, da bi katera od mojih strank na osnovi spremljanja spletnega prometa grozila s kakšnimi sankcijami. Seveda pa ne morem izključiti takega primera. Koneckoncev je to popolnoma legitimna stvar, če nekdo krši politiko varnosti v podjetju, da se ga opozori. Če pa s kršitvami nadaljuje, pa so disciplinski ukrepi povsem logična posledica.

Sem pa mnenja, da se v primeru kršitve moraš pogovoriti z kršiteljem, da izveš zakaj je do kršitev pravil prišlo. Neredko se gredi zaposleni nekakšen 'Shadow IT' - sami skušajo reševati probleme, ki bi jih moral rešiti IT oddelek, ki pa nima časa ali posluha. Z dobrim razgovorom se lahko tudi najde alternative, kako bi se dalo takšne stvari rešiti na varen in kontroliran način in ne 'po domače'. Saj niso delavci vedno zgolj 'lenuhi, ki ves čas brskajo po spletu', pogosto so zgolj nevedni in naivni. Ravno spremljanje dogajanja, pa ti omogoči, da zaznaš takšno nevednost in naivnost ter ustrezno ukrepaš.

Ko sem pa že rekel, je tega spremljanja veliko premalo. Jaz bi si želel, da bi si admini vsaj enkrat na teden vzeli čas in pregledali tedenske statistike. A kaj, ko nikoli 'ni časa', vedno je kaj bolj 'pomembnega' za početi, pa še tako dolgočasno suhoparna so tista poročila...

darkolord ::

SeMiNeSanja je izjavil:

jukoz je izjavil:


Thank you for your valuable feedback =)

Bi mi vseeno lahko kdo podal razlago (tudi link bo zelo dobrodošel) kako izvajati DPI na HTTPS prometu brez da bi dešifriral in ponovno šifriral komunikacijo (in bil FW s tem MITM)?

SEVEDA se https promet dešifrira - in tudi nazaj zašifrira.

Pri tipičnem MITM se uporabnika 'nategne' in njegov promet do 'napadalca' poteka kot navaden http promet.

KER se promet nazaj zašifrira in to ne na način, da bi se 'nategnilo' uporabnika, temveč tako, da uporabnik točno ve, kdo je bil vmes, da je bila to 'dovoljena' kontrola, si mora namestiti certifikat požarne pregrade ali podjetja, če smo na požarno pregrado namestili poseben certifikat podjetja. S tem se zagotovi, da ne more v promet posegati neka nepooblaščena tretja oseba, ne da bi uporabnik to zaznal.
Ravno tako se s tem zagotovi pravilno prikazovanje varnih spletišč z veljavnimi certifikati (zelena ključavnica v brskalniku) in ostalih ne-varnih spletišč z ne-veljavnimi certifikati (načeloma to že preveri požarna pregrada ampak prav je tudi, da se uporabniku pravilno prikaže v brskalniku).

Uporabnik, ki ne bo imel nameščenega ustreznega certifikata požarne pregrade bo pri vseh https komunikacijah dobil obvestilo o neveljavnih certifikatih. V tem primeru je seveda pravilno, da ne uporablja komunikacije ampak se pozanima za vzrok (lahko bi se šlo tudi za kaj drugega?) in namesti potrebni certifikat.

Enačenje DPI z MITM je na istem nivoju, kot inkvizicijsko preganjanje tistih, ki so trdili, da jemlja ni ravna plošča, da je krogla in bog ne daj, da si še trdil, da se vrti okoli sonca.

Stvar gre na isti nivo, kot če bi nekoga obtoževal, da je morilec, ker ima v kuhinji kuhinjske nože.

DPI NI zgolj pregledovanje kriptiranega https prometa. Pri požarnih pregradah DPI stoji za vse, kar preverja promet bolj detajlirano, kot navadna SPI požarna pregrada (port, source, destination). Marsikatera požarna pregrada izvaja DPI kontrolo prometa - pa ni sposobna dešifrirati in pregledovati https prometa! Zato je tako enačenje z MITM, ki se nanaša eksplicitno na https dekripcijo, popolni nonsense.

Z vidika varnosti je ua zporabnika pomembno, da je https promet pred in za požarno pregrado kriptiran in vanj ne more posegati nepooblaščena tretja oseba. Na sami požarni pregradi pa da same vsebine komunikacije, uporabniška imena (razen če se nahajajo v samem url-ju strani) in gesla (nikoli!) ne logiramo, oz. te možnosti sploh nimamo na voljo, tudi če bi jo želeli vključiti.

Danes poteka več kot 1/3 prometa preko https. Jutri bi že polovica, nekega dne morda ves spletni promet. Ne samo tisti do preverjenih spletišč - tudi tisti do spletišč s škodljivo kodo. Ravno zato, ker marsikdo niti ni zmožen preverjati https prometa in ustrezno blokirati izvršljive in potencialno nevarne datoteke, bo uporaba https protokola za distribucijo nesnage naraščala hitreje, kot uporaba https protokola na navadnih spletiščih - ker zagotavlja visoko verjetnost uspešne dostave na računalnik uporabnika.

Če si odgovorna oseba podjetja ali admin omrežja, pred tem dejstvom ne smeš vtakniti glave v pesek. Če se je pred 30 leti trobilo, da je AV na računalnikih nujno potreben in marsikomu ni bilo jasno zakaj, se zdaj zgodba ponavlja z DPI inšpekcijo in https dekripcijo. Če obstaja metoda, da se polovi škodljivo kodo predenj pride do računalnikov, ne sme biti nobenega pomisleka, da se jo uporabi.

Če ti pa tvoji uporabniki ne verjamejo, da se to dela dobronamerno in ne zato, da bi se jih špioniralo, potem imaš v podjetju zelo velike težave - pa ne z omrežjem, ampak z zaupanjem zaposlenih v poštenost vodstva podjetja. Tudi jaz nebi hodil k zdravniki, ki bi ga sumil, da mi naroča naj se razgalim, da bi se naslajal nad mojim golim telesom. V takem primeru delavci sumijo, da je vodstvo tisti perverzni zdravnik in morebiten 'upor' zoper poglobljeno kontroliranje prometa predstavlja samo vrh ledene gore problemov, ki so se v podjetju nakopičili. Pogosto jih lahko reši edino menjava vodstva, saj ta ne uživa zaupanja zaposlenih.
Če se že o tem govori, se ne sme (ne glede na to, koliko ti to ni po godu) mimo tega, da potem tvoj UTM oz. DPI naprava glede varnosti potem postane šibka točka.

Če pade tak UTM, v istem trenutku pade še VSA ostala varna komunikacija (pošta, banke, ...) in zaščite - tudi antivirusi in vsa ostala zaščita na clientih.

Glede na to, da v zadnjih časih primeri backdoorov v enterprise rešitvah sploh niso neznani, to niti ni tako neverjetna možnost, da jo lahko kar ignoriraš.

Zgodovina sprememb…

  • spremenilo: darkolord ()

SeMiNeSanja ::

darkolord je izjavil:

Če se že o tem govori, se ne sme (ne glede na to, koliko ti to ni po godu) mimo tega, da potem tvoj UTM oz. DPI naprava glede varnosti potem postane šibka točka.

Če pade tak UTM, v istem trenutku pade še VSA ostala varna komunikacija (pošta, banke, ...) in zaščite - tudi antivirusi in vsa ostala zaščita na clientih.

Glede na to, da v zadnjih časih primeri backdoorov v enterprise rešitvah sploh niso neznani, to niti ni tako neverjetna možnost, da jo lahko kar ignoriraš.

ČE pade...

Kot prvo nihče ne gre kupovati bilokatero varnostno rešitev z predpostavko, da ima vgrajen backdoor.
Seveda pa obstaja tveganje, ki bi ga bilo nesmiselno zanikati.

Na tebi je, da pretehtaš, katero tveganje je večje - da te bo NSA špionirala, ali da bo nekdo od tvojih uporabnikov z neta zvlekel nek malware.

Koneckoncev pa ne boš nič na boljšem, če ti bo špijon nekje na internetu navesil TAP in tam prestrezal ves tvoj promet. Takointako pa ti večinoma raje podtaknejo trojančka, pa boš kmalu spet tam, da ga brez DPI in https dekripcije ne boš uspel 'zalotiti' in onemogočiti.

Katero zlo je potem tisto večje?

darkolord ::

Ne, seveda ne predpostavljaš, da ima backdoor. Ampak zato tudi ne daš eni rešitvi kar tako moči, da overrida (in onemogoči!) vse ostale.

Če špijon nekje prestreza moj enkriptiran promet, ne bo videl ničesar. Če bo kar koli spreminjal, bom jaz to na clientu videl.

Če nekdo z DPI rešitvijo prestreza moj enkriptiran promet, bo videl vse. Če bo karkoli spreminjal, jaz tega ne bom videl.

Vidim, da ne razumeš čisto, zakaj so sporni "NSA" backdoori. Ne samo zato, ker bi NSA poslušala. Ampak zato, ker če ta backdoor lahko uporablja NSA, ga lahko tudi kdorkoli drug, ki ga odkrije (ali kupi/ukrade).

Zgodovina sprememb…

  • spremenilo: darkolord ()

jukoz ::

SeMiNeSanja> Do mene ni prišel še niti eden kupec, ki bi prvenstveno iskal orodje, s katerim bi lahko videl, po katerih spletiščih zaposleni brskajo med delovnim časom.

Ampak rabi zaščito pred virusi in ostalo nadlogo. Če pa lahko spremlja ves promet zaposlenih je pa to bonus. Kolk procentom kupcev je to bonus. Tak, pomemben bonus, ki če ga ne bo ne bodo vzeli vse skupaj?

SeMiNeSanja>...

Glede Dropboxa, VPNjev, remote dostopov in podobnega. Za večino teh zadev se ve kam se povezujejo in se jih da blokirati. Lahko uporabiš proxy, ... Ni potrebe po DPIji in dekripciji HTTPS prometa.

Moje mnenje sicer je, da uporabnikom daš čim več svobode. Če opravljajo svoje delo in med tem visijo na facebooku, pa naj, koga briga. Če ne ga ne opravijo ... Pol bodo morali pa manj viseti na facebooku.

V meni znanih primerih se pa nikoli ni dobro končalo za delodajalca, če so zaposlenega dobili pri npr. odnašanju podatkov h konkurenci. Ko pride do disciplinskih postopkov taki zaposleni hitro najdejo dobre odvetnike. In je ceneje skleniti sporazumno odpoved. Druga opcija so gorile.

"Shadow IT"ja noben noče. Je pa problem če je IT preveč pameten in noče slišati težav s katerimi se soočajo uporabniki.


darkolord >Če pade tak UTM, v istem trenutku pade še VSA ostala varna komunikacija (pošta, banke, ...) in zaščite - tudi antivirusi in vsa ostala zaščita na clientih.

In naenkrat tvoj FW postane MITM napadalec.

SeMiNeSanja> Na tebi je, da pretehtaš, katero tveganje je večje - da te bo NSA špionirala, ali da bo nekdo od tvojih uporabnikov z neta zvlekel nek malware.

Problem nastane ko vgrajene backdoorje (spomni se Juniperja) začnejo uporabljati tudi drugi.

SeMiNeSanja ::

@Darklord - Če si v kategoriji strank z višjim tveganjem, pač postaviš dve različni požarni pregradi eno za drugo, ter izvajaš https dekripcijo na tisti ta 'zaščiteni'. Kar nekaj bank ima (tudi pri nas!) tako postavljene sisteme in to že desetljetja, ne šele od 'Juniper afere' naprej.

Kot sem rekel - vse skupaj je vprašanje ocene tveganja.

Toda kaj boš naredil, ko boš imel samo še https promet namesto http? Glavo vtaknil v pesek in upal, da ne bo noben zaposleni snel nekega hudiča z neta?

Če gledaš zdravila, imajo vsa neke možne nezaželjene stranske učinke - pa se boš zato odpovedal vsem zdravilom?

Kaj ti koristi če veš, da ti NSA ne more izkoristiti hipotetičnega backdoora, če se ti lahki izvršljiva koda, malware, trojanci, botnet klienti in še kaj nemoteno prenašajo in komunicirajo skozi požarno pregrado, ki ni sposobna opravljati svoje funkcije, ker je ves promet zakriptiran in sploh ne ve, kaj se skozi njo pretaka? Zakaj jo kar takoj ne vržeš proč in daš navaden switch, vsaj ne bo nepotrebnega zaviranja prometa.

Kolikokrat večja je verjetnost, da boš staknil trojanca, kot da se ponovi Juniper zgodbica? In kaj pravzaprav je lahko NSA v primeru Juniperja potegnila ven z naprave? Vgraditi backdoor v firewall, da bo iz spomina kopiral dekriptiran https promet, verjetno ni tako preprosta zadeva. Juniperjev backdoor je bil precej manj sofisticiran, tako da govorimo o znanstveni fantastiki, ne pa o nečem, kar bi bilo dejansko že kdaj videno.
Saj ne rečem - morda bo jutri tudi kdo tak backdoor kje odkril, ampak danes ga še ni!

deadbeef ::

Kot prvo veliko lahko rešiš če navadin uporabnikom odvzameš admin pravice in ufuraš AppLocker ali SRP (Software Restriction Policy) tako dejansko definiraš kaj se lahko execute-a na sistemu in kaj ne. S tem dobiš nazor in se znebiš nesnage kt bi jo drugače userji posrali po sistemu.

SeMiNeSanja ::

@Jukoz - glede na tvoja vprašanja, samo upam, da nisi delodajalec. Že samo to, da ti takšne stvari o kontroli delavcev hodijo po glavi, me namreč strašijo.

Daj razloži mi, kaj mi koristi požarna pregrada in logiranje, če ne morem pogledati, kdo vse je v zadnjem mesecu prejel mail z priponko invoice*.doc ?

Če objavijo, da je bila neka spletna stran pri nas okužena z drive-by download-om, bom hotel imeti možnost pogledat, če je kdo od mojih zaposlenih morda to stran obiskal, da bom lahko šel prekontrolirat njegov računalnik.

Kriminaliziraš stvari, ki so več kot koristne pri upravljanju omrežja in ljudem podtikaš najslabše možne namere.

Vsakdo ima svojo politiko dopustne rabe interneta. Lahko si še tako liberalen, pa še vedno obstajajo določene kategorije spletnih strani, katere ne želiš, da bi bile dostopne iz tvojega omrežja (known malware sites, botnet centrale,...).

Verjetno si tudi ne želiš, da bo vsak hote ali nehote vlekel exe, dll in kaj vem kakšne še datoteke iz interneta?

Kako pa boš potem nastavil stvari, kaj boš gledal in kako boš te informacije uporabil, pa je odvisno od TEBE. Če te ne zanima, ali Jaka ves dan visi na porno straneh, pač ne boš šel gledat statistike kategorij obiskanih spletnih strani, sploh pa ne boš šel gledat v podrobnosti, da bi videl, kdo je tisti pacek, ki ga plačuješ, da preveč uživa na delovnem mestu.

To je TVOJA stvar. Če to kdo drug počne z namenom, da bo koga odpustil, pa je to njegov problem - koneckoncev se s tem podaja na spolska tla in lahko faše celo kakšno ovadbo, ki mu bo, če nič drugega naredila precej preglavic, tudi če jo na koncu odnese brez kazni. Če kdo misli, da bo s tako statistiko zlahka nekoga odpustil, se tudi krepko moti. Stvar ni tako preprosta in samoumevna, kot bi si to kakšen delodajalec želel.

Ampak po drugi strani, če vidiš črno na belem, da ti nekdo nonstop brska po spletu, hkrati pa jamra, kako ima preveč dela, pa tudi ne moreš biti tiho in nič ukrepati.

So pa tu tudi precejšne razlike med podjetji glede na njihovo velikost. manjša kot so, bolj so statistike nepomembne.Potem pride neka velikost, kjer lahko to postane 'vabljivo', ko greš pa še bolj v velika podjetja, pa te samo še zanima tista skupna rekapitulacija, saj ti imena uporabnikov ne povedo kaj dosti in stvar s tem postane brezosebna. Karkoli delaš, takrat delaš v smeri, da se celokupno povprečje na nivoju podjetja popravi k večji storilnosti in k manj brezveznemu brskanju po spletu.

Brez logov pa si slep in slepo verjameš, da je vse v najlepšem redu. Dokler te enega dne ne predrami klic 'server ne dela...'. Sem zadnjič imel stranko, ki ni vedela, da ima Conflicker na strežniku, meni je pa v logih 'ven skakal', ko sem jim postavljal požarno pregrado. Pa so se ga lotili čistiti in mislili, da so ga odstranili - meni je pa v logih še vedno ven metalo, da skuša vzpostavljati povezave. Ups?

deadbeef je izjavil:

Kot prvo veliko lahko rešiš če navadin uporabnikom odvzameš admin pravice in ufuraš AppLocker ali SRP (Software Restriction Policy) tako dejansko definiraš kaj se lahko execute-a na sistemu in kaj ne. S tem dobiš nazor in se znebiš nesnage kt bi jo drugače userji posrali po sistemu.

Hja... whitelisting, blacklisting... o teh rečeh sem slišal zelo deljena mnenja s strani tistih, ki so to kdaj skušali vpeljati. Večinoma so obupali.

Zgodovina sprememb…

shadow7 ::

OK, razumem da je blacklisting v praksi neuporaben. Ampak zakaj bi obupali nad whitelistingom?
OK, so določene SLO specifike, zaradi katerih ima admin več dela (nadgradnja podpisnih komponent, FURS-ovi Silvestri). Ampak dokler se commercial-grade malware poganja z diska, je to vsekakor omembe vreden kamenček v mozaiku.

SeMiNeSanja ::

shadow7 je izjavil:

OK, razumem da je blacklisting v praksi neuporaben. Ampak zakaj bi obupali nad whitelistingom?
OK, so določene SLO specifike, zaradi katerih ima admin več dela (nadgradnja podpisnih komponent, FURS-ovi Silvestri). Ampak dokler se commercial-grade malware poganja z diska, je to vsekakor omembe vreden kamenček v mozaiku.

Saj ne rečem, imaš tudi solidne komercialne variante z močnim database-om zadaj (npr. Bit9) - ampak ne boš verjel: VEDNO se uporabljajo kot dodaten layer izza spodobne požarne pregrade. Pa zadeva ni niti malo poceni...

Samo ni mi čisto jasno, zakaj tak strah pred dekripcijo https-s.
Kot admin imaš takointako v roki škarje in platna, da določiš, katera so tista spletišča, ki bi ti predstavljala dodatno tveganje, če bi kaj leak-alo. Če so to zaupanja vredna spletišča, pač promet do njih ne dekriptiraš.

Tiste resnično 'problematične' strani, kjer uporabljaš tudi uporabniški certifikat (spletne banke, e-Uprava,..), pa takointako ne moreš pošiljati skozi dekripcijo.
Tako se na koncu vse skupaj skrči na spletišča, ki jim že v osnovi ne moreš zaupat, pa mislim, da ne bo ravno konec sveta, če bi se slučajno zgodilo, da bi kdaj kaj leak-alo.

Ves svet vse bolj prehaja na https dekripcijo, ker se zaveda, da postaja nuja. Ampak ja, vedno se bo našel nek skeptik. Samo ne potem jokat, ko fašete take in drugačne okužbe! Sami ste namreč presodili, da je to manjše zlo.

jukoz ::

SeMiNeSanja> @Jukoz - glede na tvoja vprašanja, samo upam, da nisi delodajalec. Že samo to, da ti takšne stvari o kontroli delavcev hodijo po glavi, me namreč strašijo.

Kot kaže imaš težave z bralnim razumevanjem. Poglejmo kaj sem napisal:
"Moje mnenje sicer je, da uporabnikom daš čim več svobode. Če opravljajo svoje delo in med tem visijo na facebooku, pa naj, koga briga. Če ne ga ne opravijo ... Pol bodo morali pa manj viseti na facebooku."

Pa nima veze, ker glede na zapisano razumeš kaj te sprašujem, samo odgovorit nočeš. Še enkrat: koliko odstotkom strank tvojih naprednih požarnih pregrad je bolj pomemben nadzor zaposlenih kot pa dejanska varnost omrežja. To vidiš tako, da v primeru da nimajo možnosti nenadzorovanega vpogleda v promet omrežja, niso zainteresirani za nakup. Običajno ti bo admin takega omrežja povedal nekaj v tem stilu: "Saj naš direktor je fajn in normalen, vseeno pa ima rad pregled nad delovanjem."

Zaradi tega sem proti tem da se dešifrira https povezave.
Ti kar spremljaj kam se povezujejo. In normalno je da si pozoren, ko ti ena mašina v omrežju pošilja ogromne količine podatkov na nek cloud, pa nima tam kaj početi. Verjetno nekaj ne bo OK, če prej tega ni počela. Ampak prometa pa po _moje_ ne greš dešifrirat. Želje in prakse drugih so pa seveda različne.

SeMiNeSanja ::

@Jukoz - za spremljanje katera spletišča kdo obiskuje, sploh ni potrebno dekriptirati https prometa - ima že header vse potrebne informacije!

Od mojih strank niti ena ni nabavila požarne pregrade zato, da bi vohljala za zaposlenimi, oz. je nebi kupila, če te možnosti nebi nudila. To se vidi tudi v okviru osnovnega izobraževanja za uporabo, ker se vprašanja tipa 'kako lahko izpišem katere spletne strani je obiskoval uporabnik xxx?' sploh ne pojavljajo.

Komur je namen vohljanje za zaposlenimi, to lahko počne ceneje, kot da si gre kupovati UTM požarno pregrado!

RedDrake ::

Jaz sem sicer bolj programerske branže, ampak administriram pa tudi omrežje za 2 majhni slo firmi (ena 6, druga 11 userjev).
- navaden SPI FW (oz. bolje rečeno router)
- dva identična strežnika
- clienti imajo vse podatke samo na strežniku
- primarni strežnik ima pol urne snapshote
- sekundar ima default FW rule da ne accepta _ničesar_, dovoljene so samo outbound povezave za potrebe sinhronizacije
- vsak client ima na fizično odklopljenem disku mirror trenutnega stanja
- 1x na teden delam še backup na oddaljeno lokacijo, kjer imam poleg podatkov na strežnikih tudi offline podatke na različnih nosilcih za 2 meseca nazaj

pros:
+ 99,99% bulletproof, tudi če ti client prinese USB z vsem možnim malwareom (ok, možen bi bil kak malware, ki bi iskal luknjo v *nix network stacku, da bi hacknil še sekundarni strežnik, ampak to bi bila custom tailored zadeva, seems unlikely ...)
+ podatkov se ne da izgubiti
+ vse-v-enem rešitev (proti virusom, neumnim uporabnikom, ki sami uničijo podatke/računalnik, požaru/fizičnemu uničenju stavbe)
+ clienti sploh nimajo AV SW-ja ali FW-ja ali česarkoli
+ SW cena je nižja (licence samo za client OS + productivity SW, ki ga dejansko rabi)
+ karkoli crkne (HW ali SW) je menjava oz. popravilo max 5 min.

cons:
- več dela pri dodajanju SW opreme clientom (priklopiti disk, narediti upgrade, nov image, stestirati, odlopiti, ...)
- dela z administracijo je več, sploh ker vse teče na mojih lastnih skriptah

mogoče še kaj kar jaz ne vidim?

Zgodovina sprememb…

  • spremenil: RedDrake ()

SeMiNeSanja ::

RedDrake je izjavil:

mogoče še kaj kar jaz ne vidim?


a) v bistvu takšna zadeva pokriva zgolj disaster recovery, ne pa tudi disater prevention (nimajo AV?!? Niti Windows Defender?!?)

b) kako preprečiš, da tisti 'mirror server' ne bo z primarnega potegnil že okužene datoteke (zakriptirane?) in z njimi povozil zdrave na mirrorju? Imaš vsaj še kakšna dva dnevna backup-a, da bi lahko posegel po 2 dneva stari verziji, če prepozno ugotoviš, da so se podatki sesuli?

Worst case scenarij: okužba se zgodi v petek na koncu šihta. Datoteke na primarcu se z nekajurno zamudo zašifrirajo ob 10h zvečer (danes se malware zna tudi potuhniti). Ob 10.30 so datoteke na mirror serverju povožene z kriptiranimi datotekami. Ob 00.00 se zalaufa cloud backup. Povozijo se zdrave datoteke v oblaku.

V ponedeljek zjutraj pridejo na šiht... in ugotovijo, da je 'backup' odlično deloval....

Vsekakor upam, da imaš kakšno varovalko, da se tak scenarij ne more zgoditi, saj si sicer vložil ogromno truda v nič.

Nekateri malware-i so tako potuhnjeni, da se bodo skrivali vse dokler ne bo z veliko verjetnostjo okužena tudi cloud backup kopija. Zato ni slabo, če znaš pravočasno ugotoviti okužbo in preprečiti, da bi se povozilo backup kopijo.

Če se že gremo home-grown variante, se na vsakem računalniku nahaja več map, katerih vsebina je 'arhivske narave' - se ne dodaja in se ne spreminja.
Če v takih mapah narediš checksum in ga zapišeš v posebno datoteko, potem lahko pred pričetkom kopiranja s svojo skripto preveriš, če se checksum še ujema. Če se ne, zaustaviš kopiranje in udariš alarm. Če imaš ene 5 - 10 takih map raztresenih po celem disku, boš z kar nekaj verjetnost uspel zaznati, da je prišlo do nenavadnih sprememb. Lahko bi celo v sistemki mapi imel checksum. Ta se bi sicer spremenil ob vsaki posodobitvi sistema, vendar ga nebi smelo biti problem ponastavjati ob vsakokratnem zagonu sistema.

c) pozabil si na BYOD - Tudi če imaš vse ostalo diskless workstation-e, imaš še vedno posamezne prenosnike, tablice in nenazadnje telefone, ki jih tvoj home-grown disaster recovery ne pokriva.

d) Veliko malware-a je botnet tipa. Uporabnik sploh ne bo zaznal, da ga je staknil, medtem pa na veliko pošilja spam v svet, sodeluje v DDOS napadih in podobno. Ponavadi to ugotovijo šele takrat, ko dobijo klic od providerja, da jih bo začasno odklopil od interneta, če takoj ne ukrepajo.

Tvoj disaster recovery (predvidevam) odlično deluje, če se mašina v hipu sesuje. Problematičen pa je pri vseh kompromitacijah, ki se ne opazijo takoj in se lahko v ozadju dogajajo tudi tedne. Takrat pa bo težko povrniti čisto kopijo sistema - vsaj na strežnikih, če že ima vsak klient svoj lastni backup na odklopljenem disku. Lahko se ti zgodi, da boš moral strežnika reinštalirati, da bi se znebil okužbe.

Torej smo spet pri pravočasnem zaznavanju problemov, ki ti omogoči, da izkoristiš prednost svojega disaster recovery-ja.

AV na klientih in strežniku, bo zagotovo nekoliko pripomogel k bolj zgodnem odkrivanju okužbe. Vendar pa imaš variante, kot npr. Conflicker, ki zelo uspešno izključijo nameščeni AV proizvod.

Tu potem lahko dodaš še tisti layer dodatne zaščite, ki ti ga lahko nudi napredna požarna pregrada, ki te bo ob pravilni konfiguraciji znala opozoriti, da imaš na mreži nekaj, kar skuša komunicirati na način, ki ni običajen. Ponavadi rabim samo pogledati, katere povezave notranjih IP naslovov sem največkrat blokiral - medtem ko imaš na povprečnem klientu kakšnih 10-100 blokiranih povezav na dan, ti okuženi skačejo ven iz statistike z 500 do več tisoč blokiranimi povezavami. Če zgolj to statistiko spremljaš, boš točno vedel, kje se nekaj kuha.

Miha 333 ::

SeMiNeSanja je izjavil:

RedDrake je izjavil:

mogoče še kaj kar jaz ne vidim?


a) v bistvu takšna zadeva pokriva zgolj disaster recovery, ne pa tudi disater prevention (nimajo AV?!? Niti Windows Defender?!?)

b) kako preprečiš, da tisti 'mirror server' ne bo z primarnega potegnil že okužene datoteke (zakriptirane?) in z njimi povozil zdrave na mirrorju? Imaš vsaj še kakšna dva dnevna backup-a, da bi lahko posegel po 2 dneva stari verziji, če prepozno ugotoviš, da so se podatki sesuli?

Worst case scenarij: okužba se zgodi v petek na koncu šihta. Datoteke na primarcu se z nekajurno zamudo zašifrirajo ob 10h zvečer (danes se malware zna tudi potuhniti). Ob 10.30 so datoteke na mirror serverju povožene z kriptiranimi datotekami. Ob 00.00 se zalaufa cloud backup. Povozijo se zdrave datoteke v oblaku.

V ponedeljek zjutraj pridejo na šiht... in ugotovijo, da je 'backup' odlično deloval....

Vsekakor upam, da imaš kakšno varovalko, da se tak scenarij ne more zgoditi, saj si sicer vložil ogromno truda v nič.

Nekateri malware-i so tako potuhnjeni, da se bodo skrivali vse dokler ne bo z veliko verjetnostjo okužena tudi cloud backup kopija. Zato ni slabo, če znaš pravočasno ugotoviti okužbo in preprečiti, da bi se povozilo backup kopijo.

Če se že gremo home-grown variante, se na vsakem računalniku nahaja več map, katerih vsebina je 'arhivske narave' - se ne dodaja in se ne spreminja.
Če v takih mapah narediš checksum in ga zapišeš v posebno datoteko, potem lahko pred pričetkom kopiranja s svojo skripto preveriš, če se checksum še ujema. Če se ne, zaustaviš kopiranje in udariš alarm. Če imaš ene 5 - 10 takih map raztresenih po celem disku, boš z kar nekaj verjetnost uspel zaznati, da je prišlo do nenavadnih sprememb. Lahko bi celo v sistemki mapi imel checksum. Ta se bi sicer spremenil ob vsaki posodobitvi sistema, vendar ga nebi smelo biti problem ponastavjati ob vsakokratnem zagonu sistema.

c) pozabil si na BYOD - Tudi če imaš vse ostalo diskless workstation-e, imaš še vedno posamezne prenosnike, tablice in nenazadnje telefone, ki jih tvoj home-grown disaster recovery ne pokriva.

d) Veliko malware-a je botnet tipa. Uporabnik sploh ne bo zaznal, da ga je staknil, medtem pa na veliko pošilja spam v svet, sodeluje v DDOS napadih in podobno. Ponavadi to ugotovijo šele takrat, ko dobijo klic od providerja, da jih bo začasno odklopil od interneta, če takoj ne ukrepajo.

Tvoj disaster recovery (predvidevam) odlično deluje, če se mašina v hipu sesuje. Problematičen pa je pri vseh kompromitacijah, ki se ne opazijo takoj in se lahko v ozadju dogajajo tudi tedne. Takrat pa bo težko povrniti čisto kopijo sistema - vsaj na strežnikih, če že ima vsak klient svoj lastni backup na odklopljenem disku. Lahko se ti zgodi, da boš moral strežnika reinštalirati, da bi se znebil okužbe.

Torej smo spet pri pravočasnem zaznavanju problemov, ki ti omogoči, da izkoristiš prednost svojega disaster recovery-ja.

AV na klientih in strežniku, bo zagotovo nekoliko pripomogel k bolj zgodnem odkrivanju okužbe. Vendar pa imaš variante, kot npr. Conflicker, ki zelo uspešno izključijo nameščeni AV proizvod.

Tu potem lahko dodaš še tisti layer dodatne zaščite, ki ti ga lahko nudi napredna požarna pregrada, ki te bo ob pravilni konfiguraciji znala opozoriti, da imaš na mreži nekaj, kar skuša komunicirati na način, ki ni običajen. Ponavadi rabim samo pogledati, katere povezave notranjih IP naslovov sem največkrat blokiral - medtem ko imaš na povprečnem klientu kakšnih 10-100 blokiranih povezav na dan, ti okuženi skačejo ven iz statistike z 500 do več tisoč blokiranimi povezavami. Če zgolj to statistiko spremljaš, boš točno vedel, kje se nekaj kuha.

Pri nas zato delamo read-only snapshote, na primer urno, ki se hranijo 3 dni, dnevno za zadnjih 7 dni, tedensko za zadnje 4 tedne, mesečno za zadnjih 12 mesecev, letni hranjeni trajno. Na primarnem strežniku za shrambo ter replicirano na oddaljeni backup strežnik. Delamo pa to na nivoju FS-ja (uporabljamo ZFS, ki se BTW za te zadeve odlično obnese).

Pride prav tudi, če uporabnik kaj po pomoti pobriše/povozi, ker ima v windows explorerju - desni klik - lastnosti - prejšnje različice na voljo vse te snapshote.

Zgodovina sprememb…

  • spremenilo: Miha 333 ()

RedDrake ::

@SeMiNeSanja:
Hvala za izčrpen odgovor.
Ja res je, to je bolj disaster recovery.
Ampak recimo na cryptolocker (in izpeljanke, kar je tudi tole) je tak sistem popolnoma odporen, že z enim samim strežnikom.
Kot je napisal tudi Miha 333, gre za read only incremental backup, kar pomeni da če se clientu nekaj zakodira, se zakodira kopija, original pa ostane tak kot mora biti, kot napisano delam pol urne incrementale med delovnim časom (7-17h), dnevne ob koncu dneva in tedenske.
Ker podatki niso tako grozno občutljivi, ni recimo letnega forever backupa, kot ga ima Miha 333
Sekundarja sploh malware ne more okužiti in je v bistvu drop-in replacement primarja, če pride tam do težav (HW ali SW failure).
Tako da strežniki in podatki so secure.
BYOD ni issue pri teh firmah, večinoma zaposleni niti slučajno nočejo dela nositi domov (niso IT firme), tako da tega tam afaik ni.
APji za wifi (vsi workstationi so wired) so na lastnem VLANu in so ločeni od "business" mreže.

Problem je, na katerega dejansko nisem pomislil (ker sam tudi ne uporabljam AV-ja) razni trojanci in botneti.
Verjetno vsaj neka osnovna AV zaščita ne bi bila slaba, predvsem iz vidika varovanja interneta :)

Miha 333, bi se priporočal za kak dober dokument/tutorial/namig o tem ZFS-ju in desni klik v explorerju, tole se sliši dobro. Trenutno, ker so firme majhne uporabljam čisto navaden ext4 za podatke, backup pa je potrebno najti na posebnem shareu (jasno read only), ampak tak fičr bi bil gotovo zelo priljubljen (saj je raznih napačnih save-ov in podobnih bedarij vedno dovolj ...).

SeMiNeSanja ::

Kadar je govora o varovanju omrežij, je bilo v lanskem letu precej govorjenja o tzv. Cyber Security Kill Chain-u.

Pojem je nastal v Lockheed Martin-u, so ga pa zelo hitro pograbili praktično vsi ponudniki varnostnih rešitev, saj opisuje faze tipičnega cybernapada in vsakemu proizvajalcu nudi možnost ponazoritve, kako lahko njegova rešitev pomaga pri določeni fazi.
Razumevanje Cyber Security Kill Chain-a je izrednega pomena tudi za vsakogar, ki se ukvarja z zaščito omrežij. Bolje kot razumeš sovražnika in njegov pristop, lažje se boš branil proti njemu. Bolje kot poznaš Kill Chain, bolj se boš zavedal, kje imaš šibke točke in poskusil najti način, da jih odpraviš.

Invictus ::

SeMiNeSanja je izjavil:

Kadar je govora o varovanju omrežij, je bilo v lanskem letu precej govorjenja o tzv. Cyber Security Kill Chain-u.

Pojem je nastal v Lockheed Martin-u, so ga pa zelo hitro pograbili praktično vsi ponudniki varnostnih rešitev, saj opisuje faze tipičnega cybernapada in vsakemu proizvajalcu nudi možnost ponazoritve, kako lahko njegova rešitev pomaga pri določeni fazi.
Razumevanje Cyber Security Kill Chain-a je izrednega pomena tudi za vsakogar, ki se ukvarja z zaščito omrežij. Bolje kot razumeš sovražnika in njegov pristop, lažje se boš branil proti njemu. Bolje kot poznaš Kill Chain, bolj se boš zavedal, kje imaš šibke točke in poskusil najti način, da jih odpraviš.

Glede na to, da so jim Kitajci spizdili načrte za F-35, so se tega sigurno resno lotili ;).
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

SeMiNeSanja ::

Invictus je izjavil:

Glede na to, da so jim Kitajci spizdili načrte za F-35, so se tega sigurno resno lotili ;).

Temu se reče učenje na napakah ;((
Koliko so se na koncu dejansko naučili, bo pa treba kitajce vprašat 8-O

deadbeef ::

RedDrake je izjavil:

Jaz sem sicer bolj programerske branže, ampak administriram pa tudi omrežje za 2 majhni slo firmi (ena 6, druga 11 userjev).
- navaden SPI FW (oz. bolje rečeno router)
- dva identična strežnika
- clienti imajo vse podatke samo na strežniku
- primarni strežnik ima pol urne snapshote
- sekundar ima default FW rule da ne accepta _ničesar_, dovoljene so samo outbound povezave za potrebe sinhronizacije
- vsak client ima na fizično odklopljenem disku mirror trenutnega stanja
- 1x na teden delam še backup na oddaljeno lokacijo, kjer imam poleg podatkov na strežnikih tudi offline podatke na različnih nosilcih za 2 meseca nazaj

pros:
+ 99,99% bulletproof, tudi če ti client prinese USB z vsem možnim malwareom (ok, možen bi bil kak malware, ki bi iskal luknjo v *nix network stacku, da bi hacknil še sekundarni strežnik, ampak to bi bila custom tailored zadeva, seems unlikely ...)
+ podatkov se ne da izgubiti
+ vse-v-enem rešitev (proti virusom, neumnim uporabnikom, ki sami uničijo podatke/računalnik, požaru/fizičnemu uničenju stavbe)
+ clienti sploh nimajo AV SW-ja ali FW-ja ali česarkoli
+ SW cena je nižja (licence samo za client OS + productivity SW, ki ga dejansko rabi)
+ karkoli crkne (HW ali SW) je menjava oz. popravilo max 5 min.

cons:
- več dela pri dodajanju SW opreme clientom (priklopiti disk, narediti upgrade, nov image, stestirati, odlopiti, ...)
- dela z administracijo je več, sploh ker vse teče na mojih lastnih skriptah

mogoče še kaj kar jaz ne vidim?


+ 99,99% bulletproof my ass.... en spear phishing attack in ti pokradejo vse zadeve kar imate intelektualne lastnine, tko da se sploh zavedal ne boš da so bli znotraj mreže.

Uglavm iz security point-a katastofalen setup... tipičen v večini slovenskih podjetji

SeMiNeSanja ::

deadbeef je izjavil:


+ 99,99% bulletproof my ass.... en spear phishing attack in ti pokradejo vse zadeve kar imate intelektualne lastnine, tko da se sploh zavedal ne boš da so bli znotraj mreže.

Uglavm iz security point-a katastofalen setup... tipičen v večini slovenskih podjetji

Tako črno spet ni - imajo vsaj nek osnovni disaster recovery plan - s tem se tudi ne more pohvaliti vsako podjetje.

Je pa res, da nima POPOLNOMA nobene zaščite pred odtekanjem podatkov in 'sodelovanjem' v botnetih.

Tu še toliko bolj pride do izraza kontrast med razumevanjem varnosti pri enih in drugih. Eni se ne sekirajo, če jim vse podatke prekopirajo, drugi pa skačejo v zrak, češ da bo NSA zagotovo vgradila backdoor v požarno pregrado, ki bo omogočal odtekanje dekriptanih SSL podatkov.

Na koncu se pa nebi sploh čudil, če je pri komu, ki vpije, kako bo NSA preko backdoora kradla podatke, 'varnost' postavljena točno tako, kot v zgornjem primeru. Presneti trolli...

jukoz ::

deadbeef je izjavil:

RedDrake je izjavil:

Jaz sem sicer bolj programerske branže, ampak administriram pa tudi omrežje za 2 majhni slo firmi (ena 6, druga 11 userjev).
- navaden SPI FW (oz. bolje rečeno router)
- dva identična strežnika
- clienti imajo vse podatke samo na strežniku
- primarni strežnik ima pol urne snapshote
- sekundar ima default FW rule da ne accepta _ničesar_, dovoljene so samo outbound povezave za potrebe sinhronizacije
- vsak client ima na fizično odklopljenem disku mirror trenutnega stanja
- 1x na teden delam še backup na oddaljeno lokacijo, kjer imam poleg podatkov na strežnikih tudi offline podatke na različnih nosilcih za 2 meseca nazaj

pros:
+ 99,99% bulletproof, tudi če ti client prinese USB z vsem možnim malwareom (ok, možen bi bil kak malware, ki bi iskal luknjo v *nix network stacku, da bi hacknil še sekundarni strežnik, ampak to bi bila custom tailored zadeva, seems unlikely ...)
+ podatkov se ne da izgubiti
+ vse-v-enem rešitev (proti virusom, neumnim uporabnikom, ki sami uničijo podatke/računalnik, požaru/fizičnemu uničenju stavbe)
+ clienti sploh nimajo AV SW-ja ali FW-ja ali česarkoli
+ SW cena je nižja (licence samo za client OS + productivity SW, ki ga dejansko rabi)
+ karkoli crkne (HW ali SW) je menjava oz. popravilo max 5 min.

cons:
- več dela pri dodajanju SW opreme clientom (priklopiti disk, narediti upgrade, nov image, stestirati, odlopiti, ...)
- dela z administracijo je več, sploh ker vse teče na mojih lastnih skriptah

mogoče še kaj kar jaz ne vidim?


+ 99,99% bulletproof my ass.... en spear phishing attack in ti pokradejo vse zadeve kar imate intelektualne lastnine, tko da se sploh zavedal ne boš da so bli znotraj mreže.

Uglavm iz security point-a katastofalen setup... tipičen v večini slovenskih podjetji


Še en valuable input v to temo =)

Drugače bolj tipičen setup in respons je: Juniper ima hardkodan backdoor v FW - admin skomigne z rameni in reče "takle mamo"

jukoz ::

SeMiNeSanja> Na koncu se pa nebi sploh čudil, če je pri komu, ki vpije, kako bo NSA preko backdoora kradla podatke, 'varnost' postavljena točno tako, kot v zgornjem primeru. Presneti trolli...

Najdi kateregakoli nepopačanga Junipera s ScreenOS 6.2.0r15 - 6.2.0r18 ali 6.3.0r12 - 6.3.0r20.
u: admin
p: boš našel na netu, konča se z %u

Aja, išči "juniper backdoor password"

Bravo, postal si NSA superduper secret spy

Zgodovina sprememb…

  • spremenilo: jukoz ()

SeMiNeSanja ::

jukoz je izjavil:

SeMiNeSanja> Na koncu se pa nebi sploh čudil, če je pri komu, ki vpije, kako bo NSA preko backdoora kradla podatke, 'varnost' postavljena točno tako, kot v zgornjem primeru. Presneti trolli...

Najdi kateregakoli nepopačanga Junipera s ScreenOS 6.2.0r15 - 6.2.0r18 ali 6.3.0r12 - 6.3.0r20.
u: admin
p: boš našel na netu, konča se z %u

Aja, išči "juniper backdoor password"

Bravo, postal si NSA superduper secret spy

Pa nisem jaz kriv, če ljudje:
a) kupujejo 'varnostne rešitve' - brez maintenance-a
b) ne nameščajo popravkov, ko so ti na voljo
c) tako bedno administrirajo firewall-e, da dovolijo dostop do managementa preko WAN interface-a in to kar brez VPN ali kakršnekoli druge dodatne zaščite.
d) da upravljajo VARNOSTNE rešitve ljudje, ki nimajo niti približne predstave o osnovnih načelih varnosti v omrežjih

jukoz ::

Nisi ti kriv. Kriv je sistem: http://pro.finance.si/8841317/%28Interv...

"Toda ljudje, ki jim je IT-varnost služba, menda že vedo, kaj deluje in kako?

Mislite? Se ne strinjam. Ena večjih težav je, da danes tudi zaposleni v IT zgolj hodijo v službo, kjer se bojujejo z zahtevami nadrejenih in uporabnikov ter internetnimi nevarnostmi. Konec dneva želijo predvsem preživeti. Težava je v tem, da si niti prizadevajo ne več za spremembe."

In potem ti reče admin "takle mamo" ali pa "company policy". Ker imajo poln kufer sranja tako ali tako in če je kriv proizvajalec potem niso krivi oni.

SeMiNeSanja ::

jukoz je izjavil:

Nisi ti kriv. Kriv je sistem: http://pro.finance.si/8841317/%28Interv...

"Toda ljudje, ki jim je IT-varnost služba, menda že vedo, kaj deluje in kako?

Mislite? Se ne strinjam. Ena večjih težav je, da danes tudi zaposleni v IT zgolj hodijo v službo, kjer se bojujejo z zahtevami nadrejenih in uporabnikov ter internetnimi nevarnostmi. Konec dneva želijo predvsem preživeti. Težava je v tem, da si niti prizadevajo ne več za spremembe."

In potem ti reče admin "takle mamo" ali pa "company policy". Ker imajo poln kufer sranja tako ali tako in če je kriv proizvajalec potem niso krivi oni.

Na žalost trditve iz intervjuja še kako držijo.

Mene je v IT pripeljal firbec in sem še danes, po 30 letih firbčen. Sicer ne več v tako širokem spektru - sem pač našel svojo nišo, ki me je pritegnila.

Čeprav 'prisegam' na WatchGuard, vseeno grem pogledat, kaj ponujajo SonicWall, Fortinet, Sophos,...., na tem področju, predvsem z vidika upravljanja.
Razlike so lahko gromozanske med različnimi implementacijami, od 'bog se usmili', pa do 'tole bi pa tudi jaz imel'.

Nikoli mi pa ne bo jasno, da tako zelo malo adminov pred nakupom nove rešitve ne gre pogledat, kaj dejansko nudijo različne rešitve, ki so na voljo na trgu.
Datasheet-i ti tega namreč ne povedo, če boš VPN vzpostavil v 1 min, ali se boš s tem zezal pol ure. Tudi ti ne povedo, koliko časa boš potreboval od klica uporabnika 'meni pa aplikacija xxx ne deluje' do uspešno dodanega pravila, da bo ta aplikacija delovala.

Dejansko jih vse več zgolj 'hodi v službo' in so izgubili tisti zdravi firbec, ki je v tem poslu potreben, da ostaneš na tekočem z razvojem tehnologije in ponudbo na trgu. Po neki inerciji kupujejo najdražje rešitve (pri tej ceni ne moreš kaj dosti kiksniti, ziher je top?), ne da bi se prepričali, če ne preplačujejo vse skupaj za 2-3x. Imajo svoje dvorne dobavitelje, in se obnašajo kot priden kuža, ki požre vse, kar mu gospodar nasuje v skledo. "Če bo šlo kaj narobe, bo že dobaviteljev support rešil stvar"?

Potem pa hodijo na razne "Risk" in podobne konference. Da bi se kaj novega naučili? Jok! Ker imajo fine žurke zvečer, ker delodajalec plača malo sprostitve. Ker se počutijo pomembne, saj so v elitni druščini kolegov, ki se med seboj prepričujejo, da imajo najboljšo rešitev. Bognedaj, da zamenjajo rešitev. Koliko bi to bilo enega dela. Nič ekstra plačano. Spet se učiti od nule. Opravljeni izpiti na enkrat brez vrednosti. Pa še na konferenci boš kar na enkrat postal 'outsider'. Ne boš več spadal med 'elito', če nimaš šminkerske rešitve!

Jap. Takle mamo!

waterbike ::

Zdravo,

ali ima kdo izkušnje, koliko dni po okužbi lahko še zaprosiš za dešifrirno geslo?

lp

Manna ::

običajno v 7 dneh
znesek (Euro 200) se potem poveča

http://myspybot.com/decrypt-locky-files/

Zgodovina sprememb…

  • spremenila: Manna ()
1
2
»


Vredno ogleda ...

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

Crypto AG: umazana obveščevalna zgodba bajnih zaslužkov (strani: 1 2 3 )

Oddelek: Novice / NWO
12327399 (17731) poweroff
»

V letu 2016 bistveno več šifriranega prometa

Oddelek: Novice / Zasebnost
258365 (6235) Lonsarg
»

CTB locker (cryptolocker) (strani: 1 2 )

Oddelek: Informacijska varnost
7524375 (16852) AC_DC
»

VPN in oddaljene pisarne (strani: 1 2 )

Oddelek: Omrežja in internet
6813188 (11522) SeMiNeSanja
»

Kateri router za podjetje 20 ljudi (od tega 10 IT - intenzivni uporabniki)? (strani: 1 2 3 )

Oddelek: Omrežja in internet
10721261 (18238) NeMeTko

Več podobnih tem