Előválasztás összeomlás elemzés

Fórumok

Sziasztok!

Megjelent az előválasztási rendszer összeomlásáról készült elemzés. Mivel Magyarországon ilyen széles körben érdeklődésre számot tartó rendszerről ritkán adnak ki publikusan ilyet, gondoltam feldobom vitaindítónak.

Jó? Nem jó? Mik voltak az elkövetett hibák? Hogy lehetett volna megelőzni?

https://telex.hu/belfold/2021/09/27/ellenzeki-elovalasztas-leallas-ossz…

A támadás elemzése innen tölthető le (a cikkben is szerepel)

https://ahang-static.s3.eu-central-1.amazonaws.com/uploads/fresz_ferenc…

Mivel a security-ba tettem ezért legálább nyomokban legyünk szakmaiak :)

Hozzászólások

Cloudflare védelmi rendszer

Felesleges volt tovabb olvasnom.

Error: nmcli terminated by signal Félbeszakítás (2)

A vezetoi osszefoglalo nem 83 oldal. Vagy a teljes jelentes abban az esetben 830.

Technikailag pedig túlterhelés elleni védelemre alkalmas. 

A WAF resze igen, de maga a CF nem ez, plane nem enterprise szint alatt.

Error: nmcli terminated by signal Félbeszakítás (2)

Teljes amatőrség. De még, ha ki is leakelik az ip-t, cloudflare esetén a minimum, hogy el sem fogad semmit a szervered, ami nem a cloudflare ip cimeiről jön.

Gondolom a nagy leak is annyiból állt, hogy a "szakértők" beregisztrálták cloudflare nélkül közvetlen szerver ip-re dns-ben, majd valamikor valaki szólt nekik, hogy ez nem lesz jó, akkor lecserélték az ip-t cloudflare-re. Persze ez a változtatás simán visszakereshető, mellékrava az amatőrizmus csúcsát, hogy közvetlenül is meg lehetett szólitani a szervert adja is a végeredményt.

És akkor irták valahol, hogy a forgalom 40% volt nem "legális". Azért, ha nincs 40%-nyi tartalék a rendszerben egy ilyen eseménynél, az vicc kategória. Ez nem dos volt...

Túlterheléses támadás ellen hogyan lehet megvédeni egy https szervert?

Nem vagyok a téma szakértője, de úgy hallottam, hogy kb lehetetlen saját erőből megoldani ezt a kérdést, mert időnkénti koncentrált támadásokra lehetetlen saját infrastruktúrát fenntartani. Ha mondjuk egy webes újságot akarsz csinálni, aminek az ellenzéke hajlamos IT támadásra is. Hogy csinálnátok ezt meg profin? Nem trollkodok, komolyan kérdezem.

Ez addig működik, amíg a szolgáltatódnak nagyobb sávszélessége van, mint a támadónak + valóban sokat tud segíteni, ha megfelelő módon van kezelve a bejövő forgalom (ahol a megfelelő mód lehet TCP RST gondolkodás nélkül, lassú válasz, nincs válasz stb. - attól függ, hogy éppen milyen a támadás).

Azert itt nem vittek at a DTAG teljes keresztmetszetet, maradjunk annyiban... a konkret esetrol beszelunk, aminek 120 req/sec -et siman ki kell birnia. Kizart, hogy valaha is kapott ennyit, ennyire azert nem fontos, maximum a hirerteke, reklamkent/propagandakent viszont tokeletes.

Error: nmcli terminated by signal Félbeszakítás (2)

Az egyetlen módszer, ami működik, hogy legyen nagyobb sávszélességed, mint a támadónak, hogy legalább a támadóknak azt tudd mondani, hogy "menj innen". Ha a támadótól bejövő fogalom és a "menj innen" válaszok összesen megeszik a teljes sávszélességedet, akkor az égvilágon semmit nem tudsz tenni.

Ezért érdemes erre a védelmet megvenni valakitől, akinek van nagy sávszélessége, és pl. a CDN networkök ilyenek.

Erre valok a web application firewall megoldasok. A CDN eseten ez csak egy feature a sok kozul es tavolrol sem igazi a legtobb esetben. A rate limiting, az nftables geoip extensionnal pl. sokat segit, ha az ember nem alkalmaz hasonlokat.

