Co to jest kontrola stanu SSH?

Kontrola stanu SSH umożliwia inspekcję i konfigurowanie stanu zabezpieczeń serwera SSH w obsługiwanych dystrybucjach systemu Linux, w tym Ubuntu, Red Hat, Azure Linux i innych. Kontrola stanu SSH bezproblemowo integruje się z usługami ładu platformy Azure (Policy, Machine Configuration), dzięki czemu można wykonywać następujące czynności:

Zapewnianie zgodności ze standardami sshd w branży lub organizacji
Zmniejszenie obszaru ataków zdalnego zarządzania opartego na dysku SSHD
zapewnić spójną konfigurację sshd dla całej floty w celu zapewnienia bezpieczeństwa i produktywności

Zrzut ekranu przedstawiający listę zgodnych testów SSH

Aby ułatwić zademonstrowanie zgodności z audytorami (i pomoc w podjęciu działań w razie potrzeby), każda kontrola zgodności zawiera dowody za pośrednictwem pola Powody wskazujące, w jaki sposób określono zgodność lub niezgodność.

Możesz dostosować parametry SSHD (numer portu, dozwolone grupy itp.) lub użyć wartości domyślnych zasad, które są dopasowane do punktu odniesienia zabezpieczeń platformy Azure dla systemu Linux.

Dokumentacja dotycząca rozpoczynania pracy

Przewodnik Szybki start: aby uzyskać praktyczne środowisko kliknięcia, zobacz Szybki start: stosowanie kontroli stanu SSH do maszyny testowej.
Omówienie i dokumentacja: Aby uzyskać informacje koncepcyjne, dokumentacja i często zadawane pytania, przejdź do tego artykułu.

Wybieranie zachowania tylko do inspekcji i konfigurowania

Podczas przypisywania zasad kontroli stanu SSH można wybrać zachowanie tylko do inspekcji (czyli "Inspekcja") lub inspekcji i konfigurowania (np. "Konfigurowanie").

	Definicja zasad	Efekt usługi Azure Policy	Uwagi na temat tego, czego można oczekiwać
zachowanie tylko do inspekcji	`Audit SSH Posture Control on Linux machines`	auditIfNotExists	Zasady zawierają bardziej restrykcyjne ustawienia w porównaniu z wieloma popularnymi obrazami systemowymi. Na przykład odmowa dostępu do głównego protokołu SSH. W związku z tym należy oczekiwać, że zgłoszone stany niezgodne.
zachowanie inspekcji i konfigurowania	`Configure SSH Posture Control on Linux machines`	deployIfNotExists	Jak powyżej, można oczekiwać, że początkowo stany niezgodne. Następnie maszyny zostaną ponownie skonfigurowane tak, aby były zgodne z zasadami, co spowoduje ostateczne stanów zgodne.

W przypadku istniejących maszyn administratorzy zazwyczaj zaczynają od zachowania tylko inspekcji w celu określenia istniejącego stanu i odnajdywania zależności, takich jak konta dozwolone dla automatyzacji systemów. Po porównaniu istniejącej floty z domyślnymi ustawieniami kontroli stanu SSH należy zdecydować, które parametry kontroli stanu SSH mają być dostosowane. Po tej analizie i planowaniu nastąpi przejście do zachowania inspekcji i konfiguracji (z bezpiecznymi rozwiązaniami wdrażania, takimi jak pierścienie).

W przypadku scenariuszy greenfield lub jednorazowych maszyn testowych możesz pominąć tę analizę i przejść bezpośrednio do zachowania inspekcji i konfigurowania, zaczynając od silnych domyślnych ustawień kontroli stanu SSH.

Ostrożność

Przed skonfigurowaniem jakichkolwiek maszyn należy dobrze sprawdzić poprawność nowej konfiguracji. Możesz przypadkowo utracić dostęp do maszyn.

Przykłady przypadkowego zablokowania się:

Zastosowane ustawienia autoryzacji netto (kombinacja allowUsers,denyGroups,permitRootLoginitp.) nie zezwalają na wymagane identyfikatory logowania
port skonfigurowany dla dysku SSHD jest blokowany przez inne kontrolki w środowisku (zasady SELinux, reguły zapory hosta, reguły zapory sieciowej itp.)
- Należy pamiętać, że wiele dystrybucji rodziny Red Hat ma zasady SELinux domyślnie, które blokują dysk sshd z używania portów innych niż 22.
- Aby uniknąć przekraczania granic zespołu przedsiębiorstwa, kontrola stanu SSH skonfigurowała tylko sshd. Obecnie nie próbuje modyfikować zasad SELinux maszyny, reguł zapory itp., aby pomieścić skonfigurowany port sshd. Jeśli chcesz omówić te scenariusze z nami, skontaktuj się z nami (zobacz Dodatkowe zasoby poniżej).

Zakres kontroli stanu SSH: reguły, ustawienia domyślne i dostosowywanie

W poniższej tabeli wymieniono elementy, które można przeprowadzić inspekcję lub skonfigurować za pomocą kontroli stanu protokołu SSH. Każda z nich jest nazywana regułą .

Każda reguła ma domyślną wartość konfiguracji zgodną z punktem odniesienia zabezpieczeń platformy Azure dla systemu Linux.

Większość reguł może mieć wartości niestandardowe, za pośrednictwem przypisania zasad parametrów inspekcji pod kątem inspekcji lub konfigurowania i inspekcji. Jeśli na przykład standardem w organizacji jest użycie portu 1111 (zamiast 22) dla dysku sshd, należy ustawić odpowiedni parametr w przypisaniu zasad. Te parametry mają identyfikatory, które znajdują się w poniższej tabeli. Zazwyczaj krótka nazwa parametru jest używana programowo (na przykład z az policy assignment create --params ...), podczas gdy dłuższa nazwa wyświetlana parametru jest używana w przepływach pracy witryny Azure Portal.

Podczas dostosowywania wartości należy zapewnić wartości zgodne z plikiem sshd. Na przykład allowGroups zajmuje rozdzielaną spacją listę wzorców nazw grup. Aby uzyskać informacje, zobacz stronę człowieka sshd_config. Dokumentacja sshd_config jest również przydatna do zrozumienia innych zachowań dysku SSHD, takich jak sposób, w jaki zezwalać na i odmów listy przecinają się.

Nuta

Aby zachować układ tabeli, niektóre wartości komórek zostały przeniesione do przypisów dolnych poniżej tabeli.

Nazwa reguły	Wartość domyślna	Nazwa parametru	Nazwa wyświetlana parametru
Upewnij się, że skonfigurowano uprawnienia dla /etc/ssh/sshd_config	600	<przypis 1>	Uprawnienia dostępu dla sshd_config
Upewnij się, że właściwość IgnoreRhosts jest ustawiona	tak	`ignoreHosts`	Ignoruj hosty rhost i hosty
Upewnij się, że ustawiono wartość LogLevel	INFORMACJI	`logLevel`	Poziom szczegółowości dziennika
Upewnij się, że parametr MaxAuthTries jest ustawiony	6	`maxAuthTries`	Maksymalna liczba prób uwierzytelniania
Upewnij się, że dostęp SSH jest skonfigurowany dla dozwolonych użytkowników	@ <zobacz przypis 5>	`allowUsers`	Zezwalanie użytkownikom na protokół SSH
Upewnij się, że nie skonfigurowano użytkowników na potrzeby dostępu SSH	korzeń	`denyUsers`	Odmowa użytkowników dla protokołu SSH
Upewnij się, że skonfigurowane są dozwolone grupy dostępu SSH	*	`allowGroups`	Dozwolone grupy dla protokołu SSH
Upewnij się, że skonfigurowano grupy odmowy dostępu SSH	korzeń	`denyGroups`	Odrzucone grupy dla protokołu SSH
Upewnij się, że ustawiono opcję HostbasedAuthentication	Nie	`hostBasedAuthentication`	Uwierzytelnianie oparte na hoście
Upewnij się, że ustawiono właściwość PermitRootLogin	Nie	`permitRootLogin`	Czy użytkownik główny może się zalogować przy użyciu protokołu SSH
Upewnij się, że właściwość PermitEmptyPasswords jest ustawiona	Nie	`permitEmptyPasswords`	Czy serwer zezwala na logowanie do kont z pustymi ciągami haseł
Upewnij się, że właściwość ClientAliveCountMax jest ustawiona	0	`clientAliveCountMax`	Liczba komunikatów żywcem klienta, które mogą być wysyłane bez dysku SSHD odbierającego komunikaty z powrotem z klienta
Upewnij się, że parametr ClientAliveInterval jest ustawiony	3600	`clientAliveInterval`	Interwał limitu czasu w sekundach, po którym jeśli żadne dane nie zostały odebrane od klienta, sshd wyśle komunikat, aby zażądać odpowiedzi
Upewnij się, że karty MACs są skonfigurowane	<przypis 2>	<przypis 3>	Lista dostępnych algorytmów uwierzytelniania komunikatów (MAC)
Upewnij się, że baner został skonfigurowany	<przypis 4>	`banner`	Zawartość pliku baneru wysyłanego do użytkownika zdalnego przed zezwoleniem na uwierzytelnianie
Upewnij się, że właściwość PermitUserEnvironment jest ustawiona	Nie	`permitUserEnvironment`	Czy opcje ~/.ssh/environment i environment= w pliku ~/.ssh/authorized_keys są przetwarzane przez plik sshd
Upewnij się, że skonfigurowano szyfrowanie	aes128-ctr,aes192-ctr,aes256-ctr	`ciphers`	Lista dozwolonych szyfrów
Upewnij się, że port SSH jest skonfigurowany	22	`port`	Port SSH
Upewnij się, że jest używany protokół najlepszych rozwiązań	2	<brak parametru>	<brak parametru>

