Fail2Ban – zlyhaj a sedíš!

21. 5. 2014 | Juraj Remenec | Návody | 12118×

Chcel by som sa v krátkosti povenovať pomerne známemu no prekvapivo málo medializovanému nástroju pre zvýšenie bezpečnosti v Posix-like systémoch. Skúsení užívatelia tu zrejme nenájdu nič nové na rozdiel od tých, ktorí tento nástroj ešte nepoznajú.

Chcel by som sa v krátkosti povenovať pomerne známemu no prekvapivo málo medializovanému nástroju pre zvýšenie bezpečnosti v Posix-like systémoch. Skúsení užívatelia tu zrejme nenájdu nič nové na rozdiel od tých, ktorí tento nástroj ešte nepoznajú.

Nedávno som mal možnosť nahliadnuť do záznamov smerovača jedného z väčších firiem, ktoré v internej sieti používajú mnoho lákadiel v podobe otvorených a úplne nezabezpečených SSH serverov. Z množstva konektov na jeden konkrétny port bolo zrejmé, že sa tu konajú denné súťaže na tému “kto skôr uhádne” no a cieľové stroje im v tomto vychádzali viac než v ústrety.

Každý správca servera sa už určite stretol s “Brute-force” útokom na nejakú z jeho služieb. Postup, metodiku a popisovať, v čom spočíva taký útok, je mimo hranice tohto článku. V dnešnej dobe netrvá príliš dlho, kým sa z nenápadného stroja na internete na úplne neznámej adrese stane pieskovisko pre všetky internetové boot-y skúšajúce sa dostať dovnútra cez každý otvorený port. Tým najčastejšie vyhľadávaným je napríklad aj spomínaný Secure shell (port 22), ale pozornosti sa nevyhnú ani služby ako ftp (21), http(s) (80,443), smtp (25) a ďalšie. Umiestniť službu na iný, neštandardný port je len dočasné riešenie schopné odolávať len prvej vlne záškodníkov. Navyše, nie pri každej službe to je z technických príčin takto možné.

Fail2Ban je bezpečnostnou medzi-vrstvou vo Vašom systéme. Nie je tu aby vyriešil Vaše problémy s týmto druhom útoku. Tieto veci si je vždy lepšie vyriešiť buď priamo na úrovni daných, bežiacich služieb, alebo za pomoci externých zariadení či softwaru (VPN, Firewall, IPSec a kopec ďalšieho). Keď ste však nútení ponúknuť služby servera širokej verejnosti a zároveň sa chcete zbaviť ľudí útočiacich na ne, môže byť Fail2ban tým, čo Vám pomôže udržať stroj v prevádzke a relatívne v bezpečí.

Pýtate sa ako? No jednoducho tak, že odníme prístup útočníkovej IP adresy k danej službe – „uväzní jeho IP adresu“.

Obsah

• Odkiaľ, koľko a ako?
• Ako to funguje?
• Príklad...
• Overenie, klientska časť a un-jail
• Naše prvé vlastné pravidlo
• Možné limitácie
• Záver

Odkiaľ, koľko a ako?

Domovská stránka projektu sa nachádza na http://www.fail2ban.org a v dobe písania tohto článku sa program nachádzal vo verzií 0.8.x. Program je založený na jazyku Python, takže k jeho funkčnosti potrebujete minimálne verziu 2.4 a vyššie. Ďalšie požiadavky sa už líšia len v závislosti na konfigurácií Vášho systému (netfilter/iptables, shorewall, ipset a pod.).

Dnes už väčšina väčších distribúcií podporuje a ponúka program priamo zo svojich repozitárov. Jeho inštalácia je v tomto prípade veľmi jednoduchá.

# Debian-like systemy, Ubuntu, Mint a dalsie…
apt-get install fail2ban
# Gentoo
emerge fail2ban
# Fedora, CentOS
yum install fail2ban

V prípade, že si potrpíte na ručnú inštaláciu (hovorím tomu „komplikovanie“ si života), prejdite na download sekciu stránky s programom, stiahnite si ho a:

tar xvjf fail2ban-x.x.x.tar.bz2
./setup.py install

Fail2ban by sa mal týmto krokom sám skopírovať aj do /usr/share/fail2ban a /usr/bin. Taktiež skontrolujte prítomnosť adresára s konfiguračnými súbormi v /etc/fail2ban.

Keďže ja na svojich systémoch používam prevažne len distribúciu Debian a v nej iptables, budem v nasledovných riadkoch popisovať možnosti programu hlavne pre túto konfiguráciu.

Ako to funguje?

Fail2ban je obyčajný „log parser“, ktorý v 1 sekundových intervaloch pokukuje po systémových logoch a pri zaregistrovaní nezvyčajnej aktivity, na základe podmienok, ktoré v ňom zadefinujete, dôjde k zavedeniu nejakého (väčšinou DROPovacieho) pravidla do iptablesu. Hlavná obrana servera teda spočíva v tom odňať prístup ku konkrétnej službe.

Veľmi jednoducho napísané ale ako neskôr zistíte, možnosti konfigurácie môžu zahŕňať aj kopec iných akcií od odoslania mailu, SMSiek, zhodenia danej služby až po automatickú samo deštrukciu servera

Konfigurácia programu sa skladá z troch hlavných častí. Z filtrov, jailov (väzení) a akcií.

Filtre – obsahujú prevažne regulárne výrazy ktoré hovoria čo konkrétne má program v logoch hľadať. V momente keď v systémovom logu dôjde k udalosti, ktorá povedie k rovnosti s výrazom vo filtroch, spúšťa sa vo fail2ban celý sled ďalších udalostí. Konfigurácie všetkých filtrov nájdeme pod adresárom /etc/fail2ban/filter.d

Akcie – Obsahujú celé skripty alebo len príkazy, ktoré sa spúšťajú pod hlavičkou fail2ban (mimochodom s právami roota), keď dôjde k zhodnosti v nejakom z filtrov. Toto je miesto, kde môžete naplno presadiť svoju fantáziu a rozhodnúť čo spravíte s hriešnikom, ktorý obťažuje Vaše systémové zdroje. Konfiguráky umožňujú zadať vlastné akcie pri rôznych stavoch. Pri zachytení, banovaní, ukončení fail2banu, checkovaní a mnoho ďalších. Práve na tomto mieste sa môžete rozhodnúť či na reštrikcie použijete iptables, netfilter alebo zavediete pravidlo do shorewallu, pošlete maila alebo si jednoducho poviete, že „Aj tak ma nedostanú!!” a následne “shred /dev/sdX”. Konfigurácie akcií sa nachádzajú v /etc/fail2ban/action.d

Jail (trestnica/väzenie/žalár) – Aj keď preklad tohto slova viac používa slovo väznica alebo žalár (a prispôsobil som tomu aj názov článku) mne sa najviac páči možný výklad slova ako – „trestnica“ (trestná lavička?). Je to konfiguračný súbor a nachádza sa v /etc/fail2ban/jail.conf. Ak by filtre boli bezpečnostné zložky a action.d výkon trestu, tak jail je jednoznačne súdna moc (úvaha autora úplne od veci). Takže je to akýsi poriadok v chaose, ktorý môžu filtre generovať. Jail.conf je práve to miesto, ktoré Vám umožní rozlíšiť záškodníka od užívateľa nevediaceho napísať svoje heslo. Definujete si tu „väznice“ do ktorých sa dostane zdrojová IP adresa zakaždým, keď splní podmienky pre vstup. Ku každej väznici definujete monitorovacie porty ktoré k nej prislúchajú, systémové logy ktoré sú pod  drobnohľadom a filtre ktoré sa na túto službu vzťahujú. Nájdeme tu ale aj zoznam adries ktoré podliehajú výnimke v monitorovaní.

Fail2ban prichádza s množstvom pred-konfigurovaných „Jailov“ a filtrov. Nie je teda potrebné sa nijak zvlášť venovať ich konfigurácií. Stačí len vojsť do jail.conf a povoliť niektoré ďalšie. Okrem kontroly chybných prihlásení k SSH tu môžeme aktivovať napríklad kontrolu mailového systému (nie len postfixu) na „Relay access denied“, Apache na kontroly od chybnej autorizácie (mod_auth) cez 404, bad bootov až po overflow alebo si jednoducho pridáme svoje ďalšie.

Príklad...

Teraz pre nedočkavcov. Pokiaľ vo svojom /var/log/auth.log vidíte niečo takéto:

10-05-2013 12:01:12 Failed password for invalid user user from 129.121.32.80 port 59666 ssh2
10-05-2013 12:01:13 Failed password for invalid user nagios from 129.121.32.80 port 60725 ssh2
10-05-2013 12:01:14 Failed password for invalid user nagios from 129.121.32.80 port 32884 ssh2
10-05-2013 12:01:14 Failed password for invalid user oracle from 129.121.32.80 port 34008 ssh2
10-05-2013 12:01:15 Failed password for invalid user oracle from 129.121.32.80 port 34506 ssh2
10-05-2013 12:01:15 Failed password for invalid user weblogic from 129.121.32.80 port 38702 ssh2
10-05-2013 12:01:16 Failed password for invalid user weblogic from 129.121.32.80 port 39317 ssh2
10-05-2013 12:01:17 Failed password for invalid user ftp1 from 129.121.32.80 port 39995 ssh2
10-05-2013 12:01:18 Failed password for invalid user ftp1 from 129.121.32.80 port 40498 ssh2


Tak si môžete byť istí, že sa nejedná o vašu kolegyňu, ktorá si zabudla heslo od svojej poštovej schránky doma na lístočku. Pozrime sa teda, čo s takouto situáciou urobí Fail2ban.

Najprv nazrieme do jail.conf aby sme sa uistili, že to vôbec bude fail2ban nejak riešiť.

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 4

Každý jail začína sekciou a tá je pomenovaná (väčšinou) podľa služby, ktorej sa týka. V tomto prípade je to [ssh].
enabled = true (true || false) – aktivuje alebo deaktivuje daný jail a kontrolu naň. SSH sa inštaluje so spustenou kontrolou na tento konkrétny jail. Ostatné nájdete buď za po známkované alebo deaktivované.
port = ssh – Port na ktorom služba sedí. Je možné uviesť číselný údaj alebo názov služby tak, ako sú uvedené aj v /etc/services. Je možné uviesť aj viac portov a oddeliť ich čiarkou (napr: http,https).
filter = sshd – je meno filtra, ktorý sa nachádza pod zmieňovaným adresárom /etc/fail2ban/filter.d a ktorý pomáha správne identifikovať chybovú udalosť zo sledovaného logu:
logpath = /var/log/auth.log – log súbor, do ktorého sa zaznamenávajú chybné prihlásenia čo sa sshd týka a ktorý je pod analýzou fail2ban.
maxretry = 4 – počet „pokusov“, ktoré sú na hranici tolerovania. Po presiahnutí tohto čísla nastupujú na scénu /etc/fail2ban/action.d, ktoré sú taktiež definované v jail.conf vo voľbe banaction = iptables-multiport.
Na rozdiel od predošlých volieb môžeme niektoré definovať aj mimo sekciu a v takom prípade sa ako globálne aplikujú štandardne na každú z nich. Nič však nebráni pre každú väznicu aplikovať vlastnú akciu.

Ďalšími voľbami, ktoré v jail.conf ešte určite stoja za povšimnutie sú globálne (ale taktiež vsunuteľné do jednotlivých sekcií):

