Czy można zapobiec SCP, jednocześnie umożliwiając dostęp do SSH?

13

Używając serwerów Solaris i Linux oraz OpenSSH, czy można uniemożliwić użytkownikom kopiowanie plików przy użyciu „scp”, jednocześnie umożliwiając dostęp do powłoki za pomocą „ssh”?

Zdaję sobie sprawę z tego, że dostępom do plików typu „ssh $ server” cat file ”jest znacznie trudniej zapobiec, ale muszę wiedzieć o zatrzymywaniu„ scp ”na początek.

W przeciwnym razie, czy istnieje sposób, aby niezawodnie rejestrować cały dostęp SCP po stronie serwera syslog?

Peter Mortensen
źródło
Jeśli chcesz zamknąć ssh, ale nie scp, możesz użyć tego: sublimation.org/scponly/wiki/index.php/Main_Page Szkoda, że ​​chcesz to odwrotnie: - \
Mam to samo pytanie, ale z innego powodu. W moim przypadku lubię wyłączać SFTPD i SCPD na serwerze. Powodem jest to, że zezwalamy na przesyłanie plików, ale lubimy, aby użytkownicy wykonywali je za pośrednictwem naszego węzła kopiowania. Wynika to z tego, jak oddzielamy obciążenie naszych linków. Więc zgodnie z tą pętlą łatwo jest wyłączyć SFTPD, ale jeśli dobrze rozumiem, wyłączenie SCPD jest prawie niemożliwe.

Odpowiedzi:

12

Możesz edytować swój /etc/ssh/sshd_configwygląd, który wygląda mniej więcej tak:

ForceCommand           /bin/sh
PermitOpen             0.0.0.0
AllowTcpForwarding     no
PermitTunnel           no
# Subsystem sftp       /usr/lib/openssh/sftp-server
PermitUserEnvironment  no

Zamiast tego ustalę, do czego użytkownik może go użyć. Ponieważ jeśli jest tylko kilka poleceń, do których chcesz, aby mieli dostęp, zamiast tego usunęłbym możliwość nawet wywołania normalnej sshpowłoki.

AllowUsers             root
PermitRootLogin        forced-commands-only

PermitUserEnvironment  no

AllowTcpForwarding     no
PermitTunnel           no

# Subsystem sftp       /usr/lib/openssh/sftp-server
Subsystem smb-reload   /usr/bin/smbcontrol smbd reload-config
Subsystem status       /opt/local/bin/status.sh

ssh root@example -s smb-reload

Jeśli okaże się, że naprawdę musisz być w stanie uruchomić normalną powłokę, najbardziej, na co naprawdę możesz liczyć, to spowolnienie ich i utrudnienie.

Brad Gilbert
źródło
8

Jak zauważyli inni, nie możesz zablokować scp (cóż, możesz: rm /usr/bin/scpale tak naprawdę nigdzie cię to nie prowadzi).

Najlepsze, co możesz zrobić, to zmienić powłokę użytkownika na ograniczoną (rbash), a dopiero potem uruchomić określone polecenia.

Pamiętaj, że jeśli potrafią czytać pliki, mogą je kopiować / wklejać poza ekran. Pliki binarne? xxd / uuencode / mmencode wszystko to obejdzie.

Sugeruję również stosowanie księgowania procesów, aby pomóc Ci śledzić aktywność.

MikeyB
źródło
Rachunkowość procesów trochę pomaga, ale historyczna ewidencja procesów była naprawdę bezużyteczna (np. Rejestrowanie tylko nazwy bazowej uruchomienia polecenia). Chciałbym usłyszeć o wszelkich współczesnych sukcesach w zakresie księgowości procesów, która jest rzeczywiście przydatna.
carlito
1
Co powiesz na użycie załatanej ograniczonej powłoki, która rejestruje również wszystkie polecenia uruchamiane gdzieś w potoku? Scentralizowany pomysł .bash_history.
MikeyB
Właściwie po stronie serwera musiałbyś usunąć / usr / lib / openssh / sftp-server, ale myślę, że sshd ma wbudowany serwer sftp.
Brad Gilbert
@Brad: Wszelkie polecenia określone przez klienta są nadal uruchamiane przez powłokę; więc jeśli serwer sftp nie znajduje się w domyślnej ŚCIEŻCE (której nie ma), zmiana powłoki na ograniczoną wystarczy, aby ją wyłączyć, nie musisz usuwać pliku binarnego.
MikeyB,
6

