A Graph Search-sztori

A téma, amiről néha úgy gondolom, hogy már nem lehet több bőrt lenyúzni, aztán rájövök, hogy mégis. Ha valaki nagyon lemaradt volna, a Graph Search egyszerűsítve a Facebook szemantikus keresője, ami máig működésképtelen olyan módon, ahogyan működnie kellene, viszont megfelelő URL-ek összetákolásával és küldésével rábírható, hogy szinte akármilyen elborult feltétel szerint keressünk a Facebookon belül, az egyetlen előzetes feltétel, hogy a Facebook használati nyelve US English-re legyen beállítva.

Egy-egy ilyen URL entitásazonosítókból és kulcsszavakból áll, egy-egy részterm pedig lényegében mondjuk a magyarral párhuzamba állítva határozóknak, jelzőknek, tárgyaknak vagy alanyoknak feleltethetők meg, az elméleti lényeget vázlatosan ezzel a prezivel mutattam be még 2017. októberében.

Évekkel ezelőtt, amikor a kulcsszavakat elkezdtem bányászni, szinte hihetetlen volt, hogy alig foglalkozott ezzel valaki előttem, pontosabban párhuzamosan velem. A témában egy cikket egy nyelvtechnológiai konferenciára is beadtam évekkel ezelőtt, amit aztán alaposan lehúzott a programbizottság, tök véletlenül pedig szinte ugyanakkor a cikkben megjelölt, akkor ismert kulcsszavakat konkrétan valaki finoman fogalmazva kreatívan újrahasznosította persze egy kőkeményen fizetős szolgáltatásban.

Később belefutottam egy oldalba, ahol már egy rakás kulcsszó kint volt, linkeltem is egy szakmai csoportba kopipészttel, aztán az alapján már megtalálható volt más számára is a spanyol nyelvű oldal, ami még mindig nem tartalmazta a teljes listát. A 2017. októberében bemutatott prezentáción cca. 40 kulcsszó szerepel, de világos volt, hogy ennél több van, ezen kívül nyilván többnek a használata, ha úgy tetszik helyesírása egyszerűen nem volt világos.

Aztán a jóég tudja, hogy hogyan, de 2017. szeptembere körül találtam a Githubon egy forráskódot benne 300-nál is több kulcsszóval, amit egy Huy Do nevű vagy nevet használó japán csávó tett fel, nem világos, hogy ő írta vagy ő is átvette valahonnan, ami viszont durva, hogy 2014. szeptemberében töltötte fel a repójába, holott maga a Graph Search első verziója mindössze 6 hónapos volt. Persze számomra így sem volt értelmetlen a kulcsszavak addigi bányászata, már csak azért sem, mert közben legkülönfélébb alkalmazási lehetőségekre jöttem rá. Más oldalról viszont azt lehetne mondani, hogy újra feltaláltam a kereket, ráadásul ahhoz képest, hogy elvileg éppen a keresés lenne a területem, olyan hülye voltam, hogy nem találtam meg korábban. A magyarázat azért nem olyan ördögien bonyolult: a DuckDuckGo, a Google, a Yandex és a többi egyrészt értelmes kifejezések keresésére van idomítva, egészen egyszerűen azért, mert a forráskódok csak egy töredékét képzik a web tartalmának. Meg persze nem ezzel foglalkoztam látástól Mikulásig.

Valami után kutatás persze nem csak keresésből áll, de jórészt abból. Viszont ha rákeresünk három, kimondottan ritka kulcsszóra, kettő másik mellett mondjuk arra, hogy

commerce_by_product_capability

nos, még mindig kevesebb, mint 200 találatot kapunk a Gugliban. Amire kerestünk, mind valamilyen forráskódba ágyazva vannak, másrészt gyakorlatilag azonosak a forráskódok, esetleg forkok. Azaz tényleg eléggé kevesen ismerték azt a 314 szóból álló szótárat, ami most teljesnek tűnik, ha pedig többen, akkor azok megtartották maguknak illetve nem azzal foglalkoztak, hogy milyen nyelvtannal működőképes. Hogy konkrétabban fogalmazzak: a

Photos taken in Rózsakert Bevásárlóközpont

lekérdezés értelmes visszatérési értékekkel a

https://www.facebook.com/search/1280747421959605/photos-in/

URL-lel áll össze, viszont a

Photos taken in Rózsakert Bevásárlóközpont from June 2016

már valahogy így:

https://www.facebook.com/search/1280747421959605/photos-in/jun/2016/date-2/photos/intersect

Az, hogy összetett kifejezés /intersect-tel zárandó, világos, ahogy az is, hogy diszkrét értékként adjuk meg entity_id-vel, hogy mivel kapcsolatban keresünk, azt viszont már véletlenül nem lehet kitalálni, hogy időbeli szűkítésnél:

- a photos-in kulcsszó kerül előre
- az időre való szűkítést, mint résztermet utána, a hónap három betűs rövidítésével kell megadni
- utána az évet
- de olyan módon, hogy azt a date-2, nem pedig például a logikusan várható date kulcsszó követi
- utána ismét jelölni kell, hogy fotót keresünk

Na most ilyenre véletlenül nem lehet rájönni, ez világos. Olyan logikával lehet próbálkozni, hogy magába a keresősávba külön-külön megadjuk, hogy

Photos taken in Rózsakert Bevásárlóközpont

illetve

Photos taken in 2016

aztán az első néhány értelmes találat alatti "See all" URL-jét kipuskázzuk, viszont ennyi alapján nem lehet megállapítani, hogy a kettőt hogyan kellene összetákolni összetett feltételt kifejező termmé, ha pedig kézzel adjuk meg a keresősávba, hogy mit keresnénk, szinte 1000%, hogy tokenizálni sem tudja a hülye Graph Search, hogy mit is kellene keresnie. Mármint első keresésnél biztosan, amit korábban lefuttattunk, annál nyilván más a helyzet.

Életszerűtlen, hogy valaki annyi ideig próbálgassa, amíg rá nem jön a fenti 5 szabályra még egy ilyen egyszerű keresés esetében is, én is inkább suggestek alapján túrtam ki, amit kitúrtam.

Az egész persze semmiféle hivatalos fejlesztői dokumentációban nem lehető fel, a szókészletet egészbe nézve pedig eléggé világos, hogy nem is embereknek szánták, hanem tényleg belső lekérdezőnyelvként, amit majd a gép tákol össze önmagának már ha megértette egy NLP-pipeline alapján, hogy mit kellene keresni. Például a napos pontosságú időpontra való keresésnél ezért találták ki hanyag eleganciával, hogy date-3 épüljön az URL-be, mert nem kell, hogy human readable legyen...

Annyi mankó talán van, hogy például Huy Do kódjából lehet erre-arra következtetni a nyelv nyelvtanával kapcsolatban, aztán hol full egyszerű a szabály, hol közel sem, de alighanem az alapján majd írok egy komolyabb "nyelvtankönyvet" is.

Ami eléggé sanszos, na meg az én sejtésem, mintha az egészet úgy találták volna ki, hogy azt szépnevű nyomozóhatóságok tudják kifinomult keresésekre használni. Mivel a Graph Search sokáig konkrétan nem vette figyelembe a privacy selectorokat, azaz hogy találatként mit mutathat majd meg. A másik, ami szinte biztos, hogy eredetileg magától a Facebooktól szivárogtak ki a kulcsszavak és a nyelvtan, amiket tehát nem is felhasználóknak, nem is fejlesztőknek, csupán az okos GS-nak építettek. Az API-n futó appok nem dobálják vissza a kulcsszavakat, azaz aligha vicceskedte ki valaki azokat ilyen módon.

