"A kormány szerint hackertámadás miatt állt le a koronavirus.gov.hu"

Fórumok

https://444.hu/2020/03/16/a-kormany-szerint-hackertamadas-miatt-allt-le…

"Dömötör Csaba, a Miniszterelnöki Kabinetiroda államtitkára az oldalán azt írta, hogy a mostani tudásuk szerint a leállást „kívülről indított terheléses támadás okozta”."...

Hozzászólások

Érdekes, Drupal fórumok szerint az elfogyott helyre írja ezt a hibát, mert nem tud lock fájlt létrehozni...

Ez a másik hiba, ami előfordult, de ez emlékeim szerint később jött már elő, ennek a 'max_allowed_packet' növelése a megoldása, vagy a kapkodásban elbaszták vagy valamit változtattak, ami miatt kevés lett a korábban működő méret. :)

Elmondom mi volt.

Leraktak egy 10 éves desktop PC-t 1.5 milla + ÁFA áron.

Ráhúztak next-next finish-sel egy drupal-t.

Az eddig bírta.

Amikor beborult, a Vérpisti BT egy gyors gugli után rájött, hogy elbaszta, de az RCA-ba Fawkes maszkos gonosz hekkereket írt, mert azt úgyse éri utol senki.

Majd megírta a számlát helyreállításról és hardeningről.

van 1 sztorim.

pizzát akartunk rendelni de már untuk az ismerős helyeket.

kolléga talált újat, leadta a rendelést.

2.5 óra múlva rájuk csörgött, WTF?

mondták, hogy debreceni pizzéria, nem szívesen hoznának ki 5 pizzát Bp-re. :D

kívülről indított terheléses támadás okozta”.

Meg akarták nézni az oldalt a zemberek :)

Az elmélet az, amikor mindent ismerünk, de semmi nem működik. A gyakorlat az, amikor minden működik, de senki nem tudja, miért.

Közben kiderült, hogy hogyan: a hackerek (legalább tizen-tizenketten) összehangoltan, egyszerre kattintottak az oldalon...

ennyi kurva szakértőt basszátok meg. távgyógyítást és lottoszámokat vállaltok?

Aki másnak vermet ás, az stack pointer.

Baszki, kiírta az a köcsög oldal a konkrét hibát, aminek a letiltása valahol az elején van a how to secure Drupal checklist-nek. Onnan már nem nagy kunszt hibát keresni, ha az ember tudja, hogy mi a hiba.

Ennek ellenére érdeklődve várom, hogy vajon kit fognak feljelenteni, mert minden ilyen üzemeltetési hibát eddig kapásból külföldi összehangolt támadásra fogtak, aztán soha nem lett belőle semmi.

KKV-ban minden project így indul.. Azaz, mintha sosem lett volna az előző eléggé hasonló elbaszásokból tanulás. De sajnos hülye multiéknál is detto ugyanez van, csak ott a kolosszális elbaszások nagyságrendje más: elindul a kibaszott nagy ügyféllel a mégkibaszottnagyobb project. Aztán indulás után esik-kel az egész. Előkerül az összes fontoskodó középvezető köcsög, mind ugyfél, mind kivitelező oldaláról. És sajnos általában nem a kivitelező mérnök a hülye. Az ugyanis felhívta a jól látható buktatókra előre a figyelmet. Csak ha a sales-es mindent bevállalt mert az ő bónusza a megkötött eladásból jön, mire a hülye mérnökhöz kerül a meló, addigra a szerződés az említett vállalhatatlan tartalommal már aláírásra került. Azon módosítani az okoskodó "hülye" mérnök kedvéért már nem fog senki utólag. Hülye multiéknál kultúrális okai vannak h. a mérnököt a sales sohasenem kérdezi meg, csak utólag tolják a pofája elé a kész tényeket. Innentől a hülye mérnök általában abból főz, amije van. Azaz a két lába között. A lófaszt nem érdekli már ilyenkor az elbaszott szerződésben bevállalt mindenféle taposóaknák helyett taposóatombombák, a munkát valahogy össze kell gányolni.

Erre gondoltál? :)

igen. nem.

