Názory k článku Postřehy z bezpečnosti: nový typ DoS útoku na protokoly využívající UDP
-
Vladimír ČunátStříbrný podporovatelA pro ntpd autoři odkazují na bug z roku 2009
https://bugs.ntp.org/show_bug.cgi?id=1331 -
DannyStříbrný podporovatelAno, i kdyz jde o problem v jadru popsany uz v roce 1996, porad se i v roce 2024 najdou implementace, ktere to osetrene jaksi nemaji. O ty stare (davno nepodporovane) veci zas az tak nejde - ale trpi tim treba i ten zminovany Mikrotik, Honeywell, Broadcom,Brother ci WDS od Microsoftu. A mozna se najde i neco dalsiho.
A to doporuceni tam omezit komunikaci z ephemeral zdrojovych portu v obecne rovine neni az tak od veci. Zminovany
ns_client_dropportje sam o sobe pekny - bohuzel se vyctove omezuje jen na porty 7, 13, 19, 37 a 464. Zbytek to neresi...25. 3. 2024, 08:46 editováno autorem komentáře
-
Vladimír ČunátStříbrný podporovatel
Zrovna tenhle měsíc jsme to zvažovali šířeji než BIND9:
https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1507/diffsRozumné DNS servery prostě smyčku neudělají, na to takové změny potřeba nejsou, ale...
-
DannyStříbrný podporovatel
Je to stara vec. Ale k videni to je v ruznych mutacich pri utocich pravidelne a celkem casto i v dnesni dobe. A reseni, co maji u Knotu mi v tomhle svetle prijde ponekud lepsi nez vycet jen par vybranych portu ala Bind...
-
DannyStříbrný podporovatel
Ja na rozdil od vas ten realny provoz resim, pane kolego. A utoky, v nichz na strane zdrojoveho i ciloveho portu je nejaky ephemeral port zas tak neobvykle nejsou.
-
Filip JirsákStříbrný podporovatelJe dobře, že se s NVD konečně začíná něco dělat. Současný stav je neudržitelný. Na jedné straně číslo CVE dostane každý, kdo jde kolem. (Takže každý, kdo si chce říkat bezpečnostní expert, začne tím, že si nechá přidělit CVE – je jedno na co.) Na straně adresátů se vůbec nerozlišuje stav a závažnost CVE (protože se na současné údaje nedá spolehnout). Takže někdo na jakékoli CVE kašle, jiný zase odmítá jakýkoli software s aktivním CVE a je mu jedno, že je to CVE nepotvrzené a jeho závažnost, pokud by se potvrdilo, by byla 0,01.
-
holt jsme v době, kdy počet CVE je metrika, ať už pro uchazeče, tak i jako KPI pro vývojáře a stejně tak to slouží jako páka u bezpečáci.
Bohužel, dnes drtivá většina klientů požaduje v akceptaci nulu neopravených CVE, stejně tak bezpáči přestali úplně rozlišovat kontext CVE a řeší to pouze na úroveň produktu/nástroje bez ohledu na instalované části, balíčky nebo použité funkce.
Plně automatické skeny typu owasp, qualys tomu dávají třešničku na dortu a jsou schopné hlásit jakoukoliv volovinu bez ohledu na to, jestli tam ta volovina opravdu je.
Stává se to docela neudržitelné. Začínají se mi třeba objevovat reporty s desítky tisíci nalezenými zranitelnostmi, kdy ruční kontrola neodhalí ani jedinou a ty náklady na to jsou obrovské a věnujeme už více času na administrativu než reálné řešení zranitelností.
-
Filip JirsákStříbrný podporovatel
To je právě na tom to nejhorší, že to bezpečnost ve skutečnosti snižuje. Protože kapacita věnovaná bezpečnosti je daná, ale místo hledání a řešení reálných problémů se tou kapacitou plýtvá na papírování kolem nesmyslných CVE.
Pak se k tomu ještě přidá to, že vám u opensource projektu postupně různí lidé založí 5 různých issue na to, že je v tom projektu nevyřešené CVE – protože nedokážou to CVE ani zkopírovat do vyhledávače issue, aby zjistili, že už na to issue je a řeší se to. Tak nabydete přesvědčení, že by bylo nejlepší celý systém CVE zrušit a začít znovu. A to je jedna malá knihovna, jak to řeší velké projekty si vůbec nedokážu představit.
26. 3. 2024, 12:10 editováno autorem komentáře
ČLÁNKY DO MAILU