Honeynet: kdo se přilepil za poslední 3 měsíce

Jiří Machálek z Laboratoří CZ.NIC připravil pro blog sdružení další statistiky spojené s projektem Honeynet. V přehledu je vedle jiného uvedeno i to, že nejaktivnější útočníci za poslední tři měsíce byli skryti ze dvěma tchajwanskými IP adresami; v obou případech se připojovali téměř výhradně na port 445, a to více než 88000krát (více než 14000krát nahrávali jednu variantu viru Conficker). Další významní útočníci byli z Ruska, Kazachstánu, Venezuely nebo Číny.

V aktuálním reportu jsou i dvě novinky. Jednou z nich je přehled nejčastěji nahrávaných virů; celkem bylo za uvedené období zaznamenáno 33165 nahrání virů (z toho 600 unikátních). Průměrně tedy jeden virus každé 4 minuty. Druhou zajímavou informací je potom přehled nejčastějších kombinací, které útočníci zkoušeli při přístupu na službu SSH v červenci.

13.8.2012 11:46 | Vilem Sladek | Zajímavý článek

Komentáře

[Michal Kubeček]

Kam ten svět spěje, už ani s devítiznakovým heslem nemůže být člověk v klidu…

[Pavel Čejka]

Přidej ještě nulu, zvýšíš bezpečnost

Ta ostatní hesla taky stojí za to. Ono je vůbec divné, že si někdo zapne SSH nezakáže roota a používá prosté heslo a notabene kombinace, které bych se neodvážil použít ani u bezvýznamného webmailu ...

[Sten]

+1. Na veřejném serveru přístup na disk jenom přes SSH a jenom na klíče (a to i pro zákazníky). Na soukromém počítači sice na heslo, ale root zakázán a rychlost zkoušení firewallem omezena. A zatím to drží

[Prcek]

Já se v tom nevyznám, ale jaký je rozdíl v tom zakázat rootovi přihlašovat se na ssh, když se pak jako uživatel můžu přihlásit na roota přes su? Že není předem známé uživatelské jméno (tak jako je známé právě jméno root)? Nebo v čem je ta vyšší bezpečnost?

[Michal Kubeček]

Já se v tom nevyznám, ale jaký je rozdíl v tom zakázat rootovi přihlašovat se na ssh, když se pak jako uživatel můžu přihlásit na roota přes su?

Není v tom (podstatný) rozdíl. Co je ale skutečně užitečné, je zakázat autentizaci heslem (všem).

[aubi]

Pokud Ti neprijde podstatne dramaticke zvyseni slozitosti lamani (rekneme nejakych 7 znaku hesla roota versus 7 znaku jmena krat 7 znaku hesla plus 7 znaku roota, tedy nejmin 7^25krat slozitejsi), pak mas pravdu.

Nicmene certifikaty jsou samozrejme certifikaty, to mas pravdu. A port knocking je taky fajn.

[Michal Kubeček]

rekneme nejakych 7 znaku hesla roota versus 7 znaku jmena krat 7 znaku hesla plus 7 znaku roota, tedy nejmin 7^25krat slozitejsi)

Za prvé si pletete 7^25 a 25^7, cože je docela zásadní rozdíl. Za druhé by i po opravě váš výpočet fungoval pouze v případě, že by útočník obě hesla musel uhodnout současně, což není pravda. Snaha použít uživatelské jméno coby další heslo, je také hodně nešťastná. Takže ve skutečnosti tam není násobení ale sčítání a pouhým prodloužením (jednoho) hesla o jeden znak dostanu o (desítkový) řád vyšší bezpečnost proti útoku hrubou silou. Pokud autentizaci heslem zakážu úplně, jsem už úplně někde jinde někde úplně jinde.

Ale to už jsem tu vysvětloval tolikrát, že by stálo za to napsat na to FAQ - jenže on by ho někdo z těch, kdo věří na "princip dvou dveří" nejspíš hned "opravil".

[Ondroid]

Tohle se tu řešilo už mnohokrát a už je to tu zas. Vždycky se najde někdo kdo si myslí, že dvě hesla v téhle souvislosti jsou lepší než jedno pořádné. Fakjů už mě taky napadlo, jen to napsat :@)

[Radek Hladik]

Tak schválně, zda to někdo opravi... http://www.abclinuxu.cz/faq/bezpecnost/je-bezpecnejsi-prihlasovani-pomoci-bezneho-uzivatele-a-su-nez-primo-na-roota

[Michal Kubeček]

Dneska na to čas asi mít nebudu, ale bylo by dobré zmínit i to, že pokud příslušný uživatel při každém přihlášení důsledně nekontroluje informaci, odkud a kdy se přihlásil naposledy, a před každým použitím su (sudo) důsledně nezkontroluje, že to není funkce nebo alias nebo úplně jiné su/sudo, tak na žádné hádání hesla roota vlastně ani dojít nemusí.

[Jendа]

a před každým použitím su (sudo) důsledně nezkontroluje, že to není funkce nebo alias nebo úplně jiné su/sudo

Tohle uživatel zkontrolovat nemůže, respektive nenapadá mě způsob, jak by mohl.

[Michal Kubeček]

Nemůže samozřejmě poznat to, že někdo, kdo už roota získal, nahradil /usr/bin/su něčím jiným - ale v takovém případě už je stejně pozdě. Měl jsem na mysli spíš scénář, kdy útočník získá v první fázi přístup pod daným uživatelem a pak místo toho, aby se snažil lokálně hádat heslo roota, prostě nastaví alias nebo funkci nebo do ~/bin dá vlastní binárku nebo skript (nebo symlink). To jsou věci, které se zkontrolovat dají, ale asi jen málokdo to opravdu dělá.

Na druhou stranu, když tak o tom přemýšlím, i tahle kontrola by šla hodně znepříjemnit, upraveným ls počínaje, přes to, že se z ~/.bashrc exec-ne upravený shell, …

[Jendа]

Na druhou stranu, když tak o tom přemýšlím, i tahle kontrola by šla hodně znepříjemnit, upraveným ls počínaje, přes to, že se z ~/.bashrc exec-ne upravený shell, …

Přesně to jsem myslel.

[Radek Hladik]

To je jen důsledek toho, že už to prolomení toho prvního hesla je dost vážný bezpečnostní problém. Někdo může namítnout, že se to dá eliminovat předem - například se při každém přihlášení může rozbalit celý home toho běžného uživatele z nějaké "zálohy". Ale celé mi to připadá jako zbytečné zlepšování principielně špatného řešení.

Co jsem do toho FAQ taky nenapsal (protože to tam podle mně přímo nepatří) je, že přímé přihlášení na roota je podstatně pohodlnější, co se týče SCP a SFTP. Viděl jsem jako docela pěknou praxi, že admin editoval konfiguráky v /etc přes WinSCP a ještě si dělal lokálně na stanici kopie. To s dvojím přihlášením neuděláte... A já taky docela rád na serveru pracuju jako root ze svého oblíbeného file manageru z Windows stanice....

[Bedňa]

To sa tu už rozoberalo a skončilo to nastejno.

[intense]

Imho, vypnúť priame prihlásenie na roota cez SSH je síce zvýšenie bezpečnosti ale nemyslím si že nejaké super level. Predsa len keď sa už útočník dostane na nejakého usera do systému tak má už k dispozícii viacej ciest ako exploitovať zraniteľnosti a získať root euid. Podľa mňa je to rovnaké riziko keď sa dá na non-root usera prihlásiť s heslom

[snajpa]

Jsou pripady, kdy zakazat root login pres SSH nejde (nebo by to vyzadovalo hodne vlastniho programovani/hackovani cizich programu). Nemyslim si, ze to nejak extremne zvysuje bezpecnost (obzvlast kdyz vezmu bezny konfigurace serveru). Ale se zbytkem souhlasim.

[Jendа]

Zapnul jsem SSH a nezakázal roota, co mi hrozí?

(přihlašování heslem je buď vypnuté nebo s entropií 80+bitů)

[Šangala]

Že se někdo (kdokoliv) přihlásí na root-a rovnou.

[Jendа]

Nemůže, nezná 80bitové heslo nebo 2048bitové prvočíslo.

[Šangala]

Ano nezná, ale pokud jej uhodne, tak hrozí přihlášení rovnou na root-a, je to prostě jen odpověď na otázku co hrozí.
Jinak přihlášení povolené z venku na root-a certifikátem považuji za nejhorší možnost, protože to beru jako největší riziko a to proto, že stačí jen scizit ten certifikát a pokud není chránění große-big heslem, tak je to to nejednoduší k čemu může dojít a co lze okamžitě použít… .

[Jendа]

Hmm, a jaká je pravděpodobnost zmíněných událostí?

[Šangala]

To už je jiná otázka…, ale u té druhé části je to obvykle pravděpodobnější, než že nějaký automat či „útočník“ rozlouskne 20+ znakové heslo, nebo, že jej někdo zaznamená.

[miro]

u té druhé části je to obvykle pravděpodobnější

Jenže nepříznivost té druhé části uměle vytváříte podmínkou, že soukromý klíč není šifrovaný.

[Šangala]

Nebo je chráněný slabým heslem, což už tak umělé není…

[miro]

Osobně nevidím důvod chránit klíč pomocí slabší passphrase než jaké je heslo roota. U mě osobně je to srovnatelné.

[Šangala]

Osobně ho mám paranoidně ještě o kus silnější (je snazší jej získat, než heslo k root-ům, ikdyž obojí je v mém případě zatím technicky nemožné), ale věřím tomu, že několik z těch, co to tady čtou, se hluboce zamysleli…

[miro]

ROFL.

BTW - na ssh není třeba certifikátů, stačí dvojice klíčů. Jedinci, kteří jsou dost paranoidní na to, aby zakázali přihlášení na ssh heslem, budou AFAIK dost paranoidní i na to, aby si soukromý klíč zašifrovali - ostatně ssh-keygen tuto volbu nabízí zcela standardně. Šifruje se, tuším, AES-128.

[Radek Hladik]

Upřímně řečeno, docela by mě zajímalo, jaké máte v dané oblasti vzdělání a praktické zkušenosti. Na jednu stranu vynášíte poměrně ostré soudy a na druhé straně mluvíte o "scizení certifikátu" a "certifikátu chráněním heslem", až to skoro vypadá, že se v dané oblasti pramálo orientujete.

Ale protože v tom je přeci jen zrnko pravdy, dovolím si odpovědět. Celé zabezpečení takového přihlašování je postavené na zabezpečení privátního klíče a to pouze na něm. Vše ostatní může být veřejné, zveřejněné, atd. Tady je například můj veřejný klíč, na emailu vám klidně řeknu, na kterém serveru je povoleno přihlášení roota s tímto veřejným klíčem:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAstrDBRm02D5twGH3N
FU9p44VgqfvLPmVPD8RSwEbmk+2N8o4MVIBHJqGsLf0kM0BIw/sbImajqk
YmLDwgw1L0hb3HHUbm6zj0OvwklIOo3q+cKrWU/A5TzJNfihdjYYx2cB7
GeEOveOlmAxB5wVlUfH7IRQsyShnds1s5sf2S5jV3TEgA0fHk56A99jrAg4D
/qE92tLHzTOHlMhVTkGCQZmZDes08NXmiYwSedTcWysXgZ8gFpJhpaGgYgYAN
h0BjKuOitp+1RNHKlzftWF+6A52kKeJRxG3Ltz83/iyz4whSxmfs6ebg/Mzvw
Ulr3sqX7BbiFtAkQ7A/CMk9hKelw==

Protože privátní klíč má pouze několik set bajtů, je možné jeho zabezpečení věnovat náležitou pozornost. Samozřejmostí je možnost šifrovat, kde je samozřejmě nutnost mít dostatečně bezpečné heslo. Další možností je uložení privátního klíče (nebo dokonce přímo generování) na hardwarovém zařízení, které je specielně navržené, aby privátní klíč nevydalo.

[Šangala]

Nemám přímo vzdělání v informačních technologiích, praktické zkušenosti bych řekl že ano, ostré soudy nevynáším aspoň jsem to neměl v úmyslu, spíše bych to označil za lehkou nadsázku.
Pravdou je, že jsem použil nepřesnou terminologii (to já často), myslel jsem scizení privátního klíče.
Obvykle se řeší bezpečnost jen „matematicky“, a neřeší jiná zranitelná místa.
Takže jsem chtěl poukázat na to, že když povolím přihlašování root-ovi a jen klíčem tak to klidně může ohrozit server více, než pokud tam nastavím 20+ znaků heslo, které mám v hlavě (berme to tak, že prakticky obě volby jsou za hranicí kdy je možné je zlomit).
Protože ten klíč třeba je někde na NTB a někdo si jej prostě vezme (tam už řešíme zabezpečení přístupu ke klíči), nebo ještě snadněji, máte klíč v ssh-agent-ovi, a někdo si jen pustí terminál na tom NTB a je tam, pokud je to na heslo, tak toto nelze, žít v iluzi, že přihlašováním klíčem jsem si vyřešil bezpečnost je příjemné, nicméně může to být zranitelnější.
Výčet toho, jak si zabezpečíte svoje PC, či jak zamykáte (zbytečně) obrazovku při odchodu není třeba rozebírat. Pokud bych se měl dostat na server a věděl o někom kdo tam má přístup a je navíc na stejné síti, určitě bych první věnoval pozornost jeho PC ne serveru.
To je stejné jako, že i „security-by-obscurtity“ (tedy obvykle nevědomost), má svou váha a zvyšuje zabezpečení, byť těžce definovatelně a nikdy nemůže stát samostatně…, matematika je jen na to, aby se vyloučili možnosti, na které nemám prostředky…

[miro]

Protože ten klíč třeba je někde na NTB a někdo si jej prostě vezme (tam už řešíme zabezpečení přístupu ke klíči), nebo ještě snadněji, máte klíč v ssh-agent-ovi, a někdo si jen pustí terminál na tom NTB a je tam, pokud je to na heslo, tak toto nelze, žít v iluzi, že přihlašováním klíčem jsem si vyřešil bezpečnost je příjemné, nicméně může to být zranitelnější. Výčet toho, jak si zabezpečíte svoje PC, či jak zamykáte (zbytečně) obrazovku při odchodu není třeba rozebírat. Pokud bych se měl dostat na server a věděl o někom kdo tam má přístup a je navíc na stejné síti, určitě bych první věnoval pozornost jeho PC ne serveru.

parse error

Chápu to tak, že chcete říct, že s klíčem se dá nakládat prasácky, a že v tom případě může být bezpečnost výrazně nižší, než pokud se přihlašujete heslem, se kterým prasácky nenakládáte. O tom není sporu. O srovnání bezpečnosti těch dvou metod v obecné rovině to ovšem neříká zhola nic.

[miro]

Jo sorry, tak už jsem to rozparsoval. Ale na zbytku mého příspěvku to nic nemění. Ke klíči a k passphrase se je samozřejmě zapotřebí chovat stejně paranoidně jako k heslu.

[Šangala]

Chápete správně, a neřekl bych „prasácky“, možná nezodpovědně…, že máte (nebo kdokoliv jiný) klíč ssh-agent-ovi a odběhnete a jen zamknete obrazovku, nebude zas tak řídký jev (možná dokonce zavřete ten „kritický terminál“ )…
O srovnání metod zabezpečení přímo ne, ale o metodě získání přístupu k serveru ano.
Pokud je heslo v hlavě, tak bezpečnost přístupu k serveru definuje hlava a server, pokud máte klíč, tak navíc zabezpečení klíče spolu se všemi místy kde se nachází. A to třetí je obvykle nejzranitelnější, „však ho mám na šifrované partition a kdyby něco ještě je tam pro jistotu 6 znaků heslo“.

[Radek Hladik]

No já jsem si například putty ssh agenta upravil tak, že a) při každém použití klíče vyskočí bublinu b)před použitím klíče chce zadat určitý PIN (pokud se PIN nezadával před krátkou dobou). A obecně není tak jendoduché přesvědčit agenta, aby někomu na stejné síti udělal autentizaci.

Ale pokud se jedná o důležité servery, pak opravdu není problém použít klasický šifrovací token...

[Šangala]

„aby někomu na stejné síti udělal autentizaci“

- myslel jsem něco mnohem jednoduššího (a co s heslem nejde), a to když si odskočíte na 1 min, a já si otevřu terminál na Vašem PC, přihlásím se na server (bo máte klíč v agent-ovi), udělám si co potřebuji a za 30 sec, jsem zpátky a od sebe přihlášený na server a otvírám si vrátka.

[Radek Hladik]

Za předpokladu, že mám klíč v agentovi, že znáte můj PIN ke klíči, tak ano. A za předpokladu, že ten klíč není na klíčence, kterou jsem si odnesl sebou...

[Jendа]

A nebo udělá úplně stejná vrátka na tvém počítači a počká, až se přihlásíš heslem k nějakému ze serverů. V čem je rozdíl?

[Šangala]

To je prakticky o kus složitější - dostat se do konkrétního terminálu přihlášeného uživatele a vzdáleně, a pokud by to tak bylo, tak je zas jednoduší (když už se dostanu na přihlášeného uživatele) jen sis pustit svůj terminál, který si opět z agenta vezme klíč, tedy i v tomto případě je na tom klíč hůř.
Nebo pokud už jsem tam (na tvém/mém počítači), tak samozřejmě mám možnost si ten klíč vzít a doma jen čekat až rozlousknu heslo…
Zásadní rozdíl je v tom, že systém je „ohrožený“ ze všech míst, kde jsou klíče uložené.
Snažím se ukázat jen na to, že tvrzení: „přihlašování klíčem je bezpečnější než heslem“, není obecně pravdivé, zneužít klíč může být výrazně snadnější než zneužít heslo byť metoda vlastního přihlášení má vyšší odolnost a je to o to nebezpečnější, že přihlašování klíčem obecně budí falešný pocit vyššího bezpečí.

[miro]

Zásadní rozdíl je v tom, že systém je „ohrožený“ ze všech míst, kde jsou klíče uložené.

Zatímco v případě přihlašování heslem je systém ohrožený ze všech míst, odkud se na server přihlašujete. Pravda, z flashky se přihlásit nelze. Na druhou stranu pokud se přihlašujete heslem, potřebuju jenom to heslo. Klíč chráněný (kvalitní) passphrase je de facto dvoufaktorová autentizace. Když se vám podaří odkoukat zadávání passphrase, není vám to bez klíče k ničemu. Když se dostanete ke klíči, není vám bez passphrase taky k ničemu. Pravda, můžete "čekat, až ji rozlousknete". Tak můžete tu passphrase odkázat svým praprapravnukům.

[Šangala]

„odkud se na server přihlašujete.“ - platí jak v případě klíče tak v případě hesla a jak jsem posal už výše, může být snadnější získat přístup pokud je to klíčem.
Jinak často je ten klíč uložený v NTB/PC daného správce a často v případě některých externích správců jsou i hezky pohromadě. A že fčul lze lousknout možná už i 8-10 znaků v rozumném čase, neznamená, že za ½ roku to nebude víc (a robotem heslo 6 znaků na server nelousknu ani za ½ roku).

[miro]

platí jak v případě klíče tak v případě hesla

Tak jsem to myslel.

[miro]

BTW a co known_hosts ten si šifrujete nebo si před každým přihlášením kontrolujete integritu? Pokud ani jedno, je IMHO do jisté míry jedno, jestli se přihlašujete heslem nebo klíčem, nebo jestli si soubor se soukromým klíčem šifrujete.

[Jendа]

Nebavíme se o pozměnění (pak by ale ani šifrování known_hosts stejně nepomohlo), nýbrž o odcizení.

[miro]

Ono se v tomhle vlákně smíchalo víc věcí dohromady. Já jsem chtěl poukázat na to, že known_hosts je možným vektorem útoku. Přitom ho na rozdíl od klíče člověk mít musí (no vlastně nemusí, ale takových asi nebude mnoho - viz podnadpis - "První akční paranoidní postup..." - proč tam, hrome, nejsou kotvy?).

known_hosts se zneužije trochu hůř než klíč, ale zatímco klíč si asi většinou člověk zašifruje (ssh-keygen k tomu ostatně by default nabádá) aspoň blbým šestiznakovým heslem, o known_hosts se musí postarat sám.

A když tady Šangala na základě svých praktických zkušeností (jak alespoň naznačuje) tvrdí, že problémem klíče bývá to, že se buď nešifruje, nebo se kdekomu povaluje v rozšifrované podobě v jeho ssh agentovi (což je vektor útoku, který "heslaři" nemusí řešit), tak mě zajímalo, jak dle jeho praktických zkušeností "heslaři" nakládají s known_hosts, protože k jeho zneužití přispívá úplně stejný druh chování (nezamčené terminály atp.)

Nebavíme se o pozměnění (pak by ale ani šifrování known_hosts stejně nepomohlo)

Bavíme se o tom samém? Vy umíte pozměnit soubor zašifrovaný symetrickou šifrou, aby při rozšifrování byly v tom souboru data, která tam potřebujete podvrhnout?

[Jendа]

Bavíme se o tom samém? Vy umíte pozměnit soubor zašifrovaný symetrickou šifrou, aby při rozšifrování byly v tom souboru data, která tam potřebujete podvrhnout?

Pokud můžu pozměnit known_hosts, pravděpodobně budu schopen pozměnit i login shell, binárku ssh a další věci.

[miro]

V praxi asi většinou ano. Pokud oběť třeba nebude mít known_hosts na flešce spolu s klíčem (a vy budete mít přístup jen k té flešce). Nebo pokud nenarazíte třeba na to, že /home je mountován jako noexec a není otevřený žádný terminál s nalogovaným rootem. Pak už asi bude hodně záležet na tom, kolik máte času k útoku a co všechno stihnete (jestli je třeba čas na reboot nebo rovnou na demontáž hdd). Tady by mohl být rozdíl mezi šifrovaným a nešifrovaným known_hosts docela zásadní.

[Martin Mareš]

Zásadní rozdíl je v tom, že systém je „ohrožený“ ze všech míst, kde jsou klíče uložené.

Systém je ohrožený ze všech míst, odkud se k němu přihlašujete. Pokud je v okamžiku přihlašování terminál v moci útočníka, útočník může provést cokoliv. Na tom nic nezměníte způsobem autentikace – heslem je to stejné jako klíčem, u jiných metod (HW tokeny, systémy s jednorázovými hesly) to může být lepší v tom, že útočník nemá možnost pořídit si vlastní session, ale to je jen malé vylepšení, protože v rámci té vaši může beztak napáchat dost škody.

Výhoda klíčů se projeví, pokud útočník nemá v moci terminál, ale útočí na samotný server. Běžná hesla jsou proti útokům hrubou silou mnohem méně odolná než běžné klíče.

[Šangala]

Běžná hesla jsou proti útokům hrubou silou mnohem méně odolná než běžné klíče.
pokud ovšem neútočím na frázi klíče off-line…

[miro]

Však pan Mareš píše o útoku přímo na server. Chtěl bych vidět útočníka, který po odpovědi serveru Permission denied (publickey) začne generovat a zkoušet klíče.

[miro]

útočník nemá možnost pořídit si vlastní session, ale to je jen malé vylepšení, protože v rámci té vaši může beztak napáchat dost škody

Například přidat klíč do /root/.ssh/authorized_keys a následně si odkudkoli otevřít vlastní session.

[Jendа]

To je prakticky o kus složitější - dostat se do konkrétního terminálu přihlášeného uživatele a vzdáleně

Stačí se dostat na účet toho uživatele a nastavit si $DISPLAY.

Zásadní rozdíl je v tom, že systém je „ohrožený“ ze všech míst, kde jsou klíče uložené.

To je při přihlašování hesle taky.

Snažím se ukázat jen na to, že tvrzení: „přihlašování klíčem je bezpečnější než heslem“, není obecně pravdivé

To je pravda, tady nejsme vepři. Diskuze začala kolem direktivy PermitRootLogin, o klíčích jsem nikde nemluvil.

[Šangala]

Stačí se dostat na účet toho uživatele a nastavit si $DISPLAY. a to mi zpřístupní klíče v ssh-aggent?

Ano, diskuze sklouzla a můžu za to, ale taky netvrdím, že jste tam někde něco „nahoře“ tvrdil o klíčích…

[Jendа]

a to mi zpřístupní klíče v ssh-aggent?

Ne, to ti umožní odposlechnout zadávané heslo (v emulátoru terminálu v X).

[miro]

Pro zajímavost - jak by ta proměnná měla vypadat? Případně kde se lze dočíst víc?

[Jendа]

~/odposlechy/brmlab/12-08-15> tsocks ssh jenda@nsn.nbu.cz
Linux nsn 3.2.0-2-486 #1 Fri Jun 1 18:07:23 UTC 2012 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Aug 16 17:03:11 2012 from ee.str.mvcr.cz
jenda@nsn:~$ export XAUTHORITY=/home/jenda/.Xauthority 
jenda@nsn:~$ export DISPLAY=":0"
jenda@nsn:~$ xlsclients -l
...
Window 0x3a00024:
  Machine:  nsn
  Name:  jenda@nsn: ~
  Icon Name:  jenda@nsn: ~
  Command:  xterm
  Instance/Class:  xterm/XTerm
...
jenda@nsn:~$ xev -id 0x3a00024
...
KeyRelease event, serial 21, synthetic NO, window 0x3a00024,
    root 0x156, subw 0x0, time 3120809139, (437,604), root:(835,952),
    state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0x3a00024,
    root 0x156, subw 0x0, time 3120809140, (437,604), root:(835,952),
    state 0x0, keycode 30 (keysym 0x75, u), same_screen YES,
    XLookupString gives 1 bytes: (75) "u"
    XFilterEvent returns: False

[Jendа]

Ten první řádek tam bejt neměl…

[Ondrej 'SanTiago' Zajicek]

Snažím se ukázat jen na to, že tvrzení: „přihlašování klíčem je bezpečnější než heslem“, není obecně pravdivé, zneužít klíč může být výrazně snadnější než zneužít heslo

To je otazka. Ja osobne bych mene veril heslu, nebot se da mnohem snaze pasivne ziskat (odkoukani napr. bezpecnostni nebo skrytou kamerou, ci analyza zvuku a tempa uderu do klavesnice) Oproti tomu ziskat soubor s klicem (bez ohledu na to, zda je ci neni chranen passphrasi) muze byt o dost komplikovanejsi - je treba napr. nahackovat se do pocitace nebo ziskat fyzicky jeho harddisk.

[Pavel Čejka]

Zákazem přihlášení na roota odstíním spoustu automatů, stejně tak přesunutím SSH na jiný port, stejně tak omezením přihlášení z určitého rozsahu IP adres, snížením počtu pokusů, prodloužením prodlevy po neúspěchu/ban IP adresy atd... je mi jasné, že při cíleném útoku člověka by to bylo nanejvýš zdržení, ale alespoň se mi v logu nehromadí bordel od botů, kteří hromadně zkoušejí vše v okolí.

A samozřejmě se non-root uživatele, přes kterého se mohu sučknout dál, snažím chránit přinejmenším stejně (dlouhým klíčem, dlouhou náhodnou passfrází).

[Jendа]

Zákazem přihlášení na roota odstíním spoustu automatů

Opravdu?

Aug 14 10:56:49 deka sshd[25821]: ROOT LOGIN REFUSED FROM 89.177.89.230
Aug 14 10:56:49 deka sshd[25821]: ROOT LOGIN REFUSED FROM 89.177.89.230 [preauth]
Aug 14 10:56:50 deka sshd[25821]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=89.177.89.230  user=root
Aug 14 10:56:52 deka sshd[25821]: Failed password for root from 89.177.89.230 port 33257 ssh2
Aug 14 10:56:57 deka sshd[25821]: Failed password for root from 89.177.89.230 port 33257 ssh2
Aug 14 10:56:57 deka sshd[25821]: Connection closed by 89.177.89.230 [preauth]
Aug 14 10:56:57 deka sshd[25821]: PAM 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=89.177.89.230  user=root

[Pavel Čejka]

Kombinací uvedeného ano, jedním z opatření ne.

[Jendа]

Citovanou hlášku jsem si musel vygenerovat sám, na ten server (veřejná IPv4 adresa, SSH otevřené do světa na nestandardním portu) totiž nikdo neútočil. Srovnáním s ostatními servery to bylo právě, jen a pouze díky SSH na divném portu.

Takže - jak jsem napsal. Pouze přesunutím SSH jinak se toho zbavíš (tj. jedním opatřením), zakázáním přihlašování na roota ne (v logu pořád bude to, co jsem citoval).

[Pavel Čejka]

Ok, uznávám, blbě jsem to zformuloval a nedomyslel. Přesunutí z 22 na jiný port pomáhá možná 100% (resp. nezaznamenal jsem případ, že by to automat zkoušel jinde).

[Michal Kubeček]

Zákazem přihlášení na roota odstíním spoustu automatů, stejně tak přesunutím SSH na jiný port … alespoň se mi v logu nehromadí bordel od botů, kteří hromadně zkoušejí vše v okolí

Když vám vadí hlášky v logu, tak si jejich logování zakažte, z hlediska bezpečnosti si tím pomůžete asi tak stejně jako těmi obskurnostmi.

stejně tak omezením přihlášení z určitého rozsahu IP

Tím omezím i sebe.

A samozřejmě se non-root uživatele, přes kterého se mohu sučknout dál, snažím chránit přinejmenším stejně (dlouhým klíčem, dlouhou náhodnou passfrází).

No a pak se právě nabízí otázka, proč vlastně otravovat s druhým přihlašováním, když to vlastně nic nepřináší.

[Jendа]

když to vlastně nic nepřináší

…a naopak to znemožní jednoduché scp/rsync nějakého souboru. O zálohování rsyncem/rdiff-backupem nemluvě.

[Pavel Čejka]

Když vám vadí hlášky v logu, tak si jejich logování zakažte, z hlediska bezpečnosti si tím pomůžete asi tak stejně jako těmi obskurnostmi.

Je trochu rozdíl mezi tím, jestli pokus bota selže hned v počátku, nebo tím, že ho ignoruji a nechci vidět. ... zbytek je věc osobních preferencí a pohodlí.

[Jendа]

Je trochu rozdíl mezi tím, jestli pokus bota selže hned v počátku, nebo tím, že ho ignoruji a nechci vidět.

wut?

zbytek je věc osobních preferencí a pohodlí

Tohle vypadá spíš na OCD nebo masochismus (proč používat méně pohodlně řešení jenom tak?).

[Pavel Čejka]

Děkuji za diagnozu, ušetřil jsem 30Kč.

Masochismus to určitě není (OCD si ještě rozmyslím ). Na šifrovaném úložišti, které používám k ukládání lecčeho jiného mám připravené skripty, takže přihlášení je navenek (z uživatelského pohledu) jedno kliknutí + zadání passfráze.

[Jendа]

Dobře, ale proč se tam teda musí admin přihlašovat tak klikatě?

[xxx]

... zbytek je věc osobních preferencí a pohodlí.

Ano fail2ban, pripadne jeste v kombinaci s fw a povolenim jen vybranych adres, je asi tak 100x pohodlnejsi, nez ruzne nestandardni porty, port knocking a jine nesmysly.

[Ondrej 'SanTiago' Zajicek]

Když vám vadí hlášky v logu, tak si jejich logování zakažte,

No, on nevadi ani ten bordel v logu, jako to vytizeni CPU. I kdyz mam zakazane prihlasovani heslem a utocnik nic jineho nezkousi, tak samotne navazani sifrovaneho spojeni docela dost stoji. Bezny scan mi na desktopu udela i 30 % vytizeni. Rozumne reseni je napr. per source IP rate limiting na prichozi SSH spojeni (pomoci netfilteru).

[Radek Hladik]

No to jsem takhle jednou dostal od zákaznínka A server k nainstalovanání na hosting a že někdo další (zákazník B) se mu o to bude starat a mám mu dát věděť, až to poběží. Netušil jsem, že si povolili roota přes SSH s heslem root. Než zákazník A dal vědět zákazníkovi B, že už to běží (asi půl hodiny), tak už to administroval někdo třetí Od té doby se v podobných situacích radši přeptám

[Jendа]

Pokud je to heslo password123, tak může být i 11znakové :).

[Sten]

Praví odborníci doporučují nbusr123

[Asdasd]

co je to za chujovina? Mna by taketo hesla nenapadlo skusat :D

[Michal Kubeček]

Zkuste se zeptat strejdy Googla…

[ewew]

Uživatelia uzavretých systémov si možno neuvedomuju riziká spojené s nechránením systému pre napadnutím škodlivým kódom.

Najlepšie sú hlášky :

• Ja tam nemám nič, čo by mi mohli ukradnúť.
• Ja nie som vyznamný aby napadli môj PC.
• Používať obmedzené konto, je to zbytočné. Mne sa nechce prepínať kvôli inštalácii nejakého programu.

Niekedy to vyzerá, že bežný užívateľia nechcú si udržať plnú kontrolu na systémom. Vôbec ich nezaujíma, že ich systém môže byť zneužitý.

Možno z Honeynet-u bude forma bariery ako v anime Ghost in The Shell.

[AsciiWolf]

+1

[sidik]

A u open source tohle nehrozí? Aha, tak to jo. Ty se budeš jednou divit.

[otula]

No to by mne fakt zajímalo, jaké myšlenkové pochody tě vedly na základě příspěvku, na který reaguješ, k této dedukci.

[l4m4]

Nebo zda vůbec nějaké myšlenkové pochody proběhly...

[otula]

[Sten]

Uživatelia uzavretých systémov

[otula]

Jaj, tak to jsem přehlédnul. Jdu si sehnat popel na hlavu :)

[Jendа]

pwned

[Jendа]

Používať obmedzené konto, je to zbytočné. Mne sa nechce prepínať kvôli inštalácii nejakého programu.

Pokud uvažujeme běžný domácí desktop (což asi uvažujeme, podle těch hlášek), tak jediný rozdíl je v tom, že útočník bude muset patchnout sudo a chvilku počkat. No jéje.

Niekedy to vyzerá, že bežný užívateľia nechcú si udržať plnú kontrolu na systémom.

Ono taky udržet si ji je zatraceně těžké (čti: na mém desktopu může mít nelegálního roota až moc lidí - popisoval jsem to… tu).

[qwertz]

teda ja mam na svych serverech standardne vse krom nezbytnych portu (80,25 a jeden nestandardni) zakazano. Na tom nestandardnim pouzivam openvpn, na kterou se pripojim a teprve odsud se dostanu na SSH. Takze jsem chraneny VPNkou, kde bez privatniho klice ani bž, a pak jeste by musel prekonat rootovske heslo na ssh, nicmene uz v te chvili bych vedel ze mi nekdo zlomil privatni klic, pac by se mi VPNka odhlasovala a prihlasovala - mlatilo by se utocnikovo spojeni a legitimni spojeni a o tom bych se dozvedel. Takze pokud neni nekde jina chyba, nebo treba by se nepovedlo proniknout skrz sluzby zvenci pristupne, tak asi neni sance. Jo onehda se mi to ale trosku vymstilo, kdyz jsem posledne delal nejake šachy s certifikatama, restartnu VPN a ona nenabehla.. no musel sem jet do serverovny, ale to jsou fakt vyjimky. Stejne tak si muzu ustrihnout server treba tak ze si ho omylem zafirewalluju a jsem ve stejne kasi :) Takze nejmene 3x mer jednou rez :)

[Jendа]

(80,25 a jeden nestandardni)

Ne každý provozuje na serveru jenom HTTP a SMTP, že.

Na tom nestandardnim pouzivam openvpn, na kterou se pripojim a teprve odsud se dostanu na SSH. Takze jsem chraneny VPNkou, kde bez privatniho klice ani bž, a pak jeste by musel prekonat rootovske heslo na ssh, nicmene uz v te chvili bych vedel ze mi nekdo zlomil privatni klic, pac by se mi VPNka odhlasovala a prihlasovala - mlatilo by se utocnikovo spojeni a legitimni spojeni a o tom bych se dozvedel.

To uvažuješ remote root exploit na sshd a neuvažuješ root exploit na ovpn?

[qwertz]

ale jisteze. Ja mluvil o sobe. Ne o univerzalnim reseni na vse a pro vsechny.

"To uvažuješ remote root exploit na sshd a neuvažuješ root exploit na ovpn?"

Tak root exploit muze byt uplne na vse, treba i na ovladac sitove karty.. pak tedy ma smysl neco resit a zabezpecovat a vymyslet prekazky pro jine typy utoku nez root exploit? Vychazim ze stavu kdy mohu OpenVPN duverovat i SSHD mohu duverovat. Pokud tam existuje nejaky pruser tak dokud nebude opraven autory, nebo nekym z komunity kdo na to ma cas, nebo je za to placen, asi s tim nic jineho neudelam. Na ladeni openVPN ani SSHD a pochopeni filosofie zdrojaku jaksi nemam az tak moc casu (i kdyz rad bych na to nekdy mrkl), musim resit i jine povinnosti a navic autor, nebo komunita zabyvajici se vyvojem techto konkretnich projektu to bude mit asi rychleji nez ja.

Pak lze taky uvazovat nad vstupem zneprateleneho admina do stejne serverovny, odvezeni serveru a romlaceni serveru kladivem. To je vic nez root exploit. takzvany TDOS - Total Denial Of Service.

[Jendа]

Ne, spíš mě zajímal attack vector, kterému se harakiri s VPN bráníš.

[qwertz]

no .. mam za to ze kdyz bude SSH viset na libovolnem portu, i nestandardnim, a bude ta sluzba dostupna z venku a utocnik zjisti ze se jedna o SSH, muze zacit zkouset treba slovnikovy utok. Uhodne nejakou haluzi heslo, nebo projde skrz nejakou chybu v SSH a je tam. Pokud nebudu mit SSH viditelne z venku ale schovane za VPNkou nemusi to tak lakat k utoku na SSH, utocnik si rekne aha.. tak tady SSH neni vubec, asi je povolene jen lokalne z termninalu primo fyzicky u serveru, tak tady nebudu ztracet cas a jdu na dalsi IP ktera je na rade. Ale jako je fakt, ze muze byt chyba v OpenVPN a pak je mi tahle finta k nicemu. Privatni klic od VPNky + heslo k SSH bude patrne lepsi nez pouze heslo k SSH. Takze ja vlastne pouzivam dvoji autentifikaci. Jedna je privatni klic k VPN a druha je samotne rootovske heslo s tim, ze SSH z venku je uplne zavrene na firewallu, v podstate vse je zavrene krome nezbytnych portu tak aby ten server vubec fungoval tak jak je od neho zapotrebi, tedy jako web server a mailserver a skrz VPNku jako privatni server pro ruzne ucely a dalsi sluzby, ktere neni treba aby byly z venku viditelne.

[Zopper]

Ovšem port knocking by to zabezpečil taky, ne? Zatímco takhle si holt neřekne "je tam ssh, tak se zkusím prolomit", ale "je tam vpn, tak se zkusím prolomit" - což není moc rozdíl.

[qwertz]

Urcite by fungoval, jasneze. Ja tam tu VPNku beztak mam, rekl jsem si ... schovam vse co nepotrebuji normalne venku do VPNky. Citim se o trochu bezpecneji, soukromeji. Alespon trosku :)

[miro]

Pokud zapnete tls-auth, tak to rozdíl je. To spíš mezi vpn s tls-auth a portknockingem není moc rozdíl (z útočníkova pohledu - v obou případech nevidí nic).

[xkucf03]

Rozdíl je v tom, že by se ve stejnou dobu musely sejít bezpečnostní chyby OpenVPN i OpenSSH a útočník by musel prolomit oboje najednou.

[MaT]

Takhle to skoro vypadá, jakoby SSH nepodporovalo autentizaci pomocí klíčů...

Dotaz na zkušenější: Dá mi SSH schované za OpenVPN něco navíc oproti SSH, na které se přihlašuji přímo, ale pomocí klíčů (tzn. autentizace hesly je zakázána)?

[qwertz]

da. Nebude videt z venku ze je ta sluzba otevrena a ceka na spojeni. Proto ta VPN. 50 na 50 ze se za VPNkou skryva SSH, kdezto 100procentni jistota v pripade ze se nalezne SSH a jeste k tomu kdyz je na standardnim portu 22, ktery je z venku otevren. Si myslim teda.

Premyslel jsem i nad tim portknockingem. Kde mam jistotu, ze portknocking nebude odposlechnut nekym na lince a nepouzit znovu pro odemceni pristupu k nejake sluzbe? Leda ze by se poradi portu na "zaklepani" menilo s kazdym novym prihlasenim podle nejake matematicke posloupnosti.

Kdyz mam vytvorene spojeni od sebe primo na server na port 22, muze to videt opet nekdo na lince, ze je to spojeni otevrene a timpadem vi, ze tam 22jka je otevrena. Pokud to schovam do VPNky pak tezko zjisti jaky provoz tam jde vzhledem k sifrovani. Leda podle cetnosti paketu, nebo nejake jine analyzy, ale kdyz tam bude mimo ssh (tukani do klavesnice) bezet i jiny datovy tok, tak uz je uplne v haji i s takovou detekci.

[miro]

Premyslel jsem i nad tim portknockingem. Kde mam jistotu, ze portknocking nebude odposlechnut nekym na lince a nepouzit znovu pro odemceni pristupu k nejake sluzbe?

Vyřešeno. Navíc, jak píšu výše, tohle se dá řešit pomocí tls-auth přímo v openVPN.

K výhodám bych ještě přiřadil, že VPN může jet přes UDP, což ztěžuje DOS. Nevýhodou naopak je, že když si člověk nechá expirovat serverový klíč, bude muset k mašině. Tohle chování možná lze nějakou volbou eliminovat, ale nevím, nestudoval jsem.

[xkucf03]

Nakonec do toho ani není potřeba zatahovat OpenVPN – můžeš schovat SSH za Stunnel a na klientovi používat ProxyCommand, pak je potřeba pro úspěšný útok prolomit TLS i SSH zároveň – ale přijde mi to trochu přehnané, ve většině případů by mělo stačit běžné SSH s přihlašováním pouze pomocí klíčů.

[xkucf03]

treba tak ze si ho omylem zafirewalluju a jsem ve stejne kasi

Tohle se dá řešit tak, že si dáš do at příkaz na reset původních pravidel (třeba po minutě) a kdyby to náhodou nevyšlo, vrátíš se k nim. (ale uznávám, že po bitvě je každý generál )

[qwertz]

no kdyby jste me nekdo slyseli jak jsem nadaval sam na sebe jak se mi ten stroj prestal ozyvat a nemohl jsem se nijak dostat na SSH.. ze jsem si ja vuuuul neshodil na tu chvili firewall, abych mel SSH docasne dostupne naprimo i bez VPNky kdyby nahodou neco ... fuuuu .. skoro bych si tehdy naliskal... Pak samozrejme prisly myslenky na to jak si vlastni system hacknout abych nemusel jet 12 km do serverovny a 12km zpet ve 2 rano (trebas pres server zakaznika, ktery ma na nas server taky VPN ale na jinem VPN subnetu a tam mam SSH projistotu zakazane i z VPN kdyby nahodou nejaky vtipalek od zakaznika zjistil ze tam skr VPN je dosazitelne SSH ... pfffff) .. mno .. stane se .. :D serverovna byla bohuzel nutnosti .. :D

[Ondrej 'SanTiago' Zajicek]

at prikaz je zbytecne slozity, staci na vedlejsim terminalu zadat 'sleep 60 && xxx', kde xxx je opravna akce (nebo treba reboot). A pokud vse funguje, tak ten prikaz vcas prerusit (^C).

[Jendа]

No, to bych radši pouštěl ve screenu nebo něčem podobném. Zejména při delších intervalech bych se bál, že se shell při přerušení spojení zavře i s procesem.