Vlákno názorů k článku
Výzkumníci opět varují před stále nedostatečně zabezpečenými SSH servery od mad - Tak primarne lze asi predpokladat, ze vetsina komercnich...

Tak primarne lze asi predpokladat, ze vetsina komercnich subjektu ma dnes moznost definovat seznam 3+ verejnych "pevnych" IP, ze kterych lze pristup na ssh sluzbu na externich serverech omezit. Cili nejdriv VPN s MFA ci jednorazovym heslem do firemni infrastruktury (extra dmz ?), pak ssh/rdp na nejaky interni k tomu urceny server(y), a teprve pak na servery v AWS nebo na verejnych IP (kdyz uz nemate do AWS VPN gw-gw). Funguje to vetsinou o dost lip, nez fail2ban.

V bezpecnem a auditovanem firemnim prostredi se snaze pristupy k externim serverum ridi a audituji.

Caste zmeny hesel uz dnes propaguje snad jenom NUKIB. Maj skluz tak 20 let, jedou CTRL+C && CTRL+V z cehokoliv, co se namane bez ohledu na stari a obsah, takze az budu (snad brzy) v duchodu, mozna si nekde konecne prectu clanek, ze prestali vynucovat 16 znaku jednou za 3 mesice, a na kazdy system jine.

Vlastne asi ne, protoze v ramci kazdorocniho "vylepsovani" do te doby budeme uz na 256 znacich jednou za 3 hodiny, abychom nasledne zjistitli, ze pulka systemu z toho stejne hashuje jen prvnich "x" znaku ...

I prumerne pitoma veverka dnes pouziva kratkou sekvenci znaku nekolikrat za sebou a meni obvykle jen 2 znaky (zacatek, konec) "hesla" ob 3 mesice. Je to tak v poradku, donutili jste je k tomu. (16-2 )/2 = 7, a to se rozhodne vyplati.

To, ze na Windows lze z powershell zjistit podobna (nedostatecne odlisna) hesla ruznych uzivatel v ramci stejne domeny (a co to vypovida o "security" funkcich pouzitych ve windows) zatim neresi NUKIB ani zadna jina banda zoufalcu.

SSH klice jsou sice fajn, ale videli jste nekde v realu nasazeny a funkcni system pro evidenci, identifikaci a audit verejnych ssh klicu ? Nejake "key repository" ? Neco jako centralizovana distribuce ssh klicu splnujici pozadavky AAA ?

Moje zkusenost je, ze pokud za klic pridam komentar typu "backup@nemazat" prezije snad i atomovy vybuch.

Generatory OTP - aktualne mam v mobilu 3 ruzne, k tomu dalsich "x" via SMS, a uz asi 5x jsem zazil situaci, ze kvuli rozbitemu OTP na nejake gateway nebylo mozne se k nejakemu systemu prihlasit (kdyz to bylo opravdu potreba). Je to sice fajn, ale vetsinou to vyzaduje i nejaka "zadni vratka", na ktere se pak obcas bohuzel zapomina.

Od zacatku v IT predpokladame, ze jedine co ma smysl pro zvyseni bezpecnosti je skoleni uzivatel, ale do toho jde naproste minimum financi (a ze strany zamestnavatelu i koncovych uzivatel to vzbuzuje asi nejvetsi odpor). Tak je alespon sikanujeme dlouhymi hesly. To je k ucasti na (temer neexistujicich) skolenich o bezpecnosti rozhodne povzbudi.

ad. > Od zacatku v IT predpokladame, ze jedine co ma smysl pro zvyseni bezpecnosti je skoleni uzivatel,

No a to je pěkně prosím obrovská hloupost.Školený uživatel je výborný k tomu, když chcete vykázat relativně levnou činnost (otravovat lidi odklikáním nějakého nesmyslu na intranetu), případně hodit na někoho chybně navržený bezpečnostní model.
Ano, je pravdou, že vyškolený uživatel je důležitý pro snížení rizik. Ale rozhodně to není a nesmí být hlavní/jediný díl bezpečnosti. Výmluva "ale von na to kliknul" když útok vyřadí celou firmu je poněkud trapný, už proto, že s časem pravděpodobnost čistě kliknutí omylem/z nepozornosti roste nezadržitelně k jedné, i když jsou lidi perfektně vyškolení.

Ostatně můžeme se podívat na jakékoli opravdu kritické systémy - ŘLP, jaderné reaktory, ...
Zaměstnanci jsou perfektně vyškoleni, ale stejně jsou systémy designovány tak, aby selhání jednotlivce nevedlo ke katastrofě.

"ale stejně jsou systémy designovány tak, aby selhání jednotlivce nevedlo ke katastrofě"

Mno ... nejsou. U tech elektraren je jeste jakoz takoz reseno to, ze kdyz se podela pocitac, da se otocit ventilem, ale u toho rizeni ... kdyz ridici rekne klesat, pilot zacne klesat ... ostatne (nejen)proto je tu uz par let snaha lidi eliminovat.

Je rozdíl mezi nechtěným selháním a úmyslem. V letecké dopravě jedna neúmyslná chyba ke katastrofě nevede, dá se napravit.

Jinak v letecké dopravě platí, že rozhoduje pilot. Takže pokud řídící řekne klesat, ale palubní systémy budou pilotovi hlásit, že je moc nízko, tak klesat nebude. Podobně pokud TCAS hlásí nebezpečí kolize s jiným letadlem, má se pilot řídit tím a ne pokyny řídícího – což bohužel zpočátku nebylo úplně jasné.

Koukam ze nam tu prisel odbornik na leteckou dopravu vysvetlit, jak tomu vubec nerozumi. Pilot nema prehled o provozu kolem, takze se pokynem ridiciho ridit musi. A protoze narozdil od Mr Jirsaka vi, ze na ten manevr muze mit sotva jednotky sekund, tak ho neprodlene udela. Pokud by se pokyny neridil, tak v extremnim pripade muze byt letadlo, jak Mr Jirsak netusi, i sestreleno.

Propracovaný evidenční systém na přístupy pomocí SSH provozuje třeba Facebook, ale řeší si to přes SSH certifikační autoritu a vystavuje krátkodobé klíče.
Doporučuji čtení knihy SSH Mastery Michaela W Lucase. Dává slušné postřehy, jak SSH používat v celé řadě situací.

Na OTP zkuste FreeOTP+. Není to na úplně všechno, protože různé banky a spořitelny mají názor, že ví všechno nejlíp, ale na spoustu věcí to stačí.

Správu klíčů pro SSH (krátkodobé klíče) umí mimo jiné i Hashicorp Vault.

Banky a spořitelny totiž nepotřebují jednorázové heslo, ony potřebují podpis transakce. Tj. typicky něco, co se změní, když změníte číslo cílového účtu nebo částku. Kdyby banky používaly jednorázové heslo pro potvrzení bankovního převodu, útočník vám pod rukama změnil číslo účtu a částku, vy byste to potvrdil jednorázovým heslem a to heslo by sedělo i na podvržené údaje, bylo by to k ničemu.