Názory k článku Single Packet Authorization aneb jeden paket vládne všem
-
frantazdepa (neregistrovaný)
uz vidim jak „hranicni firewall“ rozumi tomuhle nesmyslu. leda ze tam mate nejakej linux+iptables fw, coz vetsinou neni pripad rozumne vetsi site (ale samozrejme chapu ze v hromade nasazeni to muze byt rozumny reseni)
ale zase je to typicky „security through obscurity“, mnohem radsi budu verit aplikaci, ze dokaze obstarat autentizaci, nez nejakymu takovyhlemu bazmeku
-
V. H. (neregistrovaný)
Že nevíte jak to funguje nemusíte tvrdit, to je vidět z vašich příspěvků. Tohle nenahrazuje aplikační autentizaci, ale přidává se to k ní – nejdřív člověk musí projít SPA autentizací a pokud uspěje, následuje standardní autentizace u aplikace.
Firewall to umět nemusí, tohle se odehrává na cílových serverech. Firewall jen propustí pakety na port serveru, kde čeká SPA démon. Čili umí to libovolný krabičkový firewall, který umožňuje zadat pravidlo „pusť pakety na port XYZ“. Takže asi každý.
-
V tomoto systému vidím dvě nezmíněná rizika:
– Odposlechem se přítomnost SPA dá zjistit. Pro případný útok na špatně zabezpečenou službu za ním stačí poslouchat na síti a vyčkat, až si oprávněný majitel port odemkne. Pak spustit bleskový automatizovaný útok. Za těch pár sekund lze stihnout ledacos.
– Přímý útok na případnou zranitelnost SPA. SPA je složitý systém, jistě v něm nějaké chyby budou. Běží SPA pod neprivilegovaným uživatelem?
-
frantazdepa (neregistrovaný)
jasne, jeste si pred to muzes dat neco ve stylu „port knocking“, pretim jeste ping s md5 hesla a aktualniho timestampu do datovy casti, a jeste by to mohlo kontrolovat obsah nejakyho webu, ktery bys testne predtim musel zmenit…
realne se bezpecnost sshcka zvetsi o jedno procento, ale kazdy prihlaseni bude fakt zabava
… a nebo na ssh zakazes autorizaci heslem a budes mit zivot mnohem jednodussi
-
Ed (neregistrovaný)
Vyznam techto technik je jednoduchy – je to ochrana proti chybam v aplikacich. Predpoklada se, ze kod firewallu (iptables, …) ma mensi mnozstvi remote exploitu nez aplikace, takze timto zpusobem muzete chranit aplikaci i proti exploitum, ktere jeste nejsou obecne znamy.
Ma to tedy stejny vyznam, jako nastavit na firewallu, ze pristupovat na ssh se muze jenom z nejake site nebo adresy. Ucel firewallu doufam chapete?
Oproti staticky nakonfigurovanemu firewallu vam to ale umozni dynamicky zvolit adresy, vuci kterym jsou porty otevrene. To znamena, ze se na ssh dostanete, i kdyz jste zrovna jinde nez na sve obvykle siti. Je to jasne?
-
frantazdepa (neregistrovaný)
ne, jsem uplne hloupy a nechapu to a potrebuju aby se mi, i pres to jak je to trivialni, tady kazdy snazil vysvetlit jak to funguje
ja osobne rozhodne vic verim sshcku (ano, i pres ten posledni debiani trapas) nez programum tohoto typu
v cem je to lepsi, nez se na ten stroj prihlasit tim sshckem (kteremu tedy opakuji verim vic) a ten fw proste upravit tam – treba rovnou skriptem (coz btw jde delat stejne automaticky jako tohle, jenze je to cistsi)?
jinak, na web, smtp apod. tohle stejne nepouzijete, a na nejaky privatni (treba mezifiremni) aplikace proste normalni clovek pouzije nejaky druh vpnky
-
dustin (neregistrovaný)
Předpokládám, že do tak bezpečné sítě, na kterou chci použít výše uvedené zabezpečení, nebudu otevírat smtp nebo www.
Mně to SPA přijde velice užitečné řešení další vrstvy zabezpečení služeb typu SSH i VPN. Zrovna to SSH je zajímavé, protože denyhosts nám denně posílá desítky mailů s útoky.
-
A jak timto zpusobem chcete chranit ssh? Prihlasite se tam pres ssh a upravite si fw? ;-) Nebo spise zavolate Frantovi, aby se vam z vnitrni site zalogoval na fw a povolil pristup na ssh ze stroje s adresou w.x.y.z? Co kdyz ale nejaky imlitator hlasu odposlouchava vas hovor a odchyti cislo a pak sam zavola Frantovi, kdy se mu zachce? Budete hovorit navajsky, abyste snizil riziko, protoze navajsky hovoricich imitatoru hlasu po svete beha jen malo?
-
Jenze ten SPA bazmek, jak jiz nekdo podotkl, pridava dalsi bezpecnostni vrstvu ke vsemu, co ma jiz sve stare dobre bezpecnostni mechanismy. Muzete verit ssh jak chcete, to vam nikdo nebere, nicmene i u ssh existuje riziko, ze nekdo odhali nejaky vypeceny exploit (a i se to tusim stalo vice, nez jednou) a vypali vam rybnik, nez bude patch.
Vy treba mate pouze data, ktera nejsou natolik strategicka, aby vami pripadny hack tolik lomcoval. Znamenalo by to pro vas tak leda obnovu ze zalohy nebo reinstalaci a riziko spojene s tim, ze po urcitou dobu budete dosovat nebo spamovat, eventuelne se lamat do Pentagonu, coz by vam ISP a rozvedka nasledne vysvetlili. Jsou ale admini, kteri maji na krku data, jejich unik by mel mnohem zavaznejsi dusledky. SPA bazmek pak muze prispet k ochrane tech dat a nutnost otevirani portu pred vlastnim pripojenim je jen nepodstatnou obtizi, bohate vyvazujici pripadny pruser. Otazka je jenom to, nelze-li samotny SPA nejak exploitnout.
BTW, copak asi dnes dela ten zeleny mozek z Jizni Koreje, ktery zpusobil unik strategickych planu do Severni Koreje? Zameta ulice? Dobre mu tak.
-
I když ale věříš SPA méně než SSH, tak co ti brání využít oboje najednou? Ochrana se tím vlastně sečte – někdo musí prolomit SPA a pak SSH místo aby mu stačilo prolomit SSH. Takže i když SPA bude méně důvěryhodné než SSH, bezpečnost se tím zvýší (byť ne na dvojnásobek).
Jedinou podmínkou je, aby v SPA nebyla díra, která by naopak bezpečnost snižovala. (ovšem tímhle jsem tu nikoho argumentovat neviděl)
-
ZiGi (neregistrovaný)
musim povedat, ze pokial to nie je standardizovane, je to zbytocne.
ak je potrebna dodatocna ochrana staci pouzit VPN a je pokoj – vnutorne sluzby su zvonku neviditelne, VPN autentifikacia/autorizacia je nezavisla na autentifikacii/autorizacii pre jednotlive sluzby a je to rozsireny a standardny sposob ochrany podporovany na routroch aj klientskych OS (openVPN klient existuje snad pre vsetky platformy, cisco VPN tiez)
Pre SPA ocividne neexistuje multiplatformna implementacia, takze jedine vhodne nasadenie vidim v pripade maleho poctu pouzivatelov a to sa neprejavi ani jedina vyhoda – male vypoctove naroky.
Situacia sa moze zmenit ak sa SPA stane RFC standardom a objavi sa ako volba vo vacsine ssh/sftp klientov (alebo aspon v putty a openssh), potom by to mohlo byt zaujimave aj pre normalne servre a nie len pre domacich kutilov.
-
Našel jsem v článku malou chybku: v „kapitole“ Jaké jsou výhody" je tato věta: „Vše může být ještě rozlišeno pomocí příkazů, takže klient může přímo požádat server o otevření konkrétního paketu.“ Zde místo „paketu“ má IMHO být „portu“.
Jinak zajímavá metoda, díky. Pokusů o přihlášení na SSH je teď čím dál více a tak se to docela hodí.
Zdraví
Honza Marek -
Pavel (neregistrovaný)
Asi budu za rýpala, ale popsaná technologie je zejména o autentizaci (i když má v názvu autorizaci a tu i podporuje). Očekával bych, že autentizace bude v textu zmíněna místo autorizace. Např. formulace „Tím jsme připraveni se autorizovat“ mi nepřipadá správně, protože jsme zejména připraveni se autentizovat.
Ale ani původní článek na LinuxJournal v tom nemá jasno. Na jednom místě uvádí:
„This article explores the concept of Single Packet Authorization (SPA) as a next-generation passive authentication technology …“.O kousek dál je potom uvedeno:
„This article … lays the theoretical foundation for Single Packet Authorization and why it is a next-generation passive authorization technology …“ -
Fletcher (neregistrovaný)
Ale existuje. Existují totiž tři významově shodné výrazy pro tutéž činnost. Rozdíl v nich je pouze v tom, z jakého jazyka byly převzaty.
1) autentifikace – FR – authentification
2) autentikace – EN – authentication
3) autentizace – DE – authentisierungVíce viz odkaz, kde najdete i vyjádření Ústavu pro jazyk český: http://interval.cz/…tentifikace/
-
Petr (neregistrovaný)
Aha, to je chytré. V článku jsem si nevšiml, že se do SPA přibaluje i veřejná IP. Podle specifikace fwknop se adresa zjišťuje na whatismyip.org. To ovšem dělá útok malinko složitější, protože útočník musí být blíže klientovi. Nic mu nebrání v podvrhnutí IP. Klient pak packet s nesprávně získanou IP poslušně podepíše a je to.
-
michal_sjx (neregistrovaný)
Zda se mi, ze se tim zvetsuje riziko. Pokud je to tak slozita aplikace, ktera sifruje a tak dale, tak se na ni da provest (D)DoS. Dalsi vec je, ze nejakym zpusobem ovlada firewall. No a opravdu nechci nechat verejne dostupnou sluzbu, aby mi ovladala nastaveni firewallu.
Predpokladam, ze vetsina z nas to pouzije jen kvuli portu 22. Na to pouzivam jednoduche pravidlo ve FW – seznam povolenych. Pokud jsem nekde na cestach, tak mam VPN a jedu skrze ni. -
Phokz (neregistrovaný)
+1
Když už by někdo chtěl používat nějaký podobný obalovač, jako je SPA, tak by to mělo být algoritmicky hodně tupé, aby to mělo naprosto minimální složitost a definovanou paměťovou náročnost.
Jako ideální bych viděl předgenerovat si na serveru dostatek (dejme tomu desítky) 128bitových nebo delších zcela náhodných čísel, ty si pak stáhnout na flash disk nosený s sebou a používat je k ťukání. Spotřebované náhodné číslo se odstraní z listu na serveru.
Server je naprosto tupý, nebosahuje žádné složité algoritmy (typu SSL nebo Diffie-Helman apod) ve kterých by bylo možné udělat díru. Paket nelze použít znovu, jedině jde modifikovat na cestě src adresa.
Tupost algoritmu činí server odolný i proti wire-speed brute force attacku. -
Presne :). Nosim je vytistene na kousku papiru v penezence http://www.freebsd.org/…sswords.html
-
UfounX (neregistrovaný)
My ve firme mame na povoleni pristupu k VPN prave port-knock, a SPA je bezpecnejsi alternativa k port-knocku.
Proste dalsi urovnen zabezpeceni – pokud by byla objevena nejaka bezpecnostni dira ve VPN, tak se musi utocnik dostat nejdive pres SPA (resp. port-knock – podle toho co tam clovek pred tim ma).
-
JogoBlba (neregistrovaný)
Na tom řešení se mi nelíbí 2 věci:
- potřebuju další hesla a klíče (už teď si potřebuju pamatovat ,,kurwamoc" hesel)
- pokud se potřebuji připojit třeba z internetové kavárny na kanárech, nebude mi stačit www prohlížeč jako na obyč portknocking (ano, i prohlížečem lze klepat na porty a webová správa je mocný nástroj – hlavně když nemůžete instalovat další programy jako PUTTY)
