Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Organizace Apache Software Foundation (ASF) vydala verzi 22 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Společnost AMD na veletrhu Computex 2024 představila (YouTube) mimo jiné nové série procesorů pro desktopy AMD Ryzen 9000 a notebooky AMD Ryzen AI 300.
OpenCV (Open Source Computer Vision, Wikipedie), tj. open source multiplatformní knihovna pro zpracování obrazu a počítačové vidění, byla vydána ve verzi 4.10.0 . Přehled novinek v ChangeLogu. Vypíchnout lze Wayland backend pro Linux.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
adduser --non-unique --uid 0 root2
prihlasovani proimo na roota povazuji za nedobre a melo by byt zakazano
Proč? Předem upozorňuji, že pseudoargument "protože se to říká" resp. "psali to v příručce" neberu.
Zrovna tyto dva argumenty bych nechal spát někde hluboko v houští a vůbec bych je nevytahoval na světlo... Platí, že "jednou root, vždycky root". Pokud někdo rootový přístup na mašinu měl, lze mu jej bezpečně odebrat pouze kompletní přeinstalací celého stroje. Nic takového jako "dočasný" root prostě neexistuje.
Tohle povyprávěj ve firmě, kde měl správce na starosti 150 serverů, kde většina je vprovozu nonstop...
tudiz neni problem aby kazdy znal jen jedno heslo k prave jednomu uctu rootX - takze ani nezna jedno heslo vic lidi, ani neni problem kdyz ten clovek odejde protoze se proste zablokuje rootY
Tak to zase tak úplně ne. Pokud někdo má přístup do systému "na roota" (tedy UID=0), není pro něj moc velký problém se dostat k heslům ostatních "rootů", a to i bez crackování /etc/shadow. Stačí třeba nechat si to heslo odposlechnout, až se druhý bude přihlašovat.
28.10.2007 17:07
sudo něco řeší.
'PermitRootLogin yes'?co je na tom spatneho? to mam na vsech svych serverech.
Protocol 2,1', ale ani ta není nebezpečná sama o sobě, ale jen v případě, že byste byl tak nerozumný, že byste SSH verze 1 opravdu použil. Asi tak jako není a priori chybou mít spuštěný telnet server (za předpokladu, že v něm není díra), ale hrubou chybou by bylo ho používat.
To je marné. Vy prostě odmítáte vnímat, co píšu, a zarputile reagujete na něco, co jste si sám vymyslel a mně to jen podsouváte.
pripada mi to ako keby si teraz hovoril nieco taketo: za predpokaldu, ze ma nikdo nehackne, nemusim rootovi davat ziadne heslo cize sa mi ulahci prihlasovanie
To není tak úplně pravda. Činnost, kdy se někdo zkusí přihlásit pod uživatelem root a nebude ani dotázán na heslo, bych asi slovem "hackne" neoznačil. Ale pokud by ta věta začínala třeba "za předpokladu, že se na můj počítač nikdo cizí nepřihlásí", tak se vám pod takové tvrzení milerád podepíšu. Zkusím hádat: vy jste asi žádné základy matematické logiky neabsolvoval, že?
mam za sebou maticky gympel a momentalne studujem 3. rok na matfyze
Pak byste ovšem měl vědět, co je to implikace a že pokud napíšu "z A plyne B", neříkám tím zhola nic o tom, zda platí jednotlivé výroky A a B.
mimochodom, neviem co ma matematika s informacnou bezpecnostou
Právě tady asi bude ta základní chyba. Protože zabezpečit systém znamená především informace vyhodnocovat a analyzovat. A v tom se bez logiky neobejdete. Nemluvě o tom, že veškerá kryptografie je samozřejmě jen aplikovaná matematika.
chyba je v tom, ze sa na bezpecnost snazis aplikovat principy matematickej logiky
To ale není chyba. Chyba je, že vy to neděláte a řídíte se prvním dojmem místo toho, abyste problém analyzoval do hloubky.
cryptografia je samostatna veda, nezaobera sa zabezpecovanim ale utajovanim
S tím slovem "utajování" by se dalo polemizovat, ale budiž. Hlavně si ale povšimněte, jak velká část bezpečení problematiky je postavena právě na aplikacích této vědy?
if (false and true) then doIt. Vy ho vylepšíte tak, že odstraníte předpoklad, který nelze splnit: if (true) then doIt. Myslíte si, že program dělá stále to samé?
Logické uvažování Michala Kubečka je v tomto případě zcela bezchybné, zatímco s vaším byste nedostudoval žádnou střední školu, kde se vyučuje matematika. Má vůbec smysl s vámi dále diskutovat?
ssh démon, který zapomíná ověřit heslo“, odeslat ji do říše pohádek a můžeme začít znova dumat nad tím, před čím vlastně ten váš druhý stupeň ochrany v reálu chrání.
připustil existencí telnet serveru, ve kterém stoprocentně, ale stoooooprocentně není bezpečnostní chyba
A kde to konkrétně bylo, smím-li se zeptat?
případně napsat vlastní opravdu neprůstřelný telnet, a ten nepoužívat, což by byla rovněž chybná bezpečnostní strategieProč? Navíc opravdu si myslíte, že někdo bude pracně shánět neprůstřelný telnet, nebo jej dokonce sám programovat, s myšlenkou na to, že jej pak nikdy nepoužije?
sshd.
Myšleno tak, že pro dva identické stroje, které se liší jen v tom, že na jednom běží telnetd, zatímco na druhém sshd bude ten druhý úspěšně napaden s větší pravděpodobností?
Přesně tak. Samozřejmě se teď bavím pouze o otázce zneužití bezpečnostní díry v démonovi samotném, ne o případě, že by se ten telnet aktivně používal ke vzdálenému přihlášení.
Ale je zde opět ta možnost, že 10 hekrů jen tupě nasadí sniffer, (protože co taky na někoho kdo v dnešní době (asi) používá telnet) a bude odposlouchávat ten telnet, až se pan root někdy konečně přihlásí
Opět stejný problém jako předtím: nereagujete na to, co jsem napsal, ale na to, co si představujete, že jsem napsal. Já jsem mluvil o bezpečnosti démona jako takového, ne o zabezpečení protokolu.
a jedenáctý se tam přes ten telnet na toho roota bruteforce dostane
1. Je potřeba si konečně ujasnit, jak to s tím útokem hrubou silou je. Budu-li počítat relativně rychlý (ale snadno dostupný) stroj a náhodné heslo o délce 8 znaků nad abecedou 62 znaků, bude střední doba jeho uhodnutí hrubou silou při znalosti hashe (tedy velmi silný předpoklad) tři a půl roku pro DES (který už skoro nikdo nepoužívá), 400 let pro MD5 (nejobvyklejší) a 9478 pro Blowfish (default v mé distribuci). Jinak řečeno, pokud má root takové heslo, že má smysl se reálně zabývat možností, že jeho heslo uhodne někdo zvenku pouhým zkoušením možností, znamená to, že správce je diletant a o bezpečnosti je škoda ztrácet řeč.
2. Myslíte si, že ten, kdo bude provádět útok hrubou silou, se bude obtěžovat s ověřováním veřejného klíče serveru? A podle čeho vlastně? Že vám nejdřív slušně napíše "Chtěl bych se lámat na váš server, můžete mi, prosím, poslat jeho veřejný klíč?" Asi ne… Pak je sice pořád výrazně těžší sledovat SSH komunikaci než telnet, ale v principu komunikaci útočníka se serverem musíte považovat za nechráněnou.
Pokud je ten rozdíl jako rozdíl mezi 90 tisíci a 900 tisíci lety, pak to je z hlediska životnosti stroje rozdíl zanedbatelný tedy žádný. Pokud přešalftováváte do těchto vod, můžeme se tedy začít bavit o tom, jak je to s těmi dvěma vrstvami?
Pořád stejně: vy nabízíte zbytečnou komplikaci, která nic užitečného nepřinese. A já se vám snažím od začátku vysvětlit, že pokud už byste cítil potřebu bezpečnost proti útoku hrubou silou zvyšovat, můžete to udělat s mnohem menší námahou a mnohem lepším výsledkem. Jestli to potřeba není (což většinou není), tím spíš není důvod si přidělávat práci s dvoustupňovým přihlašováním.
Protože však předpoklad bezchybnosti software nebývá v praxi splněn, tak nelze tvrdit, že spuštění daemona telnetu na serveru je bezpečné. V tom se pravděpodobně s Michalem Kubečkem shodnu.Ušetřili bychom si zbytečně strávený čas.
Jasně že JE bezpečnostní chybou mít povolené SSH v1 :D Pan Kubeček sice to riziko nevidí, jemu totiž stačí, že ON ho nebude používat. Ale už neuvažuje o možnosti, že se mu tam přes něj někdo nabourá
A jak to udělá? SSH protokol verze 1 je nebezpečný pouze tím, že je kryptograficky slabý, takže útočník může analýzou komunikace získat citlivé údaje. Jenže když žádná komunikace neproběhne, nemá co získat. Právě proto jsem to přirovnával k telnetu - v okamžiku, kdy ho nepoužiju, problém se snadností odposlechu komunikace se nemá kde projevit.
Popisoval jsem takový myšlenkový veletoč, že se do systému úspěšně nabourá nějaká lama, která nic zlého neprovede, a tu bude shodou okolností sniffovat někdo jiný, který to tam pak provětrá :) To bylo jen v rámci těch "myšlenkových experimentů", jak je tu někdo popisoval a který jste vy uvedl. (Poukázal jsem na jeho slabinu.) Za této situace opravdu nelze říct, že povolení ssh v1 nebylo v dusledku chybou, protože kdyby šlo vše podle stejného scénáře ale v ssh v2, tak by se to takto odposlechnout nedalo.
A já jsem vám u toho příspěvku v té úvaze nalezl hned dvě velmi problematická místa.
Osobně tam sice většinou mám without-password, ale ani na yes nevidím nic principiálně špatného. Vynucováním dvoustupňového přihlašování bezpečnost nezvýšíte.
Zkuste se např. zamyslet nad tím, jak ztížíte útočníkovi útok hrubou silou tím, že místo jednoho hesla bude muset (postupně) louskat dvě (stejně složitá). Časová náročnost vzroste na dvojnásobek. A co když bude muset louskat jen jedno heslo, ale bude o pouhý jeden znak delší? Časová náročnost vzroste tolikrát, kolik znaků má abeceda, nad kterou to heslo generujete, tedy typicky 62-krát (malá a velká písmena a číslice) nebo aspoň 36-krát (malá písmena a číslice), i v tom nejhorším myslitelném případě 26-krát (pouze malá písmena). To jen tak pro ilustraci…
Samozřejmě. Zkusím to napsat ještě víc názorně: mám systém, kde má normální uživatel i root (třeba) osm znaků dlouhé heslo. Zvažuji dvě možnosti, jak zvýšit odolnost proti útoku hrubou silou:
Druhá možnost mi nabídne podstatně menší zvýšení bezpečnosti při větších komplikacích pro mne. Proto samozřejmě zvolím tu první.
A pokud byste chtěl tvrdit, že nejlepší by bylo prodloužit hesla i vynutit dvoustupňové přihlašování, tak ani to není pravda - místo toho raději ta hesla prodloužím na 10 znaků a opět dostanu "více muziky za méně peněz".
Protože mám jakýsi výchozí stav a dvě možnosti, jak ho změnit. A ty porovnávám.
Nebo jinak: kdykoli vy vymyslíte variantu s dvoustupňovým přihlašováním a hesly délky n, já vám nabídnu jako alternativu jednoduché přihlašování a délku n+1. Moje alternativa bude pohodlnější pro správce a těžší na prolomení pro útočníka. Takže netuším, proč trváte na řešení, které funguje na principu "cesta byla delší, zato však méně pohodlná".
uvazujme modelovou situaci kdy mame pristupny pocitac, na nem dva ucty:
30.10.2007 14:50
su a tak. Takže ve vašem moduelu se s pouhou znalostí hesla roota na roota může přihlásit každý Číňan, ktežto v konkurenčním modelu jen privilegovalý uživatel toho stroje (vy).
1. Pořád zanedbáváte, že mezi "pouhá znalost hesla roota" a "znalost hesla normálního účtu a hesla roota" je jen velmi malý rozdíl, zcela zanedbatelný proti efektu elementárního posílení síly hesla.
2. Tvrdošíjně ignorujete vysvětlení, že omezení na "privilegovaného uživatele" je faktorem naprosto zanedbatelným v porovnání s elementárním posílením bezpečnosti hesla. I kdyby musel útočník prolomit těch hesel postupně prolomit deset, pořád to bude pro něj výrazně menší komplikace než pouhopouhé prodloužení hesla o jeden znak.
3. A konečně zapomínáte, že u vzdáleného přihlašování nemusím autentizaci heslem povolit vůbec a proti náročnosti prolomení 1024-bitového klíče jsou vaše opatření už naprosto bezpředmětná.
S ohledem na to, že bod 3 jste až dosud označoval za řešení velmi namáhavé s relativně nízkým efektem
Vážně? Kdy a kde to bylo?
Přemýšlel jste někdy nad možností, že poté, co kterýkoliv uživatel na daném stroji zjistí heslo na roota, může tam cokoliv spáchat zcela anonymně? Případně si ani nevšimnete, že jste to "nebyl vy"? A může to udělat i lama, které by po sobě neuměla "uklidit".
Za prvé: "který zjistí heslo na roota" je velmi silný požadavek. Za druhé: nevysvětlil jste nám, v čem je vámi navrhovaný model lepší - tam totiž platí přesně totéž. Pokud byste chtěl problém opravdu řešit, musel byste nasadit něco na způsob LIDS nebo SELinux, ne jen "schovat roota" a doufat, že to bude stačit. Nebude.
Takže vy dáváte všem uživatelům (i sekretářce kdyby byla schopna vám přes rameno vočíhnout heslo) do rukou jednoduchý nástroj -- anonymní správu serveru, a nepřipadá vám to jako snížení bezpečnosti?
Čím, mohu-li se zeptat? Myslíte si snad, že heslo roota rozdávám na potkání každému, kdo si o něj řekne? Co se odpozorování hesla týká, váš přístup opět nic neřeší - když budete tak nepozorný, že si necháte heslo odpozorovat, jste na tom úplně stejně.
kubecek@ nepřihlašujou, takže to pomůže rozeznat náhodný hack od těch "závažnějších", což může být docela důležité.
Za až tak silný požadavek to nepovažuji, zrovna to "odpozorování" je snadná záležitost.
Získání hesla uživatele root je velmi silný požadavek. A pokud snad u někoho není, měl by se v první řadě zabývat tím, proč není a jak zajistit, aby byl. To by bylo daleko přínosnější než vymýšlet opatření typu, že kromě zadání hesla je potřeba (obrazně) stát na levé noze a držet mezi palcem a malíčkem lalůček pravého ucha. Ale to jsme zase zpátky u toho, že bezpečnost je v první řadě otázkou stanovení priorit a že je lépe posílit slabé místo, než za něj vložit ještě jednu ochranu stejně pochybné kvality.
V dalších odstavcích opět předpokládáte, že záškodník, který se vám nabourá do systému, vám nechá nedotčené logy, ve kterých si snadno najdete, kdo to byl a co dělal. Takový předpoklad považuji za naprosto neoprávněný, kdybych se někomu lámal do systému, jedna z prvních věcí, které bych pak udělal, by byla právě likvidace jakýchkoli záznamů, které by mu umožnily zjistit, jak jsem se tam dostal a co jsem tam dělal (nejlépe i to, že jsem se tam vůbec dostal). Vy snad ne?
Já prostě odmítám zabezpečení stavět na předpokladu, že útočník bude hloupý a bude dělat chyby. Proto počítám s útočníkem, který je schopný a cílevědomý. Jsem přesvědčen, že bude-li zabezpečení odolné proti němu, bude přinejmenším stejně odolné i proti těm neschopným a náhodným.
Můj přístup je ten, že pokud se mi někdo do systému dostane na roota (jakýmkoli způsobem), tak jsem při standardním bezpečnostním modelu prostě prohrál a nezbývá mi než systém nainstalovat znovu. To, jestli v případě, že útočník bude nepořádný nebo neschopný, bude určitá šance, že mi nechá v logu nějaké zajímavé informace, už není rozdíl, který by byl natolik zajímavý, abych kvůli němu blokoval přímé přihlášení na roota. Pokud už se rozhodnu řešit situaci, kdy se mi někdo do systému pod rootem nabourá, pak ji budu řešit pomocí nástrojů, které skutečně z bezpečnostního hlediska něco podstatného přinášejí (LIDS, SELinux), ne jen zbožného přání, že po sobě dostatečně neuklidí.
Vy pak ještě několikrát, protože pachatel pro vás zůstane stále neznámý a tedy aktivní a neeliminován :Dtak toto ma byt vtip? (smajlik tam sice je, ale radsi se ptam)
a nevidíte problém v méně schopném potenciálním pachateli třeba ve firmě
Mně ovšem připadá bezpečnější i u vnitřního útočníka předpokládat spíše schopnost než neschopnost.
Jenže vy stavíte zeď proti schopnému útočníkovi (o znak delší heslo:) a podceňujete až ignorujete ty méně technicky schopné
Podle mne schopný útočník může udělat cokoli, co může udělat neschopný. Obráceně to ale samozřejmě neplatí, proto mi připadá vhodnější orientovat se na schopné. Proto také nepoužívám techniky, které fungují jen za předpokladu, že "útočník nezkusí", "útočníka nenapadne", "útočník zapomene" atd. Když budu počítat s tím, že útočník zkusí, napadne ho a nezapomene, a ono to bude naopak, tím lépe pro mne.
Takže lepší je model můj a umožní mi s nezanedbatelnou pravděpodobností pachatele odhalit.
Jednak nesouhlasím s předpokladem, že je ta pravděpodobnost nezanedbatelná, jednak nesouhlasím s vaším sebevědomím, že pachatele odhalíte nebo dokonce eliminujete. Když budete mít hodně velké štěstí, zjistíte IP adresu stroje někde v Zimbabwe, z něhož se vám tam útočník dostal. Jestli zjistíte, kde byla na na vaší straně chyba (což je jediná skutečně užitečná informace), na to máme oba šanci asi tak stejnou. Tedy pokud mi na tom systému nebude záležet natolik, abych tam nasadil LIDS nebo SELinux (s pořádnou politkou) nebo si aspoň pořádně pohrál s profily pro AppArmor. Totéž se týká množství napáchaných škod.
tvoje reseni ti akorat pridelava praci navic a bezpecnost nijak moc nezvysuje.
16.3.2011 09:44
Petr Tomášek | skóre: 39
| blog: Vejšplechty
kedykolvek ty vymyslis nejaku alternativu s heslom n+1, ja pridem s lepsou s 2x(n+1) (pripadne staci kludne 1 a n+1) ktora bude 100% bezpecnejsia (tazsia na prelomenie) ako ta tvoja.
Jenže když já nabízím alternativu, nabízím zlepšení v obou kritériích (bezpečnost i pohodlí). Alternativa, kterou nabízíte vy, zlepší jedno za cenu zhoršení druhého.
Ten druhý odstavec budu raději ignorovat. Rád bych, aby si tato diskuse i přes zjevný odpor mých oponentů k logickému uvažování zachovala aspoň nějakou úroveň. Tedy aspoň z jedné strany, nelze-li jinak…
nema cenu sa o tomto dohadovat s clovekom, ktory uprednostnuje pohodlie pred bezpecnostou
Já neupřednostňuji pohodlí před bezpečností. Já jen v situaci, kdy mohu zvýšit bezpečnost i pohodlí současně, to udělám. Zatímco vy tu bezpečnost raději neposílíte, protože byste měl špatný pocit, že je málo nepohodlné. Mně jsou pocity ukradené a zajímá mne, jak se věci skutečně mají, ne jak vypadají.
ze ten druhy odstavec ignorujes beriem ako suhlas s nim
To není souhlas. Ten odstavec neobsahuje žádná tvrzení, o kterých by se dalo diskutovat. Jsou tam jen invektivy a já nechci klesnout na vaši úroveň a předhánět se, kdo dokáže druhého víc urážet.
Achich ouvej. Kde jsem něco takového tvrdil? Tvrdím pouze, že k vašemu řešení vždy najdu
a dokonce i
Dokážete takovou alternativu nabídnout k mému řešení? Nedokážete. Vaše řešení bude při stejné odolnosti méně pohodlné a při stejné pohodlnosti méně odolné. Případně dokonce jak méně bezpečné, tak méně pohodlné. Jestli to pomůže, klidně vám to znázorním i graficky.
SAP si musel vymyslet vlastní VM kontejnery, aby splnily jejich nároky.
inymi slovami, potrebujes poznat dve konkretne hesla dvoch konkretnych userov a v tom je prave ta sila
Jenže prolomit (hrubou silou) hesla těch dvou uživatelů je pořád výrazně snazší než prolomit to jedno moje.
ty absolutne nechapes (alebo nechces chapat), o com hovorim. kolko krat mam zopakovat, ze o silu hesiel v tomto nejde
Ale jde. Odolnost vůči útoku hrubou silou závisí právě na síle těch hesel. A ani u jiných typů útoků (kromě naprosté slabomyslnosti systémáka - a ani tam ne vždy) to vaše opatření nic zásadního nepřidá. Dokonce v určitých situacích spíš naopak.
precitaj si prosim ta cele vlakno. ja proste nechapem preco vsetci porovnavate hesla roznej dlzky/roznej sily!Protože nejde pouze o to, zda něco zvýší bezpečnost nebo to bezpečnost nezvýší. Jde o to, jak moc to zvýší bezpečnost, a za jakou cenu. Takže jedna možnost zvýšení bezpečnosti je prodloužit heslo
roota o jeden znak. Bezpečnost se tím zvýší výrazně a náklady nejsou téměř žádné. Další možnost je vyžadovat přihlášneí přes dva uživatele. Bezpečnost se tím zvýší trochu, náklady budou vyšší (je třeba si pamatovat a psát více znaků hesel). Další možnost je třeba třeba zavolat čarodějku, která server na sto let zakleje ochranným kouzlem. Bezpečnost se v tomto případě nezvýší vůbec, náklady na shánění kořene madragory a dračího zubu budou nemalé
Soudný člověk bude postupovat od těch možností zabezpečení, které přinášejí nejlepší poměr cena/výkon. Takže když chci zvýšit úroveň zabezpečení roota, nejjednodušší řešení je (pokud už chci mít povolené přihlašování helsem ze sítě) prodloužit heslo o jeden znak. Pak se podívám, jestli už mi to zabezpečení stačí. Pokud ne, odívám se na další možná řešení – a, ejhle, nabízí se možnost (opět s nejlepším poměrem cena/výkon) prodloužit heslo o ještě jeden znak. Takhle budu pokračovat, dokud nebudu se zabezpečením spokojen, nebo dokud nenarazím např. na nějaký limit, který by mi zabraňoval efekticně heslo prodlužovat (např. pokud se bude brát v úvahu jenom prvních 8 znaků hesla, nemá smysl ho prodlužovat za tuto hranici). Pak teprve přistoupím k řešení, které má nižší poměr cena/výkon – a zavedu třeba dvoustupňové přihlašování. Pokud to tedy vůbec bude mít smysl – pokud bych bezpečnost potřeboval zvýšit o 500 %, a dvoustupňové přihlašování mi ji zvýší o 1 %, musel bych aplikovat přihlašování přes 500 uživatelů, což asi nebude to pravé ořechové.
Mozna rizika jsou treba odkoukani - pokud bych obe prihlasovani neprovadel obvykle ihned po sobe, pak obe zadavani hesel jsou relativne nezavisle udalosti a pri caste obmene hesel se tim prudce minimalizuje pravdepodobnost, ze nekdo ziska odkoukanim obe zaroven platna hesla.
Tady vidím problém v tom, že jakmile odkoukne to první, má získání toho druhého výrazně usnadněné. Už se nebude muset snažit ho fyzicky odkoukat při psaní na klávesnici, ale může začít používat rafinovanější triky, jako je podvržená verze příkazu su apod. (Schválně: kdo píšete důsledně /sbin/su? Bez mučení přiznávám, že já ne. Ale ono by to stejně neřešilo všechny možnosti.)
su a dovolí se přepnout na roota bez hesla komukoli – proti tomu je vám zase vaše „třístupňová“ ochrana k ničemu.
A stále je to o tom, jaký je poměr ceny zabezpečení, a přínosu zabezpečení. Jaká je pravděpodobnost, že se bude pokoušet někdo heslo prolomit hrubou silou? Děje se to vcelku běžně. Jaká je pravděpodobnost, že budete mít na svém systému ssh, které povolí přihlásit uživatele bez znalosti hesla, ale jinak bude veškerá omezení respektovat, a někdo se pokusí váš systém napadnout přes tuto chybu? Pravděpodobnost je téměř nulová. Je opravdu rozumné zabývat se řešením tohoto hypotetického případu, nebo budete raději posilovat bezpečnost proti útokům, kterým musí váš počítat čelit každodenně?
su.
akoze nie ? najskor sa musis k tomu 'su' predsa dostat. a je _OVELA_ lahsie dostat sa k SSH ako k su takze zase z tohto vychadzam lepsie ako Michal.K tomu
su se dostane každý uživatel počítače, který na něm má přístup k shellu nebo může spouštět programy. A nemusí překonávat žádné překážky.
To je ale mimo téma, o čem se tady půdoně diskutuje. Aspoň tedy předpokládám, že nepovažujete obranu před hypotetickou chybou v ssh za důležitější, než obranu před reálnými útoky hrubou silou.
su na roota (s prázdným heslem)?
moje riesenie pridava aj ine vyhody a ochrany, ktore su podla mna nezanedbatelne
Tak nás s nimi konečně seznamte. Zatím jste pouze operoval hypotetickou a krajně nepravděpodobnou chybou v SSH démonovi, což není zrovna dvakrát přesvědčivé.
suovat (to je pěkné české slovo )
Jedno přihlášení navíc není obrovskou přítěží – ale vzhledem k tomu, že to má zanedbatelný vliv na zvýšení bezpečnosti, je ten poměr vložená práce / zvýšená bezpečnost dost špatný. Za názorem, že je to téměř zbytečné si stojím; a špatné je to proto, že bezpečnost se tím téměř nezvýší, ale neznalý uživatel bude mít pocit, jak moc pro bezpečnost udělal – protože předtím přece zadával 8 znaků hesla, a teď jich zadává 16, tak to tedy musí být něco, to je vlastně jako kdyby měl 16znakové heslo, a ještě musí uhodnout toho uživatele. Jenže ono je to ve skutečnosti pořád jako kdyby měl osmiznakové heslo a k tomu musel ještě určit, zda panna nebo orel.
viacstupnove prihlasenie navyse ochranuje (do urcitej, podstatnej, miery) aj pred inymi typmi utokov.Trochu bych tu větu upravil: více stupňové přihlášení navíc ochraňuje (do určité, nejspíš nepodstatné) míry před jinými naprosto nepodstatnými typy útoků. Typ útoku, který jste popsal (a před kterým vaše vícestupňová zabezpečení chrání), je stejně vykonstruovaný, jako moje konstrukce s prázdným heslem roota. Pokud už byste chtěl váš způsob zvýšení bezpečnosti propagovat, měl byste férově předeslat, že proti útoku hrubou silou nepřináší vaše vylepšení zabezpečení prakticky žádný přínos, proti známým typům útoků typu buffer overflow nebo spuštění podstrčeného kódu nepřináší také žádné zlepšení, ale přináší zlepšení v případě chyby „ssh zapomene ověřit heslo“, přičemž takový typ chyby zatím nebyl v žádném masověji používaném programu nikdy zaznamenán.
ake manevry preboha ? :) to sme myslim uz prebrali nie ? ziadne extra manevry sa nekonaju, o tom stale vsetci hovorite ako keby vam ruky odpali pri napisane jedneho hesla naviac :D doslova smiesne.Vzhledem k tomu, že to nepřináší prakticky žádné zvýšení bezpečnosti, jsou to zbytečné manévry.
ssh a bezchybné su. Já jsem pouze upozornil na to, že to stejně dobře může být opačně. Navíc chyby, kdy je možné z lokálního účtu získat roota se občas objeví, na chybu, kdy by ssh zapomnělo kontrolovat heslo si opravdu nevzpomínám.
"k tomu su se dostane každý..." jsem pochopil jako že každý se přes něj může začít přihlašovat, což mne zarazilo a myslel jsem, že má nějakou nedostatečnou či výrazně slabou ochranu, že ji každý hned obejde. Pokud jste myslel jen to, že se dostane k té binárce, tak to je podobné tomu, že se dostane k ssh na které třeba nemá přístup přes heslo nebo tak +-zhruba něco. Díky.
Jenže právě v tomto případě vaše idea vrstev nefunguje. Závislost náročnosti prolomení na délce hesla není lineární ale exponenciální. Proto zde ani zdaleka neplatí myšlenka, že dvě hesla určité délky jsou "dvakrát lepší". Tedy ona dvakrát lepší jsou - jenže právě jen dvakrát, zatímco "pouhé" jedno, ale o jediný znak lepší, bude odolnější 62-krát.
Protože jste dal opakovaně najevo, že čísla ani logika vás neoslovují, zkusím to ještě obrázkem. Na vodorovné ose máte počet znaků hesel dohromady (tj. náročnost pro správce), na svislé logaritmus* doby potřebné k prolomení hrubou silou (tj. náročnost pro útočníka). Červená křivka je vaše, modrá moje. Snad se shodneme na tom, že lepší je být "nahoře" (těžší pro útočníka) a "vlevo" (lehčí pro správce). Všimněte si, že ke kterémukoli bodu vaší křivky naleznu bod na své, který je od něj "vlevo nahoře", zatímco k žádnému bodu mé křivky nebudete schopen nalézt na své bod, který by od něj byl "vlevo nahoře".
pridanim dalsieho kroku do procesu overovania znamena pridanie dalsej vrstvy ochrany, cez ktoru je potrebne preniknut
Jsou-li ty dvě vrstvy založené na stejném principu, je přínos naprosto zanedbatelný a nestojí za ty komplikace. Proto je lepší, nejsem-li se současným stavem spokojen, zvýšit bezpečnost způsobem, který ji zvýší podstatně více a přinese méně komplikací.
* logaritmickou stupnici jsem zvolil proto, aby se obě křivky daly vůbec rozumně zobrazit v jednom grafu; rozhodně tím vašemu řešení neubližuji, spíš naopak: kdybych to neudělal, plazila by se vaše křivka hluboko u osy x
ten obrazok je nespravny pretoze prikladas velmi velku vahu tomu, ze sa treba 2x prihlasit
To je právě úplně jedno, jakou tomu přikládám váhu. Když si osu x přetransformujete jakoukoli rostoucí funkcí, dopadne to úplně stejně. Problém je, že ve vašem případě rostoucí není, protože vy potřebujete ten dobrý pocit, že pro "dobro věci" děláte víc práce. Že zbytečně, to vás netrápí.
napriklad, ak by sa v SSH objavila chyba, ktora by umoznovala obyst zadanie hesla
To by byla velmi specifická chyba, pokud by tam byla chyba takového kalibru, pak už je řádově pravděpodobnější, že mi umožní získat toho roota rovnou (protože útočníkovi umožní spouštět podvržený kód v kontextu sshd). Takže na tom nebudete o nic lépe než já.
taktiez hesla su navzajom rozne
Efekt tohoto opatření je celkem zanedbatelný, jak se vám celou dobu snažím doložit. Jenže výpočet ignorujete, logické argumenty odmítáte, ani obrázek interpretovat nechcete. Naštěstí se zdá, že jste jen jeden z mála.
To jsem vám snad jasně popsal - na vodorovné ose je počet zadávaných znaků hesel, na svislé (desítkový) logaritmus počtu pokusů potřebných k prolomení hesla (na střední hodnotu bych to musel před zlogaritmováním vydělit dvěma, ale to na věci opět nic nezmění, jen by se obě křivky posunuly kousek dolů). Předpokládám abecedu 62 znaků, ale ani kdybyste vzal nejmenší myslitelnou hodnotu 26, na vyznění grafu se opět nezmění nic, jen se modrá křivka mírně sklopí (ale pořád bude vlevo nahoře od červené). Předpokládám, že vzorečky si dokážete odvodit sám.
ano, je to velmi specificka chyba avsak je to len jeden jediny maly priklad
Můžu vám ukázat desítky (spíš víc) chyb, kde buffer overflow umožní útočníkovi spuštění podvrženého kódu v kontextu démona. Ukažte mi aspoň jednu, kde nějaký démon (tak dlouho a tak široce používaný jako OpenSSH) jen tak z plezíru zapomene zkontrolovat heslo.
ukazal som niekolko _dobrych_ prikladov a porovnani
Kde? V této diskusi to nebylo. Tady logické argumenty (jasně, ty vy neuznáváte), čísla a dokonce už i grafy předkládám jen já (OK, nejen já, ale zatím nikdo, kdo by tvrdil totéž co vy).
Tak mi v tom grafu na kterékoli z těch křivek ukažte hodnotu, která je podle vás spočítaná špatně. Nebo abyste to měl ještě jednodušší, tady máte zdroják pro gnuplot, kterým to bylo vykreslené:
set terminal png set output 'pwd.png' set xrange [0:25] set yrange [0:25] set parametric plot [1:25] t,log(62**t)/log(10) with lines lw 2 lc rgbcolor "#0000C0" \ title 'one step', \ 2*t,log(2*62**t)/log(10) with lines lw 2 lc rgbcolor "#C00000" \ title 'two steps'
(Znalci nechť prominou, s gnuplotem pracuji jednou za uherský rok.)
t,log(2*62**(t/2))/log(10) with lines lw 2 lc rgbcolor "#C00000" \.
To není chyba. Jasně jsem napsal, že na vodorovné ose je náročnost přihlášení pro správce systému. Ta je v mém případě n, ve vašem 2n. Logaritmus výsledky nezkresluje, protože nás zajímá jen porovnání (nahoře/dole a vlevo/vpravo) a logaritmus je rostoucí, takže výsledek porovnání zachová.
ak by si nahodou nevedel, tak…
Trochu neskromně si troufám tvrdit, že o tom něco malinko vím. Ale fakt nemám náladu na nějaké handrkování ve stylu "kdo vejš" a mlácení se diplomy, připadá mi to nedůstojné a už mnohokrát jsem si ověřil, že ta písmenka kolem jména sice nějakou vypovídací hodnotu mají, ale není dobré je přeceňovat.
tu
"Tu" je zcela mimo. Tam v podstatě jen opakujete, že vás náročnost pro správce nezajímá. Ale ani tak nechápu, proč nejste ochoten akceptovat řešení, které je proti vašemu bezpečnější i pohodlnější současně.
aha, tak preco si prednedavnom naznacoval, ze mas lepsie vzdelanie ako ja (to svoje si mimochodom neprezradil) ? a zrazu je nieco taketo pod tvoju uroven.. zaujimave
Pokud si opravdu myslíte, že je nezbytně nutné si ty centimetry poměřovat, tak těch let na matfyzu mám za sebou osm (budu-li počítat jen dobu, kdy jsem byl formálně studentem), nějaký ten diplom bych taky doma našel, riga hotová, k dokončení PGDS chyběla "jen" ta drobnost v podobě disertace (ale pak jsem se rozhodl, že matematikou se živit nebudu). Bude se vám teď lépe spát?
Jinak v tom příspěvku, na který se teď odkazujete, jsem nechtěl porovnávat formální vzdělání, ale jen mne zajímalo, čím je způsobeno vaše hluboké nepochopení formulace "za předpokladu A platí B". Skutečnost, že studujete třetí ročník matfyzu (pořád tajně doufám, že ne toho pražského), mi docela vyrazila dech. V dobách, kdy jsem cvičil, bych takovou ignoranci netoleroval ani prvákovi z bakalářského oboru (jakéhokoli).
vidim, ze pre teba ja naozaj brutalne narocne napisat par znakov naviac
Není to brutálně náročné, ale nevím, proč bych si komplikoval život, když mohu mít mnohem větší zvýšení bezpečnosti za cenu mnohem menší ztráty pohodlí pro mne.
tiez nechapem, preco nie si ochotny akceptovat riesenie, ktore je oproti tvojmu znacne bezpecnejesie a takmer rovnako pohodlne
Protože kdybych chtěl (a potřeboval), mohl bych mít při podstatně menším omezení pohodlí podstatně výraznější zvýšení bezpečnosti.
prosim ta, ake porovnavanie ? :) este nakoniec som s tymto zacal ja, hej ? :D porovnavat si sa chcel ty sam (vyssie je presny link)
Kde je v tom mém příspěvku nějaké porovnávání? Já se jen zeptal, zda jste absolvoval aspoň nějaké základy matematické logiky. A to proto, abych věděl, jestli má smysl dál něco vysvětlovat. Protože s tak zásadním nepochopením významu implikace, jaké jste předvedl vy, se obvykle setkávám pouze u lidí matematickou logikou zcela nedotčených. U studenta třetího ročníku MFF je to ovšem naprosto alarmující.
si chod hovorit do zrkadla (ak znesies sam seba)
Nezaujatý pozorovatel si už jistě dávno udělal obrázek, kdo tu opakovaně ztrácí nervy a uchyluje se k osobním výpadům. Nemusíte mu to znovu a znovu předvádět.
nedostatky v matematickych vedomostiach nemam, to sa len ty snazis presvedcit sam seba, ze to tak asi bude :)Ach jo, člověče, tohle nemůžete myslet vážně... přiznejte se, že se jenom snažíte p. Kubečka vytočit?
(...)
30.10.2007 14:31
satanatas | skóre: 14
| blog: vše co můžete s klidem hodit za hlavu ze světa linuxu i jiných světů
| Graveyard
31.10.2007 20:47
Michal Fecko | skóre: 31
| blog: Poznámkový blog
co je toto za blbost ? :) kde sa hovorilo, ze hesla su rozne silne ? praveze cely cas hovorim, ze su silne rovnako (vsetky tri)!Asi to nemá cenu vysvětlovat. Komu není rady ... Třeba se k tomu ještě vrátíme, teď to nechme.
ale ten rozdíl kupodivu bude velice malý:
log A = n*log(2*26), log B = n*(log(26))
dalsia blbost, pocitas to zle. v jednom pripade pouzivas 52 znakov a v druhom 26. tak ci tak to pocitas uplne chybne. cize (62 lebo Michal pocital s takou abecedou):
A = 2*log(62^5)
B = log(62^5)
Takže nejdříve jeden středoškolský vzoreček:
log(a^n) = n*log(a)
Teď k věci. Já to totiž nejdřív spočítám a pak teprve zlogaritmuju. Jestli tam dám 26 nebo 62, to už je kosmetický rozdíl. Ty to ale evidentně násobíš až po logaritmování, takže to ve skutečnosti umocňuješ místo násobíš. Vidíš ten rozdíl? Opravdu rád bych dostal odpověď na tuhle otázku.
na admina sa mi zdas primalo paranoidny
Jen proto, že odmítám provádět efektně vypadající opatření a dávám přednost těm, která jsou skutečně efektivní? Budiž, s tím se dokážu vyrovnat. Chcete-li si mermomocí vyměňovat komplimenty, tak vy jste ve mně vzbudil pocit, že máte příliš povrchní myšlení a rád podléháte prvnímu dojmu místo toho, abyste o problémech přemýšlel do hloubky. Ale asi by nebylo (z obou stran) fér posuzovat někoho, koho neznáme, jen na základě dojmu, který na nás udělal v jedné diskusi.
ja som nikde neovori, ze tato vlastnost zasadnym sposobom zvysi bezpecnost (praveze vyssie hovorim opak). aj male zvysenie je lepsie ako ziadne.Problem je, ze zablokovani prihlasovani na roota ma casto negativni efekt na zabezpeceni. Pokud se prihlasuji primo na roota, tak se mohu prihlasit pomoci DSA klice (chraneneho heslem) a tento postup je odolny proti 'odkoukani' hesla (nebot heslo k DSA klici je bez DSA klice k nicemu). Pokud se ale prihlasim na lokalniho uzivatele a nasledne su nebo sudo na roota, tak uz musim zadavat heslo na roota nebo sebe a to heslo muze 'odkoukat' nekdo jiny a staci mu libovolny lokalni ucet (bez dalsich protiopatreni) pro ziskani roota.
Problém je v tom, že vy se nám snažíte tvrdit, že nutností zadat dvě hesla netriviálně zvýšíte bezpečnost systému a že tudíž kvůli tomu stojí za to komplikovat správu systému. Já vám na to odpovídám, že kdyby útočník místo nutnosti zadat dvě hesla musel zadat sice jen jedno, ale o pouhý jeden znak delší, byla by to pro něj podstatně větší komplikace. Tedy že prodloužením hesla o jediný znak zvýšíte bezpečnost (proti útoku hrubou silou) řádově více než vynucením postupného zadání dvou hesel, a to při podstatně menším znepříjemnění života správci systému.Pěkně se ta diskuze rozjela, píšu sem, abych nevyhrál vyhlášenou soutěž o nejužší příspěvek
nicméně realita je taková, že pokud budou hesla dostatečně kvalitní a jejich délka dostatečná, nemáte s útokem hrubou silou šanci. To znamená, že máte-li heslo dlouhé n nebo n+1 znaků nehraje žádnou významnou roli, protože ani jedno neprolomíte hrubou silou dostatečně rychle.
Výborně! Konečně si to někdo uvědomil. (To není ironie, to myslím naprosto vážně.) Vtip je v tom, že zvýšení bezpečnosti dvoustupňovým přihlašováním zvýší bezpečnost naprosto nepodstatně a navíc ještě v místě, kde to tak jako tak není potřeba, a kdyby bylo (proto jsem také pořád zdůrazňoval formulace typu "pokud už mám potřebu zvyšovat odolnost proti útoku hrubou silou), dá se mnohem snáze dosáhnout mnohem více. Proto ho považuji za opatření sice efektně vypadající (Považte! Musí zadat dvě hesla!), ale z praktického hlediska naprosto nezajímavé.
Vrstvení vám navíc dává výhodu proti jiným typům útoků,kde může útočníkovi významným způsobem ztížit pozici.
Pořád se snažím vyzvědět jak, ale bohužel mi to nikdo nechce říct. Ty argumenty, které tu zatím padly, byly dost slabé, spíš šlo o pocity než o fakta.
Může dojít ke zcizení hesla roota, které bylo uloženo na externím, snad bezpečném, místě. Potom bude muset útočník buď zjistit další heslo nebo získat přístup k lokálnímu stroji.
Nicméně abych nesklouznul pouze k případu dvou hesel, spíše jsem komentoval použití více vrstev. Nikoliv nutně více hesel. Na první vrstvě mohu použít např. klíč na druhé až heslo apod.
Nepodstatné se mi spíše zdá prodloužení už kvalitního hesla o další znak, tím nepřidáváte do ochrany nic nového proti útočníkovi.
Naprosto souhlasím, že je nepřidávám nic podstatného. Ale pořád přidávám podstatně víc než vy dvoustupňovým přihlašováním.
Pokud si samozřejmě šikovně nainstaluje někam skrytou kameru, tak uvidí obě hesla
Taky se koukám na CSI. Ale vždycky když zaslechnu větu "Teď mi to zvětšete a doostřete.", obracím oči v sloup a uvažuji, kolik z těch technologií, které tam používají, je stejně smyšlených.
Může dojít ke zcizení hesla roota, které bylo uloženo na externím, snad bezpečném, místě.
Teď mi připadáte jako někdo, kdo posuzuje bezpečnost vchodových dveří podle toho, jestli je odemkne někdo, kdo najde klíč pod rohožkou.
Nicméně abych nesklouznul pouze k případu dvou hesel, spíše jsem komentoval použití více vrstev.
To je ovšem velmi podstatný rozdíl. Použít dvě vrstvy má smysl, pokud jsou ty vrstvy principiálně různé. Když dáte za sebe dvě stejné vrstvy, efekt je mizivý a výsledek nestojí za vynaloženou námahu.
Naprosto souhlasím, že je nepřidávám nic podstatného. Ale pořád přidávám podstatně víc než vy dvoustupňovým přihlašováním.
Jelikož vaše řešení má jen jeden krok, a to zadat silné heslo a v druhém řešení zadáme v prvním kroku také silné heslo, tak po prvním kroku jsou na tom obě řešení stejně. Tak nevím jak můžete tvrdit, že vaše řešení přidává podstatně víc.
Taky se koukám na CSI. Ale vždycky když zaslechnu větu "Teď mi to zvětšete a doostřete.", obracím oči v sloup a uvažuji, kolik z těch technologií, které tam používají, je stejně smyšlených.Já také koukám na CSI a v podobných situacích kroutím hlavou. Nicméně to nemá nic společného s tím co jsem napsal. O žádné kameře na parkoviští nebo algoritmu, který umí rozlišit nápis v novinách odražený ve zpětném zrcátku automobilu, který se odráží ve výkladní skříni 200 metrů daleko jsem nepsal
Utočníkovi postačí jednoduchá kamerka z mobilu v dostatečné blízkosti klávesnice, s přímým výhledem na klávecnici. Nemluvě o tom, že heslo z klávesnice lze odposlechnout i s použitím mikrofonu.
Teď mi připadáte jako někdo, kdo posuzuje bezpečnost vchodových dveří podle toho, jestli je odemkne někdo, kdo najde klíč pod rohožkou.Opět jsem nic takového nepsal
Heslo roota je uložené na bezpečném místě pro případ, že by se osobě, která ho zná, snad něco stalo apod. Bezpečné místo může být různé pro různé lidi. Bankovní trezor, trezor v kanceláři ředitele, bezpečnostní skříň v archivu, bezpečnostní schránka doma u živnostníka. Tj. získání tohoto hesla není snadné jako nalezení klíče pod rohožkou, ale ani nemožné. A pokud jsou dveře dostatečně pevné nezbyde jiná možnost než nějáký ten klíč opravdu nalézt, ale ne pod rohožkou. Toto celé jsem výše uvedl jako příklad v čem je vícestupňové řešení bezpečnější, protože po nalezení klíče od vašeho domu máme přístup do celého domu. Kdežto v případě nalezení klíče u mého domu musíte překonat ještě jedny stejně silné dveře, tj. získat další klíč od dveří.
Použít dvě vrstvy má smysl, pokud jsou ty vrstvy principiálně různé. Když dáte za sebe dvě stejné vrstvy, efekt je mizivý a výsledek nestojí za vynaloženou námahu.Toto nelze obecně tvrdit, dvě stejné vrstvy mohou být stejně užitečné. Vaše argumentace platí pouze v případě, že prolomením jedné vrstvy získáme obrovskou výhodu k prolomení další vrstvy. Pokud tedy budeme mít dva případy: (1.klíč, 2.silné heslo) nebo (1.silné heslo, 2. silné heslo) k překnání 1. vrstvy potřebujeme u obou zcizit (klíč nebo silné heslo), což nám nedává žádnou výhodu k překonání druhé vrstvy. Rád bych ale připomněl, že se nesnažím obhajovat použití konkrétně pouze dvou hesel, ale více vrstev obecně, kterými mohou být i dvě hesla, když to vyhoví požadavkům na bezpečnost. PS: Tato diskuze je dost rozsáhlá a nepřehledná, ale v mnoha směrech zajímavá. Existuje na abíčku nějaká delší
?
Utočníkovi postačí jednoduchá kamerka z mobilu v dostatečné blízkosti klávesnice, s přímým výhledem na klávecnici.
Asi máme diametrálně odlišné představy o tom, odkud a za jakých podmínek se přihlašovat na servery.
Heslo roota je uložené na bezpečném místě pro případ, že by se osobě, která ho zná, snad něco stalo apod. Bezpečné místo může být různé pro různé lidi. Bankovní trezor, trezor v kanceláři ředitele, bezpečnostní skříň v archivu, bezpečnostní schránka doma u živnostníka. Tj. získání tohoto hesla není snadné jako nalezení klíče pod rohožkou, ale ani nemožné.
Jsou jen dvě možnosti: buď je to těžší než nabourání se do systému obvyklým způsobem a pak bych se měl zabývat tím, jak zabezpečit obvyklé cesty. Nebo je to těžší, a pak zase nemá (v tuto chvíli) smysl se zabývat tím, co je na počítači. Na úrovni paranoie, na které se tu pohybujeme, je ale už samotná myšlenka "schovaného hesla roota" značně pochybná.
Vaše argumentace platí pouze v případě, že prolomením jedné vrstvy získáme obrovskou výhodu k prolomení další vrstvy.
Vůbec ne. Snažím se vám vysvětlit, že nasazením dvou stejných vrstev za sebe získáte prodloužení časové náročnosti útoku na dvojnásobek za cenu dvojnásobné náročnosti i pro řádného uživatele. Oproti tomu změnou parametrů té vrstvy obvykle docílíte řádově většího navýšení náročnosti pro útočníka při podstatně menším zvýšení náročnosti pro řádného uživatele.
Rád bych ale připomněl, že se nesnažím obhajovat použití konkrétně pouze dvou hesel, ale více vrstev obecně,
A já zase netvrdím, že přidávání vrstev je chyba (nebo zbytečné) všeobecně. Tvrdím, že jsou-li dvě vrstvy konstrukčně stejné, nestojí výsledek za tu námahu.
Existuje na abíčku nějaká delší?
Mnohem delší… (ale už jsme za polovinou)
26.10.2007 22:28
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
25.10.2007 13:02
satanatas | skóre: 14
| blog: vše co můžete s klidem hodit za hlavu ze světa linuxu i jiných světů
| Graveyard
25.10.2007 17:54
tsLnox | skóre: 31
| blog: Blog jednoho ukecaného Gentoolemana
| Žďár nad Sázavou
25.10.2007 22:14
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
26.10.2007 23:44
sudo su
26.10.2007 12:48
satanatas | skóre: 14
| blog: vše co můžete s klidem hodit za hlavu ze světa linuxu i jiných světů
| Graveyard
26.10.2007 23:31
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
26.10.2007 23:29
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
25.10.2007 22:06
the.max | skóre: 46
| blog: Smetiště
Takovou hovadinu, ze by zmena portu zabranila exploitu (ackoliv ciste teoreticky se podobne se chovajici chyba muze vyskytnout) tady snad nikdo netvrdi, opet nechapu proc to zminujete.
U nepratel je dulezity sirsi pohled, je treba odhad schopnosti a moznych strategii/taktik ruznych skupin nepratel. Takze polopaticteji: ano, pokud nekdo pujde primo po me, pak mi zmena portu nepomuze, v ostatnich pripadech to je velice levny a ucinny zpusob, jak se schovat v davu. A pred cim schovani v davu muze chranit vizte vyse.
Takovou hovadinu, ze by zmena portu zabranila exploitu (ackoliv ciste teoreticky se podobne se chovajici chyba muze vyskytnout) tady snad nikdo netvrdi, opet nechapu proc to zminujete.
Tak k čemu je to tedy dobré?
A pred cim schovani v davu muze chranit vizte vyse.
Nevidím to tam. Nejdřív jste naznačoval, že odstěhování sshd na nedefaultní port nějak pomůže proti exploitům v případě, že je v démonovi chyba, teď jste (podle mne naprosto správně) připustil že ne. Že to nepomůže (nemělo by - a pokud ano, je problém jinde) proti útokům hrubou silou (ať nahodilým nebo cíleným), to jste připustil už dříve. Tak proti čemu to podle vás pomůže?
Tím pádem spím poměrně klidně.
"Naklady" se zmenou portu nejsou zadneJsou – např. nepřihlásíte ze sítě s restriktivním firewallem, případně váš
25.10.2007 21:12
ssh provoz spadne při shapingu někam mezi stahovače a P2P.
takže jsem na základě příspěvku Sinuheta změnil port a jsem klidnější
A to je právě ta chyba, před kterou se tu snažím varovat. Protože odstěhování sshd na nedefaultní port rozhodně není důvod k tomu, abyste byl o sebemenší chloupek klidnější. Pokud vám vadí ty hlášky v logu, tak si je potlačte nebo odfiltrujte do samostatného souboru.
26.10.2007 10:03
Marián Oravec | skóre: 22
| Nitra
Něco jako že když útočník zná přihlašovací jméno, verzi ssh démona a řadu dalších informací popisující váš systém, tak je nebezpeční průniku stejně velké, jako když nic z toho neví, protože vy přece máte to vaše "opravdové zabezpečení".
Ne, pouze tvrdím, že pokud lépe zvolím heslo, například tím, že místo obvyklých osmi znaků bude mít 9 nebo 10, ztížím mu ten útok řádově více než technikami, které prosazujete vy. A bude mne to stát řádově méně úsilí. O variantě, kdy autentizaci heslem zakážu úplně a budu se přihlašovat pouze klíčem, ani nemluvě…
silné zabazpeční -- root s 10 místným heslem (velmi ztížen průnik) slabší zabezpečení -- bez roota (moc práce a průnik není ztížen) nejslabší zabezpečení -- pomocí ssh klíče (strašně moc práce a efekt vlastně na houno)Dobré :)
Pokud budu důvěřovat, že deset znaků je dost, klidně vystačím s jedním desetiznakovým. A pokud ne, dostanu na 11 znaků podstatně vyšší míru odolnosti, než budete mít vy se svými osmnácti…
To je pro vás tak těžké přiznat, že při porovnání dvou variant, z nichž je jedna výhodnější v obou posuzovaných kritériích, není důvod volit tu, která je v obou kritériích méně výhodná? Nebo pokud máte nějaké kritérium, ve kterém je varianta 8+8 výhodnější než 9, tak nás s ním konečně seznamte. Tedy kromě toho, že to vypadá efektněji.
"Jenomže prolomit desiti a osmiznakové heslo je řádově těžší, než jen jedno desetiznakové."Zvláštní, já myslel, že to není težší ani o jedno procento...
(Má-li abeceda hesel 10+ znaků.)
(Snad ne "třetím rokem jako uklízečky"?)
To mne také vyděsilo. Přeci ta škola nemohla za těch pár let tak strašně upadnout.
Faktem ovšem je, že kdykoli někdo ignoruje logiku, jsem v koncích, protože nevím, jak bych měl vlastně argumentovat. Hrát na city? Že je chyba snažit se aplikovat logiku na "běžný život", to mi už tvrdila spousta lidí. Ale je že je chyba používat logiku v informatice, to na mne ještě nikdo nezkoušel…
admina, testa a guesta a sales a NIKDY nehádající hesla na kubecek :)
kubecek a hlavně za druhé to, jak se skutečně jmenuje, snadno zjistí každý, kdo ode mne dostal nějaký mail (nebo si ho našel v archivu některého diskusního listu na webu) a pravděpodobně ten login name snadno zjistí i každý, kdo si dá pár minut práce s prohledáváním mých příspěvků na tomto serveru (a nejspíš bude existovat i spousta dalších možností). Takže spoléhat na to, že do mého účtu nikdo bourat nebude, by mi připadalo krajně nezodpovědné.
Když děti vyrostou, vykročí do života, v němž odstrkovaný nakonec stejně ostrouhá, naivní sedne na lep chytrákovi a zatímco si na člověku smlsne kdejaká havěť, jeleni se klidně pasouJinak řečeno, opravdu je to zřejmě mnohem horší, než si připouštíte. Otázkou zůstává, jak z toho ven? Osobně se domnívám, že odpovědí je kultura. V tomto zde myslím odvádíte velmi dobrou práci, což je skvělé.
lukas ~ # grep 1001 /etc/passwd jeden_admin:x:1001:1014::/home/jeden_admin:/bin/bash druhy_admin:x:1001:1014::/home/druhy_admin:/bin/bash lukas ~ # su druhy_admin jeden_admin@lukas /root $ id uid=1001(jeden_admin) gid=1014(jeden_admin) groups=1014(jeden_admin) jeden_admin@lukas /root $ passwd Changing password for jeden_adminbdw. ja som tiez zastancom postupu: login na normal account a az potom su (sudo, sesu, sesudo, ..), kedze utocnik potom musi uhadnut nielen jedno heslo, ale dve aj nazov account ktory ma pravo na *su* prikazy. Spolu s limitovanim poctu pokusov napr pridavanim casu medzi zadaniami, ... to vie dost obmedzit moznosti utocnika/ov.
Bolo tu spomenute uz vselico ale zasadna vec nie :o) ked si odpustim komentare ako bezpecnost a podobne, tak pre system nebude ziadny root2. Vsetko co bude pustene, vykonane, ... bude pod accountom root. napr ked root2 si povie ze si zmeni heslo a nepovie to passwd, tak bude menit heslo pre root account.
To máte samozřejmě pravdu a je to důležitý postřeh, jen bych to ještě trochu upřesnil: pro systém (jádro) ve skutečnosti nic takového jako uživatelské účty neexistuje. Pro jádro mají jen procesy jakási číselná (E)UID/(E)GID a soubory jakási číselná UID/GID a při vyhodnocování práv se tyto hodnoty podle jakéhosi algoritmu porovnají. Uživatelské účty jsou vlastně jen berlička pro některé user space aplikace, které tu a tam podle jakési tabulky převedou textový identifikátor (login name) na UID nebo naopak.
Vlastně tak úplně pravdu nemáte, protože to, komu se změní heslo, spustíte-li passwd bez argumentů, bude záležet na tom, kterou položku vám vrátí getpwuid() - a to za určitých okolností nemusí být root, ale ta druhá. Totéž se týká třeba nastavení proměnné USER v (Bourne) shellu, výstupu příkazu id, výstupu 'ls -l' apod.
Vlastně tak úplně pravdu nemáte, protože to, komu se změní heslo, spustíte-liSuhlasim. Co sa stane zavisi odpasswdbez argumentů, bude záležet na tom, kterou položku vám vrátígetpwuid()- a to za určitých okolností nemusí býtroot, ale ta druhá.
/etc/nsswitch.conf, poradi riadkov v /etc/passwd, ...Úchylného na ní není nic. Jen se na to nesmíte dívat jako na dva různé uživatele, ale jako na dva aliasy pro jeden účet. Tedy podobně jako v případě hardlinku ve filesystému.
To je mimochodem velice názorná analogie, tam také musíte oddělit skutečný soubor (i-node + alokační bloky) a adresářovou položku, která se na něj pouze odkazuje. Přitom na tentýž soubor (i-node) může odkazovat i více adresářových položek a nebo také žádná (např. smažete-li všechny adresářové položky, ale se souborem stále nějaký proces pracuje). Rozdíl je jen v tom, že UID na rozdíl od souboru nemůžete vytvořit ani smazat.
je lepší se přihlašovat přes normální účet a používat su, sudo a pod..... pak se v logu oběví kdo jaké změny dělal a podz bezpecnostniho hlediska to vsak nijak vyrazne lepsi neni. prave naopak - musis porad psat heslo. To o te pohodlnosti vypravej nejakemu spravci, ktery ma na starosti vic jak 5 serveru.
while read server do ssh normalni_user@$server sudo rm -f /etc/passwd done < vsecky_servery.listPokud mám autentizaci klíčema a sudo se neptá na heslo, je to v pohodě a bez zadání jediného hesla. Přitom mě to i nadále chrání před vlastní blbostí (nepoužívám roota stále, ale jen když je potřeba).
normalni_user, protože normalni_user stejně může všechno co root. Takže pak mi připadá bránění v přímém přihlášení pod rootem dost samoúčelné.
Mně se právě nelíbí ta koncepce, kdy existuje normální uživatelský účet (používaný pro běžnou práci), který je oprávněn spouštět jakýkoli příkaz bez zadání dodatečného hesla. Protože pak mne fakt, že nepracuji trvale pod rootem, chrání už jen před vlastními překlepy a zbrkle odeslanými příkazy.
Další výhodou přihlašování přes normálního uživatele by mohlo být zjištění kdo (přes jaký účet) a odkud to byl, pokud se logy ihned odesílají na jiný počítač (aspoň to, že se přihlásil tam bude).
To máte pravdu. Ale pokud se takové logování používá, pak je většinou ten logovací server pod stejnou správou jako jednotlivé stroje, které ho využívají. Samozřejmě ne vždy, ale velice čast to tak je.
Ale co si budem nalhávat, tohle je asi největší bezpečnostní rizikoMně se právě nelíbí ta koncepce, kdy existuje normální uživatelský účet (používaný pro běžnou práci), který je oprávněn spouštět jakýkoli příkaz bez zadání dodatečného hesla. Protože pak mne fakt, že nepracuji trvale pod rootem, chrání už jen před vlastními překlepy a zbrkle odeslanými příkazy.
29.10.2007 17:36
xkucf03 | skóre: 49
| blog: xkucf03
)
do {
azurIt: zablokování přímého přihlášení na roota u sshd zvýši bezpečnost systému (za jinak nezměněných podmínek)
Kubeček: obskurní a pracné, zvětšením hesla o jeden znak se obrana proti útoku hrubou silou zvýší podstatně více
} until (stop_speaking("azurIt","vůz") and stop_speaking("Kubeček","koza"));
Jinak pokud si dobře pamatuju, tak azurIt tady celkem nedávno získal administrítorský účet p. Krátkého, tak bacha ať si to s ním nerozházíte. Ten chlapec má talent, ikdyž ten skript napsal jak prase
Víte, kdyby šlo jen o mne a o Azurita, nechal jsem toho už dávno, protože mi ta debata začíná silně připomínat nedávnou diskusi s jedním člověkem, který tak dlouho obhajoval neobhajitelné, až začal tvrdit takové perly, jako že vztažná soustava spojená s bourajícím autem je inerciální (později se to snažil svést na nějaký sociologický experiment nebo sázku či co).
Jenže tu diskusi si čtou a budou číst i další. Mezi nimi i uživatelé nezkušení a problematiky neznalí, kteří by snadno mohli podlehnout povrchním argumentům typu "dvě hesla jsou samozřejmě bezpečnější než jedno" a místo skutečného zabezpečování systému aplikovat opatření typu zákazu přímého přihlášení na roota a podlehnout tomu falešnému pocitu bezpečí. Kvůli nim to dělám, ne proto, že by mne tak moc bavilo věcně argumentovat v debatě s někým, kdo mne opakovaně napadá, čísla ignoruje, logiku výslovně odmítá a o názorném obrázku prostě prohlásí, že je špatně, aniž by se obtěžoval říct v čem.
29.10.2007 18:00
Ondroid | skóre: 32
| blog: Hombre
Nepracujte pod rootem když nemusíte a už vůbec se pod ním do systému nepřihlašujte.Praktikuju to tak léta a pochybuju o tom, že bych něco dělal špatně.
ssh zapomnělo ověřit heslo, který se zastáncům vrstevnatosti nelíbí, ale žádný jiný nemají; dobře, napovím další možnost – slabina v protokollu SSH2 nebo jeho implementaci. Můžete si sami odhadnout, jaká je pravděpodobnost, že takovou slabinu bude znát váš útočník a taková slabina nebude obecně známá). Můžeme si různé druhy útoků klidně vzít postupně a podívat se, kolik je proti nim postaveno vrstev při použití většího množství uživatelů, přes které je nutné se prokousat na roota:
x trvá jen dvakrát déle, než uhádnout jedno takové heslo; navíc pokud už je útočník na cílovém počítači, půjde mu louskání hesla daleko rychlejissh démona (buffer overflow apod.) – 1 vrstva, po prolomení chyby má útočník rovnou roota (protože ssh běží pod rootem)ssh ho přihlásí pod daným uživatelem – 2 vrstvy; ovšem prolomením první vrstvy se vnější útočník dostal teprve na úroveň libovolného právoplatného uživatele systému, tj. druhá vrstva musí být natolik silná, aby sama ochránila systém (a to dokonce i před interními uživateli, kteří jsou nebezpečnější) Takže onou první vrstvou stavíte další zábranu pouze do jednoho směru, odkud je útok navíc velmi nepravděpodobný – opravdu vám to připadá jako dobrá investice do zabezpečení?root, protože na serveru dělám jenom nezbytně nutné zákroky.
5.11.2007 00:09
Ondroid | skóre: 32
| blog: Hombre
5.11.2007 08:34
Ondroid | skóre: 32
| blog: Hombre
Co takhle udelat, ze kdo zada trikrat spatne heslo dostane ban. :D
Je to ale spatne, kdyz bude napriklad nekdo zkouset utok z tve skoly, zabanuje skolni IP a ty uz se ze skoly ten den neprihlasis, nebo to zkusi treba pres TOR, ale to by zas bylo kurevsky pomale.
Mozna by byla jeste moznost neomezit to jen na 3 pokusy. Nevim sice jak tyhle programky na hadani hesel funguji, zda otrocky zkousi kazdou moznost jak jdou po sobe pismena v abecede, nebo prvni zkousi nejaky slovnik a potom az ostatni moznosti. Co takhle dat mezi jednotlive pokusy casovy odstup, moznost zkouset z jedne IP jednou za minutu, to by mohlo utocnika na par let zdrzet, pri dostatecne silnem hesle. Jeste me napada silenost, po kazdem pokusu o prihlaseni heslo zmenit, utocnik by stale predpokladal ze to zkousi pro jedno heslo, a byla by sance ze zrovna kdyz se zkousi jedno heslo bude to druhe a naopak, pri vyberu treba z peti moznych hesel, by to uz mohlo docela dobre fungovat. Horsi spravce, musel by zkouset pet hesel, aby se mu povedlo prihlasit. :D
Zkuste se podívat na datum téhle diskuse, myslím, že tazatel a diskutující už jí ani neřeší.
7.1.2009 23:32
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Stačí používat tacacs ... server v linuxu je, klient se najde určitě taky
Tiskni
Sdílej:
