Como posso me proteger contra invasões e malware antes de conectá-lo à Internet (especialmente em um endereço IP público)?

60

Com o grande número de Raspberry Pis em estado selvagem e o fato de que grandes grupos deles são configurados de forma idêntica (quando um cartão SD recém-flashed é instalado com uma das poucas imagens disponíveis), é provável que eles sejam um alvo tentador para malware, incluindo botnets.

O que pode ser feito para mitigar isso?

É razoavelmente conhecido que se deve alterar a senha do usuário "pi" (Debian) e "root" (Arch.). Mas e as outras contas de sistema (por exemplo, "tli", "pnd"?) senhas universais presumivelmente iguais para todas as unidades?

E existem vulnerabilidades conhecidas em outros pacotes instaladas nas imagens SD disponíveis para o Pi (por exemplo, devido a limitações de hardware ou versões reduzidas desses pacotes?)

Em particular, estou preocupado com o sshmysql e quaisquer outros serviços que possam estar em execução em uma imagem recém-instalada.

finnw
fonte

Respostas:

23

Coisas que notei até agora sobre a imagem do Debian Squeeze:

  • / etc / shadow contém vários hashes de senha para contas que não são a conta pi (buildbot, etc). Altere a senha da conta pi, naturalmente, se você ainda não tiver (ou crie uma nova conta de usuário e exclua a conta pi), mas também edite as outras entradas e substitua os hashes por * s. Nota / etc / passwd contém entradas duplicadas para a conta pi, o que confunde muito o adduser / deluser, apenas exclua uma.

  • a configuração padrão do daemon ssh permite login raiz remoto. Isso deve estar desativado.

  • vale a pena usar o netstat para verificar o conjunto de coisas que estão ouvindo conexões; uma quantidade surpreendente de coisas está sendo executada em comparação com um típico netinst mínimo do Debian. Geralmente, é uma boa idéia reduzir a exposição a apenas as coisas que você precisa ; primeiro, desative ou faça o firewall de tudo e exponha apenas os serviços que você deseja deliberadamente que sejam visíveis na Internet pública (normalmente apenas ssh ou ssh + http).

  • convém alterar as chaves do host ssh em vez de usá-las na imagem (AIUI, a imagem mais recente na verdade as regenera na primeira inicialização)

sombra da Lua
fonte
11
Não vejo o problema com sua primeira declaração. Para que servem esses usuários adicionais? Eles não deveriam ser desativados para o login? Você pode verificar tentando supara eles.
Jivings
2
Eu vou dar isso -1. Principalmente porque você sugere editar manualmente o arquivo de sombra. O que é uma ideia tremendamente ruim.
Jivings
@Jivings Não, ele não faz. Ele também pode implicar em usar vipw; Isso é uma má ideia? Não, não é. +1 por implicar o uso vipw.
user2497
41

Existem várias maneiras de lidar com vulnerabilidades, no entanto, a primeira coisa que você deve saber é que o Linux não é tão suscetível à invasão quanto outros sistemas operacionais. Isso ocorre principalmente devido à falta de malware direcionado ao * NIX. No entanto, você deseja estar ciente das maneiras pelas quais seu sistema pode ser acessado.

Senhas

Primeiramente, você deve alterar as senhas padrão para todos os usuários que conseguem fazer login. Para o Debian, este é apenas o usuário padrão Pi . Para o Arch Linux, essa é a raiz do superusuário . As senhas são alteradas quando o usuário é conectado digitando passwdna linha de comando.

Uma política de senha segura é incentivada, pois seria bastante simples executar ataques de dicionário de força bruta no seu usuário padrão. Escolha uma senha decente e de tamanho médio.

Obscuridade

O acesso remoto é provavelmente o furo de segurança mais importante. O que podemos usar aqui é chamado de segurança pela obscuridade . Um método comum de ataque é verificar um intervalo de endereços IP em busca de portas abertas. Portanto, uma das medidas mais simples que podemos tomar é ser um usuário que não use as portas padrão .

Tudo o que precisa ser feito aqui é alterar as portas padrão dos protocolos usados ​​com freqüência. Por exemplo, a porta SSH padrão é 22 e o FTP é 21. No meu sistema, o SSH usa 222 e FTP 221, o que deve ocultar esses protocolos de qualquer ataque automatizado.

Segurança de conexão

Em primeiro lugar, a preocupação de segurança mais importante é que a conta root não consiga efetuar login via SSH. Você pode desativar o login raiz no /etc/ssh/sshd_configarquivo comentando ou removendo esta linha:

PermitRootLogin yes

Deve ser definido como não por padrão, mas é melhor garantir.


Se você usa muito o SSH e está preocupado com ataques do tipo homem no meio, ataques de dicionário contra sua senha, pode usar SSH Keys.

A autenticação baseada em chave tem várias vantagens em relação à autenticação por senha, por exemplo, os valores das chaves são significativamente mais difíceis de aplicar em força bruta do que as senhas simples.

Para configurar a autenticação de chave SSH, você precisa primeiro criar o par de chaves. Isso é feito com mais facilidade na máquina cliente (a máquina com a qual você deseja acessar o Pi).

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.

Como você pode ver, isso criou dois arquivos, a chave privada id_rsae a chave pública id_rsa.pub.

A chave privada é conhecida apenas por você e deve ser protegida com segurança . Por outro lado, a chave pública pode ser compartilhada livremente com qualquer servidor SSH ao qual você deseja se conectar.

Então, o que gostaríamos de fazer é copiar a chave pública no Raspberry Pi. Podemos fazer isso com muita facilidade:

ssh-copy-id pi@address

Onde piestá o nome de usuário do Raspberry Pi e addresso endereço IP do Pi.

