12 medidas para um MySQL Apache Linux PHP web LAMP raiz servidor seguro

A freqüência de pirataria aumentou dramaticamente nos últimos meses. Especialmente uma grande quantidade de dados a serem captados por hacks em servidores web. Até mesmo a Sony PSN corte aproveitou de uma vulnerabilidade não corrigida no Apache Web Server. Então aqui eu estou levantando as medidas que o servidor pode possuir um pouco mais seguro contra ataques de fora. Claro, isso também não oferece proteção 100%, mas é melhor fazer os bandidos o jogo um pouco mais difícil. Algumas das medidas requerem apenas uma instalação mínima e manutenção. Outros precisam de um monte de tempo e conhecimento de PHP para pegar. Você deve sempre prestar atenção à relação custo-benefício na seleção de medidas de segurança. Não faz sentido para proteger um site pequeno e privado como o Banco da Reserva Federal. No entanto, poucas alterações específicas para o sistema já tem uma grande segurança significa mais. E que você deve tratar mesmo antes que seja tarde demais ....

Todas as dicas e Codesnips referem-se a uma caixa de Debian atual.

Primeiro O firewall - proibir Uma vez que tudo

A maioria das distribuições Linux em suas instalações de padrão abrir as portas para o exterior que não são absolutamente necessárias. Esta situação pode mudar rapidamente, no entanto, mesmo quando o servidor
brincar e experimentar coisas. De repente, até mesmo o servidor de mídia está escutando na internet ou no banco de dados
aceita conexões de Internet. Portanto, não é errado para se disciplinar e colocar um firewall muito restritivo que basicamente proíbe Uma vez que todas as ligações do lado de fora e permite apenas a (auto-) compostos selecionados. Felizmente, isso é feito rapidamente com o iptables. Desta forma não se pode mais prestar serviços para tornar acessível ao mundo que não tem nenhum negócio lá. Infelizmente, você paga um pouco de conforto - o firewall deve ser ajustada a cada momento em que você deseja oferecer novos serviços. Não obstante, o esforço é pequeno e os benefícios de grande porte.

 # I! / / Apagar o bash # tabelas existentes iptables-F # proibir todas as conexões iptables-P GOTA DE ENTRADA iptables-P FORWARD DROP # Tudo saída permitem iptables-P OUTPUT ACCEPT # SSH permitir iptables-A INPUT-j ACCEPT-p tcp - dport 22 # Permitir HTTP iptables-A INPUT-j ACCEPT-p tcp - dport 80 # serviço adicional (UDP) permitir, por exemplo, jogo do servidor iptables-A INPUT-j ACCEPT-p tcp - dport 4534 # Tudo de Host Local . permitir  (Isto pode acessar livremente o próprio servidor do seu serviço, por exemplo, # PHP em banco de dados local iptables-A INPUT-j ACCEPT-s 127.0.0.1 # conexões já estabelecidas em cada porta aceita # (necessário para alguns daemons) iptables - A INPUT-m state - estado ESTABLISHED, RELATED-j ACCEPT 

Este backbone pouco podemos simplesmente continuar a expandir e adicionar seus próprios serviços. Ao trabalhar no firewall, você deve sempre tomar providências para o caso que bloqueia a si mesmo. Especialmente para servidores remotos para que você não tem acesso físico, é muito chato perder por um firewall não governar o seu próprio acesso. Para evitar este problema fora do caminho, você pode deixar o trabalho para começar no firewall temporariamente apenas um trabalho cron que redefine o firewall a cada poucos minutos ou o servidor é reiniciado. São as regras depois testado e amado, o cron será desativado e as novas regras permanentemente ativa.

Para descobrir quais serviços são apenas cerca de ouvir o seu próprio servidor, você pode usar netstat:

 # Para sockets TCP:
 netstat-lpn | grep tcp

 # Da mesma forma para UDP:
 netstat-lpn | grep udp

Para testar se o firewall realmente funciona, você pode scanear seu próprio servidor de outro computador. Tudo funcionou e deve resultar em apenas as portas que estão abertas até:

 # Para TCP:
 nmap-p1-65 535 meinserver.de

 # Para UDP:
 nmap-sU-p1-65 535 meinserver.de

