Co jakiś czas pojawia się dziwne żądanie zdalnego wsparcia, rozwiązywania problemów i / lub dostrajania wydajności w systemach Linux.

Większe firmy często mają już dobrze ustalone procedury zapewniające zdalny dostęp do dostawców / dostawców, a ja muszę tylko je przestrzegać. (Na dobre i na złe.)

Z drugiej strony małe firmy i osoby niezmiennie zwracają się do mnie z instrukcją, co muszą zrobić, aby mnie skonfigurować. Zazwyczaj ich serwery są bezpośrednio podłączone do Internetu, a istniejące środki bezpieczeństwa obejmują wartości domyślne dla dowolnej dystrybucji Linuksa.

Prawie zawsze będę potrzebować dostępu na poziomie administratora, a ktokolwiek będzie dla mnie konfigurował dostęp, nie jest ekspertem administracyjnym. Nie chcę ich hasła roota i jestem również pewien, że moje działania nie będą złośliwe, ale jakie rozsądnie proste instrukcje powinienem przekazać:

• załóż konto i bezpiecznie wymień dane uwierzytelniające
• skonfiguruj dostęp do roota (sudo)
• ogranicz dostęp do mojego konta
• zapewnić ścieżkę audytu

(I tak, jestem świadomy i zawsze ostrzegam tych klientów, że kiedy już mam dostęp administratora, ukrywanie złośliwych działań jest banalne, ale załóżmy, że nie mam nic do ukrycia i aktywnie uczestniczę w tworzeniu ścieżki audytu.)

Co można poprawić, wykonując poniższe kroki?

Mój aktualny zestaw instrukcji:

załóż konto i bezpiecznie wymień dane uwierzytelniające

Podaję skrót hasła i proszę o skonfigurowanie mojego konta z tym zaszyfrowanym hasłem, więc nie będziemy musieli przesyłać hasła w postaci zwykłego tekstu, będę jedynym, który zna hasło i nie zaczynamy od przewidywalne słabe hasło.

sudo useradd -p '$1$********' hbruijn

Podaję klucz publiczny SSH (konkretna para kluczy na klienta) i pytam, czy skonfigurowali moje konto z tym kluczem:

sudo su - hbruijn
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys 

skonfiguruj dostęp do roota (sudo)

Proszę klienta, aby skonfigurował dla mnie sudo za pomocą sudo sudoeditlub za pomocą swojego ulubionego edytora i dołączył /etc/sudoers:

hbruijn ALL=(ALL) ALL

ogranicz dostęp do mojego konta

Zazwyczaj klient nadal zezwala na logowanie oparte na hasłach i proszę o dodanie następujących dwóch linii, aby /etc/ssh/sshd_configprzynajmniej ograniczyć moje konto tylko do kluczy SSH:

Match user hbruijn
PasswordAuthentication no

W zależności od klienta przekieruję cały mój dostęp SSH przez jednego hosta bastionu, aby zawsze zapewniał pojedynczy statyczny adres IP (na przykład 192.168.1.2) i / lub podawał zakres adresów IP, z których korzysta mój dostawca usług internetowych (na przykład 10.80. 0,0 / 14). Klient może potrzebować dodać je do białej listy zapory, jeśli dostęp SSH jest ograniczony (najczęściej ssh nie jest jednak filtrowany).

Widziałeś już te adresy IP jako from=ograniczenie w ~.ssh/authorized_keyspliku, które ogranicza hosty, z których mój klucz może być używany do uzyskiwania dostępu do ich systemów.

zapewnić ścieżkę audytu

Do tej pory żaden klient mnie o to nie prosił i nie zrobiłem nic konkretnego poza następującymi czynnościami:

Staram się konsekwentnie używać sudoz poszczególnymi poleceniami i staram się zapobiegać używaniu sudo -ilub sudo su -. Staram się nie używać, sudo vim /path/to/file ale sudoeditzamiast tego używam .

Domyślnie wszystkie akcje uprzywilejowane zostaną następnie zarejestrowane w syslog (i /var/log/secure):

Sep 26 11:00:03 hostname sudo:  hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=jboss ; COMMAND=sudoedit /usr/share/jbossas/domain/configuration/domain.xml  
Sep 26 11:00:34 hostname sudo:  hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=root ; COMMAND=/usr/bin/tail -n 5 /var/log/messages

W większości rezygnuję z dostosowywania środowiska pracy, jedyne, co naprawdę robię, to ustawianie następujących elementów w mojej ~/.bash_profilehistorii bashów i dołączanie znaczników czasu:

export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S  '
shopt -s histappend

Jedyne, co przychodzi na myśl, to dodanie --expiredatedo adduserrozmowy.
Dzięki temu klient wie, że Twój dostęp wygaśnie automatycznie w określonym terminie.

Nadal musi ci ufać, ponieważ masz dostęp do konta root i nadal może usunąć flagę wygasania.

Możesz nagrywać swoje sesje za pomocą narzędzia script (1) .

$ script session.log
Script started, file is session.log
$ ls
file1  session.log
exit
Script done, file is session.log

wtedy wszystko jest w session.log.

Ponieważ już logujesz się przy użyciu klucza publicznego SSH, to trochę zaostrzyłoby się, gdybyś nie podał skrótu hasła; zamiast tego powiedz im, aby użyli adduser --disabled-password(równoważnie, useradd -p '!'jak sądzę), co jest faktycznie równoważne z PasswordAuthentication notym kontem, a ponadto nie ma szans, że ktoś szpiegujący twój adres e-mail mógłby brutalnie wymusić skrót hasła i zalogować się jako Ty.

Po co w ogóle podawać hasło, jeśli zamierzasz używać kluczy publicznych / prywatnych.

Klucze publiczne mają być udostępniane, dlatego należy tego używać do bezpiecznej wymiany poświadczeń, a nie mieszania haseł.

sudo useradd --disabled-password hbruijn

Wysyłając swój klucz publiczny, sprawdź odcisk palca na drugim kanale, np. Podczas rozmowy telefonicznej, abyś wiedział, że nikt go nie zmienił po drodze.

Ponieważ nie będziesz już mieć hasła do korzystania z sudo, musisz również zmienić linię w pliku sudoers na

hbruijn ALL=(ALL) NOPASSWD:ALL

Jeśli nie czujesz się komfortowo z brakiem hasła do sudo i naprawdę chcesz hasła, nadal nie musisz wysyłać swojego hasha, pozwól, aby konto zostało utworzone bez hasła, ustaw swój klucz publiczny, a gdy konto zostanie skonfiguruj, możesz zalogować się przez ssh i uruchomić, passwdaby ustawić własne hasło.