É possível impedir o SCP enquanto ainda permite o acesso SSH?

Usando servidores Solaris e Linux e OpenSSH, é possível impedir que os usuários copiem arquivos usando "scp" enquanto ainda permitem acesso ao shell com "ssh"?

Percebo que os acessos a arquivos do tipo "arquivo de gato" ssh $ server são muito mais difíceis de evitar, mas preciso ver como parar o "scp" para iniciantes.

Na falta disso, existe uma maneira de registrar de maneira confiável todo o acesso SCP no lado do servidor syslog?

Enquanto você pode editar o seu /etc/ssh/sshd_configpara algo parecido com isto:

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

Em vez disso, eu determinaria para que o usuário provavelmente o utilizaria. Porque, se houver apenas alguns comandos aos quais você deseja que eles tenham acesso, eu removeria a capacidade de invocar um 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

Se você achar que realmente precisa ser capaz de executar um shell normal, o máximo que realmente pode esperar é desacelerá-lo e torná-lo mais difícil.

Como outros observaram, você não pode bloquear o scp (bem, você poderia:, rm /usr/bin/scpmas isso realmente não o leva a lugar nenhum).

O melhor que você pode fazer é alterar o shell dos usuários para um shell restrito (rbash) e somente então executar determinados comandos.

Lembre-se, se eles podem ler arquivos, eles podem copiá-los / colá-los na tela. Arquivos binários? xxd / uuencode / mmencode todos contornam isso.

Eu também sugeriria o uso da contabilidade de processo para ajudar a rastrear a atividade.

Você não ganha nada parando o "scp" quando ainda permite literalmente infinitos mecanismos adicionais de transferência de arquivos. Desabilitar o scp, mas permitir outros mecanismos de cópia de arquivos, é um método de mentir para os auditores. Muitas vezes, os auditores pedem mentiras. Normalmente, vejo auditores trabalhando com gerentes para fazer correções falsas, para que possam declarar algo como "o comando scp file transfer foi desativado, para que os arquivos não possam ser copiados do servidor usando scp".

Agora, um mecanismo de registro razoável seria bom. Talvez o auditd finalmente funcione no Linux. Talvez o Solaris finalmente tenha adicionado algum mecanismo ou o dtrace possa ser usado com segurança. É razoável querer que o sistema operacional faça logon sempre que um arquivo for acessado. Claro que não há diferença entre "ler" e "copiar". Mas isso pode satisfazer um auditor e dar segurança significativa ao sistema. Seus logs podem ser tão barulhentos que os dados são inúteis, ou mesmo que você é forçado a manter uma trilha de auditoria ridiculamente curta. (por exemplo, você não pode registrar todas as leituras () - e um aplicativo que faz algo surpreendente pode tornar o registro a cada abertura () um desastre).

Dependendo do que o SSH é necessário, talvez você consiga atingir esse objetivo (para arquivos não triviais) usando o IPTables para encerrar as sessões se o tamanho do pacote for maior, digamos 1400 bytes. Isso significa que o ssh interativo funcionará principalmente, mas assim que algo tentar enviar um scp semelhante a um pacote de 1500 bytes para um arquivo maior que 1499 bytes, assumindo um MTU padrão de 1500, ele encerrará a conexão.

Isso também impedirá o ataque "catting" que você mencionou.

Infelizmente, isso significa que você pode ter problemas para editar alguns arquivos com um editor de texto, se a tela precisar desenhar mais de 1400 caracteres, ou se você precisar criar um arquivo longo ou fazer uma lista longa de diretórios.

No caso mais simples, um comando para fazer isso pode parecer algo como

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

Podemos melhorar esse trabalho combinando as verificações de tamanho de pacote com ipt_recent, para que você permita um número limitado de pacotes maiores que 1400 bytes em um período de tempo definido (digamos 8 pacotes por 5 segundos) - isso permitiria que pacotes de até 12k passassem , mas pode fornecer a interatividade necessária para editar arquivos etc. Você pode, é claro, ajustar o número de pacotes.