Segundo SSH proibição logins

Em sua própria raiz do servidor você tem acesso SSH completo. Isto é bastante útil, como você pode partir de qualquer cliente SSH para os tempos de servidores apenas para trabalhar sobre ela. A desvantagem desta situação é que o curso pode alguém que, infelizmente, é de alguma forma tomado suas próprias senhas. É muito mais seguro para permitir logins via SSH apenas com um ficheiro de chave válido. Portanto, a chave pública do cliente para o servidor e copiados logins interativos estão desativados, digitando uma senha.

 # No cliente, crie uma chave pública
 # Se for especificado ao gerar uma senha, é preciso
 # Arquivo de log mais tarde, a chave ea senha.  Caso contrário
 # Só necessário a chave.

 ssh-keygen-t rsa

 # Copie a chave gerada para o servidor

 ssh-copy-id-i ~ /. ssh / id_rsa.pub root@meinserver.de

 # Agora ajuste sshd_config no servidor / etc / ssh /
 .
 .
 PasswordAuthentication no
 .
 .

 # Em seguida, começar de novo RearBBpos
 / Etc / init.d / ssh reiniciar

Mesmo aqui, deve-se tomar precauções para não fechar para fora, mesmo se algo não funciona.
A chave pública em um stick USB com a senha correspondente em sua cabeça torna muito mais difícil para os bandidos para obter uma shell.

Terceiro SSH Bruteforcing evitar DenyHosts

Se o conselho não é prático 2 e você não desistir da conveniência de senha baseadas logins quiser, você pode pelo menos evitar que as taxas de senha automatizado de atacantes no servidor. Um monte de bots na internet o dia todo olhando para fazer mais nada além de servidores SSH e experimentar em suas várias senhas. Com uma senha razoavelmente segura não é um grande problema, mas há uma sensação melhor, nem mesmo se isso é possível. Além disso, ele também protege seus usuários, se existem sobre as contas de servidor e do usuário. Aqui, você não pode confiar em que os usuários usem senhas seguras. DenyHosts constantemente revisados ​​e logins ssh sobre o usuário bloqueia por um tempo que entraram a senha incorretamente repetido. A do IP de usuários temporariamente entrar em / etc / hosts.deny, de modo que eles não têm mais acesso é possível. Este SSH Bruteforcing a uma tarefa muito longa e não muito promissor.

 apt-get install DenyHosts

 DenyHosts # funciona direito após a instalação.  Ela pode ser
 # Na sintonia arquivo / etc / denyhosts.conf multa

4 As listas negras usado para bloquear IPs de problemas conhecidos

Em listas negras de Internet diferentes são mantidos, que lista um grande número de servidores criminais / picado / spam / fraudulenta. Estas listas de IP pode ser digitado diretamente no firewall, para que desse não é conhecida a computadores confiáveis ​​não podem se conectar a todos para seu próprio servidor. Assim, você pode reduzir a quantidade de spam no seu próprio servidor de forma dramática e um ou outro script kiddie lock-out, porque o seu procurador russo de repente pára de funcionar. Como fazer que eu fui em outro artigo do blog descrito o exemplo da lista negra de Infiltrated.net.

5 Não usar o FTP para trabalhar no servidor

FTP é uma relíquia de tempos melhores, quando a Internet era uma pequena aldeia ainda confiável. Muitos administradores de sites ainda usam o FTP para transferir arquivos para o servidor ou para trabalhar em seu próprio site. Infelizmente, isso é muito incerto, pois FTP transmite todos os dados sem garantia. Senhas e dados podem ser lidos sem problemas em cada salto entre servidores e clientes. Muito mais seguro ir com sshfs. Permite montar um diretório via ssh no sistema do servidor remoto de arquivos local. Você pode então trabalhar no servidor como se fosse no computador local. Todo o acesso ao arquivo para arquivos no servidor são completamente transparentes, assim você pode abrir com o programa gráfico local para editar uma imagem no servidor diretamente, e depois salvar. Mais conforto e segurança, sem muito esforço.

 # Instalar sshfs
 apt-get install sshfs

 # Criar ponto de montagem no sistema de arquivos local
 mkdir / media / myserver

 # Servidor para a montagem local do sistema de arquivos
 sshfs www-data@mein-server.de :/ var / www / media / myserver

 # Agora, o diretório é / var / www no meu servidor local sob / media / myserver disponível

