Jak wyłączyć przekierowanie lokalnego portu SSH?


20

Mam serwer z systemem Ubuntu i demonem OpenSSH. Nazwijmy to S1.

Używam tego serwera z maszyn klienckich (nazwijmy jeden z nich C1), aby wykonać tunel zwrotny SSH za pomocą zdalnego przekierowania portów, np .:

ssh -R 1234:localhost:23 login@S1

Na S1 używam domyślnego pliku sshd_config. Z tego, co widzę, każdy posiadający odpowiednie poświadczenia {login, pwd} na S1 może zalogować się do S1 i albo wykonać zdalne przekierowanie portów i przekierowanie portów lokalnych. Takie poświadczenia mogą w przyszłości stanowić certyfikat, więc według mnie każdy, kto pobierze certyfikat, może zalogować się do S1 z dowolnego miejsca (niekoniecznie C1), a tym samym utworzyć przekierowanie portów lokalnych.

Dla mnie zezwolenie na przekierowanie portów lokalnych jest zbyt niebezpieczne, ponieważ pozwala stworzyć pewnego rodzaju publiczny serwer proxy. Szukam sposobu, aby wyłączyć tylko przekazywanie -L.

Próbowałem następujących czynności, ale powoduje to wyłączenie przekazywania lokalnego i zdalnego:

AllowTcpForwarding No

Próbowałem także następujących, pozwoli to tylko -L na SX: 1. To lepsze niż nic, ale wciąż nie to, czego potrzebuję, co jest opcją „brak”.

PermitOpen SX:1

Zastanawiam się więc, czy jest jakiś sposób, abym mógł zabronić wszystkim lokalnym portom przekazywania dalej pisania czegoś takiego:

PermitOpen none:none

Czy poniższe są dobrym pomysłem?

PermitOpen localhost:1

więc, jak zawsze, przejdźmy do sedna tego: jaki jest twój prawdziwy problem, dlaczego chcesz skonfigurować coś takiego dla urządzeń mobilnych / wbudowanych, co chcesz rozwiązać?
akira

Problemem do rozwiązania w tym przypadku jest możliwość otwarcia sesji Telnet w dowolnym miejscu z Internetu na urządzeniu mobilnym / wbudowanym podłączonym do Internetu, biorąc pod uwagę, że urządzenie może być NATowane lub zapory ogniowej, a zatem nieosiągalne z Internetu.
SCO,

telnet .. po co? za wybijanie dziur w zaporze sieciowej Google dla „ogłuszenia”
akira

Odpowiedzi:


16

każdy z poświadczeniami logowania może wywołać własną instancję sshd, działającą na losowym porcie i zezwalać na wszystko, co chce, w tym na -L przekazywanie lokalne:

% /usr/sbin/sshd -d -f mysshd.config -p 12345

jeśli nie ufasz użytkownikom, że coś zrobią z twoim komputerem, nie powinieneś pozwolić im na logowanie się w pierwszej kolejności.

(przy okazji flaga -D jest również trochę „problematyczna z serwerem proxy”)


Cóż, myślę, że mogę skonfigurować bardzo restrykcyjne konto w tym celu (np. Przykleić użytkownika do jego strony głównej, bez wpisu, bez przeglądania systemu plików), aby nie mógł się uruchomić i sshd (lub zainstalować i uruchomić plik binarny sshd). Chodzi o to, że klienci mają być urządzeniami osadzonymi. Ale ponieważ prawdopodobnie będą osadzać certyfikaty, a ich pamięć flash można zrzucić, możliwe jest, że certyfikaty wyciekną, co pozwoli każdemu zalogować się do S1.
SCO,

Użycie ChrootDirectory dla tego konkretnego użytkownika załatwi sprawę, spróbuje tego!
SCO,

1
W uprawnione klucze, ustaw command="/sbin/nologin". Powinno to uniemożliwić im uruchamianie jakichkolwiek poleceń na serwerze.
justis

Stwierdzenie „każdy, kto ma dane logowania, może wywołać własne <kolwiek cokolwiek>” jest fałszywe. sshmoże być używany do łączenia się z kontami, które poważnie ograniczają powłoki logowania, które na to nie pozwalają. Przekierowywanie portów jest luką bezpieczeństwa w takich ograniczonych powłokach. Oprócz uruchomienia dozwolonego polecenia użytkownik może tworzyć tunele.
Kaz.

3
Cytat ze sshd_configstrony podręcznika : Pamiętaj, że wyłączenie przekazywania TCP nie poprawia bezpieczeństwa, chyba że użytkownikom odmówiono również dostępu do powłoki , ponieważ zawsze mogą oni zainstalować własne programy do przesyłania dalej. (Podkreśl moje).
Kaz.

17

Innym rozwiązaniem byłoby zezwolenie na przekierowywanie portów tylko dla określonych użytkowników:

Od SSH: ostateczny przewodnik

