Útoky na SSH mění strategii

9.9.2008 16:32 | Přečteno: 2621× | poslední úprava: 25.11.2008 15:32

Pokud máte stroj se v Internetu, na který se přihlašujete přes SSH, tak jste se jistě setkali s hromadnými pokusy o uhádnutí hesla. Možná jste si nastavili nějaký systém pro detekci a odražení útoku. Pak si raději projděte logy, protože váš systém se asi již několik dnů míjí účinkem.

Sám používám bezpečnostní modul pam_abl, který sleduje frekvenci útočících strojů a po překročení jistého počtu chybných přihlášení z téže adresy učiní tomuto řádění přítrž. Nakonec napojený skript zašle hlášení o incidentu jabberem.

Avšak poslední dobou mi přestaly zprávy chodit. Ne, útočníky si neodnesl ani čert, ani neprozřeli. Změnila se taktika útoku, na kterou je můj detekční systém krátký.

Hleďte:

Sep  7 18:42:27 gw sshd[23616]: Failed password for invalid user admin from 213.8.59.133 port 49426 ssh2
Sep  7 19:09:32 gw sshd[23902]: Failed password for invalid user admin from 124.42.124.87 port 16947 ssh2
Sep  7 19:46:37 gw sshd[24324]: Failed password for invalid user admin from 123.14.10.64 port 18032 ssh2
Sep  7 20:16:09 gw sshd[24649]: Failed password for invalid user admin from 74.95.30.50 port 54088 ssh2
Sep  7 20:46:32 gw sshd[24990]: Failed password for invalid user admin from 69.64.166.23 port 56622 ssh2
Sep  7 21:17:52 gw sshd[25330]: Failed password for invalid user admin from 69.64.166.23 port 39447 ssh2
Sep  7 21:39:05 gw sshd[25561]: Failed password for invalid user admin from 200.56.117.250 port 55007 ssh2
Sep  8 00:34:25 gw sshd[27484]: Failed password for invalid user admin from 80.152.235.138 port 41501 ssh2
Sep  8 00:48:31 gw sshd[27648]: Failed password for invalid user admin from 90.188.155.248 port 34724 ssh2
Sep  8 01:18:10 gw sshd[27981]: Failed password for invalid user data  from 80.34.55.88 port 50898 ssh2
Sep  8 01:33:37 gw sshd[28152]: Failed password for invalid user data  from 200.79.25.39 port 17768 ssh2
Sep  8 01:49:23 gw sshd[28319]: Failed password for invalid user data  from 218.201.39.216 port 1533 ssh2
Sep  8 02:43:13 gw sshd[28922]: Failed password for invalid user data  from 89.97.62.16 port 34530 ssh2
Sep  8 09:17:36 gw sshd[  923]: Failed password for invalid user ftp   from 200.148.241.202 port 41471 ssh2
Sep  8 10:21:36 gw sshd[ 1634]: Failed password for invalid user ftp   from 90.188.155.248 port 59550 ssh2
Sep  8 11:10:39 gw sshd[ 2175]: Failed password for              mail  from 201.236.192.195 port 19295 ssh2
Sep  8 11:27:23 gw sshd[ 2357]: Failed password for              mail  from 145.253.179.228 port 50467 ssh2
Sep  8 12:05:04 gw sshd[ 2765]: Failed password for              mail  from 78.96.220.78 port 21005 ssh2

Na první pohled to vypadá jako internetový šum, ale na druhý, poté co se zaměříte na posloupnost přihlašovacích jmen, lze vypozorovat pravidelnost.

Dovolím si tvrdit, že se rodí nová strategie: distribuované útoky.

Uzly botnetu nyní spolu komunikují a vedou koordinovaný útok, snažíce se zakrýt svoje stopy příkrovem adresního prostoru a času. Prozrazují je jen účty.