Hatalmas hiba lenne azért azt gondolni, hogy na, akkor most megvan a svájci bicskánk a világ egyik legnagyobb élő adattárházához kis képzavarral élve. Mivel még a kulcsszavak és a szintaktika ismeretében is gyakorolni kell ahhoz, hogy ésszerű idő alatt tényleg azt találjuk meg, amit szeretnénk, az itt nem részletezett buktatókról nem is beszélve.

Kulcsszólista erre, azt meg kétszer is meggondolom, hogy a nyelvtant mennyire és milyen körben osszam meg, amint teljes lesz. 

https://github.com/bardoczi/facebook-graph-search/blob/master/facebook-graph-search-keywords

Google Drive felzárkóztató

Na szóval: mivel egy mezei Google-user ismerős ma tudta meg tőlem, hogy a Google Drive-ot a Google a most ismert formájában kinyírja, írom a lényeget, hogy csak linkelni kelljen, ha valaki szeretne képbe kerülni.

Arról már nagyon sokat cikkeztem, hogy miért nagyon nem bölcs dolog úgy bármit is tárolni Google szolgáltatásban mondjuk Youtube-playlisteken, na meg filmeken kívül, akkor hivatkoztam egy cikket is, amiben a szerző alaposan utánajárt, hogy a Google eddig hány száz szolgáltatását nyírta ki vagy tette fizetőssé, a jelenlegi szolgáltatások közül pedig melyik mekkora valószínűséggel fog létezni néhány év múlva is. Úgy nagyjából a Gmail-t leszámítva gyakorlatilag mind komoly valószínűséggel megszűnhet vagy valamilyen formában fizetőssé válhat - nagyon értetlenül néztek sokan, amikor még a pattintott kőkorszakban azt mondtam, hogy valamit majd a Youtube-divíziónak ki kell találnia, hogy fedezze a fokozott adatátvitellel járó költségeket, az informatikus hallgatók nem értették, amikor pedig megjelentek az első Youtube-reaklámok - amikor bizonyos államokban fél-egy percesen és át sem lehet őket ugrani - néztek nagyokat.

A Google még mindig nem népjóléti intézmény, a Google Reader még csak erőforrásigényes sem volt, viszont nem tudtak belőle annyi, a felhasználói magatartásra vonatkozó információt kisajtolni, hogy profitábilis legyen, így tetszik-nem tetszik, annak ellenére nyírták ki, hogy örömmel használta a fél világ. Mármint az a része, amelyik nem hallott még az ATOM/RSS feedolvasóról, ami meg egy teljesen független szabvány, mégpedig olyan, amit aligha vezetnek ki.

Szóval Google Drive - még egyszer: az adatátvitel nagyon drága mulatság, azzal, hogy a fájlhoszting szolgáltatók milyen ordas hazudozással próbálták túllicitálni egymást, na meg elhitetni a világgal, hogy van ingyen ebéd, már jóval korábban foglalkoztam itt.

Nos, a Google Drive-nál nem is a tárhely volt az igazán drága, amiről nem tudni, hogy a globális kihasználtsága mennyi. Az viszont tudható, hogy a 2013. augusztusi leállásnál a globális netforgalom 40%-ot esett. Azaz, hogy folyamatosan szinkronizálnak a gépek a felhővel, eszelős adatforgalmat generál, mondjuk nem is véletlenül van jelent 60 gbps-es peering tagként Magyarországon - összehasonlításként a Magyar Telekom, mint internetszolgáltató, 30 gbps-es játékos. Hogy miért maga az adatátvitel a legköltségesebb része a teljes internet működésének /*igazából csak IT gazdaságtani értelmezésben van értelme így elkülöníteni*/, nem megyek bele.

Lényeg, hogy a Google Drive-ot a mezei ügyfeleknél és az üzleti ügyfeleknél a mostani formájában egyaránt kinyírják aztán lesz helyette valami, nem világos, hogy mennyiért vagy milyen korlátozásokkal, de a nevéből ítélve valami olyan szolgáltatás, ahova fel lehet szórni minden ritkán használt szart, azaz inkább archiválásra lesz alkalmas.

Mivel teljesen mással kellene foglalkoznom, jobban nem is merülök el a témában, ha felmerül az a kérdés, hogy ha fájlhosztingról van szó, akkor mégis melyiket érdemes választani, amikor még tesztelgettem, akkor a legjobbnak, legstabilabbnak, leginkább platformfüggetlennek a Onedrive és a MEGA mutatkozott. Microsoftéknál az 5 GB-nál nagyobb, újonnan igényelt accountok már fizetősök, amik jól mutatják, hogy tényleg nem olcsó mulatság biteket mozgatni, ha sok van belőlük. Másrészt az utóbbi kettő mentes az olyan hülyeségektől, mint mondjuk az, hogy a fájl feltölti ugyan, de nem indexeli, azaz olyan, mintha fel sem töltötte volna, lehal a kliensprogram vagy éppen az üzemeltető konkrétan belepofázik, hogy mit tárolhatsz és mit nem, na meg az általad tárold adatokat gépileg kedvesen átnyálazza és a rólad készült profilt eladja a hirdetőknek...

Valamikor 2013-2014 táján volt egy vaskosabb cikkem azzal kapcsolatban, hogy a nethasználat jelenlegi növekedési üteme alapján belátható időn belül az end-user is fizetni fog olyan szolgáltatásokért, amiről ma még el sem tudja képzelni vagy éppenséggel minden korábbinál durvább hirdetési modellek lesznek általánosak.

Van egy sajátos gyermeki bája, amikor valaki erre rávágja, hogy "én aztán nem fogok fizetni érte" vagy "akkor használok másikat", amire a rövid válaszom, hogy "de fogsz fizetni" illetve, hogy "nem fogsz másikat használni". Ha a Google vagy a Microsoft nem képes megoldani, hogy izmosabb tárhelyet adjon díjmentesen, akkor a többi játékos a pályán mégis miért tudná? Szóval átmenni nem nagyon lesz hova. Ha konkrétan fájlhosztingról van szó, a MEGA komolyan vehetőnek tekinthető, de függetlenül attól, hogy díjmentes vagy előfizetéses plant használ valaki, ha elhányta a jelszavát, rosszabb esetben lenyúlják, bambi, nincs support, nincs elfelejtett jelszó, az adatoknak annyi. Ami pedig például a Youtube-ot illeti, ha mondjuk belekattintasz egy 5 perces videóba, amiről előre azt sem tudhatod biztosra, hogy éppen az érdekelni fog, de azért egy fél perces reklámot végig kell nézni előtte, mint már most is a burzsujabb országokban, még a leginkább fillérbaszó felhasználó is egy idő után azt mondja, hogy inkább fizet, csak lehessen normálisan használni a szolgáltatást.

A webhoszting gazdaságtana - így vernek át a nagyok

Időnként megkapom a kérdést, amit alighanem nagyon sokan, nevezetesen, hogy melyik szolgáltatót ajánlom, akár csak egy egyszerű személyes webhelyre lenne szükség valamilyen lightweight CMS-sel, akár a szerver erőforrásait kétpofára zabáló wordpresses webhelyre, akár olyanra, amelyiknél fontos, hogy a szolgáltató akkor sem szól, ha az ügyfél nem kimondottan a klasszikus célra használja a szolgáltatást, azaz ritkán, viszont akkor kimondottan nagy erőforrásigényű webappokat kell futtatni, de kellően ritkán ahhoz, hogy ehhez túl drága lenne egy webappokat hosztoló, kimondottan cloud computing szolgáltató igénybevétele.

És még mindig azt tudom mondani, amit akár 3-4 évvel ezelőtt: hogy komolyan nem tudom! Hozzá szoktam tenni, hogy az enyém melyiknél van pillanatnyilag, de azt is, hogy simán előfordulhat, hogy amit éppen használok, néhány hónap múlva már gyakorlatilag használhatatlan lesz, viszont lévén, hogy általában 1-2 éves ciklusokban érdemes előfizetni a szolgáltatásra, a pénzvisszafizetési garancia már lejárt, ha az ügyfél költözik, bukja a befizetett pénzt. Emellett pedig azt, hogy az az összes, ami mellett el is hiszem, hogy a szolgáltató tud normális szolgáltatást nyújtani ebben a műfajban, olyan 5 USD/hó körül lehet, de már inkább 7-8 USD/hó összeget mondanék.

Szájbarágó következik, és igen, tudom, biztos lesz, aki unja - mire kell figyelni a szolgáltatóválasztásnál, mik a leggyakoribb tévhitek és átverések a szolgáltató oldaláról?

Még mindig meglepő, hogy mennyi ügyfél van, amelyik európai vagy magyar cégtől vesz igénybe webhoszting szolgáltatást annak ismeretében, hogy még a legsuttyóbb USA-beli szolgáltató is az összes fontos tényezőt tekintve messze veri a magyar webhoszting szolgáltatókat, na meg nem mellékesen sokkal olcsóbb is.

Ennek megértéséhez tényleg nagyon egyszerűsítve próbálom összefoglalni, hogy hogyan is működik a hagyományos webhoszting üzletág.

Abban nagy meglepi nincs, hogy ami a neten létezik, azt szerverek szolgálják ki. Azaz a szolgáltató vagy vesz vagy bérel egy dedikált szervert, ha van egy csöpp esze, azt normális szerverhotelben helyezi el. Természetesen ha nem piti játékosról van szó, akkor előre gondolkozik és eleve kolokáció alapon vesz igénybe szervertermi szolgáltatást, ahova rögtön több száz vagy több ezer szervert helyez el. Miután ez megvan, egy-egy szerverre, a virtualizáció nyilvánvaló előnyei miatt felhúz - ideális esetben kevés számú - virtuális gépet, ami persze a net felé valós szerverként fog látszódni, innentől kezdve minden a VM-en történik.

A VM ugyebár attól VM, hogy az ügyfél felé tökéletesen úgy látszik, mintha egy önálló szerver lenne. Megjegyzem, láttam, már olyan "internet szolgáltatót", ami kitalált valami Droid Pisti, aztán nem elég, hogy összesen egy szervert bérelt csórikám, de arra vagy idétlenül sok virtuális gépet húzott fel, hiszen ezzel a trükkel tudott VPS-szolgáltatást is biztosítani vagy ami még rosszabb, többrétegű virtualizációt alkalmazott, azaz a VM-en belül további VM-eket telepített. Aztán amikor már volt rajta mondjuk 100 ügyfél, ideális esetben egyvalakinek az elszart szkriptje nem rántotta magával az egész boltot mindenestől.

Tehát adott jópár szerver, azon kevés számú virtuális géppel, amit a szolgáltató kezel. A shared hoszting szolgáltatást igénybe vevő ügyfelek pedig a VPS-eken kapnak egy-egy adag erőforrást, tárhelyet, jó esetben pedig normálisan meg van oldva, hogy egy ügyfél se vihessen el annyi erőforrást, ami a teljes VM stabilitását, így a többi ügyfél webhelyeinek rendelkezésre állását veszélyeztetné. Alapvető elvárás, hogy a leggyakrabban használt funkciók legyenek elérhetőek egy grafikus felületen keresztül, ingyenes VestaCP és ZPanel meg a többi ide vagy oda, az első helyről eléggé kirobbanthatatlannak tűnik a cPanel/WHMCS. Ha van felület, aminél kritikus fontosságú elvárás, hogy biztonságos legyen, az pont a cPanel és társai, mivel amit az ügyfél csinál, azzal végez ugye közvetlen műveleteket a saját birodalmában, innentől kezdve amikor tárhelyről írok, ebbe beleértem a rendelkezésre álló lemezterületen túl az adatbázisokat, a szkripteket futtató motorokat és természetesen adatbázismotorokat. Az ügyfeleknek nem evidens, de a cPanelért eleve fizetnie kell a szolgáltatónak, mégpedig olyan összeget, amit csak akkor éri meg licenszben használnia, ha nagyon nagy tételben boltol be belőle. 

A hosztingban még csak nem is ez a legdrágább, hanem a többé-kevésbé normális support, ami lévén, hogy emberi erőforrást igényel, néhány ritka kivétellel mindig ki van szervezve a világ valamilyen kevésbé boldog országába, tipikusan Indiába, ahol aztán a 1st level support ideális esetben tud írni-olvasni amerikaiul' és 24x7x365-ben elérhető. Egyszerűen fel nem bírom fogni azoknak a szolgáltatóknak a felelőtlenségét, akik csak a helyi idő szerint munkaidőben adnak supportot, hiszen mindegy, hogy milyen eredetű szolgáltatáskiesésről van szó, akár egy lehaló szervert, akár egy komolyabb malware támadást, akár egy hülye ügyfelet, amelyik véletlenül rántja magával akár a teljes VM-et, ahogy írtam, végképp nem érdekli, hogy milyen nap és milyen napszak van.

Ha van terület, amire biztosan igaz, az a webhoszting, hogy a 1st support level, aztán tényleg 1st level, azaz tényleg csak a legelemibb ügyfélkéréseket tudják megoldani, mióta az eszemet tudom, ha volt valamilyen hiba vagy olyasmi, amit nem tudtam beállítani, a vonal túloldalán lévő busmannak mindig tovább kellett dobni a labdát egy magasabb support level felé, azaz akik már harceddzettebb IT-sok, több jogosultsággal, ők viszont eléggé világos, hogy nem ugraszthatók pár percen belül, pár órán belül jó esetben igen. Lényeg, hogy a support annyira drága, hogy tökéletes supportot fenntartani egyszerűen egy szolgáltató sem tudna fenntartani kifizetődő módon.

Ha valaki ráguglizik arra, hogy webhosting reviews, az első nagyon-nagyon sok találat olyan oldalra mutat, amelyik a szeplőtelen szűzanyára esküszik, hogy ők aztán tényleg függetlenek és az értékelések valóban felhasználói értékelések, sokszor nem is kell különösebb utánakutatni, hogy azonnal kiderüljön az, hogy gyakorlatilag az összes meg van bundázva, kevésbé rossz esetben csak el van árasztva valódinak tűnő, de egy-egy szolgáltató által elhelyezett értékelésekkel, amihez hozzáadódnak a teljesen dilettáns ügyfelek értékelései. Mert nem, az, hogy egy webhoszting szolgáltató 2-3 évig bevált, nem jelent semmit, ha 5 éven keresztül folyamatosan, az már igen. A leghosszabb ideig talán az Arvixe-tól igényeltem webhoszting szolgáltatást, ami kifogástalanul működött éveken keresztül, majd egyszer csak megvásárolta egy holding, amelyik valahol nagyon spórolni akart, mert folyamatosan lett egyre megbízhatatlanabb az egész, a végén már nem volt nap, hogy ne legyen több-kevesebb totális leállás, de még egy átlagos forgalmú Wordpress-oldalt sem volt képes elvinni a hátán annak ellenére, hogy minden létező bűvésztrükköt bevetettem a gyorsítás érdekében. Ha volt hiba, amit elkövettem, az az, hogy bíztam benne heteken keresztül, hogy majd javulni fog a helyzet, mire végül sürgősségi jelleggel kellett minden szart kimenekíteni a szolgáltatótól.

