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

12

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

Eu percebo que os acessos a arquivos do tipo ssh $ server "cat file" 'são muito mais difíceis de evitar, mas eu preciso ver como parar o "scp" para iniciantes.

Em caso negativo, existe uma maneira de registrar com segurança todo o acesso ao SCP no lado do servidor através de syslog ?

    
por Peter Mortensen 29.04.2010 / 11:18

11 respostas

9

Enquanto você pode editar seu /etc/ssh/sshd_config para 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 pode usá-lo. Porque se houver apenas alguns comandos aos quais você deseja que eles tenham acesso, eu removerei a capacidade de eles invocarem um shell ssh 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ê acha que precisa realmente executar um shell normal, o máximo que realmente pode esperar é diminuí-lo e torná-lo mais difícil.

    
por 19.06.2009 / 22:20
6

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

O melhor que você pode fazer é mudar o shell dos usuários para um shell restrito (rbash) e só então executar certos 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.

Também sugiro usar a contabilidade de processo para ajudar você a acompanhar as atividades.

    
por 19.06.2009 / 21:10
5

Você não ganha nada parando "scp" quando ainda está permitindo literalmente infinitos mecanismos adicionais de transferência de arquivos. Desativar o scp, mas permitir outros mecanismos de cópia de arquivos, é um método de mentir para os auditores. Frequentemente os auditores pedem para serem mentidos. Normalmente eu vejo auditores trabalhando com gerentes para fazer correções falsas, para que eles possam dizer 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 SO registre toda vez que um arquivo é acessado. Claro que não há diferença entre "ler" e "copiar". Mas isso pode satisfazer um auditor e dar uma segurança significativa ao sistema. Seus registros podem ser tão barulhentos que os dados são inúteis, ou mesmo que você seja forçado a manter uma trilha de auditoria ridiculamente curta. (por exemplo, você não pode registrar cada leitura () - e um aplicativo que faz algo surpreendente pode tornar o registro em log todo aberto (), um desastre).

    
por 29.06.2009 / 08:10
5

Dependendo do tipo de SSH necessário, você pode conseguir esse objetivo (para arquivos não-triviais) usando IPTables para finalizar sessões se o tamanho do pacote for maior que, digamos, 1400 bytes. Isso significa que o ssh interativo funcionará principalmente, mas assim que algo tentar enviar um pacote de 1500 bytes como o scp para um arquivo maior que 1499 bytes, assumindo uma MTU padrão de 1500, ele terminará 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 capturar um arquivo longo ou fazer uma lista longa de diretórios.

No caso mais simples, um comando para fazer isso pode ser parecido com

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

Podemos fazer isso funcionar melhor combinando as verificações de comprimento de pacote com ipt_recent, para permitir um número limitado de pacotes maiores que 1400 bytes dentro de um prazo definido (digamos 8 pacotes por 5 segundos) - isso permitiria pacotes de até 12k para passar, mas pode lhe dar 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 regra acima protegem apenas contra uploads scp, como scp myfile.data remote.host:~ . Para proteger-se adicionalmente contra downloads scp, como scp remote.host:~/myfile.data /local/path , repita as regras acima, mas substitua --dport por --sport .

Um hacker indício pode contornar essas limitações definindo um MTU de menos de 1400 em sua máquina (ou forçar mtu ou similar). Além disso, enquanto você não pode limitar isso a certos usuários, você pode limitá-lo por IP modificando as linhas do iptables conforme apropriado !!

Felicidades, David Go

    
por 17.02.2017 / 21:52
2

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.

    
por 20.06.2009 / 15:44
1

Não. scp e ssh operam nas mesmas portas e usam o mesmo protocolo. Se você abrir uma sessão ssh , poderá até compartilhar sua conexão com as chamadas scp subseqüentes usando opções como ControlMaster .

Se você não quiser que as pessoas copiem arquivos particulares de uma máquina, você não deve conceder a eles nenhum tipo de acesso à máquina.

    
por 19.06.2009 / 20:35
0

Bloquear a transferência de arquivos sem remover tantos utilitários do sistema, pois deixar a máquina completamente inútil é impossível. Você teria que se livrar de tudo que fosse capaz de exibir conteúdo de arquivo para stdout, e tudo capaz de escrever seu stdin para stdout, e no momento em que você removeu todos eles há tão pouco que não há nenhum ponto para permitir acesso shell em tudo.

Por isso, focaremos sua alternativa de registro:

Existe um programa chamado "script" que está incluído em praticamente todas as distros, e que deve ser fácil de instalar nas que não estão. É um registrador de sessão que registra todas as entradas e saídas de um shell, opcionalmente com dados de tempo para que ele possa ser repetido e pareça como se você estivesse observando o ombro do usuário quando ele o fez. (95% de qualquer maneira, ocasionalmente faz a saída funcionar quando ncurses está envolvida, mas não com muita frequência).

Sua página man 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 simplesmente excluí-los (o atributo filesystem somente de anexação (configurável via chattr) pode ser útil para isso. Assim como ACLs ou inotify scripts)

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

    
por 30.05.2018 / 01:04
0

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 os dados, então se você se livrar do scp no servidor, então você deve estar 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 [email protected] reply 0
lost connection
    
por 25.10.2018 / 03:36
0

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

Você pode explorar o hack scontly para realizar o inverso.

    
por 19.06.2009 / 20:37
0

Isso não é possível, na verdade, depois de um pouco de googling.

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

    
por 19.06.2009 / 20:37
0

Por que vale a pena, o produto comercial CryptoAuditor afirma ser capaz de controlar as transferências de arquivos por SSH, por < hit="https://en.wikipedia.org/wiki/Man-in-the-middle_attack"> MITM ligando a conexão e usando inspeção profunda de pacotes . Obviamente, nenhuma solução é segura de copiar + colar, uuencode / decodificar, FISH , etc. O bom é que é transparente ( além de prováveis erros de certificado); não há software de agente para instalar em qualquer extremidade da conexão SSH e nenhum portal / proxy para configurar.

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

    
por 27.01.2017 / 00:00