¿Es posible evitar SCP mientras se permite el acceso SSH?

Usando los servidores Solaris y Linux y OpenSSH, ¿es posible evitar que los usuarios copien archivos usando "scp" y al mismo tiempo permitir el acceso de shell con "ssh"?

Me doy cuenta de que los accesos a archivos del tipo 'ssh $ server "cat file" son mucho más difíciles de evitar, pero necesito ver cómo detener "scp" para empezar.

De lo contrario, ¿hay alguna manera de registrar de manera confiable todo el acceso SCP en el lado del servidor syslog?

Si bien puedes editar tu /etc/ssh/sshd_configpara que se vea así:

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

En cambio, determinaría para qué es probable que el usuario lo use. Porque si solo hay unos pocos comandos a los que desea que tengan acceso, en su lugar, eliminaría la posibilidad de que incluso invoquen un sshshell normal .

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

Si encuentra que realmente necesita poder ejecutar un shell normal, lo máximo que realmente puede esperar es reducir la velocidad y hacer que sea más difícil.

Como otros han notado, no puedes bloquear scp (bueno, podrías: rm /usr/bin/scppero eso realmente no te lleva a ninguna parte).

Lo mejor que puede hacer es cambiar el shell de los usuarios a un shell restringido (rbash) y solo entonces ejecutar ciertos comandos.

Recuerde, si pueden leer archivos, pueden copiarlos / pegarlos de la pantalla. Archivos binarios? xxd / uuencode / mmencode todos evitan esto.

También sugiero usar la contabilidad de procesos para ayudarlo a rastrear la actividad.

No gana nada al detener "scp" cuando todavía permite literalmente infinitos mecanismos adicionales de transferencia de archivos. No permitir scp pero permitir otros mecanismos de copia de archivos es un método de mentir a los auditores. A menudo, los auditores piden que se les mienta. Por lo general, veo auditores que trabajan con los gerentes para hacer correcciones falsas, para que puedan decir algo como "el comando de transferencia de archivos scp se ha deshabilitado, de modo que los archivos no se pueden copiar desde el servidor usando scp".

Ahora un mecanismo de registro razonable sería bueno. Tal vez auditado finalmente funciona en Linux. Quizás Solaris finalmente agregó algún mecanismo o dtrace podría usarse de manera segura. Es razonable querer que el sistema operativo inicie sesión cada vez que se accede a un archivo. Por supuesto, no hay diferencia entre "leer" y "copiar". Pero esto puede satisfacer a un auditor y proporcionar una seguridad significativa al sistema. Sus registros pueden ser tan ruidosos que los datos son inútiles, o incluso que se ve obligado a mantener un seguimiento de auditoría ridículamente corto. (por ejemplo, no puede registrar cada lectura (), y una aplicación que hace algo sorprendente puede hacer que el registro de cada abierto () sea un desastre).

Dependiendo de para qué se necesite SSH, es posible que pueda lograr este objetivo (para archivos no triviales) utilizando IPTables para terminar las sesiones si el tamaño del paquete es mayor, digamos 1400 bytes. Esto significa que el ssh interactivo funcionará principalmente, pero tan pronto como algo intente enviar un paquete de 1500 bytes, como scp debería para un archivo de más de 1499 bytes asumiendo una MTU estándar de 1500, terminará la conexión.

Esto también evitará el ataque de "captura" que usted menciona.

Desafortunadamente, esto significa que puede tener problemas para editar algunos archivos con un editor de texto, si la pantalla necesita dibujar más de 1400 caracteres, o si necesita capturar un archivo largo o hacer una lista larga del directorio.

En el caso más simple, un comando para hacer esto podría ser algo así como

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

Podemos hacer que esto funcione mejor combinando las comprobaciones de longitud de paquetes con ipt_recent, de modo que permita un número limitado de paquetes de más de 1400 bytes dentro de un marco de tiempo establecido (digamos 8 paquetes por 5 segundos); esto permitiría que se escapen paquetes de hasta 12k , pero puede darle la interactividad que necesitará para editar archivos, etc. Puede, por supuesto, modificar la cantidad de paquetes.