Przypisy dolne tabeli:

accessPermissionsForSshdConfig
messageAuthenticationCodeAlgorithms
hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com
#######################################################################\n\nAuthorized access only!\n\nIf you are not authorized to access or use this system, disconnect now!\n\n#######################################################################\n
1. Uwaga: ta opcja jest wyświetlana dla użytkowników końcowych jako:
```
#######################################################################

Authorized access only!

If you are not authorized to access or use this system, disconnect now!

#######################################################################
```
W allowUsers wartość domyślna "@" reprezentuje wszystkie konta na maszynie

Dodatkowe parametry zasad (inne niż sshd)

Te dodatkowe parametry zasad są dostępne podczas przypisywania zasad. Mają one wpływ na zachowanie przypisywania usługi Azure Policy, a nie ustawienia sshd na maszynach.

Nazwa	Opis	Domyślny
Dołączanie serwerów połączonych z usługą Arc	Wybierając tę opcję, zgadzasz się na naliczanie miesięcznych opłat za połączoną maszynę z usługą Arc.	FAŁSZYWY
Efekt	Włączanie lub wyłączanie wykonywania tych zasad	<zależy od wybieranie zachowania tylko do inspekcji i konfigurowania>

Definicje zasad? Przypisania zasad? Przypisania gościa? Konfiguracja maszyny? Jak to wszystko pasuje do siebie?

Aby rozpocząć pracę z kontrolą stanu SSH, podstawową akcją jest utworzenie przypisania zasad . Przypisanie zasad łączy definicję zasad (np. "Przeprowadź inspekcję kontroli stanu SSH dla maszyn z systemem Linux") do zakresu (np. "my_factory_3_resource_group").

Podczas korzystania z systemu napotkasz dodatkowe typy zasobów i terminologię, jak podsumowano w poniższej sekcji.

diagram przedstawiający sposób, w jaki przypisanie zasad łączy maszyny z usługą Konfiguracji maszyny za pośrednictwem przypisań gościa

	Opis
definicji zasad	W usłudze Policy dane abstrakcyjne opisujące klaster dostępnych zachowań inspekcji i/lub konfiguracji. Na przykład "Przeprowadź inspekcję kontroli stanu SSH na maszynach z systemem Linux".
przypisywania zasad	Łączy abstrakcyjną definicję zasad z konkretnym zakresem, takim jak grupa zasobów. Przypisanie zasad może zawierać parametry i inne właściwości specyficzne dla tego przypisania.
Konfiguracja maszyny	Usługa platformy Azure i agentry, które obsługują inspekcję i konfigurowanie ustawień na poziomie systemu operacyjnego.
przypisanie gościa	Zasób, który działa jako trzykierunkowe połączenie między przypisaniem zasad, maszyną i usługą Machine Configuration. Zasady tworzą i monitorują zasoby przypisania gościa zgodnie z potrzebami. Aby uzyskać więcej informacji na temat terminologii "gość" a "maszyna", zobacz Dlaczego widzę terminy "Konfiguracja gościa" i "Automanage" w miejscach?
Machine	Maszyna z obsługą usługi Arc lub maszyna wirtualna platformy Azure.

Informacje o zgodności (dystrybucje, implementacje serwera SSH itp.)

Kontrola stanu SSH jest przeznaczona dla głównego nurtu ogólnego przeznaczenia scenariusza systemu Linux pojedynczego długotrwałego wystąpienia serwera SSH:

którego cykl życia jest zarządzany przez system init sush jako systemd
którego zachowanie jest zgodne z zachowaniem sshd_config pliku, zgodne z zachowaniem sshd protokołu OpenSSH
których efektywna konfiguracja/stan są ujawniane przez dane wyjściowe sshd -T zgodne z zachowaniem sshd protokołu OpenSSH

W przypadku wszystkich obsługiwanych dystrybucji (zobacz poniżej) jest to domyślny przypadek użycia serwera SSH.