Isso pode parecer 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

Os exemplos de regras acima protegem apenas contra uploads de scp como scp myfile.data remote.host:~. Para proteger adicionalmente contra downloads scp, como scp remote.host:~/myfile.data /local/path, repita as regras acima, mas substitua --dportpor --sport.

Um hacker capaz de contornar essas limitações definindo um MTU inferior a 1400 em sua máquina (ou forçando mtu ou similar). Além disso, embora você não possa limitar isso a determinados usuários, você pode limitar por IP modificando as linhas do iptables conforme apropriado !!

Cheers, David Go

Sua melhor aposta não é bloquear o scp, mas usar um sistema de arquivos com ACLs para impedir o acesso de leitura. Você provavelmente poderia fazer algo com o SELinux para impedir que certos aplicativos leiam certos arquivos.

No. scpe sshoperam sobre as mesmas portas e usar o mesmo protocolo. Se você abrir uma sshsessão, poderá compartilhar sua conexão com chamadas scp subsequentes usando opções como ControlMaster.

Se você não deseja que as pessoas copiem arquivos específicos de uma máquina, não deve dar a eles nenhum tipo de acesso shell à máquina.

Existe uma maneira de usar 'scponly' como o shell para desativar o ssh interativo e permitir o scp, mas não estou ciente de nada existente que funcione da maneira inversa.

Você pode explorar a invasão do shell scponly para realizar o inverso.

Na verdade, isso não é possível depois de um pouco de pesquisa.

Confira esta discussão: http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Pelo que vale a pena, o produto comercial CryptoAuditor afirma ser capaz de controlar as transferências de arquivos por SSH, MITM na conexão e usando inspeção profunda de pacotes . Obviamente, nenhuma solução é segura contra copiar + colar, codificar / decodificar, FISH , etc. O bom é que é transparente (além dos prováveis ​​erros de certificado); não há nenhum software de agente para instalar nas extremidades da conexão SSH e nenhum portal / proxy para configurar.

Eu não usei o produto, então YMMV.

É impossível bloquear a transferência de arquivos sem remover tantos utilitários do sistema que deixem a máquina completamente inútil. Você precisaria se livrar de tudo o que é capaz de exibir o conteúdo do arquivo no stdout, e de tudo o que é capaz de gravar seu stdin no stdout, e quando você remove todos, resta tão pouco que não há sentido em permitir o acesso ao shell em absoluto.

Então, vou me concentrar na sua alternativa de log:

Existe um programa chamado "script" que está incluído em praticamente todas as distribuições e que deve ser fácil de instalar naquelas em que não está. É um registrador de sessões que registra todas as entradas e saídas de um shell, opcionalmente com dados de tempo, para que possam ser reproduzidos e parecidos com os que você estava observando por cima do ombro do usuário quando o fizeram. (95% de qualquer maneira, ocasionalmente altera a saída quando ncurses está envolvido, mas não com muita frequência.)

Sua página de manual inclui instruções para configurá-lo como o shell de login do sistema. Certifique-se de que os logs vão para algum lugar em que o usuário não possa excluí-los (o atributo de sistema de arquivos somente anexável (configurável via chattr) pode ser útil para isso. Assim como ACLs ou inotificar scripts)

Isso ainda não impede que os usuários copiem arquivos para fora do sistema, mas permite revisar o que foi feito por quais usuários e quando. Provavelmente, não é impossível ignorar, mas o desvio quase certamente acabaria nos registros, para que você pelo menos soubesse que alguém não era bom, mesmo que eles conseguissem esconder exatamente o que era.

Eu acredito que você pode desinstalar o openssh-clients (ou equivalente) no servidor.

Eu acho que o cliente scp invoca o scp no servidor ao copiar dados; portanto, se você se livrar do scp no servidor, você deve ficar bem.

$ 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