Hirdetés
-
GAMEPOD
Az összefoglalóban igyekeztünk az alapelveket összeszedni mindkét témakörben.
Új hozzászólás Aktív témák
-
Ez meglátásom szerint ott jön elő, ahol mindenki ellen érdekelt:
- vezetőség: nem akar költeni rá, mert sokba kerül és nem érdekli a biztonság, jó nekik a 20 éves technika,
- informatikus: vagy nincs tudása és csak barkácsolgatja a rendszert, vagy van valamennyi tudása és amit abból nem lehet megcsinálni az "hülyeség, minek az nekünk". -
Egon
nagyúr
A hírek szerint nemsokára jön az NKI-tól egy segédlet az OT rendszerek auditálásával kapcsolatban. Plusz ki tudja mikor, a hiányzó kettő darab SZTFH rendelet.
Btw LinkedIn-en páran olyan szinten sírnak, hogy az már nekem fáj. Nem mondom egy szóval sem, hogy nem lett túltolva a hazai szabályozás (mert de), de ettől függetlenül azért nem tartozik a megugorhatatlan kategóriába, és a hat hetes (!) auditokat vizionálók is el vannak tévedve, nem kicsit... -
Egon
nagyúr
Nem ismerem a részleteket, de az sem véletlen, hogy a bankok még mindig AS400-as cuccokkal bohóckodnak, meg Cobol fejlesztőket keresnek: egészen egyszerűen túl nagy tétel kiváltani 1-1 rendszert (és ennek szerintem semmi köze a hatékonysághoz).
A rendelkezésre állást úgy oldották meg, hogy vettek a Vaterán (!) még 2-3 db C64-et, és ott van lezsírozva a raktárban...
-
Ilyenkor azért több kérdés is felmerül bennem.
Mennyire lehet hatékony az a cég? Azért ez mégiscsak egy közel 50 éves technika.(Nem egy kalapács amivel ugyanolyan hatékonyan lehet dolgozni, a kalapács korától függetlenül). Lehet hogy sokba kerülne az új, de valszeg hatékonyabb, energiatakarékosabb is lenne.
Ha megpukkan mi lesz, beáll a földbe az egész cég? Azért egy C64-et nem olyan könnyű már leakasztani. (Jó nekünk is van egy ügyfelünk ahol inkább vettek 20 000Ft-ér 5 db használt routert tartalékba, csak ne kelljen 100 000Ft-os routert venni újonnan. Ha megpukkan elővesszük a fiókból a másikat, áttöltjük a konfigot és mennek tovább) -
"Az a baj a fejlesztőkkel, ha nem kötöm meg a kezüket, elkezdik játszani a hülyét. "
Ezen pont nem rég akadtam ki itt cégen belül. Van néhány diákunk akik épp a szakdolgozatról beszélgettek. Hogy mit kellene még beletenni tesznek bele (2FA, jogosultság kezelés, email értesítés új dolgokról, stb), meg hogy hamarosan beadási határidő. Én naiv rákérdeztem, hogy ha még csak most írjátok a fejlesztési doksit, akkor mikorra lesz ebből program. Válasz, a fejlesztési doki már rég le van adva, lassan kész van a program is, ezek csak az extra dolgok amik felmerültek, hogy esetleg beletesszük. Ez az agilis szoftver fejlesztés, van egy doksi ami nagyjából tartalmazza mit akarunk a többit menet közben találjuk ki és a fejlesztő találja ki milyen "extrák" legyenek a szoftverben.
Mondom, he? Én még azt tanultam, hogy megírod a fejlesztési doksit, ügyfél elfogadja. Addig egy betűt nem írsz a forráskódból. Ha az ügyfél áldását adta rá, akkor fogunk a kódoláshoz és csak azt csináljuk ami a doksiban szerepel. Minden ettől való eltérés plusz munka amit külön kell dokumentálni, elfogadtatni. (És persze külön számlázandó.) -
Az a baj a fejlesztőkkel, ha nem kötöm meg a kezüket, elkezdik játszani a hülyét. Példa: azt mondom, hogy a hálózati kommunikáció titkosított legyen, de ha nem mondom meg neki, hogy TLS 1.2-n belül milyen cipher suite használható, akkor belerakja az alkalmazásba a weakek támogatását is.
De ugyanezt elmondhatom MFA-ról is: ha nem tiltom le az e-mailről, neki az lesz a második faktor.Nem egyedi jelenség...
-
Ezért leszek kíváncsi rá, hogy fog-e bármi változni.
Egyrészt a jogszabályban is benne van, hogy ha legalább 5 a kiberbiztonsági törvénynek szolgáltatsz akkor rád is vonatkozik a jogszabály (persze ezen megint lehet vitatkozni kire vonatkozik). Másrészt meg ha elég sokan csesztetik a céget akkor hátha lépnek.Egyébként szerintem nem nagyon van olyan fejlesztő cég Magyarországon aki átmenne egy NIS2 auditon.
-
Egon
nagyúr
És emiatt leszek kíváncsi, hogy erre a fejlesztők hogy fognak reagálni.
Sok esetben már az kiveri a biztosítékot, amikor a szerződés megújításakor felhívom a figyelmet rá, hogy ha egy sérülékenység vizsgálat során felmerül, hogy a szoftver sérülékenységet tartalmaz, vagy egy audit során felmerül egy hiányosság, akkor azt hogyan tervezik javítani? Azt meg sem említem, hogy egy sérülékenység javítása számomra a garanciális javítás kategória, bele kell férnie a support szerződésbe.Csakhogy nem így működik a piac. Mivel nincs definiálva az "elvárt minőség" fogalma (azaz pl. hogy legalább OWASP Top10 sérülékenységeket ne tartalmazzon az a fejlesztett tákolmány), mindenki a kiírásból, a műszaki specifikációból indul ki, igyekezvén azt szűken (a lehető legszűkebben) értelmezni. Mivel az esetek 99%-ában az ár dönt az adott pályázatok elbírálásánál (papíron legalábbis - az egyéb "elhajlásokról" idő és kedv hiányában inkább nem beszélnék), sok esetben igenis erős árverseny alakul ki, amit pedig a minőség rovására igyekeznek sokan tartani. Triviális, hogy a funkcionalitásból nem engednek, a legkönnyebben a security rész húzható le. Sok fejlesztőnél egyáltalán nem triviális, hogy legyen biztonság a CI/CD pipeline-ban, max. a Sonarcube-basl bohóckodnak kicsit, esetleg statikus forráskód-elemzés történik, de hamar belefáradnak a sok false positive kiszűrésébe, így inkább ignorálják, stb.
A lényeg, hogy nincs beárazva, nincs benne az árban az ilyen jellegű support, egy kicsit sem. Főleg, ha eleve koncepciós, tervezési hibára (vagy mondjuk már nem frissülő beépülőre, aminek nincs alternatívája...) vezethető vissza 1-1 sérülékenység, és k. sokba fájna javítani. -
Ezzel teljesen egyet értek.
A problémám nekem ezzel az, hogy:
1. ugyanazt az 1000 éves szoftvert árulják tetszik nem tetszik nincs más,
2. mivel nincs más, tojnak rá, hogy az ügyfelet segítsék a jogszabályi megfelelőségben.És emiatt leszek kíváncsi, hogy erre a fejlesztők hogy fognak reagálni.
Sok esetben már az kiveri a biztosítékot, amikor a szerződés megújításakor felhívom a figyelmet rá, hogy ha egy sérülékenység vizsgálat során felmerül, hogy a szoftver sérülékenységet tartalmaz, vagy egy audit során felmerül egy hiányosság, akkor azt hogyan tervezik javítani? Azt meg sem említem, hogy egy sérülékenység javítása számomra a garanciális javítás kategória, bele kell férnie a support szerződésbe. -
Egon
nagyúr
Az EIR meg ahogy sh4d0w is írta, gumiszabály jelenleg. Hozzám az 1 EIR - 1 alkalmazás közelebb áll.
Nem gondolnám hogy ez lenne a jó irány. Tudtommal eleve félrefordítás eredménye az egész "EIR" fogalom is: a NIST 800-53 szervezetenként 1 EIR-ről beszél, általánosságban...
A valóságban el kellene felejteni az EIR fogalmát, inkább folyamatokban kellene gondolkodni, és nem megfelelőképességet, hanem - csúnya "magyar" szóval - rezilianciát kellene építeni a kötelezetteknél. Ahogy azt tőlünk nyugatabbra teszik, vagy legalábbis próbálják.
Mi azonban tipikus "magyar" módra nem a fejlődés lehetőségét, hanem a szívatás (az állami kishivatalnok "ösztönös" gyűlölete a "jól kereső, adócsaló" vállalkozóval szemben) és a könnyű, bankszektort érintő sarcolás mintájára bevezetett sarcolás (legalábbis jelentős és magas szinten) lehetőségét láttuk meg ebben.
Ahhoz, hogy ez másképp legyen, mind az államilag egy bizonyos réteg számára erősen támogatott vadkapitalizmust, mind a szocializmus kapcsolódó negatív gondolkodását (ti. hogy mindenkinek egyenlően jut a nagy közös kalapból, akinek kicsit több, arra irigykedünk) el kellene felejteni (ez meg nyilván illúzió, legalábbis rövid- és középtávon). -
Egon
nagyúr
Hadd oszlassak el pár (ezek szerint közkeletű) félreértést.
Ez a rész elég jó le van írva a kapcsolódó jogszabályokban.
1. Az auditor nem vizsgálja (nem is vizsgálhatja) az EIR-ek darabszámának, vagy kialakításuk logikájának megfelelőségét. Sőt: a teljességüket sem (azaz ha valaki úgymond nem "vallja be" a fél IT-ját, akkor az kimarad a szkópból).
2. Amit az auditor vizsgálhat (és kötelező vizsgálnia): az EIR-ek besorolásának megfelelősége (azaz valóban alacsony, jelentős illetve magas-e).
3. Ha az auditor eltérést talál ebben (ami elég nehéz, tekintettel arra, hogy sok tényező szintén gumiszabály, illetve szubjektív, lásd nagyszámú személyes adat, társadalmi-politikai hatás stb.), akkor egyrészt lefolytatja az auditot a szerződés szerint (tehát alacsony szinten), másrészt javaslattal él a hatóság felé a szerinte megfelelő besorolásra. Ezt követően a bizonyítékok és érvek megvizsgálásával a hatóság hoz döntést az adott EIR szintjére nézve. -
"...Vajon pl az 1000 éves Visual FoxPro-s garázscégek el fognak tűnni?..."
Na varj, ez csak az IT vilag, az OT meg problemasabb. Ott kvazi szabvany, hogy evtizedekig hasznalnak egy eszkozt, meg a hozza valo szoftvert es mondjuk a gyarto tamogatja 5 evig, jo esetben 8-ig...
-
"HA most tolnának egy évet a határidőn, nem lenne jobb. Egy csomóan 2026. szeptembere táján kapnának észbe."
Én annak látnám értelmét, hogy le kell szerződni IBF-re és az IBF készítsen valami "szabvány" GAP elemzést, amit a hatóságnak beküld. (Lásd OVI tábla.) A Hatóság meg válaszol, hogy ok, vettük, van 1 éved a hiányok teljesítésére, de negyedévente küld a változást, jövőre meg audit.
Az EIR meg ahogy sh4d0w is írta, gumiszabály jelenleg. Hozzám az 1 EIR - 1 alkalmazás közelebb áll.
Az audit munkák meg kicsit szerintem túl vannak aggódva, egy bizonyos mértékig lehet őket szabványosítani. Sok helyen ugyanazokat a dobozos (könyvelő alkalmazás, bérszámfejtő alkalmazás ERP-CRM rendszer, számlázó alkalmazás, ügyfél kezelő szoftver) szoftvereket használják. A szoftver tudását így csak egyszer kell alaposan átnézni, utána azt fel lehet használni sok helyen.Hasonló volt az ASP előtti időkben az állami cégeknél. Volt kb 3 cég iktató szoftvere, 4 cég pénzügyi alkalmazása, 2 cég szoftver csomagja amivel többféle nyilvántartást vezettek. Ezekkel kb 50%-át le is fedtük a szervezeteknek, ezen felül voltak a webes cuccok amivel nem kellett foglalkozni, meg az az 1-2 egyedi szoftver amit külön kellett vizsgálni.
Itt a NIS2-nél is hasonló lesz szerintem, sok esetben működni fog a korábbi audit infók ismételt felhasználása. Több lehet persze az "egyedi" szoftver (idézőjeles mert ezek többsége az ágazatra jellemző dobozos szoftverek lesznek) de szerintem itt is ki fog alakulni, hogy minden audit cégnél lesz olyan aki bizonyos ágazatra specializálódik, vagy akár az auditor cég fog specializálódni bizonyos ágazatra.Egyébként nekem furcsa csak, hogy a könyvelő cégek nem NIS2 kötelezettek? (Sem DORA, sem NIS2 alá nem tartoznak.) Pedig ott is lenne szerintem bőven teendő.
Arra leszek viszont kíváncsi, hogy a hazai szoftver fejlesztő cégeknél milyen változások lesznek. Mert tavaly még elég nagy volt az arca jó pár fejlesztónek, mikor jeleztük, hogy a szoftver enyhén szólva is problémás. Vajon pl az 1000 éves Visual FoxPro-s garázscégek el fognak tűnni?
-
Ezt szerintem senki sem tudja, de szvsz kb. az varhato, hogy ha most a regi 41/2015-nek megfelelsz, akkor az most elfogadott es 2 ev mulva kell teljesitened a NIS2 elvarasokat minden EIR-nel. Ez mondjuk akkor rohejes, ha kozbesz kotelezett vagy es a DKU-s kor legalabb fel ev (mert most eppen annyi, de javulast nem varok).
-
Egon
nagyúr
Mint NIS2 auditor cégnél dolgozó az alábbiakat mondhatom.
Nincs egzakt elfogadott elmélet az EIR-re, így ebbe belekötni nehéz. Btw a legtöbb cég azért megáll 4-5 EIR-nél szerintem, bár nyilván vannak másfajta besorolási elvek, ami szerint ugyanannál a szervezetnél lehetne 15-20 EIR-t is képezni.
Az, hogy több EIR-nél drágább az audit, valahol logikus: egy csomó kontrollt EIR-enként kell nézni, kiértékelni stb. Nem lehet független ettől az audit díja.
Btw nagyjából 2.5-3M alatt szerintem csak kb. egyszemélyes BT-nek lenne rentábilis egy ilyen audit (természetesen alap szinten, a jelentős és magas jóval többe fájna).
HA most tolnának egy évet a határidőn, nem lenne jobb. Egy csomóan 2026. szeptembere táján kapnának észbe. Inkább úgy kellene csinálni, hogy valamilyen elv alapján ketté osztani a kötelezetteket, pl. páratlan összegű cégjegyzékszámosok páratlan, a párosok a páros években lennének auditkötelezettek. -
Salex1
őstag
Szerintem irgalmatlan nagy baromság, hogy ha több EIR-ed van, sokkal drágább az audit. Így mindenki 5 alá sorolja magát, pedig lehet jóval több lenne, ha csak az elméletet nézzük.
Nem kellene hogy az árát befolyásolja.
Az meg a másik jó, hogy Audit cég, alacsony besorolás mellett is 1 hónap után válaszolt annyit, hogy nem tud már fogadni minket...
Minimum lenne +1 évet tolni a határidőn. -
Tegye fel a kezét aki ezen meglepődött.
"Az érintett cégek többsége azonban alacsony osztályba tartozik."
Legalábbis ide próbálja magát mindenki besorolni, meg hogy ne legyen 5-nél több EIR-je.A határidő megint csak problémás.
Miért nem tudtak ugyanúgy 2 évet adni mint korábban az IBTV-nél. -
Egon
nagyúr
válasz
VágniValó
#2758
üzenetére
Nem, ez inkább szabadkozás volt, ennél jobb preziket szoktam tartani.
Nem akartam mélyebben semmibe belemenni, inkább egyfajta áttekintést akartam adni az incidens-megelőzés lehetőségeiről. Nehéz úgy prezit összerakni, hogy csak annyit tudsz a többi előadóról, hogy ők is ezt a témát feszegetik majd, és azért szeretnéd elkerülni, hogy esetleg egy a másikra kísértetiesen hasonlító előadást prezentálj...
Majd legközelebb...
Btw Gyebnár Gergő és Kovács Zoli előadása elég tekire sikeredett (voltak azért olyanok a teremben, akiknek szerintem az egész kínai volt), de mindenképp hasznos dolgokat mondtak (főleg Gergő). Marsi Tamás meg nagyon jó előadó, az ő prezijét leginkább ezért érdemes megnézni. Kucsera Erika előadása is tetszett.
-
-
inf3rno
Topikgazda
válasz
sztanozs
#2744
üzenetére
Én egy kicsit más értettem browser fingerprint alatt, kb. azt, amit a javascript begyűjt, de ezen felül még a szerver is gyűjt be request headereket, IP-t, amit szintén be lehet dobni az egyvelegbe. Igazából az érdekel, hogy ennek van bármi értelme ebben a kontextusban? Mármint hogy 2FA, megjegyezteti a gépet, generálódik cookie, amit védünk ilyen megoldással...
Amúgy olvasgattam a témában, és az állt össze, hogy az utolsó belépés idejétől is függ, hogy mennyi változást engedélyezünk, illetve súlyozás helyett, mellett érdemes úgy megoldani, hogy mondjuk veszünk egy tucat paramétert, és ha 1-5 napja lépett be, akkor 1 dolog változhat az előző állapothoz képest, ha 5-15 napja lépett be, akkor 2 dolog, ha 15-30 napja, akkor 3 dolog mondjuk. Ezt csak így hasra ütésre írtam. A lényeg, hogy időtől is függ a dolog, azt írja a szakirodalom. Illetve a saját ötletem, hogy mindig az előző állapotot nézni, és menteni kell sikeres belépésnél, nem pedig a legelső állapotot, amitől akár néhány nap alatt is komolyan eltávolodhatunk ha bejön egy böngésző frissítés meg felteszünk valami új betűtípust a gépre. Még függhet a környezettől is, pl. mobiloknál elég állandó tud lenni, asztali gépeknél elég változékony, de ezt már nem raknám bele a paraméterekbe.
Állítólag találtunk erre fizetős megoldást közben, úgyhogy nem foglalkozok vele tovább.
-
Egon
nagyúr
Az Egyesült Államok kormányzata megszüntette a MITRE által működtetett Common Vulnerabilities and Exposures (CVE) program finanszírozását. A CVE Records-t a MITRE 1999 óta kezeli az amerikai kormány szerződéses partnereként, és a program kulcsfontosságú eleme volt a nyilvánosan ismert szoftversebezhetőségek nyilvántartásának. A finanszírozási szerződés 2025. április 16-án lejár, és a jövőbeni támogatás sorsa jelenleg nem ismert. A MITRE bejelentette, hogy továbbra is folytatni kívánja a program működtetését, és együttműködik a kormányzattal annak érdekében, hogy a CVE továbbra is fenntartható maradjon.
Trump most már leállhatna, de tényleg...
-
sztanozs
veterán
válasz
inf3rno
#2743
üzenetére
Fingerprinting csak annyi, hogy tobb fele letarolhato/olvashato adat van, es azok osszesseget figyeli fingerprinting es ebbol szamol egy valoszinusegi egyezest.
kiolvashato:
- window size, bongeszo agent string, os, canvas (betutipus, touch support), WebGL (videokartya, felbontas), keyboard layout, ip, mac address
letarolhato:
- Cache, LocalStore, IndexedDB, OPFS, Cookie -
inf3rno
Topikgazda
Érdekel a véleményetek egy témában. Van egy fapados 2FA email-el, és szeretném megjegyeztetni a gépet, hogy ne kelljen állandóan emailre várniuk a felhasználóknak. Kérdés, hogy ilyenkor a sütit, amiben a gépet azonosító tokent tároljuk le kell e védeni hijacking ellen pl. IP ellenőrzéssel és/vagy browser fingerprint ellenőrzéssel vagy elég ha csak elég hosszú a token, és ne foglalkozzunk a hijacking eshetőségével?
Én az utóbbi mellett vagyok, mert szerintem erősen user error, ha kikerül valaki jelszava és sütije egyszerre, mások szerint erre kimondottan szükség van, viszont nem találtam rá életképes megoldást, mert az IP változik, a browser fingerprint változik, stb. Úgy tűnik, hogy valamekkora változékonyságot tolerálni kell, és csak ha átlép egy thresholdot, akkor eldobni a tokent. Viszont erre nem találtam konkrét algoritmust, csak legendákat, hogy a PayPal is így csinálja. Gondolom itt úgy van, hogy sokféle értéket veszünk alapul, és mindegyiknek adunk egy súlyt, aztán végigellenőrizzük, de a használható súlyok olyasmik, amiket ki kell mérni. A másik ötletem, hogy nézzük meg a süti történetében az előző ellenőrzés állapotát, és ahhoz mérjük a változást, ne a létrehozás állapotához, különben bizonyos helyzetekben viszonylag hamar távol kerülhetünk a kiindulási állapottól. Pl. egyik alkalommal az IP változik, másik alkalommal a böngésző pluginek változnak, harmadik alkalommal frissül a böngésző, aztán máris túl távol vagyunk a kiindulási állapottól úgy, hogy önmagukban ezek a változások tolerálhatóak lennének. Szóval végülis megvalósítható, csak szerintem nem indokolt meg sok munka kimérni a helyes súlyokat, tűréshatárt. Tudtok ezzel kapcsolatban bármit, hogy hogyan érdemes megoldani, súlyozni? Ha van rá open source vagy fizetős projekt, az is érdekel.
-
-
-
Egon
nagyúr
Volt tegnap egy meghívásos alapon összehozott szakmai dzsembori az Íváj szervezésében, ahova az összes auditort meghívták (persze egy bizonyos kör az nem jött el, úgyhogy összesen 7 cég volt jelen, bár egy igazoltan hiányzott, szóval az egyik "nagy" is leereszkedett a plebshez...
![;]](//cdn.rios.hu/dl/s/v1.gif)
), meg ott volt pár gittegylet mint az IVSZ is, no meg azon egyetemek képviselői, ahol kiberbiztonsági képzés folyik (túl sok hozzáadott értéket nem adtak).
Sokat elmond, hogy ezen körben sem sikerült úgy definiálni az EIR fogalmát, hogy azzal mindenki egyetértsen... (Bár bíztató volt némileg, hogy azért a nagy többség egyetértett egy definícióval).
Persze a fő kérdés az (lesz), hogy a hatóság(ok) mit ért(enek) az EIR alatt... 
-
Egon
nagyúr
Vicces képek - PROHARDVER! Hozzászólások
Ezt lopom is az oktatáshoz...
-
Nagyszabású hekkertámadás érhette az Oracle-t, sok magyar cég is érintett lehet
https://telex.hu/techtud/2025/03/26/oracle-hekkertamadas-adat-szivargas-kiberbiztonsagA Forbes szerint összesen 140 ezer Oracle-ügyfél kerülhetett veszélybe, köztük a Mol, a Telekom, a 4iG, az OTP, a Budapest Bank (ami már a Magyar Bankholding része), a MÁV Informatika, az Index, az Opten, valamint a Digitális Állampolgársághoz tartozó alkalmazást fejlesztő Idomsoft is.
-
Egon
nagyúr
-
#2721
Egon
nagyúr
aprokaroka87
#2720
Egon
nagyúr
válasz
aprokaroka87
#2720
üzenetére
Ez így van...
-
#2719
sh4d0w
félisten
aprokaroka87
#2717
válasz
aprokaroka87
#2717
üzenetére
Nem küldetésünk, hogy amerikai idiótákat tanítsunk, bőven megvan nekünk a saját dolgunk máshol.
-
#2718
Egon
nagyúr
aprokaroka87
#2717
Egon
nagyúr
válasz
aprokaroka87
#2717
üzenetére
A Signal alapból egy elég biztonságos cucc, még az EU (poontosabban EB) is ajánlgatta:
Az Európai Bizottság is a Signalt javasolja üzenetküldésre - Raketa.huMás kérdés, hogy minősített információt (jó eséllyel ilyen volt az ominózus "hadititok")nem igazán elegáns ilyen módon megtárgyalni. Vannak appok (magyar fejlesztésű is akad), amelyekkel a hatóság által is engedélyezett egy mezei okostelefonon is minősített információt továbbítani, de egyrészt ezek jellemzően csak a legalacsonyabb minősítési szintű (ún. "Korlátozott terjesztésű!") minősített adat továbbítására akkreditáltak, másrészt nyilván egyéb környezeti tényezőket is figyelembe kell venni a használatuk során (pl. praktikusan nem a tömött 72-es trolin, ordítva kommunikálni ilyen érzékeny információkat).
Summa summarum: Signal-on (vagy más hasonló appon) keresztül ilyen infókat továbbítani hiba, de még mindig sokkal kisebb hiba, mint szimpla e-mailben vagy telefonon beszélni hasonlókról...
-
#2717
aprokaroka87
nagyúr
aprokaroka87
nagyúr
Miközben itt sokan kb az életük részének tekintik a IT biztonságot, addig valahol Signal appon keresztül beszélnek meg hadi titkokat...
😁
De legalább jó kis reklám nekik -
válasz
inf3rno
#2704
üzenetére
Apache-on a fail2ban konfg már tud egy kis segítséget nyújtani.
A tűzfalon a GeoIP beállításnál általában van térkép is, ahol grafikusan látszik, honnan jön sok lekérdezés.
De a tűzfalon érdemes konfigurálni az egyidejű félig nyitott tcp kapcsolatok számát automatikus lezárását.
IPS ha van szintén tud segíteni, mert általában fel tudja ismerni s DDoS-t. (Elvileg internet szolgáltatói oldalon is lehet kérni forgalom szűrést.) -
Egon
nagyúr
válasz
inf3rno
#2706
üzenetére
Volt egy jó írás valahol a neten (talán a hup-on vagy esetleg a redditen) a témában, de most nem találom.
A lényeg: alkalmazás oldalon, ha a fejlesztő hajlandó belenyúlni a kódba, ezt lehet kezelni. Pl. ha 1000 db lekérdezés van folyamatban, akkor addig nem enged új lekérdezést az adatbázis szerver irányába, amíg valamelyik be nem fejeződik. Közben várakoztat, ha valaki F5-öt nyom, a várakozás újraindul (számlálón látszik). X perc tétlenség után bontja a sessiont.
Viszont ha már a weblap lekérdezés borít mindent is, akkor szerintem webszerver oldalon kell konfigurálni valamit. -
-
Egon
nagyúr
válasz
inf3rno
#2704
üzenetére
Dinamikus vagy statikus weboldal? Apache webszerver vagy mondjuk nginx?
Ha jól rémlik, akkor lehet konfigurálni az egyidejű kapcsolatok számát, de annyira nem értek hozzá.
Mindenesetre ezt a típusú támadást tudtommal pont lehet kezelni saját eszközökkel (ha a sávszéledet eszik meg, ott leginkább csak a szolgáltató segíthet). Illetve ott a Cloudfare ingyenes, vagy legkisebb fizetős csomagja. -
inf3rno
Topikgazda
Az elv érdekelne, hogyha mondjuk van egy kezdőlap, amit 100k címről lekérnek egyszerre validnak tűnő fejlécekkel, akkor melyik címeket tiltsuk le, vagy mit lehet tenni? Most van, hogy ideiglenesen komplett országokat kitiltunk, amíg kinyomozzuk, hogy milyen konkrét címeket érdemes tiltani. Azért ez nem járható út, főleg az lenne gáz, ha itthonról jönne egy ilyen botnetes támadás.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Állítólag százmilliós tétel lenne a kiváltása.
Új hozzászólás Aktív témák
- ASUS Dual 4070 OC 12GB GDDR6X - Garanciális 2027 januárig
- B W PS PX8 jó áron eladó
- ÁÁÁ NE NÉZD MEG! A szórakozás, és a multitasking csúcsa, Lenovo Yoga 9i //3 OLED Modell Ajánló//
- UF Lenovo Yoga 9i x360 Érintős Hajtogatós Laptop Tab 14" -60% i7-1360P 16/1TB Iris Xe 2,8K OLED 90Hz
- Xbox Series X 1TB - 2 kontroller + 3 játék szabadon választható
- BESZÁMÍTÁS! Gigabyte B760M i5 14600KF 32GB DDR4 1TB SSD RX 6700XT 12GB Zalman Z1 Plus Seasonic 650W
- Azonnali A320 B350 X370 B450 X470 A520 B550 X570 chipset alaplap felvásárlás személyes/csomagküldés
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Tablet felvásárlás! Samsung Galaxy Tab S10+, Samsung Galaxy Tab S10 Ultra, Samsung Galaxy Tab S10 FE
- BESZÁMÍTÁS! Gigabyte H510M i5 11400F 16GB DDR4 512GB SSD RX 5700XT Rampage SHIVA Zalman 600W
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest