Vlákno názorů k článku CrowdSec: chraňte své servery a pomáhejte tvořit reputaci IP adres od Petr Hudaň - Jak se takovýto typ nástrojů chová k IPv6? Blokuje...
-
nevím, jak se chová CrowdSec, podle popisu prostě mají reputaci na /128. U ipv6 limity obvykle uplatňujeme stromově, tj. něco ve stylu:
30 rps na /128
100 rps na /64
200 rps na /56
400 rps na /48
...Čísla jsou vycucaná z prstu a neodpovídají žádném reálním systému, spíše pro představu. Čekám, že na podobný princip přistoupi v budoucnu i CrowdSec, jinak ta reputace pro ipv6 bude chrátit spíše proti napadeným systému než proti systémům, které má útočník plně pod kontrolou a může měnit adresy dle libosti.
15. 1. 2021, 15:09 editováno autorem komentáře
-
Zde je právě možnost (ne nutnost; bez ohledu na Crowdsec) řešit blokování postupně - nejdříve jednu IP, při opakovaném výskytu z /64 (asi privacy ext.) celou /64, případně postupně kratší prefixy. Ale to se neliší od IPv4 až na to, že u natované 4 nemáte možnost blokovat jen někoho. Neboli jedno zařízení s více adresami filtrovatelné je, ale jedno zařízení se sdílenou adresou není.
-
Petr Hudaň (neregistrovaný)
Z toho mi vychází, že se s IPv6 oproti CGNATu nikam moc neposouváme :(. Ano, u CGNATu to je větší problém, ale následuje hypotetický scénář:
Ovládnuté PC s měnící se IPv6 adresou zablokuje /64 a všichni ve stejné (firemní?) síti se mohou jít klouzat. Tři ovládnuté PC ve třech různých /64 povedou k blokaci /56 a tedy k blokaci dalších nenakažených 252 sítí/zákazníků. A tak dále.
-
J ouda (neregistrovaný)
A přesně na tohle narážím v prvním postu, že záleží detailně jakým způsobem bude ten blacklist dělaný, jestli jde o cely rozsah nebo systém pozná že jde o izolovaná PC. Ale mám jisté pochybnosti, pokud se posílá srcip bez portu, tak to minimálně s CGNatem prostě nepočítá.
Navíc argument, že místo IP blocku tam může vyskočit captcha neberu. U mě pokud na mě vyskočí podobná buzerace (navíc s nepřehlednými privacy policy), tak to znamená že zboží už z principu koupim kdekoli jinde.
-
<blockquote>Ovládnuté PC s měnící se IPv6 adresou zablokuje /64 a všichni ve stejné (firemní?) síti se mohou jít klouzat.</blockquote>
Jenže pak je na adminovi dané sítě, aby si tam udělal pořádek. Jako sorry, ale i v domácí síti mám jednu /64 pro guest network. I když mi přijde na návštěvu někdo s napadeným Androidem, odstřihnou mi maximálně /64 a zbytek zařízení je v suchu. -
J ouda (neregistrovaný)
Tak ono je to řešitelné i rozumným způsobem, https://en.wikipedia.org/wiki/Proof_of_work , jen se bojím že reálný výsledek bude buď IP blok, nebo redirect na reCaptchu která je možná ještě horší než úplný blok ;-)
A dnes rozšířený postoj "nevymejšlejte kolo a nechte autentizaci na frameworku" tomu taky moc nepomůže. (BTW znáte nějaký framework, který něco jako PoW implementuje?)
-
Jan HrachStříbrný podporovatelMně přijde blbost vyžadovat PoW u autentizace. K čemu to je? Máte zoufale slabá hesla, která jdou uhádnout po síti? Pak řešte tento problém, ne rate limit autentizace.
-
J ouda (neregistrovaný)
Ono ani nejde o to jestli jsou hesla slabá nebo silná. Každopádně nějak musí být uložena, buď postaru v nějaké v lepším případě saltované velmi rychlé MD4/MD5 (což je katastrofa při úniku databáze), a nebo nějak moderněji (bcrypt etc). Jenže ve chvíli, kdy jedna autentizace sežere řádově desetiny core-sekundy, tak bez silného rate limitingu dostaneme obrovský DoS potenciál, což taky není žádoucí a musíte ho nějak (minimálně během útoku) řešit. Tupý rate-limiting na account/IP je z bláta do louže , a pak už zbývá buď captcha která ale otravuje uživatele, nebo tam vetknout nějakou formou PoW která může být pro uživatele u browseru transparentní, a přitom může o několik řádů celý útok zdražit.