Error: nmcli terminated by signal Félbeszakítás (2)

Még mindig: ha a WAF megoldásod az internet fel mondjuk egy 100 Mbites vonalon néz, akkor futhat rajta bármilyen rate limiter meg nftables, akkor is kiütöm pár olyan gépről, ami viszont 10 Gbiten lóg.

Azzal egyetértek, hogy sokat segítenek az általad is emlegetett megoldások, és a konkrét esetben is valószínűleg javítottak volna a helyzeten.

A (D)DoS támadások egy elég nagy része nem a CPU/memory/diskIO erőforrásaid ellen irányul, hanem a sávszélességedet akarja megenni, hogy a legitim kérésekre se tudj válaszolni.

Ez ellen védekezni alapvetően úgy lehet, ha nagyobb sávszélességed van, mint a támadónak - és itt jönnek képbe a CDN-ek, amelyeknek nagy sávszélességük van, ezen beengedik a forgalmat, megszűrik, és a szervereidre már csak a szűrt, érdemi kéréseket engedik be, ami a sávszélességedbe belefér. Nyilván ez így végtelenül leegyszerűsített, de a modell ez, és ezt lehet akár védelmi rendszernek is nevezni.

Ami itt el lett szúrva az az, hogy nemcsak a CDN irányából volt beengedve a forgalom, hanem bárhonnan máshonnan is. Ez nem jó - a doksi alapján kb. 60%-kal alacsonyabb lett volna a forgalom, ha a más irányból jövő kérésekre kapásból egy TCP RST-vel válaszolt volna a rendszer. Ez még mindig kiütötte volna amúgy a rendszert, de eggyel bentebb lettünk volna.

Ami szomorú, hogy pl. az egyszerű gyalogkakukk webshopok, amiket csinálok ennél sokkal jobb védelemmel vannak ellátva, havi párszáz euro költségből. Annyi pénz meg volt itt is, ráadásul nem is mindig kell, csak 1-2 hónapra.

Ami viszont vidám, hogy azt írják az üzemeltetők, hogy ebből most tanultak, és ezután jobb lesz. Kíváncsi vagyok, hogy jobb lesz-e tényleg legközelebb.

Szerkesztve: 2021. 09. 28., k – 10:46

Szánalmas.
Favágó megoldás: két proxy, egyik csak Mo-i IP-ket enged be, másik a többit. Proxy egyidejű kapcsolatok száma szinkronizálva a kiszolgáló rendszerével. DNS RR a két címre. Valós szavazók 97+%-a úgy is Mo-ról lépett volna be.
Ismétlem, ez egy _favágó R1_ megoldás. De valszeg mégis jobb eredményt hozott volna, mint összehoztak.

Ha szigoruan ITs szemmel nezzuk a problemat, akkor igazad van. Azonban...

a) Mi az elovalasztas celja?

b) Hogyan illeszkedik ebbe, illetve hogyan szolgalja legjobban az elovalasztas celjat vagy celjait a szamitogepes tamogato rendszer?

Ha az a) kerdesre a reklam a / az egyik valasz, akkor vajon a b)-re melyik a jobb megoldas: 1) csendben teszi a dolgat, 2) teszi a dolgat, de bekerul a hirekbe, 3) a dolga az, hogy bekeruljon a hirekbe?

Nem valasz a kerdeseidre, de:

Az egyik legfontosabb celja egy ilyen rendszernek az adatok illetektelenek altali hozzaferhetetlensegenek biztositasa, az adatintegritas, es a vonatkozo adatvedelmi szabalyok (GDPR) betartasa.
Az elovalasztast lebonyolito rendszernek ezeket figyelembe veve -mivel epp alternativat kinal a polgaroknak- ezeket az alapveto kriteriumokat teljesitenie kellene. 
Ha az erre adott valasz az, hogy a jelenlegi kormanyzati IT rendszerek sem megfeleloek, akkor az elegge gaz...

Szigoruan maganvelemeny: 

 3) a dolga az, hogy bekeruljon a hirekbe?

Igen, mártírmarketing. De ez IT szempontbol irreleváns :) Tenyleg ne terjunk (terjek) el a szakmai vonaltol.

Error: nmcli terminated by signal Félbeszakítás (2)