6 Instalar atualizações

Um sistema super seguro não vai ajudar se o próprio sistema é falho e uma vulnerabilidade conhecida pode ser explorada. Na maioria dos casos, essas vulnerabilidades fechado rapidamente, mas muitas vezes esquecido admin atualizações regulares do sistema para fazer. Se você deve ativar as atualizações automáticas em servidores Linux ou não é uma questão controversa. Alguns nunca faria, porque, naturalmente, com muita má sorte pode ser que as atualizações de tornar o sistema inutilizável. Isso aconteceu comigo em mais de 10 anos de trabalho em sistemas Debian, mas nunca e eu aprecio os benefícios de atualizações em tempo hábil e regular, muito maior do que o risco resultante.

 # Esta linha no / etc crontab /, atualiza o relógio do sistema todos os dias às 6 da manhã
 0 6 raiz *** apt-get update && atualização apt-get-y

Estes método rápido e rasteiro trabalhou para mim até agora sempre bom. Eu li recentemente que no repositório Debian eo pacote autônoma upgrades existe que resolve o problema, provavelmente, mais elegante, mas eu não foram testados.

Mesmo com essas atualizações de sistema vollautomtischen não é completamente fora do gancho. Se uma atualização do kernel foi entregue, você tem que inicializar o sistema mais uma vez com a mão, caso contrário as alterações não estará ativo.

Se usarmos de terceiros código PHP no servidor, como um CMS open source ou um fórum, é claro absolutamente necessário e este código com a nova versão até a data. Desde o Debian não atualiza suas alterações às aplicações nas regras que regem este trabalho manual é necessário. A melhor maneira de ler as suas listas de discussão com os correspondentes produtos, a fim de estar sempre atualizado.

7 PHP com open_basedir aprisionar

Muitos cortes baseada no fato de que uma vulnerabilidade no código PHP é usado para acessar arquivos no acesso ao sistema de arquivos que não pertencem ao site, mas o sistema em si é por isso que você deve bloquear o PHP para que ele leia apenas em diretórios especificamente designados e escrever permitido. Para isso, o php.ini a opção de configuração de open_basedir. PHP tem a opção de colocar o acesso só é permitido para os diretórios lá. Arquivos como o / etc / passwd estão fora de alcance. Hospedando vários sites em um servidor, você deve definir open_basedir em cada configuração de host virtual em cada lado.

 Php.ini # global através de:
 # Etc/php5/apache2/php.ini /
 open_basedir = tmp / var / www / :/ /

 # Site Per na configuração VirtualHost:
 php_value open_basedir / var / www / site / :/ tmp /

É importante considerar se todos os sites foram adicionados aos scripts geralmente precisa ter acesso, caso contrário, pode ser que você são funções deficientes e legítimo da aplicação PHP.

8 Crie seus próprios sites para usuários do MySQL

Use a sua aplicação PHP-MySQL próprio, você deve criar para absolutamente Apllikation usuário MySQL própria e sob nenhuma circunstância usar as solicitações dos usuários do MySQL raiz. Você também deve restringir os direitos do usuário até que as operações realmente só são permitidos, o que requer o script PHP. CREATE TABLE e DROP TABLE são tão comuns em injecções SQL e usada na maioria das aplicações PHP nunca necessários. Abriga vários sites com vários bancos de dados em um servidor, você deve criar seus próprios bancos de dados para todos os usuários. Assim, após um ataque bem-sucedido, um atacante só tem acesso a um dos bancos de dados e não diretamente em tudo. Se você não quer tentar a linha de comando para gerenciar as contas de usuário do MySQL, usuário de gestão funciona também muito fácil com o phpMyAdmin no separador "direitos".

