Tak řekl bych, že kritický bod, který rozhodne jestli bude projekt úspěšný nebo propadák, a zároveň ďábel skrytý v detailech, je:
4- (ONLY) The aggressive IP, the scenario name triggered and a timestamp is then sent to our curation platform (to avoid poisoning & false positives)
a jak se popere s věcmi jako sdílené a dynamicky přidělované IP, thresholdy, dynamika ban/unban time etc.
Mailové blacklisty jsou dost hezká ukázka, že to nemusí být vůbec jednoduché.
CrowdSec - aneb jak odstavit třetí svět od internetu ;-)
Vzhledem k tomu, že spousta providerů ve třetím světě používá masívně NAT, dojde tímto postupem k blokaci nebo omezení velkého množství uživatelů za stejnou (NATovanou) IP.
Konkrétní zkušenost: před lety, když ještě ROOT neměl povinné přihlašování, jsem chtěl přispět do diskuze od zákazníka v Pakistánu a byl jsem odmítnut z důvodu "spamer IP".
Není chyba CrowdSecu: není, ale činí jej to problematicky použitelným. Protože takto blokuje lidi, kteří jen shodou okolností dostali na CGNATu stejnou adresu, jako někdo napadený (v botnetu) a naopak ten, co je v tom botnetu dostane za nějakou dobu jinou adresu z poolu CGNATu.
Obávám se, že tím napácháte víc škod, než užitku - viník si z toho nic moc nedělá (má botnet), ale zato potrestáte nezúčastněné.
Myšlenka pěkná, ale s masivním NATem a přetrvávající IPv4 nepoužitelná.
15. 1. 2021, 11:38 editováno autorem komentáře
Nerozumiem prečo sa všetci boja blokovania IPčiek, keď je to bežná prax už celé roky. Pripadá mi to, že tí čo to tu kritizujú asi nevedia o čom hovoria. To že sa niekomu raz za život stalo, že sa našiel za NATom na IPčke ktorá bola niekde zrovna blokovaná je "neskutočne" veľký problém oproti úžitku, ktorý toto dočasné blokovanie malo. Netreba zabúdať, že to blokovanie nieje navždy, ale na dopredu nastavený čas, ktorý po odznení problému skončí...
Tak si to představte: někdo u stejného ISP je součástí botnetu, který zaútočí někam na vědeckou instituci. A vy si pak on-line chcete koupit jízdenku na vlak, a nemůžete, protože jdete ze zablokované adresy.
To jsou podobné faily, jako když kontrolovali počet přístupů do katastru nemovitostí a brali síťovou masku z registru sítí - takže všechny přístupy přes IPv6 via Hurricane Electric se počítaly jako jeden uživatel (vzali masku /30 místo /64).
Tohle (i kdyby to nebylo přímo blokování) trestá někoho za něco, co udělal někdo jiný někde jinde. Vůbec nic jste neudělal, už vůbec ne tomu serveru, kam chcete, a jste za to potrestán - omezen, když tedy ne rovnou blokován.
Jo, a IPv6 vám nepomůže, protože naši mobilní operátoři na to kašlou, polovina providerů taky a nakonec i státní správa (zase ta registrace na vakcinaci není na IPv6).
15. 1. 2021, 12:52 editováno autorem komentáře
A co by měl cíl útoku dělat? Zišťovat, která komunikace z dané IP je legální a která útokem? Uvědomujete si, že po něm chcete řešení PNJ? Cíli útoku je u ( ! ), že máte poskytovatele připojení lempla. Kdyby všichni místo držkování, že IPv6 vlastně vůbec nepotřebujeme, radši pravidelně kopali do ( ! ) rádobyposkytovatele rádobypřipojení, tak se to tu nemuselo řešit.
Nemá smysl jako příklad uvádět okrajový případ lemplů a jejich nepřiměřeného zásahu.
Cíl útoku tu IP adresu blokovat může, ale CrowdSec způsobí, že ji zablokují i jiní na úplně jiných službách, aniž by věděli, proč.
No a i když ví proč, a vy se pokoušíte řešit problém, tak jak to asi probíhá?
"Z této adresy jste na nás útočil tehdy a tehdy."
"Cože? Já? V žádném případě, to byl modem vypnutý - ale mě ji blokujete! Proč?"
ISP jako lempl by mohla být pravda, kdyby byla volba. Který mobilní operátor nabízí IPv6? Zatím to nesměle zkouší O2.
S tím, že by měl být větší tlak na IPv6 souhlasím, tohle celé je problém masivního NATování. Jenže to je realita. Co s tím chcete dělat? Jako v Bělorusku to ISP nařídit? Nevím. Někdy se mi zdá, že by to bylo řešením, ale když ani stát sám se neřídí svými předpisy, které mu IPv6 nařizují... To by bylo jako vyšetřování otravy Bečvy.
15. 1. 2021, 15:35 editováno autorem komentáře
Zákazníci si stěžovat můžou, ale to je v mnoha případech asi tak všechno. Onehdá mě můj ISP vlastní vinou odstřihl od mailu a trvalo 4 dny, než se to po několika urgencích uráčil opravit. Můžu být rád, když mi internet vůbec funguje, protože tady na dědině kromě mobilních operátorů nemám moc reálných alternativ.
Stejně tak jsem si marně opakovaně stěžoval na to, že naše obec oficiálně navádí občany, aby si do počítače nainstalovali backdoor (https://www.streliceubrna.cz/jak-pouzivat-verejnou-wifi-sit-na-uradech-obce-strelice/d-3435/p1=7574). Firma spravující obecní síť dělala mrtvého brouka, vedení obce stejně jako skoro všichni ostatní dané věci vůbec nerozumí a nakonec měli všichni úplně jiné starosti kvůli COVID-19.
A to se nacházíme v jedné z vyspělejších zemí. Myslet si, že běžný uživatel kdoví kde bude se svým ISP řešit blokování IP adres, přechod na IPv6 a nekompetenci jeho personálu, je značně optimistické. Dle mých zkušeností ze zdejších končin ještě tak nejlépe funguje "poraď si sám" a zároveň se snažit zbytečně nekomplikovat život ostatním uživatelům internetu.
Hi all. We were finally able to create an account and are now happy to answer your questions (in English - we can't speak Czech we are afraid).
We highly recommend users to always take the “softest” remedy, a smarter remediation than just drop/block. If you deal with a threat on an HTTP layer for example, send a captcha, this will not block other innocent people behind a NAT IP
Any IP can be used to give access to a large number of users. Think of a large corporate network allowing 35 000 users to surf the net through 4 proxies for example. If you ban one IP, you could block some of the 34 999 legitimate users to stop just one hacker and that would be overkill. Users behind those IPs are not always the same and blocking the IP is not a real option neither an efficient remedy.
To avoid these problems, CrowdSec uses several mechanisms. One of them is to only keep an IP for 72 hours in the database. If this IP hasn’t shown any sign of further aggressivity within this timeframe, we consider it has been cleaned or that it was a variable IP, and it’s removed from the blocklist.
Please see my answer below. Besides this, we give the opportunity for people to unban themselves. If the IP behind attacks was cleared from the security breach that probably led to nefarious actions, we have no reason to keep it in our database forever. It could also happen that the Consensus unrightfully evaluated an IP as dangerous. But we cannot ignore the fact that hackers themselves may want to unban themselves. That is why the first removal will be made within 24 hours. The second query to unban the same IP though will take more time. And the third one even more time. This is made to prevent hackers to unban themselves too easily. The Captcha required will also chill out attempts to clear a large number of IPs in an automated way. Any IP that wasn’t spotted for at least 72 hours will also be automatically be cleared without the need for admins to unban themselves.
mně tohle asi nevadí, v golang to je poměrně standardní. Udržovat rpm/apt repo není vůbec sranda, těch druhů distribucí a dalších metadat, které k tomu musíš držet je docela dost. K tomu manipulace s GPG klíči, takhle nechá distribuce na docker hubu a githubu.
Mám raději, když balíčky udržuje samotná distribuce a dostat tam nový SW nějakou dobu trvá, nechci mít pro každou aplikaci samostatný yum/apt repo, to přináší ještě více problémů.
Naopak stáhnout si ručně .rpm, .deb balík a přímo ho nainstalovat vlastně nic nepřináší, kromě toho, že mi na serveru zůstane nesledovaný a neaktualizovaný SW.
Osobně nemám problém si balíčky prostě z go připravit, naopak mi to dává poměrně slušnou volnost, mohu udržet systém jednotný, ve firmách spravujeme stejně vlastní repo a celé to dobře zapadne do infrastruktury.
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í.
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.
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.
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?)
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.
Nad analýzou logu běžících služeb jsme také uvažovali a do budonoucna se i možná obdoby dočkáte. Prozatím to ale nepovažujeme za zcela důležité. Struktura Sentinelu je, že ti kteří danou službu veřejně neprovozují místo ní mohou provozovat Sentinel mini-honeypoty. Na základě jejich dat jsou tak chráněni i ti s opravdovou službou.
Výhodu Sentinelu je pak centrální analýza všech záznamů - ke zpracování se tak dostanou i záznamy o aktivitě "velmi opatrných" botů, kteří zkusí na každé z obětí například jen jeden pokus o příhlášení.
Sentinel také disponuje vícero druhy minipotů (SMTP, HTTP, Telnet a FTP), dále daty z projektu HaaS a firewallových logů - skladba útočníků by tedy měla být pestřejší.
Good point.
Every network member sharing his signals gets a trust rank (TR). By consistently sending valuable and accurate information back, the TR gets better over time. A daemon reporting for months, with 100% accuracy, valuable information will eventually reach the maximum TR. Feeding the system with wrong information would result in a severe and immediate loss of TR. This mechanism is made to avoid poisoning.
All TR can partake in the consensus, but only the highest TR rank can publish to the database without needing validation from our own honeypot network. It nevertheless has to pass the test of the Canary list, meaning the IP reported shouldn’t be one of the canary. Canaries are in fact whitelisted IP, known to be trustworthy, like the Google bot, Microsoft updates, etc. If a scenario is too sensitive or twitchy, it might shoot a canary. This mechanism is made to avoid false positives.