Názory k článku Port knocking: zaklepejte na svůj server
-
Firewall v Cechach se zepta serveru v Gronsku, ma-li nekomu povolit ssh port. Napriklad se jednou za minutu podiva, jestli tam nekdo nekam neulozil jednorazove heslo (nahodne smeti). Nebo se podiva, jestli tam neni soubor, zasifrovany „verejnym“ klicem, ktery ma k dispozici akorat uzivatel, dozadujici se pristupu. V tom souboru bude adresa stroje, odkud se uzivatel hodla pripojit a firewal mu z ni povoli spojeni na ssh ne urcitou dobu. Nebo tam bude fotka Radka Hulana se steganografickou zpravou, obsahujici jednorazove heslo a ip adresu.
-
Mam supertajny firewal na podzemni zakladne jadernych ponorek na Machove jezere. Potrebuji se na nej pripojit ze sve dovolene na Mysu dobre nadeje. Nahraji tedy do Gronska do adresare s 10000 jinymi blbymi fotografiemi fotografii Radka Hulana se steganografickou zpravou zasifrovanou verejnym klicem firewallu. Firewall se jednou za minutu podiva, jestli v Gronsku maji Radka Hulana. Pokud najde, tak stahne a pokusi se vyextrahovat skrytou zpravu a rozsifrovat ji svym privatnim klicem. Pokud se mu to povede a ve zprave najde ocekavany obsah, otevre mi na 10 minut ssh port pro adresu obsazenou ve zprave. Pokud se do te doby nepripojim, protoze me prave unesli teroristi dotovani CIA z fondu ziskanych z ilegalniho obchodu s narkotiky, port zase zavre.
P.S.: Pro pomale: Server v Gronsku nema port knocking ani nic podobneho. Muze to byt treba uplne nudny Windozestroj, nabizejici pres IIS primitivni stranky plne totalne nudnych fotografii, bez nejmensich umeleckych aspiraci, nesoucich znamky totalni technicke neschopnosti fotografa. Tedy server, kteremu se i otrly webovy cumil zdalky vyhne. -
Protoze: 1) Holubi nemaji dostatecnou odolnost proti mrazu. 2) Prestoze prumerna prenosova rychlost je, pri pouziti vysokokapacitnich sd karet pomerne slusna, latence je neunosne vysoka. 3) Prenos holubi postou je pomerne nespolehlivy: Vyskytuji se ztraty dat, zpusobene napriklad dravci nebo nenazranymi strelci. Nejsem si jist, co se tyce schopnosti holubu preletet ocean na jeden zatah. Pri UDP prenosu je pak nutno znovu vyslat paket vzdy po nekolika tydnech, nedojde-li ke kyzenemu vysledku, pri TCP prenosu je navic nutno dostatecne dlouho (dalsich nekolik tydnu) pockat, prijde-li SD karta s potvrzovacim paketem. Za techto okolnosti si to radsi s nekym vyridim po telefonu. 4) Je vyzadovana znacna ucast lidske obsluhy, i kdyz to by se snad dalo obstarat prenosem dat pres radio, nainstalovane v holubniku. 5) Mnou uvedeny priklad s ponorkovou zakladnou a Gronskem byla do nesmyslnosti vyhnana blbost pro milovniky spionaznich filmu. Podobny princip, akorat trochu mene pritazeny za vlasy, by se ovsem vyuzit dal. Treba jako varianta pro ty, kteri nemohou pouzit port knocking z nabozenskych duvodu nebo z duvodu jejich sexualni orientace. Nebo jako doplnek port knockingu pro paranoidni, po kterych jdou.
-
Miro (neregistrovaný)
A je to v běžné praxi použitelné? Moje představa je, že budu mít server, který bude naslouchat jen na portech 80 a 443. Přes https se přihlásím ke speciální straně, kde se autentizuji (heslem nebo certifikátem) a zároveň si vyberu port, který chci otevřít. Port se otevře jen pro adresu REMOTE_ADDR, ze které jsem se na stranu připojil.
Je tohle dobré řešení? Nemá to nějakou slabinu?
-
Lubosch (neregistrovaný)
Vzpominam si, ze podobne clanek tu uz byl pred nekolika letym, takze zadna novinka. A mam pocit, ze jak na lupe (rok 2004 http://www.lupa.cz/…rt-knocking/ ) tak na rootu. Ale proti tomu nic nemam. Dobre veci je dobre pripominat a kdyz to neni kazdy tyden tak proc ne. Taky se posunula doba, knockd je mozna dobre reseni a do commandu si vlastne muzu napsat cokoliv. Nicmene zasadni problem je v tom, ze stale neni „cim klepat“, minimalne z woken. Tj. dokud pro portknocking nebude podpora v POP3 a smtp klientech, nebo napr. v puttym tak je to jen hracicka. Ano, priznavam, ze tim se dostavam do Win sveta. V linuxech cim klepat je, z commandlajny. Ale ma podporu napriklad Thnderbirdu abych na tom mohl zalozit zvyseni bezpecnosti ve firme pro pristup napr. k SMTP? Ja o takove nevim :-( A to si myslim ze je to co portknockingu chybi.
-
webbrowserom?
http://server:port1
http://server:port2
http://server:port3a máme zaklopane…
(pre skúsenejších, vo windows je štandardne aj telnet)
-
Nemám pocit, že by sa „štandardne nie je“ vylučovalo s „dá sa doinštalovať“, alebo mu nejako inak oponovalo.
Dopísal som to sem iba, len a výlučne preto, lebo sa sa mi už veľakrát niekto sťažoval, že „hlúpa Vista nemá Telnet“.
Ak to pomôže čo i len 1 človeku v riešení čo i len 1 problému, aj tak dobre.Pekný deň.
-
. (neregistrovaný)
Bohužel nemáte pravdu. Pokud je něco standardně (defaultně), tak to znamená, že to tam je bez jakéhokoliv dalšího zásahu. S vaším překrouceným viděním bych mohl říct, že ve Windows je standardně raytracer, protože si můžu stáhnout Povray a doinstalovat ho tam. Nebo že ve většině Linuxových distribucí je standardně třeba WAPová brána, protože si při instalaci můžu zaškrtnout balíček Kannel. Kdyby toto vysvětlení otevřelo oči aspoň jednomu člověk, je to dobře.
-
laoce (neregistrovaný)
No ani tenthunderbird o ktory na zaciatku tohoto vlakna slo nie je standardne v vanilla Win7 installnuty :o). takze je to tu uz dost off topic. Ak tomu dobre rozumiem ide tu o pridanie funkcionality do thunderbirdu pri autentizacii na POP3 alebo SMTP. Aby sa pred nou este spustila nejaka utilitka (extena alebo interna - zpohladu thunderbirdu saamo) co by to klopanie urobila. Zial taku extenznu som nenasiel ;o(
-
misch (neregistrovaný)
To jako že třeba apache není standardní součástí většiny linuxových distribucí, protože aby se mi nainstaloval, musím zaškrtnout balíček „WEB server“? Mám se pořád co učit.
U těch Vist přece nešlo o to že by někdo musel googlem hledat odkud stáhnout telnet, instalovat kdoví jakou verzi, atd.. Vždyť stačí jen vlézt do ovládacích panelů a zaškrtnout že ho tam chci mít, ne?
-
. (neregistrovaný)
„Standardní součást“ je prostě to, co je výsledkem postupu další, další, další, dokončit. To, co má 99% lidí. Ne to, co lze DODATEČNÝMI kroky udělat. Evidentně se máte pořád co učit.
Perfektně by vás naučilo, kdybyste navrhoval systém, který budou používat stovky tisíc uživatelů na úrovni BFU. Pak přesně víte, že jakýkoliv NADSTANDARDNÍ krok 99% BFU prostě nedělá, nemají důvod.
A i u těch Vist je to přesně o tom, že k tomu, aby telnet součástí Windows byl, jsou třeba DODATEČNÉ kroky. Opakuji, že právě ta dodatečnost vylučuje standardnost.
-
JJ (neregistrovaný)
Bez Cywginu na Woknous nedam ani ranu…A pod odkazem http://www.zeroflux.org/projects/knock najdete i cygwin package pro klepani..
I kdyz, uznavam ze asi nema kazdy moznost Cygwinu.. -
HonzaCZ (neregistrovaný)
http://www.zeroflux.org/projects/knock
http://www.zeroflux.org/…ck-win32.zipi se zdrojákama, stačí hledat, vy klepači ;-)
-
Jiří J. (neregistrovaný)
Tak tak, už nějakou dobu vím o http://sourceforge.net/…/knockknock/
-
BLEK. (neregistrovaný)
Takové technika jako port knocking ti funguje právě jen tehdy, dokud ji většina lidí nepoužívá. Říká se tomu security through obscurity.
Kdyby se rozšířila, tak si různé sniffery začnou sekvence portů a RST packetů zaznamenávat a bezpečností se to dostane na úroveň nešifrovaného spojení s heslem.
-
Pán Krčmář, ak Vás zaujíma trocha rozvinutie problematiky skrytých kanálov, tak mrknite na http://www.krutibrko.sk/…paper_41.pdf.
Nájdete tam jednu peknú vec. :-)
Pekný deň.
-
BLEK. (neregistrovaný)
Technika popsaná v článku žádný covert-channel není. Dá se to triviálně detekovat, tak, že urgent pointer není nula nebo že id čísla nejsou sekvenční (což Linux dělá).
Spíš by měli ta tajná data cpát do timestampu a do syn čísla u nově vytvořených spojení, pak to tak snadno detekovat nepůjde.
-
Pri mobilnom pripojení Orange 3g to fungovať nebude – nedávno som riešil s ich supportom, prečo mi nejde teredo. Záver: sieť je NATovaná cez niekoľko routerov s rôznymi verejnými IP adresami, a odchádzajúce spojenie (alebo UDP packet) ide cez náhodný z nich. Záver: „budú to riešiť“. Čakal som, že mi akože zadarmo ponúknu verejnú IP adresu, keďže chyba je na ich strane, adresu mi ponúkli, ale za štandardný poplatok…
-
Já nějak nechápu smysl těchto fíglů. Jsem asi trochu oldschool, ale mám prostě pocit, že port je místo, na který se připojím, potom jsou ověřena moje oprávnění a potom můžu službu používat.
Pokud mi vadí, že mě na standardním portu pořád otravují boti, nebo se bojím, že by služba mohla být děravá, přesunu ji na jiný port, o kterém vím jenom já.
Technika popsaná v článku prostě přidává jakoby „další heslo navíc“ – principielně je efekt úplně stejnej jako při přesunu na nějaký vysoký port (akorátže to „heslo“ je v tomhle případě delší – sekvence místo jednoho čísla) – přináší to ale reálně nějaké zvýšení bezpečnosti?
A když už chci teda port před někým maskovat a použít další heslo navíc, není daleko čistší a efektivnější použít třeba přihlášení na webové stránce a otevření portu poté?
-
Honza (neregistrovaný)
Pokud to chápu správně – kdybych hledal port, na kterém běží služba, na kterou chci útočit – musím zjistit, které porty jsou ochotny si se mnou povídat. Takto mlčí i port, na kterém ona služba je – navenek je stroj mrtvý, ale oživím jej právě oním zaťukáním na ty správné porty.
Výsledek – zatím co v případě prvním zjistím port a pak už jen řeším, jak nejlépe zaútočit, v případě druhém proklepnu všechny porty a zjistím, že nemám kam útočit, protože stroj je tuhý a nereaguje.
Náhodné vyťukání je možné, ale nepravděpodobné…
Defakto mi to připomíná situaci, kdy si zavolám kamarádovi, aby mi otevřel port na svém PC, abych k němu mohl nakouknout – akorát bez nutnosti telefonu a kamaráda u toho PC.
-
Ano, to je pravda. Mně ale není jasné, proti komu je vlastně toto opatření zaměřeno.
Stejného efektu bych totiž dosáhl tak, že bych před samotným SSH spojením poslal na jeho port jedno heslo navíc – a teprve podle něj by začal/nezačal SSH protokol. A aby to bylo ještě peprnější, to první heslo posílám nezašifrovaně, takže ho může kdokoli odposlechnout :)
Jinými slovy – hodně podobného efektu dosáhnu, když pro SSH zvolím heslo dlouhé jako součet délek těch dvou hesel…
Možnost s „vyťukáváním“ jednotlivých bytů nějaké zprávy mi už přijde úplně ulítlá – jaký je rozdíl třeba oproti použití UDP?
-
V případě UDP a firewallu, který packety na neplatný porty zahazuje, žádné rozlišení otevřený/zavřený port neexistuje.
V případě TCP je to tak, jak jsem napsal – abych dosáhl stejného efektu, stačí mi předřadit wrapper, který povolí přístup ke službě jen když dostane správné heslo. Když zadám heslo špatné, tak je port jakoby taky „zavřený“, protože k té službě se prostě nedostanu.
Jemné rozdíly jsou samozřejmě z pohledu nebezpečí DOS apod. – ale vzhledem k tomu, že knockd musí nějak evidovat přístup na porty taky, nevím, kde je ten nárůst bezpečnosti.
Je to asi tak, jako když přijdu k domu, kde jsou všechny dveře zavřené a mám domluveno, že klepnu třikrát na první, dvakrát na druhé a pak mi třetí otevře vrátný a když se mu prokážu občankou, pustí mě dovnitř.
Nechápu, jaký je rozdíl v bezpečnosti oproti klasické situaci, kdy jsou první i druhé dveře zavřené a hluché a třetí sice otevřené a stojí v nich vrátný, ale za ním jsou ještě dveře pancířové, které mi otevře jen když předložím občanku…
-
Jenže ta „občanka“ (tj. ssh autentizace heslem nebo certifikátem) je podstatně silnější než ten tajný klepací kód. Kdo umí vyrobit falešnou občanku, toho nějaké klepání na dlouho nezastaví…
Jinými slovy, je to prostě jedna vrstva autentizace navíc – tj. (opakuju) je to stejné jako bych měl firewall, který nechtěné UDP zahazuje a na jednom UDP portu chytá heslo… Popsané řešení nepřináší imho NIC navíc oproti tomuhle řešení, které je podstatně jednodušší.
-
Jiří J. (neregistrovaný)
Tak nějak to osobně vidím já v případě použití knockd jako univerzálního auth řešení (zmíněný range 256 portů a třeba asymetrický klíč s timestamp, …).
Port knocking vidím jako skvělou obranu proti DoS u služeb jako SSH. Proto používám sekvenci 3–5 portů a jednoduchý knock. Skript na serveru mi každý týden generuje novou sekvenci na další týden, kterou si syncnu s notebookem (tzn. mám týden na sync, abych se další týden připojil) – čistě pro případ, že by to snad někdo odposlouchával.
V případě odposlechu může totiž přinejhorším „útočník“ získat přístup na port SSH, pořád tam má před sebou key-based auth, kterou asi za ten týden neprolomí. Když tedy pominu, že možnost takového odposlechu je pod 1%.
V mých očích je port knocking JEN obscurity-based řešení, tedy vhodný doplněk běžného zabezpečení, který by měl zůstat jednoduchý v principu. Jakmile totiž útočník zjistí, že někdo „klepal“ (systematicky posílal data na zavřené porty), ihned ví, že daný range monitoruje nějaký daemon a že jakýkoli packet v něm je jistým způsobem (ideálně v userspace) zpracován. A (D)DoS je na světě.
Vím, existují chyby v SSH serverech, stejně tak se značně zvyšuje pravděpodobnost výskytu bugu v knockd, pokud tam někdo začne cpát věci jako RSA. Opět – pokud někdo potřebuje dodatečný security layer mezi službou a port-knock mechanismem, ať si tam strčí nějakou proxy nebo podobné řešení, ale proboha, ať nedělá z jednoduchého klepání orchestr :)
PS ještě k původnímu postu: Jde o to, že při zadání „hesla“ už útočník ví, že na tom portu něco naslouchá a může tomu cpát tuny packetů, které se dostanou do userspace. Naproti tomu knockd může naslouchat třeba na 5 tajných portech a zahazování na všech ostatních obstarává kernel (vlastně to i na těch 5, sk_buff se jen zkopíruje pro knockd, podobně jako u tcpdump), takže při (D)DoS je zátěž CPU daleko menší. Kapacita linky už je další věcí.
U webserveru by to bylo celkem jedno, ale u firemního routeru, u kterého nejsou potřeba žádné veřejně přístupné služby, se to docela hodí.
Nutno podotknout, že současná verze knockd, založená na knihovně pcap, tohle asi nebude umět, a tak se všechny přijaté packety zkopírují pro userspace, ale to je problém implementace.Nicméně hlavním bonusem zůstává to, že útočník neví, zda vůbec něco na nějakých portech naslouchá.
-
Jiří J. (neregistrovaný)
eer, pletu se – knockd používá pcap, jehož filter sahá přímo na BPF ( http://en.wikipedia.org/…acket_Filter ), a k sestavení filteru používá relativně komplikovanou funkci generate_pcap_filter() (pro podrobnosti vizte zdrojový kód – http://www.zeroflux.org/projects/knock source tarball), tudíž zbytečným kopiím je skutečně zabráněno.
Z dokumentace pcapu:
The process is quite simple. After we have already called pcap_open_live() and have a working sniffing session, we can apply our filter. Why not just use our own if/else if statements? Two reasons. First, pcap's filter is far more efficient, because it does it directly with the BPF filter; we eliminate numerous steps by having the BPF driver do it directly. Second, this is a lot easier :) -
Ash (neregistrovaný)
Je to asi tak, jako když přijdu k domu, kde jsou všechny dveře zavřené a mám domluveno, že klepnu třikrát na první, dvakrát na druhé a pak mi třetí otevře vrátný a když se mu prokážu občankou, pustí mě dovnitř.
Nechápu, jaký je rozdíl v bezpečnosti oproti klasické situaci, kdy jsou první i druhé dveře zavřené a hluché a třetí sice otevřené a stojí v nich vrátný, ale za ním jsou ještě dveře pancířové, které mi otevře jen když předložím občanku
Nechápete rozdíl mezi pancířovými dveřmi na občanku, a pancířovými dveřmi na občanku o kterých nevíte? Nezapomínejte že v prvním případě jsou dveře také pancířové, port-knocking nějak nesnižuje zabazpečnení dveří (démona) jako takového.
-
pht (neregistrovaný)
Rozdíl je zcela zásadní – pro port-knocking mohou být (jsou) porty zavřené, nikoliv otevřené. A na zavřený port se nedá připojit, nedá se zaútočit na službu která na něm (ne)běží. V tom je ten rozdíl.
Právěže dá. A tenhle démon jen přináší další level, kde může být nebezpečný kód, přinejhorším vedoucí k tomu, že se tím sshd nebude muset útočník vůbec zabývat.
-
proto bych to resil primo v iptables, coz uz je davno popsano, ne dalsim deamonem, napr:
-A INPUT -m state –state NEW -p tcp -m tcp –dport 22 –tcp-flags SYN,RST,ACK SYN -m recent –check –seconds 60 –name SSH_ALLOW -j ACCEPT
-A INPUT -m state –state NEW -p tcp -m tcp –dport 123 –tcp-flags SYN,RST,ACK SYN -m recent –set –name SSH_FIRST -j DROP
-A INPUT -m state –state NEW -p tcp -m tcp –dport 234 –tcp-flags SYN,RST,ACK SYN -m recent –check –seconds 10 –rttl –name SSH_FIRST -j SSH_SECOND
-A SSH_SECOND –tcp-flags SYN,RST,ACK SYN -m recent –set –name SSH_SECOND
-A SSH_SECOND –tcp-flags SYN,RST,ACK SYN -m recent –remove –name SSH_FIRST
-A SSH_SECOND -j DROP-A INPUT -m state –state NEW -p tcp -m tcp –dport 345 –tcp-flags SYN,RST,ACK SYN -m recent –check –seconds 10 –rttl –name SSH_SECOND -j SSH_THIRD
-A SSH_THIRD –tcp-flags SYN,RST,ACK SYN -m recent –set –name SSH_THIRD
-A SSH_THIRD –tcp-flags SYN,RST,ACK SYN -m recent –remove –name SSH_SECOND
-A SSH_THIRD -j DROP-A INPUT -m state –state NEW -p tcp -m tcp –dport 456 –tcp-flags SYN,RST,ACK SYN -m recent –check –seconds 10 –rttl –name SSH_THIRD -j SSH_FOURTH
-A SSH_FOURTH –tcp-flags SYN,RST,ACK SYN -m recent –set –name SSH_ALLOW
-A SSH_FOURTH –tcp-flags SYN,RST,ACK SYN -m recent –remove –name SSH_THIRD
-A SSH_FOURTH -j DROP( rychle vygooglovano – http://uhacc.org/…ms/index.php?…)
-
Ash (neregistrovaný)
Je to asi jako přidat k bitevníku ještě neviditelnost. Sice když nepřítel ví, kde bitevník je, zneškodní ho stejně jako viditelný bitevník, ale když o něm nepřítel neví, je to jakási výhoda navíc. Někdy to nepomůže, ale nikdy to neublíží. Snad jen někdy můžete mít problém ten svůj bitevník najít, ale to už není věc bezpečnosti ale dostupnosti služby :)
-
fo (neregistrovaný)
PK nie je „metoda“, ktoru ma zmysel pouzivat neustale pri kazdom/beznom prihlasovani (na to vieme pouzit ine „metody“ a formy prihlasovania, ktore uz boli spomenute nizsie). Poita PK je v tom, aby sa pouzil len vtedy, kedy je to ako jedno z najvhodnejsich rieseni. Najcastejsie PK nasadzujeme v tomto pripade: niektori z adminov ide na dovolenku a kedze ide dovolenkovat tak si neberie pracovny notebook s mobilnym internetom. Ak nahodou nastane vazny problem, ze je potrebne aby sa na to vzdialene pozrel, tak ma moznost vyuzit prave PK. Dost casto v mieste dovolenkovania sa najde nejake inet cafe apod. Kazdy ma predgenerovanu sekvenciu portov na „otukanie“, ktoru si definoval vacsinou na zaklade nejakeho svojho „algoritmu“ (napr. nejaka geo rada:). Potom je jedno do akeho nezabezpeceneho inet cafe s osekanym hacknutym windowsom pride, staci ze si spusti z webu putty, vykona jednorazovu tukaciu sekvenciu a nasledne sa prihlasi cez SSH na jeden z nasich virtualnych strojov, ktory sluzi cisto pre ucely PK a prihlasovania sa dalej pomocou klucov s passfrazou. Po prihlaseni na stroj s PK staci ze pocka definovanu dobu, nez port prestane prijimat SYN connecty a moze sa zacat prihlasovat dalej. Ak spojenie nahodou spadne (_predtym_ nez zadal passfrazu na kluc pre prihlasenie dalej na servery), tak to moze skusit znovu (novou sekvenciou) atd. Ak nahodou ale spojenie spadne az po tom, co uz bola zadana passfraza, tak z toho inet cafe sa uz neprihlasuje (logicky na tej stanici mu uz mohli byt odchytene login/pass a pass k passfrazi,takze jedine co uz stoji potencialnemu utocnikovi v ceste je otvorenie portu pre SSH vytukanim sekvencie). Za poslednych 6 rokov sa to sice vyuzilo asi len 2×, ale pomohlo to:). A ak by niekoho napadlo, ze si donesiem kluc na USB a pod. tak uz sme zazili inet cafe, kde bol skript nastaveny tak, ze pokial sa detekla jednotka z usb, tak sa automaticky z nej zacali skopirovavat data (tymto sa uz hraju deti na zakladnych skolach:), takze staci uz len keylogger.....