tudod hány hisztiző fejlesztővel találkoztam? hát azt nem lehet megcsinálni. hát az nagyon sok munka. hát lehetetlen. aztán mondom merre induljon. hát az ugy tuti szar, hát az ugy bonyolult, így nem lehet úgy nem lehet. mennyi munka az. CSINÁLD MÁR VAZZE! aztán csak meg lehet csinálni, csak hisztizés helyett dolgozni kellene rajta, mert a hisztivel eltöltött időt is MUNKÁRA lehetne fordítani, mert ÚGYIS AZ A VÉGE, HOGY KELL, ÉS MŰKÖDNI FOG.

a másik kedvencem, hogy hát az mennyi munka volt már, mennyi munkaóra...  mennyire bonyolult volt... jolvan, ne etess....

lehet hekkertámadás volt, lehet nem. logot kéne látni...

Aki másnak vermet ás, az stack pointer.

Úgy általában az esetek nagy részében ettől szokott elfogyni a hely és áll meg valami nagyon fontos dolog, mert egyrészt ugyanoda megy a log, ahova minden más, ha meg a minden más nem tud létrehozni egy nyomorult 0 bájtos lock fájlt, akkor megáll a fél világ, másrészt meg ugye a monitoring rendszer általában hibatűrő, már ha van. Aztán meg persze kevés az ember, azok se akarnak sokat dolgozni kevés pénzért és ezért vannak az ismert piros riasztások, amihez ha hozzájön a 101. piros riasztás, az nem mindig tűnik fel.

Annó a zuhany helyett kádat rakattam a fürdőbe, gondoltam hogy jó lenne pár csempét azért megóvni, és mondtam hogy a fugát véssék ki. Jött a szaki hogy azt nem lehet, elkértem a vésőt meg a kalapácsot, nézett csúnyán, aztán kivette a kezemből és hiba nélkül megcsinálta az összes csempénél. Ezért keresek én ennyit ő meg annyit.

ESET és Synology hivatalos viszonteladó

"Ezért keresek én ennyit ő meg annyit."

Akarom mondani manapság simán megkeresnek annyit, mint az irodistamulti informatikai középvezető. De annyit minimum, mint te.

Elavult gondolkodás azt hinni, hogy ma 2020-ban az informatikus keres(ne) jól: mióta az elmúlt 5-10 évben a hozzáértőbb kétkezimunkások kimentek londonba mosogatni a hazai pénz triplájáért, az itthonmaradt KÓKLER csürhe is árat duplázott.

Valaki aki nálam jobban ért ehhez a témához nem tudná megmondani, hogy mi a pékért nem generálnak statikus verziót egy ilyen oldalból (de legalább a főoldalból) aztán pakolják fel egy jó-közepes CDN-re? A kereső kivételével nem igazán látok dinamikus funkciót. Ha frissülnek a számok/hírek, mehetne egy új generálás, cache gyilkolás, aztán szép napot mindenkinek.

Nincs igazi indok, de szerintem némi tweak-el simán kéne bírnia egy gépnek is akár dinamikusan is, mivel tökéletesen cachelhető sql lekérdezésekről van szó.

Külföldi CDN-t én azért, ha lehet kerülném a kormányzati oldalak területén. 

de mielőtt nagyon elkezdesz ilyen szolgáltatásokat építeni, nem triviálisabb egy ilyen rohadtul nem változó tartalomnál, ha: pl generálsz egy statikus kimenetet amit újragenerálsz minden változáskor? jah és el kéne futnia egy kenyérpirítón is :)

https://goo.gl/muWzKz (digitalocean)

Persze, ha csak a contentet nézzük akkor igazad van.

De tételezzük fel a legjobbat, hogy a feladatnak része volt egy tartalom-elfogadási workflow implementálása.

Akkor azért már célszerű egy igazi CMS-t alkalmazni, amire a Drupal azért alapvetően megfelel.

Gábriel Ákos

Mindkettőtöknek igaza van. Volt nálunk a múltkor előadni Preston (a Gatsby mögötti egyik alapító arc), és megmondom őszintén: überkirály ez a technológia, de a tizedét sem nézem ki egy állami IT cégből. Egyszerűen nem voltak még olyan ügyféligényeik, ami alapján értenék egy ilyen stack mögöttes tartalmát, se a megrendelő számára nem fontos annyira se a tartalom milyensége, se a skálázhatóság és így a megbízhatóság, hogy meg tudják csinálni, illetve meg akarnák ezt rendelni.