Obávám se, že pokud četnost těchto útoků stoupne na tolik, že jeden stroj bude pod palbou několika botnetů ve stejný okamžik, i sloupec s uživatelskými jmény ztratí na pravidelnosti, a tak útok snáze unikne bedlivému oku správce.

Tímto vyzývám obecenstvo, aby potvrdilo či vyvrátilo mé domněnky a navrhlo spravedlivý systém pro odhalování těchto útoků.

       

Anketa

Komentáře

[tomm]

Utoci na me od minule nedele. Nasbiral jsem zatim neco pres 800 unikatnich IP, ktere uz blokuji pro SSH. Jestli si nekdo chce usetrit namahu, rad poskytnu cerstvy seznam.

Podle me ti boti ani tak moc komunikovat nemusi. Na me zkusi 2 jmena a pak si da minimalne hodinu pokoj, jestli ma kazdy uzel svoji mnozinu jmen, komunikovat nemusi, protoze ne prekryvaji. No a vcase, kdy to nezkousi na me, to zkousi na jine servery - to uz mam potvrzeno z jineho serveru.

Momentalne to vyresim tak, ze na SSH se pujde pripojit jen z konkretnich IP adres a pak si na par mistech pustim SSH na nejake naprosto nestandardnim portu, pripadne k tomu pouziju port randomizer. Ma nekdo nejake napady?

[Josef Kufner]

Používat místo hesla klíče, na port 22 pověsit falešné ssh s nějakým virtuálním pískovištěm a kouknout se, co bude bot dělat, když uspěje? Poté analyzovat úpravy, které bot provedl, komunikační protokol používaný botnetem, najít bezpečnostní díru a botnet zrušit nebo jím zrušit jiný botnet

[pc2005]

kouknout se, co bude bot dělat, když uspěje

Tohle jsem chtěl vyzkoušet, ale nevím jak udělat dostatečně slabé heslo, aby se bot rychle proboural. Existuje nějaká možnost rozbrazení zkoušeného hesla, nebo se to řeší nějakým hashem?

[Mrkva]

Tipuju root nebo toor :) Uz instaluju virtualni masinu :)

[Jakub Suchy]

Pozor. Takovy honeypot ma zavazne bezpecnostni i pravni dusledky. Nez to udelas, bud si jich prosim vedom.

[Mrkva]

Bezpecnostnich jsem si vedom. A pravni dusledky? Samozrejme to nenecham utocit na cizi stroje, jestli myslite tohle :)

[Zdeněk Štěpánek]

root:rootpassword

root:root

root:password

admin:admin

milion pitomych hesel. taky je mozno dat prazdny heslo, ale to se musi explicitne u sshd povolit.

Jinak me to nechava absolutne klidnym. Ackoliv moje hesla na verejnych strojich nejsou nikterak silene dlouha, nejsou to zadna slovnikova slova a tak neverim ze by to nejaky robot prolomil, tak at se klidne snazi, sshd je bude odkazovat do vecnych lovist. Snad toho akorat nebude tolik ze to zpusobi DoS, pak to samozrejme bude lepsi zarazit uz na firewallu.

Zdenek

[pc2005]

taky je mozno dat prazdny heslo

Že by to bylo až takhle jednoduchý, no ale co, vyzkouším .

[Dalibor Smolík]

admin:admin
ROFL .. mám to do dneška na domácím routeru ..

[CEST]

hehe, vtipny. nedavno jsem se takhle analyzou hacknutyho serveru dostal na jedno FTPko, kde meli ty script kiddies tyhle nastroje, tak jsme tam kouknul a maji fakt dost hesel. Byl tam i seznam IP, jmeno+heslo, neco jsem zkusil, nejaky routery jsou prekonfiguroval a restartoval.

jinak jsem zkousel i ty IRC servery, ale to uz jsem pak nemel tolik casu s tim vic experimentovat, ale ty boti se prihlasi s ID napadenyho systemu.

[Petr Tomášek]

Používat místo hesla klíče...

To nekdy neni mozne, zvlast jestli je pozadovano, aby uzivatele meli k serveru pristup odkudkoliv (kde lze alespon nainstalovat putty)...

[Filip Jirsák]

To nekdy neni mozne, zvlast jestli je pozadovano, aby uzivatele meli k serveru pristup odkudkoliv (kde lze alespon nainstalovat putty)...

A pokud tam lze nainstalovat putty, nejde tam nahrát klíček z flashdisku nebo třeba i z webu?

[Petr Tomášek]

a) z flashdisku: no to právě předpokládá, že člověk má ten flashdisk všude (heslo si pamatuju i na pustým ostrově)

b) z webu: no to pak už vůbec nemá cenu používat nějaký ssh :D

[Käyttäjä 11133]

Za to při připojování z cizích počítačů má cenu to SSH používat, když tam může být libovolný trojan a to putty stahuješ taky z webu, takže může být klidně udělaný man in the middle útok na to http spojení přes které stahuješ to putty.

To s tím putty po http vyvozuji z:

a) z flashdisku: no to právě předpokládá, že člověk má ten flashdisk všude (heslo si pamatuju i na pustým ostrově)

[pavlix]

Když ho zahesluješ, tak získáš podobnou bezpečnost jako u SSH s heslem.

[tomm]

Používat místo hesla klíče

Kolegove jsou jeste na dovolenych, takze v tento okamzik to nepirpada v uvahu, ale samozrejme to bude brzo nasledovat.

na port 22 pověsit falešné ssh s nějakým virtuálním pískovištěm a kouknout se, co bude bot dělat, když uspěje? Poté analyzovat úpravy, které bot provedl, komunikační protokol používaný botnetem, najít bezpečnostní díru a botnet zrušit nebo jím zrušit jiný botnet

Kez bych na tohle mel cas, moc by me to bavilo Uz jsem si par tech nodu projel nmapem, co maji otevreno, ale zatim jsem na nic moc neprisel, neni cas

[pc2005]

Já jsem jednou našel na IP adrese, odkud mě crackovali (neúspěšně ), běžící VNC server, tak se připojím a co vidím: Suse .

[petr_p]

Jeden ochotný správce mi kdysi poslal .bash_history a inkriminované soubory (zdrojáky útočníkových nástrojů). Něco bych o tom mohl napsat, jestli bude zájem.

[houska]

urcite

[pc2005]

Jsem pro.

[Mrkva]

To by nebylo spatny. Ke me zatim nic neleze, takze se rad podivam :)

[Ritchie]

Ma nekdo nejake napady?

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

[rincewind]

Ne vzdy jdou pouzit jen klice :( takze to resim klice + heslo ktery mi vrati tohle echo "heslo" | md5sum. A velmi premyslim, ze pro cely pristup zavedu to same co pro web - pristup jen z CZ, SK, DE IP adres - btw. nasel jsem sice urcity seznam, ale nahodne jsem zjistil, ze neni presny, nemate nekdo navrh na takovy seznam adres?

[Jakub Suchy]

povoluju si vetsinou pouze neco takoveho: 85.160.0.0/16:22/tcp 147.32.0.0/16:22/tcp 82.99.128.0/18:22/tcp 217.77.160.0/20:22/tcp

+ par jednotlivych adres. vim, ze vzdycky v jedne z tech siti mam stroj ze ktereho se tam dostanu. je to neco jako CRo, Eurotel, Vodafone, CVUT. T-Mobile jsem nezkoumal, nepouzivam.

[xkucf03]

heslo ktery mi vrati tohle echo "heslo" | md5sum

Doufám, že pak nezapomínáš pouštět history -c na stroji, kde sis heslo generoval

[Käyttäjä 11133]

Hlavně si stačí spočítat jak ošklivě tím použitím md5sum redukuje počet možných kombinací. Přecijen md5ka je dlouhá 128bit, což při té šestnáctkové soustavě dělá nějakých 32 znaků, které si musí uživatel zapamatovat, kdyby místo toho použil znaky z běžné klávesové mapy, tak má něco jako 7 bitů na znak, což při 32 znacích dělá 224 bitů. Případně při stejné bezpečnosti (tj. délka 128bit) musí použít zaokrouhleně jen 19 znaků...

Snad každému je jasné, že 2^128 << 2^224

[Ondrej 'SanTiago' Zajicek]

To neresi problem, ze takovy ssh utok muze dost vytezovat CPU.

[zdenek-hbr]

v ankete chybi: "nevim, logy nezkoumam"

[Josef Kufner]

Příloha:

• log-auth-week.png (3430 bytů)

Jo, přesně tak

Btw, jako detekci útoku používám mrtg sledující rychlost růstu souboru /var/log/auth.log. Když je tam kopeček, tak tam byl útok (viz příloha)

[Luk]

Ano, tento typ útoku jsem zaznamenal také, ale v drtivé většině to nebylo více než 10 pokusů/uzlů na jedno uživatelské jméno. Zatím vidím jako nejjednodušší řešení (když nepočítám whitelist s povolením jen určitých adres a zákazem všech ostatních - bohužel nemohu použít) volbu vhodných hesel (tedy ne "admin" a podobně ), případně povinnou autentizaci klientským certifikátem.

[trekker.dk]

Taky se občas někdo snaží - většinou zkouší roota (je zakázaný) a pak různá další jména podle slovníku - zatím ještě neuhodli jméno účtu, na který se jde přihlásit.

[Shadow]

Tyhle útoky už pozoruji nějaký čas (tak cca půl roku zpět). Kupodivu i na mém malém domácím servříku. Bohužel na ostrých strojích, které spravuji, si obvyklé triky jako povýšení SSH portu či přihlašování pouze pomocí klíčů nemohu dovolit. Ale i tak, dokud to budou pořád jen útoky zkoušející jména a hesla ze slovníku, tak se toho nebojím.

[Käyttäjä 11133]

Bohužel na ostrých strojích

&

přihlašování pouze pomocí klíčů nemohu dovolit.

To si děláš srandu, ne? Ten luxus, jakým je povolené přihlašování pomocí hesla si snad můžeš dovolit akorát tak na domácích strojích, ne? Nebo to myslíš vážně, že se na produkční stroje přihlašujete pomocí hesel a máte přihlášení heslem povolené?

A přehazování SSH na jiný port je taky blbost.

[Michal Fecko]

Bohužel na ostrých strojích

&

přihlašování pouze pomocí klíčů nemohu dovolit.

To si děláš srandu, ne? Ten luxus, jakým je povolené přihlašování pomocí hesla si snad můžeš dovolit akorát tak na domácích strojích, ne? Nebo to myslíš vážně, že se na produkční stroje přihlašujete pomocí hesel a máte přihlášení heslem povolené?

A přehazování SSH na jiný port je taky blbost.

jj, telnet rules!

[xkucf03]

< vtip > náhodou, telnet by byl rulezní, pochybuji totiž, že by se ho dneska někdo pokoušel hackovat < / vtip >

[pavlix]

Já nepochybuju :).

[Shadow]

Myslím to samozřejmě úplně vážně. Doporučuji nesoudit předčasně a hlavně bez znalosti podstatných detailů jako třeba typ provozované služby, požadavky vedení, apod. Zatím jsem neviděl webhosting, který by měl přihlašování pouze pomocí klíčů. Ba co hůř, mnohde se stále používá FTP a přístup přes SCP/SFTP/FTPS aby člověk vyloženě hledal.

[pele]

A přehazování SSH na jiný port je taky blbost.

Proc by to mela byt blbos, ja sem se takhle utoku na me verejne adresy zbavil. Samozrejme sem nasledne zakazal autentizaci heslem.

[Shadow]

Když jste zakázal autentizaci heslem, tak jste nemusel přehazovat port. Ale jinak souhlasím, není to blbost, i když autentizace pomocí klíčů je podstatně lepším řešením.

[Grunt]

+1

Také nechápu proč by to měla být blbost. Téže jsem tak učinil a spokojeností jen bručím.

[Käyttäjä 11133]

Protoč.

[Mrkva]

Není to blbost. Minimálně to pomůže od vytěžování linky a CPU stupidními boty (i když je povolené přihlašování jenom klíčem)

[anicka]

Blbost to samozřejmě není. Když tomu neříkáš "bezpečnostní opatření" ale "hack, díky kterému je můj server mnohem méně vytížený," bude vše v naprostém pořádku

[CEST]

Když tomu neříkáš "bezpečnostní opatření" ale "hack, díky kterému je můj server mnohem méně vytížený," bude vše v naprostém pořádku

Do ty doby, nez ty zombie zacnou delat tcp scany. SSH se docela hezky identifikuje.

[xkucf03]

Aspoň ti to pomůže rozlišit vážnější zájemce o hacking od úplných lam, které nemá cenu řešit.

[Käyttäjä 11133]

Ono nemá cenu řešit žádný útok, který spočívá v tipování usernamů s hesel. (Za předpokladu, že člověk nemá nastavené stupidní hesla a pokud taková hesla má, tak mu nepomůže ani 10 změněných portů)

[xkucf03]

K tomu nestandardnímu portu jde udělat ještě malé vylepšení: pro moje známé adresy bude povolena 22, aby uživatele neobtěžovalo zadávání jiného portu, pro cizí adresy bude fungovat jen port nestandardní (přesměrovaný např. v iptables).

[Filip Jirsák]

Možná jste si nastavili nějaký systém pro detekci a odražení útoku. Pak si raději projděte logy, protože váš systém se asi již několik dnů míjí účinkem.

Můj systém se účinkem nemíjí, nemám totiž žádný systém na „detekci“ a „odražení“ útoku – používám přihlášení klíčkem a přihlášení heslem je zakázané. Pokusy uhodnout heslo mne netrápí…

[alfonz]

no já jsem třeba teďka náhodu zjistil, že můj /var/log/auth.log mám 200MB...:D což jsem teda ani ve snu netušil;)

[ja]

Tak po prve - root je na ssh zakazany a po druhe - uz moje samotne prhlasovacie meno je nezistitelne. A to nehovorim o hesle (ktore je samozrejme menene kazdy mesiac) - makepasswd --char=25

[Michal Fecko]

Tak po prve - root je na ssh zakazany a po druhe - uz moje samotne prhlasovacie meno je nezistitelne. A to nehovorim o hesle (ktore je samozrejme menene kazdy mesiac) - makepasswd --char=25

Paranoja je skvela vec, a ani neboli vsak? A ten zablokovany root skrz SSH, to tu nespominaj, mnohym pride blbo aj po case...

[Smajchl]

tak ono pokud mas povoleny sudo, tak ti je to k nicemu zablokovat roota pres ssh... Maximalne jde o to, ze bot ma mensi sanci uhodnout tvy username, "root" zkusi asi kazdy

[Käyttäjä 11133]

Povolené sudo neznamená automaticky povolené sudo bez hesla, nebo se stejným heslem jako pro uživatele...

[miro]

Síla, už vím, že pány Kubečka a Jirsáka lze snadno odlišit v davu podle svatozáře nad jejich hlavami. Ale je to spíš debata na téma "co je to certifikát", památná debata na téma PermitRootLogin no proběhla spíš tady.

[Luk]

Síla, už vím, že pány Kubečka a Jirsáka lze snadno odlišit v davu podle svatozáře nad jejich hlavami.

Otec a syn. Ještě tu chybí Duch svatý

[Käyttäjä 11133]

To jsem já... Kudy chodím, tam nadávám na ifconfig... :D A taky na přečíslování SSH na jiný port...

[Filip Jirsák]

A nechtěl byste si k tomu přibrat i to varování, že se za žádnou cenu nemají nevydávat z ruky privátní klíče? Jo a pak ještě různá dvojitá, trojitá a vícečetná hesla jako zvýšení bezpečnosti. Abyste to měl komplet…

[Käyttäjä 11133]

[pavlix]

Nemají nevydávat? To že musím povinně vydat svůj soukromý klíč komukoliv? :D

To asi ne, že ;).

[pavlix]

Když koukám na tu konstrukci věti, tak teda i vidím, ja vznikala.

[pavlix]

*y

[Filip Jirsák]

No jo, vznikala, vznikala, ale nějak nedovznikla. Ta poslední iterace na nemají vydávat už nějak neproběhla

[miro]

Už jsem se chtěl polekat, že jste se nakonec nechal od papundekla přesvědčit

[Petr Tomášek]

Si říkám, že by vlastně vše vyřešilo, kdyby ssh umožňovalo připojení pomocí dvojice, nebo trojice hesel. IMHO by i dvě slabší hesla byla ve výsledku velmi těžko rozlousknutelná a hlavně by to bylo uživatelsky zapamatovatelné :)

[Filip Jirsák]

Stačí si to jedno heslo, které používáte, prodloužit o jeden znak, a výsledek bude bezpečnější, než kdybyste používal trojici hesel stejně dlouhých, jako je vaše současné heslo.

Pokud máte heslo dlouhé x znaků a budu brát 26 možných znaků hesla, musí útočník vyzkoušet maximálně 26^x kombinací. Když heslo prodloužíte o 1 znak, bude to 26^x+1, tedy 26×(26^x) ale když použijete 3 hesla o délce x, bude to jenom 3×(26^x).

[Petr Tomášek]

ale když použijete 3 hesla o délce x, bude to jenom 3×(26^x).

Blbost. Když použiji tři hesla, tak samozřejmě musejí být správně všechna zároveň, tj. bude to 26^3x! Což se samozřejmě liší od hesel s délkou 3x jedine v zapamatovatelnosti a možnosti použít např. tři triviální („slovíková“) slova...

[Filip Jirsák]

Pokud to budou 3 hesla, která zadáváte postupně, a každé se ověřuje zvlášť (tj. zadáte 1. dozvíte se, zda je správně, zadáte druhé atd.), je to 3×(26^x) – ověřují se nezávisle na sobě 3 hesla. Pokud zadáte první heslo, nedozvíte se nic, zadáte druhé, také nic a až po třetím se hesla zkontrolují, je to úplně to samé, jako by to bylo jedno heslo o trojnásobné délce – a k tomu nepotřebujete žádnou podporu v ssh, můžete si prostě ta tři triviální hesla napsat za sebe.

[MJ]

je to úplně to samé, jako by to bylo jedno heslo o trojnásobné délce

Přísně vzato, není, pokud jsou ta tři hesla různě dlouhá. Pro tři neprázdná hesla o celkové délce N mám 26^N*C(N-1,2) = 26^N*(N-1)*(N-2)/2 možností. To lze samozřejmě překonat přidáním několika málo (totiž 2*log₂₆ N) znaků k jedinému heslu.

[Petr Tomášek]

Pokud to budou 3 hesla, která zadáváte postupně, a každé se ověřuje zvlášť (tj. zadáte 1. dozvíte se, zda je správně, zadáte druhé atd.), je to 3×(26^x) – ověřují se nezávisle na sobě 3 hesla.

A kdo by dělal takovou hovadinu? Samozrejme, ze zadate tri hesla, a pak se dozvite, ze bud jsou z nich vsechna spravna, nebo "alespon jedno heslo neni spravne"...