Itt megtorpannék egy kicsit: az én esetemben nem nagyon volt szükség többre, mint arra, hogy a személyes webhelyem legyen valahol, meg legyen egy tárterület, ahova stabilan lehet menteni olyan adatokat, amik nem érzékenyek. A szolgáltatók árképzési logikája alapján viszont még ilyen esetben is olyan csomagot érdemes választani, amelyik 5-10 oldal hosztingját vállalja. Azaz ha egy ilyenre az ügyfél előfizet, akkor édes mindegy, hogy önmagában egy oldal árválkodik vagy éppenséggel önkéntesen beköltöztetjük a szomszéd, a haver, a kolléga webhelyét is, lévén, hogy fizetni így is, úgyis ugyanannyit kell, lassabb meg nem lesz a szolgáltatás ettől. Márpedig ha a hozzám költöztetett oldal a szolgáltató balfaszsága miatt nem működik normálisan, az vérciki. 

A másik fontos tényező, hogy az összes, de komolyan szinte az összes webhoszitng szolgáltató hazudik, különbség csak abban van, hogy mennyire pofátlanul! Éppen ezért van az, hogy az összesről található olyan review, amelyik az egekig magasztalja, na meg olyan is, amelyikben leírják ugyanarról, hogy a világon nincs nagyobb aljas lehúzás annál, amit csinálnak. Na ilyen szempontból semmit sem változott ez az egész piac 10 év alatt.

Először is: ha valamivel kapcsolatban az olvasható, hogy unlimited vagy unmetered, még a presales-enél rá kell kérdezni, hogy az náluk egészen pontosan mit jelent. Ha nem tud meggyőzni, felejtsd el!

A korlátlan használattal kapcsolatos átverések, amikkel találkoztam vagy olvastam, konkrét szolgáltatóknál, komolyan csak a legirritálóbbakat emelem ki:
- az übernépszerű Hostgator még a legerősebb csomagjánál is korlátlan tárhelyet ígér, ami egy olyan hazugság, amit mire tetten ér az ügyfél, már kifutott abból az időablakból, amikor pénzvisszafizetést lehet kérni. Konkrétan arról van szó, hogy ha az inode-ok azaz, gyakorlatilag a fájlok és mappák száma meghaladja a 100.000-et, afölött nem végzik el a biztonsági mentést, ami elemi szolgáltatás, 250.000 inode-ot elérve pedig kihúzzák a dugót és jelzik, hogy "hé paraszt! bérelj dedikált szervert, tízszer ennyiért, de rögtön, persze tőlünk, hát honnan máshonnan?"

Na most aki kicsit is képben van, az tudja hogy a 100.000 lehet, hogy soknak tűnik, viszont egy komolyan vehető CMS telepítése önmagában több tízezer inode-ot foglalhat le, azaz amikor még nincs is rajta semmilyen tartalom! Arról nem is beszélve, hogy az ilyen-olyan logfájlok napi rendszerességgel jönnek létre halomra, amiket valahogy le is kell válogatni. Vagy éppen ha valaki van annyira kezdő, hogy az email-szolgáltatást nem kimondottan email-szolgáltatótól veszi igénybe, hanem a web-hoszting szolgáltatójától, a csomag részeként, számolni kell vele, hogy minden szutykos email természetesen plusz egy-egy fájl, amiből aztán jó sok lehet, kevés felhasználó esetén is. A Hostgatornál a lenyűgöző prosztóság része, hogy előre nem figyelmezteti az ügyfelet és be se engedi addig, amíg nem fizet! Ahogyan suttyóság a köbön az is, hogy megtévesztő módon az első számlázási ciklusra, azaz 1-2 évre adnak mondjuk 60%-os kedvezményt, amit ugye jól el is felejt az ügyfél, amikor pedig ez az idő letelik, a következő ciklust automatikusan számlázzák és persze vonják is le a kártyáról, már ha tudják - az én esetemben nem tudták. A kedvezmény nélküli ár pedig olyan összes lett volna, hogy attól még bennem is megállt az ütő, de ez még mindig nem a legalja, amikor chatsupportot kértem, elkezdtek alkudozni és a végén már negyed annyiért (!!) adták volna a szolgáltatást, csak hogy ottmaradjak - érted, pár órával azt követően, hogy konkrétan megpróbáltak meglopni. Ennyit a világ legnépszerűbb, legfancybb shared hoszting szolgáltatójáról.
- a hasonló népszerű Godaddy beígér toronyórát lánccal, de egy sokadik keresési találatként fellelhető fórumban ugyanúgy ott van, mint a TOS-jükben, hogy a fene nagy korlátlanság mellett korlátozzák az adott időkeretben engedélyezett adatbázis-tranzakciók számát. Na már most, egy kisebb látogatottságú hírportál esetén is simán előfordulhat az, hogy hirtelen több látogató esetén átlépné a CMS a megengedett limitet és nem, nem az történik, hogy a látogatók egy részét nem tudja kiszolgálni egy kedves Times New Roman bötűvel' írt out of resources üzenet mellett, hanem az, hogy konkrétan senkit!

Azt meg tudjuk, hogy a leginkább kritikus általában éppen az adatbázismotor erőforrásigénye. A webhely utolsó helyes állapotát statikusan behúzni képes Cloudflare ideig-óráig megoldást jelenthet.

- a szépnevű Bluehostnál még ügyesebben el van rejtve, hogy mennyi az annyi, akit nem hiszi, járjon utána. A Kék Parasztok 20 USD/hó-tól kínálnak normális Wordpress-hosztingot, az már csak pici betűkkel van odabökve, hogy csak az első számlázási ciklusban, mert utána már 40 USD/hó a díj, ami egy vicc. Bizarr vicc, ha azt nézzük, hogy a hivatalos Wordpress-hoszting csomagok közül a legizmosabb is 25 USD körül van, gyakorlati szempontból a korlátozás meg annyi, hogy nyilván nem lehet belenyúlni a kódba. Viszont a hivatalos Wordpress-hosztingnál amellett, hogy eléggé harceddzett arcok figyelik főállásban, hogy ne is legyen törhető az oldal, ha extrém forgalma van az ügyfélnek, az ő asztaluk megoldani a dolgot a háttérben.

- nem tudom már, hogy hol láttam olyan típusú csalást, ami nagyon hasonló annál, amit a Hostgator alkalmaz a tárterülettel kapcsolatban. Nevezetesen az, hogy korlátlan adatbázist kínálnak, viszont maguknak az adatbázisoknak a mérete már korlátozott, néhányszor 10 MB-ra, amit ugyancsak nem olyan nehéz megugrani még szabályos használat esetén sem, mint amilyennek tűnik.

Ahogy utaltam rá, a pénzvisszafizetési garancia is rendszerint okosba' úgy van kitalálva, hogy az arra adott 30-90 napban úgysem fog kiderülni, ha valamit nem teljesít a szolgáltató normálisan, a költözés pedig minél később történik, rendszerint annál fájdalmasabb.

