Názory k článku
Single Packet Authorization aneb jeden paket vládne všem

radsi bych tedy vsadil na authpf kombinujici silu ssh a pf firewallu na *BSD. preci jen je ssh otestovanejsi :)

neni lepsi pouzivat tu autorizaci normalne na aplikacni urovni? vetsina pouzivanych aplikaci to umi, a urcite je to lepsi nez vymyslet takovyhle kraviny
(pokud se nekdo chcete hadat, tak mi reknete v cem je to realne lepsi, nez normalni inteligentni autorizace)

např. dokud nepošlete správnou sekvenci, vůbec netušíte že nějaká služba existuje, není zatěžován autorizační mechanismus ssh (výměna klíčů,…) – vše se řeší na hraničním fw.

Je to security through obscurity, ale aspon pak neni v /var/log/auth.log milion pokusu o vlamani se skrz ssh. Mozna to muze trochu zprehlednit logy…

Ž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?

těch pár sekund ale budete muset předstírat, že lezete z tý odemčený IP

… coz ve chvili kdy na ty siti muzete sniffovat nebude problem, ze…

Ale ochrani vas to pred naprostou vetsinou rutinniho skanovani a naslednych utoku.

>tak mi laskave ukazte nejaky „krabickovy“ firewall, ktery tohle podporuje

Jakýkoliv na kterém běží nějaký GNU(/Linux) systém, BSD a nebo vše jiného na čem je ta aplikace schopna běžet.

Tohle je druhá vrstva zabezpečení, stále tam přece budeš mít heslo/klíč k SSH. SPA je prostě „něco navíc“, další petlice na dveře. A určitě mi to přijde lepší než třeba měnit číslo portu.

Což jsem také speciálně napsal do článku, protože už minule se o tom vedly spory.

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

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?

Jenze firewall se napriklad s DDoS utokem popere mnohem lepe nez vase SSHcko. Kdyz vam zacnu floodovat port 22 a mate tam otevrene SSH, tak se vam pro kazde spojeni bude forkovat sshd proces coz bude server stat nejake resources a tech neni nekonecno.

a proti tomu stejnymu utoku na smtp nebo www se budete branit taky tim ze je defaultne pro vsechny zakazete?

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?

co nechapete na „(kteremu tedy opakuji verim vic)“ ?

pro ty mene chapave: kdyz mu verim vic nez tomu SPA bazmeku, tak to znamena ze ho mam otevreny

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)

vy to ale vůbec nechápete :(

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 autentifikaci­a/autorizacia je nezavisla na autentifikaci­i/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.

Je to tak. Opraveno, díky moc.

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 …“

Když už se začalo s rýpáním, tak přidám svojí trošku do mlýna :-)

Jde o autentikaci, žádná autentizace neexistuje.

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 – authentisierung

Více viz odkaz, kde najdete i vyjádření Ústavu pro jazyk český: http://interval.cz/…tentifikace/

Za nejobvyklejší považuji „autentizaci“*, nechci se nikoho dotknout, ale ty zbylé dva mi znějí jako patvary a zkomoleniny :-)

*) obvykle se mluví o autentizaci a autorizaci.

Autentikace? To taky někdo používá :D

Takže stačí, když někdo na trase takovému packetu změní source IP a bude mu otevřen přístup k tajným portům ;-)

Ne. Uvnitř toho zašifrovaného paketu je příkaz se žádostí o otevření konkrétního portu pro konkrétní počítač.

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.

Nestaci. Obsah paketu je sifrovany.

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.

+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.

Tím se ovšem vracíte zpět k port-knockingu… :)

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).

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)

Pokud se na zabezpeceny stroj pripojujes z internetove kavarny, tak nema cenu ani resit SPA, protoze daleko vetsi nebezpeci ti hrozi tim, ze se pripojujes z non-trusted procitace.

vládne všem…jeden jim všem káže !

Nechat taketo programiky kontrolovat firewall je super napad…uz staci len exploit, ktory otvori firewall a pusti tam netcat…uzasny napad. hlavne, ze je to cool :/