Názory k článku CrowdSec: chraňte své servery a pomáhejte tvořit reputaci IP adres

That's a good point. We are completely aware and working on it. It's one of our R&D main focus right now.

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".

To není chyba CrowdSecu. Totéž se stane s jinými nástroji nebo i třeba s ručním zablokováním útočné IP na firewallu. Problém je v blokování na úrovni IP v kombinaci s množícím se CGNAT. Za to ale provozovatel služby nemůže. Pokud mu IP způsobuje problémy, jde na block list.

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

Nemusíte tu adresu hned blokovat. Pokud je to problém, můžete přijmout mírnější opatření, v článku je jich několik uvedeno.

Tak Root není charita. Jestliže mu konkrétní adresa/rozsah způsobuje problémy a tedy i náklady výrazně převyšující příjmy generované klienty z těchto adres, tak mi dává smysl, že to prostě bloknou.

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.

It is possible indeed. Use the below command and you can choose for how long you want to see the selected IPs banned.
/etc/crowdsec/pro­files.yaml

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.

Tool vyzerá zaujímavo a aj by som ho vyskúšal. Ale prečo dnes má každý nová aplikácia distribúciu cez binárky a docker image, ale na rpm/apt balíčky sa zabúda? Už to nie je in? Priveľa roboty navyše?

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.

We are currently working on RPM/APT packages, we'll release a Debian package very soon

Není poslední příklad špatně? Po instalaci a zadání:

# cscli ban list --api
Error: unknown command "ban" for "cscli"
Run 'cscli --help' for usage.
FATA[0000] While executing root command : unknown command "ban" for "cscli"

This command is wrong indeed. The correct one is:
cscli decisions list -a

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í.

<blockquote>O­vládnuté PC s měnící se IPv6 adresou zablokuje /64 a všichni ve stejné (firemní?) síti se mohou jít klouzat.</bloc­kquote>
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.

A co na to Sentinel od CZ.NICu?

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ší.

Jak chtějí zařídit, aby útočník neposlal do centrální databáze falešnou stížnost na napadení z adresy root.cz? Kdokoliv se může zapojit, tedy falešných stěžovatelů může být řada. A nejde jen o zombie počítače, úplně stačí poskytovatel bez kontroly zdrojové IP.

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.