Nagyon bájos hazugság még, amikor feltüntetik, hogy a szervereik milyen überbiztonságos szerverhotelben vannak elhelyezve, azt a benyomást kelteve, mintha övék lenne az egész, nem pedig olyan adatközpont aminek amúgy van rajtuk kívül még akár több száz mammut-ügyfele.

Visszatérve ahhoz, hogy hogyan lehet még életben 2017-ben is a magyar webhoszting-üzletág, szakmailag megalapozott magyarázatot inkább ne is keressünk, mert aligha van. Az egyik gyakori eset, hogy egy hardcore IT-s havernak van pár szervere, aztán önkéntesen beenged néhány ismerőst, ugyan ennek nincs különösebb piactorzító hatása. A másik magyarázat az, hogy egyszerűen azért választják a magyar ügyfelek a magyar hosztingot, mert magyar, ami meg aztán tényleg csak akkor indokolt, ha az ügyfél egy büdös szót nem tud angolul, lévén, hogy nyilván a support is magyar nyelvű lesz.

Ezen kívül keringenek még olyan közkeletű ostobaságok, minthogy az, hogy a Google preferálni fogja a tartalmakat a rangsorolásnál Magyarországról indított keresés esetén, ha az magyar hálózat felől töltődik. Ez valamikor jópár éve akár még igaz is lehetett, de akkor is minimálisan nyomott a latba, ami viszont sokkal inkább számít, hogy az oldal mennyire gyorsan töltődik be. Ehhez viszont érdemes tudni, hogy az utóbbi pár évben több nagy, végfelhasználók számára is igénybe vehető CDN költözött be Magyarországra. Ez pedig annyit jelent, hogy simán előfordulhat, hogy mondjuk egy echte-magyar szolgáltatónál lévő, de ingyenes-filléres Cloudflare mögé tett oldal betöltődése Magyarország területén belül gyorsabb lesz esetenként, mintha egyenesen a szolgáltatótól töltődne be, nem mellékesen más földrajzi területről pedig teljesen biztosan. Igaz, van pár szempont ami miatt a Cloudflare-t már nem ajánlanám, hogy miért nem, az most nem tartozik ide.

Summázva, ha valaki nincs otthon a témában, kérdezzen olyat, aki sok-sok éve igen, viszont nem a haverja szolgáltatóját fogja ajánlani szakmai megfontolás nélkül. Ugyanakkor sok esetben a geekek vagy kimondottan IT-sok sem a legjobb tanácsadók a témában, mivel esetleg rögtön VPS-t vagy dedikált szervert ajánlanának sokkal drágábban olyan célra, amire egy megbízható shared hoszting is elegendő. Másrészt amikor az IT-s rögtön VPS-t ajánl például azon az elven, hogy körülbelül egy jóféle shared hoszting árában' mérik, a fene nagy csőlátás miatt egy nagyon fontos dolgot elfelejt: a virtualizált vas vagy a tényleges vas, az tényleg csak vas. Azaz ha licenszelni kell rá ezt-azt, na meg üzemeltetni kell, akkor az ügyfélnek úgyis meg kell fizetnie egy IT-st, esetleg nem is tudja annyira biztonságosra beállítani, megfelelő SLA mellett, mint az erre specializálódott szolgáltatónál dolgozó szakik, másrészt nem is ugrasztható 0-24-ben, aztán az ügyfél többet fizet a kevesebbért.

Cloudflare-örömök és a DNSSEC

Ha van, amiről mindenki beszél, elvben már mindenki fel van rá készülve, mégsem merik bevezetni az internetes szabványok közt, az IPv6 mellett a DNSSEC ott a dobogón.

Ugyan a DNSSEC többek szerint kimondottan ellenjavallt és a rendelkezésre állást súlyosan veszélyezteti, tény, hogy a domainekhez tartozó zónafájlok rekordjainak hitelesítése nagyban fokozná a teljes internet biztonságát, amihez viszont több dologra elemi szükség lenne:
0x100. egyrészt arra, hogy a DNS hoszting szolgáltatók, a resolverek és a kliensek kivételesen pontosan tartsák magukat az IETF által rögzített vagy ajánlott szabványokhoz - ilyen szabvány vagy szolgáltatás viszont gyakorlatilag máig nem született a net történetében
0x200. mivel ma már egyre ritkább esetben történik parancssoros környezetben valamilyen IT-szolgáltatás beállítása, a DNS-hoszting szolgáltatók felelőssége lenne egyértelművé tenni, hogy _pontosan_ mi is történik, amikor a végfelhasználó valamit webes felületen keresztül - pl. a Cloudflare zónaszerkesztőjében állít be

A Cloudflare még 2015-ben jelentette be, hogy általánosan támogatni fogja a DNSSEC-et, az ügyfeleknek tényleg nincs más dolga, csak rátaposni a bekapcsolás gombra, illetve a regisztrátornál megjelölniük, hogy a domainjük DNSSEC-et használ, és egészen pontosan milyen módon - a Cloudflare a mai napig csak az ECDSA-t támogatja az erőforrásrekordok hitelesítéséhez. A DNSSEC-et támogató regisztrátoroknál, mint amilyen a Namecheap, szinte hülyebiztosan beállítható a szükséges DS rekord. A beállításhoz persze nem árt alaposan ismerni a DNSSEC-természetét, a beállítás tényleg nem volt több a saját domainem esetén néhány percnél. A beállítás helyessége pedig a https://dnssec-debugger.verisignlabs.com/ és a http://dnsviz.net/ oldalakon keresztül seperc alatt ellenőrizhető.

Mindez roppant szép és jó, de azonnal kiderül belőle, hogy a Cloudflare a domain A, MX, SOA, NS és TXT rekordjait írja alá, naivan úgy gondolhatnánk, hogy az aldomainek esetén hasonló a helyzet. A Cloudflare az aldomaineknél csak az A-rekordot írja alá, van viszont egy sokkal súlyosabb probléma is. Abban az esetben, ha egy aldomain kezelését egy aláíratlan NS-rekord megadásával másik névszerverre bízzuk, amelyik már nem irkál alá semmit, naivan úgy gondolnánk, hogy ez egyértelműen jelzi a resolver felé, hogy onnantól már nem kell ellenőrizni a DNSSEC-et. Ehelyett az történik, hogy a DNSSEC szerves részét képző NSEC, NSEC3, NSECPARAM rekordok miatt a felsőbb szintű névszerver azt fogja jelezni a resolver felé, hogy az adott domain biztosan nem létezik!

Ilyennek pedig egyenes következménye, hogy az érintett aldomain leesik a net azon részéről, ahol be van állítva, hogy a resolver ellenőrizze az zónarekordok RRSIG aláírásait, ha pedig igen, foglalkozzon-e vele vagy sem. 

A probléma nem csak az, hogy a Cloudflare nem hívja fel a figyelmet arra, hogy az aldomainek NS-rekordjait nem írja alá, ami pedig már logikus, hogy onnantól kezdve más névszerver által kezelt aldomainek érvénytelennek lesznek nyilvánítva. Hanem az, hogy a regisztrátor Namecheapnél konkrétan csetes supportot kellett kérni a DS-rekord eltávolításához, addig nem engedte a Cloudflare az egész DNSSEC-et kikapcsolni, holott két piacvezető szolgáltatóról van szó.