ignoreip = 127.0.0.1 – obsahuje zoznam ip adries ktoré budú ignorované na kontrolu.
bantime = 1382400 (v sekundách) – doba, počas ktorej bude útočníkova IP adresa uvrhnutá do jailu/blokovaná. Uvádza sa v sekundách. Po uplynutí tejto doby je IP adresa opäť vyňatá z jailu a komunikácia sa znova odblokuje. Múdri ľudia tvrdia, že ak v tejto voľbe uvediete negatívnu hodnotu bude ip adresa blokovaná permanentne. Neskúšal som.
findtime = 600 (v sekundách, defaultná hodnota ak nie je uvedené) je časový úsek, na ktorý fail2ban reaguje. Inak povedané ak od poslednej chybovej hlášky (ktorej počet nepresiahol maxretry) prejde 600 sekúnd, počíta sa od znova.

Pri pohľade do /etc/fail2ban/filter.d/sshd.conf nájdeme zoznam regulárnych výrazov, na ktoré sa log testuje:

failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from \s*$
            ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from \s*$
            ^%(__prefix_line)sFailed (?:password|publickey) for .* from (?: port \d*)?(?: ssh\d*)?$
            ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM \s*$
            ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from \s*$
            ^%(__prefix_line)sUser .+ from  not allowed because not listed in AllowUsers$
            ^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=(?:\s+user=.*)?\s*$
            ^%(__prefix_line)srefused connect from \S+ \(\)\s*$
            ^%(__prefix_line)sAddress  .* POSSIBLE BREAK-IN ATTEMPT!*\s*$
            ^%(__prefix_line)sUser .+ from  not allowed because none of user's groups are listed in AllowGroups\s*$

V našom prípade je zrejmé, že tretí riadok korešponduje s chybovým stavom v našom logovacom súbore. V súvislosti s uvedeným je jasné, že na scénu nastupuje akcia v /etc/fail2ban/action.d/iptables-multiport.conf a to:

# Option:  actionban 
# Notes.:  command executed when banning an IP.
actionban = iptables -I fail2ban- 1 -s  -j DROP

Do nášho iptablesu pribudne pravidlo, ktoré dropne každý jeden paket z útočníkovej ip adresy a služba sa tak stáva nedostupnou na dobu uvedenú vo voľbe bantime. Efekt? Buď to dotyčného prestane baviť alebo ak sa budú útoky opakovať naďalej, Vám ako správcovi to dáva čas rozumne zvážiť možnosť trvalej blokácie danej adresy.

Overenie, klientska časť a un-jail

Po jednej noci spusteného fail2ban je naj-jednoduchšou cestou ako zistiť, či sa nejaký „Číňan“ chytil do pasce jednoduchá. Od nazretia do logu v /var/log/fail2ban.log až po reálny výpis.

$ iptables –L 
....
Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       all  --  129.121.32.80 	anywhere
DROP       all  --  129.121.32.75 	anywhere
DROP       all  --  129.121.32.12 	anywhere
DROP       all  --  62.125.111.12 	anywhere
RETURN     all  --  anywhere             anywhere
....

Fail2ban obsahuje okrem tej serverovej časti aj klientsku, ktorá zjednodušuje prístup k práve bežiacej konfigurácií a umožňuje ju meniť bez nutnosti program reštartovať a prísť tak o aktuálne uložené jaily. Skúsime sa teda k zoznamu uložených jailov dostať cez klientsku časť.

Najprv si pozrieme zoznam dostupných jailov (ak nie sme na vlastnom):

