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

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?

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.

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ść.

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ą).

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

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.

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.

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.

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

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.

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.

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 eow@openssh.com reply 0
lost connection