Crawler – pouzivate blacklist proti botom ktory skusaju exploity?

Ahojte, pouzivate nejaky blacklist proti botom ktory skusaju exploity a podobne? Nemyslim v CMS ale na urovni webserveru.

k čemu ti pomůže ho zablokovat? Pokud tam máš díru, blacklist je jen další děravá hradba, pokud ti přetěžují web, nastav rate limit.Již doba, kdy exploity zkoušely pronajaté servery, je pryč, dnes exploity na web ve velké míře zkoušejí zavirovaná zařízení a ukradené servery, jejich zablokováním můžeš postihnout běžné uživatele. Krom toho, v ČR je pořád velice běžná NAT, ve světě již tolik ne.Z jakého důvodu je chceš blokovat?Osobně všude nastavuji u http serverů rate limit podle stavových kódu, 200 a 304 povoluji hodně, 404 nebo 500 extrémně málo (cca jednotky za s). Targetuji jednak přímo /32, ale i /24 se širšími pravidly.U jednoho projektu si vedu i db vzdálených IP adres, které se ke mně připopuji a hledám v jejich komunikaci určitou pravidelnost a ty nejvytrvalejší si zobrazují v dashboard, ale nic zajímavého z toho zatím nebylo, prostě zkoušejí až se tam objeví známý systém. Rekordman dokonce jeden několik měsíců každých 5s jeden požadavek.

Můžeš se zkusit inspirovat z https://perishablepress.com/6g/

Blokovat nechcem nikoho, to nema vyznam. Len som rozmyslal nad vzorcami poziadavkov ci by to malo vyznam riesit na urovni webserveru. Len si myslim ze sledovat nove utoky by bolo dost narocne a tie pravidla by asi casom slusne narastali. Preto ma zaujima ci to tu niekto nejako riesi alebo ani nie.

Napsal TomášX;1349119

Osobně všude nastavuji u http serverů rate limit podle stavových kódu, 200 a 304 povoluji hodně, 404 nebo 500 extrémně málo (cca jednotky za s). Targetuji jednak přímo /32, ale i /24 se širšími pravidly.

Čistě z profesních důvodů bych měl otázku. Používáš k limitaci přímo možnosti http serveru (jako req_limit_zone u nginx), nebo nějaké rozšíření jako mod_security? A zahrnuješ do počítání i dotazy na statické soubory? Já většinou všechno blokuji přes fail2ban, protože mi vyhovuje, že blokuji vše jedním nástrojem. Ale uvažuji, že bych rate limiting řešil na úrovni http serveru, ale zase to tam přináší synchronní zátěž, parsování logu není tedy žádná výhra, ale je asynchronní. Tak mě zajímají zkušenosti.

snažím se vyhnout blokování přímo na webovém serveru - ne vždy je možné používat nginx či podobně schopný server, špatně se to monitoruje a sleduje, blbě se to chová v servové farmě atd. Až na pár vyjímek v podobě hw fw vše blokuji přes iptables či ipfw. Klasicky se čtou asynchronně logy, z nich se sestavují metriky a podle nich se nastavují blokovací pravidla a jejich expirace, zpoždění od requestu k případném blokování je asi do 5s.Statické soubory jsou často v CDN nebo jsou odbaveny z speciálních serverů, v tom případě se nelogují, pokud se požadavek dostane až na aplikační servery, loguje se a limituje. Každopádně na 200 jsou limity běžně ve stovkách rps, zbytek limitů ač si řeší aplikace. Mně jde tímhle o dvě věci, chci zabránit masivního skenování systému a úmyslnému přětěžování, kdekoho totiž napadne spustit si na web ab. Poté chci mít kdykoliv možnost část provozu odklonit nebo zaříznout či zpomalit.Ať se jedná o malý blog nebo aplikaci na několika serverech, vždy to navrhuji podobně, v popřetí je jednoduchý balancer s minimem logiky a firewall, v pozadí jsou poté aplikační a souborové servery. Vedle toho stojí monitoring, který právě zajišťuje pravidla do fw. Projekt od projektu měním technologie, jednou se používá nginx, jindy apache, občas haproxy či varnish či často jejich kombinace.Dělat limit přímo na webovém serveru znamená, že se požadavek dostane poměrně daleko a spotřebuje se na něj zbytečně dost zdrojů, proto raději zařezávám na fw ještě před vytvořením tcp spojení. Fail2ban je dobrý, ale špatně se řeší v clusteru (každý node má svoje data) a docela rád ucpe paměť a zablokuje celý server. Zažil jsem ddos na jeden web, kde fail2ban jsem musel killnout, protože odrovnat kompletně systém.Parsování souborů se snažím vyhnout, buď mi server přímo logy poskytuje (např. nginx je cpe přes udp ven) nebo si je přes fuse cpu rovnou do databáze, kde se rovnou zpracovávájí. Nemám rád, když logy zůstávají přímo na serveru, chci mít přehled a rovnou data ze všech částí systému na jednom místě, nemám čas a ani chuť vše procházet.