Pokud zadáte první heslo, nedozvíte se nic, zadáte druhé, také nic a až po třetím se hesla zkontrolují, je to úplně to samé, jako by to bylo jedno heslo o trojnásobné délce – a k tomu nepotřebujete žádnou podporu v ssh, můžete si prostě ta tři triviální hesla napsat za sebe.

Vy vubec nectete prispevky, na ktere reagujete, ze? Samozrejme, ze to neni to same, protoze zapamatovat si (a nejen pro BFU) heslo typu „nejakydlouhynesmyslbla“ je daleko tezsi, nez tri slova (typu „zizala“, „sroubek“, „karburator“). To, ze lze vymyslet bezpecna hesla preci dnes neni problem, problemem je, jak donutit uzivatele, aby skutecne bezpecne heslo mel a zaroven aby si je byl schopen zapamatovat!

[xkucf03]

Uživatel si může zapamatovat tři běžná slova, ale je to velice hloupé - stačí na to slovníkový útok.

Pokud by byla tři samostatně zadávaná hesla, dejme tomu: abcd efgh chijk, tak to má oproti jednomu dlouhému heslu jedinou výhodu: abcd efgh chijk a abc def ghchijk jsou dvě různé věci, zatímco, kdyby se to psalo do jendoho hesla, množina možností je při stejné celkové délce menší.

Zlepšení je to jednak velmi malé, že se kvůli němu nevyplatí implementovat nový mechanismus, a jednak velmi pochybné - dá se na něj dívat i jako na zhoršení, protože podněcuje uživatele k tomu, aby používali několik jednoduchých slov a ty se dají snadno hádat se slovníkem.

[Petr Tomášek]

Uživatel si může zapamatovat tři běžná slova, ale je to velice hloupé - stačí na to slovníkový útok.

Předpokládejme běžný slovník o 10.000 slovech. Pak při třech heslech to je 1*10¹² kombinací. Pokud bychom uvažovali úplně náhodné heslo složené z osmi malých písmen, pak to bude 26⁸, což je cca 0.2*10¹² možností...

[xkucf03]

Heslo z osmi malých písmen je nedostatečné. Obecné doporučení zní, že heslo by mělo obsahovat alespoň 3 ze 4 skupin znaků (velká písmena, malá písmena, číslice a zvláštní znaky). Což dělá 26 + 26 + 10 + 10* = 72. Vybereme si třeba jen velká, malá a číslice a máme 62 možných znaků. Počet kombinací je tedy 62⁸, což je řádově 200x víc než ty tři hesla.

*) dejme tomu, že se omezíme jen na: !@#$%^&*{}

[Filip Jirsák]

Jediné, co jste přidal, je nutnost uhodnout ještě pozici dvou mezer mezi hesly. Jak se tím zvýší počet možných kombinací už vám napsal Martin Mareš, konkrétně pro celkovou délku hesla 5 písmen dosáhnete lepšího výsledku přidáním 1 znaku, pro celkovou délku hesel do 26 znaků dosáhnete lepšího výsledku přidáním dvou znaků.

[xkucf03]

Tak si prostě tu trojici hesel vymysli a piš je vždy za sebou, ne?

[pc2005]

Jak je na tom bezpečnost ssh hesla v závislosti na jeho délce a na délce šifry, protože pokud by bylo heslo, které je delší než šifra méně bezpečné, tak po spojení všech tří hesel, by se ochrana mohla teoreticky oslabit.

[Petr Tomášek]

A jak k tomu donutit BFU, ha?

[xkucf03]

1. Technickými prostředky - stanovit pravidla pro hesla: délka, skupiny znaků, kontrola proti slovníku, kontrola proti předchozím heslům (ty si můžeme schovávat dobře zahešovaná)
2. Bezpečnostní politikou - stanovit odpovědnost uživatele za operace provedené jeho s přihlašovacími údaji. Když ztratíš peněženku s kartou a máš na ní napsaný PIN, tak je to tvoje blbost a banka ti za případné škody taky nic nedá. Měl sis PIN chránit. Stejně tak je to s heslem.

