Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Ono je to tak (asi som mal tú pasáž v článku zvýrazniť). Netreba chápať fail2ban ako odpoveď na bezpečnostné hrozby. Tou zďaleka nie je. Ale určite zdržanie pre útočníka a čas pre Vás, zareagovať tu je.
1/ v tomto prípade by som skúsil navýšiť findtime, keď to z každej adresy skúsi 4x tak bude mať 1024 pokusov. Myslím, že tých 1024 oproti dennému priemeru nie je tak zlých. Tu sa už treba trochu spoliehať aj na silu hesiel.. napr.
2/ Treba si uvedomiť, že tou prvou vlnou sú väčšinou booti. Nemenia IP adresy a väčšinou to na tú službu doslova vychŕlia. Ak sa rozhodne útočiť skutočné nejaký znalec, tak fal2ban si ani neškrtne. Veľmi diskutabilná otázka je - či máte tak exkluzívný server. Väčšinou to je len o hľadaní ovečiek...
3/ už neviem čo som chcel napísať.
pokusy na přístup na děravé doplňky v redakčním systému - které tam nejsou
Jaký má smysl blokovat "útoky" na něco, co tam nemáte nainstalované?
Musíme přijmout víc uředníků abychom zvládli administrativní zátěž spojenou s jejich propouštěním.
Přijde mi, že se tu vzdalujeme od příspěvku, který toto vlákno vyvolal. O SSH tam není ani zmínka. Jde o kontrolu error logů z Apache na výskyt 404 u konkrétních (neexistujících) scriptů doplňků nějakého RS. A z toho vycházel i můj první příspěvek. Jelikož nevíme nic o tom, kdo se do onoho RS přihlašuje, uvažoval jsem v zcela obecné rovině. Takže smysl to mít může, jen ho v tom nemusíme nutně vidět. V příspěvku se také nepíše nic o tom, jestli si autor uvědomuje rizika přinášející jeho řešení, ale opět, ony rizika mu nemusí vůbec vadit.
Situace má lepší řešení - většina řešení nějakých situací bude mít ještě lepší řešení, jde o znalosti a prostředky, které daný správce má / může vynaložit. Ale opět, nevíme nic o tom, jak to přispěvatel používá a proto se nedá říct, že je to špatně, nebo správně. A proto jsem se rozhodl reagovat na příspěvek:
Jaký má smysl blokovat "útoky" na něco, co tam nemáte nainstalované?
Takže v důsledku jsem jen uvedl příklad, kdy to může mít nějaký přínos. Nebudu tu rozepisovat přesné podmínky, za kterých to má smysl a je to přiměřené opatření, ale rozhodně se nedá říct, že takové neexistuje.
Také píšete, že "Nicméně případů, kdy se hodí použít fail2ban, je nesrovnatelně méně.". Ano, to jsem ani nikde nepopřel a souhlasím s tím. Ale nemůžeme přeci vědět, že je to zrovna tento případ, když o něm nemáme žádné informace. Diskuze by se tedy měla spíše ubírat konstruktivnějším směrem - a to dotazem na okolnosti použití daného způsobu a případně připomínek, co to může způsobit a jestli to pisatele vědomě netrápí, nebo o tom vůbec neví.
Nebudu tu rozepisovat přesné podmínky, za kterých to má smysl a je to přiměřené opatření, ale rozhodně se nedá říct, že takové neexistuje.To je právě ten problém, že obhájci fail2ban a podobných řešení argumentují buď užitím, které moc smysl nedává, nebo tím, že možná za nějakých velmi specifických okolností, které nechtějí uvést, to smysl mít bude. Jenže za jistých velmi specifických okolností bude mít kladný vliv na bezpečnost serveru zakopat pod ním za úplňkové noci kořen mandragory nebo instalovat server když je Mars v konjunkci se Saturnem. Přesto nic takového většina správců nepraktikuje, protože jednak existují mnohem efektivnější způsoby ochrany serveru, jednak je plus mínus stejná pravděpodobnost, že ten kořen mandragory a konjunkce planet bude mít na bezpečnost serveru záporný vliv. A pak je samozřejmě nesrovnatelně větší pravděpodobnost, že to vliv nebude mít žádný.
Ale nemůžeme přeci vědět, že je to zrovna tento případ, když o něm nemáme žádné informace.Stoprocentně vědět to nemůžeme, ale můžeme si být dost jisti. Protože pokud by to byl zrovna tento případ a dotyčný správce by to opatření udělal vědomě, tak by zatraceně dobře věděl, v čem je ten jeho případ specifický, měl by velmi dobře zvážená všechna pro a proti, a v diskusi by to použité řešení velmi přesvědčivě zdůvodnil. To by nebylo žádné "když zablokuju dost adres, zvyšuje se pravděpodobnost, že zablokuju i nějakého útočníka".
To asi nemá smysl dál řešit, takže naposledy.
Chyba HTTP 404 znamená "stránka nenalezena". S přihlašováním to tedy nemá vůbec nic společného.
Byla řeč o děravém RS "pokusy na přístup na děravé doplňky v redakčním systému - které tam nejsou", takže to s přihlašováním má sakra co společného a jak jsem se snažil nastínit, může tou blokací omezit právě uživatele přihlašující se do onoho RS. Nikde není uvedeno, že RS běží na stejném serveru, jako obsah, který se v něm spravuje, takže se omezení normálních návštěvníků nemusí dotknout a pro správce to může být dostatečné řešení. V příspěvku bylo napsáno "je to spíš jako prevence", tak nechápu, co Vás na tom řešení tak štve. Vypadá to, že to berete jako zabezpečení proti neoprávněnému přístupu do Vaší banky. Ještě prosím, vyhněte se poučkám typu "Chyba HTTP 404 znamená stránka nenalezena". Moc dobře vím, jako většina zde diskutujících, co je 404. Poznámku o přihlašování byste asi nenapsal, kdybyste si uvědomil kontext příspěvku, kde se jasně psalo o RS (tady si také rejpnu, není to roztroušená skleróza, ale redakční systém), který asi nebude otevřený pro veřejnost bez vyžádání hesla.
Obhájci fail2ban a podobných řešení... To, že Vám to nedává smysl neznamená, že to smysl nemá! Spousta řešení je něčím specifická a rozhodně se o tom nebude správce rozepisovat, je to přeci jeho (firemní) know-how a rozhodně nemá zapotřebí ho podrobněji publikovat. Pokud si nedovedete představit konkrétní případ, kdy se to hodí, myslete si své, ale pořád to nemůže znamenat, že je to celé špatně a na nic.
Stoprocentně vědět to nemůžeme, ale můžeme si být dost jisti... To mi také přijde úsměvné . Opět, nic o tom nevíme, pisatel nemusí mít zájem na tom, abychom o tom něco bližšího věděli a rozhodně z toho nelze vyvozovat, že je to nějakej bastl, který vůbec nic neřeší. Nastínil základ řešení a každý musí zapojit fantazii. Já Vám tu také nebudu popisovat, jakým způsobem probíhá vyhodnocování hrozeb a jaké jsou automatické preventivní kroky na našem serveru.
Ani jeden z nás neznáme ani 1 % lidí nějakým způsobem se na profesionální úrovni zabývajících bezpečností serverů. Takže nemůžeme posoudit, jestli je daná myšlenka špatná, nebo dobrá. Jde mi tady o princip, říct o řešení bez bližších informací, že je špatné, je šatně. Takže tady to dopadlo tak, že někdo napíše jak něco dělá, další se zeptá na smysl, já jeden smysl nastíním a dočkám se jen úšklebku odpůrce daného řešení, který nemá žádné bližší informace a neumí si použití ani představit, přitom nenapíše jediný důvod, proč je řešení špatné a jediný způsob, jak by to řešil jinak. Ono to vlastně napsat nejde, protože tu nejsou kontextové informace, ale pak nelze ani řešení posoudit. Neznáme ani autora, takže si nemůžeme být ani "dost jisti". A i kdyby to v tomto případě bylo nevhodné, pořád to nevypovídá nic o tom, že neexistuje tuna případů, kdy je to naopak a běžně se to používá a ani o tom nevíme.
Ještě jednou připomínám, bylo zmíněno, že jde o prevenci a prevence není nikdy dost, také je to na spoustě serverů vidět.
To je tak vše, co bych rád řekl k tomuto tématu.
To, že Vám to nedává smysl neznamená, že to smysl nemá!Na to už jsem reagoval. Úplně stejné je to s astrologií nebo sázením šťastných čísel ve sportce. Existují postupy, které se slušnou jistotou dokáží prokázat, že to opravdu smysl nemá.
Ještě jednou připomínám, bylo zmíněno, že jde o prevenci a prevence není nikdy dost, také je to na spoustě serverů vidět.Ano, na spoustě serverů je to vidět, protože místo skutečné prevence jejich správci mrhají energií na fail2ban. Prevence není nikdy dost, a proto je potřeba začínat od těch kroků, které řeší útoky s nejhoršími následky. Pokud někdo ponechá přihlášení přes ssh heslem a navíc umožní přihlásit se rootovi bez hesla, a místo toho nasadí fail2ban, je to chyba v preventivních opatřeních, protože nezačal od těch nejdůležitějších. A fail2ban je v hierarchii těch opatření až někde hodně na konci.
Ja to už ani nečítam ale z toho rýchleho pohľadu vidím, že sa držíte SSH ako kliešťa.Tak to vidíte dost špatně.
to ich riešenie je tým pádom nepodlomiteľnéTo tady nikdo netvrdí.
Ja som sa za svoju prax naučil nestavať celú bezpečnosť len na nastaveniach jedinej aplikácie.To je fajn. Ale bezpečnost se nezvyšuje tím, že uděláte libovolné nesmyslné opatření, které vypadá dostatečně sofistikovaně a které znepříjemňuje život oprávněným uživatelům.
Preto ak vravíte, že máte super-bezpečné ssh a brute-force vám nevadia -- je to len Váš subjektívny postoj.Problém je, že váš postup brute-force útoku nebrání. Takže já tvrdím, že mi brute-force útoky nevadí, protože jsem provedl opatření, která podle mého nejlepšího vědomí a svědomí mají brute-force útokům bránit. Mám povolené přihlašování jen klíčem, klíče jsou dostatečně dlouhé a udržuju je v tajnosti. Vy také tvrdíte, že vám brute-force útok nevadí, ve skutečnosti ale nemáte žádnou obranu proti distribuovanému útoku.
Takže Vaše zhadzovanie fail2ban ako neúčinného a neefektívneho nástroja je len Váš subjektívný názor prameniaci z nedostatku "prežitého".Právě naopak. To, že vy si myslíte, že je ten nástroj k něčemu dobrý, pramení z nedostatku „prožitého“.
Keď sa rozhliadnete trošku aj po zahraničných fórach zistíte, že fail2ban je veľmi častým bezpečnostným prvkom u mnohých "správcov".K tomu se nemusím rozhlížet po zahraničních fórech. U mnoha „správců“ je to velmi častým bezpečnostním prvkem, podobně jako přesouvání
sshd
na nestandardní port a zákaz vzdáleného přihlášení na roota. A dalším častým bezpečnostním prvkem těchto „správců“ je, že jimi spravovaný počítač už je součástí botnetu, tak si majitel botnetu pohlídá, aby na uzlu jeho sítě neřádil někdo jiný a třeba ho neprozradil. Já se ale „správcům“ snažím vyhýbat a raději spolupracuji se skutečnými správci.
predpokladá, že všetci sú dnes za NATomNepředpokládá. Ale skutečný správce počítá i s tím, že existují lidé, kteří jsou za NATem, a že jim nemůže jen tak odepřít službu.
za každým sa skrýva nejaký záškodník, ktorý VIE, že tam mám Fail2BanOpět, když řešíte bezpečnost, musíte počítat s tím, že někde ten záškodník existovat může. Jinak to, že používáte fail2ban, nemusí nikdo vědět, a taky se to dá snadno zjistit.
vie čo musí spraviť aby odpísal službu pre všetkých ostatnýchTo je právě ten problém. Vy se bráníte útočníkovi, který neví. Já se bráním útočníkovi, který ví – protože to je silnější soupeř, a protože úspěšná obrana proti němu automaticky funguje i proti tomu slabému útočníkovi.
Je dnes kopec služieb ktoré vyslovene trpia keď sú zahltené requestami o prihlásenie a daný správca tejto služby na to jednoducho musí nejak zareagovať.Neřekl bych, že je těch služeb kopec. Ale i u těch, kde to skutečně je problém, musí správce reagovat tak, aby problém zmenšil a nevytvořil jiný. Opět, v tom je mezi námi rozdíl – vy se spokojíte s nějakou (prakticky libovolnou) reakcí, já chci, aby ta reakce byla smysluplná.
Mám sa vyhovárať na nejakého hajzlíka niekde za NATom a tvrdiť zvyšku internetu, že to kvôli nemu sú vo fronte na prihlásenie?Já tvrdím, že je potřeba udělat takové opatření, aby v té frontě nečekal nikdo a všichni legitimní uživatelé se mohli přihlásit. Vy tvrdíte, že zas tak moc nevadí, když se nějaký legitimní uživatel nepřihlásí – hlavně když budou existovat někteří, kteří mají to štěstí, a přihlášení se jim někdy podaří.
Všetko čo robím - informujem o ďalšej možnosti.Akorát jste u té možnosti bohužel zapomněl zmínit dost podstatné nevýhody. A to je to, o čem píšu od začátku. Pokud tomu někdo rozumí, uvědomuje si všechny souvislosti, a přesto se s plným vědomím rozhodne takové řešení nasadit, ať to klidně udělá, já ho budu respektovat – a když to své řešení někde popíše, uvidím to třeba z jiného úhlu pohledu a třeba usoudím, že takové řešení by bylo smysluplné i v mém případě. Třeba v této diskusi popsal své řešení Šangala, a z toho komentáře je evidentní, že ví co a proč dělá. Já mám na některé věci jiný názor, ale respektuju ho, a nebudu se s ním o to zbytečně přít. Ale vzhledem k tomu, co napsal v komentáři, nečekám, že by někomu bez znalosti situace radil „použij fail2ban, to nainstaluješ a rázem máš server zabezpečený“. Fail2ban je velmi kontroverzní řešení a má spoustu vedlejších účinků, které můžou být velice snadno horší, než problém, kterému má bránit. Právě proto by bylo potřeba v textu, který má o fail2ban informovat začátečníky, o všech těch souvislostech informovat a podrobně je rozebrat. Aby se případně čtenář mohl pro nasazení fail2ban rozhodnout na základě skutečných informací, ne na základě toho, že o fail2ban vlastně nic neví. Jenže takový text by vydal na seriál, a musel by se zabývat i takovými věcmi, jako jak náročné je navázání SSH spojení před tím, než server rozpozná, že jde o neoprávněného uživatele a spojení ukončí. Jak náročné a spolehlivé je parsování logů, jaká je reakční doba takového řešení. Jak se takové řešení bude chovat, pokud je útočník za NATem, jak v případě, kdy má k dispozici malý botnet, jak v případě, kdy si vás vybere za cíl a nasměruje na vás velký botnet. Musel by řešit, jak funguje konfigurace iptables a jak pak jádro pravidla firewallu aplikuje. Musel by řešit, jak se bude takové řešení chovat, pokud je server v DMZ a před ním je nějaký lepší firewall, který např. sleduje spojení. A také by měl třeba obsahovat nějakou statistiku toho, jak se útočníci chovají.
predpokladá, že všetci sú dnes za NATom
Ono to nemusí být rovnou NAT. Některé firmy (pochopitelně opět pod vlajkou bezpečnosti, AV kontroly apod) vyžadují přístup na web přes proxy server. (Pravým, ale nezvěřejňovaným, důvodem je pochopitelně kontrola zaměstnanců.)
Pravým, ale nezvěřejňovaným, důvodem je pochopitelně kontrola zaměstnanců.Což může být čistě pod vlajkou bezpečnosti.
A i druhá strana mince, bezpečnost firemních dat, což lze označit za šmírování, nicméně z cílem zabezpečit data/know-how (vědět co se děje), nikoliv „buzerovat“ zaměstnance. (I když i ta rozumná buzerace má opodstatněné důvody, ale nespadá už asi do ranku bezpečnost, pokud to nejsou ovšem děti, kde se jim chce připravit „bezpečný“ internet).
A jeden příklad konkrétní proxy, díky proxy, a vyhodnocování logů, bylo velmi jednoduše možné identifikovat pár strojů, co generovaly zbytečný provoz a i čím to generovali (zamotané aktualizace, které se nijak jinak neprojevily), nebo problémy s Nokia aplikacemi (stovky mega při každém připojení mobilu), či nechtěné reklamy (nechtěný plugin v prohlížeči) a v neposlední řadě opět velmi jednoduše identifikovat „multimediální“ provoz, který začal brát značnou část pásma - zaměstnanci nejsou v zásadě omezování a stačili 2-4 lidi, kde si pouštěli písničky ze seznam a youtube a megabity z linky v háji - protože to sice přehrávalo písničku, ale stahovala se videa (z random listů), nikdo nikoho nebuzeroval stačilo vysvětlit (a nikoho by ani nenapadlo, že to dělá takové zvěrstva ... třeba ten seznam). Po nasazení periodické automatické kontroly logů a získání důvěry k výsledků a tedy provedení opatření na jejich základě, klesl provoz téměř o třetinu a nikdo nebyl omezen - ba naopak. Taková analýza je jen o kliku a bez nějakých znalostí či dalších specializovaných nástrojů, a tedy i okamžité řešení a spoustu z toho může být součástí bezpečnostních opatření (o blokaci ven z důvodu bezpečnosti jsi už psal, chtěl jsem to jen rozšířit co může být či hraničit s bezpečností)…Existuje něco, co se dělá kvůli bezpečnosti a ty jsi ochoten uznat, že to tak skutečně je?
Co je to za otázku? Jistě, o tom je přece celá tato diskuse o tom, co je bezpečné a co jen tak pro efekt.
Osobně mi přijde, že zablokování škodlivých webů (= web, který obsahuje vir/exploit, je to cíl odkazu v phishingovém mailu apod.) k bezpečnosti přispívá docela hezky.
Ano, je to hezké. Jenže by se to nemuselo pokaždé (skoro ) zvrhnout na to, že "A když už to máme, tak můžeme tím sledovat, kam lidi chodí na web?" A nebo třeba na MITM i na https? (Vnucení kořenového certifikátu do všech stanic a potom ...) Nebo, firewall, který zasahuje do protokolu ssh? Kolikrát se člověk nestačí divit.
V některých firmách se dokonce sleduje (lze sledovat) to, co má dotyčný na monitoru (videostream z obrazovky).
A nebo třeba na MITM i na https? (Vnucení kořenového certifikátu do všech stanic a potom ...)Je to jediný způsob, jak kontrolovat HTTPS provoz. Krom toho ti to taky dá globální kontrolu nad tím, jakým certifikátům ve své síti důvěřuješ (proxy ověří, když se certifikát nelíbí, nepustí to.) Pokud ti jde o soukromé věci, v práci na ně nemáš lézt - tvůj problém, když to děláš.
Za relatívne bezpečné sa donedávna pokladalo aj SSL.
Možná jen máme rozdílné chápání spojení relativně bezpečné, ale v SSL se po dlouhá léta objevují chyby v implementacích, protokolech a lámou se i použité šifry a mění se délka použitého klíče. Tedy, pokud někdo SSL považoval za bezpečné (bez jakéhokoliv dalšího dodatku), tak si to sice mohl myslet, ale realita byla zcela jiná a jím nastavený server nemusel být tak bezpečný, jak by mohl být. To, že se až teď jakási chyba zpopularizovala (což je samo o sobě k zamyšlení proč vůbec a proč v tento termín) na věci nic nemění.
no prave ze ostatni uz maji vsechno dulezite nastavene, a hraji si s opatrenim na konciJo. A všichni to tady úspěšně tají a velmi věrohodně se přetvařují, aby to vypadalo, že ani netuší, co je principem brute-force útoků.
Pane Jirsák, tak si přiznejte, že prostě jen nechcete ustoupit ze svého názoru, protože je přeci správný a neexistuje možnost, že by to mohlo být jinak - alespoň tak stále vystupujete. Víte, vím moc dobře, co je redakční systém, na vývoji jednoho se dokonce aktivně podílím a věřte, že nemáte pravdu. Vaše teze s přihlašováním je pěkná, ale stále si jí upravujete dle sebe. Takže ještě jednou a polopatě nastíním zcela reálný příklad z praxe (oddělený RS) s úpravou na příspěvek, který se tu řeší:
Takže Váš první odstavec je důkaz nepochopení problému. Pokud zablokuji uživatele, je přeci jasné, že mu znemožním se přihlásit. A uživatel byl zablokován právě proto, že se z jeho IP adresy přistupovalo na 404 stránku, resp. přesně specifikovanou neexistující stránku! (pokusy na přístup na děravé doplňky v redakčním systému - které tam nejsou)
Pokud ani teď nechcete pochopit tento konkrétní příklad a nebo nechcete uznat, že to má svůj význam v prevenci, asi je něco špatně.
Jak již bylo v diskuzi níže psáno, nikdo z nás prostě neví, co je tam za další bezpečnostní prvky a je to tak dobře. Protože snad jen (s nadsázkou) blázen odhalí ucelenější řešení zabezpečení - a to bez ohledu na to, že mnoho zaměstnanců je vázáno mlčenlivostí plynoucího ze smlouvy.
Nemám proti Vám nic osobního, ale nepobírám Vaší uzavřenost myšlení. Zabednit se umí každý, kritizovat také - uznání asi dost bolí. Jak jste napsal níže, vycházíte z myšlenky, že to tu je samý laik nerozumíc problému a jen se tvářící erudovaně. Ale co když tomu tak (alespoň u některých) není? Pak z nich děláte akorát blbce, přitom to mohou být lidé na svém místě.
Jak jste napsal níže, vycházíte z myšlenky, že to tu je samý laik nerozumíc problému a jen se tvářící erudovaně. Ale co když tomu tak (alespoň u některých) není? Pak z nich děláte akorát blbce, přitom to mohou být lidé na svém místě.To jsem nepsal. Jsou tady lidé, kteří problému rozumí. Jejich práci nekritizuju, ptám se na detaily jejich řešení a proč v jejich případě zvolili zrovna nějakou variantu, která se mi nezdá nejlepší. A pak jsou tu lidé, kteří neustále opakují, že někdy možná za určitých okolností by takové řešení mělo smysl – a když z nich konečně vypadne konkrétní příklad, ukáže se, že místo toho, aby kritickou aplikaci určenou jen omezenému okruhu uživatelů zpřístupnili opravdu jenom tomuto okruhu uživatelů, vystaví ji veřejně do světa, nechají do ní bušit roboty, a pokouší se to zachraňovat blokováním IP adres. Mimochodem, i ten váš systém „vítáme 999 útočníků z 1000“ bude fungovat jedině tehdy, pokud útočník bude takový trouba, aby bezpečnostní díry zkoušel od nejstarší. Pokud logicky začne nejnovější, nabourá se vám do systému dřív, než fail2ban stihne zareagovat.
A uživatel byl zablokován právě proto, že se z jeho IP adresy přistupovalo na 404 stránku, resp. přesně specifikovanou neexistující stránku! (pokusy na přístup na děravé doplňky v redakčním systému - které tam nejsou) Pokud ani teď nechcete pochopit tento konkrétní příklad a nebo nechcete uznat, že to má svůj význam v prevenci, asi je něco špatně.
Prošel jsem si celé vlákno, přečetl jsem si váš komentář 2x a buď nám něco zásadního tajíte (což je vaše věc), nebo je to celé postavené na hlavu.
Takže, vy blokujete IP, který "útočí" (to je fakt silné slovo, prostě nějaký automat zkouší, zda na daných URL něco není, a když tam je, tak vyzkouší pár dlouho provalených zranitelností těch nejznámějších web aplikací a jde o dům dál, nic sofistikovaného v tom není) na něco, co tam není nainstalované proto, že až to tam náhodou nainstalujete (s tou známou chybou, kterou testují ty roboti), aby už byl preventivně zablokovaný? Nebylo by lepší tam ty známé chyby nemít?
Z původního příspěvku jasně vyplývá, že jsou dané IP blokovány preventivně, pokud se pokouší přistoupit na nějakou díru
Která tam není, protože je to 404
a to rozhodně ne proto, že autor plánuje instalovat tam děravý doplněk,
fajn
ale prostě proto, že je to potencionální problém s jiným doplňkem, do té doby s neznámou dírou
ehm cože?
a tito "oťukávači" mohou být s klidem zablokování, protože to pravděpodobně nikdy nebudou relevantní uživatelé stojící o danou službu.
Jinými slovy je blokujete jen tak z dlouhé chvíle. Fajn, je to vaše věc.
Sice jsem stále nepochopil v čem spočívá ona zmiňovaná prevence, ale tak co se dá dělat
a já jsem v nelibosti
Těžko můžete být v nemilosti, když komentáře píšete jako anonym.
403 Forbidden
/: 288 Time(s)
404 Not Found
/phpmyadmin/scripts/setup.php: 3 Time(s)
/wp-login.php?action=register: 6 Time(s)
/MyAdmin/scripts/setup.php: 3 Time(s)
/myadmin/scripts/setup.php: 3 Time(s)
/FCKeditor/_samples/asp/sample01.asp: 1 Time(s)
/FCKeditor/_samples/default.html: 1 Time(s)
/FCKeditor/editor/filemanager/browser/default/browser.aspx: 1 Time(s)
/FCKeditor/editor/filemanager/connectors/aspx/connector.aspx: 1 Time(s)
/FCKeditor/editor/filemanager/connectors/test.html: 1 Time(s)
/FCKeditor/editor/filemanager/connectors/uploadtest.html: 1 Time(s)
/FCKeditor/editor/filemanager/upload/test.html: 1 Time(s)
/manage/fckeditor/editor/filemanager/brows ... ctors/test.html: 1 Time(s)
500 Internal Server Error
/wp-comments-post.php: 4 Time(s)
Mě to nemusíte posílat, to se můžu rovnou podívat k nám do logů, tohle zná asi každý admin webového serveru připojeného na internet. Toto je přesně ta automatické detekce url a testy na známé chyby. Nic, čeho by se měl dobře nastavený server bát.
Otázka je postavená tak, mám čakať až dotyčný objaví nejaký zraniteľný doplnok o ktorom ja nemám vedomosť?
To žádný dotyčný není. To je automatizované skenování ze zombie počítačů nějakého botnetu. A ten botnet nemá zájem ztrácet čas nějakým skutečně sofistikovaným útokem, on má jen zájem najít co nejvíce snadných cílů (jednoduchá hesla na ssh, otevřené chyby v několika webových app). Cílem tohoto cvičení je pouze získat další zombie pro botnet, který potom někdo úkoluje například rozesílání spamů nebo ddos útoky.
Jak již bylo v diskuzi níže psáno, nikdo z nás prostě neví, co je tam za další bezpečnostní prvky a je to tak dobře.Erm...
i kdyby jenom pro ten pocit "že se s tím něco dělá"To je právě jeden z problémů. Správce získá pocit, že už toho udělal dost, a neudělá žádné skutečné bezpečnostní opatření. Vy jste alespoň na dobré cestě, když si uvědomujete, že může jít jen o dobrý pocit, který nemá žádný reálný základ.
může začít posílat pakety s podvrhnutou zdrojovou IP adresou a velice elegantně takto "odpojovat" od služby chudáky uživateleTo těžko. Aby fail2ban zareagoval tak musí dojít k navázání TCP spojení a nějaké komunikaci ohledně jména a hesla. To se běžnému útočníkovi nepovede. (A toho kdo má přístup na routery ISP vašeho serveru nebo může manipulovat BGP tabulkama toho za běžného útočníka opravdu nepovažuju).
Pokud se místo TCP používá UDP, tak tam by to mohlo reagovat už i na první paket, například u OpenVPN občas v logu vidím, že se s chybovou hláškou zahazují pakety, které očividně nepatří žádnému z připojených klientů a nejspáíš jsou důsledkem scanování portů boty.může začít posílat pakety s podvrhnutou zdrojovou IP adresou a velice elegantně takto "odpojovat" od služby chudáky uživateleTo těžko. Aby fail2ban zareagoval tak musí dojít k navázání TCP spojení a nějaké komunikaci ohledně jména a hesla.
To se běžnému útočníkovi nepovede.Pokud používáš SYN cookies, tak máš AFAIK jenom 24b seq číslo, takže se to povede po 8M pokusech. Tedy u HTTP a podobných služeb, kde není žádný komplikovaný handshake.
Čo by som však mohol je dať tam kontrolu na bežné prihlasovacie praktiky (teda či to niekto skúša cez účet nejakých služieb či účty o ktorých viem, že sa prihlásiť nemôžu (root?)).K čemu je taková kontrola dobrá? Přináší nějakou novou úroveň ochrany? Když vám pošle e-mail, co s ním budete dělat? Na e-maily reagujete 24 hodin 7 dní v týdnu, nebo počítáte s tím, že slušný útočník v noci spí?
V době různých NATů je jasné, že fail2ban často zakáže přístup spoustě uživatelů, kteří s útokem nemají nic společného.Njn, to je hloupé. Řekněte si svému ISP o IPv6. Ti, co mají tu smůlu a jsou za NATem, můžou tlačit na svého ISP, aby škodící uživatele odstřihl. Pokud vím, třeba UPC to dělá.
V případech, kdy k serveru přistupuje více uživatelů, bych fail2ban nepoužil nikdy, protože v takovém případě už o těch podmínkách, odkud se připojují, nevíte vůbec nic – takže DoS pro oprávněné uživatele by bylo velmi časté.Zkušenosti z reálného provozu vám nedávají za pravdu.
při velkém počtu selhávajících pokusů budete mít ve firewallu spoustu pravidel pro jednotlivé IP adresy, takže jejich procházení pro každý paket bude pomaléTohle není pravda:
Otázka pak je, čemu fail2ban vlastně brání. Pro útočníka dnes není problém koordinovat útok ze spousty různých strojů...a z každého stroje má pár desítek pokusů. Hodně štěstí.
Třeba ví, že je útok veden z mnoha IP adres na stále stejné přihlašovací jméno, tak zablokuje přístup pro to jméno a ne pro IP adresy.Tak nevím, dlouhosáhlý příspěvek o tom, jak je fail2ban nebezpečný a jak může odříznout další legitimní uživatele, a nakonec rada, jak ten DoS udělat pořádně a spolehlivěji?
Pro odsouzení řešení, by bylo dobré řešení znát.
Když se podívám do logů (svého obdobného řešení), tak obvykle do týdne po nasazení, je to jen sem tam nějaký ban, i když to před tím po určité době zkoušely střídavě stovky IP po různě velkých blocích nepřetržitých „útoků/pokusů“.
Takže to obvykle obhospodařuje zablokované jen jednotky kusů IP a nebo nic a nejsem si vědom, že by došlo k ban-u na oprávněného uživatele ani na ssh ani ftp ani https za několik let (netvrdím, že k tomu nedošlo, ale nevím o tom). Nemám žádné extrémní provozy, kdybych měl mám i odpovídající předřazené prvky, které už tu zátěž rozloží podobným způsobem, ale v mnohem větším měřítku a taky nepřetržitý hot-line, který třeba nakonec taky udělá ban na celé rozsahy aby ohlídal pásmo.
Přiznám se že nevím jak fail2ban, ale mé řešení má vyňaté některé IP, tedy nikdy nedojde k jejich zablokování, jen v případě útoku k notifikaci - tedy přístup je vždy možný.
fail2ban parsuje logy, ale parsuje jen přírustek od poslední pozice a díky tomu, že to postupně ban-uje, tak i při vyšším logovaném trafiku je to „pár řádků“ - prostě brnkačka…
Předpokládám, že fail2ban vytvoří chain a pak vyhodnocuje jen konkrétní pakety (já to dělám jen omezeně). A ty typy útoků, které to má odfiltrovat eliminuje v základu, a těch pravidel je tam opravdu jen pár a, opět předpokládm je to na daný port(službu) a IP. Ano těsně po nasazení, na serveru, který s tím nic nedělá a je tím v botnet-kruzích známý, tam toho vznikne trochu víc, ale také to není nic extra, ala na takovém ADSL je slyšet jak si linka oddychne :).
Odpověď je, že rozhodně brání útoků z nejedné adresy, ale je to jen pomůcka, která vyčistí provoz a dokonce si troufám tvrdit že minimalizuje provoz, protože jak jsem, někde už několikrát jinde uvedl, eliminuje i desítky procent zbytečného zatížení pásma, takže to je další odpověď.
Pokud to řeším na aplikační úrovni, tak docílím naprosto téhož, ale s výrazně vyšším zatížením stroje, takže argumentace, že pár pravidel v iptables zatěžuje a vyhodnocení v aplikace je méně náročnější je neuspěšná (REJECT a opakovaně DROP je mnohem méně náročnějí než cokoliv jiného) a navíc o útočníkovi vím zhruba to samé, nevím co bych mohl vědět víc…
Na aplikační úrovni by to mělo být řešené TAKY, ale fajn je když ta aplikace dostane jen omezený počet dotazů.
Třeba na ssh a ftp co se tak dívám nevidím žádné dlouhé pokusy na stejného uživatele (ano jsou, ale buď krátké, nebo v různých dlouhých periodách) - s tím bych počítal já, ne tak sofistikované rozšiřovače botnetů.
A nevidím rozdílu potencionálního DOS, mezi blokací dané IP či daného login-name, naopak to vidím právě naopak s ohledem na počet kombinací IP a počet kombinací login jmen v obecné rovině.
Přiznám se že nevím jak fail2ban, ale mé řešení má vyňaté některé IP, tedy nikdy nedojde k jejich zablokování, jen v případě útoku k notifikaci - tedy přístup je vždy možný.Umožňuje whitelistovat IP adresy.
Nejlepe jeste zakazat hesla a prihlasovat se jen s klici.
Přesně tak. V případě SSH je vůbec nejlepší zakázat autentizaci heslem úplně a pak ať si script kiddies hádají hesla do alelujá, když je to baví. Nabízet útočníkům rozhraní pro DoS jako službu mi přijde poněkud nešťastné.
A snad se nebude heslem připojovat z nějakého počítače v internetové kavárněOTP?
Velmi casta situace sshcka = vice adminu, kteri se potrebuji prihlasovat "odkudkoli" (protoze potrebuji resit kdyz se neco podela, a ne kdyz sedej doma) a ne kazdej je ochoten 24/7 sebou nosit neco s klicem. Heslo si samozreme pamatuje.
Takže se běžně přihlašují na roota z počítačů, které nemají pod kontrolou, aniž by použili aspoň nějakou implementaci one time passwords? Pořád ještě se bavíme o bezpečnosti?
klic je uplne a presne stejne bezpenej jako hesloPodstatné je, kolik by musel útočník vyzkoušet kombinací, aby zjistil vaše heslo nebo klíč. Nebo-li kolik bitů entropie to heslo nebo klíč obsahuje. Kolik bitů entropie má vaše heslo, a kolik bitů entropie má běžný klíč pro SSH? Jinak pro vaši informaci, ten klíč nemusí být uložen jen jako soubor na disku, může být třeba také v „neexportovatelné“ podobě na čipové kartě nebo v HSM (v tom případě ani není potřeba psát neexportovatelné do uvozovek).
klic je uplne a presne stejne bezpenej jako hesloDocela odvážné tvrzení, takhle bez kontextu.
otvorených a úplne nezabezpečených SSH serverov
Co bych si měl pod tímto souslovím představit?
Teraz odpoviem na oba komenty.
Bolo odo mňa neštastné uviesť tento môj reálny príklad (v článku s ktorým sa často stretávam) na otvorené SSH. Ja, na rozdiel od čitateľov mám prehľad o prostredí a pomeroch na ktoré som v tomto konkrétnom prípade narážal. To samozrejme nemôžte vedieť a preto ma teraz chytáte za slovíčka a hoci to s článkom nijak nesúvisí - bavíme sa tu o tom, čo môže byť zlé na tom keď SSH (hoci to vôbec nie je len o SSH) zbytočne odpovedá. Z čoho som teda vychádzal keď som si dovolil povedať, že SSH v nemenovanej firme je otvorené?
V prípade, že všetky tieto veci opomeniem a poviem si, tak fajn. Mám brutálne zabezpečený prístup na server na ktorý sa viem dostať len ja cez svoj kľúč (istá no najmenej pohodlná varianta) a všetko mám pod kontrolou a dokonca používam aj okresaný zoznam adries z ktorých je služba prístupná -- mám stále za potreby aby niekto len tak obťažoval túto službu a bombardoval ju svojím slovníkovím útokom??? A ja som mu okrem kapacity linky a výpočtového výkonu daroval aj miesto v logoch na disku? Viem, že po ňom príde ďalší a ďalší a nikdy nekončiací kolotoč.
Pýtate sa ma či radšej zavediem pravidlo, ktoré ho zahodí hneď v úvode alebo ho nechám nech si skúša donekonečna čo chce aj keď viem že neuspeje??
Volím to pravidlo. A keď ich už bude také množstvo, že by hrozilo nejaké spomalenie, tak to budem riešiť inak.
sshd
?
Pokud je služba dostupná jenom adresám z whitelistu, a přesto je bombardována útoky, je na tom whitelistu něco špatně. Navíc máte krásně zaděláno na problém, z jiné adresy se na server nedostanete, a až se něco stane, fail2ban vás velice rychle od serveru odřízne.
S kapacitou linky to může dopadnou všelijak, fail2ban může klidně vést i k vyšším nárokům na přenosovou kapacitu, záleží na tom, jak bude útok vypadat. Výpočetní výkon potřebujete vyšší při použití fail2ban, protože musíte procházet logy a spoustu pravidel firewallu. Pokud vám vadí, že se logují neúspěšné pokusy o přihlášení, tak je nelogujte.
Pokud vím, že útočník s přihlášením neuspěje, ať si to klidně zkouší. Nebudu přidávat pravidlo, které podle mne ničemu nepomůže a přináší spoustu problémů. Což je jen můj názor, někdo může mít jiný. Ale začátečník, který toho o správě počítače moc neví, by se měl z článku především dozvědět o těch problémech, které fail2ban přináší.
Možno by ste mi mohol povedať ako spraviť whitelist na prístup z rôznych ISP ktorí svojím zákazníkom prideľujú IP dynamicky. Ja sám počas dňa pristupujem na svoje stroje zo 4 rôznych poskytovateľov.Řešení je nedělat whitelist ani blacklist.
po zavedení pravidla do iptablesu (praktický na úrovni jadra) sa blíži k nuleNesmysl. Po zavedení pravidla se musí každý paket zakládající nové spojení s tímto pravidlem porovnat. Pokud na základě fail2ban jenom zakazujete navázání nového spojení.
A ja si rád veci logujem. Nezatváram pred nimi oči.Pokud rád věci logujete, neměly by vám vadit zalogované neúspěšné pokusy o přihlášení. Naopak, když na základě fail2ban tyhle pokus zastavíte už na firewallu, v logu se o nich nedozvíte vůbec nic, nebo jenom minimum informací (IP adresu).
Jestli dovolí fail2ban by-default současně milion pravidel, tak je idiot.
Jakékoliv takové řešení musí hlídat zdroje (a prakticky stačí o několik řádů méně) a po překročení meze by mohlo dělat něco jiného (třeba přejít na rozsahy - WOW:)) a mělo by notifikovat (pokud má ovšem kudy).
Pokud někdo udělá takový útok v reálném čase, tak je spousta serverů tak jako tak v pr..li, tak je to úplně putna co se bude dít, to je debata o potencionálním problému, ke kterému nemá u velké většiny koncových serverů šanci dojít a přesně v tomto případě se bude banovat/dropovat jak na bojišti… ;)
Praxi mám takovou to jeden den jen ssh u jednoho serveru na veřejné IP n-let (Běží tam i pureftp a logované přihlašování na https php-ko, které se už blokují opravdu jen sem-tam, dokonce za tento rok ftp méně než 30× a https 0× - tedy teď 1× bo jsem to otestoval)
[2014-05-21 06:18:31] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 61.174.51.215 for 600 seconds (10 minutes) [2014-05-21 06:29:01] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 61.174.51.215 [2014-05-21 07:09:32] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 116.10.191.230 for 600 seconds (10 minutes) [2014-05-21 07:20:02] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 116.10.191.230 [2014-05-21 07:22:02] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 193.107.16.206 for 600 seconds (10 minutes) [2014-05-21 07:32:32] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 193.107.16.206 [2014-05-21 14:00:37] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 121.199.13.47 for 600 seconds (10 minutes) [2014-05-21 14:11:07] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 121.199.13.47 [2014-05-21 14:45:38] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 121.199.13.47 for 1186 seconds (20 minutes) [2014-05-21 15:05:38] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 121.199.13.47 [2014-05-21 15:13:38] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 121.199.13.47 for 3313 seconds (55 minutes) [2014-05-21 16:07:09] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 101.227.170.42 for 600 seconds (10 minutes) [2014-05-21 16:09:09] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 121.199.13.47 [2014-05-21 16:17:39] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 101.227.170.42 [2014-05-21 17:27:40] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 121.199.13.47 for 6664 seconds (111 minutes) [2014-05-21 18:20:40] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 61.174.51.213 for 600 seconds (10 minutes) [2014-05-21 18:31:11] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 61.174.51.213 [2014-05-21 19:19:11] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 121.199.13.47 [2014-05-21 19:42:41] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 121.199.13.47 for 11638 seconds (194 minutes) [2014-05-21 22:56:44] xxxxxxxxxxxx: UNBLOCK PORT: 22 IP: 121.199.13.47 [2014-05-21 23:14:44] xxxxxxxxxxxx: BLOCK PORT: 22 IP: 121.199.13.47 for 18711 seconds (312 minutes)(není to tam vidět, ale následně po odblokování 121.199.13.47 už dál nepokračoval. Zkoušel furt root-a a pak taky všemožné kombinace čísel, to mě pobavilo, asi se lidi/účty už číslují…) Bohužel nemá uchován žádný záznam situace před nasazením, ale vygeneruje to tak 10-500× víc řádku, které za pár dni vypadají obdobně jak tady a sem tam se to třeba 2-10× natáhne (vypadá to jako velký nárůst blokovacího času, ale je to odvinuté od toho kolik pokusů vygeneruje „útočník“ za 30sec a pokud má špagetu tak dostává velkou pokutu). Našel jsem jeden zapomenutý log (měl jiný formát názvu, tak tam zůstal) pro „auth“ před nasazením a jestli to dobře počítám, tak je to:
v ø 1.1 pokusy (jen ssh) za sec
(to je průměr nejvíc je tam asi 3×/sec),
což mi dává (a mohlo by to odpovídat přibližně i dle velikosti logu)
až 95040 pokusů / 24 hod ≈> 9MiB v nekomprimovaném logu / den
Ale toš :), prostě jsem to jen vyjádřil v číslech, neumím takto vyčíslit zpětně kolik to zebere z konkrétního pásma ani jak to zatíží konkrétní stroj, ale umím vyčíslit kolik je to pokusů (což je ten hlavní údaj), ale mimo jiné taky umím (a kdokoliv jiný) vyčíslit, kolik to přibližně zabere místa v logu (při průměrné délce takového záznamu znaků).
Odpověď jestli je nechci(?), ne já je tam chci, když se to děje, ale nebudou tam pokud se to neděje.
sshd
nepovolilo přihlášení, teď jsou neúspěšné, protože firewall neumožní navázat spojení. Kolik to zabere místa v logu, to je čistě vaše rozhodnutí.
A co se týče zabrané šířky pásma, je otázka, zda by povolení navázání spojení a následné pomalé udržování toho spojení neušetřilo pásmo víc.
To není pravda, jejich odeznívání je vidět v auth logu stále, a blokování je vidět v logu (který jsem uvedl) a logovat DROP na firewallu - by to v tomto kontextu postavené na hlavu. Ale celý vtip je v tom „ty útoky odezní a pak už se nedějí a je klid“, to je ten přínos (viz. uvedený log, kde jsem schválně dal z 21. kde byl vidět i ten progres při občasné umíňěnosti asi napadeného serveru, ale to není moc časté, obvyklé je že to zkusí tak 2×), tedy aktivní botnety/servery pak už vědí že s tím nepochodí a zkusí to jen jedenkrát za čas a jinak je pokoj, bez tohoto řešení je to nekonečná komunikace z roje IP.
Teoreticky by bylo možné i nějakou analýzou podle toho identifikovat i jednotlivé IP, které patří do jednoho botnetu, bo vy-DROP-ování 2-3 IP adres má za následek, konec pokusů od spousty dalších. A lze na tom sledovat i vývoj. Před lety, to bylo téměř vždy tak, že jedna IP nekonečně hloupě jela (jak třeba ten asi napadený server v tom logu), ale pak to začalo postupně přecházet do sofistikovanějšího plánovaní a útoky se rozdělili do bloků a IP adresy se opakovali v dlouhých periodách, a když jsem přidával progresivní blokování a pak ještě „pamatováka“, tak bylo krásně vidět jak se učí a snaží se přizpůsobovat, ale se současným nastavením už je to pro ně nezajímavé. Sem tam to zkusí, ověřit jestli se něco nezměnilo, možná i jiný model pokusů, sem tam se přidá takový úlet umíňěnce jak v logu a sem tam je to cílené „jen z několika či jedné IP“, kde jsem to mohl i řešit (nebo dokonce dotyčnému vysvětlit, že to nedá i když si ten skript upraví 100×).
Takže celkem jistě to má bezpečnostní přínos, protože eliminuje množství pokusů (třeba pro FTP nějaké další loginy do HTTPS aplikací, u ssh je to sporné, protože tam je buď klíč, nebo hnusné heslo, takže těch pár desítek milionů pokusů ± je fuk). Ale hlavně to vyřeší „obtěžování serveru“ a užírání pásma. Pokud se stane cílem nepřetržitého „umíňeného“ nebo s cílem DOS, útoku, tak s tím nic nenadělám, ale pro první kategorii, je to odráženo s nejmenším úsilím a zdroji.
Já posílám většinou první odpověď REJECT (pokud počet dotazů nebyl extrémní) a následně DROP, takže útočník neví a musí počítat s timeoutem.
a lidi co s tím pracují tento způsob přihlašování akceptují.Dejme tomu. Ale je to škoda ;).
To já si to dovedu představit naprosto hravě a těším se, aby to tak bylo.
a nedejkdokoliv aby ještě ke každé službě jiným
A přihlašovat se ke každé službě jiným (a dostatečně složitým) heslem ti dnes nevadí? (Nehledě na to, že jeden klíč můžeš použít pro více služeb, tak jak se to dnes dělá u ssh.)
Teď nevím jak odpovídat…, začnu odzadu.
Útok na aplikace https jsou reálné, například pokusy na phpMyAdmin na standardních adresách je docela běžný a častý (jak na http tak https). Měl jsem i na rozhraní téměř neznámé aplikace nebo třeba na web rozhraní k ftp serveru. Z redakčními systémy a jejich provozem nemám moc zkušeností (krom něco co jsem dělal a bylo možné takto označit).
A teď na ten zbytek, pokud je to Adsl linka (třeba 4096/256) a běží tam sshčko (povolené přihlášení heslem), ftp-ko, a něco dalšího na https, dřív nebo později vystřídají pokusy na všechno a když si někdo/něco někde usmyslí, tak to tam jede nepřetržitě a na všechno, to zebere znatelnou část pásma a i na rychlosti odpovědi je to pak znát. Otázkou je co rozumíme pod pár https spojení a jestli se bavíme o těch co současně obsluhuje server nebo o těch příchozích požadavcích.
Já mám raději linku čistou a komukoliv dík, útočníci stále šetři zdroje a existují furt ti/vy druzí co to nechávají tak, takže mi máme pokoj, bo jsme nedostupní/nezajímaví ;).
Provozování takových věcí na takových linkách je docela běžné a plně dostatečné na spoustu případů a smysl to rozhodně má. (Aktivace na požádání, to je absolutně mimo jakoukoliv realitu i třeba jen doma…).
Já nemám žádný problém s tím, že to někdo neřeší a nevadí mu to - naopak z principu jsem rád a potřebu aby takoví byli…
(Ale nezapomeňme i na efekt zvýšení bezpečnosti eliminací počtu pokusů na jednotlivé služby nejlevnější cestou.
Bolo odo mňa neštastné uviesť tento môj reálny príklad (v článku s ktorým sa často stretávam) na otvorené SSH. Ja, na rozdiel od čitateľov mám prehľad o prostredí a pomeroch na ktoré som v tomto konkrétnom prípade narážal. To samozrejme nemôžte vedieť a preto ma teraz chytáte za slovíčka a hoci to s článkom nijak nesúvisí - bavíme sa tu o tom, čo môže byť zlé na tom keď SSH (hoci to vôbec nie je len o SSH) zbytočne odpovedá. Z čoho som teda vychádzal keď som si dovolil povedať, že SSH v nemenovanej firme je otvorené?Za všetky príklady postačí jeden : Heart Bleed. Som rád, že už asi dorobili do Fail2Ban aj pravidlá ktoré toto by chovanie mali eliminovať podobne ako by tomu malo byť v prípade ukradnutých kľúčov. Ale je to pekný článok, najmä keď zoberieme do úvahy že obsahuje pridanie kontroly pre doteraz ním nepodporovanú službu.
Za všetky príklady postačí jeden : Heart Bleed.Jak přesně by to mělo fungovat?
sshd
tuhle část OpenSSL nepoužívá, takže byste to mohl ukázat třeba na příkladu webového serveru. Na firewallu detekuju paket s požadavkem, který může zneužít HeartBleed chybu – a místo abych ho zahodil, tak ho zahodím, zaloguju a zakážu přístup k webovému serveru všem z dané IP adresy, takže třeba tisícům lidí za NATem? To je velice efektivní způsob DoS útoku na vlastní server…
Jedná vec ktorá mi nedá. Veľmi rád hovoríte v spojení s Fail2ban o DoS útoku a ja sa s tým nemôžem stále stotožniť.
Je DoS útokom na vlastný server akcia pri ktorej ja sám hodím do jadra pravidlo ktoré odoprie prístup jednej konkrétnej IP adrese na jeden konkrétny port??
Ja si myslím, že pomenovanie "DoS útok" môže niesť len akcia pri ktorej nie je služba schopná odpovedať nikomu. Či je alebo nie je v nejakých pravidlách. Jednoducho je tak zahltená že je neschopná reálnej funkcie. Zakázal som kompletný prístup na sambu z vonkajška. Spravil som sám na sebe DoS útok??
Ďalšia vec, koľko útočníkov ste mali z nejakej blizkej krajiny?? Mne osobne sa ešte nestalo (za 13 rokov praxe) aby na mňa skúšal dlhodobo niekto niečo z CZ/SK na ktorých mi ešte relatívne záleží.
A ak odpalím za nejakým NATom celú tlupu ukrajincov - je mi to vcelku jedno. Je to dočasná nedostupnosť. Nakoľko vychádzam z toho, že útok bol vedený aj tak z nejakého skompromitovaného stroja na ktorom už o pár dni možno ani nebude. fail2ban odbanuje adresu po niekoľkých dňoch sám a udrží tak relatívne čisto v pravidlách.
Ja už asi nemám viac čo dodať na túto tému. Je to na zvážení každého zvlášť.
Ja zastávam názor, že dokonalé riešenie neexistuje. Existuje len malé a nedokonalé, ktoré v skupine spoločne dosiahnú nejakú vyššiu úroveň. Zvážte reálne možnosti:
Je vám treba nechať ssh povolený pre celý svet? Ak sa doň hlásite len sám nechcete préjisť z overovania heslom na kľúč (+bude sa vám chcieť nosiť stále nejaké médium s týmto kľúčom?), čo všetko budete naozaj potrebovať pri ssh? Spravte čo môžte a všade kde to je možné. Fail2ban je len to jedno z malých mnohých riešení.
bude sa vám chcieť nosiť stále nejaké médium s týmto kľúčom?
Mně se především nebude chtít přihlašovat z cizích počítačů. Neudělal jsem to už přes deset let (nepočítám-li ssh mezi dvěma firemními stroji, na kterých má roota stejná množina lidí).
Mimochodem, když se přihlašujete odkudkoli a nechce se vám s sebou nic nosit, hashe veřejných klíčů svých serverů si pamatujete nebo je nekontrolujete?
Nedělat to a mít v záloze možnost to udělat se nevylučuje.
Pomocí mnemo-básničky si lze třeba 48bit z otisku pamatovat velmi lehce a několik
Po tomto už je zcela jasné, že ty f2b a podobné finty neslouží ani tak na zvýšení bezpečnosti,No jestli omezení počtu pokusů o uhodnutí hesla za jednotku času nepřináší žádné zvýšení bezpečnosti, tak jsou asi autoři software, který v případě neúspěšného pokusu o přihlášení před vrácením chyby chvíli čeká, idioti. Blbý je, že tohle dělá prakticky každý software, který obsahuje nějaké přihlašování, loginem v getty počínaje.
Cítím dost výrazný rozdíl mezi původním
neslouží ani tak na zvýšení bezpečnosti, jako spíš "řešení" nějakých zástupných problémů
a vaší verzí
nepřináší žádné zvýšení bezpečnosti
Pokud přidám jeden znak k heslu, zvýším složitost 27x (dle množiny znaků). Nevím jak kdo, ale já bych opravdu nechtěl používat systém, kdy pro stejné zvýšení bezpečnosti budu muset čekat 27x déle, pokud jsem se prve překlepl.Tahle úvaha je nějaká divná. To, jak dlouho budeš muset čekat, když ses poprvé (a jednou) překlepl, přece nemění úroveň bezpečnosti.
Tohle mají widle, tam se ten čas mezi dalšími pokusy o přihlášení zvyšuje snad exponenciálně, takže pokud se nepovede napsat heslo na šestý pokus, tak už jsou to dlouhé minutyAle to je přece účel. Možná by to nemuselo být takhle extrémní, ale cílem je, aby někdo, kdo heslo hádá, neměl neomezený počet pokusů.
Heslo, které by dnes mělo mít cca 24 znakůProč? Protože některé systémy neúspěšné pokusy o přihlášení odbavují tak rychle, jak jenom to jde, aby jich útočník stihl co nejvíc za co nejmíň času?
Při přihlašování heslem je nutné ten řetězec nějak porovnat tedy dopravit mezi klientem a serverem (kde dojde k porovnání).Tak my, co šifrujeme...
Při představě, že bych měl 60x denně zadávat hesla, by mě asi jeblo.Ale fajn, vždyť klíč ti nikdo nebere. Jenže o tom se snad debata nevede, ne? Aspoň já tady vidím diskuzi o tom, jestli má smysl omezovat počet chybných pokusů o přihlášení, aby se heslo nedalo zjistit brute-force útokem. To, že je přihlášení heslem povolené, v této diskuzi není volitelné. (Ne všichni můžeme uživatelům říct dejte si tam klíč.)
Výsledek není ani bezpečný, ani pohodlný.FTP umí šifrovat. Pro toho, kdo zná svoje heslo, je práce s tím pohodlná stejně, jako kdyby tam ten f2b nebyl.
Po Heartbleed už ta hláška není, co bývala.Při přihlašování heslem je nutné ten řetězec nějak porovnat tedy dopravit mezi klientem a serverem (kde dojde k porovnání).Tak my, co šifrujeme...
No a když mě fail2ban odřízne, tak bych musel použít tisícihlavý botnet - a ten třeba já nemám.Proč ve svých úvahách záměrně oslabujete útočníka? To taky můžete uvažovat, že útočník by musel umět spustit SSH klienta, váš útočník to neumí, takže vlastně jako dostatečná ochrana stačí SSH protokol a můžete klidně povolit přihlášení na roota bez hesla. Takže si nejprve položte otázku, jak byste tu situaci řešil v případě, že útočník ten botnet má. Mimochodem, že nemáte tisícihlavý botnet – kolik je řádově TOR exit nodů? Kolik stojí pronájem takového tisícihlavého botnetu?
Proč ve svých úvahách záměrně oslabujete útočníka?Protože když útočníka v úvahách záměrně neoslabuju, tak zjistím, že útočník je NSA, která má backdoor v AMT nebo SMM nebo v mikrokódu procesoru a donutila vývojáře Debianu odevzdat podepisovací klíče na balíčky a ještě k tomu má od VUPENu 0daye na všechny běžně provozované služby. Proč vy ve svých úvahách o zámku na dveře uvažujete, že to útočník neodstraní semtexem?
Takže si nejprve položte otázku, jak byste tu situaci řešil v případě, že útočník ten botnet má.Nijak. Stejně, jako nemohu nijak moc přispět k bezpečnosti proprietárního mikrokódu v mém procesoru a SMM na desce. Prostě doufám, že nestojím NSA za to, aby na mě tento exploit použila, že nestojím za to, aby na mě někdo spouštěl botnet nebo mě třeba unesl a heslo ze mě vymlátil.
Mimochodem, že nemáte tisícihlavý botnet – kolik je řádově TOR exit nodů? Kolik stojí pronájem takového tisícihlavého botnetu?Jo, to je pravda, zhruba tak.
Off topic:
a když zvolíte dveře z bezpečnostním zámkem
No upřímně řečeno, když jsem viděl, že i drahé zámky prodávané jako bezpečnostní s certifikáty a já nevím čím, jdou otevřít do 30s a to ještě za situace, kdy je na druhé straně pootočený klíč a na přední straně kování proti odvrtání, tak už zamykám spíše jen z nějaké kontinuity. Protože praktický smysl to zamykání stejně nemá a s příslušnou sadou a zručností ten zámek odemkne (i zamkne) každý kdo chce. Jinými slovy, je to drahá hračka pro děti.
To, jak dlouho budeš muset čekat, když ses poprvé (a jednou) překlepl, přece nemění úroveň bezpečnosti.
Fajn, tak proč se tady bavíme o systému na zpomalování / omezení počtu loginů, když to nemění úroveň bezpečnosti?
Tak my, co šifrujeme...
To je sice hezké, ale i po tom šifrovaném kanále (opět, nutost ověřit s kým se bavím atd.) to heslo jde buď jako plaintext, nebo jako hash (podle toho, jaký šílenec to psal). Obojí může útočník odposlechnout (ne nutně na tom šifrovaném kanále) a přihlašovat se už přímo tím stringem. Zatímco u asymetrické kryptografie může odposlechnout co chce (což je samozřejmně samo o sobě závažné), ale ten soukromý klíč z toho prostě nedostane, takže se nemůže ve volném čase hlásit za toho klienta.
Což mimochodem souvisí i s tou délkou hesla. Pokud se někomu podaří odchytit i ten hash (nebo se rovnou dostane k tabulce loginu), tak v případě krátkého hesla je schopen to bruteforcnout. V případě, že je to heslo dostatečně silné (a hash není stupidní md5, která se dodnes, 10 let po prolomení používá), tak se mu to nepodaří. Jinými slovy, to, kolik #/s to bude zkoušet, si určuje sám útočník a nikoliv nějaký systém na zdržování.
Aspoň já tady vidím diskuzi o tom, jestli má smysl omezovat počet chybných pokusů o přihlášení, aby se heslo nedalo zjistit brute-force útokem.
Ano, podle mě nemá smysl, protože pokud by heslo bylo tak silné jaké má být, tak ani ten nejrychlejší dostupný komp by to nelouskl
Takže opět, vlastně nejde o bezpečnost, ale jde o to, jak se pokusit tu bezpečnost ojebat. Místo 112b hesla nějaké slabší a nasadit tam omezovátor pokusů a rychlosti.
Jinak, poznámka lehce mimo téma, ale možná to někoho trkne a zamyslí se jiným směrem. I já, coby root na trojciferném počtu strojů mám mnohem lepší pocit, když spravuji systém, kde jsou uživatelská data buď chráněná podpisem, nebo jsou rovnou šifrovaná klíčem, ke kterému já nemám přístup. Protože v praxi se najdou úživatelé, kteří se nestydí vám zavolat a přesvědčovat vás, abyste támhle něco malinko pozměnil. Nejde to a jsem za to moc rád. Buď by neseděl podpis u veřejných dat a nebo jsou ta data rovnou šifrovaná soukromým klíčem klienta. Jak říkám, je to mimo téma přihlašování heslem a blokace přístupů, ale málokdo myslí na ty adminy, kteří mají ke všemu přístup a jsou terčem různých snah ta data jaksi vynést nebo alespoň upravit.
Což mimochodem souvisí i s tou délkou hesla. Pokud se někomu podaří odchytit i ten hash (nebo se rovnou dostane k tabulce loginu), tak v případě krátkého hesla je schopen to bruteforcnout. V případě, že je to heslo dostatečně silné (a hash není stupidní md5, která se dodnes, 10 let po prolomení používá), tak se mu to nepodaří. Jinými slovy, to, kolik #/s to bude zkoušet, si určuje sám útočník a nikoliv nějaký systém na zdržování.Chápu dobře, že celá tvoje argumentace teď byla založená na tom, že útočník odposlechne cleartext šifrované komunikace? Vraťme se do reality...
Takže opět, vlastně nejde o bezpečnost, ale jde o to, jak se pokusit tu bezpečnost ojebat. Místo 112b hesla nějaké slabší a nasadit tam omezovátor pokusů a rychlosti.112b heslo bez omezení rychlosti - uživatel si ho někam napíše. Kratší heslo s omezením rychlosti - uživatel si ho může zapamatovat a doba na prolomení je stejná (respektive nelze porovnat, ale taky nelze tvrdit, že je to méně bezpečné.)
Chápu dobře, že celá tvoje argumentace teď byla založená na tom, že útočník odposlechne cleartext šifrované komunikace? Vraťme se do reality...
V citovaném odstavci jsem také uvedl "dostane k tabulce loginu". Viz. aktuální zprávička o narušení bezpečností eBay. A ano, to že útočník odposlechne cleartext ze zašífrované komunikace také není až tak vyjímečné. Útoků na SSL, ale i PKI bylo poměrně dost. A když vidím, jakým stylem vydávají autority certifikáty komukoliv, kdo zaplatí, tak se divím, že útoků MITM je tak málo (k tomu ještě přidejme slabou podporu DNSSEC).
uživatel si ho někam napíše
Jistě, proto raději doporučuji používat klíče.
Jistě, proto raději doporučuji používat klíče.Ty možná. Ale jak jsem už psal, v této diskuzi není přihlašování heslem volitelné, požadavkem je, aby to bylo možné. Ty pak řekneš "pak to nejde udělat bezpečně" a neděláš nic, já říkám "nasadím fail2ban a jsem na tom líp, než kdyby tam nebyl".
Chápu dobře, že celá tvoje argumentace teď byla založená na tom, že útočník odposlechne cleartext šifrované komunikace? Vraťme se do reality...V Heronově komentáři bylo výslovně napsáno, že to heslo nemusí nutně získat z toho šifrovaného kanálu. Vy jste o Heartbleed fakt ještě neslyšel?
112b heslo bez omezení rychlosti - uživatel si ho někam napíšeProto je lepší ten klíč, který je dost dlouhý a uživatel si ho nikam psát nemusí. Ale i když chcete mít to heslo, 112b si uživatel nemusí nikam psát, pokud správce nenastaví šílená pravidla, ale místo toho poradí uživatelům, jak si vytvářet silná a snadno zapamatovatelná hesla.
Kratší heslo s omezením rychlosti - uživatel si ho může zapamatovat a doba na prolomení je stejnáCož ale znamená, že zabezpečení musí být až na úrovni aplikace, která zná i to přihlašovací jméno a může tedy evidovat pokusy o přihlášení k jednomu uživatelskému účtu z různých zdrojů (v jiném komentáři jste to jestli se nepletu označil za ideální přípravu pro DoS). Omezení rychlosti na jednu IP adresu nestačí, protože to neřeší případ, kdy si útočník pronajme botnet a bude to heslo hádat distribuovaně.
Omezení rychlosti na jednu IP adresu nestačí, protože to neřeší případ, kdy si útočník pronajme botnet a bude to heslo hádat distribuovaně.Už jsem to psal jednou. Z každého kompu má pár pokusů a pak má smůlu. To by musel být hodně velký botnet na to, aby to bylo znát.
To sem zvedav, ja svym chlebodarcum vysvetlis ... ze je ti vazne lito ze cela firma stoji ... ale ze ses zrovna ... kdes v pr ... a tim padem jim pomuzes mozna za tejden, az dorazis domu.
Podobných hypotetických problémů si můžete vymyslet kolik chcete. Firma, která je existenčně závislá na jednom člověku stejně dlouho nepřežije. Protože ten člověk nemusí být stovky kilometrů v prdeli, ale může ho třeba srazit auto právě cestou z práce a pokud ho rovnou nezabije, tak bude stejně několik měsíců mimo hru. Takže konstrukce typu "je potřeba se okamžitě připojit kamsi" svědčí daleko více o tom, že nefunguje vzájemné zastupování pracovníků a předávání informací, než o jakémsi zabezpečení.
Apropos, ty duverujes (trebas) androidu? Ze nepraskne tvuj klic googlu? A nebo mas ten svuj zcela duveryhodny stroj projistotu (z duvodu zaloh a bezpecnosti) rovnou syncovanej nekam do cloudu?
Pochopitelně netuším, zda je v Debianu nebo rovnou v HW nějaký backdoor. Věřím, že není. A není v mých schopnostech ho odhalit. Ale i kdyby byl, tak by nebyl rozdíl mezi použitím klíče nebo hesla. Stejně by to odposlechli. K tomu syncování na cloud se snad ani nemá smysl vyjadřovat.
Jen tak mimochodem, co tak malá organizace, která má jen jednoho člověka, a pro případy „total-off“ je obálka v trezoru(?)
Některé organizace to vyřeší nákupem služby, ale některé tím že mají pravě toho jednoho, nebo právě ten jeden jich má víc bokem a další to prostě neuživí, ale dostupnost i tak může být potřebná a toto (mít přístup kdykoliv odkudkoliv) je jedna z cest jak ji zajistit s rozumným poměrem cena/výkon…
hashe veřejných klíčů svých serverů si pamatujete nebo je nekontrolujete?SSHFP nic?
Jak vhodně transportovat SSH klíče na SD kartě? Stačí, že mají klíče heslo? Zašifrovat filesystém na kartě? Něco mezi tím?
Klíče zabezpečené passfrází jsou zašifrované pomocí AES, což je totéž, čím je zašifrovaný disk (jasně, u některých šifrátorů disků si lze vybrat šifru, to u standardního klíče asi ne). Takže ano, pokud je klíč zašifrován dostatečně dobrým heslem, tak to stačí.
Ja si myslím, že pomenovanie "DoS útok" môže niesť len akcia pri ktorej nie je služba schopná odpovedať nikomu.
Já ne. Za DoS (Denial of Service) útok se obvykle považuje útok, který znemožní přístup oprávněnému uživateli. Je jedno, jestli toho docílí tím, že sestřelí celý server, sestřelí toho démona, zařídí zablokování jedné IP adresy nebo třeba jen vyvolá dočasný lockout jednoho uživatele. Závažnost je samozřejmě různá, ale všechno to je Denial of Service.
Čo ma pamäť neklame, tak som mal pred nejakou dobou dosť pripojení v krátkom čase z jednej útočníkovej adresy na ssh, bez autorizácie. Pochybujem že hľadali či mám nejako kompromitovaný kľúč, tá diera z debianu je už veľmi stará. Skôr to z nadhľadu vyzeralo na pokračovanie Heart Bleed. Riešil som to jednoducho, limit štyroch nových pripojení z jednej adresy na ssh za minútu dal drop.Za všetky príklady postačí jeden : Heart Bleed.Jak přesně by to mělo fungovat?sshd
tuhle část OpenSSL nepoužívá, takže byste to mohl ukázat třeba na příkladu webového serveru.
sshd
tuhle část OpenSSL nepoužívá...
Nepoužívám Fail2Ban, protože když jsem chtěl začít, měl některé vlastnosti co jsem nebyl ochoten akceptovat a některé mu chyběli a byl/je zbytečně složitý, takže mám vlastní řešení hodně let v provozu („démona“ v PHP s progresivním hodnocením, pamatovákem a limity na zdroje ;)) - zarovna včera jsem ho „udržoval“ a nasazoval.
Na silných trubkách takové řešení zavdává oprávněnou příčinu k různým debatách, ale na nějaké slabém připojení, je to i o uvolnění značné části pásma. Ze zkušenosti, takový neřešený nežádoucí provoz zabere až desítky procent pásma. Tento druh provozu je o tom, že se chce něco získat a když se zjistí, že nic, tak se toho nechá. Není to jen o SSH, ale i o FTP či nějaké HTTPS apod. a asi je to spíš doménou domácích/malých uživatelů.
Potenciální ban sebe je jen pro debatu v nějakých kroužcích, prakticky k tomu nedochází a navíc vždy jsou možnosti se přihlásit odněkud, nebo vyjmou některé IP z politiky. A ban neprávem někoho „navíc“ - a co (?), lze eliminovat jen útok „odněkud“ a pokud to „odněkud“ je roj „někdo“, musí si to vyřešit správce „odněkud“.
Komukolivdík na místech „co mám“ s úzkými trubkami není ipv6 konketivita, takže je to na pohodu, ale nemám šajn jaký postup zvolit přes ipv6, protože buď to bude neúčinné, nebo daleko častěji dostane ban někdo (a to třeba i velký roj) neoprávněně.
Omezit útok na heslo s několika desetitícíců (měl jsem i 60k pokusů z jedné IP) za den na pár desítek je i bezpečnostním prvkem, ale hlavně šetří trubky, logy a CPU - a udělat to mimo jiné lze efektivně ban-em.
IPv6 je momentálne v testovaní. Podporu do aktuálnej verzie je možné zaviesť skrze patch.
backend = systemd :)
Ďakujem za námet. Určite sa o to obtriem pri pokračovaní
tohto článku v budúcnu.
/var/log/maillog
. Upravil filter (prípadne pridal nový ak tam nie je už nejaký, tento-problém-chytajúci) a upravil regulárny výraz na checkovanie práve tejto chybovej hlášky:postfix/smtpd[44549]: NOQUEUE: reject: RCPT from unknown[208.125.197.250]: 450 4.7.1 Client host rejected: cannot fi nd your hostname, [208.125.197.250]; from=<> to=<39ce2440d@xxxxx.sk> proto=ESMTP helo=< >
Hm, ale to přece každý ví, nebo měl vědět jaká je politika…, je mu odepřena jen konkrétní služba, u ssh je to dost sporná situace, bo tam řešení přes klíče, nejen, že se nabízí, ale je to vlastně standard, takže využití hlášení se roji uživatelů na ssh heslem jako standard je trošku z ne-praxe. No a u ostatních služeb, je to o tom co loguje daná služba (ftp/https atd.) a pod. a může to být nastaveno tak aby první provedla svoje banování (třeba uživatele) a až při dalším roji pokusů začala logovat a pak se bude banovat na nižší úrovni (nebo jsou parametry tak nastaveny, aby takové chování „vyšlo“).
Přece nenecháš nekonečnou smyčku pokusů přístup na ftp či login na nějakou službu bez povšimnutí, nějakou formu banu asi zvolíš, co-jo-nebo-ne? :)
Tiskni
Sdílej: