Názory k článku
Malware SSH-Snake hledá klíče k SSH a pak se šíří po síti

Nevim, nikdy jsem to nepochopil.

Ted si predtavte, kdyby banka "schovala" internetove bankovnictvi treba na https://internetbanking.cz:12345/, to by bylo najednou bezpeci, tam by to zadny utocnik nehledal :-D

No a protoze to nikdo nedela, asi logicky nema smysl schovavat ani jine sluzby na jine porty.

Jasne, to dava smysl. Take mam jednu OpenVPN na TCP443 presne kvuli tomu samemu.

Ale podle me nedava smysl dat SSH na jiny port. Kdyz uz, tak ho cele schovat za VPN.
Ale cemu pomuze jiny port? Zrovna OpenSSH jsem vzdy povazoval za dost bezpecny software.

No kdyz jsem na VPS posunul ssh z 22, tak se snizila ilegalni fekvence dotazu na ssh sluzbu o 95%

Chapu ze to neni " bezpecnsot" posunout... ale prekvapilo men jak moc to droplo dolu... takze fail2ban toho uz nemusi zrat tolik. Takze jen posunuti muze pomoct zbavit se velke casti robotu. Ve vnitrni siti jsem nevidel ze by ssh bylo jinde nez na 22

A co logy web serveru? Tam taky u stranek s http basic auth vidim spousty pokusu o prihlaseni.

Ten neprovozuji, ale predpokaldam ze pokud se adminsitrace zakaze z internetu tak ten problem odpadne :)

Pokud je vaším cílem připojit se na SSH, tak zrovna takovou činnost dělat skrz VPN založenou na TCP je velmi špatný nápad.

V praxi je TCP v TCP na ad-hoc věci poměrně v pohodě. Nedělal bych pomocí toho nějakou site2site VPN nebo nepřipojoval hromadně zaměstnance na home office atd. ale moje zkušenost je, že je to až překvapivě použitelné.

Pokud přes něj neběží nic datově náročnějšího než přístup k terminálu, je to úplně ale úplně jedno. A, upřímně, ono je to jedno i ve většině ostatních případů užití. Z praxe.

No, spatny napad to mozna je - ale dnesni komercni (korporatni) VPN produkty jsou vesmes nejakym derivatem SSL VPN nad TCP, uz driv treba byly i proprietarni implementace IPSECu nad TCP. A zrovna specificky u te odkazovane OpenVPN je problem spis to, ze spousta veci se honi z user-space. Ano, uz je tu moznost kerneloveho offloadu, ale neni uplne rozsirena.

Dobrý nápad to možná není, ale někdy nemáte na vybranou - jsou situace, kdy UPD neprojde. Takto kolega ve špitále zjistil, že je bez šance, tak jsem mu udělal OpenVPN na TCP a to mu prošlo.
A když je nešťastník v ještě ořezanějším prostředí, skončíte s VPN na portu 443.
Tak si můžete vybrat: použít ne dobrý nápad nebo nemít přístup vůbec.

Dobrý nápad to možná není, ale někdy nemáte na vybranou

A o to právě jde: když nemáte jinou možnost, tak se holt nedá nic dělat - a právě proto ta možnost vůbec existuje. Viděl jsem ale dost nasazení, kde používali TCP v TCP čistě z neznalosti, aniž by k tomu byli nuceni. Dokonce jsem zažil i admina, který měl na jakékoli problémy s openvpn univerzální odpověď: "Tak zkuste přepnout na TCP."

Pokud má někdo skvělou konektivitu s (prakticky) nulovou ztrátovostí a nízkými a stabilními latencemi, tak to opravdu může působit dojmem, že "to pro normální použití v pohodě funguje a není s tím žádný problém". Ale stačí ztrátovost na úrovni jednotek procent nebo trochu víc kolísající latence (tedy "v terénu" nijak výjimečný stav) a výsledek je naprostá katastrofa.

Ne, utocnika to k nicemu nenuti... ty data si muze vytahnout ze sluzeb typu Shodan (a nikoliv jen ten), ktere vam rovnou i napraskaji i to, ze to SSH mate na nestandardnim portu... takze jsme u silenosti jmenem security through obscurity ;-)

Jasne ze muze pouzit shoda atp., ale praxe uakzuje, ze to tak uplne neni.
Nevsiml jsem si ze by nekdo tvrdil ze to je security reseni, jen to odfiltruje roboticke testy. A to o cca 90%

Coz podle mne, jasne ukazuje ze utocnik si to cislo protu muze zjistit jinak a provadet normalne utok na sluzbu i na jinem portu, al e v praxi se to tak vlastne moc nedeje.... posle se robot projede 21,22,23,3389­,3306,80,433 atp a pokud tam nic neni tak nazdar, naslednej, ci cilenej, sken ocividne probiha jen u cca 10%

Pokud si mne nekdo vybere jako cil, je jedno kde ta sluzba lezi, ale provedeni posuniti naprihlad ssh z 22 jinam, nemusi bejt uplne blbej napad.

jen to odfiltruje roboticke testy. A to o cca 90%

...což ale pořád neodpovídá na základní otázku, k čemu má ta věc být vlastně dobrá. Buď mají ty "robotické testy" nějakou šanci na úpěch, a pak i těch zbylých 10 procent stačí k tomu, abych měl průšvih, nebo ji nemají, a pak je to odfiltrování zbytečné. Možná tak pro dobrý pocit, jak jsem na ně vyzrál. Pak by bylo ale férovější to přiznat a nepředstírat, že je to opatření, ktreré něčemu objektivně pomáhá. :-)

"Buď mají ty "robotické testy" nějakou šanci na úpěch, a pak i těch zbylých 10 procent stačí k tomu, abych měl průšvih, nebo ji nemají, a pak je to odfiltrování zbytečné"

Mne to zbytecne nepridje, prestoze ty dotazy nemaj sanci na uspech neznamena ze to tam negeneruje trafik, a logy...

Mne to zbytecne nepridje, prestoze ty dotazy nemaj sanci na uspech neznamena ze to tam negeneruje trafik, a logy...

A čemu konkrétně to vadí? Ten "trafik" je naprosto zanedbatelný v porovnání s běžným objemem komunikace jakéhokoli trochu používaného serveru a pár řádků v logu (obrazně řečeno, opět zanedbatelné plivnutí do moře v celkovém objemu logů) mne taky netrápí.

Nemluvě o tom, že i kdyby typický útočník vyzkoušel jen těch sedm portů vyjmenovaných výše, nebude vygenerovaný "trafik" o moc menší, než kdyby se trefil rovnou na portu 22. A když bude scanovat podstatnou část rozsahu, bude dokonce mnohem větší.