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.

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)

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.

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.