Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: ssh 09. 10. 2018, 07:01:48
-
ahoj.
pod clankom o deravom HP ILO sa riesilo zabezpecenie pristupu k serveru cez ILO, rad by som na tuto temu naviazal v diskusii.
moja situacia: mam vlastny server v datacentre (housing), bezi na nom posta, LAMP a samozrejme ssh. Do interenetu mam otvorene len porty (http, https, smtp a ssh). Po par hodinach ako bol server pripojeny na internet som uz videl v logu pokusy o prihlasenie na ssh port pod "typickymi" usermi (root, test, cisco a pod) . Nastastie som sa z diskusii tu na ROOT-e dozvedel hint, ze je lepsie ten port 22 premapovat na iny. to som urobil a uz bolo pokusov znacne menej:) - ano, viem security by obscurity ale ma to vyznam. Dalej som sa tu dozvedel, ze je moznost sa prihlasovat na ssh pomocou certifikatu, to je velmi user friendly, netreba buchat stale heslo pri prihlaseni. Shh je ale nastaveny tak, ze akceptuje certifikat, ale aj username/pass.
ak ssh nastavim na akceptaciu IBA certifikatu, pridem o moznost prihlasit sa z ineho klienta, alebo mam problem ked stratim private key certifikatu. napadlo ma zalohovat ich niekde na verejny email, alebo podobne. - ale s tym mam nejaky psychicky problem, mate lepsi napad?
co doporucujete? resp. ako inak este viac zabezpecit pristup na ssh? ma zmysel tam instalovat (ubuntu na bare metal) nejaky SW firevall?
dakujem za kazdy tip, niekedy sa tu da najst naozaj dost uzitocnych veci. (Peto K, stale ma toto forum zmysel)
-
Hele základy zabezpečení ssh si najdes na internetu během jednoho dotazu, ale obecně:
- private key zálohovat, ale určitě né někam na veřejný mail
- certifikát přenes na všechny klienty ze kterých se hodláš přihlašovat
- certifikát je vhodné chránit heslem
- v configu kde jsi měnil port zakaž přihlašení pomocí jmena + hesla
Ale fakt si o tom radši něco přečti, materiálu je hromada, i tady na rootu kdysi vyšla serie článků
-
Přesouvat SSH na jiný port je k ničemu, maximálně si tak odříznete přístup ze sítě, kde budou povolené jen vybrané porty a ten váš mezi nimi nebude.
Nejpodstatnější je zakázat na SSH globálně přihlášení jménem a heslem.
K jednomu účtu si můžete zaregistrovat kolik klíčů chcete. Takže není problém si pro každé přístupové zařízení vygenerovat jiný klíč a další třeba jako záložní, kdybyste o všechny ostatní klíče přišel.
Používat veřejný e-mail k zálohování souborů není dobrý nápad, e-mail slouží k zasílání zpráv a ne k ukládání souborů. K ukládání souborů do cloudu existuje spousta služeb, mnoho z nich má nějakou kapacitu zdarma, kam se vám případně klíč k SSH určitě vejde – např. Dropbox, Box, Google Drive atd. Pokud ten záložní klíč vyexportujete se silným heslem, nebál bych se ho uložit do nějakého cloudového úložiště. Případně pokud jste zvyklý soubory šifrovat, je to ještě bezpečnější (ale nezprovozňoval bych to jenom kvůli tomu, když to nebudete používat průběžně, v případě krize budete mít problém se k tomu klíči dostat, protože co nepoužíváte, to se v průběhu času samo rozbije).
Víc než klíčem nemá smysl to SSH zabezpečovat, ve vašem případě se soustřeďte spíš na ten poštovní server a pak na ten web a databázi, abyste díry neměl tam.
-
Ja som danú situáciu riešil inštaláciou a nastavením fail2ban. Fail2ban zažne postupne tieto adresy blokovať a výrazne klesol počet útokov z cca 500 za hod. na 3 za hod. V IPTABLES je momentalne blokovaných cca 550 IP adries.
-
- certifikát přenes na všechny klienty ze kterých se hodláš přihlašovat
Osobně mi přijde lepší vygenerovat na každém klientovi speciální klíč a naopak všechny jejich veřejné části nahrát na server. Klienta pak můžeš snadno zahodit a nemusíš řešit výměnu klíčů všude. (pozn. možná jsi to takhle i myslel, ale kvůli použití chybného pojmu „certifikát“ jsem to špatně interpretoval)
V IPTABLES je momentalne blokovaných cca 550 IP adries.
Tak to doufám že alespoň používáš ipset a ne tu konfiguraci co bývala defaultní, protože jinak ti teď každé spojení co ti přijde na server musí propadnout 550 pravidly ;)
-
Tak to doufám že alespoň používáš ipset a ne tu konfiguraci co bývala defaultní, protože jinak ti teď každé spojení co ti přijde na server musí propadnout 550 pravidly ;)
Nebylo by lepsi pouzit port-knocking na outside iface?
-
Tak to doufám že alespoň používáš ipset a ne tu konfiguraci co bývala defaultní, protože jinak ti teď každé spojení co ti přijde na server musí propadnout 550 pravidly ;)
Nebylo by lepsi pouzit port-knocking na outside iface?
Normální člověk místo obskurních pitomostí (port knocking) a věcí rozbitých by design (fail2ban) použije VPN.
-
SSH private key sa da preniest aj na HW kluc (Yubikey, Nitrokey, a ine) a dokonca aj na viac klucov a tie drzat oddelene.
-
Normální člověk místo obskurních pitomostí (port knocking) a věcí rozbitých by design (fail2ban) použije VPN.
Nevím, jestli to pomůže. 1) automatizované útoky mi chodí i na VPN:
Oct 9 06:56:25 coralmyn ovpn-server[664]: 142.44.223.234:443 TLS: Initial packet from [AF_INET]142.44.223.234:443, sid=6a22eb44 5adb63fe
Oct 9 06:57:25 coralmyn ovpn-server[664]: 142.44.223.234:443 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivi
ty)
Oct 9 06:57:25 coralmyn ovpn-server[664]: 142.44.223.234:443 TLS Error: TLS handshake failed
Oct 9 06:57:25 coralmyn ovpn-server[664]: 142.44.223.234:443 SIGUSR1[soft,tls-error] received, client-instance restarting
2) nepřijde mi, že by pravděpodobnost vzdáleně zneužitelné chyby byla v OpenVPN menší než v SSH. Možná až začlení WireGuard, tak tomu by se dalo věřit víc.
-
https://www.fail2ban.org/wiki/index.php/HOWTO_fail2ban_with_OpenVPN
-
Nevím, jestli to pomůže. 1) automatizované útoky mi chodí i na VPN:
No jistěže to pomůže. Protože např. tu OpenVPN s certifikátem a heslem bude asi někdo dost blbě lámat, narozdíl od SSH s jménem a heslem "zabezpečeného" nějakou kravinou typu fail2ban.
https://www.fail2ban.org/wiki/index.php/HOWTO_fail2ban_with_OpenVPN
Ano, děkujeme za rozšíření blbého nápadu i na OpenVPN. K čemu to je jako dobré (krom toho, že vás nebudou "obtěžovat" záznamy v logu, který si soudný člověk odfiltruje jinak)? FYI, ta VPN je k tomu, abych se mohl připojit odkudkoliv a přitom nevystavoval do internetu služby typu SSH. Banovat IP adresy, za kterými můžou být tisíce zaNATovaných klientů, je v tomto ohledu úplně padlé na hlavu.
-
Ono fail2ban ma automaticke blokace, ale i deblokace po zadanem case - nevim, co se ti na nem nelibi
-
Nevím, jestli to pomůže. 1) automatizované útoky mi chodí i na VPN:
No jistěže to pomůže. Protože např. tu OpenVPN s certifikátem a heslem bude asi někdo dost blbě lámat, narozdíl od SSH s jménem a heslem "zabezpečeného" nějakou kravinou typu fail2ban.
OpenVPN zabezpečná certifikátem a SSH zabezpečené tím stejným certifikátem se podle mě moc neliší.
FYI, ta VPN je k tomu, abych se mohl připojit odkudkoliv a přitom nevystavoval do internetu služby typu SSH.
Tak místo toho vystavuješ do internetu VPN…
-
Hlavne se jedna o to, ze prolomenim VPNky se jeste nikam nedostanu.
Mel bych az pote jit pres ssh dal dovnitr. Cili zlomit dalsi uroven zabezpeceni
-
zdar,
nastavil som prihlasovanie na SSH vyhradne iba certifikatom, tym padom mi odpadaju fake prihlasenia username/passwd. Ak by som to(napr. OpenVPN) este nastavil tak, ze SSH sa bude dat pouzit vyhradni iba cez VPN, ktora potrebuje na prihlasenie opat certifikat, tak by to uz hadam bolo dostatocne zabezpecene. co myslite?
-
opat certifikat
zabudol som napisat, ze by to bol iny/dalsi certifikat, nie ten isty, ktorym sa prihlasujem na ssh.
-
Tak místo toho vystavuješ do internetu VPN…
Tak konkretne u OpenVPN je krome certu jeste pouzit soucasne i shared secret (tls-auth) na HMAC, coz je docela cpu-rychla cesta jak zahodit nechteny bordel.
I kdyz osobne bych spis sel do IPSec, uz proto ze ma daleko rozsirenejsi klienty.
-
buď hosts.denny nebo fail2ban
když budeš mít šikovné heslo, dost pochybuju, že se podaří s tím někomu vyjebat
Pokud máš, ale v plánu se spojovat na ssh z kdejakého cizího počítače, tak jedině přes certifikát, kterej si ssebou budeš smýkat na USBdisku
-
.... momentalne blokovaných cca 550 IP adries.
Kdy ti to mam prijit dosnout? Hooodne blbej napad. Vygeneruju ti behem par minut klidne par milionu pokusu, kazdej z jiny IP samo, o login a zhrouti se ti to.
...
No jistěže to pomůže. Protože např. tu OpenVPN s certifikátem a heslem bude asi někdo dost blbě lámat, narozdíl od SSH s jménem a heslem "zabezpečeného" nějakou kravinou typu fail2ban....
A neni asi tak 1000x jednodussi si nastavit autorizaci pouze klicem?
...zabudol som napisat, ze by to bol iny/dalsi certifikat, nie ten isty, ktorym sa prihlasujem na ssh.
To je uplne jedno, je to totez jako kdyz pred bepecnostni dvere das jeste dalsi dvere a pred ne jeste dalsi ... a zlodej prijde oknem.
...
Pokud máš, ale v plánu se spojovat na ssh z kdejakého cizího počítače, tak jedině přes certifikát, kterej si ssebou budeš smýkat na USBdisku
To aby si ten cizi pocitac moh ten certifikat v poklidu skopirovat a pripadny heslo odchytit.
-
To je uplne jedno, je to totez jako kdyz pred bepecnostni dvere das jeste dalsi dvere a pred ne jeste dalsi ... a zlodej prijde oknem.
+1
Pokud bych ciste teoreticky byl opravdu paranoidni, pak asi nejak takhle. SSH vystaveno pouze na VPN, IPTABLE umozni pripojit na SSH pouze predem znamym statickym IP klientu. SSH akceptuje pouze pripojeni pres klic. Kazdy klient ma vlastni klic s omezenou dobou platnosti. (Idealne nekoncici vsem naraz). FAIL2BAN nebo jinej log parser upozorni administratora mailem/smskou pokud pokusy o prihlaseni prekroci threshold. Optional: port knocking, zmena SSH portu.
Utocnik v tomhle pripade (pokud neprojde oknem) musi byt schopen proniknout do VPN jako "admin" klient nebo premluvit VPN server o prideleni povolene IP adresy, pripadne se pred serverem tvarit ze ji ma i kdyz nema (MITM pres VPN). Ziskat klic k ssh, a optional vedet spravny port a sequence (coz dokaze ziskat pokud se mu podari proves MITM na VPN). Nebo ziskat user access na klientsky PC/Mobil (vsechna tahle prace prichazi v nivec instalaci prvniho cracku)
No a pak prichazi na radu zabezpeceni oken (aplikace bezici v kontejnerech)
-
To je uplne jedno, je to totez jako kdyz pred bepecnostni dvere das jeste dalsi dvere a pred ne jeste dalsi ... a zlodej prijde oknem.
+1
Pokud bych ciste teoreticky byl opravdu paranoidni, pak asi nejak takhle. SSH vystaveno pouze na VPN, IPTABLE umozni pripojit na SSH pouze predem znamym statickym IP klientu. SSH akceptuje pouze pripojeni pres klic. Kazdy klient ma vlastni klic s omezenou dobou platnosti. (Idealne nekoncici vsem naraz). FAIL2BAN nebo jinej log parser upozorni administratora mailem/smskou pokud pokusy o prihlaseni prekroci threshold. Optional: port knocking, zmena SSH portu.
Utocnik v tomhle pripade (pokud neprojde oknem) musi byt schopen proniknout do VPN jako "admin" klient nebo premluvit VPN server o prideleni povolene IP adresy, pripadne se pred serverem tvarit ze ji ma i kdyz nema (MITM pres VPN). Ziskat klic k ssh, a optional vedet spravny port a sequence (coz dokaze ziskat pokud se mu podari proves MITM na VPN). Nebo ziskat user access na klientsky PC/Mobil (vsechna tahle prace prichazi v nivec instalaci prvniho cracku)
No a pak prichazi na radu zabezpeceni oken (aplikace bezici v kontejnerech)
Udivují mě tady rady od lidí, kteří snad o zabezpečení čtou jen na rootu.J to řiká správně.
SSH klíč nemůže mít nastavenou dobu platnosti, musel bych ho někým podepsat a ssh server nastavit tak, aby akceptoval pouze validní podepsané klíče. Port knocking, změna SSH portu jsou nesystémové změny, které nemají reálný význam.
Kontejner (Linux containers aka LXC aka docker) není vůbec určený k zabezpečení, má spousty míst kudy může útočník uniknout.
Sice jsi super paranoidní, máš vpn s adminem, ale pak tam necháš apache pod rootem či jinou zranitelnou službu a jsi v loji. Zabezpečení serveru musí být komplexní, musí se řešit veškeré služby, musí se řešit jejich pravidelná aktualizace (co bylo neproniknutelné dnes, je děravé zítra), logy se samozřejmě musí zpracovávat.
Fail2ban je nesmysl, snadno se dá zahltit a poslat server do kolen, při jeho restartu se pak může najít slabina u nějaké služby (velká část služeb startuje pod rootem a teprve posléze snižuje svoje práva) či prostě stačí jen omezit dostupnost serveru a vyprovokovat admina k unáhleným krokům a otevření vrat. FW pravidla musí být před samotným serverem, jejich automatické bezhlavé vyplňování do lokálního iptables je cesta do pekel, s ipv6 ta cesta má ještě zkratku.
-
myslim, ze sa to tu uz zvrhava na zabezpecenie celeho servera/kontajnera, to ale nebola povodna otazka. ci sa uz utocnik dostane ku mne oknom, alebo kominom je momentalne uplne jedno a nie je potrebne to riesit. otazka smerovala vyhradne na komunikaciu so serverom cez ssh. ak to teda zhrniem, dostali sme sa "len" k dalsej vrstve a to dodatocne zabezpecenie pomocou VPN. pevna IP adresa neprichadza do uvahy, pretoze telekom z casu na cas zmeni moju verejnu adresu a v tom pridade som v pr.eli. takze, ked budem mimo svoj notas, tak by som sa rad pripojil na server, napr z ineho/kamaratovho notasu alebo mi moj notas zdochne - opat musim ist "do susedov" a fixnut pripadny problem odtadial. btw. na ten server sa pripajam vyhradne z nedneho clienta na 99,999% . takze ak vas uz nic ine produktivne nenapada, zostaneme pri tom prihlaseni pomocou kluca/certifikatu do ssh a pristup do ssh je povoleny iba cez vpn. akekolvek ine pripomienky, zlepsujuce zabezpecenie ssh kludne pridavajte dalej, nerieste prosim okna a komin.
dakujem
-
vyhradne z nedneho
...vyhradne z jedneho...
pardon