Ez olyan, mintha mi most magyar embert akarnánk küldeni az amerikaiakkal a Marsra, holott pár köztes "apró" (évtizedes) lépés kimaradt a Pulispace és a Maszat, illetve a konkrét holdutazás és modern űrtechnológia között.

Van bőven magyarországi tapasztalat is nagy forgalmú, nagy terhelésű és nagy rendelkezésre állású rendszerek fejlesztésében és üzemeltetésében, csak az állam tett arról az utóbbi években, hogy csak az nyúl hozzá állami rendszerekhez, akár üzemeltetés, akár fejlesztés terén, akinek nincs más választása, mert nem szakmai döntéseket fognak hozni, hanem politikai döntéseket.

Ha mindent szakmai alapokra helyezünk, akkor se jó döntés minden kis munkára a legprofibbakat/legtapasztaltabbakat ráállítani.

Ez egy olyan oldal, ahol ritkán változik a tartalom, nem kell mögé egy komplett NAV rendszer,...

Azaz egy átlagos csapat (pár ember a csapatból) generált statikus oldalakkal meg tudja oldani profin. Egyszerű karbantartás, kevés hibalehetőség, nem kell mindenféle spéci tudás/tapasztalat a gyorsítótárazáshoz... CDN hálózatra feltolva egy külföldi támadás se okozhat komolyabb problémát.

(A Drupal gyorsítótárazás minőségét itt a HUP-on is tapasztaljuk.)

(A Drupal gyorsítótárazás minőségét itt a HUP-on is tapasztaljuk.)

Nem vagyok biztos abban, hogy ez a Drupal gyorstárazás minőségére utal.

Ez egy olyan oldal, ahol ritkán változik a tartalom, nem kell mögé egy komplett NAV rendszer,...

De baszki, mégiscsak mögé tették, a főoldal tömörítése, sallangmentesítése és statikussá tétele nélkül. Gondolhattak arra is, hogy "minket ez úgy se érint majd", aztán még messze nem tartunk ott, mint azok az országok, amelyek előttünk járnak két-három héttel, de már nem bírja a terhelést, a sajtótájékoztató alatt általában lassul aztán összeomlik.

Szerintem például töredéke forgalom kattint tovább a főoldalról, szóval a főoldal lehet módosításonként generált minified monolitikus HTML, bármilyen CDN-ből agresszív cache beállításokkal az összes külső library. Aki meg továbbkattint, az megy a kisebb terhelést elbíró csoffadt szarra, amit nem tudnak skálázni.

Nyilván, ha az ember kicsit se gondolkodik, akkor persze legyen egy skálázhatatlanra konfigurált Drupal az egész, aztán ha megfittyed, akkor fogjuk rá a - milyen nap van ma, hm... kedd... mit is ír keddre a kifogásnaptár, megvan - mocskos liberálisokra.

Nem néztem ezt az oldalt, de ezen miért kell _bármit_ dinamikusan generálni, per megnézés?

A választási oldallal is az volt évtizedekig, hogy az egész dinamikus belső oldalból készül ~10 percenként egy statikus snapshot, és aztán az kimegy a frontendekre, és nézegessék csak a népek azt.
 

A generált statikus oldalak további előnye, hogy nem nem kell hetente, havonta biztonsági javításokat telepíteni.

De maga a varnish, memcached,... is többlet munka, több hibalehetőség, plusz szakembert igényel.

Szóval ilyen honlapoknál egyértelműen jobbnak gondolom a generált statikus oldalakat.

Jobb lehet, de statikus motorok kevésbé népszerűek -> kevesebb tapasztal velük -> kevesebben választják, ha gyorsan fel kell állítani egy siteot + kevesebb feature-t is kínálnak (főleg multiuser kezelés, admin felület terén)

Emiatt egy frontend cache proxy kézenfekvőbb választás.

Én pl. wordpressből generálok statikus oldalt. Értem ez alatt, hogy valószínűleg akad akár drupalhoz is.

Ettől még igaz persze hogy kevesebb az ilyen felállással a tapasztalat és a többi is. Meg tény, hogy néhány plugin, amelyik nagyon ráfekszik az aszinkron működésre, az esetleg okoz fejfájást, vagy akár azt, hogy hanyagolni kell.