A problémát relatív gyorsan azonosítottam, de akkor is sikerült úgy lábon lőnöm magam, hogy 61 percig az érintett aldomain nem csak, hogy elérhetetlen volt az erre érzékeny resolvereket használó gépek felé, de még az is bekerülhetett néhány gyorsítótárba, hogy biztosan nem létezik. Ez viszont nem derül ki azonnal egy megszokott dig lekérdezéssel, ha nem adjuk meg, hogy a DNSSEC-et is ellenőrizze és egy olyan resolvert, ami nem gyorsítótárból dolgozik és fel van készítve a DNSSEC-re, azaz a hagyományos lekérdezés alapján semmilyen hibát nem fogunk észlelni.

Na most ha valaki nem ír rá szkriptet, hogy a

dig MX +additional +multiline +dnssec dnsviz.net. @8.8.8.8

fusson le valami megbízható helyen percenként és riasszon valamilyen módon olyan esetben, ha az aláírással para van, akkor teljes aldomainek vagy domainek eshetnek le a netről olyan módon, hogy azt az admin észre sem veszi. Ráadásul a fizetős uptime monitoring toolok többségében sincs olyan beállítás, ami a DNSSEC-et is figyelembe venné. Külön szép az egészben, hogy a regisztrátornál megadott DS TTL értékébe nem lehet belenyúlni, azaz a kikapcsolást követően is ideig-óráig a domain vagy látszik vagy sem.

Persze, lehet azt mondani, hogy aki nem parancssori környezetben állít be valamit, ami azért feltételezi, hogy az admin tudja, hogy mit csinál, az megérdemli, ez már egyre kevésbé életszerű. A DNS-hoszting szolgáltatók eleve nem is adnak SSH-t, másrészt tömegigényt kell kielégítenie, azaz minél inkább bolondbiztos, hibákra is figyelmeztető webes felületeket biztosítani ezen a területen is, hogy az ügyfelek kevesebb tudással is be tudják állítani, amit szeretnének úgy, hogy minél ritkábban kelljen supportot kérni. Azaz hasonlóan, mint az egyszerű webhoszting szolgáltatók esetén, ahol alapértelmezés szerint az SSH le is van tiltva. Nagycéges környezetben persze más a helyzet, de az IT-sek érhető módon mindenhol az olyan megoldást fogják előnyben részesíteni, amihez tartozik pofás webes felület.

Összességében: a világ sokmindenre megérett már, de hogy a DNSSEC tömegessé válására nem, az biztos. 

Gumicsont: a legnehezebben tanulható idegen nyelvek

Nem lehet elégszer elmondani: aki azzal jön, hogy melyik a legnehezebb nyelv, csak a szegénységi bizonyítványt állítja ki magáról. Legfeljebb egy bizonyos anyanyelvű és kulturális háttérrel rendelkező csoportok számára legnehezebben megtanulható nyelvről lehet beszélni – már kérdés, hogy van-e értelme, főleg, ha figyelembe vesszük, hogy a ma ismert körülbelül 6000, ebből írásbeliséggel rendelkező 3000 nyelv aligha vethető össze bármilyen ésszerű szisztéma alapján is. A nyest.hu még korábban a legnehezebben megtanulható idegen nyelvként az ubih nyelvet jelölte meg, megint mások szerint az inuit eszkimót elsajátítani a legnehezebb.

Néhány nappal ezelőtt a nevezetes TOP 10 videókkal nyomuló WatchMojo összeállította a 10 legnehezebb idegen nyelv listáját, ami messze nem tudományos ugyan, viszont felfért a listára, igaz, csak a 10. helyre a magyar nyelv is. Személy szerint hülyeség, hogy az arab, az orosz és a japán a legnehezebben megtanulható nyelvek közé tartoznának, egy bizonyos alap szintre mindhárom esetén el lehet jutni némi kitartással, csak a szabályokra ne kelljen figyelni. Ami szerintem főszabály az összes, a tanuló által korábban megismerttől teljesen eltérő nyelvek tanulásánál, hogy kifejezéseket kell tanulni szavak és szabályok helyett.

Nem is magyaráznék tovább, jöjjön a WatchMojo nem túl tudományos, de jópofa értelmezése:

Kozma Réka pécsi ügyvéd még mindig akciózik

Hatósági eljárásokkal kapcsolatos információkat közölni ugyebár bőven törvénysértő lehet, de jelen esetben rólam van szó, azaz úgy írok róla, mint magánügyről.

Ha valakinek nincs meg: Kozma Réka az a büntetőjogász, aki a Pécsi Tudományegyetem jogi karán szerezte a diplomáját, már komolyan nem is tudom, hogy mikor, de feljelentettek rágalmazásért, amikor az nem jött be, - mondjuk tényleg nem is rágalmaztam senkit - akkor feljelentett még egyszer zsarolásért, amit szintén instant elvérzett, mivel hogy gyorsan túlessünk a dolgon, én, mint nemhivatalos vádlott-jelölt bizonyítottam, hogy nem zsaroltam meg. Mármint nem én őt. Legújabban Kozma Réka a zsarolási feljelentéshez használt keresetlevelet újrahasznosítva feljelentést tett ellenem becsületsértés miatt. A harmadik feljelentés egyébként kicsit büdösnek érződhet, mert a Pécsi Járásbíróság átpasszolta a Pécsi Törvényszéknek, amelyik másodfokon megnézte és úgy döntöttek, hogy átpasszolják a Szigetvári Járásbíróságnak. A Szigetvári Járásbíróság szintén nem vállalta be az eljárás lefolytatását, ezért visszapasszolta a Pécsi Törvényszéknek, amelyik ha jól értem, visszaküldte a Pécsi Járásbíróságnak, amelyik megküldte a Komlói Járásbíróság felé, így az eljárást a Komlói Járásbíróság indította meg Kozma Réka magánvádja alapján. Ha nem tudtad követni, nem baj, mert én sem nagyon.

Minő manír, hogy a bíróság ugyanazokat a doksikat kapta meg a bizonyításhoz, amit anno a szigetvári rendőrségen ismertettem, ahol megállapították, hogy nem történt bűncselekmény, meg semmilyen törvénysértés. Legalábbis én nem követtem el ellene.

Ha esetleg többet szeretnél tudni Kozma Rékáról, egyszerűen keress rá a nevére a neten.

Ja, ha Nyuszimuszi esetleg majd negyedszer is nekifutna a pernek Tökfejjel vagy nélküle, előtte érdemes átolvasni ezt a karácsonyi posztom, ha pedig postán küldtök valami szart már megint jó távol, a bejelentett lakcímemre, a borítékra legalább írjátok rá jeligeként, hogy „jehova”, köszi!

Ja, jut is eszembe, nem kell bombázni a blogszolgáltatót ügyvédi fenyegetésekkel, ha esetleg eltűnne a poszt, elérhető még a Tumblr-ben, a Blogspot-on, na meg a Wordpressen is.

Jehova, Jehova, Jehovaaa! xDDD

Gondolatkísérlet: ellenőrizni sosem fogjuk, de tessék adózni ám!

Rozi nénit kötelezni az egyetemi tanulmányi osztályon a bonyolult jelszó használatára olyan, mintha azt mondanánk, hogy mindenki fizessen adót, ellenőrizni viszont sosem fogjuk...

Azt hiszem, hogy Bruce Schneider adta az egyik legjobb definíciót arra, hogy mi is a biztonság. A biztonságra való ráfordítás egyenlő azzal, amennyit az enber a kényelemből veszít.

- Mit csinál a retardált Ubuntu-júzer?

