Bloqueando meu servidor Ubuntu com o UFW [duplicado]

Question

Estou usando o Ubuntu 12.04 em uma instância do Amazon EC2 e novo no lado sysadmin das coisas. Estou trabalhando em um pequeno projeto e já estou começando a me tornar alvo de bots (pelo menos espero que sejam bots).

Estou usando o PHP e, em meus registros de erro, observei w00tw00t romanian anti-sec e /w00tw00t.at.blackhats.romanian.anti-sec: . Eu pesquisei e encontrei vários resultados, como este e esta que afirmam que é mais provável que sejam apenas alguns bots. Eles estavam procurando por variações do PHPMyAdmin, PMA, MyAdmin. Pelo que posso dizer, eles não encontraram nada e só conseguiram alguns erros 404. No que diz respeito ao PHPMyAdmin, estou usando um alias e tenho acesso restrito a alguns endereços IP.

Atualmente estou executando o UFW e tenho essas regras

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22                         ALLOW       MY.IP.ADDRESS1
22                         ALLOW       MY.IP.ADDRESS2
22                         ALLOW       MY.IP.ADDRESS3
80                         ALLOW       Anywhere (v6)
443                        ALLOW       Anywhere (v6)

Todos os tutoriais que vi no UFW dizem apenas como configurá-lo, e não sugestões sobre a própria configuração. Basicamente eu uso SFTP e SSH (com um par de chaves) para trabalhar no meu servidor. Há alguma regra que deve ser omitida?

    

Answer 1

Não vejo como você possivelmente usaria o UFW para evitar esse tipo de ataque.

Se tudo, exceto o 80/443, for negado ao acesso público e você tiver especificado apenas alguns IPs específicos para o acesso ssh, o problema está no aplicativo, não na configuração da rede.

Nem toque nas regras de firewall nesta instância.

Você precisa se proteger de:

• Senhas fracas
• Links "Admin page" óbvios, ou seja, website.com/admin, website.com/phpmyadmin
• Senhas incorporadas no seu código
• Injeções de SQL e outras diversas vulnerabilidades de código da Web / banco de dados.

Para aumentar a segurança do seu servidor, você pode fazer o Apache executar o chroot'ed, para que ele seja separado do sistema principal por uma camada virtual.

Você também pode implementar o FIM (gerenciamento de integridade de arquivos) para garantir que os arquivos que não devem ser alterados não sejam alterados (exemplo: a configuração do apache / php)

ou você pode escrever um script para registrar todos os comandos executados pelo root / apache e enviá-lo por e-mail periodicamente.

Coisas assim são o que você deve olhar depois de configurar seu firewall (o que você fez)

    

Answer 2

Provavelmente, a melhor maneira de se proteger da varredura do painel de controle é não executar um painel de controle da web. Se você puder evitar fazer isso, você pode ignorar totalmente esses ataques.

Outra coisa que você pode fazer para se proteger de ataques comuns é configurar uma VPN e restringir o acesso a serviços administrativos (SSH, painéis de controle, etc.) para endereços IP nessa VPN. Use seu firewall para garantir que esse tráfego realmente venha da VPN e não seja falsificado (por exemplo, descarte o tráfego vinculado à interface VPN da WAN).

Se você usar senhas strongs, manter seus aplicativos atualizados, usar usuários de privilégios mínimos para daemons e seguir as práticas recomendadas, você não precisa se preocupar com esses tipos de ataques automáticos.

Tenha em mente que não há um conjunto de regras mágicas de firewall, e um firewall não pode protegê-lo de muitas coisas. Eles foram projetados para manter os serviços "internos" inacessíveis à WAN pública (veja meu ponto sobre a VPN), e você pode usá-los para descartar certos tipos de tráfego que, de outra forma, violariam um limite de segurança, mas eles não funcionam camada de aplicação e você não pode usar isso para proteger seus aplicativos da Web.

    

Answer 3

Todos os w00tw00t de tráfego em seus registros significam exatamente o que você está vendo: Você é investigado por um script de algum tipo. Eu não faria uma grande parte disso, mas se você estiver realmente preocupado, use iptables & ufw realmente não ajudará.

Como parece que você está executando um servidor da Web, recomendamos o uso do ModSecurity .

O Ubuntu tem um pacote no repositório para o ModSecurity, mas o conjunto de regras principal (CRS) está desatualizado. Então, eu recomendo fazer o download aqui .

O que nos leva a um buraco de coelho de: O ModSecurity não é tão fácil de configurar para iniciantes. Já fiz isso várias vezes, mas, mesmo quando está em execução, há problemas que você precisa conhecer. Como o fato de que, desde ModSecurity opera heuristicamente & monitora o tráfego da Web e, às vezes, o comportamento esperado em seu servidor da Web será bloqueado devido a um "falso positivo" aparecendo.

O que é tudo para dizer, você pode estar em um cenário onde você realmente não precisa se preocupar com nada ainda. Servidores da Web - e todos os servidores - são verificados o tempo todo. Dependendo do que você está fazendo com esse servidor, o melhor & a segurança mais real é garantir que seus aplicativos frontais estejam seguros. E se você está codificando sua própria base de código PHP, pode ter certeza de que está seguro.

Se você estiver usando algum software padrão como o WordPress ou o Joomla !, meu melhor conselho é fazer isso: Basta colocar as senhas de autorização da Web do Apache nas URLs / caminhos de administração do seu CMS. Sério, esta é uma das melhores medidas de segurança por aí. Scripts que sondam sites geralmente procuram por falhas no script (PHP, Perl, Ruby, etc…) codificando, mas colocando uma senha de autorização web do Apacce, você bloqueou uma boa parte dos scripts lá fora. O negativo dessa abordagem é que agora você precisa lembrar sua senha para o CMS, bem como a senha do Apache, mas isso é um inconveniente trivial comparado a ter seu sistema comprometido.