Nic nie zyskujesz, zatrzymując „scp”, kiedy wciąż zezwalasz na dosłownie nieskończone dodatkowe mechanizmy przesyłania plików. Wyłączenie scp, ale zezwolenie na inne mechanizmy kopiowania plików jest metodą okłamywania audytorów. Często audytorzy proszą o okłamanie. Zwykle widzę audytorów współpracujących z menedżerami w celu wprowadzenia fałszywych poprawek, aby mogli powiedzieć coś takiego: „Polecenie transferu plików scp zostało wyłączone, aby nie można było kopiować plików z serwera za pomocą scp”.

Teraz rozsądny byłby rozsądny mechanizm rejestrowania. Może w końcu auditd działa w systemie Linux. Być może Solaris w końcu dodał jakiś mechanizm lub dtrace może być bezpiecznie używany. Rozsądne jest, aby system operacyjny logował się przy każdym dostępie do pliku. Oczywiście nie ma różnicy między „czytaniem” a „kopiowaniem”. Ale to może zadowolić audytora i zapewnić znaczące bezpieczeństwo systemu. Twoje dzienniki mogą być tak głośne, że dane są bezużyteczne, a nawet że jesteś zmuszony do utrzymywania absurdalnie krótkiej ścieżki audytu. (np. nie można zarejestrować każdego odczytu () - a jedna aplikacja, która robi coś zaskakującego, może spowodować, że rejestrowanie każdej operacji open () będzie katastrofą).

Carlito
źródło
5

W zależności od tego, do czego potrzebny jest SSH, możesz być w stanie osiągnąć ten cel (w przypadku nietrywialnych) plików, używając IPTables do zakończenia sesji, jeśli rozmiar pakietu jest większy niż, powiedzmy 1400 bajtów. Oznacza to, że interaktywny ssh będzie w większości działał, ale jak tylko coś spróbuje wysłać pakiet 1500 bajtów - podobnie jak scp powinien dla pliku większego niż 1499 bajtów przy założeniu standardowej MTU 1500, przerwie połączenie.

Zapobiegnie to także wspomnianemu atakowi „catting”.

Niestety oznacza to, że możesz mieć problemy z edycją niektórych plików za pomocą edytora tekstu, jeśli ekran musi narysować więcej niż 1400 znaków, lub jeśli chcesz zakotwiczyć długi plik lub zrobić długą listę katalogów.

W najprostszym przypadku polecenie to może wyglądać podobnie

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP

Możemy usprawnić to działanie, łącząc sprawdzanie długości pakietów z ipt_recent, aby umożliwić ograniczoną liczbę pakietów większych niż 1400 bajtów w ustalonym czasie (powiedzmy 8 pakietów na 5 sekund) - to pozwoliłoby na przeskakiwanie pakietów do 12k przez, ale może zapewnić interaktywność potrzebną do edycji plików itp. Możesz oczywiście dostosować liczbę pakietów.

To może wyglądać mniej więcej tak

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --set 
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --update --seconds 5 --hitcount 8 \
         -j REJECT --reject-with tcp-reset

Powyższe przykłady reguł chronią tylko przed przesłaniem scp, takim jak scp myfile.data remote.host:~. Aby dodatkowo zabezpieczyć się przed pobraniem SCP, np. scp remote.host:~/myfile.data /local/pathPowtórz powyższe zasady, ale zastąp --dportje --sport.

Klarowny haker może obejść te ograniczenia, ustawiając na swoim komputerze MTU na poziomie mniejszym niż 1400 (lub wymusza mtu lub podobny). Ponadto, chociaż nie możesz tego ograniczyć do niektórych użytkowników, możesz ograniczyć to przez IP, odpowiednio modyfikując linie iptables !!

Pozdrawiam, David Go

David Go
źródło
2

Najlepszym rozwiązaniem nie jest zablokowanie scp, ale użycie systemu plików z listami ACL, aby uniemożliwić dostęp do odczytu. Prawdopodobnie możesz zrobić coś z SELinux, aby uniemożliwić niektórym aplikacjom odczytanie niektórych plików.

supercheetah
źródło
Lub możesz zrobić jedno i drugie.
msanford
1

Ilość scpi sshdziałają na te same porty i użyć tego samego protokołu. Jeśli otworzysz sshsesję, możesz nawet udostępnić swoje połączenie kolejnym połączeniom SCP, używając opcji takich jak ControlMaster.

Jeśli nie chcesz, aby ludzie kopiowali określone pliki z komputera, nie powinieneś dawać im dostępu do powłoki.