Esto podría parecerse a algo como

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

Los ejemplos de reglas anteriores solo protegen contra cargas scp como scp myfile.data remote.host:~. Para protegerse adicionalmente contra descargas scp como scp remote.host:~/myfile.data /local/path, repita las reglas anteriores pero reemplace --dportcon --sport.

Un pirata informático puede solucionar estas limitaciones estableciendo una MTU de menos de 1400 en su máquina (o forzar mtu o similar). Además, aunque no puede limitar esto a ciertos usuarios, puede limitarlo por IP modificando las líneas de iptables según corresponda.

Saludos, David Go

Su mejor opción no es bloquear scp, sino usar un sistema de archivos con ACL para evitar el acceso de lectura. Probablemente podría hacer algo con SELinux para evitar que ciertas aplicaciones lean ciertos archivos.

No. scpy sshoperar en los mismos puertos y usar el mismo protocolo. Si abre una sshsesión, incluso puede compartir su conexión con llamadas scp posteriores utilizando opciones como ControlMaster.

Si no desea que las personas copien archivos particulares de una máquina, no debe darles ningún tipo de acceso de shell a la máquina.

Hay una forma de usar 'scponly' como shell para deshabilitar ssh interactivo y permitir scp, pero no conozco nada existente que funcione de manera inversa.

Es posible que pueda explorar hackear el shell scponly para lograr lo contrario.

Esto no es posible en realidad después de un pequeño googlear.

Echa un vistazo a esta discusión: http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Para lo que vale, el producto comercial CryptoAuditor afirma ser capaz de controlar las transferencias de archivos a través de SSH, mediante la conexión MITM y el uso de la inspección profunda de paquetes . Obviamente, ninguna solución está a salvo de copiar + pegar, codificar / decodificar, FISH , etc. Lo bueno es que es transparente (aparte de los probables errores de certificado); no hay software de agente para instalar en ninguno de los extremos de la conexión SSH y no hay que configurar un portal / proxy.

No he usado el producto, así que YMMV.

Bloquear la transferencia de archivos sin eliminar tantas utilidades del sistema como para dejar la máquina completamente inútil es imposible. Tendría que deshacerse de todo lo que sea capaz de mostrar el contenido del archivo en stdout, y todo lo que sea capaz de escribir su stdin en stdout, y para cuando haya eliminado todos esos elementos, queda tan poco que no tiene sentido permitir el acceso al shell en absoluto.

Por lo tanto, me centraré en su alternativa de registro:

Hay un programa llamado "script" que se incluye en prácticamente todas las distribuciones, y que debería ser fácil de instalar en aquellos donde no lo está. Es un registrador de sesión que registra todas las entradas y salidas de un shell, opcionalmente con datos de temporización para que pueda reproducirse y verse como si estuviera mirando por encima del hombro del usuario cuando lo hizo. (De todos modos, el 95%, ocasionalmente bota la salida cuando está involucrado ncurses, pero no muy a menudo).

Su página de manual incluye instrucciones para configurarlo como el shell de inicio de sesión del sistema. Asegúrese de que los registros lleguen a un lugar donde el usuario no pueda simplemente eliminarlos (el atributo del sistema de archivos de solo agregar (configurable a través de chattr) puede ser útil para esto. Al igual que las ACL o las secuencias de comandos de inotify)

Esto aún no impide que los usuarios copien archivos del sistema, pero le permite revisar qué hicieron los usuarios y cuándo. Probablemente no sea imposible omitirlo, pero el desvío casi seguramente terminaría en los registros, por lo que al menos sabría que alguien no era bueno, incluso si logran ocultar exactamente lo que era.

Creo que puede desinstalar openssh-clients (o equivalente) en el servidor.

Creo que el cliente scp invoca scp en el servidor cuando copia datos, así que si se deshace de scp en el servidor, entonces debería estar bien.

$ 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