Mezinárodní nezisková organizace Women Who Code (WWCode, Wikipedie) založena v roce 2011 s cílem usnadnit ženám vstup do světa informačních technologií nečekaně skončila. Došly finance.
DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
Přečetl jsem si řadu zdejších diskuzí na téma účtu root, ssh, povolení rootovi přihlásit se atd. Nejinspirativnější byla diskuze Michal Kubeček vs. Azurit. Michal Kubeček razil cestu nejmenšího odporu s co největším teoretickým výdělkem. Tedy, že nejúčinější cesta, jak zvýšit bezpečnost serveru není vícestupňové přihlšování se zakázaným přímým loginem na roota, ale zvýšení délky hesla z N na N+1 znaků. Azurit na proti tomu oponoval, že samotná filozofie vícestupňové bezpečnosti je lepší než filozofie jednosttupňové. Tedy, že když zlepšení tak user s heslem N+1, root s heslem N+1. Celá diskuze ze poněkud zvrtla v přihazování +1 na všechny hromady, ale něco zajímavého jsem si odnesl...
Je nepochybně "efektivnější" proti obecnému bruteforce útoku, zvýšit délku hesla roota na N+1, než zakázat rootův login s heslem o délce N a zavedení userova loginu s heslem o délce N. V tom má pan Kubeček pravdu. Lze se na to ovšem dívat takto stritkně matematicky? Platí takováto hezká kombinatorika? Něco mi říká, že neplatí a že ten Azurit může mít v lecčems pravdu.
Ve zmiňované diskuzi popisuje uživatel, že přestěhování portu ssh ho zbavilo všech cizích loginů, které se k němu do té doby dobývaly. Jednalo se nepochybně o automaty. Ale jaký je například poměr mezi automaty a skutečnými osobami? Co když je to třeba 200:1. Jestliže je možných znaků 64 a přidání +1 k heslu zvedne bezpečnost hesla 64x (doufám že to říkám správně) pak přestěhování portu ssh zvede v tomto případě bezpečnost 200x. To ovšem pouze za předpokladu, že nebezpečnost každého útočníka je stejná. Tento příklad mě vede k domněnce, že jakákoli anomálie ,může vést k vyšší bezpečnosti, než jak ji logicky vykládá N+1 kombinatorika, a to právě proto, že nejvíce útoků probíhá na zaběhaná místa a podle zaběhaných schémat. Nebo i toto lze nějak exaktně spočítat a změřit? Jeden přístup je, že prodlužováním hesla zvyšujeme bezpečnost útoku. Proč by ale ty účinné metody, které snižují počet útočníků měly být špatné nebo neefektivní? Jen se tak ptám...
Tiskni
Sdílej:
7.1.2009 22:18
Michal Fecko | skóre: 31
| blog: Poznámkový blog
to boli vlakna, panecku...
to vlákno je fakt inspirativní. Ale pořád nemůžu přijít na to, jak může být striktní kombinatorika aplikovatelná na problém tohoto typu.
7.1.2009 22:32
Michal Fecko | skóre: 31
| blog: Poznámkový blog
pár matfyzáků znám. Zjednodušeně řečeno, 80% z nich si neumí zavázat ani tkaničku, ale hlavně že ví co je reziduum funkce a zná na toto téma nejméně 20 vtipů.
Ale to samozřejmě platí i na jíné osoby podobného zaměření z jiných ústavů
Zjednodušeně řečeno, 80% z nich si neumí zavázat ani tkaničku,Zjevně si zvolil špatný statistický vzorek.
Já myslím že nikoli. Většina těch lidí je tak trošku "mimo". Tím neříkám, že jsou horší nebo lepší. Ale jsou prostě jiní. I takové společnost potřebuje, ale na pivo bych s nimi nešel. A že jsem to párkrát udělal, vím o čem mluvím.
To uznávám. Ovšem za přepokladu, že nejsi stejný "mimoň" jako těch zmiňovaných 80% matfyzáků, což nemohu posoudit. V tom případě by tvé dobrozdání bylo irelevantní. Ale myslím, že toto téma můžeme ukončit. nic proti Matfyzákům nemám.
7.1.2009 22:52
Michal Fecko | skóre: 31
| blog: Poznámkový blog
pripomenulo mi to IT Crowd Season 3 Episode 2 "Are We Not Men?"I takové společnost potřebuje, ale na pivo bych s nimi nešel. A že jsem to párkrát udělal, vím o čem mluvím.
7.1.2009 22:53
Michal Fecko | skóre: 31
| blog: Poznámkový blog
včetně všech obezliček zařazovaných do kategorie security by obscurity.Myslíš hned tu první co si vyjmenoval?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ssh uzivatel@server, tak bych si tam dopsal ještě parametr pro číslo portu. Uživatelé Putty to mají taky snadné. Tady bych problém vážně neviděl.
Ono je mozne si takovehle "aliasy" napsat do configu sshcka a lze tam sachovet vlastne se vsemi parametry. Pouzivam to leta a je to velmi uzitecne.
ssh s nějakým parametrem, ne? To mi takový třípísmenný alias v shellu přijde kratší
Ne ne, zadny specialni parametr, definuje se to pres jmeno:
Host mujserver
User ladicek
Compression yes
Cipher blowfish
HostName nejaka.adresa
Port 12345
8.1.2009 18:18
xkucf03 | skóre: 49
| blog: xkucf03
Změna čísla portu mi přijde smysluplná snad jen pro případ, že bys chtěl rozlišit mezi neškodnými* lamami, které spustili jednoduchého robota, a pokročilejšími útočníky a proti těm pak nějak zakročit (jak?). Pokud ale žádná odvetná opatření neplánuješ, znamená to prakticky jen snížení počtu záznamů v logách, nikoli nějaký reálný přínos pro bezpečnost. Ten, kdo není schopný ti proskenovat i jiné porty než 22, tě sotva bude schopný hacknout.
Pak je ještě možné nastavit firewall tak, že ze známých IP adres bude přijímat i na 22 a když se budeš potřebovat připojit odjinud, použiješ jiný domluvený port. Dají se vymyslet i jiná vylepšení: třeba poslání SMSky s kódem a IP adresou, pomocí které si na firewallu otevřeš port pro danou nestandardní IP adresu. Ale to jsou jen hračky navíc – základ (technické stránky) bezpečnosti by měl stát na aktualizovaném softwaru a silných heslech nebo klíčích.
Změna portu se uživatelů dotkne: je to otrava zadávat nestandardní číslo portu a nebo si ho musíš dát do konfiguráku. Uživatelé, kteří se připojují z různých míst a méně často, na to pak budou zapomínat a divit se, proč jim to nejde. A efektem je vlastně jen to, že jsi odfiltroval neškodná skript-kiddie.
Užitečnější mi přijde zákaz přímého přihlášení roota – např. při více správcích můžeš z logů poznat, kdo se kdy na roota přepnul.
*) za předpokladu, že nemáš slovníková nebo příliš jednoduchá hesla.
znamená to prakticky jen snížení počtu záznamů v logáchNení to pozitivní? Čím víc nezávažných záznamů v logu, tím větší riziko, že přehlédnu nějaký závažný.
8.1.2009 19:06
Jakub Lucký | skóre: 40
| Praha
8.1.2009 19:39
Jakub Lucký | skóre: 40
| Praha
8.1.2009 19:40
xkucf03 | skóre: 49
| blog: xkucf03
když se o ten systém bude hezky starat, třeba bude pouštět aptitude upgrade častěji než skutečný správce
8.1.2009 19:38
xkucf03 | skóre: 49
| blog: xkucf03
Je, ale ty logy si můžeš grepnout nebo nasměrovat jinam, aniž by to mělo dopad na uživatele, kteří musí používat nestandardní porty. Navíc pokud používáš nějaký nástroj pro analýzu logů, tak si můžeš tyhle záznamy odfiltrovat jako nezajímavé. Kromě toho: v předchozí diskusi bylo pár lidí se zájmem o kombinatoriku a ti by ti jistě vypočítali, že nestandardní port zvýší bezpečnost naprosto zanedbatelně oproti prodloužení hesla o jeden znak
8.1.2009 19:52
Jakub Lucký | skóre: 40
| Praha
že nestandardní port zvýší bezpečnost naprosto zanedbatelněAsi tak o minutu
8.1.2009 20:03
xkucf03 | skóre: 49
| blog: xkucf03
No, co kdyby během té minuty vydali bezpečnostní záplatu
8.1.2009 20:59
Jakub Lucký | skóre: 40
| Praha
Pokud mohu prispet svou trochou do mlyna, pridal bych tento duvod proc vyuzivam prihlaseni na non-root usera a pak su na roota. Prihlaseni na non-root usera zanecha stopu v logach s oznacenim uzivatele, ktery se prihlasil. Coz muze byt uzitecne pokud server spravuje >1 user. Lze potom napriklad dohledat ci heslo je kompromitovane, coz musim priznat ze je castejsi nez prunik prez exploit.
Hmmm, kdyz jsme menili hesla roota po odchodu predchoziho spravce, tak jsem myslel, ze ho vubec nebudu pouzivat. Ale bohuzel, minimalne pri instalaci ho potrebuju a pak je obcas potreba proste neco kopirovat (rsync, scp), co pod obyc userem nejde (nejsou prava). Takze root heslo si pamatuju, ale samozrejme pouzivam ho minimalne.
Když už se to tu zmiňuje, přidám i já svojí trošku do mlýna. Mně docela vyhovuje přihlašování pomocí klíče přímo na roota. A pokud by chtěl být člověk důsledný, tak klíč uložený na nějaké smartkartě a je to...
Velká výhoda je, že je možné pracovat jako root třeba i přes sftp a tak - někdo to může samozřejmě považovat za nevýhodu, ale pro mně je to pohodlné editování konfiguráků z editoru na normálním PC téměř bez námahy a velmi solidně zabezpečené...
8.1.2009 01:09
Jakub Lucký | skóre: 40
| Praha
To bude zase flame 
Jinak, jiny port si nemusite pamatovat, mate ~/.ssh/config a tam si to napisete. Jeste sikovnejsi ale je port nikam nestehovat, ale proste povolit prihlaseni na server ze svych znamych IP adres.
Prihlaseni na verejne viditelnou masinu, kde se nedaji omezit IP adresy, jednoznacne jen certifikatem/klicem. Jak uzivatelum povolite hesla, nikdy neuhlidate, jestli jsou dostatecne silna a neprolomitelna.
A nikdy nezakazovat prime prihlaseni na roota, stroj se snadno dostane do stavu, kdyz neni mozne prihlaseni bezneho uzivatele a nebo potrebujete posilat prikazy i na stroj, ktery je napul padly a uz na nej nejde pustit shell. I na takovy stroj dokazete poslat neco do /proc/sysrq-trigger nebo spustit nejaky killall. Jakmile zakazete prihlaseni na roota, budete mit mnohem delsi vypadky, vice vyjezdu ke strojum, ktere nemaji remote management. Kdo se na stroj prihlasoval poznate podle IP adresy a nebo jsou patche do ssh, ktere loguji jaky klic byl pouzit pro prihlaseni. Sudo je fajn pro delegaci pravomoci pri bezne udrzbe, ale v krizi kdy musite dostat stroj co nejdrive zpet do provozu potrebujete roota bez nejakych obezlicek. Nehlede na to, ze u sudo si musite pamatovat heslo, nejde to automatizovat. Kdyz uz se to musi udelat dvoustupnove, je lepsi jit na uzivatele a pod nim udelat s povolenym forwardem klicu ssh root@localhost a pro roota mit omezeni prihlaseni na localhost.
No, víte, jestli se nemýlím, některé z těch zámků fungují jen na základě určitých okolností, to potom... jaksi... bychom tady mohli být celé roky...“ odvážil se. „Předpokládejme třeba, že by je mohlo otevřít jen malé světlovlasé dítě, které drží v ruce myš? V úterý? A jen když prší?“ Terry Pratchett, OTEC PRASÁTEK
ssh -- pokud máte tak slabé heslo, že se bojíte útoku nějakého automatu, přesunutí na jiný port to nezachrání; není nic snazšího, než nechat automat skenovat všechny porty, stroji je to jedno. Pokud naopak věříte, že máte dostatečně silné heslo, aby odolalo útokům automatů zkoušejících slovníková hesla, je přesun na jiný port z hlediska tohoto problému irelevantní -- bezpečnost ani nezvýší, ani nesníží. Otázka pak je, zda něco ospravedlní nižší komfort způsobený nestandardním portem -- někdo pro to může mít jiné důvody (třeba má nerad, když se mu plní logy a nechce to řešit jinak), jiný pro to žádný důvod nenajde.
Otázka pak je, zda se přesouváním na jiný port a zakazováním přihlášení na roota administrátor nevyčerpá natolik, že už neudělá žádná pořádná opatření. Zajímavé je, že když si někdo představí buldozer (crackera) jedoucí proti betonovému zátarasu (silné heslo), nikoho nenapadne házet mu napínáčky do cesty -- ať před zátaras, nebo za něj. Každý bude řešit dvě věci -- buď jak postavit ještě jeden stejně masivní zátaras (který jeho postup alespoň zpomalí), jak udělat nějaký ještě masivnější zátaras -- a také zda buldozer nemůže zátaras někudy objet. U počítačové bezpečnosti ale rozhazování napínáčků považuje spousta lidí za celkem dobrý nápad, jehož promýšlením a realizací se rozhodně nic neztratí...
Vy ovšem apriori přepokládáte, že s dostatečně silným heslem se to nikdy žádnému automatu nepovede. Jistě máte v 99.99% pravdu. Ale v tom případě doufám, že jste nikdy nesázel sportku, šťastných deset, nekupoval lístek do tomboly a vůbec nikdy se nic nepokoušel vyhrát. Protože z vašeho pohledu je výhra v loterii nemožná, a jakákoli snaha o ni naprosto stupidní.
To je pravda. Takže jste si nikdy nevsadil a nikdy nezkoušel zda vyhrajete?
A to jsme pořád jenom u kompromitaci hrubou silou. Proč si nechcete připustit, že stát se může i něco jiného? Mnohdy i to, co nemůžete ovlivnit, ani kdyby jste byl neomylný, což stejně nejste?
Jenže pokud obranná funkce hesla selže, ty vaše výpočty si můžete strčit víte kam. Potom je pravděpodobnost průchodu rovna téměř jedné bez ohledu na to, kolik jste si původně vypočítal, že by normálně měla být. Osobně ani neočekávám, že by mi heslo někdo zlomil bruteforce útokem, takže právě přidávat +1 považjuji za hloupost. potože proti jiným hrozbám nechrání vůbec.
sshd? Jak v těchto případech pomůže přihlašování přes dva uživatele nebo přesun sshd na jiný port? Jak brání proti těm vašim "jiným hrozbám"?
Budu pokračovat v té úvaze o díře v sshd:
A) Mám nastaven standardní port 22. Stopadesát obyčejných nájezdníků z celého světa se mi dostalo dovnitř a stáhlo si infomace jaké chtěli.
B) Totéž co A plus nějaký důmyslných škůdce
C) Mám nastaven port 1987. Stopadesát obyčejných nájezdíků našlo zavřený port 22 a šlo jinam
D) Totéž co v C, ale dostal se mi tam důmyslný škůdce
Jaký je výsledek. V případě A) mám sice super skvělé heslo, ale moje citlivé dokumenty i tak lítají po celém světě. Ale jsem borec, heslo mi přece zaručilo, že se to s téměř absolutní jistotou nestane. pohužel, výpočet nepočítal s exploitem, takže byl úplně na hovno.
Případ B) troufám si říct, už není o nic horší než případ A), i když i o tom se dá spekulovat.
V případě C) jsem ovšem zvítězil. Moje citlivé informace nezískal nikdo a na rozdíl od pana Kubečka jsem zvítězil a uchráníl data řešením, nad kterým on ohrnuje nos, protože si he přece nevypočítal.
V případě D) jsem na tom o něco hůř než v případě C) ale existuje šance, že mi hacker například prodá citlivá data zpět, a mohu tak aspoň minimalizovat škody. jistě, nemám žádnou jistotu, že je nebude chtít prodat někomu jinému, ale kdyby to udělal, riskuje, že příště už od něj nikdo nic zpět nekoupí a přijde tak o svůj lup. A i v tomto případě je pravděpodobné, že jsem na tom pořád lépe, než v případě A), kdy moje dokumumenty má každý.
I kdyby platil jenom bod C) považuji to za velikou výhru. Pro mě je totiž zcela irelevantní jestli někdo zlomil mé heslo. Mě zajímá, zda jsem data uchránil či nikoli.
A to se nějak vylučuje. Že při tomto 2 hodinovém okně se na váš počítač pokusí dostat i škůdci, kteří by se tem jinak nedostali a vědí to? Příležitost přeci dělá zloděje.
A vy dáváte rovnítko mezi cílenost a schopnost crackera. Skutečně platí, že každý cílený cracker je extrémně schopný a každý kobercový cracker to jen tak zkouší? ti neschopní nemohou využívat příležitostí?
a to už raději ani nemluvím o možnosti, že schopný cracker může způsobit paradoxně menší ztrátu, protože to bude chtít využít i jinde a vícekrát. Neschopný idiot s vidinou zisku maximalizuje škody, protože mu nedochází, že příště už bude mít smůlu.
Pak si ale vcelku závažně protiřečíte. Víte vůbec co píšete?
...bych měl v případě takového scénáře obavy spíš z jednoho útočníka, který se mi nabourá do sshd na portu 4928, než ze stovky těch, kdo se tam dostanou na portu 22 během těch dvou hodin...
A proč si nejste ochoten přiznat, že existuje určitě spousta těch, kterým problém měnící pravidla hry (jehož příkladem je xploit sshd), otevře možnosti jak vás dostat, ale z časové tísně raději dostanou Nováka, Vaška, Pepíka, Jardu a Michala místo aby se zdržovali s Kubečkem, který jim postup ztížil nestandardnostmi?
Podle vás je existence takového útočníka vyloučena?
V té chvíli nemůžete spoléhat na nic. vaše zabezpečení ztroskotalo. Zůstává vám jen víra, že útočník nebude důsledný, a v rámci maximalizace zisku raději půjde jinam.
Nechci po vás aby jste na to spoléhal. Snažím se naznačit, že jestli mě ten blbý port, změna nicku nebo cokoliv jiného co útočníka prostě lidsky odradí, zachrání, je zvyšeí bezpečnosti vyšší, než nakolik ho vypočítáváte tou svojí matematikou. Pokud se na to díváte logikou, proč nechcete připustit, že i útočník se na to bude dívat logikou a napadat nejdříve ty, kteří půjdou nejsnáze.
sshd se jen tak neválejí po internetu. Já i Michal Kubeček víme, že to, co zastaví schopného crackera, zastaví i toho neschopného. Takže těmi neschopnými se nezabýváme a snažíme se zabránit v průniku těch schopných.
Vy naopak doufáte v to, že schopný cracker najde díru v sshd, napíše exploit, který ji dokáže zneužít, vytipuje si váš počítač, na kterém jsou zajímavá data, a pak mu někdo zřejmě provede lobotomii, dotyčný zkusí svůj útok na váš počítač na port 22, neuspěje -- a ráno ho policajti najdou, jak se blbě usmívá a ptá se, proč ta bedýnka před ním tak hučí.
Mám nastaven standardní port 22. Stopadesát obyčejných nájezdníků z celého světa se mi dostalo dovnitř a stáhlo si infomace jaké chtěli.Shrňme si situaci. Existuje díra v
sshd, kterou nezná nikdo, kromě sto padesáti obyčejných skriptkiddies. Těch sto padesát skriptkiddies spustí plošný sken, takže se nebudou zabývat ničím jiným, než portem 22. Takhle se nabourají kromě desítek tisíc dalších počítačů také na ten váš. Na těch desítkách tisíců počítačů okamžitě spustí svoje skenování, které jim odhalí zajímavé dokumenty (software mají půjčený od CIA, nějaký starší typ Echelonu). Okamžitě začínají zajímavé dokumenty stahovat do svých datacenter. Je ráno, útok končí, skriptkiddies musí do školy. Desítky tisíc správců zjišťují škody, ti, kteří měli sshd na nestandardním portu, se jim smějí.
V psaní tohoto sci-fi můžete pokračovat sám. Ale asi to nikdo číst nebude, protože to, jak se geniální hackeři nechali nachytat nestandardním portem, nikoho zajímat nebude.
Vy jste v bodě C) jako správce neuvěřitelně selhal. Díra v sshd byla natolik veřejně známa, že už ji zkoušejí tisíce nájezdníků -- vždyť i na váš počítač zaútočilo 150 z nich. A vy jste tam nechal volně přístupné nezazáplatované sshd a doufal jste, že nikdo neobjeví, že běží na jiném portu.
Pokud máte na počítači natolik citlivá data, že očekáváte, že budete cíl hned v první vlně útoku, musíte se proti takovým útokům zabezpečit úplně jinak, než přesouváním sshd na nestandardní port.
Začínám si myslet, že porucha skutečně není na mém přijímači.
1) exploit sshd byl zveřejněn a oznámen. (jak dlouho byla ta slavná díra v ssh v Debianu a Ubuntu a kolik hodin trvalo než byla skutečně odzáplatována na serverech po zveřejnění?) Co to tu meleš o díře kterou nikdo nezná?
2) Proč bych měl být takový vůl a skenovat celý internet? Možná že Filip jirsák by v tom případě skenoval od vedlejší vesnice až na opačný konec světa, ale Wire.64 by vzal seznam potencionálně zajímavých cílů a pár jich namátkou zkusil.
3) Předpokládání a "myšlení" ( ono slavné. ale vždyť já jsem myslel, že...! ) je matka omylu!
exploit sshd byl zveřejněn a oznámen. (jak dlouho byla ta slavná díra v ssh v Debianu a Ubuntu a kolik hodin trvalo než byla skutečně odzáplatována na serverech po zveřejnění?) Co to tu meleš o díře kterou nikdo nezná?Co dělá nezazáplátované
sshd veřejně přístupné na počítači s citlivými daty, když je veřejně známá díra v tom sshd?
Proč bych měl být takový vůl a skenovat celý internet? Možná že Filip jirsák by v tom případě skenoval od vedlejší vesnice až na opačný konec světa, ale Wire.64 by vzal seznam potencionálně zajímavých cílů a pár jich namátkou zkusil.A když už by měl Wire.64 těch pár potenciálně zajímavých cílů, proč by zkoušel jenom port 22? Když už si dal tu práci s tím, že si cíle vytipoval, proč nezkusí rovnou všechny otevřené porty? Co mu v tom brání?
Předpokládání a "myšlení" ( ono slavné. ale vždyť já jsem myslel, že...! ) je matka omylu!A kdo tady pořád předpokládá, že útočník bude zkoušet jenom port 22?
Tak to skutečně nevím. Co dělalo nezáplatované sshd na tisících a tisících počítačů s Debianem a jeho deriváty po dobu řadu měsíců před zveřejněním exploitu, a hodiny po zveřejnění?
01:30 je zveřejněn exploit, 05:00 zveřejněna záplata, Filip Jirsák vstává v 8:00. Jak je možné že Jisrákův server jel až do 9:00 , kdy přišel do práce, bez záplaty? Od 1:30 to je dlouhá doba.
Proč by wire64 zkoušel jenom port 22? Protože Wire64 není hloupý. Ví, že než přijde na to co všechno je na serveru "jinak", už dávno ždímá 10 jiných, kde je všechno "standardně" a admin je namyšlený blb, který si myslel, že jenom heslo spasí vše. To je přesně ta vaše oblíbená statistika a pravděpodobnost, aplikovaná na změnu pravidel hry, která v 1:30 v noci nastala.
Tak to skutečně nevím. Co dělalo nezáplatované sshd na tisících a tisících počítačů s Debianem a jeho deriváty po dobu řadu měsíců před zveřejněním exploitu, a hodiny po zveřejnění?Zřejmě naslouchaly na nestandardních portech.
01:30 je zveřejněn exploit, 05:00 zveřejněna záplata, Filip Jirsák vstává v 8:00. Jak je možné že Jisrákův server jel až do 9:00 , kdy přišel do práce, bez záplaty? Od 1:30 to je dlouhá doba.Za tu dobu ten exploit stihne vyzkoušet pár jedinců na počítače svých spolubydlících na kolejích. Wire64 jej zkoušet nebude, protože o něm nebude vědět.Můj server tou dobou poběží s nezazáplatovaným
sshd proto, protože na něm nejsou natolik kritická data, abych tohle řešil. Až ráno problém zjistím, budu ho řešit. K nějakým důležitým datům se pomocí toho exploitu nikdo nedostane, všichni se dostanou jenom k nezajímavým věcem, ke kterým by se dostali i použitím běžného slovníkového automatu. Sítě, kde jsou nějaká důležitá data, jsou chráněny tak, že je nějaké napadnutelné sshd neohrozí (a není to změnou portů).
Proč by wire64 zkoušel jenom port 22? Protože Wire64 není hloupý. Ví, že než přijde na to co všechno je na serveru "jinak", už dávno ždímá 10 jiných, kde je všechno "standardně" a admin je namyšlený blb, který si myslel, že jenom heslo spasí vše.Ždímá, ždímá, a nic nevyždímá, protože zjistí, že tam nic není. Navíc u mne by Wire64 ztroskotal, protože mám pro
roota nastavený netypický shell, netypickou klávesnici a netypickou barvu promptu.
admin je namyšlený blb, který si myslel, že jenom heslo spasí všeStokrát za trest rukou opište: "Nikdo netvrdí, že heslo spasí vše. Tvrdí jen to, že nestandardní port nepomůže v žádném případě, který by byl pravděpodobnější, než 100 hlavních výher ve sportce po sobě".
Hezké. nikdo ovšem netvrdí, že nestandardní port spasí vše.
Jsem rád, že jste mi nakonec přiznal že mám pravdu, a sám se mou úvahou o anomáliích řídíte!
Tímto bych vám rád poděkoval, protože moje otázka je rozřešena. anomální nastavení samozřejmě bezpečnost zvyšuje, a důkazem budiž přímo váš případ, kdy jako kriitik jste si stejně vlastní stroj nastavil s netypickýcm shellem pro roota
Možná se teď vrátiíte zpět k textu blogpostu zjistíte, že není o nějakém "portu".
Barvu shellu určitě. Ale s tím shellem samotným , kdo ví?
Nikdy vás hoši nenapdlo, proč jsou Windows tak zranitelné oproti Linuxovým systémům? mimo jiné proto, že jsou unifikované. diverzifikace u Linuxu znamená, že exploit na Debian často vůbec nefunguje u RedHatu. Diverzifikace vždy zvyšuje odolnost čehokoli, i mimo IT.
zsh raději než bash.
Záměrné anomálie nenastavuju na svých počítačích žádné, protože už samotný fakt, že si počítač nakonfiguruju podle svých potřeb, jej činí zcela odlišný od jiných počítačů.
Pokud chce někdo machrovat, že si také spravuje počítač, a nainstaluje někam nějaký OS a má pocit, že má vystaráno, udělá mnohem víc pro bezpečnost toho počítače tím, že začne studovat, co a jak funguje a jak to má správně nastavit, než že začne vyrábět nějaké "anomálie". Pokud bude tomu systému rozumět, vyrobí si ty anomálie tak nějak přirozenou cestou.
Myslím že to už chápu. Takže vyzrazení informací či ztráta dat pro vás v tom případě asi nejsou problém a příliš vám vadit nebudou.
Možná jsou mé dotazy skutečně hloupé. Ale když si představím, že se objevilo okno, tak si vyberu 10 cílů, o kterých si myslím že můžu něco ukrást. Z hacknutých 10 000 počítačů přece nebudu mít nic, z jednoho určitě něco kápne. A když náhodou narazím na stroj, kde ssh není (nebo je na jiném portu) nebudu to řeši, mám přeci jen dvě hodiny, přesunu se jinam.
Ale možná že jsou crackerři idioti a takto nepostupují. Možná jenom nejsem patřičně IT podeformován a dívám se na to jiným pohledem.
Ale když si představím, že se objevilo okno, tak si vyberu 10 cílů, o kterých si myslím že můžu něco ukrást.
A když u těch 10 cílů nenajdete sshd na portu 22, povzdechnete si a necháte toho?
Z hacknutých 10 000 počítačů přece nebudu mít nic.
Open relay pro rozesílání spamu? Proxy pro anonymní přístup na web? Stroj pro DDoS útok?
Za předpokladu že admini jsou hloupí tak ano. Sám jste ale řekl, že takto kompromitovaný systém přeinstalujete. Co tedy budu mít ze stroje, který někdopoté stejně vypne a mám po spamování? nic.
Ale máte pravdu. Považuji za výnosnější zkusit těch 10 cílů, a jestli všechny spravují Kubečkové, port 22 tam přeci bude Jak sám s oblibou říkáte, je to o pravděpodobnosti.
A kdyz si ssh nechate na standardnim portu, tak takove obavy nemate??? Jako ze nekdo si rekne, pan Kubecek me pekne nasral, jdu ho hacknout, zaloguje se na oblibenou zombie, tukne si na vas port 22, uvidi tam ssh nacez ho popadne smrtelny strach a vyskoci z okna? Sshackem na standardnim portnu proti cilenym utokum?
Mimochodem, od posledni debaty uplynulo neco vody a v mezicase jsme se dockali zajimave zranitelnosti ssh na debianu. A tohle tam neviselo par hodin, ale pres rok. V teto souvislosti se ani zakazani prihlasovani na roota, nebo "znepredikovatelneni" loginu nejevi jako uplne nesmyslna a neproduktivni cinnost.
A kdyz si ssh nechate na standardnim portu, tak takove obavy nemate???
Nejde o to, jestli je nemám. Jde o to, že přesunutím sshd na jiný port by se ani trochu nezmenšily, takže nemám důvod to dělat. Upřímně řečeno... kdybych se chtěl nabourat do svého severu, nejspíš bych na to šel úplně jinak.
V teto souvislosti se ani zakazani prihlasovani na roota, nebo "znepredikovatelneni" loginu nejevi jako uplne nesmyslna a neproduktivni cinnost.
Neřekl bych.
Vyborne, kdyz vasi uvahu rozvinu, tak vlastne ani nema smysl patlat se s nejakym dlouhym heslem, protoze kdyby se chtel nekdo, jako treba vy, nabourat do vaseho serveru, tak by na to sel stejne uplne jinak. Proc resit nejake ssh, kdyz machr hacker se ke mne vloupe pres apache? Vystacime si s nesifrovanym telnetem.
A to ja zas jo. Neznam login => nemuzu zacit bruteforce utok.
Vyborne, kdyz vasi uvahu rozvinu, tak vlastne ani nema smysl patlat se s nejakym dlouhym heslem, protoze kdyby se chtel nekdo, jako treba vy, nabourat do vaseho serveru, tak by na to sel stejne uplne jinak.
Pokud "dlouhým" znamená delší než osmiznakové (předpokládám náhodně vygenerované nad [a-zA-Z0-9], ne slovo ze slovníku), pak ano. Bezpečnost systému je dána bezpečností jeho nejslabšího místa. Troufám si tvrdit, že v popsaném případě jím není odolnost hesla proti útoku hrubou silou.
A to ja zas jo. Neznam login => nemuzu zacit bruteforce utok.
Zjistit přihlašovací jméno není obecně tak těžké, jak by se na první pohled zdálo.
Jde o to, že přesunutím sshd na jiný port by se ani trochu nezmenšilyAle já jsem Vám (viz výše) celkem přesně ukázal o kolik by se zmenšily. Těšil jsem se na plodnou debatu, ale buď byl můj příspěvek tak hloupý a nebo tak výborný, že se nedočkal odpovědi. Vaše vize bezpečnosti je založena na solidní teorii, což Vám chválím, ale místy jste až přehnaně důsledný. Já jsem toho názoru, že sebelepší teorie nemá v praxi opodstatnění, není-li podpořena naměřenými fakty. V nějakém příspěvku níže jste naznačil něco jako že není problém pro script kiddies proskenovat další porty. To je výborný teoretický postřeh, ale empirické zkušenosti naznačují, že to problém je. Schválně změřte frekvenci útoků na port 22 a na jiný port. Já měl donedávna několik let otevřený ssh démon na portu 1 (slovy jedna) a nezaznamenal jsem jediný (!) útok. Na port 22 bylo na té IP adrese oproti tomu jen za tento týden dvacet pokusů o připojení (port je zavřený, takže nevím co by bylo dál). Z tohoto důvodu se odvážím tvrdit, že přestěhovaný ssh démon je elementární obrana proti 0-day exploitu. Mimochodem, na stejném principu fungují obrany typu "graylisting" a "nolisting" z jiného soudku, které by také "teoreticky fungovat neměly". Budete-li "kobercově zbombardován", jaká škoda bude napáchána? V jiném příspěvku píšete (vy nebo pan Jirsák, teď nevím přesně), že pravděpodobně dojde pouze k instalaci nějakého standardního rootkitu, který jde lehce detekovat a zapojení Vašeho PC do spamovacího botnetu. Byl zde i názor, že na serveru budou "velmi citlivá data", která rootkidi promptně zcizí. Ten druhý scénář je sice velmi nepravděpodobný (a jako takový byl smeten ze stolu), ale bylo by mylné se domnívat, že v prvním případě škoda nestojí za řeč. Přinejmenším Váš čas, který budete věnovat nápravě problému, se dá vyčíslit pěněžně. Stojí to za to? Samozřejmě, bezpečnost nekončí na tom, že si přesunu port ssh démona. To je jen doplněk stravy. Rozumně uvažující administrátor má na firewallu nadefinovány IP adresy odkud se smí přihlašovat. Má-li s tím problém a potřebuje být ultra mobilní, řeší to dvoustupňově -- například VPN (na nestd. portu :) a až pak SSH. Nebo nejprv SSH do chrootu, kde prolomení nemá přímý dopad na bezpečnost serveru, a pak nějakou jinou metodou dál (jde zde využít i ten zmiňovaný telnet). A toto nejsou věci efektní, nýbrž velmi efektivní. Divím se, že ani jedno z těchto podpůrných řešení neaplikujete (nebo alespoň jsem to tak vyčetl z Vašich reakcí).
Přinejmenším Váš čas, který budete věnovat nápravě problému, se dá vyčíslit pěněžně.
Takže vy budete v klidu, a vaše náklady budou nulové, protože i když jste měl v internetu stroj s děravým sshd (řekněme) stejně dlouho jako pan Kubeček, tak vás se ten problém netýká (díky tomu, že máte sshd na nestandardním portu)?
Problém se mne a pana Kubečka bude a nebude týkat ve stejné situaci, tj. kdy dojde nebo nedojde k prolomení bezpečnosti serveru.
Já měl za to, že pokud jsem měl např. půl dne k internetu stroj s sshd, na které existoval (a byl znám) funkční exploit, tak stejně musím nějakým způsobem zjistit, zda k prolomení bezpečnosti došlo nebo ne (bez ohledu na číslo portu, kde to sshd viselo).
8.1.2009 20:02
xkucf03 | skóre: 49
| blog: xkucf03
Rozumně uvažující administrátor má na firewallu nadefinovány IP adresy odkud se smí přihlašovat. Má-li s tím problém a potřebuje být ultra mobilní, řeší to dvoustupňově -- například VPN (na nestd. portu :) a až pak SSH. Nebo nejprv SSH do chrootu, kde prolomení nemá přímý dopad na bezpečnost serveru, a pak nějakou jinou metodou dál (jde zde využít i ten zmiňovaný telnet).
Konečně nějaká rozumná řeč – nejbezpečnější je takové SSH, na které se nedá připojit, resp. dá se na něj připojit jen z několika předem definovaných IP adres. Pro mobilní přístup se dá vytvořit dedikovaný server, který bude sloužit jen jako brána – prošťouchneš si tam tunel na SSH skutečného serveru, nebo přesměrování agenta.
sshd server. A o tom tady celou dobu s Michalem Kubečkem píšeme. Neustále tu někdo řeší, jak se bránit před exploitem přesunem sshd na nestandardní port, ale už nikoho nenapadne, že se ten útočník stejným exploitem dostane i na router vašeho ISP, tam si poslechne, který je to ten tajný port, na který se připojujete, pak routeru vysvětlí, že vaši IP adresu nemá směrovat k vám ale k němu, a přes firewall povolující přístup „několika vybraným IP adresám“ aplikuje svůj exploit na sshd běžící na „tajném portu“.
Aby se dalo mluvit o další vrstvě zabezpečení, musí tato vrstva fungovat i zcela sama o sobě, bez ostatních vrstev. A aby mělo smysl jí do celého systému zabezpečení přidávat, měla by být zhruba alespoň stejně silná, jako vrstva ostatní. Takže tu máme 3 vrstvy: šifrované spojení zabezpečené symetrickou kryptografií a přihlášení klíčem s asymetrickou kryptografií – SSH; dále přesun na „nestandardní port“ a do třetice přístup jen z povolených adres. Spolehli byste se jen na první možnost, tj. SSH na standardním portu a přístup odevšad? Já ve většině případů ano. Spolehli byste se jen na druhý způsob zabezpečení, tj. dáte klidně veřejně k dispozici svoje heslo nebo klíč a zabezpečíte přístup jen přesunem sshd na nestandardní port? Já ani ve snu. Třetí případ – dát k dispozici své heslo nebo klíč, sshd ponechat na standardním portu a pouze omezit přístup „z několika málo vybraných IP adres“? To bych ISP na obou koncích musel hodně důvěřovat, za současné situace, kdy jsem pro ISP obyčejný zákazník jako kdokoli jiný bych do toho nešel ani u domácího serveru – je to u mne na hranici nouzového dočasného řešení a nesmyslu. Takže pokud bych si chtěl 1. řešení pojistit nějakou druhou vrstvou (pro případ exploitu či kompromitace klíče), považoval bych třetí řešení za nouzové než zprovozním něco jiného, jako s trvalou druhou vrstvou zabezpečení bych se s ním nesmířil. O druhém řešení s přesunem portu nemá smysl se vůbec dál bavit.
8.1.2009 22:10
xkucf03 | skóre: 49
| blog: xkucf03
To bys to ale mohl dovést až k tomu, že firewally nepotřebujeme vůbec, můžou být otevřené všechny porty pro všechny IP adresy, protože na serveru ti mají běžet jen ty služby, které potřebuješ a mají být plně aktualizované a bezpečné. Přesto většina lidí firewall používá a explicitně si na něm definuje porty, které na daný stroj propouští (přestože by teoreticky systém měl být bezpečný i bez toho firewallu).
Nestandardní porty neuznávám, protože mi pomer přínos pro bezpečnost : opruz pro uživatele přijde nevýhodný. Ale když vím, že se vždycky přihlašuji jen ze 2-3 počítačů, tak nemám důvod mít SSH otevřené pro celý Internet. Vedle toho mám jeden počítač, kam se dá přihlásit jen s klíči, a tomu věřím natolik, že si ho klidně dovolím zpřístupnit celkému světu (port 22).
V jednom příspěvku tu padlo, že je zkombinovat různé technologie – např. OpenVPN a SSH – to považuji za rozumné, protože pravděpodobnost, že by ve stejnou dobu byl funkční exploit pro obě technologie je hodně nízká – aby se útočník mohl probourat přes OpenVPN na bránu a z ní pak na SSH.
To bys to ale mohl dovést až k tomu, že firewally nepotřebujeme vůbec, můžou být otevřené všechny porty pro všechny IP adresy, protože na serveru ti mají běžet jen ty služby, které potřebuješ a mají být plně aktualizované a bezpečné. Přesto většina lidí firewall používá a explicitně si na něm definuje porty, které na daný stroj propouští (přestože by teoreticky systém měl být bezpečný i bez toho firewallu).Ano, tak nějak to chápu, s drobným rozdílem – netvrdím, že firewally nepotřebujeme vůbec, k ochraně síťové infrastruktury jsou užitečné. Ale k ochraně jednotlivých síťových služeb podle mne prakticky nejsou potřeba, s výjimkou některých hloupých služeb nebo implementací, které nezvládnou síťový přístup řídit samy (a např. službu, která má být dostupná pouze v rámci daného počítače, nelze donutit, aby nedopovídala na požadavky z venčí).
V jednom příspěvku tu padlo, že je zkombinovat různé technologie – např. OpenVPN a SSH – to považuji za rozumné, protože pravděpodobnost, že by ve stejnou dobu byl funkční exploit pro obě technologie je hodně nízká – aby se útočník mohl probourat přes OpenVPN na bránu a z ní pak na SSH.Já tohle řešení nepovažuji za nějak extra dobré, protože bezpečnost násobí nějakou konstantou, ale nenásobí ji mezi sebou – ty technologie toho mají až příliš společného, vlastně jsou to dvě implementace téměř toho samého. Samozřejmě je to lepší než samotné SSH, ale k plnohodnotné druhé vrstvě to má podle mne daleko.
8.1.2009 23:11
xkucf03 | skóre: 49
| blog: xkucf03
Ale trochu mi přijde, že to už se dostáváme do dimenzí, které jsou vhodné tak pro banku, zatímco pro běžného smrtelníka a běžné servery je postačující bezpečnost řádově nižší. A ta banka to nakonec stejně neřeší nějakými obskurními metodami, ale prostě tak, že přístup zvenku je zatlučený úplně a vždycky má pár lidí, kteří sedí na vnitřní síti a dohlížejí na běh systému.
Neustále tu někdo řeší, jak se bránit před exploitem přesunem sshd na nestandardní port, ale už nikoho nenapadne, že se ten útočník stejným exploitem dostane i na router vašeho ISP, tam si poslechne, který je to ten tajný port, na který se připojujete, pak routeru vysvětlí, že vaši IP adresu nemá směrovat k vám ale k němu, a přes firewall povolující přístup „několika vybraným IP adresám“ aplikuje svůj exploit na sshd běžící na „tajném portu“.
Jak vite, ze to nikoho nenapadlo? Mozna napadlo, ale nezdalo se mu, ze by to melo vyznamny dopad na probirane temata.
Kdyz se dostanu na router ISP, a vim o tom, ze jsem na routeru ISP, tak filtrovat prochazejici provoz na mozna ssh spojeni jeho zakazniku, ktera miri na nestandardni porty, je opravdu to posledni, co by me... ne pockejte, takova hovadina by me vubec nenapadla! Na internetech se valej stovky tisic pocitacu s sshckem na standardnim portu, tak proc bych zabijel cas cihanim na jednotky adminu pripojujici se na nestandardni? Kolik myslite, ze by se za dobu, jakou budete na routeru cekat na nejakeho takoveho nestastnika, dalo zkomprovitovat standardne nastavenych pocitacu? Nebylo by misto toho produktivnejsi odchytavat na routeru treba hesla z http spojeni?
A aby mělo smysl jí do celého systému zabezpečení přidávat, měla by být zhruba alespoň stejně silná, jako vrstva ostatní.
Pointa je, ze si nikdy nemuzete byt naprosto jisty tim, jak je ktera vrstva silna.
Pointa je, ze si nikdy nemuzete byt naprosto jisty tim, jak je ktera vrstva silna.Tím, že zabezpečení kryptografií s veřejným klíčem je silnější než změna portu, si jist jsem.
O cilenych utocich tady vedet monolog vy ackoliv uz bylo receno, ze to tu neresime.
Ok. Jeste horsi pripad bude, kdyz nekdo prijde k serveru, vytaha z nej disky a pak ho rozmlati kladivem. Tedy spravnym resenim cilenych (a veskerych dalsich) utoku je poridit si titanovou pikslu se dvema dirama na proud a sit, do ni dat server a jsem zachranen. Jiz netreba silnych hesel, firewallu ani klicu, titan to jisti!
Vas predpoklad, ze na mnozine moznych utoku existuje za vsech okolnosti jednoznacne usporadani od nejmene nebezpecneho k nejnebezpecnejsimu utoku a kdyz implementuju ochranu proti urcitemu napadeni, tak jsem chranem proti vsem mene nebezpecnym utokum, je zkratka mylny.
V nějakém příspěvku níže jste naznačil něco jako že není problém pro script kiddies proskenovat další porty. To je výborný teoretický postřeh, ale empirické zkušenosti naznačují, že to problém je.Proti script kiddies používám spolehlivější obrany (aktualizovaný software, zákaz přihlášení heslem), takže přesun na jiný port je zbytečný (zvýšení bezpečnosti oproti již realizovaným obranám je směšné). Je to asi jako na dveře s bezpečnostním zámkem přidat umělohmotný zámeček z nějaké hry, který ukroutíte rukou. Jistě, existuje jistá nenulová pravděpodobnost, že umělohmotný zámeček někoho zastaví – ale k čemu to, když toho člověka stejně zastaví i ten bezpečnostní zámek, který tam stejně musím mít?
Já měl donedávna několik let otevřený ssh démon na portu 1 (slovy jedna) a nezaznamenal jsem jediný (!) útok. Na port 22 bylo na té IP adrese oproti tomu jen za tento týden dvacet pokusů o připojení (port je zavřený, takže nevím co by bylo dál). Z tohoto důvodu se odvážím tvrdit, že přestěhovaný ssh démon je elementární obrana proti 0-day exploitu.Kolik z těch dvaceti pokusů o připojení byl někdo s 0-day exploitem? Předpokládám, že 0, takže stejně jako na ten
sshd přestěhovaný na portu 1. Mít vaši odvahu, tvrdil bych třeba, že přesunem na port 1 se počet 0-day exploitů na sshd na portu 1 dostal na stejnou úroveň, jako počet 0-day exploitů na sshd na portu 22, což výrazně zhoršilo bezpečnost celého systému.
Mimochodem, na stejném principu fungují obrany typu "graylisting" a "nolisting" z jiného soudku, které by také "teoreticky fungovat neměly".graylisting není způsob, jak zabránit spamu (zredukovat jeho počet na 0), ale jak omezit spam (přijmout třeba jen 40 % vám adresovaného spamu). Pokud nechcete zabránit průniku „crackerů“ na váš systém, ale pouze omezit četnost těch průniků (že se vám nedostane do systému 10 lidí denně, ale jenom 3), je přesun na jiný port dobrá volba.
Budete-li "kobercově zbombardován", jaká škoda bude napáchána? V jiném příspěvku píšete (vy nebo pan Jirsák, teď nevím přesně), že pravděpodobně dojde pouze k instalaci nějakého standardního rootkitu, který jde lehce detekovat a zapojení Vašeho PC do spamovacího botnetu. Byl zde i názor, že na serveru budou "velmi citlivá data", která rootkidi promptně zcizí. Ten druhý scénář je sice velmi nepravděpodobný (a jako takový byl smeten ze stolu), ale bylo by mylné se domnívat, že v prvním případě škoda nestojí za řeč. Přinejmenším Váš čas, který budete věnovat nápravě problému, se dá vyčíslit pěněžně. Stojí to za to?Ano, „stojí to za to“ je celkem dobrá otázka. Udělejme si takový zkušební výpočet. Pravděpodobnost nalezení exploitu pro
sshd a napadení mého serveru: 10-9 (ve skutečnosti asi ještě daleko méně). Náklady na odstranění následků: 1000 Kč. Pravděpodobnost napadení serveru tímtéž v případě odsunu na jiný port: 10-10. Náklady na zavedení ochrany: 1 hal (jenom na změnu pomyslíte a už to je). Čisté současné náklady bez odsunu portu: 10-9·1000 Kč = 0,000001 Kč. Čisté současné náklady s odsunem portu: 0,01 Kč + 10-10·1000 Kč = 0,0100001 Kč. Takže nejen, že náklady na odsun portu vážené rizikem jsou asi desettisíckrát větší, než náklady na odstranění škod vážené rizikem, ale ještě náklady na odstranění škod vážené rizikem dosahují závratné tisíciny haléře. Pokud nedůvěřujete těm konkrétním číslům, dá se to říci obecně: nastejno (změna portu nebo řešení následků) to vyjde v okamžiku, když doba potřebná na odstranění následků exploitu bude tolikrát větší než doba potřebná k ochraně, kolikrát je větší pravděpodobnost, že dojde k získání přístupu na nepřesunutém portu, než na přesunutém portu. Přičemž odstraněním následků se myslí skutečně jen čas od okamžiku, kdy víte, že byl server napaden a jak, do okamžiku likvidace škod. To nejpracnější (dohledání informací o útocích, zjištění, zda se k vám útočník dostal či ne), musíte provést v obou případech – ať máte sshd na jiném portu nebo ne. Z toho prostě „výhodnost“ přesunu na jiný port nevytřískáte ani kdyby odstranění následků znamenalo strávit den novou instalací celého systému a změnu portu dělala cvičená opice píšící všema deseti s platem 10 Kč za hodinu.
Samozřejmě, bezpečnost nekončí na tom, že si přesunu port ssh démona. To je jen doplněk stravy. Rozumně uvažující administrátor má na firewallu nadefinovány IP adresy odkud se smí přihlašovat. Má-li s tím problém a potřebuje být ultra mobilní, řeší to dvoustupňově -- například VPN (na nestd. portu :) a až pak SSH. Nebo nejprv SSH do chrootu, kde prolomení nemá přímý dopad na bezpečnost serveru, a pak nějakou jinou metodou dál (jde zde využít i ten zmiňovaný telnet). A toto nejsou věci efektní, nýbrž velmi efektivní. Divím se, že ani jedno z těchto podpůrných řešení neaplikujete (nebo alespoň jsem to tak vyčetl z Vašich reakcí)Myslíte doplněk stravy na bázi homeopatik – tak naředěný, až nakonec nezůstane nic? Povolení jen určitých IP by mělo, smysl, pokud bych se exploitu na
sshd skutečně musel bát – stejně už bych ale přístup přes ssh spíš než pro nějaké náhodné IP adresy někde z internetu povolil přístup jen z vyhrazené sítě, kterou mám fyzicky pod kontrolou. VPN by v určitých variantách pomohlo proti exploitu, ale nějaké výrazné zvýšení bezpečnosti to také není, chroot, ze kterého se dá dostat, ale jehož prolomení podle vás nemá přímý dopad na bezpečnost serveru, to jsem raději neslyšel. Kromě hazardu s chrootem jsou to všechna řešení jen efektní – přes okno zavřené jedním zatlučeným prknem dáte druhé prkno. Efektivní řešení je takové, které nenakopíruje další ochranu stejného druhu, ale přidá nějakou úplně novou. Třeba takovou, že je na firewallu úplně zakázán přístup k sshd a povolí se jen na žádost, a to pouze pro jedinou IP adresu a případně i port v žádosti uvedené. Tou žádostí může být port knocking, ale lépe třeba žádost opatřená elektronickým podpisem toho správného privátního klíče, doručená ať UDP paketem nebo třeba SMS. A ještě lépe pokud se to povolení na firewallu děje ještě na firewallu umístěném před cílovým počítačem. To je skutečné dvoustupňové řešení – že přidáte ochranu zcela nového typu, ne že zdvojíte ochrany stávající.
VPN by v určitých variantách pomohlo proti exploitu, ale nějaké výrazné zvýšení bezpečnosti to také není
Proč to není výrazné zvýšení bezpečnosti? Resp. v čem je horší než ten portknocking? Osobně, kdybych si měl vybrat, jestli sshd schovat do VPN nebo za portknocking, asi bych dal spíš přednost tomu VPN (se spuštěným HMAC firewallem).
Je to asi jako na dveře s bezpečnostním zámkem přidat umělohmotný zámeček z nějaké hry, který ukroutíte rukou.Já o voze a Vy o koze. Vyjádřete se prosím k tomu co jsem napsal.
Kolik z těch dvaceti pokusů o připojení byl někdo s 0-day exploitem?To já nevím a řekl jsem to. Předpokládat, že to je nula, mi ale přijde zcestné. Jak jste k tomu předpokladu došel?
Pokud nechcete zabránit průniku „crackerů“ na váš systém, ale pouze omezit četnost těch průniků (že se vám nedostane do systému 10 lidí denně, ale jenom 3), je přesun na jiný port dobrá volba.Dobře, souhlasím. Zdá se, že už si rozumíme stran užitečnosti tohoto opatření. Je pro Vás poměr 10:3 zanedbatelný?
Udělejme si takový zkušební výpočet.Tady jste s těmi čísly myslím ujel. Jak jste se k nim dopracoval? Já jen když vystřelím od boku na základě svého nejlepšího vědomí, tak jsem s těmi čísly řádově jinde. Řekněme, že za posledních deset let byl server jeden den v ohrožení, kvůli jisté /* chybě */ s /* zakomentovanou entropií */, tak mám číslo v řádu 10-4. Dále, já bych takový průměrný server reinstaloval cca jeden den, za ten den bych si naúčtoval pět až desetkrát tolik co Vy, ale to asi není moc podstatné, jelikož dominantní číslo v odhadu škody bude zřejmě ušlý zisk, který bych také sázel do oblasti čtyřmístných čísel. Nejlepší ale nakonec, jak jste se dopracoval k poměru 1/10 při změně portu? Já ať dělím jak dělím svá naměřená data, tak pořád dělím nulou.
nastejno (změna portu nebo řešení následků) to vyjde v okamžiku, když doba potřebná na odstranění následků exploitu bude tolikrát větší než doba potřebná k ochraně, kolikrát je větší pravděpodobnost, že dojde k získání přístupu na nepřesunutém portu, než na přesunutém portuAno. Změna portu nestojí nic a ty pravděpodobnosti jsou řádově různé.
To nejpracnější (dohledání informací o útocích, zjištění, zda se k vám útočník dostal či ne), musíte provést v obou případech – ať máte sshd na jiném portu nebo ne.Já myslím, že tento náklad je řádově menší, než ta přeinstalace.
Povolení jen určitých IP by mělo, smysl, pokud bych se exploitu na sshd skutečně musel bátAle já se ho skutečně bojím. Já předpokládám, že sshd je zranitelné a snažím se zmírnit dopad problému. Tento přístup pokládám za základní premisu počítačové bezpečnosti. Stejně tak v případě počítačové sítě budu předpokládat, že například jeden server byl kompromitován a budu se snažit zabezpečit zbytek sítě proti němu. Na to máme různé VLANy a DMZ, že? Předpokládat, že ssh démon je nezničitelný a hesla jsou dost silná, stavět jenom na tom, nedělat žádná další opatření, je bláznovství. I kdybych měl mít nějaký ten chosťing kde sshd opravdu potřebuji kvůli uživatelům, tak se budu snažit ze všech sil, aby ke kompromitaci přes sshd nedošlo, i když je zranitelné.
chroot, ze kterého se dá dostat, ale jehož prolomení podle vás nemá přímý dopad na bezpečnost serveru, to jsem raději neslyšelMyslím že, mi nerozumíte. Démon sshd jde spustit v chrootu pod běžným uživatelem. Z takového chrootu se už jen tak nedostanete, možná nějakou dírou v jádře, ale v tom případě jde problém odsunout jinam. Buď uděláte pro ten sshd virtuální mašinu, a nebo vezmete fyzicky jiný stroj, který spojíte se serverem nějakou point to point linkou (aby tam zas neřádily sniffery).
Efektivní řešení je takové, které nenakopíruje další ochranu stejného druhu, ale přidá nějakou úplně novou.Souhlasím -- ještě jsem explicitně v nějakém příspěvku pod tím uvedl totéž co vy. Takže mi vysvětlete, kde já přidávám stejný druh ochrany. VPN a SSH jsou dvě různé věci. Pokud mi vadí společný faktor openssl, použiju ssh a telnet.
VPN by v určitých variantách pomohlo proti exploitu, ale nějaké výrazné zvýšení bezpečnosti to také neníJá opět nechápu, jak jste došel na "určité varianty", a "nějaké výrazné zvýšení", ale budiž. I kdyby to zase jen přineslo poměr 10:3, tak je to výhodné.
Já o voze a Vy o koze. Vyjádřete se prosím k tomu co jsem napsalJá jsem se k tomu vyjádřil. Vedle silnější ochrany nainstalovat ještě daleko slabší ochranu, kterou překoná každý, kdo překoná i tu silnější, je nesmysl.
Tak, že v současnosti není znám žádný exploit na aktuálníKolik z těch dvaceti pokusů o připojení byl někdo s 0-day exploitemTo já nevím a řekl jsem to. Předpokládat, že to je nula, mi ale přijde zcestné. Jak jste k tomu předpokladu došel?
sshd.
Nejlepší ale nakonec, jak jste se dopracoval k poměru 1/10 při změně portu? Já ať dělím jak dělím svá naměřená data, tak pořád dělím nulou.Takže pravděpodobnost nalezení exploitu na SSH předpokládáte nenulovou, ale pravděpodobnost nalezení exploitu na SSH a zároveň pravděpodobnost nalezení exploitu na SSH a nalezení vašeho tajného portu s běžícím SSH považujete za nulovou? Z toho mi vychází jedině to, že za nulovou považujete pravděpodobnost nalezení vašeho tajného portu s SSH. Nechci vám brát iluze, ale ta pravděpodobnost není nulová, pravděpodobnost že se to stane do několika hodin je naopak téměř jedna.
Ano. Změna portu nestojí nic a ty pravděpodobnosti jsou řádově různéZměnu portu provedete v nenulovém čase. Pokud to nestojí nic, pak vaše cena za nějakou jednotku času je nula, takže i den trvající reinstalace pořád nebude stát nic.
Já myslím, že tento náklad je řádově menší, než ta přeinstalace.Já tedy nevím, jak by ta přeinstalace vypadala u vás, u mne by to byl reboot do jiné instalace systému, kontrola kontrolních součtů a případná obnova napadených souborů. Zatímco pro zjištění, že jste byl napaden, musíte prolézat internet a zjišťovat, jaké byly typy útoků a ověřovat, zda tento útok byl proveden i na vás. A to pořád pokud předpokládáme jen plošný útok.
Ale já se ho skutečně bojím. Já předpokládám, že sshd je zranitelné a snažím se zmírnit dopad problému.A jak se ho snažíte zmírnit? Po případném útoku musíme stejně oba dva udělat to samé -- tak k čemu vám jsou vaše opatření?
Předpokládat, že ssh démon je nezničitelný a hesla jsou dost silná, stavět jenom na tom, nedělat žádná další opatření, je bláznovství. I kdybych měl mít nějaký ten chosťing kde sshd opravdu potřebuji kvůli uživatelům, tak se budu snažit ze všech sil, aby ke kompromitaci přes sshd nedošlo, i když je zranitelné.O tom není spor. Jenže přesun SSH na jiný port není žádná obrana.
Myslím že, mi nerozumíte. Démon sshd jde spustit v chrootu pod běžným uživatelem. Z takového chrootu se už jen tak nedostaneteV tom případě ale takový chroot neřeší problém, jak se na daný stroj přihlásit na
roota, že?
Souhlasím -- ještě jsem explicitně v nějakém příspěvku pod tím uvedl totéž co vy. Takže mi vysvětlete, kde já přidávám stejný druh ochrany. VPN a SSH jsou dvě různé věci. Pokud mi vadí společný faktor openssl, použiju ssh a telnet.Stejný protokol, stejné šifrování, stejné zabezpečení klíčů -- pouze trochu jiná implementace. Zrovna útok na chybu při generování klíčů postihne SSH i VPN, tady bylo pouze to štěstí, že se náhodou asi jednalo o dvě různé implementace -- nebo se používá stejná implementace a ta zde několikrát zmíněné chyba s generováním slabých klíčů by vaše "dva stupně" ochrany postihla oba?
Já opět nechápu, jak jste došel na "určité varianty", a "nějaké výrazné zvýšení", ale budiž. I kdyby to zase jen přineslo poměr 10:3, tak je to výhodné.Pokud vám stačí bezpečnost 10:3, proč používáte SSH a hesla? Stačí telnet a jednoznakové heslo, ne?
Já jsem se k tomu vyjádřil.Ne, já jsem mluvil o tom, jaký je rozdíl mezi teoretickým a empirickým přístupem k otázce "automaty používají (úplné) portskeny".
Tak, že v současnosti není znám žádný exploit na aktuální sshd.Takže naše debata bude mít smysl pouze v tom dvouhodinovém čase, kdy ten exploit bude a náprava ještě ne. To není úplně správný přístup, myslím.
Z toho mi vychází jedině to, že za nulovou považujete pravděpodobnost nalezení vašeho tajného portu s SSH. Nechci vám brát iluze, ale ta pravděpodobnost není nulová, pravděpodobnost že se to stane do několika hodin je naopak téměř jedna.Já nevím, jaká ta pravděpodobnost je. Já mám svá naměřená data a tam se ty pravděpodobnosti takto chovají. Najděte mi prosím nějakou chybu v měření nebo naměřte něco jiného.
Změnu portu provedete v nenulovém čase. Pokud to nestojí nic, pak vaše cena za nějakou jednotku času je nula, takže i den trvající reinstalace pořád nebude stát nic.To není také úplně správný přístup. Já si za instalaci serveru mohu naúčtovat X peněz, a za instalaci serveru s jiným portem také X peněz. Nevím, jestli bych šel tak daleko, abych si účtoval X peněz plus 10 nebo kolik haléřů za změnu portu. Proto mě to nic nestojí. V praxi to vypadá buď tak, že mám příslušný konfigurák připraven při instalaci, nebo pokud ne, tak stejně procházím celý distribuční (nebo vanilkový) a přepsání jednoho čísla je opravdu zanedbatelná položka.
Já tedy nevím, jak by ta přeinstalace vypadala u vás, u mne by to byl reboot do jiné instalace systému, kontrola kontrolních součtů a případná obnova napadených souborů.Aby tohle bylo opravdu důsledné, byste musel součtovat i všechny konfigurační soubory, skripty, zkrátka skoro všechno co máte, a porovnat několik verzí dozadu vůči nějakému deníku změn. To je samozřejmě sen každého auditora, ale v praxi je to šílený opruz a patří to do kategorie do které zase nepatří volně se na Internetu poflakující servery s sshd otevřeným do světa. Já bych raději u průměrného servříku spolehl na to, že se tam všechno naleje znova.
Zatímco pro zjištění, že jste byl napaden, musíte prolézat internet a zjišťovat, jaké byly typy útoků a ověřovat, zda tento útok byl proveden i na vás.To je mi k ničemu, jednak se to špatně hledá a jednak jste říkal, že to je jen pro plošné útoky. Já samozřejmě nemám jistotu, že můj server nebyl napaden záměrně. Jenže detekce průniku je úplně jiné téma, o kterém se teď nebavíme.
A jak se ho snažíte zmírnit? Po případném útoku musíme stejně oba dva udělat to samé -- tak k čemu vám jsou vaše opatření?Ano, pokud mám nulovou možnost detekovat průnik, tak si můžu všechny ty pravděpodobnosti, že mi nikdo nic neudělá, vynásobit nulou, a jít se klouzat. Taková varianta je ale bezpečnostní paskvil a ne bezpečnostní řešení.
O tom není spor. Jenže přesun SSH na jiný port není žádná obrana.Překroutil jste kontext. Váš původní komentář byl, že nezavádíte omezení na IP adresy. O tom, jestli je přesun na port obrana, se asi už bavit nemusíme, jelikož A) jste připustil, že počet útoků na jiném portu je nižší B) stejně si myslíte že je to k ničemu, a u toho můžeme zůstat - já jsem již své argumenty podal a Vám to nenutím.
V tom případě ale takový chroot neřeší problém, jak se na daný stroj přihlásit na roota, že?Na to je tam pak ten telnet, víte?
nebo se používá stejná implementace a ta zde několikrát zmíněné chyba s generováním slabých klíčů by vaše "dva stupně" ochrany postihla oba?Já nevím, ale je možné že ano. Ale vy na tom sshd nemusíte mít klíče, jen to heslo. Pak opět potřebujete dvě úplně různé chyby k úspěšnému průniku. Navíc jsem doslova napsal: "Pokud mi vadí společný faktor openssl, použiju ssh a telnet." Pokud Vám vadí ještě něco jiného, zkuste aspoň trochu kooperovat a navrhnout k problému i řešení. Tahle oponentura mě nebaví. Ty vaše SMSky jsou zajímavé, a jednou jsem to i zkoušel, musím ale říci, že se nejedná zrovna o bezproblémové a hlavně bezplatné řešení. Na druhou stranu SMS brána u počítače se pak dá využít i na jiné věci (nagios a tak dál).
Pokud vám stačí bezpečnost 10:3, proč používáte SSH a hesla? Stačí telnet a jednoznakové heslo, ne?Protože já nemám bezpečnost rovnu tomuto poměru, jen ji tímto poměrem zvyšuji.
Ne, já jsem mluvil o tom, jaký je rozdíl mezi teoretickým a empirickým přístupem k otázce "automaty používají (úplné) portskeny".Bezpečnost se nestaví na problémy, které už nastaly, ale na problémy, které mohou nastat. Já jsem třeba empiricky zjistil, že jsem zatím nepotřeboval v autě airbagy -- přesto bych je neoznačoval za teoretický výmysl, který je v praxi zbytečný.
Já nevím, jaká ta pravděpodobnost je. Já mám svá naměřená data a tam se ty pravděpodobnosti takto chovají. Najděte mi prosím nějakou chybu v měření nebo naměřte něco jiného.Máte tam chybu v měření -- příliš malý vzorek. Pravděpodobnosti tohoto druhu se musí spočítat na základě nějakých odhadů, ne z měření. To je jako kdybyste z měření odvozoval pravděpodobnost závažné havárie v jaderné elektrárně.
To je mi k ničemu, jednak se to špatně hledá a jednak jste říkal, že to je jen pro plošné útoky. Já samozřejmě nemám jistotu, že můj server nebyl napaden záměrně. Jenže detekce průniku je úplně jiné téma, o kterém se teď nebavíme.Není to k ničemu, může mi to pomoci odhalit typ útoku, který bych jinak nerozpoznal. Samozřejmě pokud chci mít jistotu, musím předpokládat, že server byl napaden a já jsem to neodhalil -- tomu ale změnou portu stejně nepředejdu.
Překroutil jste kontext. Váš původní komentář byl, že nezavádíte omezení na IP adresy.Omezení na IP adesy nezavádím, protože mi to připadá jako slabá ochrana -- je to na hranici toho, co jsem ochoten považovat za ochranu. V některých případech -- třeba pokud by byl znám exploit na SSH a neexistovala oprava -- bych jej jako nouzové řešení použil, ale jako běžné zabezpečení ne. Pokud bych měl potřebu něco zabezpečit ještě víc, pouhé omezení na IP adresy bych nepovažoval za dostatečné zabezpečení.
Na to je tam pak ten telnet, víte?Aha, takže je to takový chroot, ze kterého se nejde dostat na roota, ale přitom to vlastně jde. A spravuje to Chytrá Horákyně?
Já nevím, ale je možné že ano. Ale vy na tom sshd nemusíte mít klíče, jen to heslo. Pak opět potřebujete dvě úplně různé chyby k úspěšnému průniku. Navíc jsem doslova napsal: "Pokud mi vadí společný faktor openssl, použiju ssh a telnet." Pokud Vám vadí ještě něco jiného, zkuste aspoň trochu kooperovat a navrhnout k problému i řešení. Tahle oponentura mě nebaví. Ty vaše SMSky jsou zajímavé, a jednou jsem to i zkoušel, musím ale říci, že se nejedná zrovna o bezproblémové a hlavně bezplatné řešení. Na druhou stranu SMS brána u počítače se pak dá využít i na jiné věci (nagios a tak dál).Nebo bych se tam mohl přihlašovat úplně bez hesla, tím se problém s klíči taky vyřeší, ne? Pokud nedůvěřuju zabezpečení klíčem, neobejdu to přece tím, že použiju nějaký ještě nižší stupeň zabezpečení. Jiné řešení jsem napsal -- třeba povolit přístup na firewallu k SSH nebo vůbec nastartovat
sshd nějakým nezávislým kanálem. Přičemž nezávislý kanál může být GSM, časová okna, šifrovaní používající jiné šifry než používá SSL... Záleží, jak moc do toho chcete investovat. Ale připadá mi zbytečné bránit se proti chybě SSH ale zůstat náchylný na chybu šifrovacího algoritmu, jeho implementace ve společné knihovně, chybu při generování klíčů a náhodných čísel atd. atd., když za stejnou cenu můžu mít ochranu, která bude fungovat i proti těmhle dalším typům chyb či útoků.
Zabezpečení by se nemělo dělat tak, že si udělám seznam možných způsobů průniku, a pak se každý zvlášť pokusím nějak zalepit. Mělo by se dělat obecně a na konkrétních typech průniků si maximálně můžu kontrolovat, jestli jsem něco nepřehlédl.
9.1.2009 11:25
xkucf03 | skóre: 49
| blog: xkucf03
pouhé omezení na IP adresy bych nepovažoval za dostatečné zabezpečení.
dostatečné určitě ne, ale je to o dost smysluplnější doplněk zabezpečení než nestandardní porty -- ty dokáže proskenovat každá lama, ale konkrétní adresu musíš nejprve zjistit (možností je daleko víc než u portů, takže skenování nepřipadá v úvahu) a jednak podvrhnout, k čemuž je potřeba nějaké selhání na síti, např. u poskytovatele.
Já jsem třeba empiricky zjistil, že jsem zatím nepotřeboval v autě airbagy -- přesto bych je neoznačoval za teoretický výmysl, který je v praxi zbytečný.Co to prosím pěkně blábolíte? O praktickém využití airbagů existují empirické údaje. Navíc Vy máte "chybu měření" v tom, že jste se ještě 10x nevyboural bez a 10x s airbagy. (Aspoň si to tedy myslím.) O tom, že automatizované útoky na SSH používají téměř výhradně port 22, existují také empirické údaje (např. ty moje, ale abyste neremcal, našel jsem i tuto zprávu z honeypotového pokusu kde se píše:
However, we believe that running an otherwise well-secured SSH server on a nonstandard high port can help reduce its vulnerability to brute-force attacks without exposing the server to additional risk. We also note that all three honeypots used in this study ran a second SSH server on a high port, which was used for maintenance and control purposes. No malicious login attempts directed at the servers running on these ports were observed during the same period that over 100,000 attacks were observed on the default SSH port.). Naproti tomu k Vaší (resp. Kubečkově) teorii, že automaty používají portscany na detekci ssh neexistuje empirický údaj, který by to potvrzoval. Takže si prosím sestavte honeypot a něco si tam naměřte a pak se budeme bavit dál.
Máte tam chybu v měření -- příliš malý vzorek.U mě jeden rok uptime bez pokusu o nabourání není malý vzorek. Honeypot popsaný v té zprávě běžel nejdéle 2x 6 týdnů.
Pravděpodobnosti tohoto druhu se musí spočítat na základě nějakých odhadů, ne z měření.A kde ty odhady vezmete?
To je jako kdybyste z měření odvozoval pravděpodobnost závažné havárie v jaderné elektrárně.Vždyť se to tak dělá. U reaktoru jsou čidla, která měří neutrony. Dál si to domyslíte sám.
Není to k ničemu, může mi to pomoci odhalit typ útoku, který bych jinak nerozpoznal.Ano, může. Ale opravdu se to špatně hledá, pokud to není opravdu něco tak závažně nového, že se o tom píše všude. (Tím myslím způsob provedení útoku a instalace rootkitu, nikoliv to, že v ssh je díra.)
Samozřejmě pokud chci mít jistotu, musím předpokládat, že server byl napaden a já jsem to neodhalilV tom předpokladu si musíte udělat rozumnou mez, jinak dojdete každý den k závěru, že server je napaden, a nakonec ho raději vypnete. Ale to je už oblast detekce, ne prevence. Tudíž míchat do toho přesun portu nemá smysl.
V některých případech -- třeba pokud by byl znám exploit na SSH a neexistovala oprava -- bych jej jako nouzové řešení použil, ale jako běžné zabezpečení ne. Pokud bych měl potřebu něco zabezpečit ještě víc, pouhé omezení na IP adresy bych nepovažoval za dostatečné zabezpečení.Ale Vy jste souhlasil s tím, že je vhodné tento scénář předpokládat, ačkoliv ještě nenastal. Tak mi tedy vysvětlete, jaké jiné dodatečné zabezpečení máte, když IP filtr je podle Vás nedostatečný.
Aha, takže je to takový chroot, ze kterého se nejde dostat na roota, ale přitom to vlastně jde. A spravuje to Chytrá Horákyně?Nerozumím. Co je na tom telnetu nebo celém řešení špatného?
Pokud nedůvěřuju zabezpečení klíčem, neobejdu to přece tím, že použiju nějaký ještě nižší stupeň zabezpečení.Dobré heslo není nižší stupeň zabezpečení. (Míněno v tomto případě, než mě zase někdo začne brát na vidle.)
Ale připadá mi zbytečné bránit se proti chybě SSH ale zůstat náchylný na chybu šifrovacího algoritmu, jeho implementace ve společné knihovně, chybu při generování klíčů a náhodných čísel atd. atd., když za stejnou cenu můžu mít ochranu, která bude fungovat i proti těmhle dalším typům chyb či útoků.Tak znova: pokud Vám to vadí, dejte si tam ten telnet. Ale SSH přes heslo má s openvpn společného kódu opravdu málo. (Můžu použít různé algoritmy pro transport obou.) Dobře, abychom měli jistotu, dáme tam telnet. Ale ten se Vám taky nějak nelíbil.
Zabezpečení by se nemělo dělat tak, že si udělám seznam možných způsobů průniku, a pak se každý zvlášť pokusím nějak zalepit. Mělo by se dělat obecně a na konkrétních typech průniků si maximálně můžu kontrolovat, jestli jsem něco nepřehlédl.Právě naopak. Dobře napsaný seznam problémů s konkrétními kroky k jejich odstranění je první věc, na kterou se Vás každý auditor zeptá. Nějaké "vyřešil jsem to obecně" obvykle pouze znamená, že nevíte, čemu přesně čelíte. A pak máte dobrou šanci, že jste na něco zapomněl.
Co to prosím pěkně blábolíte? O praktickém využití airbagů existují empirické údajeA o praktickém napadení počítačů snad ne?
O tom, že automatizované útoky na SSH používají téměř výhradně port 22, existují také empirické údajeO čem se tady pořád bavíme? Nejprve vyvraťte tvrzení, že může dojít i k útoku na SSH na jiném portu, než je 22. Pokud ho vyvrátit nedokážete a přesto nějaká bezpečnostní opatření zakládáte na domněnce, že útočník nebude útočit na jiný port, než 22, prostě to jako chlap přiznejte a řekněte: "moje zabezpečení závisí na tom, že doufám, že útočník nebude útočit na jiný port, než 22".
Ale Vy jste souhlasil s tím, že je vhodné tento scénář předpokládat, ačkoliv ještě nenastal. Tak mi tedy vysvětlete, jaké jiné dodatečné zabezpečení máte, když IP filtr je podle Vás nedostatečný.Snad si to v diskuzi dokážete najít sám a já to sem nebudu muset psát potřetí.
Nerozumím. Co je na tom telnetu nebo celém řešení špatného?To, že nejprve útočníka pustíte do shellu na cílový počítač (předpokládáte, že skrz SSH pronikne), a pak se snažíte nějak bránit. Lokální útočník má mnohem více možností než útočník vzdálený a je tedy mnohem větší šance, že se mu podaří ochranu prolomit.
Dobré heslo není nižší stupeň zabezpečení. (Míněno v tomto případě, než mě zase někdo začne brát na vidle.)Heslo se někam odesílá, klíč nikoli. Heslo budete pravděpodobně někam psát, klíč nikam opisovat nemusíte. Řekl bych, že je víc možností jak zaútočit na heslo než na klíč.
Tak znova: pokud Vám to vadí, dejte si tam ten telnet. Ale SSH přes heslo má s openvpn společného kódu opravdu málo. (Můžu použít různé algoritmy pro transport obou.) Dobře, abychom měli jistotu, dáme tam telnet. Ale ten se Vám taky nějak nelíbil.A proč to neuděláte opačně? Telnetem se přihlásit na daný počítač do chrootu a odsud se přes SSH připojit na roota? Nebo se telnetem přihlásit na vzdálený počítač a z něj dělat VPN? Pokud jsou to dvě nezávislé ochrany, na pořadí jejich aplikace přece nemůže záležet.
Právě naopak. Dobře napsaný seznam problémů s konkrétními kroky k jejich odstranění je první věc, na kterou se Vás každý auditor zeptá. Nějaké "vyřešil jsem to obecně" obvykle pouze znamená, že nevíte, čemu přesně čelíte. A pak máte dobrou šanci, že jste na něco zapomněl.Auditor ovšem nedělá zabezpečení, ale pouze jeho kontrolu. Když pubertální synek odjíždí na víkend do přírody, maminka taky udělá "audit" jeho batohu -- "máš teplé ponožky?", "máš kapesník?", "máš s sebou dost jídla?" Zkuste si představit, jak by to vypadalo, kdyby se podle tohoto seznamu vypravoval.
O čem se tady pořád bavíme?O tom, že přesunutí portu ssh démona sníží počet automatizovaných útoků na něj.
moje zabezpečení závisí na tom, že doufám, že útočník nebude útočit na jiný port, než 22Já v nic takového nedoufám a moje zabezpečení na tom nezávísí.
Snad si to v diskuzi dokážete najít sám a já to sem nebudu muset psát potřetí.Nezlobte se, ale nemůžu to najít, buďte tak hodný a napište to znovu.
To, že nejprve útočníka pustíte do shellu na cílový počítač (předpokládáte, že skrz SSH pronikne), a pak se snažíte nějak bránit. Lokální útočník má mnohem více možností než útočník vzdálený a je tedy mnohem větší šance, že se mu podaří ochranu prolomit.Zatímco u Vás pronikne rovnou na roota a má jistě mnohem více možností než ten můj uživatel v chrootu.
Telnetem se přihlásit na daný počítač do chrootu a odsud se přes SSH připojit na roota?Protože telnet přes otevřenou síť není dobrý nápad.
Pokud jsou to dvě nezávislé ochrany, na pořadí jejich aplikace přece nemůže záležet."Surely you're joking."
Když pubertální synek odjíždí na víkend do přírody, maminka taky udělá "audit" jeho batohu -- "máš teplé ponožky?", "máš kapesník?", "máš s sebou dost jídla?"Zatímco když Vy jedete na dovolenou, tak si seznam neuděláte, a pak zjistíte, že nemáte pastu na zuby.
O tom, že přesunutí portu ssh démona sníží počet automatizovaných útoků na něj.Teď jste mi to konečně osvětlil. My s Michalem Kubečkem se snažíme snížit na minimum počet úspěšných útoků a počet útoků nás nezajímá, vy se snažíte snížit na minimum počet útoků a počet úspěšných útoků vás nezajímá. No, pak se opravdu nemůžeme shodnout.
Nezlobte se, ale nemůžu to najít, buďte tak hodný a napište to znovu.Nezávislá ochrana -- např. povolení přístupu k SSH na firewallu nebo vůbec start SSH vyvolaný nějakým nezávislým kanálem -- třeba zpráva podepsaná privátním klíčem doručená přes SMS, GSM, UDP paket... Pokud tohle uděláte na externím firewallu, jste tak chráněn nejen před chybami v SSH, ale i před chybami firewallu a síťování jádra.
Pokud jsou to dvě nezávislé ochrany, na pořadí jejich aplikace přece nemůže záležet.Pokud si nezávislost ochrany definujete tak, že je to závislost na tom, že existuje ještě jiný druh ochrany, pak možná. Já si to tak nedefinuju, takže jsem to myslel naprosto vážně."Surely you're joking."
Protože telnet přes otevřenou síť není dobrý nápad.Zatímco telnet z kompromitovaného účtu je dobrý nápad?
Nemůžu si pomoct, ale základní a původní konflikt tady byl v tom, že vy se snažíte snížit počet úspěšných útoků a počet útoků vás nezajímá, zatímco proti vašemu konceptu stojí myšlenka snížení počtu úspěšných útoků se současným snížením počtu neúspěšných útoků. Proč tady neustále plantáte, že se někdo pustí útočníka dovnitř, protože se brání jenom přestěhováním portu je mi záhadou To zde nikdo pokud vím nenavrhoval..
Byli jse to vy s M.K., kteří jste zlehčovali situaci, kdy dojde k exploitu a bylo vám úplně šuma fuk, jestli se dovnitř dostane jeden cracker na nestandardním portu, nebo jeden cracker + 200 automatů na standardním portu, nemluvě o reálné šanci že v daný okamžik se o to pokusí jen automaty a ty změna portu zastaví a vyhráli jste zcela. Co si mám asi pak myslet, když je vám to jedno, jestli je průniků 100 nebo jeden? Když už se něco pokazí, tak kapituluju zcela?
Nemůžu si pomoct, ale základní a původní konflikt tady byl v tom, že vy se snažíte snížit počet úspěšných útoků a počet útoků vás nezajímá, zatímco proti vašemu konceptu stojí myšlenka snížení počtu úspěšných útoků se současným snížením počtu neúspěšných útoků. Proč tady neustále plantáte, že se někdo pustí útočníka dovnitř, protože se brání jenom přestěhováním portu je mi záhadou To zde nikdo pokud vím nenavrhoval.Pokud změnu portu považujete za dostatečně účinnou ochranu, jistě jí svěříte ochranu počítače bez nějakých dalších podpůrných ochran -- nastavte rootovi prázdné heslo, povolte přihlášení heslem odkudkoli, přesuňte ssh na jiný port, a můžete čekat, jak dlouho server vydrží.
Co si mám asi pak myslet, když je vám to jedno, jestli je průniků 100 nebo jeden?Ano, je mi to jedno. Já rozlišuju jenom dva stavy -- žádný průnik, alespoň jeden průnik.
Pokud změnu portu považujete za dostatečně účinnou ochranu, jistě jí svěříte ochranu počítače bez nějakých dalších podpůrných ochran -- nastavte rootovi prázdné heslo, povolte přihlášení heslem odkudkoli, přesuňte ssh na jiný port, a můžete čekat, jak dlouho server vydrží.
Na toto téma se s vámi již odmítám bavit. Dělá vám problém opustit tuto myšlenku, kterou jste si sám pro tuto diskuzi vymslel?
Ano, je mi to jedno. Já rozlišuju jenom dva stavy -- žádný průnik, alespoň jeden průnik.
Přesně to jsem chtěl slyšet. Po mě potopa. Dostali mě, tak ať jsou škody co největší.
Na toto téma se s vámi již odmítám bavit. Dělá vám problém opustit tuto myšlenku, kterou jste si sám pro tuto diskuzi vymslel?Nedělá mi problém tu myšlenku opustit. Stačí, když někdo napíše, co je na té myšlence špatně.
Přesně to jsem chtěl slyšet. Po mě potopa. Dostali mě, tak ať jsou škody co největší.Sedíte si na vedení? Já dělám vše proto, aby můj počítač nebyl napaden, a pokud by byl napaden, považuju to za obrovský průšvih. Vy ne, vy se snažíte o to, aby vás nenapadlo 100 crackerů, ale jenom 10. Buďte rád, že takhle neuvažují projektanti atomových elektráren nebo třeba zabezpečovacích systémů na železnici. „To se stává, že se občas nějaké vlaky srazí, to nemá smysl dělat kvůli tomu nějaké lepší zabezpečovací zařízení. Ale hlavně musí jezdit krátké vlaky, aby ta nehoda vždy postihla jenom co nejmíň lidí.“
Na vedení si sedíte vy. Já totiž netvrdím, že to co děláte vy je špatně. Já přeci udělám přesně totéž co vy. Jak mě může napadnout nějakých 10 útočníků a vás nikdo? Mé nastaveníé je přeci úplně stejné jako to vaše!
Spor se vede o to, zda udělat něco navíc! A v tom je právě ten problém. Vy říkáte, že přesunout navíc port nemá žádný vliv a zbytečně to otravuje administrátora, protože jste si to přece vypočítal. Já vám říkám, že jsou situace, kdy navíc přesunutí portu by vám mohlo zachránit krk. A ta situace není tak nepravděpodobná, jak jste si vypočítal.
Jestli mi ještě jednou budete naznačovat, že moje zabezpečení se týká pouze portu a proto jsem vůl, budu si už skutečně myslet, že máte problém s porozuměním psaného textu. Ach jo 
vy se snažíte snížit na minimum počet útoků a počet úspěšných útoků vás nezajímáZajímá. A snad se shodneme i na tom, že počet úspěšných útoků nemůže převýšit počet všech útoků. Takže snížení počtu celkových útoků může snížit počet úspěšných útoků, a to i tak, že jich bude nula. (To nastane zejména v situaci, kdy počet celkových útoků bude nula.
Já bych Vám vřele doporučil, abyste se začal zajímat i o neúspěšné útoky.
Nezávislá ochrana -- ...Tyhle věci tedy na serveru máte, nebo jste o nich jen mluvil? O povolení na firewallu již víme že nemáte. Co ty SMS? Ten externí firewall máte?
Já si to tak nedefinuju, takže jsem to myslel naprosto vážně.Nechápu. Přece Vám musí být jasné, že telnet přes síť a telnet na localhost nebo přes point-to-point linku jsou z hlediska odposlechu naprosto někde jinde. Tudíž Vám musí být jasné, že nelze zaměnit pořadí ssh a telnet.
Zatímco telnet z kompromitovaného účtu je dobrý nápad?Chytrý útočník může podvrhnout program telnet tak, aby zaznamenal heslo, nebo se na něj připojit pomocí PTRACE (v podstatě jakýkoliv program v tom chrootu je takto napadnutelný). Heslo se ale doví až v okamžiku, kdy bude zadáno. Což nemusí být nutně ihned po tom, co byl účet kompromitován. Je poměrně vysoká šance (opět v závislosti na tom jak moc (ne)odfláknete detekci průniku), že se o prolomení chrootu dozvíte a heslo zadáno nebude. Samozřejmě, pokud Vám to nestačí, můžeme nabalovat další metody, jak zesložitit cestu z toho chrootu. Tokeny, jednorázová hesla. Ale ani to není dokonalé, protože když bude útočník "online" ve chvíli, kdy heslo zadáte, může Vám ten telnet znásilnit a pracovat dál v přihlášeném sezení. Můžete myšlenkově pokračovat dál, v každém případě jsme ale s diskusí úplně někde jinde, než když se někdo dostane na toho roota hned napoprvé.
Nedělá mi problém tu myšlenku opustit. Stačí, když někdo napíše, co je na té myšlence špatně.Špatně je to, že tu myšlenku s Vámi nikdo probírat nechce (tedy aspoň ne já), ale Vy se k ní přesto neustále vracíte.
Sedíte si na vedení? Já dělám vše proto, aby můj počítač nebyl napaden, a pokud by byl napaden, považuju to za obrovský průšvih. Vy ne, vy se snažíte o to, aby vás nenapadlo 100 crackerů, ale jenom 10. Buďte rád, že takhle neuvažují projektanti atomových elektráren nebo třeba zabezpečovacích systémů na železnici. „To se stává, že se občas nějaké vlaky srazí, to nemá smysl dělat kvůli tomu nějaké lepší zabezpečovací zařízení. Ale hlavně musí jezdit krátké vlaky, aby ta nehoda vždy postihla jenom co nejmíň lidí.“Vy si lžete do pusy. Ještě před chvílí jste tvrdil, že náklad v případě prostřelení bude asi tisíc korun a budete to mít hotové raz dva. Teď je to najednou obrovský průšvih. A to tak obrovský, že se ani nenamáháte si nastavit iptables. Teď Vás možná nařknu, tak mě když tak pošlete do pr., ale připadá mi že spravujete systémy, které když kleknou tak po nich neštěkne ani pes, a že toho hodně o reálném světě nevíte. IT infrastruktura nejsou jen webové stránky. Vy dokonce ani nevíte, jak uvažují projektanti atomových elektráren nebo železničních systémů. Oni totiž uvažují stejně jako já. Oni nejsou binární jako vy, ale uvědomují si, že katastrofa nastat může vždy a selhat může všechno. Pracují s pravděpodobnostmi a empiricky naměřenými daty. Mají seznamy možných problémů a konkrétních protiopatření. Chodí k nim pravidelně auditoři. Pokud přesun sshd atomové elektrárny na jiný port zabije místo deseti milionů lidí jen tři miliony, tak to udělají.
Zajímá. A snad se shodneme i na tom, že počet úspěšných útoků nemůže převýšit počet všech útoků. Takže snížení počtu celkových útoků může snížit počet úspěšných útoků, a to i tak, že jich bude nula. (To nastane zejména v situaci, kdy počet celkových útoků bude nula.Jenže celkového počtu útoků 0 dosáhnete jen vypnutím počítače.
Nechápu. Přece Vám musí být jasné, že telnet přes síť a telnet na localhost nebo přes point-to-point linku jsou z hlediska odposlechu naprosto někde jinde. Tudíž Vám musí být jasné, že nelze zaměnit pořadí ssh a telnet.Jenže tady se nebavíme o obyčejném telnetu na localhost, tady se bavíme o telnetu ze zkompromitovaného účtu v situaci, kdy došlo k útoku na nějakou chybu v softwaru.
Chytrý útočník může podvrhnout program telnet tak, aby zaznamenal heslo, nebo se na něj připojit pomocí PTRACE (v podstatě jakýkoliv program v tom chrootu je takto napadnutelný). Heslo se ale doví až v okamžiku, kdy bude zadáno. Což nemusí být nutně ihned po tom, co byl účet kompromitován. Je poměrně vysoká šance (opět v závislosti na tom jak moc (ne)odfláknete detekci průniku), že se o prolomení chrootu dozvíte a heslo zadáno nebude.To všechno platí ale jen za předpokladu, že ona softwarová chyba byla zrovna v SSH. Ale co když byla v nějaké systémové knihovně, v jádru?
Špatně je to, že tu myšlenku s Vámi nikdo probírat nechce (tedy aspoň ne já), ale Vy se k ní přesto neustále vracíte.Jenže o téhle myšlence je celá diskuze. Celou dobu se tady bavíme o tom, zda má smysl posilovat jiný než nejslabší článek řetězu. Já pořád tvrdím, že posilovat se má nejslabší článek, a pak se tu najde několik diskutujících, kteří se mne neustále snaží přesvědčovat, že posilovat nejslabší článek je sice fajn, ale dají se posilovat i jiné články.
Vy si lžete do pusy. Ještě před chvílí jste tvrdil, že náklad v případě prostřelení bude asi tisíc korun a budete to mít hotové raz dva. Teď je to najednou obrovský průšvih.Tisíc korun a hotové raz dva se týkalo případu, kdy nějaký automat nainstaluje na tisíce počítač rootkit. Skutečný průšvih je ale to, když se někdo dostane na váš počítač cíleně a ví, co tam chce.
A to tak obrovský, že se ani nenamáháte si nastavit iptables.A nejen to. Já na bezpečnost kašlu tak, že server dokonce ani nekropím svěcenou vodou!
Teď Vás možná nařknu, tak mě když tak pošlete do pr., ale připadá mi že spravujete systémy, které když kleknou tak po nich neštěkne ani pes, a že toho hodně o reálném světě nevíte. IT infrastruktura nejsou jen webové stránky.Třeba ve školní síti s cca 350 uživateli byli dost nervózní i z každého výpadku internetového spojení, že se musí komunikovat se zřizovatelem atd. Takže jsem místo blbostí typu přesouvání ssh na jiný port řešil nejslabší místo, kterým bylo ADSL. Problémy se zabezpečením sítě nebo serverů nebyly žádné.
Vy dokonce ani nevíte, jak uvažují projektanti atomových elektráren nebo železničních systémů. Oni totiž uvažují stejně jako já. Oni nejsou binární jako vy, ale uvědomují si, že katastrofa nastat může vždy a selhat může všechno. Pracují s pravděpodobnostmi a empiricky naměřenými daty. Mají seznamy možných problémů a konkrétních protiopatření. Chodí k nim pravidelně auditoři. Pokud přesun sshd atomové elektrárny na jiný port zabije místo deseti milionů lidí jen tři miliony, tak to udělají.Ne, neudělají. Mají omezený rozpočet, takže budou dělat věci, které odvrátí věci s horším součinem pravděpodobnosti a následků. Přesouvání SSH na jiný port je jako kdyby dali v elektrárně ostnatý drát za hlavní bránu, kdyby brána selhala a někdo tudy chtěl projet. Ale už by stejné opatření neudělali u ostatních bran. A tvrdili by, že lepší něco než nic, a když útočník náhodou projede hlavní branou, tak ho to zastaví. V elektrárně to zcela jistě udělají jinak. zanalyzují, jaké je riziko, že selže primární zabezpečení bran, a pokud dospějou k tomu, že je nepřípustně vysoké, zabezpečí dalším stupněm ochrany všechny brány. Pokud se vy obáváte bezpečnostní chyby v softwaru, i pokud se obáváte jen bezpečnostní chyby v SSH a jádro a další věci považujete za absolutně bezpečné, nemůžete to řešit přesunem SSH na jiný port – je spousta druhů chyb, u kterých přesun na jiný port nebude znamenat žádné zlepšení.
Jenže celkového počtu útoků 0 dosáhnete jen vypnutím počítače.Nejen. To je zajímavé, jak neustále ignorujete ten fakt, že na ten ssh démon na jiném portu bylo nula útoků.
Jenže tady se nebavíme o obyčejném telnetu na localhost, tady se bavíme o telnetu ze zkompromitovaného účtu v situaci, kdy došlo k útoku na nějakou chybu v softwaru.Překrouceno. Zapomeňte na všechno ostatní. Mám standardní a nezkompromitovaný stroj. Tím, že na něj polezu vzdáleně telnetem, si takzvaně nadělám do bot. Když na něj polezu VPNkem a pak lokálně telnetem tak se nestane nic.
To všechno platí ale jen za předpokladu, že ona softwarová chyba byla zrovna v SSH. Ale co když byla v nějaké systémové knihovně, v jádru?Když je v knihovně tak je to to samé jako v ssh (nebo jiném programu, který tu knihovnu používá tak, že se ho chyba týká). Když je v jádru? Když je chyba v jádru taková, že Linus Torvalds má všude okamžitě vzdáleně roota tak mi pomůže už snad jen ta svěcená voda.
Třeba ve školní síti s cca 350 uživateli byli dost nervózníTo je pěkné, že školáci byli nervózní. Kolik peněz Vás ten výpadek stál, kolik lidí při tom bylo ohroženo na životě? Nic, nula. To se pak nedivím, že neřešíte pravděpodobnosti. Mimochodem, sepsal jste aspoň někam ten ADSL problém + řešení, aby se to nemuselo řešit zase příště, nebo to příští správce bude vymýšlet znova?
Přesouvání SSH na jiný port je jako kdyby dali v elektrárně ostnatý drát za hlavní bránu, kdyby brána selhala a někdo tudy chtěl projet.Já se v těch Vašich trefných příměrech začínám ztrácet. Prosím Vás, vyjádřete se nějak přímočaře a v rozmezí entit, které jsou alespoň trochu příbuzné tomu, na co reagujete.
další věci považujete za absolutně bezpečnéJá nepovažuji za absolutně bezpečné vůbec nic.
je spousta druhů chyb, u kterých přesun na jiný port nebude znamenat žádné zlepšení.Samozřejmě. Ale narozdíl od Vás já beru i to, co odstraní nějaký specifický problém a ne jen to, co odstraní všechny problémy jednou a provždy™.
Nejen. To je zajímavé, jak neustále ignorujete ten fakt, že na ten ssh démon na jiném portu bylo nula útoků.Protože si toho počítače nikdo nevšiml a nikoho nezajímal. Zabezpečení se ale opravdu nedělá pro případ, kdy se na váš stroj nikdo nechce dostat.
Překrouceno. Zapomeňte na všechno ostatní. Mám standardní a nezkompromitovaný stroj. Tím, že na něj polezu vzdáleně telnetem, si takzvaně nadělám do bot. Když na něj polezu VPNkem a pak lokálně telnetem tak se nestane nic.Ano. Ale není to zásluha toho telnetu, ale toho VPN.
Když je v knihovně tak je to to samé jako v ssh (nebo jiném programu, který tu knihovnu používá tak, že se ho chyba týká).Takže pokud je třeba v síťování, týká se každého programu, který ho používá. Takže na sebe můžete navršit třeba 10 různých SSH, VPN, telnetů a dalších, a útočník je projde všechny stejným způsobem.
Když je v jádru? Když je chyba v jádru taková, že Linus Torvalds má všude okamžitě vzdáleně roota tak mi pomůže už snad jen ta svěcená voda.Vidíte, a já pokud bych si měl vsadit, zda bude bezpečnostní díra spíš ve vanilce nebo v distribučním OpenSSH, tipoval bych to jádro a SSH považuju za bezpečnější. Takže než já začnu řešit neznámé bezpečnostní díry v SSH, budu muset vyřešit ty v kernelu.
To je pěkné, že školáci byli nervózní. Kolik peněz Vás ten výpadek stál, kolik lidí při tom bylo ohroženo na životě? Nic, nula. To se pak nedivím, že neřešíte pravděpodobnosti. Mimochodem, sepsal jste aspoň někam ten ADSL problém + řešení, aby se to nemuselo řešit zase příště, nebo to příští správce bude vymýšlet znova?Se zřizovatelem zpravidla nekomunikují žáci, ale vedení školy. Já pravděpodobnosti právě řeším, a postupuji od těch s větším součinem pravděpodobnost·škoda po ty s menším součinem. Sice bych uměl udělat tisíce jednoduchých opatření proti věcem s pravděpodobností nula celá nula nic a vzniklou škodou 5 Kč, ale nedělám to – místo toho řeším to, co je pravděpodobnější a je z toho větší škoda. ADSL problém je nekvalitní vedení a řešení je jiný způsob připojení. Nový správce to vymýšlet znova nemusí, ten po nástupu vymyslel virus, který smazal data z hlavního disku i zálohu z druhého disku, vymazal další zálohu z DVD-R, šířil se v DBF souborech, odpojil školu na několik týdnů od internetu a ranil dotyčného správce slepotou, takže dokumentaci sítě nedočetl ani do půlky první strany. Ano, největší bezpečnostní díra v síti je správce, který netuší, co dělá – ale proti téhle chybě jsem síť zabezpečit nedokázal (tedy jinak, než že bych setrval na svém místě).
Já se v těch Vašich trefných příměrech začínám ztrácet. Prosím Vás, vyjádřete se nějak přímočaře a v rozmezí entit, které jsou alespoň trochu příbuzné tomu, na co reagujete.Je to stále totéž. Vy máte řešení – přesun SSH na jiný port. K němu jste našel nějaký problém – chybu v SSH, která umožní obejít autentizaci. A je vám úplně jedno, že existují daleko pravděpodobnější typy útoků, proti kterým neděláte nic. Já se pak neustále dokola ptám, k čemu ta opatření proti problému s pravděpodobností X, když problémy s pravděpodobností 1000X ponecháváte bez povšimnutí.
Protože si toho počítače nikdo nevšiml a nikoho nezajímal.To není pravda, protože se o něj zajímaly ty automaty.
Takže pokud je třeba v síťování, týká se každého programu, který ho používá. Takže na sebe můžete navršit třeba 10 různých SSH, VPN, telnetů a dalších, a útočník je projde všechny stejným způsobem.Ano, pokud je taková chyba, tak je mi deset vrstev k ničemu. V ostatních případech k ničemu nebudou. Dobře, zamysleme se, jak můžeme vyřešit problém desetivrstvé chyby. Nevím, jak byste na to šel Vy, ale já bych ten počítač odpojil od [veřejné] sítě. A to již na začátku jeho kariéry, a ne až ta chyba bude někde na bugtraqu. Samozřejmě bych tím přišel o spoustu vlastností, ale je-li mi bezpečnost tak milá, že nesmím připustit ani takovouto chybu, nemám moc na výběr. Mimochodem, tohle je jeden z přístupů u těch Vašich elektráren. Data, která se naměří (nevím přesně jaká, ale jsou to nějaké chemické analýzy), jsou na PC bez sítě a přesouvají se maximálně na záložní CD. A ono to není ani tak kvůli hax0rům, ale aby se vyloučil průser zkrze chybující ovladač síťovky.
Takže než já začnu řešit neznámé bezpečnostní díry v SSH, budu muset vyřešit ty v kernelu.No a jak je tedy řešíte. Je to stejné jako u těch knihoven. Když chci mít jistotu, že přečkám průsery v jádře, mám vedle ještě jeden stroj vykonávající totéž, ale například na jádře Windows (ne, to není vtip, ono to skutečně funguje).
Vy máte řešení – přesun SSH na jiný port. K němu jste našel nějaký problém – chybu v SSH, která umožní obejít autentizaci.Ne, to je zase naruby. Nejdřív je problém, pak řešení.
Já se pak neustále dokola ptám, k čemu ta opatření proti problému s pravděpodobností X, když problémy s pravděpodobností 1000X ponecháváte bez povšimnutí.Ale to Vaše "když" je nepravdivé, takže se ptáte špatně.
Dobře, zamysleme se, jak můžeme vyřešit problém desetivrstvé chyby. Nevím, jak byste na to šel Vy, ale já bych ten počítač odpojil od [veřejné] sítě. A to již na začátku jeho kariéry, a ne až ta chyba bude někde na bugtraqu. Samozřejmě bych tím přišel o spoustu vlastností, ale je-li mi bezpečnost tak milá, že nesmím připustit ani takovouto chybu, nemám moc na výběr. Mimochodem, tohle je jeden z přístupů u těch Vašich elektráren. Data, která se naměří (nevím přesně jaká, ale jsou to nějaké chemické analýzy), jsou na PC bez sítě a přesouvají se maximálně na záložní CD. A ono to není ani tak kvůli hax0rům, ale aby se vyloučil průser zkrze chybující ovladač síťovky.Souhlas.
No a jak je tedy řešíte. Je to stejné jako u těch knihoven. Když chci mít jistotu, že přečkám průsery v jádře, mám vedle ještě jeden stroj vykonávající totéž, ale například na jádře Windows (ne, to není vtip, ono to skutečně funguje).Také souhlas.
Jaktože je nepravdivé? Vy výše uvedená opatření praktikujete v praxi? Nebo snad považujete chybu v jádře nebo v síťování za řádově méně pravděpodobnou, než chybu v OpenSSH umožňující obejít přihlašování?Já se pak neustále dokola ptám, k čemu ta opatření proti problému s pravděpodobností X, když problémy s pravděpodobností 1000X ponecháváte bez povšimnutí.Ale to Vaše "když" je nepravdivé, takže se ptáte špatně.
Vy výše uvedená opatření praktikujete v praxi?Já v jaderné elektrárně nepracuji, ale u některých systémů, se kterými mám/měl jsem co do činění, jsou/byla bezpečnostní pravidla nastavena podobně jako je popsáno.
Nebo snad považujete chybu v jádře nebo v síťování za řádově méně pravděpodobnou, než chybu v OpenSSH umožňující obejít přihlašování?Pokud se bavíme o chybách v knihovně nebo jádře v takovém rozsahu, jako jsme uvažovali, tak rozhodně ano. Navíc proti těmto katastrofálním chybám skutečně není moc pomoci, nechci-li server zavřít někam do sklepa. Pak už je potřeba dopilovat spíše ty metody detekce průniku. Zatímco proti (jednomu) děravému démonovi jsou ještě poměrně široké možnosti preventivních opatření.
Pokud se bavíme o chybách v knihovně nebo jádře v takovém rozsahu, jako jsme uvažovali, tak rozhodně ano.To by mne zajímalo, co vás k tomu vede. Pokud vím, OpenSSH píšou lidi zabývající se především bezpečností (patche do toho pak už v distribucích dělá kde kdo). Do jádra se klidně dostane kód, který při držení zámku dělá takové hlouposti, jako je výpis do logu – přičemž „pod zámkem dělat skutečně jen to, k čemu je zámek potřeba“ je snad první pravidlo programování se zámky.
Navíc proti těmto katastrofálním chybám skutečně není moc pomoci, nechci-li server zavřít někam do sklepa. Pak už je potřeba dopilovat spíše ty metody detekce průniku. Zatímco proti (jednomu) děravému démonovi jsou ještě poměrně široké možnosti preventivních opatření.Takže děláte to opatření proto, že to udělat jde, ne proto, že byste už všechny pravděpodobnější problémy ošetřil?
Vede mne k tomu pozorování, že v různých démonech bylo za posledních deset let chyb jak nasr*no, zatímco chyba v jádře která by měla výše uvedené katastrofální důsledky nebyla žádná.Nebavíme se o různých démonech, bavíme se o OpenSSH. Já jsem v mé distribuci žádnou podobnou chybu v OpenSSH nezaznamenal, takže můžu spát klidně, přesun SSH na jiný port by mi v ničem nepomohlo.
Ani Váš příklad se zbytečně dlouhým zámkem zřejmě k této chybě nepovede, ačkoliv může způsobit jiné potíže.Ano, způsobila pády systému teď na přelomu roku kvůli přestupné sekundě.
9.1.2009 20:18
xkucf03 | skóre: 49
| blog: xkucf03
Takže snížení počtu celkových útoků může snížit počet úspěšných útoků, a to i tak, že jich bude nula.
Jenže vada na kráse tohoto přístupu je v tom, že nestandardní porty, jakožto dost primitivní řešení, odfiltrují jako první ty nejméně nebezpečné útočníky – tudíž efekt tohoto řešení se vyplácá na problémy, které nepotřebujeme řešit*, zatímco skutečně nebezpečných útočníků se nedotkne. Přijde mi to podobné, jako kdybys provozoval HTTP server na jiném portu než 80 a uživatelům dával URL s tímto portem, protože útočník, hledající děravý WordPress nebo Joomlu, je bude hledat právě na portu 80.
Musím sice uznat, že změna portu může pomoci proti náletům během prvních hodin po odhalení exploitu, ale:
Takže i když se ti podaří odfiltrovat devět útočníků, je to na nic, protože toho desátého borce neodfiltruješ – stroj je prostě napadený a ty ho musíš přeinstalovat, obnovit ze zálohy a dát dokupy zbytek nezálohovaných dat.
*) crackeři, kteří doufají, že naše hesla najdou ve slovníku.
**) zajímavá data, známá služba, kterou by stálo za to shodit…
***) přínosy pro bezpečnost jsou sice nezáporné, ale jak moc se blíží nule?
které nepotřebujeme řešit*Vy je potřebujete řešit, a také je nějak řešíte.
Takže i když se ti podaří odfiltrovat devět útočníků, je to na nic, protože toho desátého borce neodfiltruješTaky se na to můžeme podívat tak, že mám deset serverů a devět z nich napadeno nebylo.
***) přínosy pro bezpečnost jsou sice nezáporné, ale jak moc se blíží nule?Nevím, zkuste to spočítat. Já už jsem konkrétních čísel vyplodil dost.
Odfiltrování všech brute force útoků na hesla takovým jednoduchým trikem bych neviděl jako vadu na kráse.Všude uvádíte, že nebudete čekat, až se exploit na SSH objeví, že opatření musí být provedená předem. Evidentně ale čekáte na to, až se objeví (resp. až vy zaznamenáte) útoky na SSH na nestandardních portech, a bránit se budete až potom. Není to nedůslednost?
A to že to zjistíte vyřeší váš problém že byl napaden a data vyzrazena?
Začínám mít pocit, že to stále více nechápu.
Proč? Vyberu si jen pár lukrativních cílů, nebudu se zajímat o domácí PC. Vy dopředu předpokládáte že cracker je buď naprostý idiot nebo naprostý génius?
Já možná nevím o počítačové bezpečnoti ani zbla, ale kdybych chtěl zneužít dvouhodinové okno, zkusím pouze malý omezený počet "lukrativnívch" cílů a poberu tam co se dá. Nevím proč bych měl útočit hromadně na všechny?
Ale to už je jen vaše zbožné přání.
Jsem cracker. Nejsem mistr svého oboru, ale nejsem idiot. Nejsem sice schopen překonat důmyslné zabezpečení (těch je jak jste někde tvrdili většina), ale protože nejsem úplný idiot, vytipuju si pár objektů, na které to zkusím, protože útok plošně mi nic nepřinese. Mám jenom 2 hodiny, tak lepší 2 průniky s nějakým ziskem, než 10 000 průniků s nulovým ziskem. Zkusím 22, nefunguje. Buď je port jinde, nebo tam není vůbec. mám málo času, přesunu se vedle. Raději proniknu do 5 dalších strojů než abych řešil chybejicí port.
sshd, se kterým můžete začít komunikovat, pak jste idiot.
Ach jo. Mám dvě hodiny. možná ani to ne. otevřely se mi možnosti, které jsem doposud neměl a ani mít už nikdy nebudu. Vy možná zajdete na záchod a vytáhnete pro tento případ ve stupačkách schovaný předem vyrobený seznam cílů a portů. Alé já žádný takový seznam nemám.
Mám dvě hodiny. možná ani to ne. otevřely se mi možnosti, které jsem doposud neměl a ani mít už nikdy nebudu.Našel jste na internetu veřejně dostupný exploit na
sshd. Babička vás pustila na počítač jenom na dvě hodiny...
Pokud někdo objeví chybu v sshd, bude mu trvat mnohem víc než dvě hodiny jenom to, než napíše nějaký funkční exploit. S takovou vzácností (jenom on zná díru v sshd) a tím časem, co tomu musel věnovat, nebude zacházet tak, že oťukne pár počítačů aby tam nic nenašel a prozradil se. Věnuje čas i přípravě a vytipování cíle.
Pokud ničemu nerozumíte, jenom jste našel na internetu něco, čím se prý dostanete do nějakého sshd a získáte tam prej Administrátora nebo co, tak nemáte žádné dvě hodiny, ale několik dnů, spíš týdnů, zpoždění, a snažíte se zneužít chybu, kterou už mají všichni důležití zazáplatovanou. Dostanete se už tak jenom k těm, kteří na bezpečnostní záplaty kašlou.
Opět. Podle vás existují jen všeho schopní machři, a ničeho neschopní idioti. To snad ani nemůžete myslet vážně!
Je-li zveřejněn exploit, pak jej nemusím přeci vynalézat?
Opět. Podle vás existují jen všeho schopní machři, a ničeho neschopní idioti.Já se bráním proti těm všeho schopným, proti těm ostatním to pak jako obrana funguje také. Vaše představa, že neschopný idiot se nabourá tam, kde všeho schopný machr selhal, je úsměvná.
Je-li zveřejněn exploit, pak jej nemusím přeci vynalézat?Je-li zveřejněn, kde máte jaké dvě hodiny?
Ne. Vaše představa, že "žádný machr se mi tam nenaboural" z čehož vyplývá že "žádný neschopný idiot se mi tam nenaboural" je úsměvná.
Co když to žádný machr zrovna nezkoušel? Tím jste si jako statisticky dokázal, že žádný idiot se tam nemohl dostat, protože přece průniky od machrů jsou v počtu 0? Možná už by jste tu statistiku neměl tak žrát.
S vámi je to jak s tím známým vtipem:
90% dopraních nehod způsobí řidiči, kteří před jízdou nepili alkohol. Z toho jasně vyplývá, že chlastnání zvyšuje bezpečnost silničního provozu.
Stejně absurdní je vaše argumentace.
Ale vždyť to se snažím demonstrovat. Přesně tak je to absurdní spojovat průniky machrů s průniky idiotů a vyvozovat, že když né machr tak ani idiot, bez znalosti toho, proč ten machr nebyl žádný.
za předpokladu, že zabezpečení skutečně funguje.
V tom případě je třeba mít více stupňovou obranu, nebo se pletu?
a proč by ho nezkusil? než zjistí, který port to je, má nabouráno 10 jiných s portem 22. Kde je ta vaše maximalizace zisku s minimalizací nákladů? Najednou to neplatí?
Pro něj jste jen v kategorii lukrativní předvýběr. Má dvě hodiny. Buď se bude babrat s vámi a řešit každou anomálii, kterou jste mu přichystal, nebo napadne dalších 10, kteří žádnou anomálii nemají (abychom se netočili jen kolem portu, o portu blogpost není)
Pro něj jste jen v kategorii lukrativní předvýběr. Má dvě hodiny. Buď se bude babrat s vámi a řešit každou anomálii, kterou jste mu přichystal, nebo napadne dalších 10, kteří žádnou anomálii nemají (abychom se netočili jen kolem portu, o portu blogpost není)Kdo mu dal ty dvě hodiny? Vy, aby k něčemu byla vaše obrana? Pokud je nějaký server v kategorii "lukrativní předvýběr" pro zneužití exkluzivní zatím neznámé bezpečnostní díry, pak jednak dotyčný útočník už dávno ví, že
sshd není přesunutý na jiném portu (a kdyby bylo, věděl by, na kterém), jednak je tam spolu s dalšími servery, které mají plno anomálií jako schopné správce a zazáplatovaný a bezpečný software. Takže prkotina typu přesunutý port útočníka nezastaví. Mimochodem, obrana proti útoku na díru v démonu běžícím pod rootem je jediná -- nesmíte útočníka k tomu démonu vůbec pustit. Nějaká "obrana přihlašováním přes jiného uživatele" tedy nepřipadá v úvahu vůbec, protože útočník se nebude přihlašovat vůbec...
vždyť vy nic nečtete. Díra není neznámá, ale oznámená, a ty dvě hodiny (hodnotu si vymyslete jakou chcete) jsou nadefinovány dobou mezi zveřejněním exploitu a aplikací záplaty.
sshd, používají úplně jiné zabezpečení, než přesun sshd na jiný port.
já přeci nevím, jakou politiku dělá správce. A právě proto jdu cestou nejmenšího odporu ne?
sshd exploit, když je k dispozici tolik jednodušších způsobů, jak ovládnout nějaký počítač?
To už trošku zavání demagogií ne? Vymyslel jste si příklad 10 jiných z 10 členého seznamu, aby jste mi dokázal že to nejde?
Možnosti jsou neomezené, čas je omezený. Vždy mám v tomt modelovém případě dostatek cílů ale nedostatek času. Jsem li idiot, útočím na všechny a nemám nic. Jsem li obyčejný, vyberu si 100 a na 10 z nich vybraných podle cesty nejmenšího odporu zaůtočím, a třeba něco získám. Jsem -li machr, dostanu vás tak jako tak, bez ohledu na heslo nebo exploit. Je to jen otázka času.
Nechápu, jak si můžete myslet, že existují jen idioti a machři, a množina "obyčejný" je prázdná.
Nebo ještě lépe, množina obyčejný je sice neprázná, ale bude se chovat přesně tak jak si já představuji a běda jim, když nebudou, to pak nehraju, bůůůů.
používám vaši matematiku. Ze 100 serverů je 80 spravováno Kubečky, 20 pak Wire64. Umím-li se přihlásit na ssh, pak mám 80% šanci že se na portu 22 přihlásím. A přihlásím se hned. A když se náhodou trefím někam, kde port 22 neodpovídá co udělám? budu zkoušet 10 000 (nebo kolik jich je) portů s šancí 1:10 000, nemluvě o možnosti, že na daný stroj se přihlásit nelze, a nebo zkusím další stroj, který je s pravděpodobností 4:1 spravován kubečkem? Kde je ta vaše matamatika teď? Vám opravdu přijde logické zkoušet 10000 kombinací portů u jednoho stroje (IP), když už při projíti 100 kombinací IP adres mám 80 výher?
A když se náhodou trefím někam, kde port 22 neodpovídá co udělám? budu zkoušet 10 000 (nebo kolik jich je) portů s šancí 1:10 000
Ale tady přeci vůbec nejde o pravděpodobnost, útočník nepostupuje tak, že by náhodně vylosoval jedno číslo portu v naději, že se trefí. Jde o to, jak dlouho trvá to proscanovat. A to jsou řádově sekundy, dost možná ani to ne.
Nebo ještě lépe, množina obyčejný je sice neprázná, ale bude se chovat přesně tak jak si já představuji a běda jim, když nebudou, to pak nehraju, bůůůů.Tak proč si pořád představujete, že má útočník jen dvě hodiny času? Což je navíc úplně nereálná představa, která odpovídá opravdu jenom tomu, že útočník mohl po večeři na 2 hodiny k počítači, ale pak musí jít po zprávách spát, ráno přece vstává do školy.
Ale mě je přeci jedno kolik má času. Má omezený čas, a to je to podstatné. Omezený čas má jen do té doby, než aplikuju záplatu.
sshd, které na tom počítači běží. Tak naopak jste objevil na internetu nový exploit, a chcete ho někde použít? Pak nemáte cíl v žádném konkrétním počítači, netlačí vás čas a prostě si můžete skenovat jednu kombinaci IP:port za druhou a budete čekat, kde se to ujme.
Z mého pohledu jako správce mám buď na serveru důležitá data, která se nesmí dostat nikomu cizímu do rukou ani v případě, že by byla objevena díra v sshd, a pak používám jiné mechanizmy obrany -- rozhodně jen nepřesunu sshd na jiný port. Nebo tam tak důležitá data nemám, risknu provozovat tam jen tak sshd, pak se ale raději než přesouvání na jiný port budu věnovat jinému zabezpečení. Daleko pravděpodobnější, než že bude nalezena zneužitelná díra v sshd je třeba to, že někdo odpozoruje nebo odposlechne heslo k mému klíči, získá heslo roota uložené na "bezpečném" místě apod.
Takže pokud zvážím pravděpodobnost útoku na sshd, případné následky a "pracnost" změny portu, stále mi to vychází jako přespříliš pracné -- i přes to, jak jednoduchá je to změna.
Zkusím 22, nefunguje. Buď je port jinde, nebo tam není vůbec. mám málo času, přesunu se vedle.A to je zase tvoje zbožné přání.
jak to? Ještě před chvílí mi tady někdo šermoval kombinatorikou a najedou kombinatorika neplatí?
sshd, programování exploitu, tipování cílů...
To je porad dokolecka. On nekdo tvrdi, ze presun na jiny port pred cilenym utokem ochrani?
Nebylo to jeste zmineno, ale i pri cilenem utoku ma nestandardni port vyhody. Napriklad kdyz vam nekdo zacne posilat slovnikova hesla na port 12345, tak je zrejme, ze prituhuje, a vy muzete s touto informaci dale nejak nalozit.
P.S. IMHO pan Kubecek i pan Jirsak ve skutecnosti maji to nejparanoidnejsi nastaveni, jake si lze vubec predstavit - zprehazene porty, trojstupnove prihlasovani, zmenene loginy roota, atd. A podobne vysvetlovaci kampane slouzi k udrzeni neznale verejnosti na standardnim nastaveni, coz zpetne zajistuje efektivnost jejich obskurni konfigurace.
Napriklad kdyz vam nekdo zacne posilat slovnikova hesla na port 12345, tak je zrejme, ze prituhuje, a vy muzete s touto informaci dale nejak nalozit.
Tak to přituhuje už několik let. Jak s tím mám naložit? :-)
IMHO pan Kubecek i pan Jirsak ve skutecnosti maji to nejparanoidnejsi nastaveni, jake si lze vubec predstavit - zprehazene porty
Co si nejdřív ověřit aspoň to, u čeho to snadno lze?
Pokud mate pod palcem pocitace pentagonu a googlu, tak vam cachrovani s portama nepomuze. Administratorsky plebs je ale v jine situaci.
To byl pokus o nadsazku. A ne, neminim za kazdy nejapny zert prilipavat sest smajliku, aby pohopili uplne vsichni.
Cas? Jak dlouho vam po instalaci trva zamenit jedno cislo v konfiguraku, zvlast kdyz ten konfigurak budete editovat tak jako tak? I par stovek milisekund profika zdrzuje?
Oslnovat manazery tim, na jakem portu visi sshd, hmmm... to by me teda nenapadlo. Musim to vyzkouset!
Ok, tak zmena jednoho cisla ve ctyrech konfiguracich. V ramci celkove instalace a konfigurace jednoho serveru zjevne gargantuovsky ukol.
Obmenovat nemusite, protoze jestli si na vas dal nekdo tak zalezet, ze vas proskanoval celeho, ocekaval bych celkem vysokou pravdepodobnost toho, ze pri zmene si vas prohmata znovu.
On nekdo tvrdi, ze presun na jiny port pred cilenym utokem ochrani?
Wire.64 tvrdí, že jsou situace, kdy nestandardní port zvýší (nezanedbatelně) bezpečnost. Já a Filip Jirsák se z něj snažíme dostat příklad. Zatím jsme se dopídili jen jakéhosi scénáře, který považujeme za silně vykonstruovaný. Nevím jak vy, ale já opravdu nechci stavět bezpečnost na předpokladu, že cílený útočník, který považuje můj server za lukrativní cíl, nenajde-li sshd na portu 22, pokrčí rameny a zkusí štěstí jinde. Možná se takový najde, ale spoléhat na to by mi připadalo nezodpovědné.
Tak pro pořádek: sshd mi sedí na portu 22, účet s UID 0 se jmenuje root a lze se na něj přihlásit rovnou jak z lokálního VT, tak přes SSH. Na druhou stranu ale není u sshd povolena autentizace heslem, kromě případů krajní nouze se nepřihlašuji z cizích počítačů, kontroluji veřejný klíč serveru, pro vybrané démony používám AppArmor a pro přístup ke službám buď IPsec nebo SSL. Doufám, že to stačí pro pro ilustraci toho, kde vidím rozdíl mezi efektní a efektivní.
Scénář, který tu nastínil Wire.64, mne o klidný spánek nepřipravuje. Například bych ale spal o poznání klidněji, kdyby u moderních základních desek šlo spolehlivě zakázat bootování z jiných médií než z harddisku.
sshd mám na portu 22, účet s UID 0 se jmenuje root a lze se na něj přihlásit jak z lokálního VT tak přes SSH. Dokud jeden server sloužil pouze jako Samba server, neměl jsem na něm ani jiný uživatelský účet, přihlásit ke konzoli jsem se mohl jen jako root. U sshd není povolena autentizace heslem, přihlašuju se jen z počítačů, které běžně používám a u kterých mám dobrý důvod domnívat se, že v nich není keylogger nebo nějaký vir. Přihlašovací údaje ke všem službám dostupným na serveru jdou šifrovaným kanálem nebo se posílá pouze hash hesla a výzvy, možná s výjimkou nějakých nepodstatných webových aplikací. Na všech serverech jsou spuštěny jenom ty služby, které ty počítače mají poskytovat. Webový server provozuji pod běžným uživatelem, nesmí mi na webový server kdejaký kód, který si někdo uplácá nebo najde. A bonus na závěr -- dokud jsem ještě pracoval jako správce sítě na gymnáziu, nebyl tam nainstalován (a nebyl potřeba) žádný antivir.
Scénář nastíněný Wire.64 považuji za krajně nepravděpodobný. Za přínos bezpečnosti bych považoval autentizační token nebo smartcard, která by uměl uchovávat privátní klíče certifikátů i privátní klíče pro ssh, šifrovala by sama (aniž by klíč opustil smartcard nebo token) a pin by se zadával přímo do karty nebo tokenu a ne jako teď, kdy se nejčastěji aplikace sama na pin zeptá a pak ho milostivě předá kartě (a nebo nejen jí).
Ne, to není token, to je obyčejná flashka chráněná nějakým pinem. Zkoušel jsem kdysi ohledně ní googlovat, a vypadá to, že to není nic extra (kdosi prý poslal tu flashku zaheslovanou firmě, u které měl outsourcovanou IT bezpečnost, a když dal souhlas se zničením flashky, tak dostal její obsah mailem asi za dvě hodiny).
Tak to jste spolu s panem Jirsakem idealni kandidat na chybu, kterou jsem jiz zminoval. (Prosim pominme ted fakt, ze vy myslim jedete na SuSE, pan Jirsak nevim co provozuje, a primo ohrozen jste nebyl. Jde mi predevsim o to, ze se jednalo o konkretni a realnou chybu.) Hadat login netreba, mate roota, takze muzeme ihned pristoupit k rozjeti hrubosiloveho skriptiku na testovani klicu a za par hodim je vymalovano. Pokud mate loglevel sshd nastaven na standardni INFO, tak neuspesne pokusy ani nepolezou do logu. Zvyseneho trafficu na portu si nevsimnete, protoze se hrave ztrati mezi ostatnim bordelem, ktery si do nej dobrovolne poustite.
A nekteri lide si pritom jsou tak jisti, ze kdyz maji silne heslo nebo asymetricky klic, tak jim nic nehrozi. Jak vidno ne vzdy muzete tvrdit, ze presne vite, ktery clanek retezu je jak slaby, a odmitat dalsi trivialni upravy jako zcela zbytecne.
Nechci se panu dratovi sedesatemu ctvrtemu prilis navazet do argumentace, podle meho nezvolil ciselne nejlepsi priklad, ale myslim, ze netvrdil nic ve smyslu "hodil jsem si sshd na jiny port, ted me nikdo nevycenicha, ani kdyby mel zalusk primo a jenom na muj server." Provadet fullscan vsech portu kvuli hledani nahodneho pocitace se zivym ssh by melo smysl jen tehdy, jestlize pravdepodobnost, ze u nahodne zvoleneho pocitace, u ktereho na portu 22 nic nenasloucha, najdu ssh na jinem z 65 000 moznych portu, by byla vetsi, nez pravdepodobnost, ze z dalsich 65 000 nahodne zvolenych pocitacu bude vice nez jeden vystavovat na dvaadvacitce ssh demona. Dalsi vec je, ze v realu je zvykem relevatni porty nahodnych pocitacu propingat predem, vytvorit si databazi, a pak jit najisto. Mate-li ssh jinde, je velmi pravdepodobne, ze u vas bude mit cracker v prislusnem sloupecku null a az se naskytne nejaky vhodny exploit, tak na vas rada vubec neprijde.
Na-pri-klad: Cracker se rozhodne, ze si postavi mensi botnet, anebo ze si rozsiri stavajici. Je zrejme, ze mu nezalezi na konkretnim pocitaci pana Kubecka, on chce jakykoliv pocitac pripojeny do internetu, pokud se nedostane do vaseho, nejdena se o tragedii, k mani jsou kvanta dalsich. Takze svou praci zacne treba tim, ze bude scanovat internety, aby si predpripravil nejaka data do zacatku. Bude tedy prochazet adresni prostor a postupne pingat na port 22 (plus mozna jeste par dalsich: ftp, www, mysql, ...). A ted pozor, prijde klicova cast! Kdyz na 22 nic nenajde nebude prochazet zbylych 65 000 portu, ale presune se na jinou ip. Zduvodneni tohoho tahu vizte tu komplikovanou veticku o pravdepodobnostech v mem predchozim prispeveku. Pak se dostane k zatim obecne nezname zranitelnosti (sam ji vymysli, najde v moc moc osklivych zakoutich internetu, koupi, ...), ktere nejsou na prekazku silna hesla nebo asymetricke klice, zabuduje ji do sveho cerva a vypusti ho do sveta. Pokud jste mel sshd povesene na nestandardnim portu, nebudete v jeho databazi uveden jako provozovatel ssh, proto nedojde k pokusu aplikovat na vas server exploit. V opacnem pripade bude zalezet na tom, jestli se na chybu prijde drive, nez na vas dojde rada, pripadne jestli to cracker predcasne tipne, protoze bude s prirustkem zombiku spokojen.
Jestlize nebude pouzit pripraveny seznam, ale scan bude provadet cerv osobne, bude jeho chovani tykajici se prochazeni portu totozne.
Opakuji, jestli bude mozne zjistit login behem par minut je ciste vase rozhodnuti, nikdo vas nenuti ho zverejnovat. Krom toho, zjistovani loginu tak nejak predpoklada zasah cloveka, tedy cileny utok.
Tak to jste spolu s panem Jirsakem idealni kandidat na chybu, kterou jsem jiz zminoval. (Prosim pominme ted fakt, ze vy myslim jedete na SuSE, pan Jirsak nevim co provozuje, a primo ohrozen jste nebyl. Jde mi predevsim o to, ze se jednalo o konkretni a realnou chybu.) Hadat login netreba, mate roota, takze muzeme ihned pristoupit k rozjeti hrubosiloveho skriptiku na testovani klicu a za par hodim je vymalovano. Pokud mate loglevel sshd nastaven na standardni INFO, tak neuspesne pokusy ani nepolezou do logu. Zvyseneho trafficu na portu si nevsimnete, protoze se hrave ztrati mezi ostatnim bordelem, ktery si do nej dobrovolne poustite.Vy v tom ovšem jedete s námi a Wire.64 také. Při plošném útoku není problém uživatelská jména tipovat nebo odhadovat podle jmen v DNS a RIPE kontaktech, při cíleném útoku bude login pravděpodobně to první, co útočník zjistí. Zjistit port, na kterém běží sshd, je pak otázka možná desítek minut. Rozdíl je v tom, že zatímco my bychom v okamžiku zveřejnění chyby zahodili staré klíče a vygenerovali nové z nějakého nepostiženého systému, vy byste ukolébán pocitem, že jste změnou portu nebo přihlašováním přes uživatele chráněn, čekal, až se na váš stroj někdo dostane.
Dalsi vec je, ze v realu je zvykem relevatni porty nahodnych pocitacu propingat predem, vytvorit si databazi, a pak jit najisto. Mate-li ssh jinde, je velmi pravdepodobne, ze u vas bude mit cracker v prislusnem sloupecku null a az se naskytne nejaky vhodny exploit, tak na vas rada vubec neprijde.Ne, cracker bude mít ve sloupečku
ssh napsán váš nestandardní port. Když budu chtít vědět, s jakým strojem mám tu čest, nepropinkám si nějakých pět standardních portů, zda jsou otevřené, ale zjistím si všechny otevřené porty a co na nich naslouchá. Tou vaší metodou bych ani nepoznal, jestli ten „náhodný počítač“ náhodou není lednička.
Clovece s vama je fakt sranda. Ja vyslovne x-krat napisu, ze nehovorim o cilenem utoku na zvoleny pocitac, ze to neni nahrada za slabe heslo (pripadne klic), a vy mi zacnete vypocitavat co se zacne dit pri cilenem utoku na muj pocitac a jak bych ukoleban cekal s deravym klicem. Bavite velmi, dik.
Ja vyslovne x-krat napisu, ze nehovorim o cilenem utoku na zvoleny pocitacJistě, proč si nezjednodušit podmínky, když to jde? Proč v tom spoléhání nejdete dál? Když spoléháte na to, že na váš počítač nebude veden cílený útok, můžete spoléhat i na to, že na něj nebude veden žádný útok, ne?
to neni nahrada za slabe heslo (pripadne klic), a vy mi zacnete vypocitavat co se zacne dit pri cilenem utoku na muj pocitac a jak bych ukoleban cekal s deravym klicemDěkuji, že jste to konečně sám napsal, že to vaše není žádná ochrana (když to není náhrada za ochranu heslem), ale je to jen taková zábava.
Ja spoleham na to, ze na muj pocitac nebude veden cileny utok?
Zvlastni, co tihleti telepati a mystici dnes dokazou. Diky, ze jste se mnou ztratil par minut, zameril na me podvedomi (?) sve paprsky, a odhalil pravou podstatu mych myslenek a pohnutek.
8.1.2009 22:17
xkucf03 | skóre: 49
| blog: xkucf03
Například bych ale spal o poznání klidněji, kdyby u moderních základních desek šlo spolehlivě zakázat bootování z jiných médií než z harddisku.
Můžeš nastavit bootování z disku a vstup do BIOSu zaheslovat, ne? Ale ono to stejně moc nepomůže, protože když už je útočník fyzicky u počítače, může vyndat disk a připojit si ho k notebooku, provést patřičné úpravy a vrátit disk zpátky.
Tak si zašifrujte disk a máte po problému.
Ale vytvořím si tím jiné problémy. Třeba že kvůli každému restartu systému budu muset vyrazit do Prahy. Včetně těch neplánovaných, které nikdy nelze vyloučit stoprocentně.
Třeba že kvůli každému restartu systému budu muset vyrazit do Prahy.Praha je ale pěkné město. Každopádně pokud se Vám jezdit nechce, můžete si zjednat management kartu, nebo člověka s heslem. Nebo nějaké jiné řešení.
Pořád tady cvičíme s pojmy bezpečnost, zranitelnost, pravděpodobnost. Ovšem kde berete jistotu, že aplikace nějakého obecného statistického modelu je v tomto případě správná. Já souhlasím se statistickými závěry na toto téma učiněnými. Ale nejsem si jist právnou aplikací.
1) Tato agrumentaci mi připadá, že eliminace nejpravděpodobnějšího rizika automaticky znamená, že méně pravděpodobná rizika neexistují. Pravděpodobnost že nějaký automat uhodne heslo je mizivá, stejně jako je mizivá šance, že vyhraju ve sportce jackpot. Přesto miliony lidí na světě sází a čas od času někdo vyhraje jackpot.
2) S argumentací s buldozerem přeci naprosto souhlasím. Pouze si kladu otázku, zda je skutečně tak strašně hloupé a nerozumné, nechat k té zdi dojet pouze ten buldozer s tím, že nic jiného tam ani nedojede. Vy argumentujete s tím, že tu zeď kromě buldozeru nic prorazit nemůže, tak ať se klidně ten zbytek rozpleskne. Jenže ono se klidně může stát, že 2000 trabant tu zeď trafe tak neťastně, že kolem odvodňovacího otvoru praskne.
Jinými slovy, jde mi o eliminaci rizik. A pokud 99% útoků vyřeším jenom nějakou anomálíií (portem, uživatelem,....) proč je to tak hloupé? Samozřejmě, že je třeba splnit podmínku silného hesla, aby ten 1% zbytek měl jen mizivou šanci, ale proč pokoušet ten 99% plebs.
Pravděpodobnost že nějaký automat uhodne heslo je mizivá, stejně jako je mizivá šance, že vyhraju ve sportce jackpot. Přesto miliony lidí na světě sází a čas od času někdo vyhraje jackpot.Není stejně mizivá, je řádově mizivější.
S argumentací s buldozerem přeci naprosto souhlasím. Pouze si kladu otázku, zda je skutečně tak strašně hloupé a nerozumné, nechat k té zdi dojet pouze ten buldozer s tím, že nic jiného tam ani nedojede. Vy argumentujete s tím, že tu zeď kromě buldozeru nic prorazit nemůže, tak ať se klidně ten zbytek rozpleskne. Jenže ono se klidně může stát, že 2000 trabant tu zeď trafe tak neťastně, že kolem odvodňovacího otvoru praskne.To jako že nějaký robot si jen tak zkusí tipnout 24 znakové heslo a na popáté ho uhodne? To mně už bude jedno, protože mezitím ve Sportce vyhraju takové prachy, že mne žádná správa serverů nebude dávno zajímat.
Jinými slovy, jde mi o eliminaci rizik. A pokud 99% útoků vyřeším jenom nějakou anomálíií (portem, uživatelem,....) proč je to tak hloupé? Samozřejmě, že je třeba splnit podmínku silného hesla, aby ten 1% zbytek měl jen mizivou šanci, ale proč pokoušet ten 99% plebs.Z toho je jen vidět, že nemáte vůbec představu, o jakých pravděpodobnostech se tady bavíme. To není 1 ku 99. To je třeba jedna ku 1020 -- v takových řádech se pohybujeme.
Opakuji po sté. Na kompromitaci serveru se nedívám pouze jako na uhodnutí hesla. Právě proto, že si jsem schopen a ochoten přiznat "že nemám představu", uvažuji o anomáliích. Vy si nejste ochoten přiznat, že existuje možnost, kdy i dlouhé heslo bude k ničemu.
Opakuji znovu. Moje úvaha vychází právě z toho, že neznám všechny hrozby, nejsem schopen řešit všechny hrozby a nejsem schopen ovlivnit všechny hrozby. Vy se plácáte po ramenou a říkáte si, že dlouhé heslo vyřeší vše. Přece jsem si to spočítal. Možná máte pravdu. To já nevím, al jako chytré mi to nepřijde, protože jistě to vědět nemůžete.
Opakuji po sté. Na kompromitaci serveru se nedívám pouze jako na uhodnutí hesla. Právě proto, že si jsem schopen a ochoten přiznat "že nemám představu", uvažuji o anomáliích. Vy si nejste ochoten přiznat, že existuje možnost, kdy i dlouhé heslo bude k ničemu.Já znám možnosti, kdy je dlouhé heslo k ničemu. Ale žádné z těch možností nezabrání ani přesun
sshd na jiný port.
Pokud uvažujete o anomáliích, měl byste také obložit server česnekem, otočit jej procesorem na server a vždy o úplňkových nocích ho chodit skrápět muší krví. To všechno je relevantní obrana proti různým "anomálním" útokům -- přičemž všechny jsou stejně pravděpodobné, jako útok, proti kterému ochrání přesun sshd na jiný port. Předpokládám, že všechna tahle opatření (a miliony dalších, zapomněl jsem třeba zaříkávání, oběti...) poctivě provádíte...
Opakuji znovu. Moje úvaha vychází právě z toho, že neznám všechny hrozby, nejsem schopen řešit všechny hrozby a nejsem schopen ovlivnit všechny hrozby. Vy se plácáte po ramenou a říkáte si, že dlouhé heslo vyřeší vše. Přece jsem si to spočítal. Možná máte pravdu. To já nevím, al jako chytré mi to nepřijde, protože jistě to vědět nemůžete.Já neříkám, že dlouhé heslo vyřeší vše. Jenom tvrdím, že nestandardní port nevyřeší vůbec nic.
To mně už bude jedno, protože mezitím ve Sportce vyhraju takové prachy, že mne žádná správa serverů nebude dávno zajímat.To je ale hanebné. :)
přestěhování portu ssh zvede v tomto případě bezpečnost 200x
Tipuju, že v současné době to funguje tak, že script kiddies hledají stroje, na které by se mohli připojit a zkusí se přihlásit na portu 22. Když jim tam nic neodpoví, tak jdou jinam, protože čas, který by potřebovali na proskenování portů, využijí efektivněji jinde (tj. na stroji, který má dvaadvacítku otevřenou). Takže na vás dopadne útoků míň, ale jen do doby, než script kiddies změní strategii (a začnou proskenovávat porty). Od toho okamžiku vás přesunutí sshd na nestandardní port přestane chránit. Prodloužení hesla o jeden znak oproti tomu znamená zvýšenou obranu vždy. V některé z těch diskusí řekl pan Kubeček něco ve smyslu (nechce se mi to dohledávat, tak se omlouvám za případný posun významu), že opatření typu zákaz přihlášení roota nebo přesunu sshd na nestadardní port není nic, co by bezpečnost snižovalo (a tedy bylo a priori špatné), ale že špatné je se na taková opatření (falešně) spoléhat jako na něco, co bezpečnost nějak podstatně zvýší (a že tudíž např. můžu mít pro roota klidně heslo "toor", když při vzdáleném přihlášení musím na roota su-ovat přes jiného uživatele). Velmi pěkně to taky v jedné diskusi vyjádřila anicka.
S tímto já ale skutečně nesouhlasím.
Jestliže mi anomálie podstatně sníží počet útoků, jestliže anomálie může eliminovat hrozby, které pan Kubeček nechce nebo není chopen vůbec uvažovat (jak zde někdo výše předvedl na příkladu exploitu sshd), tak přeci zvyšuje bezpečnost velmi podstatně. Představovat si, že ke kompromitaci dojde jenom brute-force a proto budu pouze navyšovat heslo mi přijde naivní. Je to stejné jako když Václav Klaus brojí proti jakýmkoli opatřením v boji proti globálnímu oteplování, s tím že to poškodí ekonomiku a nikdo vlastně neví, jestli nějaké globální otelování v důsledku člověka je. Princip předběžné opatrnosti mu nic neříká, a až se ukáže, že byl neskutečně hloupý a i ekonomické škody jsou v porovnání s obranými opatřeními někdy před lety astronomické, tak Klaus už bude dávno pod drnem.
Princip předběžné opatrnosti pan Kubeček asi považuje za nesmysl, s tím, že všechny hrozby zná, a žádná jiná neexistuje a nemůže se objevit.
No, to se dalo očekávat, že tu zase bude pěkná divočina. Ale protože pánové Kubeček s Jirsákem už vám v podstatě všechno řekli, už toho asi mnoho nedoplním. BTW mezi námi děvčaty jste s nimi občas hovořil tónem, který bych si já speciálně vůči nim nedovolil, a to na rozdíl od vás už nějaký pátek aspoň vím, kolik je vlastně těch portů.
Pokud jde o mě: roota získám přímo, ale jen přes klíč (pokud by mi náhodou někdo někde odkoukal passphrase, nebude mu bez klíče na nic, zatímco password může použít přímo). Necítil bych se jakkoli významně bezpečněji, kdybych musel na roota su-ovat. Přihlašuji se pouze ze strojů, na kterých mám roota. Sshd mi běží na nedstandardním portu, ale to je trochu z historických důvodů, a nemám žádný praktický důvod přehazovat ho zpátky (možná při nějaké reinstalaci). Ale necítím se kvůli tomu jakkoli bezpečněji. Až se začnu obávat nějakého zero-day útoku na sshd, udělám následující:
Na rozhraní eth rozběhnu VPN, jehož porty uzavřu a budu je zvenčí ovládat portknockingem s jednorázovými hesly. Sshd převěsím z eth na tun a tun opět uzavřu portknockingem na jednorázová hesla. Tohle jsou věci, které udělám během pár hodin nebo pár desítek minut. Pak se zahrabu do dokumentace AppArmoru nebo SELinuxu, a důkladně si nastuduju, jak ta hračka funguje, a v čem mi může být užitečná (dosud jsem [ na to byl příliš líný | neměl jsem dost času ]). Až trochu slušně pochopím, jak to pracuje, tak se to i pokusím nasadit (to může trvat pár dní až týdnů podle momentálních časových možností). Minimálně v případě, že openVPN nesdílí nějakou významnou část kódu s ssh (což nevím), IMHO nějakým skutečně významným způsobem zvýším svoji bezpečnost. A pokud s něčím budu potřebovat poradit, budu velmi vděčný panu Kubečkovi nebo Jirsákovi, když mi radu poskytnou. Věcmi typu PermitRootLogin no nebo změnou portu, na kterém mi visí sshd (i kdybych ho měl na té dvaadvacítce) se zabývat nebudu, protože jsou to věci typu napínáčky proti buldozeru (jak to tu kdosi přirovnal).
Vy si to samozřejmě se svým serverem dělejte jak chcete, v tom vám určitě nikdo nebrání, klidně prohazujte jednou za hodinu port sshd, su-ujte se klidně přes pět userů, než dostanete roota. Jednak je to čistě vaše věc, jednak vám tu nikdo nikdy netvrdil, že by to snižovalo bezpečnost vašeho serveru. Jediné, na co jsou někteří zdejší lidé hákliví, je vydávat tyhle kroky za bezpečnostní opatření, protože jednak vás chrání pouze ve speciálních případech, jejichž výskyt je dost nepravděpodobný (ve všech ostatních jsou vám prostě k ničemu), a hlavně se snaží ochránit newbies, kteří se zatoulají na ábíčko hltat rozumy, přečtou si váš zápisek a získají z něj pocit, že "takhle se dělá to zabezpečení v linuxu".
Až se začnu obávat nějakého zero-day útoku na sshd, udělám následujícíA co se musí stát abyste se bát začal?
Minimálně v případě, že openVPN nesdílí nějakou významnou část kódu s ssh (což nevím)To bude asi to openssl, ve kterém byl nedávno ten /* bug */. Hups.
Jednak je to čistě vaše věc, jednak vám tu nikdo nikdy netvrdil, že by to snižovalo bezpečnost vašeho serveru.Děkuji ti náčelníku že ses mě zastal.
Jediné, na co jsou někteří zdejší lidé hákliví, je vydávat tyhle kroky za bezpečnostní opatření, protože jednak vás chrání pouze ve speciálních případech, jejichž výskyt je dost nepravděpodobný (ve všech ostatních jsou vám prostě k ničemu), a hlavně se snaží ochránit newbies, kteří se zatoulají na ábíčko hltat rozumy, přečtou si váš zápisek a získají z něj pocit, že "takhle se dělá to zabezpečení v linuxu".Já koukám, že jsou hákliví až moc. Speciální případ je potřeba ošetřit také. Navíc já přendání portu nevydávám za ultra bezpečnostní krok, dále tady žádné rady newbies jak se dělá zabezpečení nedávám a doufám, že je to z mých příspěvků jasně patrné.
A co se musí stát abyste se bát začal?
Nevím, zřejmě bude muset dojít ke zhoršení mojí paranoidní psychózy. Vy se bojíte? A udělal jste pro to něco jiného než přehození portu?
To bude asi to openssl, ve kterém byl nedávno ten /* bug */. Hups.
Díky, to mi nedošlo. Ale stejně bych řekl, že ta VPN s HMAC firewallem by mě nejspíš ochránila před větší částí světa než vás jiný port. Ale ono to nemá moc smysl řešit, v prů***u bych byl tak jako tak, leda bych byl schovaný za tím portknockingem.
dále tady žádné rady newbies jak se dělá zabezpečení nedávám a doufám, že je to z mých příspěvků jasně patrné
Což neznamená, že to newbies nečtou (a že si nemohou udělat nějaký úsudek).
Vy se bojíte?Můžete to tak nazvat, ale já prostě předpokládám že tam ta díra je, a že zítra může vypuknout poplach. Tento přístup dokonce považuji za standardní.
A udělal jste pro to něco jiného než přehození portu?Samozřejmě, a někde výše jsem sepsal alespoň částečný přehled těch opatření. Namátkou filtrování IP adres považuji za velmi účinné opatření, nicméně někteří zarputilci se brání i tomu.
Ale stejně bych řekl, že ta VPN s HMAC firewallem by mě nejspíš ochránila před větší částí světa než vás jiný port.Ano. Ale já neporovnávám jedno a druhé.
Což neznamená, že to newbies nečtou (a že si nemohou udělat nějaký úsudek).Já pevně věřím, že ten kdo se o problematiku zajímá, si diskuse přečte pořádně a nikoliv zběžně a nebude vyvozovat závěry typu přesunutí portu je spása všeho.
Ale já neporovnávám jedno a druhé.
Tedy nasadit obojí současně, jestli tomu správně rozumím? Což znamená, že útočník bude muset vyzkoušet (až) 32768 kombinací pro tls-auth klíč, aby vůbec zjistil, jestli tam ta VPN je a aby s ním začala vyjednávat o spojení (pokud nesedí někde na routovací trase, v tom případě o té VPN bude vědět, ale stejně bude muset vyzkoušet (až) 32768 kombinací), pak musí vyzkoušet dalších (až) 32768 kombinací k tomu, aby se do té VPN dostal, a když je konečně uvnitř, tak ťukne na dvaadvacítku, ze které mu nic neodpoví, načež vypadne pryč. Možná jsem fakt málo paranoidní, ale z takového útočníka prostě nějak nemám strach.
Ne, on vypadne při tom prvním ťukání, kde nebude znát port VPN a obtěžovat se ho hledat.
Jinými slovy, ti script kiddies, před kterými se schováváním portu bráníte, nenajdou nic, co není na standardních portech, tudíž rozběhnout vpn na nestandardním portu a do něj schovat sshd je totožné jako pověsit na nestandardní port přímo sshd?
ne, že by si neuměl najít port SSH, ale už nemá exploit/heslo/whatever, který by ho tam dostal
Když jsem argumentoval tím, že svoji bezpečnost zvýším minimálně v případě, že openvpn a openssh nesdílí nějaký kritický kód, tak jste mi ("hups") předhazoval bug, kvůli kterému bylo exploitnutelné jak sshd tak i openvpn (aniž by byla chyba přímo v nich). Jinde zase argumentujete, že openssh (via password, pravda) toho nemá příliš společného s openvpn. Tak si konečně vyberte, jestli se bavíme o situaci, kdy je postiženo jak openvpn tak openssh, nebo jestli se bavíme o zero-day exploitu na sshd jako takové.
S poslední větou samozřejmě souhlasím, to máme problém oba, takže to není třeba rozebírat.
Jinými slovy, ti script kiddies, před kterými se schováváním portu bráníte, nenajdou nic, co není na standardních portech, tudíž rozběhnout vpn na nestandardním portu a do něj schovat sshd je totožné jako pověsit na nestandardní port přímo sshd?Pokud definujete totožnost tak, že to skript kid nenajde, tak ano. Ale já samozřejmě počítám i s tím, že nestandardní port někdo najde, a pak to totožné není, protože tam jsou ty vrstvy pak dvě.
Tak si konečně vyberte, jestli se bavíme o situaci, kdy je postiženo jak openvpn tak openssh, nebo jestli se bavíme o zero-day exploitu na sshd jako takové.Dobře, myslím že jsem to trochu zamlžil. My se můžeme bavit klidně o obou. Problém s klíči (to je ta situace hups) mi vyřeší ssh s heslem. Jak jsem psal někde výše, pokud Vám vadí společný faktor openssl jako takový, můžete to ssh nahradit telnetem (abyste nešílel, že to je nešifrovaný telnet, tak si uvědomte, že na localhost nebo přes point to point linku). Takže OK, dejme tomu, abyste měl více nezávislé systémy, tak tam budete mít ten telnet, doplňte si to do mých ostatních úvah.
protože tam jsou ty vrstvy pak dvě
Ve vašem pojetí tři.
Jak jsem psal někde výše, pokud Vám vadí společný faktor openssl jako takový, můžete to ssh nahradit telnetem (abyste nešílel, že to je nešifrovaný telnet, tak si uvědomte, že na localhost nebo přes point to point linku). Takže OK, dejme tomu, abyste měl více nezávislé systémy, tak tam budete mít ten telnet, doplňte si to do mých ostatních úvah.
Shodli bychom se spíš na tom openvpn, ve vašem sporu o telnet bych se asi klonil spíš k argumentům páně Jirsáka. Ale pokud se vám ten telnet líbí, dobrá, máte ho mít. Máte tedy dle své úvahy dva nezávislé zabezpečovací prvky. Zero-day exploit na sshd neumožní útočníkovi dostat se přes telnet, zero-day exploit na telnet je útočníkovi sám o sobě úplně k ničemu. Sedí?
Pokud ano, pořád si ještě budete hrát na schovku s porty? Pořád se budete bát toho, že se dožijete dne, kdy zjistíte, že se časově sešly zero-day exploity jak na sshd tak i na telnet? Mě pořád připadá, že zabezpečujete stylem, že máte na dveřích od bytu dva zámky, jeden nosíte v kapse a druhý je pod rohožkou (pokud vám někdo vykrade kapsu, třeba ho nenapadne se podívat pod rohožku, a do bytu se tudíž nedostane). Podíval jsem se na ten souhrn opatření, který jste psal výše (a který jste mi doporučil k prostudování). Nevím, jestli vám vaše paranoia nezabránila (kromě citlivých údajů jako je IP adresa a číslo portu, na kterém vám visí sshd) dát do placu i nějaké jiné údaje, nicméně zkusím pracovně vyjít z toho, že to, co tam píšete, odpovídá zabezpečení vašeho serveru. Dovolil bych si popsat, jak to na mě působí:
Na sshd se dá připojit jen z vybraných adres, ok. VPN jen pro ultramobilní. Jak už bylo v diskusi zmíněno, nebude to fungovat proti útočníkům sedícím na routovacích trasách, zatímco prohnat vépéenkou i ty konexe z povolených adres by vcelku jednoduše a elegantně pomohlo. Proč tedy ne "vše přes vpn"? Dál vám vadí, že vám každý puberťák může zabrnkat na sshd (proto ho taky nemáte na 22, tak nějak jste schoval zvonek pod kouli u dveří). Bojíte se zero-day exploitu, dobrá. Máme tu portknocking, o kterém ještě nebyla příliš řeč. To je způsob, jak znemožnit útočníkovi kontakt s sshd (dokonce způsob, jak docílit toho, že sshd vůbec nepoběží, dokud to nebudu potřebovat). Skript kiddies přijdou, zaťukají na 22 a odtáhnou. Schopnější útočníci mi oskenují všechny porty a odtáhnou taky. Pokud vám přijde lepší schovat sshd na port 12345, tak se nejspíš nedomluvíme, protože asi nebudu schopen porozumět vaší logice. Pokud se shodneme na portknockingu, a začneme se znovu hádat, jestli i navzdory téhle ochraně by nemělo být sshd spuštěno raději na portu 12345, tak se taky nedomluvíme, protože to už asi nebudu schopen rozumět vaší paranoie. Ale v takovém případě aspoň pochopím, že opravdu děláte všechno proto, abyste eliminoval i ty sebemenší hrozby (i kdyby měly pravděpodobnost 10^-20, zkrátka "udělal jsem všechno pro to, aby se mi tam nikdo nedostal, co bych ještě mohl vymyslet jako nejkrajnější obranu? - aha, ještě schovám port)
Na ten druhý případ to ale nějak nevidím, protože na jedné straně pana Jirsáka obviníte, že jeho názory jsou zřejmě způsobeny tím, že nikdy nechránil žádná důležitá data, na druhé straně jste zrušil SMS bránu, protože vám připadala drahá (což nevypadá na to, že si dat, která chráníte, ceníte nějak mimořádně). Zkrátka oproti daleko účinnějším řešením (SMS brána, portknocking) stavíte druhořadé opatření (to "druho" by patřilo do hodně velkých uvozovek) a tvrdošíjně za ním stojíte. I když tohle vyjádření jsem ještě schopen pochopit (byť kroutě hlavou a mumlaje si pro sebe "že to někomu stojí za to").
ve vašem sporu o telnet bych se asi klonil spíš k argumentům páně JirsákaMohl byste prosím znovu zopakovat co je špatného na tom telnetu? Dobrá, můžeme se bavit o tom, že je to složitý protokol a bude mít složitou implementaci. Můžeme tam místo toho dát rsh, nebo ještě něco jednoduššího.
Pořád se budete bát toho, že se dožijete dne, kdy zjistíte, že se časově sešly zero-day exploity jak na sshd tak i na telnet?Bát? Nevím, počítat s tím můžu ale jak bylo řečeno pak už (v tomto scénáři) další obranu mít nebudu. Ale to neznamená, že bych měl zavrhnout případ kdy se někdo probourá jen do toho sshd, ať už cíleně nebo kobercově.
kromě citlivých údajů jako je IP adresa a číslo portu, na kterém vám visí sshdSSHD mi teď nikde nevisí. A IP adresu si můžete nějakým průzkumem zjistit sám. Můžete si zjistit i spoustu jiných věcí. Jen to, do čeho Vám skutečně nic není, si nezjistíte.
Na sshd se dá připojit jen z vybraných adres, ok. VPN jen pro ultramobilní.Tohle jsou dva různé scénáře, které můžete, ale nemusíte kombinovat.
Proč tedy ne "vše přes vpn"?I tahle varianta je možná. Pokud chcete posoudit, jakou kombinaci zvolit, tak mi nějakou navrhněte, a já Vám řeknu jaká budou pro a proti. Asi Vás nepřekvapí, že "absolutně nejlepší" kombinace nebude existovat.
Máme tu portknocking, o kterém ještě nebyla příliš řečJo. Konečně něco nového v této dlouhé diskusi. Ten jsem aplikoval kdysi dávno, pak jsem se touto technikou již nezabýval. Možná, až zas budu něco stavět, to přijde znovu na přetřes. Uznávám, že je to v katerogii "obscurity" lepší řešení, než schovat port, ale je také nákladnější. Namátkou bych ale přeskočil "standardní" řešení jako knockd, protože je to příliš riskantní. Portknock démon musí být napsán jednorázově a co nejjednodušeji, jelikož je to zase jeden démon navíc, který někde poslouchá. (K čemu pak je bezpečné ssh, když někdo prorazí rovnou ten knockd.) Napadá mě řešení, kdy se knocking zaintegruje do toho ssh démona co běží v chrootu, to by mohlo být dobré.
Pokud se shodneme na portknockingu, a začneme se znovu hádat, jestli i navzdory téhle ochraně by nemělo být sshd spuštěno raději na portu 12345, tak se taky nedomluvíme, protože to už asi nebudu schopen rozumět vaší paranoie.To je trochu divné zase mně, protože reverzní aplikací Vaší logiky, budu používat über maskování, ale zároveň vynechám tak elementární věc jako přehodit port.
udělal jsem všechno pro to, aby se mi tam nikdo nedostal, co bych ještě mohl vymyslet jako nejkrajnější obranu? - aha, ještě schovám portCo je na tom divného?
jeho názory jsou zřejmě způsobeny tím, že nikdy nechránil žádná důležitá dataTo byla spekulace spíše na téma auditů a metodiky práce s bezpečností jako takové. Zkrátka člověk který prošel nějakým mustrem se pozná od člověka který si to dělá jak ho napadne. (Čímž nehodnotím zda dobře nebo špatně.)
na druhé straně jste zrušil SMS bránuTo je opět nějaký renonc. Já jsem pouze napsal, že SMS brána není levné ani bezproblémové řešení.
Zkrátka oproti daleko účinnějším řešením (SMS brána, portknocking) stavíte druhořadé opatřeníZnova a znova nestavím. Jediné porovnání jsem provedl možná v tomto příspěvku, ale ve dvou dimenzích, takže tam nemůžete zavést jednoznačnou relaci lepší-horší. Dovolte mi ještě zmínit můj dojem z debaty na téma "přehození portu sshd". Přesun portu je opatření, které se dá použít téměř vždy, nic nestojí, a bezpečnost rozhodně nezmenší. Dobře, byly tu nápady jiné, například že se na přihlášení na roota nejprve musím přihlásít jako uživatel. To opatření také nesnižuje bezpečnost. Tam je ta daň ale daleko vyšší: musím si pamatovat dvě hesla. U toho stěhování portu mi zatím nikdo nebyl schopen říci, v čem mu tak přitěžuje. Místo toho se naprosto nesmyslně porovnává s jinými opatřeními, a dokazuje se, že je lepší udělat X než Y. Co vás na tom stěhování portu tak vytáčí, že je kvůli tomu nutné se tak sáhodlouze bavit? Potřebujete si mě proklepnout, abych Vám dokázal, že nejsem blázen, který staví veškerou bezpečnost na nestandardním portu? Těší mě, že jsem tak zajímavý, ale snad jsem již nějakou znalost prokázal. Na druhou stranu, témata, o kterých by se dalo bavit mnohem zajímavěji, jako jsou třeba ty různé řešení pomocí chrootu, smsek, atp. jsou tu jen tak nadhazovány a zanedbány ve světle toho zpropadeného přestěhování portu.
Za prvé, prosím Vás, stejně jako ostatní, přestaňte mluvit v metaforách (dveře, koule, jak tomu mám rozumět).
Sorry, zapomeňte na to.
já jsem nikde nenapsal, že každá moje věta se týká nějakého mého (nedejbože ještě toho samého) serveru
Napsal jste
Rozumně uvažující administrátor má na firewallu nadefinovány IP adresy odkud se smí přihlašovat. Má-li s tím problém a potřebuje být ultra mobilní, řeší to dvoustupňově -- například VPN (na nestd. portu :) a až pak SSH. Nebo nejprv SSH do chrootu, kde prolomení nemá přímý dopad na bezpečnost serveru, a pak nějakou jinou metodou dál (jde zde využít i ten zmiňovaný telnet).
- protože se zajisté považujete za "rozumně uvažujícího administrátora" a protože jste žádný lepší návod nedal (nebo aspoň - sorry - nevšimnul jsem si, těch příspěvků tu začíná být nezdravě moc a začínám se v nich ztrácet), tak mi nic lepšího nezbylo. To, jak mám zabezpečený server, a to jak bych ho zabezpečil, kdybych se obával exploitu na sshd (zajisté jste si všimnul, že jsem už tam ten portknocking zmínil), jsem tu nenapsal proto, že se chci chlubit tím, jaký jsem úžasný machr (nejsem, a vím to), ale právě proto, že jsem chtěl nastolit debatu o zabezpečení vzdáleného přístupu jako takového místo dosavadní debaty o tom, na kterém portu má viset sshd. Docílil jsem prakticky jen toho, že se místo toho bavíme o tom, na kterém portu má viset openvpn :-/
Mohl byste prosím znovu zopakovat co je špatného na tom telnetu?
IMHO to, že pokud někdo projde skrz sshd, tak už má lokálního usera. A výraz "špatného" jste použil vy. Zminimalizoval bych to tvrzení na to, že pokud budu mít možnost použít řešení, které útočníkovi na roota dá usera (při selhání jedné z ochran) a řešení, které mu ho nedá, dal bych osobně přednost té druhé možnosti.
Bát? Nevím, počítat s tím můžu ale jak bylo řečeno pak už (v tomto scénáři) další obranu mít nebudu.
Já zase můžu počítat s tím, že mi server zničí meteorit o váze do 1kg, a proti tomuto scénáři vytvořím opatření, kdy server umístím do sklepa do nějaké extra postavené betonové boudy. Dotaz zněl na reálné "obávání se", tedy na to, zda vám připadá rozumné vzhledem k pravděpodobnosti scénáře dál zabezpečovat. Proto jsem se debatu snažil přehodit na téma, jak konkrétně zabezpečit server na rozumně očekávatelná rizika. Neúspěšně.
Tohle jsou dva různé scénáře, které můžete, ale nemusíte kombinovat.
Sice volně, leč citoval jsem vás.
Pokud chcete posoudit, jakou kombinaci zvolit, tak mi nějakou navrhněte, a já Vám řeknu jaká budou pro a proti.
Já už jsem s návrhem přišel, navíc i z námitky "proč tedy ne vše přes vpn" je snad jakýsi návrh patrný. Jaký návrh ještě chcete?
Uznávám, že je to v katerogii "obscurity" lepší řešení, než schovat port, ale je také nákladnější.
S nákladností máte určitě pravdu při porovnání absolutních nákladů. V porovnání poměru účinek:náklad už bych to ale viděl celkem jednoznačně ve prospěch portknockingu, a ani v těch absolutních číslech to IMHO není tak hrozná palba. Popravdě, pokud by někdo schoval sshd na port 12345 a zároveň se vykašlal na portknocking (teď zrovna jste ta řešení srovnal, takže i můj předpoklad je IMHO korektní), tak předvádí typ paranoiy, který nechápu.
Portknock démon musí být napsán (...) co nejjednodušeji, jelikož je to zase jeden démon navíc, který někde poslouchá. (K čemu pak je bezpečné ssh, když někdo prorazí rovnou ten knockd.)
Souhlas.
Namátkou bych ale přeskočil "standardní" řešení jako knockd, protože je to příliš riskantní.
Lhal bych, kdybych tvrdil, že tohle dokážu posoudit. Možná tomu rozumíte, a dokázal byste si napsat lepšího démona sám. Já ne, takže bych se na knockd spolehl.
Napadá mě řešení, kdy se knocking zaintegruje do toho ssh démona co běží v chrootu, to by mohlo být dobré.
Což by IMHO znamenalo, že vám to klekne současně s sshd. V tom nějak nevidím přínos. V případě trochu volnějších hmotných podmínek by asi nejlepší bylo knockd na extra stroji před sshd (jsem si vědom, že teď "trochu" měním [nevyslovené] výchozí hw podmínky), nebo (teď vařím z vody) by snad mohl knockd běžet pod userem a otvírat port (či nahazovat sshd) via sudo.
To je trochu divné zase mně, protože reverzní aplikací Vaší logiky, budu používat über maskování, ale zároveň vynechám tak elementární věc jako přehodit port.
Pravděpodobně jsem fakt málo paranoidní. Pokud někdo dokáže projít přes knockd a sshd (současný zero-day exploit na obé považuji za extrémně nepravděpodobný), změna portu sshd mě nespasí (uvažuji variantu jednorázových hesel, kdy portknocking už IMHO není "pure obscurity" řešení, klidně můžete vědět, že tam ten portknocking je, stejně vám to moc platné nebude, na rozdíl od situace, kdy někoho napadne, že by sshd mohl být i jinde než na 22). Toť můj názor, a chápu, že se na něm neshodneme, protože vaše fantazie při vymýšlení scénářů je (bez urážky) evidentně neskonale bujnější.
Co je na tom divného?
Na tom není divného nic, pokud (např.) je pravděpodobnost průniku na váš server 50% a vy se pokusíte udělat cokoli, abyste ho snížil na 0,5% (i kdyby to cokoli bylo kouzlo woodoo). Pokud ale "trikujete" (v jednom příspěvku jste přehození portu označil za trik - a s tímhle označením souhlasím), abyste pravděpodobnost z (plácnu) 10^-16 snížil na 10^-18 přičemž k tomu snížení dojde jen za extrémně příznivých podmínek, které mohou kdykoli přestat platit (a vy se ani nemusíte nezbytně nutně dozvědět, že platit přestaly), tak se asi rozcházíme v jakémsi obecnějším pohledu na svět.
To je opět nějaký renonc.
Omlouvám se, pokud jsem posunul význam vaší informace. Pokud jste ji měl (= také zrušil), evokovalo to myšlenku, že se zřejmě nehodila do nějakého scénáře, pro který stačí přehození portu. Ale pokud vám sshd nikde nevisí, tak chápu.
Přesun portu je opatření, které se dá použít téměř vždy, nic nestojí, a bezpečnost rozhodně nezmenší.
V podstatě souhlas (jen ty náklady možná nemusí být úplně nulové, ale asi nestojí za to se o tom bavit).
U toho stěhování portu mi zatím nikdo nebyl schopen říci, v čem mu tak přitěžuje.
Když zůstanu u vaší minimalistické argumentace, že "bezpečnost rozhodně nezmenší" (BTW netvrdím opak a v tomto s vámi souhlasím), je tedy potřeba dělat něco (cokoli) co bezpečnost jenom "rozhodně nezmenší"? Všimněte si, prosím, také toho, že snad nikdo z "odpůrců" neřekl nikomu ze "zastánců": "Proboha, nedělejte to, koleduje te si o strašlivý pr**er!" Celá debata je o tom, že "zastánci" přesvědčují "odpůrce", že ve svém zabezpečení něco strašně důležitého opomíjejí, a "odpůrci" pouze oponují, že i kdyby to udělali, nijak významně tím nezlepší obranu svých strojů. A já konkrétně říkám: sshd na dvaadvacítce nemám, ale _necítím se kvůli tomu jakkoli bezpečnější_. A dodávám: až se začnu bát zero-day exploitu na sshd udělám něco jiného (a píšu konkrétně, co to bude).
Místo toho se naprosto nesmyslně porovnává s jinými opatřeními, a dokazuje se, že je lepší udělat X než Y.
Porovnává se přehození portu s tím, jaký užitek to může přinést, případně se porovnává s opatřeními, které řeší stejný problém, ale chrání i před jinými útočníky, než jsou script-kiddies a automaty (notabene blbě naprogramované či přinejmenším nakonfigurované - jaký asi tak může být problém napsat automat, který nejprv proskenuje porty, nebo automat, který se zkusí esesháčknout na všechny porty zaráz? Co když už nějací - i jen trochu pokročilí - crackeři mají takový automat v záloze pro případ, že se objeví ten vzývaný zero-day exploit? Co se stane, když nějaké významné procento adminů začne stěhovat porty sshd po všech čertech a crackeři se to domáknou, kde je v záloze nějaký další trik?)
Co vás na tom stěhování portu tak vytáčí, že je kvůli tomu nutné se tak sáhodlouze bavit? Potřebujete si mě proklepnout, abych Vám dokázal, že nejsem blázen, který staví veškerou bezpečnost na nestandardním portu?
No, řekl bych, že první jste reagoval vy na mě , ne já na vás, ale možná se pletu. (Nota bene jste dokonce na mě poprvé reagoval u příspěvku, ve kterém jsem se snažil obecnější debatu na téma zabezpečení otevřít)
Těší mě, že jsem tak zajímavý, ale snad jsem již nějakou znalost prokázal.
Opak jsem snad ani jen nenaznačil.
Na druhou stranu, témata, o kterých by se dalo bavit mnohem zajímavěji, jako jsou třeba ty různé řešení pomocí chrootu, smsek, atp. jsou tu jen tak nadhazovány a zanedbány ve světle toho zpropadeného přestěhování portu.
To jste klidně mohl udělat hned tady, to byl taky důvod, proč jsem zveřejnil svoje krajně neparanoidní zabezpečení (či "zabezpečení" ) svého serveru, a postup, který bych zvolil, kdybych se "začal bát".
protože se zajisté považujete za "rozumně uvažujícího administrátora" a protože jste žádný lepší návod nedalJo, ale těch serverů mi prošlo rukama hodně a každej potřeboval něco jiného.
nastolit debatu o zabezpečení vzdáleného přístupu jako takovéhoDobrá, odpovím Vám hlavně v tomto duchu, protože řešit ten port mě už taky nebaví
Jestli chcete ty diskuse pak odlišit, tak si napište svůj zápisek do blogu a můžeme pokračovat tam.
Ad "vpn/ssh+ssh/telnet": To je jeden z přístupů, který jsem několikrát použil a mnohokrát viděl, tj. počítač coby administrativní brána. Mám síť serverů (obvykle na nějaké interní síti, ale použít to jde i na internetové servery), ke kterým chci omezit přístup; místo abych konfiguroval každý zvlášť, povolím na všech jen jeden počítač, a omezení na konkrétní lidi už řeším tam. Brána je pak jedna z mála věcí, která se dá napadnout zvenku, a jak jste správně podotkl, pokud si mám vybrat, jestli v první instanci dostane útočník uživatele na bráně, nebo roota na serveru, tak není moc o čem uvažovat. Vedlejší efekt toho řešení je, že servery jsou obvykle za NATem a já pak nemusím dělat díru pro každý z nich.
Počítač coby brána se obvykle dává na zvláštní segment sítě (ať už fyzický nebo vlan; někdo tomu říká DMZ), a na příslušném firewallu se mu zakáže všechno, kromě toho přístupu na servery. Tím se omezí "collateral damage" v případě kompromitace té brány -- útočník sice může dráždit ty servery (resp. službu vzdáleného přístupu) ale už nemůže zkoušet jiné služby nebo útočit na pracovní stanice, které, ruku na srdce, jsou obvykle děravé jak řešeto. Navíc máte možnost na firewallu ten počítač sledovat a hlídat, co se děje. Můžete to dokonce nastavit i über tak, že ten firewall dělá jen bridging a je tedy pro tu bránu prakticky neviditelný.
Podle použitých technologií pak mám ty případy s vpn, ssh, atd. Nejčastěji používaná metoda je překvapivě ssh + ssh. (Oni ty lidi opravdu pokládají ssh za něco nezničitelného.) Každopádně pokud použijete různé autentizační metody (heslo+klíč nebo klíč+kerberos) a chroot (s sshd puštěným pod userem), tak máte za relativně málo peněz hodně muziky. SSHD v chrootu pod uživatelem se mimochodem dá využít i v jiných případech, např. pro SVN server. (Já jsem si kdysi tuto metodu oblíbil natolik, že jsem byl schopen ručně nakopírovat všechny potřebné věci (a jen ty) do chrootu po paměti :)
Řešení ala telnet se dá použít jen v případě, že máte brána=server, nebo brána a server jsou spojeny point to point (maximálně tam může být ještě ten sledující firewall). Tohle jsem použil jen jednou když jsem chtěl mít opravdu jistotu, že jsem udělal vše možné (ono to jde kombinovat třeba dvacetkrát, ale také musíme myslet na toho, kdo tam pak chce jít legitimně, navíc pak razantně upadá spolehlivost toho řešení).
Řešení ala VPN je vhodné pokud nechcete a priori povolit přístup na bránu a/nebo když máte hodně služeb (a třeba netextových, např. rdesktop), kde by si administrátor musel přes ssh kopat tunely. Z hlediska bezpečnosti si myslím, že VPN brána na tom bude srovnatelně jako SSH brána.
Co se týče SMS brány, tam bych jako největší problém viděl tu spolehlivost. Několikrát se mi stalo, že brána vypadla a musela se fyzicky resetovat, takže bych to pak mohl mít ve stavu dokonalého zabezpečení, tj. že se tam nedostane nikdo
Co se týče napsání knock démona, to asi není složité (můžete v nejhorším použít xinetd a perl nebo bash; to ale nebude úplně minimální řešení). Co se týče jeho inkluze do sshd, představoval jsem si to tak, že pokud třeba na ten port předem nepošlu nějaký magic, tak se se mnou nebude bavit. Výhoda by byla v tom, že ten knock by Vám platil skutečně jen na to jedno připojení. Další výhoda je, že pokud jste na nějakém obskurním připojení, tak vám nemusí nějaká speciální sekvence udp/icmp paketů vůbec projít, zatímco takhle pokud se dostanete na ten sshd port, tak už můžete i knockovat. Že to klekne spolu s sshd, mi nevadí, protože když klekne sshd, tak je mi knock k ničemu. Já jsem si takový knock kdysi vyrobil, momentálně bych ho ale musel kvůli zastaralosti vymýšlet znovu. Je to ale dobrý námět na volný čas.
To je asi tak co mě k tomu napadá, jestli jsem na nějakou metodu zapomněl, tak řekněte.
je tedy potřeba dělat něco (cokoli) co bezpečnost jenom "rozhodně nezmenší" ... a dodávám: až se začnu bát zero-day exploitu na sshd udělám něco jiného (a píšu konkrétně, co to bude)Tady jde o to, že aspoň nějaké řešení z toho repertoáru (přinejmenším firewall) použiju vždy. Port pak třeba nechám, nebo změním, podle potřeb. Obvykle stejně ten konfigurák edituju, takže to není nějaká ultra přítěž.
a vy se ani nemusíte nezbytně nutně dozvědět, že [nějaké podmínky] platit přestalyProto bych ten příklad s zero day exploitem neodkládal na dobu neurčitou. Vy se nemusíte včas dozvědět, že je něco jinak. Proto je v nouzi dobrý i ten zatracený port (nebo ten knock, nebo cokoliv), který prostě jen natáhne čas. Ad automat který skenuje: já si myslím, že hlavní problém je ten čas. Než něco oskenujete, tak můžete nabourat dvacet jiných strojů. Asi nejlepší přístup, který by takový automat mohl použít, je preventivně scannovat síť a udržovat databázi o tom, co našel. Kdyby se pak něco objevilo, můžu se rovnou podívat do databáze a jít na jistotu. Já nevím, třeba to někdo tak dělá. Ale většina automatů asi ne. A i kdyby, tak holt jiný port nefunguje, no, tak se spolehnu na ta další (a silnější) opatření co tam mám. Proto tam jsou.
Celá debata je o tom, že "zastánci" přesvědčují "odpůrce", že ve svém zabezpečení něco strašně důležitého opomíjejíPokud bych měl ty největší "odpůrce" zde o něčem přesvědčit, tak o tom, aby si tam dali aspoň ten firewall. To je totiž skutečně věc, která by mi nedala spát. Port ssh démona je mi u zadního portu. :)
Teď to teprve vypadá na zajímavou debatu! (BTW - téma portu bych opravdu považoval za vyčerpané, blog kvůli tomu rozhodně zakládat nehodlám.)
Jsem rád, že se můžu něčemu přiučit. Měl bych k tomu pár dotazů:
Můžete to dokonce nastavit i über tak, že ten firewall dělá jen bridging a je tedy pro tu bránu prakticky neviditelný.
Chápu to správně, že přes NAT se udělá díra v jednom portu na konkrétní stroj (bránu) a z toho jsou odchozí konexe omezeny na IP adresy serverů, které potřebuju spravovat (a na které ze stroje, na kterém je brána dosáhnu v rámci LAN)? Pak mi není jasné co znamená, že "firewall dělá jen bridging a je tedy pro tu bránu prakticky neviditelný". Můžete to trochu rozepsat?
Jinak - určitou nevýhodu na variantě ssh - telnet vidím v tom, že musím mít telnetd na cílovém stroji. Je to vlastně jen pocit, ale tipnul bych si, že už nějaký ten pátek není telnet zdaleka tak oprašován jako to openssh, takže riziko zranitelnosti tam asi bude o něco vyšší. No a pak stačí, aby se člověk "zamyslel" při nastavování iptables... No nic, to je spíš jen paranoia (ten telnet, ne to zamyšlení se při nastavování iptables, to mi naopak přijde dost reálné).
Varianta ssh - ssh mi v kontextu téhle debaty přišla trošku úsměvná, ale nemám v úmyslu ji napadat. (Vlastně ani nevím, co bych zvolil, kdybych si měl vybírat mezi ssh - ssh a ssh - telnet.)
Z hlediska bezpečnosti si myslím, že VPN brána na tom bude srovnatelně jako SSH brána.
Jako určitou výhodu VPN bych viděl, že jednak se s vámi při zapnutém HMAC FW nebaví, pokud nemáte příslušný klíč (částečná prevence proti DoS a port floodingu, skoro raději pomíjím i jisté obscurity důsledky ), jednak při případném prolomení (například kvůli "hups" chybě, ne buffer overflow) nedává útočníkovi žádného usera, žádný shell, "pouze" útočníkovi zpřístupní síť, do které ale stále ještě nijak nepronikl.
Co se týče SMS brány, tam bych jako největší problém viděl tu spolehlivost. Několikrát se mi stalo, že brána vypadla a musela se fyzicky resetovat, takže bych to pak mohl mít ve stavu dokonalého zabezpečení, tj. že se tam nedostane nikdo
To je špatný, pak není co řešit, jen počkat, až se začne vyrábět spolehlivější hw.
Co se týče jeho inkluze do sshd, představoval jsem si to tak, že pokud třeba na ten port předem nepošlu nějaký magic, tak se se mnou nebude bavit.
Chápu to správně, že uvažujete o připsání toho kódu do sshd? Takovou odvahu já osobně asi nikdy mít nebudu.
Výhoda by byla v tom, že ten knock by Vám platil skutečně jen na to jedno připojení.
Nevím jak to myslíte (výhoda ve srovnání s čím?), ale mám pocit, že s knockd a jednorázovými hesly dosáhnete podobného efektu.
Další výhoda je, že pokud jste na nějakém obskurním připojení, tak vám nemusí nějaká speciální sekvence udp/icmp paketů vůbec projít, zatímco takhle pokud se dostanete na ten sshd port, tak už můžete i knockovat.
Nejsem expert, ale za prvé jsem na takovém připojení nikdy neseděl (takže nemám moc představu o tom, jak se to může chovat, proč by nějaká síť neměla propouštět udp, o icmp nemluvě), za druhé (jestli se nemýlím) by neměl být takový problém zaťukat i tcp pakety. A minimálně v případě "klasického" knockování snad icmp ani není jak využít (leda by se port otvíral pingem).
Že to klekne spolu s sshd, mi nevadí, protože když klekne sshd, tak je mi knock k ničemu.
Na druhou stranu pokud mi někdo shodí knock, tak mě odřízne i od sshd (což se mi nemusí úplně líbit, na druhou stranu se od sshd odřízne i útočník, takže vlastně záleží na úhlu pohledu, budeme-li to brát jako bug nebo jako feature ). Původně jsem to ovšem myslel spíš tak, že pokud budu dost paranoidní na to, abych předpokládal, že knocking není nedobytná technologie, získám využitím díry v knockingu (buffer overflow) rovnou roota. Jsem si vědom toho, že na tom budu stejně, pokud použiju nějakého démona (knockd) běžícího pod rootem, proto jsem si v předchozím příspěvku zaspekuloval, zda by knockd (případně jiný démon) mohl běžet s právy usera a nezbytné věci (manipulace s iptables) dělat přes sudo. Případně přesunout portknocking na extra stroj (pokud si to mohu dovolit). Ale pokud to reálně nasadím, asi se spíš nakonec spolehnu na to, že na tom portknockingu není zas tak moc co hackovat.
Proto bych ten příklad s zero day exploitem neodkládal na dobu neurčitou. Vy se nemusíte včas dozvědět, že je něco jinak.
Toho jsem si vědom, a rozhodně netvrdím, že nemáte pravdu. Asi se nad sebou budu muset zamyslet.
Když to tak promýšlím, asi nejzajímavější mi přijde varianta, která mě napadla úplně na začátku - zkombinovat ssh s vpn a portknockingem. Do první linie openvpn s HMAC FW (to už mám i rozběhané, takže to není takový problém), sshd hodit na tun rozhraní. Na tun když tak ještě přihodit ten portknocking ve variantě s jednorázovými hesly, který si sám nenapíšu, ale nevidím jako zásadní bezpečnostní problém použít hotové (a přiměřeně osvědčené) řešení. Obskurní sítě nepropouštějící udp a icmp pakety není třeba řešit, protože budou tunelovány skrz vpn. Koukal jsem na stránky portknocking.org (docela zajímavě zpracované, myslím, že i naprostý newbie pochopí, o čem to je) a je tam i stránka se seznamem implementací (najde se tam i to bashové řešení, které jste vzpomínal). Docela zajímavě vypadal fwknop, který mimo jiné umožňuje používat Elgamal GPG šifrování (takže posiluje potenciální společný slabý prvek openvpn a openssh v podobě openssl - přeci jen se mi nechce vzdávat výhod přihlašování se na ssh pomocí klíčů). Bohužel teď nemám dost času to nějak detailně studovat, na druhou stranu je pro mě ten fwknop poněkud overkill, pro one-man ssh přístup (což je - alespoň zatím - můj případ) jsou jednorázová knock - hesla dostačující, ale čtení je to zajímavé, a třeba bych ho i časem využil.
téma portu bych opravdu považoval za vyčerpané, blog kvůli tomu rozhodně zakládat nehodlámNemyslím kvůli portu, ale té bezpečnostní diskusi. Pak by Vám tam třeba mohlo přijít víc pohledů na věc než ten můj. Teoreticky by se to dalo šoupnout i do poradny.
Chápu to správně, že přes NAT se udělá díra v jednom portu na konkrétní stroj (bránu) a z toho jsou odchozí konexe omezeny na IP adresy serverů, které potřebuju spravovat (a na které ze stroje, na kterém je brána dosáhnu v rámci LAN)?Ano. Někdy není nutné dělat díru do NAT, ale v souladu s (původními) principy internetu dát bráně veřejnou IP adresu (máte-li, ale ani v dnešní době není problém sehnat blok osmi ipv4 adres za pakatel; u ipv6 nat postrádá smysl).
Pak mi není jasné co znamená, že "firewall dělá jen bridging a je tedy pro tu bránu prakticky neviditelný".Mám na mysli koncept filtrujícího bridge/switche (ty dokumenty jsou starší, není to zrovna novinka). Místo toho abyste dva síťové segmenty spojil routováním, tak je spojíte bridgováním/switchováním, pak ta spojovací mašina nemusí mít vůbec IP adresu a při správné funkci je tudíž ze sítě nedosažitelná. Na rozdíl od běžného switche ale můžete použít plný potenciál Linuxu s jeho netfilterem.
nějaký ten pátek není telnet zdaleka tak oprašován jako to opensshTelnet je složitý protokol. Když se kouknete na rsh, tak to bylo oprašováno dost dlouho a navíc jeho zdroják je čtení na jeden večer, takže bych se toho nebál. Také se dříve rsh používalo mnohem víc, než telnet; viz jakýkoliv program, který mohl mít něco do činení se vzdáleným strojem, (cvs, tar, ...). Proto i ssh spíše imituje rsh než telnet.
[VPN] nedává útočníkovi žádného usera, žádný shell, "pouze" útočníkovi zpřístupní síť, do které ale stále ještě nijak neproniklPokud se vám podaří prolomit klíč a navázat vpn spojení, tak se samozřejmě do shellu nedostanete, ale otázka je, jestli to má praktickou výhodu, když můžete dělat přes vpn ze svého shellu v podstatě totéž, jako byste dělal ze shellu na bráně. (Pomineme-li triviality, jako že shell na bráně nemá gcc a tak dál.)
až se začne vyrábět spolehlivější hw [pro sms bránu]Možná existují brány, které se chovají rozumně, ale asi budou v jiné cenové kategorii. Ta naše stála tolik co lepší mobil a v zásadě je na ni i podobně tomu spoleh. Používáme ji spíš na hlášení průserů z monitorovacích systémů.
Chápu to správně, že uvažujete o připsání toho kódu do sshd? Takovou odvahu já osobně asi nikdy mít nebudu.Tam nic posvátného není. Každý démon má někde cyklus s accept(), a hned pod to se dá něco jednoduchého připsat. Když budu mít čas, tak něco zkusím spáchat a dám to na blog.
Výhoda by byla v tom, že ten knock by Vám platil skutečně jen na to jedno připojení.Protože knockd otevře port např. na 5 sekund pro danou IP, tohle by bylo tak, že buď se na portu démona ohlásím nějakým heslem, nebo mi to spojení zavře.
jsem na takovém připojení nikdy neseděl (takže nemám moc představu o tom, jak se to může chovat, proč by nějaká síť neměla propouštět udp, o icmp nemluvě)Už připojení přes mobil je občas úchylné dost, nemluvě o různých hotelech, konferencích, kdoví co. Proč, to se zeptejte administrátorů těch sítí. Ale na druhou stranu, já když dělám síť s přístupem do netu, tak se taky snažím ten přístup ven omezit jen na to, co vím že je potřeba a zbytek zakázat. Já ale nedělám "sítě pro veřejnost", takže nevím, jak bych se zachoval v takovém případě.
zda by knockd (případně jiný démon) mohl běžet s právy usera a nezbytné věci (manipulace s iptables) dělat přes sudoMohl, zrovna tak by mohl použít nějaký jednoduchý wrapper, nebo mít příslušné capability (u iptables je to ještě široký pojem, ale jinde se to použít dá). Konečně jde ořezávat i ty neroot programy např. selinuxem. S tím zatím nemám praktické zkušenosti, ale mám v plánu začít.
Případně přesunout portknocking na extra stroj (pokud si to mohu dovolit).Také to jde, ale tam budu asi zase stát před tím, že potřebuju manipulovat s firewallem. Pak jsou ještě další exotické varianty, např. poslat speciální dotaz na DNS a tak.
Do první linie openvpn s HMAC FW"HMAC firewall" je věc specifická pro openvpn a můžeme ji přirovnat k tomu port knockingu na steroidech. Každopádně, ten HMAC FW, nemýlím-li se, se používá jeden secret klíč všude, čili může být problém, že když někdo ukradne jeden notebook, tak budu muset předělávat ten secret klíč všude. (Což je i případ toho normálního knocku.)
sshd hodit na tun rozhraníOno úplně nezáleží na jakém rozhraní máte poslouchací port, ale z jakých adres se na něj dá dostat. V extrémním případě musíte počítat s tím, že vám přijde až z druhého konce světa packet s úplně libovolně nastavenou zdrojovou a cílovou adresou. Buď musíte aspoň zapnout rp_filter, nebo ještě lépe nastavit správně přístupy na firewallu.
fwknopTen fwknop je pěkný. Je to sice poměrně složitá věc (a tudíž může mít také chyby), ale zase to má potenciál aby to fungovalo jako samostatná bezpečnostní vrstva.
Asi se nad sebou budu muset zamyslet.Záleží, co chráníte, kolik za to dostáváte, a jak jste líný. Se stálým platem a dobrou motivací člověk může pokračovat se zabezpečováním do aleluja (např. existují sítě, kde každá pracovní stanice hovoří pouze ipsecem a tak). Pokud "nestíháte", tak to obvykle bezpečnost odnáší jako první. (V roce 2000 měl jeden z největších providerů u nás na skoro všech zákaznických cisco routerech heslo "a"; před pár lety byl podobný průšvih s "nbusr123"). Dále často (bohužel) platí princip kovářovy kobyly.
Takže na vás dopadne útoků míň, ale jen do doby, než script kiddies změní strategii (a začnou proskenovávat porty).Pak svou strategii změním taky. Bezpečnost není statická věc. Před deseti lety leckde nebylo ani to ssh. Také se ještě hojně používaly BNCáky. Kompromitace jednoho serveru v hostingovém centru a nasazení snifferu pak znamenala pěknej l00t.
8.1.2009 14:55
Shadow | skóre: 25
| blog: Brainstorm
Super. Díky. To jsem chtěl vědět.
8.1.2009 19:48
xkucf03 | skóre: 49
| blog: xkucf03
Jenže číslo portu lítá po síti v otevřeném tvaru, takže ho nelze srovnávat s heslem.
8.1.2009 20:30
xkucf03 | skóre: 49
| blog: xkucf03
Otázka ale je, jestli skript-kiddie jsou vůbec schopní heslo prolomit – IMHO při rozumných heslech nebo klíčích ne, tudíž jejich snaha je marná.
A když to bude tak horké, že přijde exploit použitelný na tvůj server, tak SSH asi stejně dočasně zablokuješ na firewallu než aby ses spoléhal na to, že si nikdo nedá práci s proskenováním všech portů.
8.1.2009 22:10
Shadow | skóre: 25
| blog: Brainstorm
8.1.2009 22:26
xkucf03 | skóre: 49
| blog: xkucf03
odhalí zcela pasivně nestandardní port čehokoliv (ale i třeba port knocking, je-li sekvence portů konstatní)
To mi celé přijde jako hra, kterou někteří rádi admini hrají – odfiltrují roboty, lamy, skript-kiddie a když i po těchto opatřeních najdou v logu nějaké záznamy, tak ví, že se o jejich stroj zajímal někdo, kdo to myslí vážně (nebo prostě uživatel napsal špatně heslo )
je třeba o tomto jako o bezpečnostním opatření neuvažovat, a řešit bezpečnost tak, jako bychom toto opatření vůbec nenasadiliby se měla aplikovat na jakékoliv opatření. Tudíž jich mít několik a doufat, že všechny najednou nepovolí.
9.1.2009 10:48
Shadow | skóre: 25
| blog: Brainstorm
Dobře, ale dát tam ten sniffer je poměrně náročný úkol.
Jak kde. Navíc předpokládat přítomnost snifferu je rozhodně lepší než doufat v to, že "je to poměrně náročný úkol", do kterého se nikomu nebude chtít.
A taky se myslím shodneme na tom, že Vaše větaje třeba o tomto jako o bezpečnostním opatření neuvažovat, a řešit bezpečnost tak, jako bychom toto opatření vůbec nenasadiliby se měla aplikovat na jakékoliv opatření. Tudíž jich mít několik a doufat, že všechny najednou nepovolí.
Samozřejmě, že bezpečnost by měla zahrnovat řadu opatření, a měli bychom uvažovat o tom, co by se stalo, kdyby každé z nich selhalo. To ano. Nicméně, nasdit firewall a chránit SSH třeba prostřednictvím modulu recent je bezpečnostní opatření, u kterého vím, že se na něj mohu alespoň částečně spolehnout. O samotném přesměrování portu bych takto uvažovat neměl, z důvodů, které jsem uvedl výše. Spíše bych se na něj měl dívat jako na opatření, které sice znesnadní můj přístup na server, ale alespoň trošku pročistí logy.
Své servery samozřejmě spravujte tak, jak sám uznáte za vhodné, to je věc každého admina. Já osobně bych místo (nebo nezávisle na) nasazení přesměrování SSH portu uvažoval o jiných opatřeních, která mají reálný (nikoliv diskutabilní/mizivý) přínos pro bepzečnost - silná hesla, omezení uživatelů s SSH přístupem, fail2ban/denyhosts, omezení na určité IP, přihlašování výhradně pomocí klíčů, apod.
předpokládat přítomnost snifferu je rozhodně lepší než doufat v to, že "je to poměrně náročný úkol", do kterého se nikomu nebude chtítAle já v nic nedoufám. Já neříkám že ten port nejde najít, ani že tam není sniffer. Já tvrdím, že ten kdo zkouší bezhlavě port 22, tam sniffer nemá. Na tom se snad shodneme?
O samotném přesměrování portu bych takto uvažovat neměl, z důvodů, které jsem uvedl výše. Spíše bych se na něj měl dívat jako na opatření, které sice znesnadní můj přístup na server, ale alespoň trošku pročistí logy.Dobrá, tak tedy zařadíme terminologicky přehození portu do nějakých "junior opatření". Ale stále ho nebudeme vyřazovat z bezpečnosti úplně.
Já osobně bych místo (nebo nezávisle na) nasazení přesměrování SSH portu uvažoval o jiných opatřeníchOpět opakuji, že ani u mne nevisí bezpečnost na tom přehození portu. (V této diskusi již asi popáté ... to jsem zase otevřel skříňku s červy
)
Dobrá, tak tedy zařadíme terminologicky přehození portu do nějakých "junior opatření". Ale stále ho nebudeme vyřazovat z bezpečnosti úplně.A co by se stalo, kdybychom ho z té bezpečnosti úplně vyřadili? Snížilo by se nějak citelně zabezpečení systému? Pokud ne, k čemu tam tedy to zabezpečení je?
Když ochrana heslem selže, platí jiné pravidla hry, než ty, které jste si nastavil původně. Pak můžete heslo klidně zveřejnit, a přestěhovaný port zvyšuje vaše šance velmi značně, v závilosti kolik útoků a jakého typu na vás půjdou. V případě automatů vás port dost dobře možná zachrání. Ale vy tady pořád operujetes nějakou pravděpodobností, která platila vdobě, kdy heslo jako ochrana fungovalo. To je přeci absurdní.
Vy se mi snad zdáte. Já tady nemluvím o tom že jsem chráněn. Já tady mluvím o tom, že mě to může zachránit v případě průseru s heslem. Ale vy nečtete, nemyslíte a pořád si melete svou a vyvracíte mi smyšlenou argumentaci, kterou jsem zde nikde nevyřkl.
9.1.2009 15:35
Shadow | skóre: 25
| blog: Brainstorm
Vtip je v tom, že jak se dozvím, že ochrana heslem je neúčinná? Téměř vždy se to dozvím s určitým spožděním. Stejně tak může být neučinné cokolo z toho, co jste vyjmenoval. Ale že se tak stalo vinou například expliotu se vy dozvíte pozdě. Celou dobu hovořím o tom, že účinná obrana se může ze minuty na minutu stát neúčinná, aniž to mohu ovlivnit, předvídat a včas zachránit.
Já jsem se nerozhodl přesunout port. To je bohužel jeden příklad, který zasvinil celou diskuzi. Vraťtse znovu na začátek. Ptal jsem se na anomálie. Když bude chyba jinde, opět nějaké nestandardní nastavení by mi mohlo zachránit kůži. Co je na tom k nepochopeni. Klidně zapomeňte na SSH, je to jen příklad, jeden z tisíce!
), kdy se někdo rozhodne vytvořit dvě anomálie – přesunout SSH na jiný port a vylepšit generování klíčů SSH. Druhá anomálie způsobí zranitelnost SSH, přičemž první anomálie tuto zranitelnost omezí pouze na ty crackery, kteří neskenují jen standardní port. Stále tedy zůstává skupina útoků, která dokáží té druhé anomálie zneužít, ale první nijak nepomůže → celková bezpečnost se snížila.
Jinými slovy – nestandardní nastavení vám v několika málo případech zachrání kůži, ale daleko spíš vám podrazí nohy.
Výborně. Celou diskuzi bychom si mohli ušetřit, kdyby jste toto napsal rovnou
10.1.2009 20:43
xkucf03 | skóre: 49
| blog: xkucf03
njn, tak to v kryptografii bývá: když chceš něco vylepšit (zesložitit) a nerozumíš tomu, většinou to zhoršíš.
Takže já bych ten Váš princip "může to být dobré ale omg! může mi to i uškodit" rozšířil z "anomálií" i na všechna ostatní opatření, které děláte. Anomálie Vás nakope do zadku jen v případě, že nevíte, co děláte.Samozřejmě, že se to týká všech opatření. Ale zavedení anomálie není k ničemu dobré, takže jediné, co to může reálně způsobit (pokud se udělá něco špatně) je právě nějaký problém. Ostatně ten patch také podle jeho autora neměl mít nic společného s bezpečností, pouze udělal jednu „prkotinu“, která neměla nic ovlivnit. Podobnou „prkotinou“ je i přesun SSH na nestandardní port. Já jsem svou (snad) jedinou bezpečnostní chybu (na kterou se přišlo ještě během dalšího vývoje té verze) vyrobil také zakomentování dvou řádků „nepotřebného“ kódu – taky to byla snaha vylepšit takovou drobnost, kdy vylepšení nemělo nikomu ublížit ale v některých případech by snad mohlo pár instrukcí ušetřit. Přesně jako ta uměle vytvořená anomálie, na kterou by se snad někdy mohl nějaký cracker nachytat.
tím spíš jsou směšné všechny návrhy řešit to přidáním VPNVy máte opravdu krátkou paměť, protože ty návrhy zněly trochu jinak.
Ale zavedení anomálie není k ničemu dobréTo zavání tím, že "anomálii" přímo definujete jako věc, o které si myslíte, že je k ničemu.
To zavání tím, že "anomálii" přímo definujete jako věc, o které si myslíte, že je k ničemu.Takto ji nedefinuju já, ale Wire.64 – podle něj je „zavedení anomálie“ takové opatření, o kterém víme, že kdo bude chtít, ten jej obejde (a víme jak to udělá).
Dělící čára se tam nevloží podle toho, jak se mi to zrovna hodí, ale podle toho, jak náročné je danou ochranu obejít.To nám říkáte jinými slovy stále totéž. Náročnost stanovíte podle toho, jak se to hodí.
Přičemž se vždy bavíme o ochraně proti určité kategorii útokůStran přehození portu jsem se bavil o kategorii "automatické útoky".
12.1.2009 15:50
masožravá palma | skóre: 6
| blog: Agnes
| Matka měst
Ale myslím si, že to tak triviální, jak naznačujete, není. Portscan je poměrně nákladná záležitost, co se týče času a bandwidth: než projedete jeden stroj, tak byste měl třeba dalších dvacet úlovků jinde. (Čas se krátí a nová díra se patchuje rychle.) Navíc to není jen věc portscanu, musíte zjistit který z těch portů je sshd (nebo jiný Vámi zaměřený démon), nebo zkusit naslepo vystřelit na všechny.
To nemluvíme o tom, že portscan provede mnohem více "hluku" a nějaký proaktivní systém Vás může na čas umlčet.
Ad "současné útoky". Současná bezpečnost také stojí na některých "neoblomných pilířích". Například, že prolomit asymetrické šifrování je těžké. Zrovna tak, jako můžou automatické skripty začít používat portscanner, může být prolomeno asymetrické šifrování. Koneckonců, je na to již desítky let soustředěna pozornost předních mozků (a strojů) této planety, zatímco portscan je podle Vás triviální a za těch 10 nebo kolik let ty masové útoky máme, to zatím nikdo neudělal.
Zrovna tak, jako můžou automatické skripty začít používat portscanner, může být prolomeno asymetrické šifrování.Přičemž obojí je asi tak stejně pravděpodobné, že?
IP='192.168.1.1' PASSWORD = 'toor' for (( port = 0 ; port <= 65535 ; port++ )) do echo $PASSWORD | ssh -p $port "root@$IP" true doneTeď je na vás řada s tím prolomení asymetrické kryptografie. Stačí koncept, detaily už si každý jistě doladí.
To je asi tak řešení na úrovni toho Vašeho skriptu, protože stále nemám nikde zprávu, že by automatické skripty scannovaly porty.A jak si takovuo zprávu představujete? Myslíte, že o tom budou celostránkové články v novinách? Nebo potřebujete, aby se někdo obtěžoval specielně s vaším serverem, a pak tomu uvěříte?
Stran přehození portu jsem se bavil o kategorii "automatické útoky".To ale používáte hloupé dělení. Proti útokům ze sítě se samozřejmě budu bránit jinak než proti fyzickému útoku na hardware serveru -- a oba dva druhy útoků od sebe taky navzájem rozpoznám. "Automatický útok" a "ruční útok" se od sebe nijak neliší -- nezáleží na tom, zda cracker spustí skript proti jednomu cíli, deseti cílům nebo proti tisícům cílů. Pokud bude nějaký trouba opisovat příkazy odněkud z internetu, místo aby si ten skript stáhnul a spustil, bude najednou obrana nějaká jiná, jenom proto, že nejde o "automatický" ale "ruční" útok?
"Automatický útok" a "ruční útok" se od sebe nijak nelišíLiší. Na jiné porty než 22 není útočeno. Abychom se furt nebavili o tom portu, určitě tam bude i dvacet dalších "závislostí": konkrétní (nejčastěji používaná) architektura stroje, verze démona, knihoven (ok, brute force lámání hesla na tom zas tak nevisí, ale spousta exploitů ano); dále kód který se spustí po úspěšném průlomu, závisí třeba na nějakých utilitách (nevím, třeba cp nebo mkdir), něco odněkud stahuje atp. Ačkoliv to zní jako banalita, je potřeba si uvědomit, že "anomálie" v jakémkoliv kroku ten automatický útok prostě zastaví (a pravděpodobně to už nikdo nebude řešit, "ladit", hledat co je špatně), narozdíl od ručního útoku. Takže je v tom velký rozdíl.
Vy tu ale pořád řešíte jen chybu v kódu SSH. Co když tak chyba bude jinde – v kódu iptables, v knihovně pro síťování, v SSH a způsobí, že server bude nezávisle na konfiguraci naslouchat i na portu 22.No, ten poslouchací port se dá celkem dobře ověřit. Ale budiž. Řekněme že je problém v iptables a z nějakého důvodu mi pouští pakety z nějakého rozsahu v zambii, nebo odkud ty útoky chodí. O tom se samozřejmě dovím jen těžko. Ale pořád jsem na tom ještě dobře, protože mám silné heslo a musela by do toho ještě zároveň přijít ta chyba v SSH, což je pravděpodobnostně o pěkných pár řádů někde jinde. Navíc, když tam budu mít to tentítko s VPN a telnetem, tak už by se musely sejít tři faktory (a takhle to můžu nabalit ještě několikrát). Já jsem tu situaci dokonce nedávno zažil. Kolega blbě nastavil firewall na vývojovém serveru a celé svátky byl otevřený (úplně). Takže jsem měl v logu ssh démona (ten v tomto případě na jiném portu nebyl) všechny ty svinstva, ale heslo bylo silné, takže se nic nestalo. Na druhou stranu, testovací aplikace, která byla také odkrytá, měla heslo 'a', ale víte co? Nikdo nevěděl že tam je, takže do ní také nikdo nevlezl. Ale u Vás se to celé sesype jen na té jedné chybě ssh démona, jelikož iptables nemáte a děravý démon je všem na očích. A Váš jediný argument je "blabla takový exploit přece není".
Nebo je to tak, že jste se rozhodl SSH přesunout na jiný port, a teď zoufale hledáte nějaký problém, kterému by to vaše řešení čelilo?Já mám v této debatě k zoufalosti hodně daleko.
Asi Vám to bude krajně proti srsti, ale kdybych měl pět týdnů na nestandardním portu sshd s l/p root/root, tak se mi může celkem dobře stát**, že mi bezpečnost nikdo neprolomí, zatímco když takový sshd posadíte Vy na svůj port 22, tak můžete na beton jít za týden reinstalovat.Já zabezpečuju počítač tak, aby se do něj nikdo nedostal, ani pokud se na něj zaměří. Ne aby se do něj nikdo nedostal, jen pokud si ho nikdo nevšimne, a jakmile někdo zjistí jeho existenci, je s bezpečností amen.
No, ten poslouchací port se dá celkem dobře ověřit. Ale budiž. Řekněme že je problém v iptables a z nějakého důvodu mi pouští pakety z nějakého rozsahu v zambii, nebo odkud ty útoky chodí. O tom se samozřejmě dovím jen těžko. Ale pořád jsem na tom ještě dobře, protože mám silné heslo a musela by do toho ještě zároveň přijít ta chyba v SSH, což je pravděpodobnostně o pěkných pár řádů někde jinde. Navíc, když tam budu mít to tentítko s VPN a telnetem, tak už by se musely sejít tři faktory (a takhle to můžu nabalit ještě několikrát).Vy si ale pořád představujete nějakou pro vás příznivou chybu. Zkuste si představit nějakou nepříznivou. Co třeba buffer overflow v kódu otevírajícím spojení. Tím přijdete jednou ranou o SSH, telnet i VPN. Co když bude kompromitován počítač, odkud se přihlašujete – rázem jste přišel o SSH, VPN, telnet i nestandardní port.
Ale u Vás se to celé sesype jen na té jedné chybě ssh démona, jelikož iptables nemáte a děravý démon je všem na očích. A Váš jediný argument je "blabla takový exploit přece není".Vám se to sesype na jiné chybě SSH, na chybě
accept(), na kompromitaci vašeho osobního PC a na spoustě dalších věcí, které jsou stejně pravděpodobné nebo pravděpodobnější, než je ten váš exploit na SSH. Proč proti nim nezabezpečujete?
Můj argument není „takový exploit není“. Můj argument je „na tuto úroveň nepravděpodobnosti už nezabezpečuju, riziko je příliš malé a náklady příliš vysoké“. A nebudu si hrát na to, že na jednu věc s touto pravděpodobností jsem připraven, když na další miliardu věcí se stejnou pravděpodobností připraven nejsem.
Já zabezpečuju počítač tak, aby se do něj nikdo nedostal, ani pokud se na něj zaměří.To Vám chválím, ale uniká Vám pointa toho, na co reagujete.
Vám se to sesype na jiné chybě SSH, na chybě accept(), na kompromitaci vašeho osobního PC a na spoustě dalších věcí, které jsou stejně pravděpodobné nebo pravděpodobnější, než je ten váš exploit na SSH. Proč proti nim nezabezpečujete?My jsme se o těchto scénářích zatím nebavili, takže nevím, jak jste dospěl k názoru, že se jimi nezabývám. Víte, myslím, že to je celý problém naší komunikace. Bavíme se o scénáři X a Vy si z toho odvodíte, že pro mne existuje pouze scénář X. Takhle to ale není.
Můj argument je „na tuto úroveň nepravděpodobnosti už nezabezpečuju, riziko je příliš malé a náklady příliš vysoké“Dobře. Nevím, jak jste dospěl k těm vysokým nákladům, ale zřejmě ve Vašem modelu bezpečnosti jsou ty pravděpodobnosti i náklady nastaveny tak, že se Vám to nevyplatí. Já Vám přeji, aby Vám to vyšlo.
My jsme se o těchto scénářích zatím nebavili, takže nevím, jak jste dospěl k názoru, že se jimi nezabývám.Jednoduše. Těch scénářů jsou miliony nebo miliardy. Takže se jimi nezabýváte prostě z toho důvodu, že se tolika scénáři najednou zabývat nemůžete.
Dobře. Nevím, jak jste dospěl k těm vysokým nákladům, ale zřejmě ve Vašem modelu bezpečnosti jsou ty pravděpodobnosti i náklady nastaveny tak, že se Vám to nevyplatí. Já Vám přeji, aby Vám to vyšlo.Neustále argumentujete tím, že váš počítač ještě nebyl napaden. Pak vás můžu s použitím vaší logiky ubezpečit, že naše opatření jsou na stejné úrovni, protože ani u mne zatím k napadení nedošlo.
Neustále argumentujete tím, že váš počítač ještě nebyl napaden.Nepostřehl jsem, že bych takový argument vznesl. Ale je logické, že bezpečnost systému, kde je kompromitován počítač operátora, je na bačkoru. Proto některé systémy žádný takový počítač nepřipouští. (Manipuluje se vždy pouze na konzoli, nebo na nějaké LANce, kde máte počítač připojený pouze pro nezbytně nutnou dobu.)
Já si myslím, že scénářů miliony nejsou, jelikož drobné nuance v jednotlivých detailech jde docela dobře generalizovat. Ve výsledku pak můžu na nestandardní port dát třeba i nějaký jiný server a naše debata o tom bude víceméně podobná.Ale vždyť jen ten příklad s přesunem portu má následující podmínky: SSH používá jen root, jde o plošný (ne cílený) útok, existuje chyba umožňující obejít zabezpečení klíčem, plošné skeny skenují jenom standardní port. Pokud kterákoliv z těchto podmínek není splněna, řešení s přesunem portu nemůžete použít nebo je neúčinné. To vám všechny ostatní varianty těchto podmínek připadají o tolik méně pravděpodobné, nebo máte pro každou takovou kombinaci aplikováno nějaké řešení? Poznámka o jiném serveru je podle mne výstižná. Považuju za pravděpodobnější, že bude chyba v digest autentizaci nějakého HTTP serveru, než že bude chyba umožňující obejít přihlášení klíčem v SSH. Na spoustě webů budou informace dostupné přes web administrátorovi a získatelné automatickým plošným průnikem, které jsou daleko zajímavější, než informace, které získáte plošným průnikem přes SSH. Webový server na nestandardní port přesunout nemůžete. Takže je to podle mne pravděpodobnější problém, než ten s děravým SSH, má horší následky – a přesto to skoro nikdo neřeší. A pokud ano, použije HTTPS, čímž se dostane pouze na stejnou pravděpodobnost chyby, jako u toho SSH – protože jde o stejný typ problému. Proč tohle neřeší, a méně závažný problém s SSH ano?
To vám všechny ostatní varianty těchto podmínek připadají o tolik méně pravděpodobné, nebo máte pro každou takovou kombinaci aplikováno nějaké řešení?Ne, představte si, že některá jiná opatření mají třeba širší účinnost. Vám zkrátka vadí že i přes všechna jiná opatření se s přesunem portu někdo páře. Tak dobře, ale už bych to téma opustil.
Webový server na nestandardní port přesunout nemůžete.Můžu. A ještě před něj můžu hodit proxy nebo další prvky.
Takže je to podle mne pravděpodobnější problém, než ten s děravým SSH, má horší následky – a přesto to skoro nikdo neřeší.Já řeším všechno co nějak rozumně řešit jde.
Poznámka o jiném serveru je podle mne výstižná.
Proč tohle neřeší, a méně závažný problém s SSH ano?Která poznámka a kdo co neřeší? Hoďte link.
Já řeším všechno co nějak rozumně řešit jde.Tím mi odpovídáte na můj dotaz v jiném vlákně. Neřešíte problémy podle toho, jak jsou závažné, ale podle toho, jak snadné je vyřešit je. Já takový přístup v bezpečnosti neuznávám.
9.1.2009 14:17
Shadow | skóre: 25
| blog: Brainstorm
Ale já v nic nedoufám. Já neříkám že ten port nejde najít, ani že tam není sniffer. Já tvrdím, že ten kdo zkouší bezhlavě port 22, tam sniffer nemá. Na tom se snad shodneme?
Na tom se samozřejmě shodneme, nicméně já k tomu dodávám, že z hlediska bezpečnostní politiky je beztak nutné uvažovat i o scénáři, kdy má někdo někde blízko nás sniffer a je schopen z něj vydolovat všechny dostupné informace.
Dobrá, tak tedy zařadíme terminologicky přehození portu do nějakých "junior opatření". Ale stále ho nebudeme vyřazovat z bezpečnosti úplně.
Tak v tom se neshodneme. Já bych toto opatření rozhodně nespojoval s bezpečností. S bezpečností bych spojoval taková opatření, která mají pro bezpečnost reálný (a podstatný) přínos. Naopak opatření, která mají diskutabilní nebo mizivý přínos, bych ze seznamu "bezpečnostních opatření" automaticky vyřazoval. Všimněte si, že tím neříkám, že taková opatření by se neměla nasazovat, jen říkám, že bych o nich jako o bezpečnostních opatřeních neuvažoval.
Opět opakuji, že ani u mne nevisí bezpečnost na tom přehození portu. (V této diskusi již asi popáté ... to jsem zase otevřel skříňku s červy
V to pevně doufám.
Pokud je délka hesla rovna N a každý znak může nabývat jedné z 64 hodnot, pak zvýšením délky o 1 bude nový počet kombinací roven 64^(N+1) -- tedy opravdu se počet zvýšil 64x. Ale podstatné je přeci o kolik, nebo ne? [ tj. 64^(N+1) - 64^N ] Při dostatečně velkém N to bude sakra rozdíl. Vyřazením 199 automatů z 200 uživatelů máte zlepšení 200x, ale z jakého základu? Nemícháte jabka a hrušky?
Tohle je diskuze, ktera se da cist jedine, kdyz na to ma clovek cely vikend
Pripada mi, ze vetsina diskutujicich tady moc neuvazuje jako utocnik.
Rekneme, ze jsem zacinajici cracker, touzim se prosadit a touzim po uznani tech starsich crackeru v komunite. Takze co udelam? Zacnu si pripravovat velkou ranu. Udelam si seznam cilu a prozkoumu je. Dam si tam roota, abicko, nejake servery statni spravy, televize, portaly. Chci byt prece tim BIG hackerem, ktery se po zbytek zivota bude chlubit tim, ze ziskal roota na rootovi. Chci byt jeste slavnejsi nez Pepa, ktery trikrat po sobe pokoril portal statni spravy. Mam na to more casu. Vubec me nevadi, ze jsou demoni na nejakych divnych portech, scanuju pomalu a potichu, abych nevzbudil podezreni.
Po nejake dobe mam zmapovano co kde bezi, jake jsou to cca verze. Sem tam se podivam, jestli jsou me udaje aktualni. A protoze jsem tezky asocial, ktery nedela nic jineho, nez sedi u pocitace, tak cekam a cekam, az nekdo zverejni nejaky ten 0-day exploit. Pripadne ho zkousim psat, abych byl hyper super mega hustej.
Hura, dockal jsem se. Jdu rychle na vec, beru si cil za cilem a zkousim, jestli exploit zabere. Ale beru cile z meho seznamu. Nemam cas na nejake nahodne. Vubec mi nevadi nejake nestandardni porty, ja vim kam jdu. Mam vlastne strasne malo casu, informace o 0-day exploitu se siri jako stepni pozar, o ty zajimavejsi stroje se staraji cele tymy lidi a infomace o skutecnych prusvihovych situacich si predavaji v radu minut. Navic se mi treba stane, ze se s velkou slavou vlamu na loadbalancer a zjistim, ze backend posloucha jen na portu 80 a nemam jak jit dal. Ono take ne vsude, kde bezi ssh je neco k videni. Takze musim vyzkouset co nejvice cilu, abych alespon nekde uspel.
Muzu mit i sekundarni seznam cilu, ktere budu hackovat az mi primarni dojdou, ale to potrva nekolik hodin. Ale zase budu operovat nad seznamem znamych cilu. Kdyz uz mam ten exploit, nebudu ztracet cas hledanim ssh demonu. To ze vidite kontinualni scany celeho netu je dane prave tim, ze utocnici si vyhledavaji cile predem. Takove ty plosne pokusy o pouziti diry, ktera je dva roky zalepena, to je neco co nemuze alespon trochu udrzovany system nijak rozhodit a tech asi lze zbavit zmenou portu. Ale porad plati, ze kdyz definujete, kdo a odkud se smi pripojit, tak nemusite menit port.
Dalsi vec, kterou utocnik potrebuje jsou nejake stroje, ze kterych provede ostry utok. Ale zase na pripravu je spousta casu.
Proste zmena cisla portu vam skutecne pomuze jen k tomu, ze se tolik neplni logy. Ale proti skutecnemu utocnikovi je to absolutne neucinne opatreni.
Tohle je diskuze, ktera se da cist jedine, kdyz na to ma clovek cely vikendJo. Taky jsem zjistil, že o víkendu ráno* má člověk klid odpovědět všem, aniž by mu někdo ihned oponoval. :) * v půl jedenácté
10.1.2009 13:24
xkucf03 | skóre: 49
| blog: xkucf03
+1 ve všem