W zasadzie maszyna może mieć dowolną liczbę wystąpień serwera SSH uruchomionych z różnym okresem istnienia, na podstawie dowolnej liczby baz kodu i biorąc ich konfigurację z dowolnej liczby miejsc (plików konfiguracji, argumentów wiersza polecenia, parametrów czasu kompilacji itp.). Takie przypadki są obecnie poza zakresem kontroli stanu SSH. Jeśli interesuje Cię taka sytuacja w przyszłości, skontaktuj się z nami, aby omówić.

Kontrola stanu SSH jest przeznaczona do użycia w tych dystrybucjach systemu Linux obsługiwanych przez usługę Azure Policy i konfigurację maszyny — z wyłączeniem tych, które były objęte rozszerzoną obsługą w czasie opracowywania. W szczególności następujące elementy należą do zakresu od 2024-06-05:

AlmaLinux 9
Amazon Linux 2
Ubuntu Server 20.04
Ubuntu Server 22.04
Debian 10
Debian 11
Debian 12
Azure Linux (CBL Mariner) 2
Oracle Linux 7
Oracle Linux 8
CentOS 7.3
CentOS 8
RHEL 7.4
RHEL 8
RHEL 9
Rocky Linux 9
SLES 15

W miarę możliwości kontrola stanu SSH jest testowana przy użyciu specyficznych powszechnie używanych kompozycji systemowych powyższych dystrybucji. Na przykład kompozycje obrazów systemu operacyjnego opublikowane przez osoby odpowiedzialne za dystrybucję w galerii platformy Azure. Zgodność z dowolną konkretną maszyną w czasie wykonywania nie może być gwarantowana, ponieważ administratorzy systemu i konstruktorzy obrazów mogą usuwać składniki z systemu operacyjnego, tworzyć systemy plików tylko do odczytu, blokować akcje agenta za pomocą narzędzia SELinux itp.

Zgodność z dyrektywami sshd_config Include

Kontrola stanu SSH próbuje uwzględnić i wykorzystać dyrektywy Include w sshd_config w następujący sposób:

W przypadku akcji inspekcji/odczytu: polegaj na -T sshd, aby odzwierciedlić konfigurację sieci z perspektywy sshd — biorąc pod uwagę wszystkie dołączania.
W przypadku akcji konfigurowania/zapisu:
- Jeśli implementacja sshd na maszynie obsługuje funkcję Dołączanie, połącz nowy plik specyficzny dla kontroli stanu SSH, aby sshd_config (jako dołączanie). Następnie umieść wszystkie operacje zapisu w połączonym pliku kontroli stanu SSH. Zwiększa to higienę systemu i możliwość śledzenia zmian systemu.
- Jeśli implementacja sshd na maszynie nie obsługuje dyrektyw Include, zapisz zmiany konfiguracji bezpośrednio w sshd_config.

Zgodność z dyrektywami sshd_config Match

Kontrola stanu SSH jest przeznaczona do inspekcji i konfigurowania zachowania podstawowego dysku SSHD. Nie podejmuje próby interakcji z blokami Match warunkowych (jeśli istnieją), które mogą stosować różne konfiguracje sshd do określonych populacji.

Jak programowo wykonywać zapytania dotyczące wyników?

Za pomocą zapytań usługi Azure Resource Graph (ARG) można zintegrować dane przypisania i stanu z własnymi przepływami pracy. W tych przykładach użyto Search-AzGraph w programie PowerShell do wykonania zapytania ARG, ale program PowerShell nie jest wymagany. Usługi ARG można używać z wielu punktów wejścia, w tym witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, wywołań REST itp.

Na największej wysokości podsumowania można uzyskać liczniki maszyn na zasobnik stanu zgodności. Na przykład:

$machineCountsQuery = @'
// SSH machine counts by compliance status
guestconfigurationresources
| where name contains "LinuxSshServerSecurityBaseline"
| extend complianceStatus = tostring(properties.complianceStatus)
| summarize machineCount = count() by complianceStatus
'@

Search-AzGraph -Query $machineCountsQuery

<#
Sample output from an environment with two machines:

complianceStatus machineCount
---------------- ------------
Pending                     1
Compliant                   1
#>

Aby przejść do szczegółów w taki sposób, aby zobaczyć ogólny stan zgodności według maszyny, możesz użyć następujących elementów:

$machinePerRowQuery = @'
// SSH machine level compliance
guestconfigurationresources
| where name contains "LinuxSshServerSecurityBaseline"
| project 
 machine = split(properties.targetResourceId,'/')[-1],
 complianceStatus = properties.complianceStatus,
 lastComplianceStatusChecked = properties.lastComplianceStatusChecked
'@

