Názory k článku
Port knocking: zaklepejte na svůj server

Taky jsem si dělal něco podobného, ale přes HTTPS přihlášení na určité webové stránce. Pak se mi otevřel port na minutu a mohl jsem se přihlásit.
Každopádně port knocking je zajímavé řešení :-)

To musi byt super kdyz ti zuchne apache a ty se chces prez ssh podivat co se deje :)

Tak si pres ssh restartuje Apache a po ptakach. Dulezite je, ze super tajny server zustane bezpecny. Jinak by nebyl problem, aby takovych stranek mel vic, kdyby jedna lehla. Nahodou, celkem chytry napad.

Pokud Apache a ssh bezi na stejnem stroji, tak samozrejme ne. Ale ssh muze bezet na firewallu v Cechach, zatimco Apache na nejakem nedulezitem stroji v Gronsku.

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.

Je problem mit zalozni server v Iranu, pro pripad, ze by Gronsko postihl osud Atlantidy? A dalsi v Australii, kdyby USA vybombardovaly I­ran?

to mam rad, ked niekto vymysli vtakovinu a potom za kazdu cenu sa jej bude drzat… preco server v gronsku nevypusti postoveho holuba, ktory vypne v cechach firewall ?

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.

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?

A co to vlastně má přinést? Jediné, před čím mě to ochrání, je bug v autentizaci nějaké služby, kterou za takovouhle ochranu umístím. A platím za to nepříjemným zesložitěním autentizace.

Nepřijde mi to jako moc zajímavý poměr cena/výkon...

Neznal jsem. Díky za článek, vypadá to na moc pěknou utilitku.

Co kdyz se do nasi sekvence priplete nahodne nekdo dalsi? Dostaneme se tam potom vubec?

imho ta sekvence musi jit z jedne IP adresy, jinak by to asi nemelo moc smysl:)

Hej, len treba davat pozor na NAT, pokial sa s niekym o public adresu delis.

Je to podle IPcka, takze kdyz se do toho priplete nekdo z jineho IPcka, tak je to jedno. A pokud z tveho IPcka prijde spravna sekvence pristupu na porty, tak z toho IP ziskas pristup k pres firewall k nejake sluzbe.

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 chy­bi.

pre ještě skúsenejších – vo Windows od dob Visty telnet štandardne nieje.

A pro nejzkušenější lekce slovenštiny: reč bola o „štandardu“, nie o možnosti dodatočne doinštalovať.

Je ostuda, že lekci slovenštiny musí dávat Čech jako poleno.

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.

Ale ty soucasti systemu v Longhornech defaultne jsou. Jen je treba je nasymlinkovat do systemu pomoci pkgmgr, nebo noveji dism.

Nainstalujte „standardní“ instalaci Visty nebo W7, tzn. s výchozími volbami. Pak se podívejte, zda tam ten telnet mít budete. Pokud ano, je to standardní součást instalace. Pokud ne a budete muset dělal dodatečné kroky, pak to standardní součást prostě není.

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(

Hasismarja, to dneska Widle uz umi opovrhovane symlinky nebo co? Svet je naruby, nic jiz neni, jako drive!

Widle umi symlinky od te doby co je v nich NTFS, tedy nekdy od dob NT4.

Myslite hardlinky? Symlinky umi snad teprve az Vista, od tusim W2k to umi junctions nebo jak se to, coz je neco, jako simlink, ale jenom pro adresare. Navic v tech Widlich nebyl zadny nastroj, ktery by ty hardlinky dokazal vytvorit. Doufejme, ze Vista uz neco ma.

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?

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

klid zbraní hoši ne?

plníte tu prostor hádáním o slovních pičovinkách

to je sranda, diskusia o portknockingu sa zvrhla o to ze ci BFU vie nainstalovat do Vist telnet :-) :-)
*
ked ten BFU bude vyuzivat portknocking tak si ten telnet do Windoze nahodi, a hop uz to nebude BFU…

Spatna rada, kdyz nekdo potrebuje telnet, doinstaluje PuTTY.

A pro jeste zkusenejsich: telnet ve Widlich stoji za …, pokud s tim teda ve Widle Vista neco neudelali.

no tak to ide s nimi dolu vodou… ešte že od doby win2000 s nimi nemusím mať veľa spoločného :-) Nie je ale lepšie urobiť jednoduchý cgi script, kde sa užívateľ autentifikuje, napíše port a script povolí prístup cez iptables na určenú dobu? Uvažujem o implementácii niečoho takého pre naše siete…

No ono by se docela složitě webbrowserem klepalo šifrovaně ;-)

Pravda, ja som mal na mysli nešifrované.

Aleaj šifrované sa dá… trocha javascriptu, alebo cgi na trusted server, ktorý do stránky vygeneruje zoznam url, na ktoré treba v danom poradí kliknúť…

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

http://www.zeroflux.org/projects/knock
http://www.zeroflux.org/…ck-win32.zip

i se zdrojákama, stačí hledat, vy klepači ;-)

Tak tak, už nějakou dobu vím o http://sourceforge.net/…/knockknock/

Kdo ti brani ve windoze udelat tohle telnet host port ?

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.

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.

Dle definice to covert channel je, ale dost mizerný.

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…

Nezkousel jste nekdo upravit daemona, aby pouzival nejenom iptables ale i ip6tables a jak to funguje?

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

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?

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.

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…

Ze by to pridalo zabezpeceni pro pripad, ze se nekdo dostavi a bude se prokazovat zfalsovanou obcankou na vase jmeno?

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šší.

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

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_fil­ter() (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 :)

V případě UDP a firewallu, který packety na neplatný porty zahazuje, žádné rozlišení otevřený/zavřený port neexistuje.

Neplatné porty na kterých pakety zahazuje FW = zavřené porty. Platné porty na kterých může něco komunikovat = otevřené porty.

>> Neplatné porty na kterých pakety zahazuje FW = zavřené porty. Platné porty na kterých může něco komunikovat = otevřené porty.

Ovšem zvenku vypadaji oba stejne, utocnik nemuze nijak zjistit, jestli tam nekdo posloucha nebo ne.

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.

Ještě pro upřesnení, v druhém případě jsou hluché všechny troje dveře (dokud správně nezaklepete).

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.

Ovšem je to pořád ještě port-knocking. Nikdo neříká že port-knocking je „démon který to dělá“. Je to mechanismus, jestli ho zajistíte pomocí knockd, iptables, nebo pomocí _my_c00l_fw_ je úplně jedno.

Myslel jsem že se ve finále dostanem k SPA…

Jo, to už je trochu rozumnější, ale stejně mně to přijde principielně pochybený ;)

Port knocking je urcite zaujimavy, no nemozem sa zbavit pocitu ze je to len workaround. V sietovani sa moc nevyznam, takze ma prosim poucte. Nie su taketo riesenia len potvrdenim toho ze existujuci bezpecnostny koncept narazil na svoje hranice?

Taketo riesenia slouzi k tomu, aby skrylo sluzby bezici na serveru pred clovekem, ktery prijde a udela portscan. Bezpecnostni mechanismy zustavaji stejne, port knocking jen zajisti, ze server kazdemu na potkani nevytroubi ktere potencialne nebezpecne sluzby na nem bezi.

+1 Dakujem za vysvetlenie.

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

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

a kto povedal, ze neexistuje nudzova sekvencia zlozena z 80 a 443 ? :)

Není mnohem jednodušší (a i bezpečnější) nahodit mu na SSH autentizaci jednorázovým heslem, než dělat takovéhle šaškárny?