Przekierowanie portów może być globalnie włączone lub wyłączone w sshd. Odbywa się to za pomocą słowa kluczowego konfiguracji AllowTcp Forwarding w / etc / sshd_config. Słowo kluczowe może mieć wartość tak (domyślnie, włączenie przekazywania) lub nie (wyłączenie przekazywania):

# SSH1, SSH2, OpenSSH
AllowTcpForwarding no

Ponadto SSH2 ma następujące opcje:

# SSH2 only
AllowTcpForwardingForUsers
AllowTcpForwardingForGroups

Ich składnia jest taka sama, jak w przypadku opcji AllowUsers i AllowGroups. [Sekcja 5.5.2.1, „Kontrola dostępu do konta”] Określają listę użytkowników lub grup, którzy mogą korzystać z przekierowania portów; serwer odmawia uznania żądań przekierowania portów dla kogokolwiek innego. Pamiętaj, że odnoszą się one do konta docelowego sesji SSH, a nie do nazwy użytkownika klienta (która często nie jest znana).

...

Ważne jest, aby zdawać sobie sprawę, że dyrektywy w tej sekcji nie zapobiegają przekierowaniu portów, chyba że wyłączysz także interaktywne logowanie i ograniczysz programy, które mogą być uruchamiane po stronie zdalnej. W przeciwnym razie doświadczeni użytkownicy mogą po prostu uruchomić własną aplikację przekierowującą porty w sesji SSH. Same te ustawienia mogą być wystarczającym środkiem odstraszającym w nietechnicznej społeczności, ale nie powstrzymają kogoś, kto wie, co ona robi.


1
Zasadniczo mam tylko jednego użytkownika przydzielonego do S1. AFAIU, w tym konkretnym przypadku, użycie AllowTcpForwardingForUsers / AllowTcpForwardingForGroups nie załatwi sprawy, prawda? Zakaz interaktywnego logowania jest dobrym pomysłem, ponieważ uniemożliwi użytkownikom uruchamianie plików binarnych. Ale każdy klient będzie nadal mógł korzystać ze składni -L, prawda? Na razie najlepsze opcje to: 1 / Wyłącz interaktywne logowanie, 2 / PermitOpen z fałszywą nazwą hosta: port. Przegapiłem coś ?
SCO

Najlepszym sposobem na sprawdzenie tego byłoby wypróbowanie konfiguracji.
Christian

Nie widzę tych opcji w bezpłatnym oprogramowaniu OpenSSH. Google dla AllowTcpForwardingForUsersujawnia, że ​​jest skonfigurowany w sshd2_config, który jest używany w niektórych programach komercyjnych. Zobacz jedną z odpowiedzi na: superuser.com/questions/384643/…
Kaz.

^ OpenSSH ma Matchbloki w konfiguracji. Możesz Matchna użytkownikach i grupach i dołączyć AllowTcpForwardingwewnątrz.
Kaz.

2

Istnieje teraz opcja zezwalania tylko na lokalne / zdalne przekazywanie.

AllowTcpForwarding Określa, czy dozwolone jest przekazywanie TCP. Dostępne opcje to „tak” lub „wszystkie”, aby zezwolić na przekazywanie TCP, „nie”, aby uniemożliwić wszystkie przekazywanie TCP, „lokalne”, aby zezwolić tylko na lokalne (z perspektywy ssh (1)) lub „zdalne”, aby umożliwić zdalne tylko przekazywanie . Domyślna wartość to „tak”. Należy pamiętać, że wyłączenie przekazywania TCP nie poprawia bezpieczeństwa, chyba że użytkownikom odmówiono również dostępu do powłoki, ponieważ zawsze mogą oni zainstalować własne usługi przesyłania dalej.

Jak już powiedziano, powinieneś również ustawić powłokę na nologin.


0

Moim rozwiązaniem tego problemu było dodanie: PermitOpen fo.local: 80 w głównej sekcji sshd_config.

To po prostu odrzuca wszelkie żądania lokalnego przekazywania poza fo.local: 80.


0

Szukam sposobu, aby wyłączyć tylko przekazywanie -L

Jeśli dobrze cię rozumiem, twoi użytkownicy mają pełny dostęp do powłoki, ale nie chcesz, aby mogli otwierać połączenia z resztą sieci.

„Przekazywanie portów lokalnych” dozwolone przez SSH jest tylko jednym z możliwych sposobów, aby to zrobić. Inne obejmują uruchomienie instancji socat, netcatlub jakąkolwiek inną liczbę narzędzi.

Najlepszym sposobem kontrolowania połączeń wychodzących i przychodzących w systemie Linux jest Netfilter, czyli IPTables.

Ma specjalny moduł o nazwie owner ( ipt_owner), który pozwala dopasować różne cechy kreatora pakietów dla pakietów generowanych lokalnie. Jest ważny w łańcuchach OUTPUTi POSTROUTING.

Możesz go użyć do odrzucenia pakietów wychodzących generowanych przez określone grupy użytkowników, tym samym uniemożliwiając jakiekolwiek przekierowanie portów, nie tylko -Lopcję SSH.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.