$fail2ban-client status
Status
|- Number of jail:      2
`- Jail list:           ssh, dovecot

Následne vykonáme výpis zabanovaných IP adries na konkrétnom jaily:

$fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list:        /var/log/auth.log
|  |- Currently failed: 4
|  `- Total failed:     21
`- action
   |- Currently banned: 4
   |  `- IP list:       129.121.32.80 129.121.32.75 129.121.32.12 62.125.111.12
   `- Total banned:     4

V prípade, že chceme niektorého neprávom zavrhnutého klienta opäť povoliť, máme k dispozícií niekoľko možností. Začnem tými najfunkčnejšími:

$iptables –L –-line-numbers
....
Chain fail2ban-ssh (1 references)
target     prot opt source               destination
1 DROP       all  --  129.121.32.80 	anywhere
2 DROP       all  --  129.121.32.75 	anywhere
3 DROP       all  --  129.121.32.12 	anywhere
4 DROP       all  --  62.125.111.12 	anywhere
RETURN     all  --  anywhere             anywhere
....
$iptables –D fail2ban-ssh 1

Alebo

$iptables –D fail2ban-ssh –s 129.121.32.80 –j DROP

V prípade, že chcete použiť klientsku časť, máte k dispozícií tieto dve možnosti:

$fail2ban-client get [MENO-JAILu] actionunban [IP.ADD.RE.SS]
$fail2ban-client set [MENO-JAILu] unbanip [IP.ADD.RE.SS]

Ktorá z nich však bude fungovať, musíte vyskúšať sami. Nakoľko to kvôli zmenám v rôznych verziách dodnes nie je jasné. Takže ja osobne radšej ručne vymažem pravidlo z iptablesu.

Naše prvé vlastné pravidlo

Dlho som premýšľal, aké vlastné pravidlo by sme si mohli urobiť, aby sme si ukázali, aké jednoduché je pridať monitoring aj na nie-systémové služby. Keďže sa veľa točím okolo LAMP riešení, povedal som si, že si ukážeme nejaké pekné možnosti, ako skĺbiť fail2ban s pomerne obľúbeným blog-cms WordPress-om.

To, čo každý WordPress-ak určite pozná a už to neraz riešil, je prílev spam bootov, ktoré bombardujú sekciu s komentármi ku článkom. Samozrejme, dnes už je k dispozícií množstvo pluginov, ktoré sa snažia daný problém riešiť priamo vo WordPresse. Ale poviem to tak, načo venovať či i len štipku výpočtového výkonu na niečo, čo je zrejmé...? A to, že ak z jednej adresy príde v krátkej dobe (rádovo niekoľko sekúnd, max pár minút) niekoľko (možno až desiatky) komentárov – je zrejmé, že nejde o vášnivého diskutéra.

Budeme teda potrebovať maličkú pomoc na strane WordPressu. Plugin, ktorý bude logovať do textového súboru IP adresu zakaždým, keď sa nejaký komentár zaradí medzi spam. Potom vytvoríme vo fail2ban filter, ktorý bude sledovať tento súbor. No a v poslednom rade vytvoríme jail v ktorom nadefinujeme, kde sú hranice vzorného správania sa. Akciu vytvárať nebudeme nakoľko počítam s tým, že používam vo svojom systéme blokovanie prostredníctvom pravidiel v iptables (toto riešenie prišlo spolu s fail2ban. Nemám prečo meniť).

1. Keďže toto je seriál o fail2ban, preskočíme teóriu okolo WP pluginov. Hotový „spam-log“ plugin si môžete stiahnuť z tohto odkazu.
2. Uploadneme spam-log folder do wp-content/plugins adresára.
3. Aktivujeme plugin vo WordPresse a nastavíme umiestnenie, kam sa bude ukladať súbor spam.log. Štandardne sa ukladá do wp-content/spam.log. V prípade, že použijete iné umiestnenie – vytvorte súbor najprv príkazom touch a potom mu nezabudnite priradiť práva pre zápis pre webserver. Vytvoríme si filter pod fail2ban. Presunieme sa pod /etc/fail2ban/filter.d/spam-log.conf a pridáme:

   [Definition]
   failregex = ^\s*comment id=\d+ from host= marked as spam$
   ignoreregex =
   

4. Našou poslednou zastávkou bude /etc/fail2ban/jail.conf

   [spam-log]
   enabled  = true
   port     = http,https
   filter   = spam-log
   logpath  = /cesta/ku/spam.log
   maxretry = 5
   findtime = 3600
   bantime  = 86400
   

Pravidlo je hotové. Reštartujeme fail2ban a od tohto momentu, ako náhle bude zaregistrovaný v rozmedzí 3600 sekúnd POST spamu viac ako 5x – bude dotyčnej IP adrese udelený ban na dobu 86400 sekúnd pri prístupe na port 80 a 443.

Uvedený príklad bol prevzatý a mierne pozmenený z blog.shadypixel.com.

Možné limitácie

Ako som už v úvode spomenul, Fail2ban je obyčajný log-parser, ktorý skenuje zmeny v logoch v 1 sekundových intervaloch. Z tohto riešenia vyplýva určitá limitácia na reakčnú dobu programu. V logoch sa môže za jednu sekundu udiať príliš mnoho. Niektoré služby overujú autentifikáciu a zároveň odpovedajú na úrovni stotín sekundy. Parameter maxretry preto nemusí vždy odrážať maximálny počet pokusov, ktoré útočníkovi povolíte a môže sa vyvolať zdanie, že program nezareagoval načas.

Záver

Okolo programu by ešte bolo čo popísať. Je tu mnoho nastavení čo sa zbierania údajov z logov týka, posielania mailov, testovania reg. výrazov či vytvárania pekných koláčových grafov. Existujú spôsoby, ako mapovať zabanované IP adresy a mať tak prehľad o krajine, z ktorej vás najčastejšie „navštevujú“. Myslím si ale, že by to presahovalo hranice článku pre prvotné sa zoznámenie, a preto si tieto veci nechám v prípade záujmu na budúce.

Na záver sa chcem ešte ospravedlniť za prípadné gramatické a pravopisné chyby ktoré ste našli a unikli mojej pozornosti. Stále sa snažím zlepšovať.

       

Komentáře

[mess]

On ten Fail2Ban je trochu dvojsečná zbraň - když se daný útočník nějak dozví, že se používá fail2ban, tak může začít posílat pakety s podvrhnutou zdrojovou IP adresou a velice elegantně takto "odpojovat" od služby chudáky uživatele.

Taky je sranda, když jste někde v zahraničí, nejlépe dlouhodobě, a spletete si párkrát heslo (třeba proto, že jste ho před odjezdem paranoidně změnili). V kombinaci s dobou zabanování třeba 3 dny je to potom legrace. Vlastní zkušenost

[Michal]

Nezdá se mi že je tak těžké "sehnat si" jinou IP adresu odkud bych se mohl přihlásti...?

Já používám fail2ban mimo jiné na blokování spammerů - když z jedné IP dostanu buď hodně spamu nebo hodně pokusů na neexistující účty tak nazdar. Nevíte někdo jestli jde fail2ban'ovat celý subnet? Když mi třeba začnou chodit spamy ze různých ale podobných adres tak bych po 5 pokusech s klidným svědomím zablokoval celou /24. To zatím nevím jak udělat...

[Juraj Remenec]

Vývojari sa vyhrážajú, že featura na jednoduchý ban celého rozsahu ip adries bude dostupná v blizkej budúcnosti. Možno už aj je s príchodom verzie 0.9.x. Každopádne nič Vám nebráni upraviť action.d a pri zavádzaní pravidla používať za IP adresou masku (/nn) a dostať tak pod ban celý subnet.

[Michal]

V action se to udelat da, ale v prvni rade fail2ban neumi pocitat dohromady pristupy z 4.3.2.1, 4.3.2.2 a 4.3.2.3 jako jeden utok. Takze kdyz z kazde IP pujde jen jeden pokus tak fail2ban ani nepipne a utocnik presto bude mit 256 pokusu na hadani hesla.

[Juraj Remenec]

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

[looker]

ja sem skombinoval fail2ban se skriptem, který mi kontroluje apache error logy a podle vzoru, který doplňuju ručně (pokusy na přístup na děravé doplňky v redakčním systému - které tam nejsou) si generuju black list s IP adresama. + k tomu připojuju trvalý blacklist a projistotu prohlídnu podle whitelistu, případně pomažu výskyt těchto IPs.

Jednou denné to vygeneruju a restartnu fail2ban - ten mi tam naháže ten blacklist. Je to spíš jako prevence, ale když už jednou někdo zkouší průniky do děravých doplňků, měl by zůstat zabanovaný napořád.

[Heron]

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é?

[Michal Kubeček]

O tom už jsem taky mockrát přemýšlel a jediné, k čemu jsem došel, bylo že pro dobrý pocit, že "se s tím něco dělá".

[looker]

jednak šetřím trochu strojovýho času a jako prevence, přihazuju tam často opakované pokusy mailbotů.

[Heron]

Jaký strojový čas? 404 nemůže zabrat víc jak 10us. To už ta analýza logů, pravidla ve fw a další operace toho cpu sežerou daleko víc.

Musíme přijmout víc uředníků abychom zvládli administrativní zátěž spojenou s jejich propouštěním.

[Peťan]

Smysl to může mít značný. Např. najde se díra v modulu, který používám a předchozí blokace "útočníků" mi do jisté míry sníží šanci využití této díry.

[Michal Kubeček]

…tedy aspoň u těch několika, kteří zrovna během posledních pár hodin ze stejné adresy zkoušeli ten neexistující skript.

[Peťan]

Proč posledních pár hodin? V komentáři bylo: "ale když už jednou někdo zkouší průniky do děravých doplňků, měl by zůstat zabanovaný napořád", tak předpokládám, že to odřízne všechny od počátku nasazení oné kontroly. Některé IP už samozřejmě nebudou platné pro dané blokování, ale to pro určité použití nemusí vadit. A každé snížení šance průniku je dobré (s ohledem na použití dané služby).

[Filip Jirsák]

Přísahám, že jsem tenhle váš komentář neviděl před odesláním toho mého ze 17:16, a že sarkasmus o 100% účinnosti bezpečnostního opatření se zakládal pouze na předchozích zkušenostech s obhájci podobných opatření. Opravdu mne nenapadlo, že mezi tím ten nesmysl zcela vážně napíšete sám.

[Peťan]

Dovolím si nesouhlasit, že je to nesmysl. Pokud předpokládáte, že se na daný server připojují běžní uživatelé a tímto jim blokuji přístup, máte pravdu, ale to přeci neznamená, že to tak musí být. Také můžete mít potencionálně kompromitovatelný sw na jiném stroji (virtuálu), než na který přistupují běžní uživatelé a data si mezi sebou jen mění. Mimochodem toto řešení se sem tam použije právě pro případ, kdy je nutné onen sw nebo stroj vypnout z libovolných důvodů, kterým nemusíte rozumět. Scénářů může být mnoho, mnoho z nich ani jednoho z nás ani nenapadne, takže nelze jednoznačně říct, že jde o nesmysl. Jelikož neexistuje 100% účinné řešení (tedy existuje, službu vůbec neposkytovat ), vždy přeci záleží na způsobu používání a pro určité způsoby má i diskutovaný blacklist své nesporné výhody. Mimochodem ne každý robot má každý den jinou IP a pokud odříznu byť jen jednoho, může to být právě ten jeden, který bude rychlejší, než správce s opravou.

PS: Abyste si nemyslel, že takový způsob sám používám. Jen reaguji na kritiku, protože mi přijde, že spousta diskutujících zavrhuje přístup dalších a přitom o problému nemá žádné nebo mají jen minimální kontextové informace. Mnohdy si pak nedokáží představit situaci, kdy má dané řešení smysl, protože oni takové použití nikdy nevyužili a nebo jim přijde nesmyslné, ale pouze na základě vlastních, zcela specifických, zkušeností.

[Filip Jirsák]

Ten příklad s virtuálem jsem vůbec nepochopil.

Přístup ostatních nezavrhuji proto, že bych si nedokázal představit situaci, kdy má dané řešení smysl. Právě naopak, takovou situaci si představit dokážu, a zároveň vím, že ta situace má daleko lepší řešení (a nebo to navrhované řešení nic neřeší).

Mimochodem, dovedu si představit i situaci, kdy má fail2ban smysl. Vedle fail2ban v té situaci vystupuje např. ještě dost rozbitý software, který tam ale musí být provozován, a který nemůžu změnit, a také nemožnost použití VPN nebo jiné další bezpečnostní vrstvy. To ale určitě není případ OpenSSH. Je to podobný případ, jako proč mít SOHO firewall před domácí sítí. Pokud by v té síti byly provozovány jen systémy, které nevystavují do sítě nepoužívané služby, a pokud by používané služby byly bezpečné, nemá to žádný význam. V praxi se v té domácí síti vyskytují i počítače s Windows, změnit nebo opravit je nemůžete, takže pak má smysl ten firewall. Nicméně případů, kdy se hodí použít fail2ban, je nesrovnatelně méně. A hlavně je potřeba v takovém případě vědět, jaké všechny nevýhody s sebou fail2ban nese.

[Peťan]

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

[Filip Jirsák]

Chyba HTTP 404 znamená "stránka nenalezena". S přihlašováním to tedy nemá vůbec nic společného.

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

[Peťan]

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.

[Filip Jirsák]

Pokud se uživatel přihlašuje do redakčního systému, přihlašuje se přes jednu konkrétní přihlašovací stránku, která musí existovat, takže určitě nevrací 404. Ten uživatel se buď přihlásí, pak použil platné přihlašovací údaje - a pokud se následně pokouší redakční systém napadnout, je potřeba zablokovat ten uživatelský účet. Protože buď je to oprávněný uživatel, který dělá neplechu a je potřeba to s ním vyřešit, nebo je to útočník, který získal přihlašovací údaje oprávněného uživatele - a pak je potřeba přihlašovací údaje změnit a zajistit, aby je příště nezískal. Nebo se ten uživatel nepřihlásí, a pokud se bude pokoušet útočit na známé chyby v redakčním systému, bude to dělat jako nepřihlášený uživatel, tudíž na to přihlašování nemá žádný vliv.

Vím, že se v kontextu příspěvku jednalo o redakční systém. A taky - asi na rozdíl od vás - mám představu, co takový redakční systém asi dělá. Redakční systém zobrazuje stránky zpravidla veřejnosti, takže od drtivé většiny uživatelů žádné heslo nevyžaduje. Heslo je potřeba jen pro úzkou skupinu uživatelů do administrace redakčního systému. Třeba tady na Abíčku se přece nepotřebujete přihlašovat, abyste mohl číst články a psát komentáře. Roboti, kteří automaticky napadají známé bezpečnostní díry v doplňcích redakčních systémů, v drtivé většině případů postupují jako nepřihlášený uživatel, a zneužívají právě takových chyb, které umožňují nepřihlášenému uživateli udělat něco, na co by neměl mít práva.

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.

[Juraj Remenec]

Ja to už ani nečítam ale z toho rýchleho pohľadu vidím, že sa držíte SSH ako kliešťa. Ale Fail2ban tu nie je len pre SSH. To bol skrátka len príklad keďže to bol prvý jail v konfiguráku. Netušil som, že sem nabehnú "odborníci" ktorí to predsa riešia inak a to ich riešenie je tým pádom nepodlomiteľné. Ja som sa za svoju prax naučil nestavať celú bezpečnosť len na nastaveniach jedinej aplikácie. Preto ak vravíte, že máte super-bezpečné ssh a brute-force vám nevadia -- je to len Váš subjektívny postoj. Za relatívne bezpečné sa donedávna pokladalo aj SSL.

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". 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". Netvrdím, že je to odpoveď na svetový mier ale myslím, že "cenný pomocník" to je!

No a k tým DoS útokom. To je tvrdenie ktoré pramení opäť len z nepoznaného reálneho stavu a predpokladá, že všetci sú dnes za NATom a že za každým sa skrýva nejaký záškodník, ktorý VIE, že tam mám Fail2Ban a vie čo musí spraviť aby odpísal službu pre všetkých ostatných. 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ť. 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? To nikoho kto sa chce dostať k svojím (napr.:mailom) nezaujíma.
Fail2ban mi môže pomôcť úlohy zautomatizovať. Presunúť dočasne väčšie časti zdrojov do onej služby aby to stíhala lepšie a potom, keď nápor opadne ju zasa vráti do predošlého stavu.
Tvrdím niekde že je to to jediné riešenie? Netvrdím.
Všetko čo robím - informujem o ďalšej možnosti. Ale určite sa nepostavím na hlavu len preto že to tak niekto nerobí.

[Filip Jirsák]

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 NATom

Nepř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 Fail2Ban

Opě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ých

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

[Heron]

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ů.)

[Šangala]

Pravým, ale nezvěřejňovaným, důvodem je pochopitelně kontrola zaměstnanců.

Což může být čistě pod vlajkou bezpečnosti.

[trekker.dk]

Existuje něco, co se dělá kvůli bezpečnosti a ty jsi ochoten uznat, že to tak skutečně je? 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.

[Šangala]

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í)…

[Heron]

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

[trekker.dk]

Ok, z toho mi vyplývá, že protože některé firmy využívají proxy ke šmírování zaměstnanců, nepřispívá web proxy k bezpečnosti.

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

[Heron]

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

[hodza]

Ono je potřeba si uvědomit, že bezpečnost není stav ale proces.

[bigBRAMBOR]

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.

no prave ze ostatni uz maji vsechno dulezite nastavene, a hraji si s opatrenim na konci, s fail2ban, ale ty jsi teprve na zacatku a resis takove zaklady jako ssh a certifikaty - jsi proste pozadu, priznej si to a styd se.

[Filip Jirsák]

no prave ze ostatni uz maji vsechno dulezite nastavene, a hraji si s opatrenim na konci

Jo. 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ů.

[bigBRAMBOR]

pravdu ma vzdycky ten co reaguje poslední nebo nejdelším prispevkem

[Peťan]

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

• Máme server A, kde je potencionálně děravý RS.
• Máme server B, kde je zveřejněna prezentace spravovaná RS na serveru A. Důvody, proč to takto dělat Vám tu nebudu vysvětlovat, do toho nikomu nic není, ale věřte, že to má smysl, jinak bychom si práci takto nekomplikovali.
• Na serveru A běží onen checker a blacklist.
• Na server A se logicky přihlašují redaktoři a útočí různé živly.
• Blacklistem na serveru A mohu potencionálně zablokovat i redaktora (ZNEMOŽNÍ MU TO PŘIHLÁŠENÍ), který konstelací hvězd dostane IP adresu robota a nebo bude mylně přidám do blacklistu. Jelikož redaktory znám, tak mi nedostupnost služby pochopitelně nahlásí a v ten okamžik si i mohu začít prověřovat činnosti onoho uživatele.
• Pokud se v RS objeví nová díra, tak právě onen blacklist PROKAZATELNĚ sníží šanci na prolomení, protože 999 útočníků je prostě méně, než 1000 a přitom to v podstatě nijak nikoho dalšího neomezuje.

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

[Filip Jirsák]

Aha, takhle amatérsky nakonfigurovaný redakční systém jsem opravdu nepředpokládal. Pokud server A slouží pouze redaktorům pro tvorbu obsahu, proč by tam měla být pro nepřihlášeného uživatele jiná stránka, než přihlašovací formulář? Zkuste tedy tuhle variantu:

• Máte server A, kde je potenciálně děravý RS.
• Na serveru A neběží žádný checker a blacklist. Naopak je ten server přístupný jenom přihlášeným uživatelům.
• Pokud se v RS objeví nová díra, přihlašování redaktorů prokazatelně sníží šanci na prolomení, protože 0 útočníků (útočník by musel znát přihlašovací údaje) je prostě méně, než 1000. A přitom to nikoho dalšího neomezuje vůbec nijak.

V tom je právě mezi námi ten rozdíl. Vy řešíte, jak zmenšit počet útočníků z 1000 na 999 pokud budete mít štěstí. Já řeším, jak zmenšit počet útočníků z 1000 na 0 vždy.

Pokud nejde ten redakční systém samotný nakonfigurovat tak, aby nepřihlášenému uživateli nedovolil udělat nic jiného, než zobrazit přihlašovací stránku, nakonfigurujte to na webovém serveru nebo předřazeném proxy serveru. Nakonfigurovat web server tak, aby nepřihlášené uživatele přesměroval na přihlašovací stránku není taková věda.

Dál píšete o zablokování uživatele, ne IP adresy. Pokud jste to myslel opravdu tak, tj. uživatelovi přihlašovací údaje má nějaký útočník, a vy to začnete řešit až v okamžiku, kdy ten útočník začne (úplně nelogicky, když už se dostal do systému) zkoušet potenciálně děravé pluginy, je taky něco hodně špatně. Navíc když už by ten útočník byl v systému a jenom chtěla zvýšit svoje práva (třeba z redaktora na administrátora), nebude slepě bušit na neexistující adresy, aby se prozradil, ale přehled o používaných pluginech si udělá jako ten přihlášený uživatel z jiných zdrojů.

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.

[Peťan]

No nic, opět si povídáte svou, vybíráte si části příkladu a opomíjíte případné další záležitosti, proč by to mohlo být nakonfigurované podobným způsobem, protože jsem přeci nenapsal přesné fungování. Takový akademický přístup, takto je to správně a ostatní řešení jsou špatně. Přeci se vždy dá navenek vystavit vlastní login stránka, to bude vyhovovat ve 100 %. Musíme to udělat tak, abychom snížily počet útočníků na 0, přitom nebudeme brát ohled na ekonomickou stránku věci a případné problémy, které vyvstanou. Stále máte v hlavě vlastní řešení a odmítáte připustit, že by snad mohlo existovat zcela jiné, specifické a konkrétní řešení, kdy to použít prostě nelze a nebo je přínos vzhledem k užití a vynaloženým prostředkům zcela neadekvátní. Bohužel realita ve firmách je jiná, vždy se musí posoudit riziko a náklady a volí se přijatelná cesta a dokud Vy nic nevíte o té konkrétní situaci, tak si nemůžete dovolit vynést soud o řešení.

Za mě je to konec této diskuze. Razíte tu princip, že řešení, o kterém máte jen strohé informace, je špatné a o tento názor mi šlo. Holt smůla... Děkuji

[Filip Jirsák]

Dobře, zkusím tu část komentáře, kterou jste buď přeskočil nebo nepochopil, vysvětli ještě jednou a pomalu.

Pokud tady někdo psal o svém řešení, a z popisu toho řešení bylo evidentní, že o tom problému docela dost ví, diskutoval jsem s ním o jeho řešení. Nepsal jsem, že je špatně, ptal jsem se na detaily, které bych třeba já řešil jinak, a zajímalo mne, jaké k tomu řešení jsou důvody - a někdy jsem se dozvěděl něco, co pro sebe za relevantní nepovažuju, někdy jsem se dozvěděl něco, co jsem nevěděl.

Vy tady píšete o specifických a konkrétních případech, a ani při čtvrtém pokusu nedokážete popsat nějaký případ, který by alespoň vzdáleně dával smysl. To je dost informací k tomu, abych pochopil, že žádný smysluplný případ ani nemáte ani nedokážete vymyslet. Protože nemáte dost znalostí na to, abyste tu smysluplnost dokázal posoudit. To není nic osobního proti vám, nikdo nemůže znát všechno. Takže pokud vám píšu, že vaše řešení nedává smysl, není to proto, že bych uvažoval pouze o jediném správném řešení, a nic jiného si nedokázal představit. Je to proto, že si dovedu představit, jakým směrem se asi budou ubírat smysluplná řešení, a taky si dovedu představit, kde to určitě nepomůže. A vidím, že vy jste se zasekl na nějakém jednom nepodstatném hledisku, a nedokážete posoudit, co je v daném případě důležité a co ne. Takže se vás snažím přesvědčit, abyste se přestal zaměřovat na ten váš jediný nepodstatný detail, a podíval se na to z většího nadhledu.

Pokud byste měl pocit, že bez pečlivého a podrobného posouzení konkrétní situace nelze o ničem rozhodnout, mám pro vás takový příklad. Představte si, že se někdo dozví nějaké základy o magnetismu a gravitaci, a půjde za fyzikem vysvětlovat mu, jaké na základě toho vymyslel perpetuum mobile. Ten fyzik o tom vynálezu nemusí vědět mnoho, aby poznal, že o perpetuum mobile nejde. A ten vynálezce klidně může mít pocit, že ten fyzik je zabedněnec a vůbec tomu nerozumí, protože ho odmítl dřív, než mohl svůj vynález pořádně ukázat. Netvrdím, že případ s fail2ban je tak jasný, jako nemožnost sestrojit perpetuum mobile. Šlo mi jen o příklad, že existují případy, kdy i o řešení, o kterém někdo zdánlivě podává jen strohé informace, je možné bez dalšího zkoumání zodpovědně říct, že je špatné.

[Heron]

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?

[Peťan]

Já nic neblokuji a podobný systém ani nepoužívám, natož nějaké otevřené RS. Na začátku vlákna někdo tuto situaci nadhodil, další uživatel nepochopil myšlenku a ptal se, jaký to má smysl, který jsem se pokusil objasnit a z toho vzniklo celé toto vlákno. 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 a to rozhodně ne proto, že autor plánuje instalovat tam děravý doplněk, ale prostě proto, že je to potencionální problém s jiným doplňkem, do té doby s neznámou dírou 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. Je to úplně jednoduchá a prostá myšlenka, ale některým se nepozdává a já jsem v nelibosti některých jen proto, že jsem se pokusil objasnit, co tím původní autor sleduje a hned se vyžaduje přesný a konkrétní příklad, protože to jinak je nesmysl. Přijde mi to celkem vtipný, kam se to vyvinulo. Jak jsem psal výše, nemá smysl dále rozebírat, každý mějme svůj vlastní názor a k tomu pěkný den

[Heron]

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.

[Juraj Remenec]

Ja si myslím, že čo sa tej prevencie týka (čo chcel autor povedať) reč je asi o niečom takomto:
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)
Všetko z jednej IP. Len idiot asi nepochopí o čo tu ide. Otázka je postavená tak, mám čakať až dotyčný objaví nejaký zraniteľný doplnok o ktorom ja nemám vedomosť? Aj keď sa všetko snažím držať vždy aktualizované - niekto môže byť rýchlejší ako ja.

[Filip Jirsák]

Otázka je správná. Akorát ta vaše odpověď je divná - vy tvrdíte, že na to čekat máte, a pokoušíte se to útočníkovi znesnadnit víceméně náhodným blokováním IP adres. Moje odpověď na tu otázku je, že na to čekat nemáte, a máte nakonfigurovat server tak, aby na všechny adresy mimo přihlašovací stránky vracel buď 403 Forbidden nebo 303 s přesměrováním na přihlašovací stránku. (Připomínám, že se bavíme o Peťanově příkladu s redakčním systémem, který je určen jenom pro správce, a pro veřejnost je určen jiný server.) Tím totiž ošetříte i ty případy, kdy to útočník bude zkoušet z různých adres, nebo kdy útočník začne tím zranitelným doplňkem.

[Juraj Remenec]

Zabúdate, že niektoré tie doplnky musia byť prístupné z internetu aby fungovali aj v rámci niečoho väčšieho (napríklad aj toho RS). 403 a 303 ich odfajčí alebo ako s obľubou hovoríte - vykonám DoS na oprávnených webmástrov
Však a čo, nech idú do prdele všetci čo nevedia aký iný, bezpečnejší RS použiť. Prečo ja mám trápiť. Všetkých odpálim a server bude len môj >
Můj milášek... .

Ďakujem za plodnú diskusiu a želám príjemný večer.

[Filip Jirsák]

Z internetu, vážně? Které a proč? Kdo k nim z toho internetu přistupuje? Přihlášený uživatel ne, ten by nedostal ten kód 403 nebo 303. Samotný web server také ne, to by nemusely být přístupné z internetu. Tak nějaký doplněk, ve kterém uživatel něco udělá, pak pošle adresu serveru někam do internetu, tam si nějaký robot něco stáhne, nějak to převrtí a výsledek zase předá redakčnímu systému? Takže musí být také autentizovaný nějakým tokenem, takže tím tokenem může být autentizovaný i ten první požadavek, takže se opět jedná o přihlášeného uživatele. Ale i kdyby ten doplněk byl tak zprasený, že by potřeboval neautentizovaný přístup z internetu, pořád můžete tu speciální adresu přidat na whitelist. Když už je tam ta přihlašovací stránka, přidat ještě jednu adresu přece není problém.

[Heron]

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.

[pavlix]

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

[Gilhad]

Třeba tady na Abíčku se přece nepotřebujete přihlašovat, abyste mohl číst články a psát komentáře.

Právě tady na Abíčku se potřebuju přihlašovat, abych mohl číst nové komentáře a měl je odlišené od těch už přečtených.

[Filip Jirsák]

Když budete blokovat náhodné IP adresy, bude to mít stejný efekt. Navíc u těch náhodných IP adres si můžete zvolit, jak velkou část adresního prostoru zablokujete, a podle toho přesně volit tu „míru šance využití této díry“. Dostat se lze až na krásných 100 %.

[looker]

chtěl jsem jenom ukázat, jak jsem si fail2ban přiohnul k obrazu svému, ale netušil jsem, co tady rozpoutá za průvan

Netvrdil jsem, že je to nějaké ideální řešení. Doplňků i děravých pro tento RS je hodně, a jsem přesvědčen, že tato prevence svůj smysl má (a i kdyby jenom pro ten pocit "že se s tím něco dělá" )

[Filip Jirsák]

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.

[looker]

nechcu se do toho zaplétat, samozřejmě tohle není jediné opatření...

[Juraj Remenec]

Mne sa to stáva pravidelne. Že som mimo, neuvedomím sa kam sa hlásim, 6x zadám hlúposť a potom, keď už je zrejmé, že pakety sa niekam zahadzujú mi "prepne" a viem, že som sa hlásil zlým heslom. Ale vždy si pomôžem. Prihlásim sa na iný server a z neho idem znova ku cieľu. Potom si zmažem aj pravidlo.

[Michal]

může začít posílat pakety s podvrhnutou zdrojovou IP adresou a velice elegantně takto "odpojovat" od služby chudáky uživatele

To 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).

[ET]

+1 neoteverne/polootevrene spojeni se vetsinou nikde neloguje takze na to fail2ban nema

a btw nejsou to booti ale boti ;)

[Kvakor]

může začít posílat pakety s podvrhnutou zdrojovou IP adresou a velice elegantně takto "odpojovat" od služby chudáky uživatele

To těžko. Aby fail2ban zareagoval tak musí dojít k navázání TCP spojení a nějaké komunikaci ohledně jména a hesla.

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.

[trekker.dk]

Akorát u UDP je větší šance na zneužití k DoS útoku falšováním zdrojové IP adresy.

[Jendа]

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.

[trekker.dk]

Tohle bys mohl rozepsat, protože mi přijde, že k těm 8M pokusům potřebuješ ještě hodně velkou dávku štěstí, že spojení, do kterého se vloudíš, bude zrovna ve správném stavu, ve kterém ti to bude ochotné přijmout tvoje podvvržená data.

[Jendа]

Já se nechci vloudit do existujícího spojení, já chci udělat TCP handshake a pak tam poslat jeden paket, který třeba v případě HTTP bude obsahovat postdata=špatné_heslo.

[trekker.dk]

Aha, už chápu, to by zafungovat mohlo. Na druhou stranu i tak - 8M pokusů na jeden nepovedný pokus o zadání hesla, řekněme 20 chyb než tě f2b zablokuje a máš na to 10 minut, to je nějakých 260k pokusů za sekundu, syn, ack, data a jsme na 800k paketů za sekundu. Přiznám se, že to nedokážu úplně odhadnout, ale přijde mi, že pokud dokážeš vygenerovat takovýhle provoz, tak už nepotřebuješ cílit na DoS způsobený kvůli fail2ban, ale můžeš prostě udělat DoS.

[tomasgn]

1) ssh klic

2) vpn

[z]

To jsi viděl v televizi?

[41.3]

Nevíte někdo, jestli existuje něco, co dokáže odhalit úspěšné nabourání do systému? Představoval bych si to tak, že by to analyzovalo logy a zjistilo, že je třeba 80procentní pravděpodobnost, že se uživatel A přihlašuje ke službě S z těchto IP, tohoto státu apod. a pokud by to našlo v logu několik neplatných pokusů z jiných IP a poté nějaký pokus, který se povedl, pak by třeba toho uživatele bloknul.

[Juraj Remenec]

Možno sa poobzerať po niečom v KALI distribúcií. Odhaliť však skompromitovaný systém bude podľa mňa na dlhé lakte (ak to robil profesionál). Tam už môže byť podvrhnutý každý jeden program.

[tm]

http://www.snort.org/ by niečo také mohol vedieť

[karel]

Hashe binarek idealni je nejprv pres ssh nebo neco prenaset i hasovaci program. Aby se pocitalo nezkompromitovynym programem.

[Jendа]

A kernel, aby se to počítalo nekompromitovaným kernelem. Ale to Linux a architektury, na kterých se provozuje, jen tak neumí.

[Filip Jirsák]

Ono to má důvod, proč je fail2ban málo medializován. On je to totiž velmi kontroverzní nástroj, který spoustu problémů sám vytváří. Každý aspoň průměrný článek se tak musí vypořádat s tím, jaké problémy ten nástroj přináší, jaké může mít přínosy, při jakém druhu útoku něčemu pomůže, kdy bude k ničemu a kdy bude sám nástrojem útoku. Právě ti nezkušení uživatelé tyhle informace potřebují, protože to často nasazují právě způsobem „hurá, další věc, která za mne sama řeší útoky“ a vůbec si neuvědomují, že fail2ban toho moc neřeší, ale za to přidává mocný nástroj pro DoS útok.

[Juraj Remenec]

Miera rizika je vždy úmerná použitiu. Sú služby pre ktoré sa fail2ban určite nehodí. V článku upozorňujem, že to navyše nie je žiaden nástroj, ktorý vyrieši bezpečnosť servera skrz na skrz a ja môžem odteraz kľudne spávať. Čo by som Vám bol ale vďačný je, keby ste skúsili predostreť nejaké reálne scérnare keď fail2ban na serveri vyslovené škodí. Alebo pridáva možnosti pre DoS útok. Mňa žiaden nenapadá.

[Filip Jirsák]

Vytvoření DoS je základní a jedinou funkcí fail2ban. DoS znamená odepření služby, a přesně to fail2ban dělá. Takže otázkou pak je, zda službu odepře jenom útočníkovi, nebo také někomu dalšímu. 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. To někomu pořád ještě nemusí vadit, přihlašuje se třeba jenom z několika počítačů, které veřejnou IP adresu nesdílí s nikým, kdo by mohl fail2ban záměrně aktivovat. (I když pak je otázka, zda není lepší řešení třeba povolit přístup jen ze zvolených IP adres a další IP adresy třeba pro nouzový přístup povolovat jinak, třeba za použití port knocking). Každopádně by ale správce, který fail2ban nasadí, měl mít ujasněný a ověřený postup, jak se na server dostane v případě, že mu fail2ban odřízne přístup. 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é.

Další problém je, že fail2ban parsuje logy (což je náročné na výkon), a přidává další pravidla do firewallu (takže 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é). Obojí vede k tomu, že pokud bude váš server pod DDoS útokem, fail2ban ten útok bude ještě zesilovat.

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ů, takže to brání jen před tím nejjednodušším útokem, kdy útočník z jednoho počítače zkouší jedno heslo za druhým. A je opravdu potřeba kvůli tomuhle případu zavádět tak nebezpečný způsob ochrany? Když stejně musíte počítat s tím, že to samé útočník může zkoušet z různých počítačů, a musíte mít tedy takové zabezpečení, aby útok hrubou silou nemohl uspět? Pokud už chcete řešit zablokování přístupu po několika neúspěšných pokusech, je mnohem lepší to řešit na aplikační úrovni, kdy aplikace o útočníkovi ví přeci jen o dost víc. 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.

[Juraj Remenec]

Hmmm. Je to príliš zglobalizované. Áno, vo svojej podstate máte úplnu pravdu. Pri verejnom serveri už záleží ktorú službu ste nútení poskytovať naozaj širokej verejnosti a neviete nič o podmienkach v ktorých sa ku nej budú hlásiť. Na takú službu predsa fail2ban nedám aby nedošlo aj k Vami zmieňovanému scénaru o NAT (všetci pod jednou IP). Ja som napríklad zavrhol kontrolu Apache na 404. Proste som prišiel na to, že vyhľadávače, ktoré katalogizovali stránky a našli viaccero vymazaných sajtov (príliš často narazili na 404) boli zabanované. Jedna možnosť bola použiť ignoreip. Tou druhou bolo vynechanie tejto kontroly. Alebo aj tretia - upraviť filter aby sa netýkal bootov/crawlerov a pdo. Ale viem si predstaviť aj prostredie, kde je táto kontrola opodstatnená. Možno, interné weby na ktoré vyhľadávače nemajú čo chodiť...
Dám fail2ban na ssh, ktoré ponúkam širokej verejnosti? No určite nedám. Lebo neviem, či sa bude prihlasovať z domu alebo z Afriky čo by som mohol vyhodnotiť ako pokus o niečo. Č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?)). Musí ho fail2ban zabanovať??? No nie, nemusí. Stačí, že mi o tom pošle mail, hneď počas dňa. Ja sám vyhodnotim nakoľko je problém závažný.

[Filip Jirsák]

Č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í?

[trekker.dk]

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:

• výchozí nastavení fail2ban vytváří uživatelské řetězce pravidel a skáče do nich pouze pro relevantní pakety (ty, které jdou na TCP port dané služby)
• není takový problém to pravidlo upravit tak, aby se provedlo jenom pro SYN pakety

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?

[Šangala]

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

[trekker.dk]

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.

[jc]

iptables maji pro podobne ucely vlastni mechanismus - modul recent. Diky nemu pak pisete pravidla, ze urcita spojeni mohou byt navazovana pouze Xkrat za Ycas a s kazdym dalsim se NECO udela (napr. reject). Funguje to dobre a nemusi se parsovat logy. Diky tomu to bude fungovat i na firewallu s iptables a neni treba to resit na cilovych serverech (ke kterym ani nemusime mit pristup).

V pripade SSH je dobre mit nejaky whitelist kvuli scp (prenos vice mensich souboru - vice spojeni za sebou) a idealne pouzivat recent jen u stroju, ktere opravdu musi byt s verejne vystavenym SSH. Jinak SSH povolit jen z urcitych (nasich) siti a tim se to zase zjednodusi. Nejlepe jeste zakazat hesla a prihlasovat se jen s klici.

V pripade postfixu je zase uzitecne nastavit *_rate_limit.

[Juraj Remenec]

Samozrejme. Recent má isté výhody. Riešenie na úrovni jadra je vždy efektívnejšie. Otázka je (neviem, recent nepoznám) nerieši sa týmto modulom prístup na službu ako takú? Napríklad, že sa počíta dajme tomu počet spojení na konkrétny port bez toho aby sa rozlišovalo medzi jednotlivými IP a celým internetom. Umožnuje recent rozlišovať konekty z mojej IP a IP niekoho ďalšieho a zablokovať následne LEN mňa?

Naproti tomu však vidím vo fail2ban väčšiu univerzálnosť a aplikovateľnosť aj na služby v ktorých by recent neuspel (aj zmieňovaný príklad s WordPressom).

[ebik]

modul recent skutečně účtuje jednotlivým IP adresám (takže se musí počítat s tím, že pro každou "aktivní" IP adresu si vezme trochu paměti, na druhou stranu adresy "hashuje", takže je furt rychlý (provede při každém relevantním packetu stejný počet operací bez ohledu na počet "aktivních" IP adres)). Na druhou stranu jsem ho úspěšně použil na Pentiu III s veřejným ssh pro vnější IP adresy. Bruteforce útoky totiž dokázali jen SSH handshakem sebrat téměř všechen procesorový čas.

[Michal Kubeček]

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

[R]

Presne tak, na SSH je to dobre. Navyse je na to plugin v arno-iptables-firewall, takze napr. v Debiane staci nainstalovat balik a plugin zapnut.

[j]

Problem s recent je ten, ze nekteri klienti nekterych sluzeb (jako trebas widli RDP) poslou rovnou sekvenci paketu (nejspis "pro jistotu"), takze pri jednom navazovani spojeni klidne vycerpaji vsechny definovany pokusy ... a jejich pocet je v tomto pripade velmi omezen (tusim ze maximum co tam lze nastavit je 20).

To omezeni pak je prave z duvodu, ze i pres toto pravidlo lze vygenerovat velmi slusny DOS - protoze se to jaksi vsechno musi nekde pamatovat ...

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.

[Filip Jirsák]

Pamatuje si heslo, které je srovnatelně silné, jako ten klíč? A snad se nebude heslem připojovat z nějakého počítače v internetové kavárně, ale z nějakého zařízení, které má pod kontrolou – a pak už není problém mít na tom zařízení i ten klíč.

[trekker.dk]

A snad se nebude heslem připojovat z nějakého počítače v internetové kavárně

OTP?

[Filip Jirsák]

OTP počítané z hlavy? Nebo OTP počítané na zařízení, které je minimálně stejně velké, jako zařízení, kde může být uložen ten klíč? Případně to zařízení rovnou umí ten klíč uložit, a nebo má dokonce SSH klienta? Nebo se taky můžou použít OTP založená na posloupnosti a vytištěná na papír – což ale pořád znamená s sebou něco nosit, a to už je jedno, zda papír nebo microSD v USB redukci.

[trekker.dk]

Dokud nepřijdete někam, kde mají zakázané používání vlastních USB zařízení.

[Filip Jirsák]

Pořád ještě je možné mít ten klíč někde na webu.

[trekker.dk]

Veřejně vystavenej nebo musím někam zadat heslo? (které jsme původně nechtěli použít, protože jsem v internetové kavárně)

[Filip Jirsák]

Schovaný za OTP. A nebo za obyčejným heslem a přihlašování k SSH bude chráněné navíc tím OTP.

[Jendа]

Ti tu session unesou.

[Michal Kubeček]

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?

[j]

Bavime se o realite ... apropos, kde byla rec o tom, ze se prihlasuji na roota?

Jinak jediny bezpeny nastaveni je znemoznit prihlaseni zvenku uplne. Zadny jiny neexistuje - klic je uplne a presne stejne bezpenej jako heslo. Naopak, bez zabezpeceni heslem je mnohem nebezpecnejsi ...

[Filip Jirsák]

klic je uplne a presne stejne bezpenej jako heslo

Podstatné 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).

[j]

Na chipovy karte, kterou nekdo zcela trivialne slohne ...

[Filip Jirsák]

Bez PINu bu bude k čemu?

[pavlix]

klic je uplne a presne stejne bezpenej jako heslo

Docela odvážné tvrzení, takhle bez kontextu.

[Michal Kubeček]

otvorených a úplne nezabezpečených SSH serverov

Co bych si měl pod tímto souslovím představit?

[Juraj Remenec]

Zbytočne otvorený port pre celý svet a na ňom služba ktorá bez akejkoľvek reflexie odpovedá na nekonečné pokusy niekoho neoprávneného - autorizovať sa.

[Michal Kubeček]

Takže podle vaší definice je SSH démon nakonfigurovaný tak, že má úplně zakázanou autentizaci heslem, a proto nemá jeho správce potřebu poskytovat útočníkům podporu pro DoS útoky, "úplně nezabezpečený"?

[ebik]

Ano, SSH handshake totiž bere nezanedbatelnou část procesorového času, na Pentiu III mi bruteforce útoky sebraly 100% CPU jen na SSH handshake. Ale jak jsem psal výše - na to je lepší použít iptables + recent.

[Filip Jirsák]

Proč by měl na nekonečné pokusy o přihlášení někoho neoprávněného reagovat jinak, než že dotyčného nepřihlásí?

[Juraj Remenec]

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é?

1. Viem, že reč o autentifikáciach kľúčmi je skôr zbožným prianim.
2. Viem, že kopec z tých ľudí čo tam robí používa túto službu tak ako sa nainštalovala. Teda s PermitRootLogin yes
3. Viem, že kopec ľudí čo si inštalovali linux na desktop ani len nevedia, že tam beží nejaké ssh.
4. Veriť dnes, že každý používa silné hesla a nie meno svojho dieťaťa alebo dátum narodenia je príliš naivné.

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.

[Filip Jirsák]

Pokud jsou body 1 až 4 někde splněné, je potřeba řešit především je a ne ztrácet čas nějakým fail2ban, které stejně ničemu nepomůže. Mimochodem, které distribuci při instalaci pro desktop ve výchozím nastavení instalují a zapínají 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áší.

[Juraj Remenec]

• 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.
• Výpočtový výkon je síce vyšší pri analýzach fail2ban ale po zavedení pravidla do iptablesu (praktický na úrovni jadra) sa blíži k nule. A ja si rád veci logujem. Nezatváram pred nimi oči.
• To parsovanie logov v skutočnosti nie je až taký náročný proces. Navyše fail2ban podporuje aj alternatívy (okrem poolingu aj gamin) ako zistiť či sa niečo "zmenilo". Keby to bolo také neefektívne riešenie, spravím si shell skript, ktorý bude robiť to isté.

[Filip Jirsák]

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 nule

Nesmysl. 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).

[j]

...Výpočtový výkon je síce vyšší ... sem zvedav, co budes rikat az tam tech pravidel budes mit milion ... teda pokud ti to vubec ten firewall prezije. A vygenerovat ti utok z milionu IPcek neni nijak velky scifi.

[Šangala]

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… ;)

[j]

DOS nikdy a nijak nevyresis na serveru. A je uplne jedno jak se k nemu postavis. Ty muzes tak maximalne udelat maximum pro to, aby DOS musel byt vyrazne vetsi. A nasazeni f2b udelas presny opak - urychlis/zesilis ucinky DOSu.

Trivialni vec ... rekneme ze das ban na IPcko na 1/2 hodiny. Tzn, staci mi vygenerovat takovy utok, ktery za +- 1/2 hodiny naposila serveru dostatecny pocet failu ... v cilovym adresnim prostoru. Tim ten stroj defakto 100% DOSnu, zcela bez ohledu na to, jak rychle je pripojen (muzou staci radove promile provozu na lince), nez ohledu na jeho vykon ...

Kdyz tam f2b mit nebudes ... potrebuju vygenerovat radove silnejsi utok, abych bud zahltil prislusnou linku ... nebo vycucal vykon CPU.

Tak jako tak, DOS stejne musis resit se svym ISP, protoze sam ho nevyresis. I pokud budes dropovat veskery prichozi provoz ... tak si nepomuzes - tvoje sluzba bude totiz nedostupna.

[Šangala]

Pominul-li praktické nesmysly (tak jednoduše získat za půl hodiny ban na půl hodiny pro nějaká větší seznam), tak má otázka zní když ti poběží nekonečné pokusy na získání hesla třeba na ftp, https aplikaci či ssh a postupem času ti to sežere třetinu linky, kus disku a permanentní zvýší zatížení CPU, tak co uděláš?

[trekker.dk]

Já vím, že pro Vás... je to jednoduché,... ale my ostatní bychom rádi... věděli, jak přesně na SSH/FTP/webu... vygenerujete útok,... aby fail2ban zablokoval... cizí IP adresy.

[Šangala]

Jen-Tak:

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

Když jsem to fčul tak zjistil/našel a spočítal, tak jsem spokojenější než dřív… .

[Filip Jirsák]

To "MiB nekomprimovaného logu za den" je nějaká nová jednotka SI, podobně jako "počet fotbalových hřišť" je nová jednotka pro plochu, nebo vážně záznamy, které v logu nechcete, řešíte blokováním aplikace na firewallu?

[Šangala]

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.

[Filip Jirsák]

Jenže ony se ty útoky pořád dějí. Akorát dříve byly neúspěšné, protože 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.

[Šangala]

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.

[Filip Jirsák]

To ale neznamená, že to ten sofistikovanější botnet nepřestane zkoušet také ihned po té, co zjistí, že přihlášení jménem a heslem není povoleno. Což by "obtěžování serveru" a užírání pásma řešilo s ještě menším úsilím a menšími zdroji.

[Šangala]

V případě SSH ano, pokud je to ovšem možné, ale to je asi tak jediné co přichází v úvahu, valná většina ostatních služeb takové možnosti nemá nebo z principu ani mít nemůže, a blokování až na aplikační úrovní je o hodně dražší.

[pavlix]

V čem je SSH tak speciální, že by o nešlo u jiných služeb?

[Šangala]

Lze povolit přihlašování jen klíčem a tazatel/útočník o tom ví a lidi co s tím pracují tento způsob přihlašování akceptují.

[pavlix]

a lidi co s tím pracují tento způsob přihlašování akceptují.

Dejme tomu. Ale je to škoda ;).

[pavlix]

Přesněji, je škoda, že to akceptují jen uživatelé SSH a to ještě zdaleka ne všichni.

[Šangala]

Nedovedu si představit že bych se ke všemu hlásil klíčem a nedejkdokoliv aby ještě ke každé službě jiným :). A až NSA spustí kvantový počítač, taky se to bude muset přehodnotit.

[Heron]

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

[Šangala]

Nevadí, protože to je copy&paste ze symetricky zašifrované klíčenky. (Možná bych používal méně klíčů než nyní hesel, ale asi velký rozdíl by v tom nebyl…)

[Filip Jirsák]

V případě HTTPS si ale nedovedu představit kombinaci "botnet zkouší přihlašovací jména" a zároveň "server to znatelně vytěžuje nebo to znatelně užírá šířku pásma". V případě toho SSH jsem si představoval, že jde o nějaký sekundární DNS server provozovaný na lepších hodinkách, ale HTTPS server, který rozhodí pár navázaných spojení? A mimochodem, botnet, který zkouší hesla (asi do nějakých redakčních systémů), navíc přes HTTPS, to je realita?

[Šangala]

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

[Filip Jirsák]

Na tom ADSL bych asi spíš řešil, zda tam má smysl provozovat veřejně přístupný SSH, FTP a web server (a pokud to nemá být až tak veřejné, zda to neaktivovat na požádání).

Já jsem nikdy neměl problém s tím, že by tyhle pokusy nějak zaznamenatelně ovlivňovaly propustnost linky nebo vytížení počítače, takže nezajímavý lze asi být i bez takových opatření

[Šangala]

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.

[Chulda]

přijdu s pozdní reakcí - botnet z číny zkouší heslo na roota přes SSH. Root je tam zakázaný, s tím problém není.

Problém je, že jsou to zákaznické oracle servery na 100Mb do internetu a ten botnet dokáže vygenerovat tolik požadavků, že zákazníkovi přetěžuje servery a chvílemi je nedostupné SSH.

Nemohu ořezat přístup pouze na zákaznické adresy a nelze použít pouze klíče. Bohužel fail2ban nemohu instalovat (teď mi to nikdo neschválí), takže teď jednou za čas musím bloknout IP síť, odkud to zkoušej. Efekt v zatížení CPU je skoro okamžitý.

Mám pocit, že p. Jirsák popisuje hezkou akademickou teorii nemající nic společného s praxí.

[Filip Jirsák]

Pocit máte hezký, ale mně nikdy botnet žádné servery nepřetěžoval, ani na 100 Mbit/s lince ani na užší ani na širší lince. Takže ta moje akademická teorie asi v praxi funguje lépe, než ta vaše praxe.

[Chulda]

pardon, nebyl to botnet, ale spíše skriptkidies. Aha, takže já si ten případ vymyslel?

Jistě, takže nedostupné SSH a zákazník, který si koupil zdroje akorát na svůj oracle kvůli drahé enterprise licenci si má připlatit více za licenci jen proto, aby mu ten server stíhal ještě odbavovat kretény zkoušející cosi na SSH?

[ebik]

Pokud máte iptables s příslušnými moduly, tak doporučuji něco takového: http://codingfreak.blogspot.com/2010/01/iptables-rate-limit-incoming.html

tím snížíte zátěž generovanou jednou IP adresou, takže už budou muset mít tisíce adres aby se to na výkonu projevilo...

[Chulda]

Díky, já včera nasadil jednořádkový pravidlo, který mi ale nefungovalo, tohle už je lepší.

Nevýhodou je blokace i po úspěšných připojeních a také doba blokace závisí na době, po kterou se sleduje počet nových připojení (nejde to IMHO oddělit), např. nejde blok na 10 minut při 5 pokusech za minutu. Umím jen pravidlo pro 5 pokusů za minutu a současně celkem 10 pokusů za 10 minut.

[Filip Jirsák]

Já jsem nepsal nic o vás. Vy jste pochyboval o tom, že se můj postup dá uplatnit v praxi. Tak jsem vás pouze ubezpečoval o tom, že já ho v praxi úspěšně provozuju.

[Chulda]

Blokování na úrovni aplikace? Viz negativní komentář o fail2ban, který se snaží prosazovat vaše řešení na aplikaci jako všeobecně vhodnější.

V mém případě (heslo povoleno, root zakázán) vedlo jednoznačně k problémům. Blokace na úrovni FW je rozhodně vhodnější.

Pravidlo pouze ve FW neumí rozpoznat úspěšné přihlášení a tak blokuje i po úspěšných pokusech, takže teď čekám, kdy se mi ozvou vývojáři o blokaci po několika scp :(

V tuto chvíli je fail2ban lepší - má informace od aplikace a blokuje efektivně na úrovni FW. IMHO jiné rychlé rozumné řešení toto nemá.

[Filip Jirsák]

Mně funguje zákaz přihlášení heslem a přihlášení na roota mám klidně povoleno. Opačná kombinace (povolení heslem a zákaz roota) podle mne z hlediska bezpečnosti moc smysl nedává, a pokud to někde "nejde" snažil bych se opravit tu chybu, proč to nejde, a ne to záplatovat fail2ban.

[Chulda]

Použití jen klíčů zákazník nechtěl a dodat seznam IP adres nedokázal.

Zákaz roota není z bezpečnostních důvodů, ale z organizačních důvodů. Je snazší dohledat co kdo udělal s použitím sudo nebo su než root z neznámé IP adresy.

[Filip Jirsák]

Pokud na používání hesel zákazník trvá, i když ví, že to bude znamenat nasazovat záplaty jako fail2ban...

[Peter Golis]

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.

[Filip Jirsák]

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…

[Juraj Remenec]

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ášť.

[Filip Jirsák]

To ale používáte nějakou svou vlastní definici DoS útoku. „DoS“ znamená „denial-of-service“ nebo-li odepření služby a je to typ útoku, kdy útočník docílí toho, aby byla služba nedostupná pro oprávněné uživatele. Takže pokud zakážete přístup z nějaké IP adresy, a za touto IP adresou je třeba za NATem oprávněný uživatel, nebo tu IP adresu po útočníkovi dostanu přidělenu nějaký oprávněný uživatel, jedná se o odepření služby oprávněnému uživateli nebo-li DoS.

To, že vás zajímají jen uživatelé, o kterých si myslíte, že jsou z ČR nebo SK, je váš problém. Já bych nenasazoval „bezpečnostní opatření“, které vůbec ničemu nepomůže, ale odepře přístup oprávněným uživatelům.

Jak už jsem psal, pokud někdo po zvážení všech pro a proti fail2ban zprovozní, je to jeho věc (řekl bych spíš jeho chyba). Problém je, že v článku ta „pro“ nejsou uvedena v patřičných proporcích a „proti“ nejsou uvedena vůbec.

[TTTTTTTT]

Fail2ban jsem použil na svůj server (pár nekritických služeb, ~5 uživatelů) ve chvíli, kdy to nějaký čínský bot zahltil sshd natolik, že se nebylo možné přihlásit. Fail2ban ho poměrně rychle odchytil a dokázal jeho požadavky zahazovat efektivněji. Pokud je fail2ban špatný, jaké je pak vhodné řešení té situace? Rád bych na měl možnost se na ten server přihlásit odkudkoliv (přes heslo, nemám-li u sebe klíč, taky ne whitelist).

Note: Chci se dovzdělat, ne obhajovat, že fail2ban je jediné správné řešení, neb vím, že v tomhle směru toho mnoho nevím.

[Filip Jirsák]

Za vhodné řešení považuju zprovoznit přihlašování klíčem a zakázat přihlašování heslem. Nedovedu si moc představit situaci, kdybych se mohl bezpečně přihlásit a neměl u sebe klíč.

[Juraj Remenec]

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

[Michal Kubeček]

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?

[Šangala]

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

[Heron]

To není o 48bit otisku, ale třeba i o min. 112b hesle

[Šangala]

To je snad brnkačka, ne(?), zhodnotil bych své heslo na záložního restriktivního uživatele „dom“ na minimálně ≈100b (odvozeno z délky a typu použitých znaků) + obstrukce neznámé/neobvyklé jméno uživatele.

[Michal Kubeček]

Když tak o tom přemýšlím, tak nemít možnost to udělat má jednu nezanedbatelnou výhodu: odpadá pokušení. :-)

[Šangala]

Dřív nebo později to jablko utrhneš - to je prostě fakt :)

[Heron]

Asi tak. Po tomto už je zcela jasné, že ty f2b a podobné finty neslouží ani tak na zvýšení bezpečnosti, jako spíš "řešení" nějakých zástupných problémů jako že to plní log, znižuje zátěž apod. Každá diskuse o změně portů (to tady dneska ještě nepadlo), blokování, fw apod nakonec skončí u příkladů, "a jak to děláte, když se chcete připojit k sobě na server z nějakého tajemného doupěte v nějaké podivné zemi". Takové prostředí je asi to poslední, ze kterého bych se chtěl připojovat kamkoliv. Takže, pokud nemůžu mít klíč, nemůžu si ověřit hash a nemůžu oběcně věřit klientskému prostředí, tak se zkrátka nepřipojuju.

[Masitá Tráva]

To se asi teda nepřipojuješ od nikud a nejspíš i nikam. Nebo přeci jen tvoje důvěra dostáva trhlinu třeba v podobě GSM firmware? A co obecně zařízení které používáš? Určitě byl ten kompiler čistý? A co tvůj CPU? Nedělá nic v SMM?

[Michal Kubeček]

Přirovnal bych to k rozdílu mezi obavou z toho, že mi CIA nainstalovala domů miniaturní kameru, kterou mi odpozoruje heslo, které zadávám na klávesnici, a situací, kdy budu na veřejnosti, vedle mne bude stát neznámý člověk a na tu klávesnici se bude dívat.

[trekker.dk]

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.

[Michal Kubeček]

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

[Heron]

Nepřináší žádné podstatné zvýšení bezpečenosti, které by vyvážilo problémy s tím spojené. 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. (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é minuty). Heslo, které by dnes mělo mít cca 24 znaků (min 112b).

Pokud budu mít přihlašování klíčem, tak pro bezpečnost udělám ještě mnohem víc. 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í). V případě asymetrické kryptografie ne.

Nejlepší na tom ale je to, že je to velmi pohodlné. Takže, zvýšená bezpečnost, snadnost použití, žádné klacky pod nohy. Klíč do agenta (nebo pokud má někdo možnost HSM, tak tam) a bez problémů se lze připojit kamkoliv (kde je veřejná část klíče), přenášet soubory apod (všichni známe). Při představě, že bych měl 60x denně zadávat hesla, by mě asi jeblo.

Že jo, klasický scénář z praxe: chceme tam FTP. FTP je nebezpečné (zajímavé je, že toto zadavatel většinou ví, ale i tak na tom trvá), takže tam musí být něco jako f2b. Výsledek není ani bezpečný, ani pohodlný.

[trekker.dk]

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é minuty

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

[Filip Jirsák]

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

Po Heartbleed už ta hláška není, co bývala.

[Heron]

Mimochodem, asi byste nevěřili, kolik obnovených certifikátů je se stejným klíčem, jako před opravou zranitelnosti heartblead. Ti lidi jsou prostě nepoučitelní a to https se může rovnou vypnout.

[Filip Jirsák]

Já doufám, že těch 7 % jsou případy, kdy ten certifikát řeší nějaký statutární orgán organizace, který vůbec netuší, o co jde, a použil standardní postup vydání následného certifikátu. Ne že by to na výsledku něco měnilo, ale aspoň by to znamenalo, že to nejsou lidé, kteří si myslí, že o certifikátech něco vědí.

Taky by mne zajímalo, na kolika serverech byl nový privátní klíč nasazen dřív, než tam byla opravena heartbleed chyba. Ale to už se zpětně nezjistí.

[Heron]

No ono je to složitější. Při reissue skutečně většina použila nový klíč. Jenže při následném obnovení platnosti už ne. Jistou část viny na tom nesou i CA, které při reissue celkem tvrdohlavě požadovali zadat CSR, ale potom už při renew nabídli použít csr zadané při prvním objednání.

Kolik jich je na procenta fakt nevím, ale je jich dost.

[ebik]

No, ono ssl jako takové se musí i správně nakonfigurovat (zakázat některé šifry, eventuelně starší protokoly) aby bylo opravdu bezpečné, a to i na straně klienta. Pokud totiž povolíte starší verzi nebo slabší šifru z důvodu kompatibility se staršími klienty, v některých kombinacích jsou (prý) známy způsoby útoku, kdy útočník může vynutit slabší verzi protokolu/šifry i když server i klient podporují silnější verzi. Ale to je podobné jako se SSH, mít povoleny protokol verze 1 se dnes již nedoporučuje.

[Jendа]

Když už taháme ty chyby: Co Fail2ban a chyba v debianím OpenSSL? Představte si situaci, kdy se dobývám na nějaký server, a nemám veřejný klíč, který tam je (v authorized_keys) - takže nemůžu lokálně „faktorizovat“, respektive vyzkoušet vydělit ho těmi 32 Ki možnými prvočísly. Musím proto provést tisíce SSH handshaků a v každém zkusit pár klíčů (openssh má defaultně snad limit něco jako 8 nebo 10 klíčů na spojení). No a když mě fail2ban odřízne, tak bych musel použít tisícihlavý botnet - a ten třeba já nemám. Pomůže tady fail2ban?

[Filip Jirsák]

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?

[Jendа]

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.

[Filip Jirsák]

NSA s backdoory v mikrokódu procesoru je dost jiná kategorie, než útočník, který si jenom vybral zrovna váš server a snaží se do něj vzdáleně dostat. Samozřejmě, že existují různé úrovně zabezpečení proti různě sofistikovaným útokům. Dveře s obyčejnou fabkou odolají nenechavci, který jde náhodou okolo a jenom zkouší, zda není odemčeno – ale pro cennější věci potřebujete lepší zabezpečení. Ale na zvolené úrovni zabezpečení nemá smysl záměrně považovat útočníka za slabšího, a když zvolíte dveře z bezpečnostním zámkem, nechat hned vedle dveře do stejného prostoru s obyčejným zámkem a doufat, že útočník se bude pokoušet dostat jen přes ty dveře s lepším zámkem.

Zabezpečit to i v případě útočníka s větším botnetem samozřejmě lze, stačí přidat druhou vrstvu autentizace – třeba jednorázová hesla.

[Heron]

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.

[Heron]

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.

[trekker.dk]

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é.)

[Heron]

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.

[trekker.dk]

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

[Heron]

Jak už jsem psal, pokud je přihlašováním heslem nutné, potom to heslo musí mít alespoň doporučovanou min. entropii.

[Filip Jirsák]

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

Proto 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ě.

[trekker.dk]

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.

[Filip Jirsák]

Pak má smůlu trvale?

Takže máte systém zabezpečený proti útočníkovi, který nemá velký botnet. Řešení s přihlašováním klíčem je odolné i proti tomu velkému botnetu – které řešení je tedy lepší?

Pokud je možnost přihlašování i heslem v zadání, a navíc v tom zadání není nic o tom, že oprávněnému uživateli nesmí být odepřen přístup (bez ohledu na to, že používá stejnou IP adresu, jako útočník), je něco divného na tom zadání. Pochybuju o tom, že jsou to skutečné požadavky, to spíš někdo neznalý přeložil (asi špatně zformulované) požadavky do nesmyslného zadání. Stává se to dost často, ale je úlohou odborníka, aby se o tom se zadavatelem bavil a zjistil, co zadavatel doopravdy chce.

[trekker.dk]

Výchozí nastavení jsou řádově minuty. V případě opakovaných pokusů - tady už si nejsem jistej tím výchozím nastavení - týden.

Pokud někdo používá stejnou IP adresu jako útočník, má problém. A nejenom v tom, že se nedostane do systému, který hlídá fail2ban, protože pokud někdo z té IP zkouší hesla, dost pravděpodobně taky posílá spam, takže si k těm problémům přidejte svoje vlastní maily padající do spamu.

Sdílení IP adresy s někým, kdo dělá bordel, prostě povede k problémům. Nevidím důvod, proč je řešit na straně jednoho z tisíce serverů místo toho, aby se vyřešily tam, kde vznikají.

[Filip Jirsák]

Problém vzniká tam, kde si někdo myslí, že podle IP adresy lze dnes identifikovat jedinou osobu. Jsem pro, aby se problém řešil tam, kde vzniká.

[trekker.dk]

Ano, je možné, že pokud si to někdo myslí, tak tam opravdu vzniká problém. Nicméně v této diskuzi jsem si nikoho takového nevšiml, takže bych se zeptal, jestli tenhle váš offtopic příspěvek měl mít nějakou další myšlenku...

[j]

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.

Pripadne te vidim nadsene vyrazet nekam par stovek kilaku ... aby ses moh pripojit zarucene bezpecne ... lol.

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?

[Šangala]

Právě proto mám záložní cestu přes jméno/heslo, bo klíč do telefonu nedám, po přihlášení přes heslo z telefonu či odjinud, jej může lehce změnit (rovnou a||nebo z bezpečného místa), ale měnit klíče je docela opruz. (Mimochodem každé přihlášení na tohoto restrict. uživatel mám notifikováno do emailu, takže šance dozvědět se „je to v prdeli“ minimálně 1× je vysoká).

[Filip Jirsák]

Je tohle opravdu dostatečný důvod, proč povolovat přihlášení heslem? Nebylo by pořád lepší třeba mít v telefonu druhý klíč pro toho druhého uživatele? Nebo „klíč do telefonu nedám“ neznamenalo „nechci dát“, ale „aplikace v telefonu ho neumí použít“? Heslo tomu telefonu svěříte, takže problém s klíčem je jen v případě ztráty mobilu a louskání hesla od klíče hrubou silou. Dostatečně silné heslo od klíče by vám mělo dát dost času ztrátu zjistit a klíč zablokovat.

[Šangala]

Ano je, to byl jen příklad s telefonem, můžu se hlásit klidně z recepce hotelu v tramtárii.
Neznamenalo nechci dát, ale nedám, aplikace jej umí normálně použít. Základní problém je, že já mu to heslo svěřím tak jako tak, takže to jen vytváří pocit falešného bezpečí.

[Heron]

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.

[Šangala]

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…

[trekker.dk]

hashe veřejných klíčů svých serverů si pamatujete nebo je nekontrolujete?

SSHFP nic?

[Michal Kubeček]

A teď upřímně: opravdu si myslíte, že kolega, kterému je zatěžko mít s sebou vlastní klíč, opravdu tohle má zřízené (včetně DNSSEC) a hlídá si, aby ten klient na každém cizím stroji, ze kterého se přihlašuje, tyhle kontroly podporoval a prováděl?

[TTTTTTTT]

Hashe veřejných klíčů s sebou na mobilu i nosím. Klíče ne, protože nevím, jak je spolehlivě zabezpečit - šance, že ztratím mobil je poměrně vysoká, přišlo mi méně nebezpečné povolit heslo na SSH než nosit klíče. Přihlašuju se typicky z počítače někoho, koho znám a kdo přístup na server nemá proto, že ho nepotřebuje, ne proto, že by nebyl dostatečně důvěryhodný.

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?

[Heron]

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

[Michal Kubeček]

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.

[Juraj Remenec]

Dá sa hovoriť o DoS útoku ktorý odstaví službu ktorú nie sú oprávnení používať žiadní, ani ďalší zablokovaní užívatelia? Čo ak som si nechal voľne prístupní SSH (pre pár ľudí na "cestách") ale oprávnení užívateľia v skutočnosti chodia na web stránky na ktorých fail2ban nesedí... ?

[Filip Jirsák]

Ve vámi popsaném případě jsou oprávnění uživatelé jak uživatelé toho webu, tak těch pár lidí na cestách používajících SSH. O DoS jde tehdy, když kterémukoli z těch uživatelů odepřete tu službu, ke které je oprávněn. Samozřejmě může být různá míra závažnosti – majiteli e-shopu bude asi víc vadit, když se nějaký zákazník nedostane na web, než že vy se nedostanete na nějaké SSH, o kterém ani netuší, co to je. Na druhou stranu to, že vy se nedostanete na to SSH, může způsobit, že se za chvíli na ten web nedostane vůbec nikdo. Nebo že z něj unikne databáze zákazníků.

[Peter Golis]

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.

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

[Filip Jirsák]

Jak přesně by to mělo fungovat? sshd tuhle část OpenSSL nepoužívá...

[Peter Golis]

Takých poznámok že to tam nie je som videl za svoj život dosť. Ak chceš, tak si ich nájdi, zdrojové kódy máš. To že Ty o chybe nevieš neimplikuje že tam chyba nie je.

[Heron]

Ad body 1 až 4: Takže správce, který se chová přesně podle bodů 1-4 (což je poměrně zásadní zanedbání povinností) náhle pocítí snahu o zabezpečení a místo toho, aby si lépe nastavil ony kritické služby (čímž by se zabezpečení zvýšilo zcela nepoměrně krát víc, než instalací f2b), tak bude chtít instalovat další balíček? A ten další balíček náhle jako zázrakem nastaví pro zcela maximální bezpečnost? Co ho k tomu vede, když vše ostatní jaksi dosud úspěšně ignoroval?

[Juraj Remenec]

Správcovi ktorý na to takto dlabe nepomôže ani Fail2ban. Lebo na to očividne kašle. Tam by som sa o to ssh bál najmenej

[Heron]

Nezdá se vám, že tímto popíráte svůj komentář, na který jsem reagoval?

[Juraj Remenec]

Neviem. Asi som nepochopil Váš dotaz. Len pre poriadok - ja som v tom komentári nepísal o sebe.

[Šangala]

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.

[Radek Podgorny]

namet pro pokracovani (okamzite odpovedi se ale nebranim ):

1) uz to umi i ipv6?
2) umi to cist systemd journal misto tech log souboru?

[Juraj Remenec]

• IPv6 je momentálne v testovaní. Podporu do aktuálnej verzie je možné zaviesť skrze patch.
• No a k druhej otázke: Fail2Ban from version 0.9 can also read directly from the systemd journal by setting backend = systemd :)

Ďakujem za námet. Určite sa o to obtriem pri pokračovaní tohto článku v budúcnu.

[Vlado99]

Zdravím.

Mne fail2ban vyhovuje, mám ho nasadený už nejakú dobu (predtým som používal vlastné naskriptované riešenie, ktoré nemalo takú rýchlu reakčnú dobu a nebolo univerzálne).

Aby fail2ban mohol pravdepodobného útočníka zablokovať, musí sa zalogovať jeho IP adresa. A tu je drobný problém: často registrujem pokusy o prihlásenie na stmp, ale súčasťou záznamu nie je IP adresa, takže nemôžem použiť fail2ban.

Loguje sa niečo takého (/var/log/secure):
saslauthd[1627]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
saslauthd[1627]: pam_succeed_if(smtp:auth): error retrieving information about user john

Podľa dátumu a času k uvedeným záznamom zo secure možno patria tieto riadky z /var/log/maillog:
postfix/smtpd[44549]: Anonymous TLS connection established from unknown[208.125.197.250]: TLSv1 with cipher AES128-S HA (128/128 bits)
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=<mail.polandfd.com>
postfix/smtpd[44549]: disconnect from unknown[208.125.197.250]

Jedná sa o CentOS 6.5 s Postfixom.

Neviete mi niekto poradiť, čo s tým?
(Ako do secure dostať IP adresu, alebo ako inteligentne spárovať záznamy v secure s maillog-om?)

[Juraj Remenec]

Len tak na rýchlo lebo musím mimo civilizáciu: Ja by som sa v jailoch zameral na /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=< >

ktorá obsahuje všetko podstatné. Mimochodom táto hláška - http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname Neviem, či to tak máte schválne alebo poľavíte z podmienok.

[Vlado99]

Ďakujem za reakciu.

reject_unknown_client_hostname mám nastavené úmyselne - normálny serózny mail server má DNS záznamy v poriadku.

Ku zameraniu na maillog: ja chcem predovšetkým stopnúť tých, ktorí sa snažia hádať názvy účtov a heslá prihlasovaním cez smtp, čo nie je vecne to isté, o čom je záznam v maillogu. Spamerov zvládne postfix a spol. vo vlastnej réžii. Na skúšačov hesiel cez smtp ale nemám žiadnu páku.

[rbc]

Komentare radoby odporniku, jak je f2b spatne, jak je to na (d)DoS nachylne, jak je fajn konzumovat veskery traffic a zatezovat servery bruteforce utoky na hesla, jak je dobre mit otevreny pristup na roota a ze staci jen "lepsi" heslo (zdravim p. Kubecku a jeho nedavnou scholastickou debatu o delce hesla n+1 - ted uz teda jen ssl certifikatu a taky zdravim heartbleed chybu) jsou bez kontextu znalosti konkretnich pozadavku a podminek uplne zcestne a spis svedci o omezenosti. Jestli spravujete nejake skolni servery, kde nejhorsi prusvih pri kompromitaci jsou zadani semestralnich pisemek nebo rozvrhu obedu tak budiz, ale jestli jsou to dulezitejsi data tak buh chran a zly pryc ;)

[j]

Pise odpornik, kterej plka zcela z cesty ...

Pokud chci zajistit 100% bezpecnost, tak ze zvenku neprihlasi NIKDO a NIKAM. (znam par takovych firem) Pokud POTREBUJU aby se zvenku lidi prihlasovali, pak je f2b narosto zcestna cesta, protoze budu neustale a opakovane resit, ze se nekdo nemuze prihlasit. (zcela realny zkusenosti z nekolika firem kde to meli)

A to na ne nikdo nepachal zadny umyslny utok, jen proste uzivatel 2-3x(ale klidne i 10x) napise spatne heslo, a pak je vprdeli, vola na IT ... coz firmu stoji $$$.

Pokud pak bude nekdo umyslny utok na takovy stroj vyrabet, tak velmi rychle odstreli uplne vsechny uzivatele ... klidne vcetne adminu.

[Šangala]

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? :)

[chsajarsa]

>A to na ne nikdo nepachal zadny umyslny utok, jen proste uzivatel 2-3x(ale >klidne i 10x) napise spatne heslo

To by snad byl zablokovan stejne ne? Tedy ve vsech firmach, kterymi jsem prosel a nebo ktere mam pod spravou, pokud uzivatel zada 3-4 spatne heslo, tak ma na par hodin zablokovany ucet a je jedno jestli se jedna o SSH,VPN,mail nebo cokoliv k cemu se vaze jeho ucet.

[R]

To je jedno z najhorsich "bezpecnostnych" opatreni, pretoze umoznuje trivialne urobit DoS na lubovolneho pouzivatela.

[pavlix]

+1

[s]

ja mam na serveru ucet test, heslo test, kdo do nej vejde, tomu hlava sejde... a staci na to jednoduchy script misto shellu. Funguje vyborne!

[trubicoid]

a co toto? https://code.google.com/p/kippo/

das to na port 22 a opravdicky ssh na jinej port

[Jendа]

Málo věrohodné.

Nejlepší by byl nějaký virtuál s logováním (třeba přes MITM na jeho SSH). Nevíte o něčem?

[trubicoid]

treba toto? http://bruteforce.gr/honeydrive

mne doma kippo staci, nebudu delat celej virtual

[Jendа]

Ne. Říkal jsem, že mu chci dát skutečný shell, ne nějakou ne příliš zdařilou emulaci.

[trubicoid]

no nevim, na roboty asi emulgace staci

tak co treba toto? http://sourceforge.net/projects/bifrozt/

[trubicoid]

ma to nejakou synchronizaci spatnyhc IP s ostatnima uzivatelama jako treba denyhosts? http://denyhosts.sourceforge.net/

[manasekp]

proxyrack.com

[zxz]

broken by design - ip adresa neidentifikuje uzivatele, a uz vubec ne bota.

[ebik]

Toto v žádném případě není nástroj na zvýšení bezpečnosti proti "jednomu" útoku (neposílí to nejslabší prvek řetězce). Ale zvyšuje to bezpečnost a komfort uživatelů ve světě kde hloupé útoky na hádání hesla, nebo na vkládání spamu (třeba za účelem indexace odkazu googlem) jsou naprosto běžné a je jich moc. Pro takové útoky je ip adresa velice dobré přiblížení jednomu uživateli/botu. (Botnety něco stojí a ipadresy mimo botnet také).

[Petr]

Ahoj, co znamená ten nadpis? Fail2Ban – zlyhaj a sedíš! To jako že něco špatně nastavím a zavřoumě? Děkuji, jsem začátečník.

[Juraj]

Alebo sa to dá vysvetliť tak, že "pár-krát" neuhádni heslo a zavrú ťa. Samozrejme - z pohľadu návštevnika. nie admina.