Gabriel Ákos:

"Az mondjuk biztos h én - amennyire pénz van - külön raktam volna az offline szavazást kiszolgáló infrát."

+1 épp ezt/hasolót akartam írni - architech nem volt a helyzet magaslatán...

For Whites Only meeting room!

Amúgy szerintem tök érdekes architektúrát tervezni ehhez az egészhez.

Maga a szavazás hótt egyszerű dolog: jön 8 millió üzenet, ezeket kell valami nagyon perzisztens tárolóba minél gyorsabban beírni --> erre egy log típusú megoldás kell, tipikusan valami queue, a gyakorlatban meg ma a Kafka a menő rá azok közül, amit magadnak is tudsz hostolni. Ezzel biztosítod azt, hogy a leadott szavazatok jól meglegyenek megfelelő redundanciával.

A szavazatszámlálás lehet bármilyen lassú, és csak annyiból áll, hogy végigolvasod a logot, vagy elolvasod az üzeneteket a queue-ból, a gyakorlatban végigolvasod az elejétől a végéig a Kafka topicot, és megszámolod, kire hány szavazat jött. Ez nagyon könnyű.

Ami szerintem kihívás az egészben az azt megoldani, hogy egy ember legfeljebb egyszer szavazhasson, úgy, hogy se az ember adataiból ne lehessen előkeresni, hogy kire szavazott, se a szavazatból ne lehessen visszakövetni, hogy ki adta le. Ez az azonosítás az, amiben igazi kihívás van, és teljesen automatikusan és gyorsan nem kezelhető - csak azzal biztosíthatóak a feltételek, ha ez a rész direkt lassú. (Hozzáteszem: lassú != erőforrásigényes).

Erre ha van valakinek jó ötlete, akkor elmondom miért nem jó :-D

Nem vagyok elég expert ebben - tud ezek közül valamelyik olyat, hogy legfeljebb egyszer tudj bizonyítani? Jó régen volt, de emlékeim szerint többször is bizonyíthattál, és vagy nem lehetett rájönni, hogy többször bizonyítasz, vagy a többszöri bizonyításból már rá lehetett jönni a knowledgre-re.

Miért irtam volna. Versenyszfére verenyszféra vagy közbeszerzés "versenyszféra"? :D Amúgy miért írtam volna nekik , vagy akár ezeknek? A docx alapján lehet , hogy az NKI adta a szakértőt (bár ott emlékeim szerint a hálózati nyomtatókat is bennehagyták a feltöltött doksikba :)) Amúgy ezeknek így kellene kinézni? Csak mert nekem nem tűnik valami professzionális elemzésnek.

Amikor ezekkel kezdesz jönni egy "Előválasztás összeomlás elemzés"  topikban, ami nem a flame-ben van, tehát szakmai kommentet vár a nyitója, akkor az hogy kezdődik? Gyenge szorítás gyomortájékon?

Ha a flame érdekel az előválasztási betlivel kapcsolatban, akkor kérlek ide írj. Itt meg próbálj szakmai kommenteket elkövetni, ahogy az OP kérte.

trey @ gépház

Várj most ez nem szakmai? Te kezdted a nemláttakinternetet (baromiszakmai hozzászólással :)). Én csak azt hoztam fel példával , hogy ez előtt legalább egy cloudflare volt nem úgy mint tudjukhol. A docx-es szakértő minősítését is tartom, bár lehet itsec területen szakmai (erre lett volna példa a makrósexceltáblás NKI :)) Idéznéd mi volt a "flame"? :D 

Nem igazán értelek. Egyelőre több ember is arra jutott, aki átnézte az elemzést, hogy SSH brute force "támadások" meg a szokásos internetes _random_ szemét forgalom kívül nem nagyon volt más illegitim forgalom. Erre te nekiállsz megsértődni, amikor felmerül, hogy láttak-e egyáltalán internetes szerver logokat ezelőtt?

trey @ gépház

Délután sikerült elérni felsőbb vezetőt a szerverszoba-szolgáltatónál, aki azt közölte, hogy „mégis van a normálistól eltérő külföldi terhelés egy csatornán, ami reálisan megállíthatta a rendszert”. Kértünk minden lehetséges rendelkezésre álló adatot, de mindössze grafikonokat kaptunk meg, amelyen ugyan jól látszik az érintett idősávokban érkezett extrém terhelés, de nem derült ki, hogy ez milyen csatornán, honnan jött, hogyan és pontosan mire irányult (ezeket a részleteket továbbra is próbáljuk kideríteni).

