Řešení 1:
Miluji myšlenku přístupu k serverům pomocí klíčů, takže nemusím zadávat své heslo pokaždé, když ssh do schránky, dokonce zamykám heslo svého uživatele (nikoli root) (passwd -l uživatelské jméno), takže se nelze přihlásit bez klíče...Doporučili byste/nedoporučili byste to udělat pro uživatelský účet na serveru?
Jdete o deaktivaci přihlášení na základě hesla špatným způsobem. Místo uzamčení uživatelského účtu nastavte PasswordAuthentication no ve vašem /etc/ssh/sshd_config .
S touto sadou je ověřování heslem pro ssh zakázáno, ale stále můžete používat heslo pro sudo.
Jediné čas doporučuji nastavit NOPASSWD in sudo je pro servisní účty, kde procesy musí být schopny spouštět příkazy přes sudo programově. Za těchto okolností se ujistěte, že jste výslovně uvedli na seznam povolených pouze konkrétní příkazy, které musí účet spustit. U interaktivních účtů byste měli vždy nechte hesla povolená.
Odpovědi na vaše doplňující otázky:
Ale myslím, že když zakážu ověřování heslem v /etc/ssh/sshd_config, takže stále musíte mít klíč k přihlášení, mohu použít jednodušší heslo jen pro sudo, které se snáze zadává? Je to platná strategie?
Ano, to je správně. Stále doporučuji používat relativně silná hesla místních účtů, ale ne směšně silná. ~8 znaků, stačí náhodně vygenerovat.
Pokud mám také klíč k přihlášení jako root přes ssh, pokud někdo získá přístup k mému počítači a ukradne mé klíče (stále jsou však chráněny heslem klíčenek OS!), mohl by také získat přímý přístup k účtu root, obcházení sudo cesty.
Přístup root přes ssh by měl být zakázán. Doba. Nastavte PermitRootLogin no ve vašem sshd_config .
Jaké by tedy měly být zásady pro přístup k účtu root?
Vždy byste měli mít prostředky k získání mimopásmového přístupu ke konzole vašeho serveru. Několik dodavatelů VPS to poskytuje, stejně jako prodejci vyhrazeného hardwaru. Pokud váš poskytovatel neudělí skutečný přístup ke konzole (řekněme například EC2), můžete obvykle stále obnovit přístup pomocí procesu, jako je to, co nastíním v této odpovědi.
Řešení 2:
Obecně omezuji používání NOPASSWORD na příkazy, které spouští automatizovaný proces. Je vhodnější mít pro tyto příkazy servisní účet a omezit použití sudo na požadované příkazy.
Povolení NOPASSWORD pro obecné příkazy umožňuje komukoli, kdo získá přístup k vašemu uživatelskému id, spouštět jakékoli příkazy. Mohlo by to být důsledkem kompromitace vašich přihlašovacích údajů, ale může to být tak jednoduché, jako když někdo sedí u vašeho stolu, když na chvíli odstoupíte.
Zjistil jsem, že své heslo nemusím zadávat tak často. Jakmile zadáte heslo, můžete spustit několik příkazů, pokud mezi nimi nebudete čekat příliš dlouho. Časový limit je konfigurovatelný.
Řešení 3:
Můžete mít to nejlepší z obou světů:ověřování SSH pro přihlášení i pro sudo. Pokud integrujete modul pam_ssh_agent_auth, můžete použít klíče SSH k autentizaci bez zadávání hesla při sudo.
Používám to ve výrobě více než pět let.
Chcete-li jej nakonfigurovat, nainstalujte modul PAM a poté přidejte řádek do /etc/pam.d/sudo nebo ekvivalent vašeho systému:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Pokud tak učiníte, nezapomeňte chránit klíče v počítači pomocí přístupové fráze. Tak by se někdo musel nabourat do vašeho počítače a ukrást klíče, aby se dostal dovnitř. Mohl by to udělat tak, že by je vytáhl z paměti, když byly odemčené, pokud měl přístup k vašemu účtu, prolomil vaši přístupovou frázi nebo ukradl vaši přístupovou frázi keylogger nebo rameno, které na něm surfuje, zatímco ho zadáváte (dívejte se za sebe!).
K přihlášení můžete použít stejný klíč SSH jako vy, nebo můžete nastavit samostatný klíč, který přidáte svému agentovi pouze při sudo. Takže pokud chcete být extra opatrní, můžete udržovat samostatný soubor author_keys, který má samostatný klíč SSH, který přidáte do svého agenta pouze tehdy, když potřebujete sudo:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo
Řešení 4:
Použil bych to pouze za dvou okolností:
- Když je to naprosto vyžadováno pro automatický skript, který běží jako konkrétní uživatel
- Pro konkrétní administrátorské úlohy (administrátorské úlohy pouze pro čtení, nikoli ty, které provádějí akci za účelem změny systému) a samozřejmě pouze pro konkrétní uživatele
Ve výchozím nastavení nejvíce sudo konfigurace se vás na chvíli ve stejné relaci nebudou ptát (pokud otevřete nový shell, který nemá žádný účinek). Toto chování můžete do určité míry ovládat pomocí timestamp_timeout nastavení.
sudo bez hesla není zdaleka tak nebezpečný jako ssh bez přístupového hesla klíče, protože vzdálený útočník potřebuje především vaše přihlašovací údaje, aby se dostal dovnitř, ale pokud se dostali nějakým kompromitováním vašeho soukromého klíče (nebo pokud jsou pro vás fyzicky místní a nechali jste se přihlášeni a odemčeni, když jste byli pryč z počítače), pak je požadavek na heslo cennou další obranou mezi nimi a privilegovaným přístupem.
Pokud jde o následnou akci 2:
Pokud mám také klíč k přihlášení jako root přes ssh
I tomu je nejlepší se vyhnout, přesně z důvodu, který popisujete. Pokud vzdálené připojení musí mít privilegovaný přístup, přihlaste se prostřednictvím servisního účtu a dejte mu dostatek kontroly, aby mohl vykonávat svou práci pomocí sudo. Toto je samozřejmě vhodnější pro konfiguraci, takže se mnoho lidí neobtěžuje (což je ve váš prospěch, pokud ano, protože existuje spousta nižších visících plodů než vy, na kterých mohou útočníci strávit čas!), takže přijde na řadu starý kompromis mezi bezpečností a pohodlím (profi tip:vyberte si bezpečnost!).
Řešení 5:
Protože jste se zeptali, zde je moje obecná rada, jak řešit sudo problém.
Sudo nebylo navrženo tak, aby poskytovalo větší zabezpečení (i když v určitém ohledu může)... ale spíše poskytovalo dobrou auditní stopu toho, kdo co na vašem systému dělá s jakými oprávněními.
Správně nastavené Sudo nebude používat ALL=(ALL) ALL nastavení, ale spíše něco omezenějšího na cokoli, co konkrétně uživatel potřebuje. Pokud například potřebujete, aby se uživatel mohl přihlásit a restartovat zaseknutou službu, pravděpodobně nebude potřebovat možnost instalovat nový software nebo vypínat váš server, měnit pravidla brány firewall atd.
Někdy je běžné, že lidé používají sudo, aby se povýšili na účet root, tzn. sudo su - . Jakmile to udělají, přestanete vidět, kdo co dělá z účtu root (root může být přihlášen vícekrát současně). Takže někdy lidé chtějí deaktivovat sudo su - příkaz také. Ale z praktických důvodů, pokud pro administraci potřebujete účet s plně privilegovanými oprávněními uživatele root, alespoň si nechat někoho vydat sudo su - příkaz by zaprotokoloval, kdo a kdy povýšil na root.
Jak zajistím své krabice:
Změňte port SSH na jiný než výchozí. Je to proto, abyste se vyhnuli hloupým robotům, kteří hledají čísla portů a pak odrážejí, dokud se nedostanou (nebo ne).
Zakažte přihlášení uživatele root přes SSH pomocí AllowRootLogin no nastavení ve vašem sshd_config. To zabrání tomu, aby někdo vnutil váš root účet. Obecně je dobrým zvykem nikdy nikomu nedovolit přímo se přihlásit k účtu root/administrátor z důvodů auditu a také z důvodu zabezpečení. Pokud povolíte přihlášení root přímo, nevíte, kdo se přihlásil, od koho získal heslo atd. Ale pokud se někdo přihlásí k Jimmyho účtu a poté zvýší svá oprávnění na root, budete mít lepší představu, kde začít auditovat vyhledávání (a kdo má účet resetovat).
Povolit SSH pouze uživatelům, kteří to vyžadují Použijte AllowUsers nastavení a explicitně určují, které účty potřebují přístup SSH. To ve výchozím nastavení zablokuje všechny ostatní účty před SSH.
Upravujte Sudoers pomocí visudo a povolte pouze příkazy, které uživatel potřebuje. Existuje mnoho podrobných návodů, jak to udělat, takže zde nebudu podrobně popisovat. Zde je začátek:http://ubuntuforums.org/showthread.php?t=1132821
Podstatou toho je zabránit tomu, aby kompromitovaný účet ohrozil váš počítač. tj. pokud se Sally nabourá do účtu a Sally může použít pouze sudo k restartování webového serveru, útočník by se mohl bavit restartováním vašeho webového serveru ve smyčce, ale alespoň nemůže rm -rf /your/webserver/directory nebo otevřete všechny porty brány firewall atd.
Nastavte dobrá pravidla brány firewall, která povolí pouze porty, které jsou nezbytné pro fungování vašeho boxu. Obecně chcete vypustit všechno a povolit pouze to, co potřebujete. Existuje spousta slušných iptables a další firewall se spouští online, zde je jeden, který používám (je to základní startér):
# Generated by iptables-save v1.4.7 on Mon Mar 3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar 3 17:55:02 2014
Klíčové je také silné heslo. I když používáte SSH klíče pro vzdálený přístup, měli byste stále vyžadovat heslo pro použití Sudo. Toto je případ, kdy sudo může poskytnout větší zabezpečení. Pokud by někdo ukradl vaše klíče ssh, stále by mu bylo zabráněno v tom, aby na vašem boxu udělal něco významného, pokud bude muset stále hrubě vynucovat heslo vašeho účtu, aby používal sudo. Hesla by neměla být slovo, ale spíše Pass Phrase. Vymyslete větu a použijte ji. To vám obecně poskytne něco delšího než 8 znaků, což poskytuje spoustu entropie, ale také je snáze zapamatovatelné než nějaké náhodné heslo. Samozřejmě, osvědčené postupy pro hesla říkají, že je třeba použít strojově vygenerované náhodné heslo k oklamání nástrojů pro prolomení, jako je John the Ripper, které prolomí většinu přístupových frází a hesel. Ne, změna E na 3 nefunguje, John dostane také tyto permutace.