Todd Gamblin
źródło
Tak, oczywistą odpowiedzią byłoby zablokowanie systemu i nie udzielanie dostępu. W rzeczywistości jednak moja firma ma audytorów, którzy twierdzą, że musimy zapobiegać kopiowaniu plików z serwerów i / lub prób logowania, mimo że poważnie ograniczamy dostęp do ssh i mamy solidny system RBAC.
2
@Jason: Następnie musisz zalogować dostęp do pliku. Nawet jeśli wyłączyłeś scp, jak powstrzymasz kogoś przed uruchomieniem: ssh server 'cat / path / to / file'> copy?
derobert
0

Istnieje sposób użycia „scponly” jako powłoki do wyłączenia interaktywnego ssh i umożliwienia scp, ale nie jestem świadomy niczego, co działałoby w odwrotny sposób.

Być może będziesz w stanie zbadać hakowanie skorupiaków w celu osiągnięcia odwrotności.

Jehiah
źródło
0

W rzeczywistości nie jest to możliwe po małym googlowaniu.

Sprawdź tę dyskusję: http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

samoz
źródło
Ten link jest martwy.
rox0r
0

Co do wartości, komercyjny produkt CryptoAuditor twierdzi, że jest w stanie kontrolować przesyłanie plików przez SSH, MITM poprzez połączenie i kontrolę głębokiego pakietu . Oczywiście żadne rozwiązanie nie jest bezpieczne przed kopiowaniem + wklejaniem, kodowaniem / dekodowaniem, FISH itp. Zaletą jest to, że jest przezroczyste (oprócz prawdopodobnych błędów certyfikatów); nie ma żadnego oprogramowania agenta do zainstalowania na żadnym końcu połączenia SSH ani portalu / proxy do skonfigurowania.

Nie korzystałem z produktu, więc YMMV.

Robert Fleming
źródło
0

Zablokowanie przesyłania plików bez usuwania tak wielu narzędzi systemowych, że pozostawienie maszyny całkowicie bezużytecznej jest niemożliwe. Musiałbyś pozbyć się wszystkiego, co może wyświetlać zawartość pliku na standardowe wyjście, i wszystkiego, co potrafi zapisać standardowe wejście na standardowe wyjście, a do czasu usunięcia wszystkich tych elementów jest już tak mało, że nie ma sensu zezwalać na dostęp do powłoki w ogóle.

Dlatego skupię się na alternatywnej opcji logowania:

Istnieje program o nazwie „skrypt”, który jest zawarty w praktycznie każdej dystrybucji i który powinien być łatwy do zainstalowania na tych, na których nie ma. Jest to rejestrator sesji, który rejestruje wszystkie dane wejściowe i wyjściowe z powłoki, opcjonalnie z danymi taktowania, dzięki czemu można je odtworzyć i wyglądać tak, jakbyś obserwował użytkownika przez ramię, gdy to robił. (W każdym razie 95%, czasami podskakuje na wyjściu, gdy ncurses jest zaangażowany, ale niezbyt często).

Strona podręcznika zawiera instrukcje konfigurowania go jako powłoki logowania do systemu. Upewnij się, że dzienniki idą gdzieś, że użytkownik nie może ich po prostu usunąć (przydatny jest do tego atrybut systemu plików tylko do dołączania (ustawiany przez chattr). Podobnie jak listy ACL lub skrypty inotify)

Nadal nie uniemożliwia to użytkownikom kopiowania plików z systemu, ale umożliwia sprawdzenie, co zrobili użytkownicy i kiedy. Prawdopodobnie ominięcie nie jest niemożliwe, ale ominięcie prawie na pewno trafiłoby do dzienników, abyś przynajmniej wiedział, że ktoś nie ma nic dobrego, nawet jeśli uda mu się ukryć dokładnie to, co to było.

Perkins
źródło
0

Wierzę, że możesz odinstalować klientów openssh (lub ich odpowiedników) na serwerze.

Myślę, że klient scp wywołuje scp na serwerze podczas kopiowania danych, więc jeśli pozbędziesz się scp na serwerze, powinieneś być w porządku.

$ scp bla server:/tmp/
...
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.utf8
debug1: Sending env LANG = en_US.utf8
debug1: Sending env XMODIFIERS = @im=ibus
debug1: Sending env LANGUAGE = en_US.utf8
debug1: Sending command: scp -v -t /tmp/
bash: scp: command not found
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
lost connection
Tomas
źródło