Egy ilyen mondjuk nem tudom , hogyan történhet meg bármilyenszférában. :) Én ezt a 41%-ot sem értem mármint ,hogy cloudflare mögött volt és ha jól értem ennek ellenére 41% direktbe kapta. (annyira profin nem lehetett beállítva)

btw

Délután sikerült elérni felsőbb vezetőt a szerverszoba-szolgáltatónál

^^ Itt azért érdekes lehet az, hogy ki volt a "hosting" szolgáltató. Gondolom nem a "szerver logokat" kérték volna, nyilván az megvolt nekik is, hanem mondjuk egy komplexebb switch/router/miegyéb, ami a szolgáltató oldali logolás.

Erre kaptak egy grafikont és pont. Az meg hogy egy hosting szolgáltató nem tudja behatárolni azt hogy honnan milyen forgalom mikor merre megy + adott esetben ezeket nem logolja valamilyen formában hát na ... Ezt azért ne varrjuk az aHang* nyakába szerintem :)

ps.: ugye képzeld el ezt úgy, hogy hup.hu totáááális támadás alatt áll, te megkérdezed a rackfrstet (vagy nem tudom hol vagytok) hogy ugyan adjanak már valamit hogy ők a saját oldalukon mit is látnak, azt odaadnak egy grafikont hogy "tessék nagy a terhelés" :) Gondolom boldogság lenne :)

"Erre kaptak egy grafikont és pont."

Egyébként mit kellene kapni egy ilyen kérésre a szolgáltatótól? A szolgáltató loggolja a teljes forgalmát mindig? Erősen kétlem. Maximum valamilyen aggregált számai lehetnek, ez lehet a grafikon.

Ha megkérem, akkor biztos tudja rögziteni, de egyébként minek? A saját szerveremen is látom, hogy milyen ip-ről milyen forgalom jött. Mert ugye itt nem az történt, hogy kapott mondjuk 100 gigabit/sec-es szemét forgalmat, amibe belehalt a szerverük. Bejött 40%-nyi plusz kérés a legális forgalom mellé. Az semmi. Itt pont nem a szolgáltatóra kellene mutogatni, ez sima hozzá nem értés.

Nézd ezt én nem tudom, de mondjuk van a BIXben egy szollgatató aki kap XY vonalat. Ott felépít egy hálózati infrastruktúrát magának és majd a leendő ügyfeleknek.

Ott nem merülhet fel olyan hogy esetleg a fő hálózati eszközökön legyen valami logolás ? vagy bármi egyéb ? Mert ha ez nem opció akkor mindenki nyisson szerver hosztingot egy tplink routerrel azt kész.

Nagy a forgalom? Nagy! Tudjuk honnan jön ?? Jah!! a BIX kapcsolat felől.. tudjuk kik azok, nem, de itt egy szép grafikon :D 

vicc

Továbbra sem értem. A szolgáltatónak van mondjuk egy 50 gigabites vonala. Mit csinál vele? Loggolja? Hova? 400 TB naponta. És minek? Hogy meg tudja mondani, honnan jött a forgalom? Arra pont elég egy graikon, mondjuk a 10 legtöbbet forgalmazó IP-vel, melyik mekkora forgalmat generált az elmúlt 24 órában. De ebből fogalmad nincs, hogy mi fektette meg a szervered, ahhoz alkalmazás szintű log kell, ott a saját szervereden.

"Ott nem merülhet fel olyan hogy esetleg a fő hálózati eszközökön legyen valami logolás ?"

Ha konkrétan kéred, akkor nyilván tudják rögziteni, adott switch portot kitükröznek egy másik portra, ahol rögzitheted egy másik eszközzel. De ha ezt te nem kéred előre és nem fizeted meg az árát, akkor utólag teljesen irreális ilyet számon kérni a szolgáltatótól.

Én itt továbbra sem a szolgáltatót érzem sárosnak. Ne felejtsük el, nevetséges, 40%-nyi plusz forgalomról beszélünk. Ezt egy normálisan összerakott rendszeren realtime a fő szerveren nézegethetnéd, ez nem DOS, amit vissza kellene követni valahova, ez semmi.