Search-AzGraph -Query $machinePerRowQuery

<#
Sample output:

machine     complianceStatus lastComplianceStatusChecked
-------     ---------------- ---------------------------
sshdemovm01 Compliant        2/15/2024 11:07:21 PM
sshdemovm02 Pending          1/1/0001 12:00:00 AM
#>

Aby przejść do szczegółów ustawień po ustawieniu, możesz użyć następujących elementów:

$settingPerRowQuery = @'
// SSH rule level detail
GuestConfigurationResources
| where name contains "LinuxSshServerSecurityBaseline"
| project report = properties.latestAssignmentReport,
 machine = split(properties.targetResourceId,'/')[-1],
 lastComplianceStatusChecked=properties.lastComplianceStatusChecked
| mv-expand report.resources
| project machine,
 rule = report_resources.resourceId,
 ruleComplianceStatus = report_resources.complianceStatus,
 ruleComplianceReason = report_resources.reasons[0].phrase,
 lastComplianceStatusChecked
'@

Search-AzGraph $settingPerRowQuery

<#
Sample output:

machine     rule                                                  ruleComplianceStatus     ruleComplianceReason
-------     ---------------                                                  ------               ------
sshdemovm01 Ensure permissions on /etc/ssh/sshd_config are configured        true            Access to '/etc/ssh/sshd_config' matches required ...
sshdemovm01 Ensure SSH is configured to meet best practices (protocol 2)     true            'Protocol 2' is found uncommented in /etc/ssh/sshd_config
sshdemovm01 Ensure SSH is configured to ignore rhosts                        true            The sshd service reports that 'ignorerhosts' is set to 'yes'
sshdemovm01 Ensure SSH LogLevel is set to INFO                               true            The sshd service reports that 'loglevel' is set to 'INFO'
sshdemovm01 Ensure SSH MaxAuthTries is configured                            true            The sshd service reports that 'maxauthtries' is set to '6'
sshdemovm01 Ensure allowed users for SSH access are configured               true            The sshd service reports that 'allowusers' is set to '*@*'
sshdemovm01 Ensure denied users for SSH are configured                       true            The sshd service reports that 'denyusers' is set to 'root'
sshdemovm01 Ensure allowed groups for SSH are configured                     true            The sshd service reports that 'allowgroups' is set to '*'
sshdemovm01 Ensure denied groups for SSH are configured                      true            The sshd service reports that 'denygroups' is set to 'root'
sshdemovm01 Ensure SSH host-based authenticationis disabled                  true            The sshd service reports that 'hostbasedauthentication' is ...
#>

Dlaczego terminy "Konfiguracja gościa" i "Automanage" są widoczne w miejscach?

Usługa konfiguracji maszyny jest również znana jako konfiguracja gościa i jako Automanage Machine Configuration. Te nazwy mogą wystąpić podczas interakcji z usługami i dokumentacją. Na przykład:

W przykładach zapytań usługi Azure Resource Graph w tym artykule tabela danych nosi nazwę guestconfigurationresources.
W witrynie Azure Portal przydatny widok do obserwowania wyników nosi nazwę "Przypisania gościa".
W witrynie Azure Portal podczas stosowania odpowiedniego rozszerzenia maszyny wirtualnej w celu włączenia konfiguracji maszyny tytuł rozszerzenia to "Automanage Machine Configuration".

Na potrzeby kontroli stanu SSH nie ma znaczącego rozróżnienia między "gościem" i "maszyną". Maszyny z obsługą usługi Arc i maszyny wirtualne platformy Azure kwalifikują się.

Jakie są identyfikatory wbudowanych definicji zasad?

W niektórych przypadkach, takich jak tworzenie przypisań zasad za pomocą interfejsu wiersza polecenia platformy Azure, może być przydatne lub konieczne odwołanie się do definicji zasad według identyfikatora, a nie nazwy wyświetlanej.

displayName	id
Inspekcja kontroli stanu protokołu SSH na maszynach z systemem Linux	`/providers/Microsoft.Authorization/policyDefinitions/a8f3e6a6-dcd2-434c-b0f7-6f309ce913b4`
Konfigurowanie kontroli stanu protokołu SSH na maszynach z systemem Linux	`/providers/Microsoft.Authorization/policyDefinitions/e22a2f03-0534-4d10-8ea0-aa25a6113233`

Aby uzyskać pomoc techniczną dotyczącą problemów itp., skontaktuj się z pomocą techniczną firmy Microsoft
Aby przekazać opinię, omówić żądania funkcji itp.: linux_sec_config_mgmt@service.microsoft.com

Last updated on 2024-10-30

Udostępnij przez