- Junyikszra nyinycsvíjus, amikorra rájön, hogy mégis, száz éve már sokkal lassabb a gép és ideális esetben nem vitte el a boltot, aki akarta.

- Mit csinál a mindig mindenkinél okosabb Debian-júzer?

- Amikor esetleg rájön, hogy rootkitekkel használta az átjáróházként működő gépet éveken át - de általában nem jön rá - beszopja magának, hogy ott voltak a rootkitek, de biztosan nem csináltak semmi csúnyát, a gépét pedig ugyan használhatta bárki bármire, biztos nem használta.

- Mit csilál az OSX-júzer?

- Elviszi az almás boltba a gépét kiganéztatni pár év után, ami a gyakorlatban egy teljes újraflashelést és telepítést jelent. Mivel az OSX-eknél az iOS-eknél lényegében csak értelmetlen szarok kerültek be évek óta egy-egy új verzióba, a malware-eket meg a sosem frissülő flash lejátszó és a JRE verziója érdekli, amiről az egység sugarú Apple-user azt semtudja, hogy mi.

- Windows (7) legális: a service pack 1 egész gyorsan felmászik, a közvetlenül utána elindított frissítő a 149 erősen ajánlott ill. hotfix frissítésből most tart a 104-ediknél.. Nem, nem állt meg, most tart ott! Na most gondolhatod, hogy ezt mikor várja ki az átlag júzer, amelyik ugye mindig arra a lehetőségre kattint, amivel éppen eltüntetheti az útjában lévő ablakot, ha dolgozna, fészezne, pornót nézne v egyáltalán bármit csinálna a gépen. Tény: a patchek jórésze a büdös életbe sem települ, elég csak a Confickerre, mint történelmi példára gondolni.

Ha most elmászol a Windows Update-re és a keresés után csak 20-40 telepítendő frissítést ajánl a rendszer, valószínűbb, hogy azért csak annyit, mert még nem települt az a szervízcsomag vagy hotfix, ami előfeltétele lenne a többinek. Aztán mindenki örömködik, amíg gyors és tiszta a gép, de mindegy, hogy Comodo CIS, AVG, Avira, Panda, kisfaszom, ezek az antivirus-persomal firewall-kombók csak részben tudják bestoppolni azokat a lyukakat, és szavatolni azt a biztonságot, amiket az oprendszernek kellene.

Na de kit érdekel mindez? Csak kritikus környezetben számít nem? Na, akkor baktass be mondjuk az egyetemre, és kérdezd meg a tőgyarcú fogalmatlan bambaborjú TO-sok egyikét, hogy szerintük miért baj, ha az éjsötét ostobaságuk miatt szinte bárki úgy le tudja szedni tőlük a személyes adataidat, személyes adatok körébe nem tartozó ún. külőnleges adataidat, mint a szoctám-, laktám- és egyéb száz éve beadott kérelmek minden faszom adattal együtt, amiről nem szeretnénk, ha egy leendő munkáltatónknál vagy egy minket nagyon nem szerető arcnál landolnának.

Ilyen auditot persze lehetne csináltatni mondjuk ITsec-es kollégával, cseréba ha én is megcsinálnám az övét mondjuk, viszont ad 1: jogilag az adatgazda beleegyezése, azaz mégcsak nem is a TO-vezér, hanem a dékán beleegyezése kellene hozzá, amelyiknek mire reggelig elmagyaráznád, hogy miért szükséges ez, úgysem egyezne bele,  mivel nem hinné el, hogy az audit eredményét valóban megtartjuk magunknak. Ad2: ha az egyetem v adatvédelmi szempontból máshogy balfasz munkahelyről vagy központi költségvetésből dolgozó munkahelyről olyan adatod kerül ki, ami súlyos hátrányt okoz, sanszos, hogy még ha feljelentést is tennél, a dolog nem jutna el a vádemelési javaslatig sem. VISZONT, ha Te csinálnád az egészet előzetes tájékoztatásuk nélkül tesztelésként, akkor esetleg Téged kiáltanának ki szarkavaró veszélyes haxorbűnözőnek...

Erre mondtam korábban, hogy hiába alakították át a személyes adatok körének meghatározását, azok védelmét, na meg hiába van minden, vattacukor-törökméz a 2013-as ibtv. szerint, na meg az ibtv-ben nem szabályozott törvények szerint, amíg nem száll ki vmilyen hatóság ellenőrizni NAV-os stílusban és bírságol hatalmasakat, a legtöbb helyen szart sem ér a teljes jogi szabályozás, hiszen ahol kell, nem a törvény miatt szigorú az adatkezelési policy, hanem azért, mert elemi érdek, egy kórházat vagy egyetemet meg miből bírságolnának, úgy mégis?

Jó messzire jutottam onnan, hogy az oprendszer kényelme hogyan kapcsolódik ahhoz, hogy az mennyire jelent veszélyt a kezelt adatokra, ami sajnos már rég túlterjed az önveszélyes, 10 éve ugyanazt a freemail-es jelszót használó TO-s néni/kiscéges képesítetlen rendszergazda/kisvállalati képesítetlen rendszergazda adatain, mivel el tud érni bárkiről bármit - és rajta keresztül más is. Pozitív példák persze vannak Magyarországon is a helyes adatkezelési politikára, egy-egy egyetem egy-egy kis részén, de ez inkább ritkaság.

A KÉRDÉS: olcsóbb lenne még az adminisztratív dolgozók elé is bekúrni egy almás gépet vagy egy rommá távfelügyt windowsosat [ilyenre ésszerű megoldást nem is tudnék, hiszen munkaidőben mindenki kolbászol a neten arra is, amerre nagyon nem kellene] pluszba elkergetni őket ITsec awareness tréningre; Vagy pedig az lenne az olcsóbb, ha tényleg lenne egy olyan szerv, amelyik olyan zaftos bírságokat szabhatna ki egy-egy ellenőrzés után, hogy egyrészt az adatkezelő az alkalmazottait befenyítené vagy kirúgná, ha kell, fosva a bírságtól, aztán rögtön változna a hozzáállás? Ja, ugyanezt kellene akkor is, amikor bizonyítható, hogy a tökkelütött alkalmazott egy ransomware-támadást igenis megúszhatott volna. 

Ha szakmán kívüliként olvasod ezt és elbagatellizálva arra gondolsz, hogy mi ebben a para, alighanem újragondolnád, ha egy megpályázott melód mondjuk azon csúszna el, mert a cég egy adatbrókeren keresztül 1 nap alatt kicibálta például azt az infót, hogy elsős egyetemistaként kérvényt kellett beadnod a TO-ra, mivel annyira szétcsaptad magad piával és kábszival egy hétvégi bulin, hogy detox/trauma lett a vége, aztán emiatt nem tudtál bemenni gyakorlatra vagy vizsgára. De az is guszta, ha tudják, hogy ezer éve szoctámért kibeszélted az egész családod, amiből következtethetnek arra, hogy full alkalmatlan lennél majd minimálisan is kényes adatok kezelésére.

Biztos a leggyűlöltebb törvényhozó lennék, de tényleg nem látszik más megoldás, mint a bírságoltatás.

IDC IT Security Roadshow 2015

Az IDC nemrég rendezte meg a 2015-ös IT Security Roadshowját, ami nem csak hazai pályán volt az egyik legjobb ITsec rendezvény, amire ellátogattam.