Igen, logolja. ha 400TB naponta akkor oldja meg. Ez tényleg komoly kérdés? vagy az úgy jó neked is hogy minden eszköz logolás nélkül megy? Lehet fel lehetne ajálnkozni Kínának valami VPN szolgátatásért ...

És igen egy adott esetben akár nemzetbiztonsági érdek is lehet hogy ezek logoljanak.

Igen, de ha már felhoztad a "10" legforgalmasabb IP-t akkor a docx (lol mér nem PDF vagy valami ...) kiderül hogy itt nem 10 darab IPről szólt a történet, de ez szerinted mentesíti a szolgáltatót azon feladatától hogy figyelje és logolja a rajta átmenő forgalmat. OKés. Végülis lehetnek  ilyen "szolgáltatók" akkor szarul válaszotta ki az aHang** egybesülés a szolgáltatót. Választhatta volna a rackforestet is, akkor nem lett volna ilyen gond.

De még mindig ott tartunk hogy a szolgáltató nem produkált logokat, trey meg rámondta hogy "a cica elvitte" ... nem nem vitte el a szolgáltató nem tudott produkálni megfelelő logokat.

ps1.: tény hogy nem is kellett volna neki, ha van rendőrségi fejlenetés / eljárás, akkor köteles bármit is kiadni a szolgáltató, már ha rendelkezik ilyennel ... itt eléggé esélyes hogy nem rendelkezett, mert PistaVPS_BT volt a szolgáltató ...

Ennyi.

ps.: de itt én magam részéről le is zártam ezt az egészet, további témákra nem fogok reagálni :)

"Igen, logolja. ha 400TB naponta akkor oldja meg."

De mi a fenének loggolja? (és persze elemezze is ki azt a 400 TB-ot minden nap)

Mert néhány tökkelütött minimálisan sem tudott bekonfigurálni egy cloudflare-t? Nincs a szolgáltatónak ilyen feladata. Pont.

Nem a pistike bt-nek, a rackforest-nek sincs ilyen kötelessége, hogy letárolja a forgalmát és biztos is vagyok benne, hogy nem is tárolja le. (egyébként szerinted hány hónapig kellene megőrizze az adatokat? Gondolom egy 30 nap minimum, az úgy 12 petabyte)

Ha valami nemzetbiztonsági kérdés, akkor a nemzetbiztonság lerakja a kis eszközét a szolgáltatónál és kéri a port tükrozését.

Továbbra is állitom irreális dolgot vársz el, ingyen.

Forgalom loggolás ISP szempontból:

- Alapvetően nem nézhetünk bele az ügyfél forgalmába, (a konkrét jogszabályi rizsát mellőzve) csak olyan mélységig analizálhatjuk a forgalmat ami a hálózat működéséhez feltételnül szükséges.

- Ez a gyakorlatban vagy semmilyen naplózást/loggolást jelent (kis cégeknél), vagy NetFlow/sFlow alapú forgalmi statisztikák gyűjtését (komolyabb szolgáltatóknál). Erre opcionálisan rájöhet pluszban még valami adat gyűjtés ha konkrétan az ügyfél rendelt DDoS / WAF / akármi más védelmet a szolgáltatása elé.

- Ilyen esetekben amit a NetFlow/sFlow logokból megkaphatott volna a szakértő a szolgáltatótól: SRC/DST IP címek, portok, packet szám és octet számok, kb ennyi. (Layer3 fejléc információk flow/session-re aggregálva) ebből be lehet határolni a támadás jellegét. Sőt (amire a szolgáltatók is használják) a támadás alatt meg lehet mondani hogy melyik ügyfelet kb mivel DDoS-olják...

Nincs konkrét kommentem a konkrét ügyben. Ezt csak azért írtam le hogy tiszta legyen hogy a szolgáltatók kb mit tudnak loggolni.

Üdv:

Angelo

Nem  hasonlítottam, pusztán annyit mondtam hogyha a szolgáltató nem tud "logot" szolgáltatni akkor ne Te legyél már a felelős ....

Te hasonlítottad a fenti hozzászólásban a hupot az előválsztáshoz hah .. 