[vladky]

Nuz ja pouzivam SSH na inom porte a mam povolene prihlasovanie iba klucom

[Aleš Kapica]

Řeším to poměrně jednoduše. Používám kombinaci nastavení ssh serveru, kde mám přihlášení pouze na povolené uživatele a aplikaci denyhosts, u které mám nastavenou blokaci na VEŠKERÉ služby z blokované adresy na tři dny. Je to dost dlouhý interval na to aby případné útočníky přešel elán. Pochopitelně důvěryhodné stroje mám povolené, takže se mi nemůže stát že bych se nedopatřením zablokoval.

[trekker.dk]

Používám kombinaci nastavení ssh serveru, kde mám přihlášení pouze na povolené uživatele a aplikaci denyhosts, u které mám nastavenou blokaci na VEŠKERÉ služby z blokované adresy na tři dny.

Před nějakou dobou jsem tady četl něco jako "když Jezinky klepou moc často, jelen už se domů nedostane."

[xkucf03]

"Postihl" v anketě znamená, že mě hacknuli, nebo že to zkoušeli? Samozřejmě, že to zkoušeli. Ale řeším to takhle:

• Na strojích, kde je firewallem povolené připojení z libovolné IP adresy mám zakázané přihlašování heslem, jen SSH klíče. + uživatel musí být uveden v AllowUsers v sshd_conf.
• Na stroji kam se přihlašuji heslem, mám firewallem omezený počet IP na 1-2 adresy.

DDoS jsem neřešil - intenzita útoků zatím nebyla tak vysoká, abych musel řešit zátěž CPU.

[CEST]

Na tohle je asi nejlepsi port-knocking. Client musi nejdriv poslat nekolik SYN packetu na ruzny (predem definovany) porty a pak se mu otevre pristup na SSH. V linuxu to pujde resit urcite jednoduse, pro Windows by slo pouzit BAT s nmapem. Samozrejme to predpoklada povoleni na firewallu u klienta, ale pokud by byl z nejaky predem definovany site, tak se SSH pristup muze povolit rovnou, a pro ostatni jen "klepani". Zadny zmeny portu, zadny klice.

[pc2005]

Jak se vyřeší dvě a více současných klepání z jedne IP adresy?

[MJ]

Proč se vlastně něčím takovým zabývat? Pokud nepoužívám triviální hesla, nemají sebemenší šanci uspět. Koneckonců, nejlepší je, jak již bylo zmíněno, přihlašování heslem vůbec nepoužívat a zásadně používat klíče, a pak mají úplnou smůlu.

Až jich bude tolik, že začnou mému serveru žrát příliš mnoho paměti nebo procesorového času, začíná to mít smysl řešit.

[Petr Tomášek]

Ano, problem zacina a konci tim, jak vynutit, aby BFU a LFU(*) ona netrivialni hesla meli.

(*) Lazy Fucking User

[xkucf03]

BFU, LFU? Ty dáváš takovým uživatelům přístup přes SSH? Někdy ho opravdu potřebují, třeba aby mohli nahrávat soubory na web, ale takoví uživatelé se většinou připojují z jednoho dvou počítačů. Pak není problém s tím, že by museli s sebou nosit SSH klíč. Stačí zakázat přihlašování heslem a nasměrovat je třeba na tento návod: SSH klíče ve Windows - PuTTY.

[frEon]

uplne jednoduse. muzes si to nastavit v /etc/pam.d/password

[fixinko]

Pouzivam denyhosts (mierne paranoidne nastavene + synchronizacia s "centralnym" blacklistom) a k plnej spokojnosti :). Aktualne ma /etc/hosts.deny cca 3000 zaznamov :).

[alkoholik]

<google>portknock</google>