9 Mensagens de erro do PHP fora

Mensagens de erro do PHP um atacante pode revelar muito sobre o seu próprio servidor: estruturas de diretórios, estruturas de banco de dados, erros de configuração, etc Eles também olhar para o utilizador muito profissional. Por esta razão, devem estar em um servidor web ao vivo, desligue sempre porque você está indo só para continuar a ver nos logs.

 Php.ini # global através de:
 # Etc/php5/apache2/php.ini /
 display_errors = Off

 # Site Per na configuração VirtualHost:
 display_errors php_flag Off

 # Mensagens de erro lê-lo de qualquer maneira:
 cat / var/log/apache2/error.log | grep php

10 Meta para SQL limite de injeção com ModSecurity

Injeções de SQL são o método mais utilizado de ataque em servidores web. Acessado diretamente através da aplicação web e cumpre um navegador para executá-las. Aqui são transmitidos pelas variáveis ​​usuário construídas consultas SQL enviados para os privilégios do usuário do banco todo seu banco de dados irá apagar ler ou editá-los. A proteção real e genuína contra injeção de SQL só existe se o código PHP foi escrito no site em relação a esses ataques. Cada variável de entrada do usuário, o que poderia entrar em uma consulta SQL, ele deve ser testado e escapou. PHP oferece a real_mysql_escape_string function ().

Se você não tem certeza se o código estiver limpo, pode mod_security do Apache ajudar a evitar uma grande quantidade destes ataques de qualquer maneira. revisão mod_security constante todas as solicitações para o servidor Web e responde a pré-padrão que os ataques de injeção SQL muitos pode ser bloqueado. Infelizmente, só funciona bem com esforço manual do mod_security. Muitas vezes, depois de alguns blocos mod_security frescas de instalação também necessária (regular) funções do seu código PHP, de modo que uma não tem outra escolha, como a aplicação completa para testar a instalação novamente. Só então é que se descobrir se mod_security pode até não querer bloquear funções. Se assim for, em seguida, a lista de filtro a ser ajustado a desaparecer de modo que o falso-positivo.

A configuração do mod_security é um pouco complicado e está fora do escopo deste artigo, mas há toneladas de bons tutoriais sobre o mod_security Internet.

11 ID check - Apache não sabe quem ele é
Isto não é realmente método eficaz contra um hack, faz scripts automatizados que estão à procura de versões de servidores, mas ligeiramente mais pesado. Normalmente os pontos Apache para páginas com mensagens de erro (por exemplo, 404 não encontrado) a sua assinatura de servidor.

 Apache/2.2.16 Server (Unix) em www.daniel-ritter.de Porta 80

Ele elimina qualquer potencial agressor receberá pelo menos uma vez antes sobre o servidor Web eigesetzten eo nível de versão. O servidor de assinatura é desligado rapidamente:

 # Etc/apache2/conf.d/security /
 ServerSignature Off

12 Não use desativar os módulos do apache

Por padrão, o Apache foi carregado alguns módulos que quase nunca são necessárias. No Debian você pode encontrar os módulos carregados
como um soft link em / etc/apache2/mods-enabled.

Pode ser removido quase sempre:

mod_cgi

Usado para executar scripts CGI. Esta técnica remonta aos primórdios da Web e foi o antepassado de linguagens de script modernas para permitir sites dinâmicos. mod_cgi é desnecessário para 99% dos sites em PHP e com uma falha de configuração do Apache é um buraco de segurança em potencial

 a2dismod cgi

mod_status

Permite que os navegadores para ler informações de status sobre o Apache. Ele quase nunca é usado para "normal" sites, fornece informações de status sobre os atacantes, mas Apache.

 estado a2dismod

mod_autoindex

mod_autoindex garante que os diretórios podem ser listados no servidor web, se não houver uma página de índice válido no diretório apropriado. Se esta funcionalidade não é desejada, você deve desativá-lo, uma vez que árvores de diretório inteiras no servidor web pode ser visível externamente.

 a2dismod Autoindexável