Vlákno názorů k článku Útoky na SSH: je ještě bezpečné? od rootless rooter - v clanku sa pise, ze "...ale obecně TLS...
-
rootless rooter (neregistrovaný)
v clanku sa pise, ze "...ale obecně TLS – potenciálně ohroženy jsou tedy i další protokoly jako HTTPS nebo VPN..."
VPN nie je protokol ani nahodou.
autor mal zrejme na mysli rodinu protokolov okolo TLS/SSL, nad ktorym je mozne vybudovat VPN [OpenVPN napriklad pouziva TLS protokol].
-
Nikita Bretschneider (neregistrovaný)
Souhlasím. Navíc, těch problémů vidím v článku víc. Může kupříkladu někdo hloupé slečně vysvětlit, co je špatně na protokolu telnet? Špatně to začne být imho až v momentě, kdy tím protokolem přenesete něco, co by nemělo být zveřejněno (například heslo). PROČ mi článek podsouvá, že služby typu telnet://horizons.jpl.nasa.gov:6775 jsou bezpečnostní průšvih? Já totiž nechápu V ČEM je použití telnetu zrovna v tomto konkrétním případě špatně a měla bych se mu vyhnout. Dtto platí i pro ftp a v podstatě i pro http, jenže o http se už autor v článku nezmiňuje a dobře ví proč. Imho autor trpí fixní ideou, že telnet se používá pouze na vzdálenou správu serveru, na což je obvykle poněkud nevhodný. Jiná použití mu uchází. A s ftp je to patrně nějak podobně, asi v životě neviděl věci jako ftp.funet.fi . A pak je otázkou jakými dalšími fixními ideami trpí a jak moc brát článek vážně.
Připouštím, že jsem dnes zvláště jizlivá, nicméně prohlášení typu "určitě znáte \(.*) ale doufám, že \1 nepoužíváte" mám až příliš spojené vymývači mozků na mlm akcích a jsem na to poměrně dost háklivá.
-
rootless.rooter (neregistrovaný)
k tomu telnetu:
nebolo to az tak davno, co sa dala zneuzit chyba v SunOS 5.10 a 5.11, ktora zneuzivala telnet [respektive bug v jeho daemonovi]utocnikovi stacilo malo: prikazom 'telnet -l "-froot" a.b.c.d ' ziskal neopravneny root na cielovom systeme. o nebezpeci protokolu, ktory prenasa udaje nesifrovane sa vazne nema cenu bavit - pouzit rsh/rlogin/telnet na prihlasenie ku kritickym systemom [switch,router,firewall] moze len naprosty ignorant.
-
j (neregistrovaný)
Takze kdyz se sifrovane prihlasis na ssh, tak bug v jeho demonovi zneuzit nemuzes? Bych rek, ze to stim jaksi vubec nesouvisi. Nesifrovany sluzby proste maji svy misto. Spoustu veci sifrovat nema smysl. U spousty dalsich je to dokonce proti smyslu tech sluzeb samotnych.
Vem si, ze chci provozovat verejnou sit, ale bez klice se do ni nepripojis ... a klic neziskas bez pripojeni do site ...
-
Petr M (neregistrovaný)
Když je bug v nešifrovaným, odposlechneš si heslo, přihlásíš se a eskaluješ práva.
Když je bug v šifrovaným, musíš po odposlechnutí napřed heslo dešifrovat a až pak můžeš eskalovat práva,
Takže pro útočníka bez hesla je SSH větší oříšek, než Telnet. Cizinec bez hesla je taky větší nebezpečí pro systém, než např. zaměstnanec, u kterýho je ověřená identita před tím, než mu IT vygeneruje klíče.
-
Obecně všechny nešifrované protokoly, které neautentizují server klientovi (a naopak) a přenášejí data nešifrovaným plaintextem bez robustní kontroly integrity přenášených dat jsou potenciálně nebezpečné. Včetně http, telnetu a dalších. Ne vždycky a pro každého ale pro někoho ano.
Nikdy nevíš jakým způsobem bude kdo kterou službu používat a jestli ji třeba pak někdo nemůže použít ke sbírání informací, exploitování klienta, atd.
BTW: Dočkáme se zabezpečeného přístupu na root.cz nebo až v příštím století?
-
Co je na tom spatneho a nebezpeneho? Zeptej se soudruhu v Samsungu treba...
http://www.root.cz/zpravicky/telefony-samsung-jsou-ohrozeny-bezpecnostni-dirou/ -
Ondra Satai NekolaZlatý podporovatelZrovna tohle jde resit i podepisovanim. (Cimz nerikam, ze https je pro tenhle ucel spatny napad, zrovna pro tohle je idealni mit oboji.)
-
Ondra Satai NekolaZlatý podporovatel
Dobra poznamka. Opravuji "je idealni mit oboji" na "je potreba mit oboji".
-
Co když mu vnutím nějakou verzi s vyšší revizí z nějaké staging distribuce, která ještě neprošla testováním do stabilní distribuce a je v ní ještě větší bota než kterou zalepuje? Nebo mu u složitějšího fixu zabráním nainstalovat jeden z X balíčků a záplata tak nebude fungovat a otevře ještě neco jiného? Nebo si počkám až bude nějaká díra v apt nebo nějakém xml parseru (tzn. průměrně stačí počkat týden) a pak si vyrobím balíček co to využije a vložím ho do session? Tím pádem mám rovnou remote root exploit.
Zkrátka možností jak mitm útočník může využít to, že nezabezpečený ftp/http je mnoho.
To že Linuxové distribuce včetně třeba Debianu tolerují http v tak kritické oblasti jako je distribuce bezpečnostních záplat nebezpečné protokoly pokládám za hru s otevřeným ohněm.
Jak Apple tak Microsoft používají bez výjimky SSL.
-
Karel (neregistrovaný)
Tak to už na Mars létáme. Aneb nepleťte si mitm a narušení komunikace. Mitm je opravdu spíše tím výletem do Podolí, byť značná část výletníků odmítne nastoupit, protože "tohle není Jim Beam". Nezanedbatelné množství uživatelů ale divnou barvu ikonky neřeší a klidně vleze na podvržený server a v pohodě surfuje "po https, takže bezpečně".
-
Útočník ví co si stahuješ a leakuješ plno informací. V případě problémů se zabezpečením podpisu balíčků, uniklému klíči k repozitáři nebo chybě v apt má nástupní pole k exploitu (zvlášť když si balíčky stahuješ pravidelně v cronu).
Pak ti třeba může zavírat spojení s aktualizacema a vynutit si chybu v přenosu. Nebo ti třeba do session podstrčí tříterový balíček bashe a nechá ti přetýct kapacitu /var než ho odmítneš až když si spočítáš hash.
I když vím, že řada distribucí to má dělané blbě.
Neexistuje služba, která by nemohla benefitovat z end-end bezpečnosti. Používání zabezpečené komunikace po síti je malá násobilka každé architektury bezpečnosti.
-
Petr M (neregistrovaný)
No... Představ si vytahování adres klientů z cizího e-shopu z linuxovýho web serveru. Někdo se naboří do systému a prvně si ho musí očuchat. Co je tam za CMS (to většinou ještě před proniknutím do systému), verzi PHP, web server, databázi,.. To mu sebere nějaký čas a záznamy v logu, navíc to vyžaduje víc znalostí.
Odposlechnutím, že server stahuje jako update PHP verze X, Apache verze Y a MariaSQL verze Z + verzi CMS, ve které zná zatím neopravenou díru, mu ušetří docela dost práce a jde na jisto...
Takže i tady má šifrování smysl. Neodstraní chyby, neovlivní možnost podvrhnutí podepsaných balíčků, ale háže útočníkům klacky pod nohy. V podstatě ty informace o stahování získá jenom provozovatel serveru, ze kterýho se tahají aktualizace (tj. musí mirrorovat distro a musí mít nejlepší spojení). Tím s docela redukuje množství lidí, kteří to mají s útokem snažší.
-
Zatimco za http:// vetsinou stoji komunitou dlouho ladeny a patchovany indian, za telnetem to bude spis nejaka domaci tvorba.
Jasne, muzu si vymyslet i relevantni pripad, kdy mi vubec nevadi, kdyz se na server nekdo prihlasi a voila - uz mam dalsi protipriklad. Autor je proste v nejakem kontextu...netreba se durdit... -
Na telnetu je blby, kdyz ho pouzivate treba pres nezabezpecnou wifi. Neni vubec problem sedet kousek pobliz a videt, co na svem pocitaci v telnetu pisete nebo delate neco jineho.
Ti lepsi dokonce umi do vasi seance podstrcit informaci at uz smerem od vas, nebo k vam, takze vy treba ziskate falesne informace a to muze byt drahe
Neomezuje se to ale jen na wifi, pevne site lze timto zpusobem taky monitorovat, je to sice tezsi, ale da se. Zalezi na vynosu, ktery to utocnikovy prinese.
Proto ja vsude pouzivam SSH a dokonce na vzdalene stroje, ktere poskytuji neverejne sluzby pouzivam tunelovani pres SSH, nez abych jim oteviral verejny port.