Vou reiterar, nós distribuímos a chave pública . A chave privada é sua. Segure-o firmemente, para liberar a chave que quebra a segurança do sistema.

O wiki do Arch tem uma excelente descrição de como isso funciona:

Quando um servidor SSH tem sua chave pública registrada e vê você solicitando uma conexão, ele usa sua chave pública para construir e enviar um desafio a você. Esse desafio é como uma mensagem codificada e deve ser atendida com a resposta apropriada antes que o servidor conceda acesso. O que torna essa mensagem codificada particularmente segura é que ela só pode ser entendida por alguém com a chave privada. Embora a chave pública possa ser usada para criptografar a mensagem, ela não pode ser usada para descriptografar a mesma mensagem. Somente você, o detentor da chave privada, poderá entender corretamente o desafio e produzir a resposta correta.

Para mais informações sobre a segurança da autenticação de chave pública, a Wikipedia tem uma explicação completa .

Com a segurança SSH, você pode realizar uma quantidade enorme de transferências de dados criptografadas e seguras. Praticamente todas as outras conexões de portas podem ser roteadas através do SSH, se necessário. Você pode até encaminhar a sessão X através do SSH para que ela apareça em outra máquina.

Como um exemplo interessante, ontem eu estava executando o Eclipse na minha área de trabalho, visualizando-o no meu Raspberry Pi e controlando o mouse e o teclado no meu Netbook. Tal é o poder do SSH.

Permissões

Permissões de arquivo são o cerne do sistema de segurança Linux. Eles afetam quem pode ver seus arquivos e pastas e podem ser muito importantes para proteger seus dados. Por exemplo, efetue login no Raspberry Pi como um usuário normal e execute:

cat /etc/shadow

O shadowarquivo contém senhas criptografadas para os usuários do sistema; portanto, não queremos que ninguém dê uma olhada nele! Então você deve ver esta resposta:

cat: /etc/shadow: Permission denied

Podemos ver por que isso ocorre dando uma olhada nas permissões do arquivo:

ls -l /etc/shadow
-rw------- 1 root root 821 Jun 11 22:13 /etc/shadow

Isso nos diz que o arquivo pertence à raiz e apenas o proprietário possui permissões de leitura / gravação. Vamos dividir essa saída.

-rw-------

Este é o estado das permissões. O primeiro bit nos diz o tipo de arquivo ( -significa arquivo regular). Os próximos três bits representam as ações disponíveis para o proprietário do arquivo. Os segundos três bits representam o grupo , e os três finais são para outro ou todos os outros. Assim, um diretório com permissões completas ficaria assim:

drwxrwxrwx  10 root root   280 Jun 20 11:40 tmp/

Isso é ler, escrever e executar permissões para o proprietário, grupo e todos os outros.

A próxima parte importante são os dois nomes. No nosso caso root root. O primeiro usuário é o proprietário do arquivo. O segundo é o grupo de usuários . Por exemplo, seria comum ver:

drwxr-xr-x  10 pi users   280 Jun 20 11:40 home/pi

Isso permitiria acesso de leitura / gravação para o usuário piem seu diretório pessoal e acesso de leitura para todos os outros usuários.

Permissões mais frequentemente referidas e controladas usando valores octais. Por exemplo, se quisermos definir rw apenas para o proprietário, digitaremos:

chmod 600 /path/to/file

Esta é uma visão geral básica, para obter mais detalhes sobre as permissões de arquivo do Linux, aqui está um bom artigo.


Esse entendimento é importante ao proteger arquivos e pastas. Por exemplo, digamos que acabamos de configurar as chaves SSH. Definitivamente, não queremos que outros usuários vejam dentro de nosso ~/.sshdiretório ou eles poderão usar nossa chave privada. Assim, removemos seus privilégios de leitura:

chmod 700 ~/.ssh
ls -la ~/.ssh 
drwx------   2 james users  4096 Jun 18 03:05 .

Espero que isso esclareça algumas de suas preocupações com a segurança do Linux. Com isso, você poderá ver que é um sistema bastante seguro e, se for cuidadoso, não deverá ter problemas de segurança.

Jivings
fonte
10
Não concordo com sua observação de obscuridade, levaria alguns segundos para mapear as portas abertas no seu dispositivo e encontrar seu servidor ssh. Desative os logins de senha e atenha-se às portas normais. Duvido que você precise de ftp, use scp.
Alex Chamberlain
2
@AlexChamberlain É uma colisão temporária para atacantes, mas de maneira alguma uma solução completa sozinha.
Jivings
4
A alteração das portas padrão tende a diminuir a batida na porta, o que geralmente leva a ataques de dicionário. Claro que é uma medida de segurança muito pequena, mas também tem outros benefícios, ou seja, pode limitar o inchaço dos registros. É mais uma ação preventiva do que segurança, mas ainda digna de consideração.
Beeblebrox
2
@AlexChamberlain, Durante o desastre da chave ssh do debian, registramos várias tentativas na porta 22 e nenhuma em nenhum outro lugar. Nesse caso, rodar em uma porta diferente teria lhe custado muito tempo enquanto os hackers tentavam descobrir quais dos hosts explorados eram valiosos. O SBO não ajuda tanto se o atacante o está alvejando especificamente.
John La Rooy
11
Concordo. Meu ponto é que não é apenas thereotical - houve um tempo na memória recente, onde SBO definitivamente fez ajuda, e fez uma significativa diferença.
John La Rooy
6

Para evitar ataques de força bruta, você pode instalar e configurar fail2ban. Ele analisará os arquivos de log (como /var/log/auth.log) e tentará detectar se várias tentativas de login falharam. Em seguida, banirá automaticamente os endereços IP de origem iptables.

Há muitos howtos na Internet.

Morgan Courbet
fonte