Meg az is igaz, hogy utólag már marha könnyű okosnak lenni :D

semmi kétség, hogy valamelyik uncsitesó kapta a melót. lesznek még ilyen bakik. itt elválik a szar a májtól. ha valaminek működni kell és a csókos kapja a munkát akkor ez van. =már ebbe is politikát látok

Jó, hát a normális embernél kb. kávéval indul a nap, a nem normálisaknál meg egy újabb ellenség haluzásával.

Van ilyen, csak ezt jobb helyen kezeltetni szokták.

Up      2020-03-17 15:41:28        OK (200)              0 hrs, 3 mins
Down    2020-03-17 15:17:56        Connection Timeout    0 hrs, 23 mins
Up      2020-03-17 14:45:34        OK (200)              0 hrs, 32 mins
Down    2020-03-17 14:34:34        Connection Timeout    0 hrs, 11 mins

nyilatkozat elott: "Te mondd, hogy 'hekkertamadas', a te hangod melyebb!" :)

Szerkesztve: 2020. 03. 18., sze - 08:46

Ennél már csak a foglalj online időpontot az "503 Service Unavailable" szolgáltatásunkon keresztül ha be akarsz jönni a jöbb. #worksforme

Vajon az e-papir megy még vagy már az is lerohadt? 

Na, most a magyarkozlony.hu kezd feküdni. Gondolom támadják ezt is.

 Down 2020-03-27 07:35:08   Connection Timeout 0 hrs, 1 mins
 Up 2020-03-27 07:28:25   OK (200) 0 hrs, 6 mins
 Down 2020-03-27 07:24:47   Connection Timeout 0 hrs, 3 mins

Ha nem mentek volna milliárdok számolatlanul a Kormányzati Felhő projektre, akkor igazad is lenne, lásd: https://kof.hu/

De közel 20 milliárd forint ment el erre a projektre, szabad szemmel is jól látható eredményekkel.

Persze, terelj csak, ahogy szoktál...

Nem, nem vettem részt, viszont ettől még elégettek egy ilyen projektre 20 milliárd forintot és képtelenek értelmesen használni.

Nem arról van szó, hogy elfogyott mind a 5300 vCPU, a 36000 GB memória és a 450 TB tárhely per site, mert hirtelen akkora felhasználói igények merültek fel, hanem nagyrészt parlagon hever az is, ami még működik és nem ment tönkre hét év alatt, de a pénz elköltve, a pecsét rányomva, a papír leadva, szokás szerint.

De szép terelés újra... szóval ennek mi köze most épp a https://magyarkozlony.hu oldalhoz és annak terhelésfüggő automatikus skálázásához?

Amúgy Drupal esetén is van lehetőség terhelésfüggő skálázásra... ez nem feltétlen pénzkérdés, az is sokat segít, ha kevés a balfasz a projekt környékén, de ez valamennyire pénzkérdés, mert ha túl kevés vagy túl sok a pénz, akkor növekszik a balfaszok aránya a projekt környékén.

Nagyszerű.

Azt gondolom tudod az üzemeltetési tapasztalatoddal, hogy egy kis forgalmú weboldal is tud napi ennyit log-ba írni... vagy úgy gondolod, hogy egy kicsomagolt/feltelepített Drupal ennyi helyet foglal és ennyi elég is az üzemeltetéséhez?

Írtam valahol is, hogy hiányzó hardver a probléma? Azt írtam, hogy elköltöttek több mint 20 milliárdot a Kormányzati Felhőre, aztán képtelenek használni arra, amire az ilyen felhő való, ezért kicsit nagyobb terheléstől hullik bármelyik kormányzati weboldal, mint az őszi légy.

És? Mi köze ennek ahhoz, hogy

a, újfent lerohadt a szokásosnál nagyobb terheléstől egy kormányzati weboldal

b, több mint 20 milliárdból építettek egy ún. Kormányzati Felhőt, hogy idézem "ezzel a megoldással az esetlegesen hirtelen jelentkező többletigények is problémamentesen kezelhetők."

Ilyenkor benned nem merül fel, hogy mégis, mi a retkes lófaszra basztak el ennyi pénzt? Ne terelj azzal, hogy de mások is elbasztak már ennyi pénzt.