(vagy melyikben, most nem fogom visszakeresni, hogy hup-ra ˘ˇ^4235234562345 csillió ilyen kérés érkezik és mégis megy)

Szakmai cucc trey, szakmai .. de olvasd el mégegyszer.

Talán jobb ez mint egy "autós hasonlat" mégis csak web* web* IT* IT* ...

ps2: mi az hogy nincs log? akkor ezek a szarok fenti .docx*ben (lol) miből vannak? SZOLGÁLTATÓ OLDALÁRÓL SZÓLÓ LOGOKRÓL VAN SZÓ, lassan és kiemeltem mondom, hogy TE is megértsd.

Kis eselyet latom, hogy ezt megkapjuk. Pedig ezzel lehetne hitelt erdemloen alatamasztani akar az o mondandojukat, akar a mienket.

Mondjuk egy profiling report sem lenne hatrany, ha mar azt feltetelezzuk, hogy alulmeretezett volt a rendszer.

Error: nmcli terminated by signal Félbeszakítás (2)

Nem volt alulméretezve a rendszer, olyan helyre (Cloudflare-t megkerülve) is ment forgalom, amelynek csak a fejlesztők és adminisztrátorok számára kellett volna elérhetőnek lennie.

Illetve a jóég tudja, hogy miért kellett az SSH-t a publikus internetre kitenni.

Általánosságban az egész szarjuk authentikációját az Ügyfélkapura kellett volna bízni (ahogy ezt korábban a Fudánnal kapcsolatos ellenzéki konzultáción tették) így a dinamikus tartalmat szolgáltató szerver csak authentikált kéréseket kapott volna.

Erre az volt a magyarázat, hogy a személyes adatokat videós cseten, unmanaged otthoni gépeken ellenőrző alkalmi munkások feladata a Fidesz szavazók kiszűrése is egyben.

Erre az volt a magyarázat, hogy a személyes adatokat videós cseten, unmanaged otthoni gépeken ellenőrző alkalmi munkások feladata a Fidesz szavazók kiszűrése is egyben.

Ezt mégis,hogy a FIDESZ szavazókra rá van írva? :D Amúgy ha tényleg ők dobták saját elhatározásból a KAÜ-t akkor jó nagy barmok és buktak vele jónéhány szavazót akik nem szeretnek videóchatelni. :P 

Fogalmam sincs, mivel az utcát ahol lakom nem ismerte a rendszer és free text lehetőség nincs, esélyem sem volt kipróbálni.

Egy, a fejlesztésben részt vett srác mondta, hogy a nagyon feltűnően kamu szavazókat akarták kiszűrni.

Define "nem legitim". :/

A doksi alapján nagy valószínűséggel volt célzott támadás célzott időben - erre utal, hogy a szokásos "zajnál" jóval magasabb terhelést kapott a rendszer. Ez nem jelenti azt, hogy erre a forgalomra ne lehetett volna számítani (lehetett volna rá számítani), illetve azt sem jelenti, hogy ne lett volna teljesen legitim a forgalom (minden bejövő kérés, ami megfelel a HTTPS protokollnak tekinthető annak). Ezek alapján valószínűleg valaki a fejébe vette, hogy meg akarja akadályozni az oldal működését, és ügyesebb volt, mint az oldal csinálói.

Na majd meglátjuk, hogy mit tanultak ebből az üzemeltetők.

A végén a grafikonok x tengelyét elnézve kb. 5 perces átlagokat mutatnak. A támadásnál volt két majdnem négyezres peak 5 percre, egyébként 2000 alatt mozgott. Jól értem? ( őőőő... )

Szerkesztve: 2021. 09. 28., k – 17:40

Most a lopott pénz Lölö meg a hitvány kurvája esküvőjére ment el, ne várjátok, hogy működő rendszer legyen, nincs arra már keret xD

Az előválasztós oldalon van egy ilyen:

> "Elolvastam a fenti Nyilatkozatot, és minden részletével egyetértek"

Csomó bekezdés, majd két oldalra van tördelve nálam. Hogy értsek "minden részletével" egyet? Fel se fogok ennyi hülyeséget egyszerre. Ezt kötelező beikszelni ahhoz, hogy szavazhassak. Trollkodásból akartam szavazni, de ezen egy kicsit fennakadtam :-)