Ha valaki követi az informatikai biztonsággal kapcsolatos híreket, különböző konferenciák témáiban igen nagy az átfedés fedezhető fel, amiben viszont már jelentős különbségek vannak, hogy egy-egy témában a
vendégek tudásához mennyit tud hozzáadni egy-egy előadás, ilyen szempontból pedig az IDC kitett magáért. Több húzónév is volt az előadók közt, akik olyan naprakész és pontos információkat tudtak mondani  különböző fenyegetések gyakoriságáról valamint természetéről, amit máshonnan nem igazán lehetett volna beszerezni és persze konkrét megoldásokat is ajánlottak ezekre a fenyegetésekre. Minden előadáson ugyan nem tudtam ott lenni, amin voltam, tényleg kiváló volt.

Csósza Lászlótól előadást hallhattunk a 0 day-eket kihasználó kártékony programok elleni védelem  lehetőségeiről, ami egyre fajsúlyosabb a különböző gyártók számára, nem véletlenül: egy-egy zero-day sebezhetőség, azaz olyan, biztonsági szempontból kihasználható programhiba, amit még nem bugreportoltak és javítottak, ilyen módon sokkal nehezebben azonosítható, mint egy vírusdefiníciós adatbázisban például szignatúra alapján felismerhető kártevő vagy tipikus, jól ismert betörési kísérletre jellemző események azonosítása, kihasználható lehet a malware-ek számára is. Az előadásból kiderült, hogy a vállalatok 84 százalékánál nyitottak már meg fertőzött csatolt fájlt tartalmazó emailt, ahogyan az is, hogy a már ismert malware-ek 0,7%-a is átmegy a hagyományos antivírus-termékeken, míg az ismeretlen malware-ek közül körülbelül az összes 5%-a jut át, a kártékony kódok legnagyobb része márpedig email-csatolmányként  érkezik a vállalati hálózatokba. Ami már elgondolkodtatóbb adat, hogy néha 79 perc telik el a 0day-t
kihasználó malware települése és azonosítása közt, így érthető, hogy miért egyre égetőbb a kutatók számára, hogy valamiféle megoldást próbáljanak nyújtani a problémára.

Hozzáteszem, a malware-ek jókora része ma már különféle trükköket vet be annak ellenőrzésére, hogy valódi, éles környezetben, operációs rendszeren fut-e vagy éppenséggel még csak az antivírus-termék által kialakított virtualizált környezetben, viszonylag elkülönített helyen, az ún. sandboxban - például úgy, hogy megpróbálja megfigyelni, hogy van-e a felhasználói magatartásra általánosan jellemző egérmozgás.

A CheckPoint ún. Threat Extraction technológiájának a lényege, hogy például PDF állomány esetén a dokumentumot gyakorlatilag másik PDF-dokumentummá nyomtatják ki, így csak a tényleges tartalom marad benne, majd ez jut el a címzett gépére, nyilván, az esetlegesen kártékony kód nélkül. A bemutatott megoldás megtartja az eredeti dokumentumot is, mindenesetre egy nagyon hatékony technológiának tűnik egy olyan környezetben, ahol - valljuk be - az alkalmazottaktól nem várható el, hogy soha nem nyissanak meg csatolmányként érkezett dokumentumot anélkül, hogy alaposan ellenőriznék annak forrását. Az eredeti dokumentum megtartása azért fontos, mert ha a konvertálás közben a felhasználóhoz kerülő dokumentum egy fontos része elveszne, még mindig előszedhető az eredeti példány. Ami bennem felmerült, például az, hogy a digitálisan aláírt dokumentumok digitális szignója a letisztított dokumentumokban [hiszen a digitális aláíráshoz elengedhetetlenül hozzátartozik a dokumentum sértetlenségét igazoló ellenőrzőösszeg], de ez még mindig kisebb kockázattal jár, mintha a dokumentumok threat extraction nélkül kézbesítődnének. Abban az esetben, ha a szoftvermegoldás csak a vélhetően kártékony elemeket próbálja kigyomlálni a  dokumentumból, a hatékonyság csak 93%-os, amihez szervesen hozzátartozik a threat emulation is, ami lényegében a malware viselkedését próbálja elemezni és az adminisztrátort képes riasztani szükség esetén. Amellett, hogy ilyen összetételű sandboxing megoldás csak ebben a termékben fordul elő, mindenki számára érdekes lehet, hogy ingyenesen elérhető webes alkalmazás is van a dokumentumok ellenőrzésére, ami a www.threat-cloud.com címen érhető el.

Ha már malware - ezt követően Gyenese Péter előadásában elmondta, hogy az IBM QRadar biztonsági  megoldásában az alkalmazások működése közben olyan naplóállomány készül, ami rögzíti annak szinte minden mozzanatát, az így készült óriáslogokat pedig aztán automatizáltan lehet kielemezni és időben  azonosítani a fenyegetéseket.

Hirsch Gábor előadásában a kritikus infrastruktúrák védelméről és a Fortinet tűzfalmegoldásairól beszélt,  persze a tűzfalak már jóideje sokkal okosabbak, mint a hagyományos értelembe vett tűzfalak. Szóba került, hogy 250-nél is több szakértőjük folyamatosan dolgozik, a 2014-es év utolsó negyedévében 150 terabyte méretű fenyegetési mintázatot tároltak és a folyamatosan növekvő elosztott adatbázisok alapján alakítják ki az ügyfeleknél többek közt az IPS [behatolást megelőző] szabályrendszert, külön az alkalmazások   biztonságára vonatkozó szabályokat. Persze olyan megoldások kidolgozása a cél, ami egyrészt az ipari vezérlő rendszerek kiszolgálásához egyrészt iparág-specifikusak, másrészt extrém működési körülmények  közt is megbízhatóan működnek, ezen kívül időben képesen az észlelt eseményeket továbbítani a Fortinetnek és annak ügyfelei felé.

A CrySystől  Bencsáth Boldizsár a legkifinomultabb fenyegetésekkel kapcsolatos trendekről beszélt, az APT, azaz Advanced Persistent Threat a saját meghatározásom szerint olyan kifinomult, célzott, professzionális fenyegetetés, ami tipikusan sok ideig rejtve marad, alapvetően több komponens  működtetésével okoznak kárt ún. C&C szervereken keresztül a bűnözők.

Az előadás legfontosabb mondandói közt volt, hogy gyakorlatilag a cyberwar, azaz a sokszor kormányzati szervekhez, államokhoz köthető támadások és a cyber crime, ami bűnözői csoportok által indított támadások gyűjtőneve, két olyan kategória, amik közt már nem csak, hogy nem érdemes, sokszor nem is lehet különbséget tenni. Többek közt, mivel sokszor nagyon hasonló vagy azonos exploitokat használnak, az APT-k nagyon nagy része közt a kiigazodás már szinte lehetetlen, az anti-APT rendszerek pedig rendszerint költségesek és nem működnek túl nagy hatékonysággal.

Egyébként a CrySys csapata volt annak idején, amelyik a világra úgy igazából ráijesztő kártevőnek, a  Stuxnetnet a kistestvérét, a Duqu-t azonosította, a teljes sztoriról egyébként erre olvasható egy egészen kimerítő cikk: https://firstlook.org/theintercept/2014/11/12/stuxnet/

Az IDC tényleg kitűnően eltalálta a legfontosabb témákat és megtalálta a témákhoz a legjobb előadókat.

Different culture, different issue

via (Young Americans for Liberty, FB)

Ultrapara: See invisible motion, hear silent sounds. Cool? Creepy? We can't decide