Elég nehéz összeszedni az információmorzsákat, hogy akkor mi is volt, mert konkrétumok, és ok-okozati összefüggés alig derül ki bárhonnan, hogy mi mikor történt és miért, de ha jól értem ennyi volt az egész:

  • Véletlenül kiderültek a cloudflare mögötti backend infra IP címei
  • Ezért le lehetett DDoS-olni az egész backendet, a támadók kitömték a backend szerverek 1Gbit linkjét
  • Nyilván ettől megfeküdt a cucc, és mivel ez ellen nem nagyon volt mit tenni, úgy döntöttek elköltöztetik a backendet, ezért kellett leállítani két napra a szavazást, hogy meg tudják csinálni a költöztetést
  • Tekertek még valamit az átköltöztetett infrastruktúrán, hogy jobban védett / skálázható legyen applikációs szinten is

Az új backendet már nem lehetett hálózati szinten DDoS-olni, hiszen nem derült ki honnan fut. Nyilván app szinten is voltak még támadások, de nagyon célzott brute force ott már nem volt, csak a szokásos, illetve/vagy app level védelmek ezt már jól kiszűrték.

"Elég nehéz összeszedni az információmorzsákat, hogy akkor mi is volt, mert konkrétumok, és ok-okozati összefüggés alig derül ki bárhonnan, hogy mi mikor történt és miért, de ha jól értem ennyi volt az egész:"

Az elején igen, csak közben lett egy elemzés az esetről. Ez alapján már sokkal több az információ.

"Véletlenül kiderültek a cloudflare mögötti backend infra IP címei
Ezért le lehetett DDoS-olni az egész backendet, a támadók kitömték a backend szerverek 1Gbit linkjét
Nyilván ettől megfeküdt a cucc, és mivel ez ellen nem nagyon volt mit tenni, úgy döntöttek elköltöztetik a backendet, ezért kellett leállítani két napra a szavazást, hogy meg tudják csinálni a költöztetést
"

A legfontosabb megállapítás, hogy nem volt DDoS, egy +70% forgalom növekedés miatt feküdt meg a rendszer:

"Kijelenthető, hogy a rendszer a nem tervezett hálózati terhelés miatt nem tudott kiszolgálni.
Támadási minták tapasztalhatóak a forgalomban, de ezek egyike sem hálózati túlterhelés, sokkal inkább a kiszolgálók és az alkalmazás sérülékenységeit letapogató próbálkozások voltak.
A megnövekedett forgalom, melynek 41%-a nem rendeltetés szerű volt, valamint a szerverek internet kapcsolatának alul méretezésé és a belső szinkronizáció hiányának együttese okozta a leállást."

A teljes forgalomban volt 41% nem tervezett és ez miatt nem tudott kiszolgálni. Mivel a 41% nem tervezett, így 59% a tervezett adatforgalom.

Ebből az következik, hogy a 41% azt jelenti, hogy +70%-al növekvő terhelés miatt omlott össze. Ez finoman fogalmazva nem az a kifejezett DDoS adatmennyiség:

41/(100-41) = 41/59 = 0,6949 = 0,7 = 70%

Előválasztás 2.0: nem vagyok az a benyalós fajta, de ilyen gördülékeny videós azonosításos szavazást szerintem sehol sem csináltak még a világon.
Írd és mondd, Kb 1 perc alatt jutottam el onnan hogy kinyitottam a böngészőt odáig, hogy Köszönjük a szavazatát.
Közben volt egy helyes kislány, aki ellenőrizte az irataimat videón.
Hajrá Magyarország, hajrá demokrácia, meg hajrá olyan miniszterelnök jelöltek, akik ki mernek állni vitatkozni a nép elé, nem csak uralkodva megmondják a tuttit!

Azért ez az online szavazás dolog annyira nem egyszerű, mint ahogy látszik: pl. meg kellene tudni győződnöd arról. hogy regisztrálták a szavazatodat, annak a jelöltnek számolták akit te szerettél volna, nem tudják visszakeresni, hogy te kire szavaztál, legkésőbb a tavaszi választásokig megsemmisítik a rólad tárolt adatokat, stb. Ezekre nincsen lehetőséged.