Esta é uma pergunta canônica sobre como proteger uma pilha LAMP

Quais são as diretrizes absolutas para proteger um servidor LAMP?

A resposta de David é uma boa linha de base dos princípios gerais de proteção de servidor. Como David indicou, esta é uma grande questão. As técnicas específicas que você adota podem depender muito do seu ambiente e de como o servidor será usado. Atenção, isso pode exigir muito trabalho em um ambiente de teste para criar e ser executado corretamente. Seguido por muito trabalho para integrar seu ambiente de produção e, mais importante, o processo de negócios.

Primeiro, no entanto, verifique se sua organização possui políticas de proteção, pois essas podem ser as mais diretamente relevantes. Caso contrário, dependendo do seu papel, pode ser um ótimo momento para desenvolvê-los. Eu também recomendaria abordar cada componente separadamente de baixo para cima.

LA
Existem muitos bons guias disponíveis para ajudá-lo. Esta lista pode ou não ajudá-lo, dependendo da sua distribuição.

• Center for Internet Security Benchmarks - Distribuição específica para os principais sabores
• Como usar o CentOS Hardening - segue de perto o guia CIS RHEL5, mas é uma leitura muito mais fácil
• NIST SP800-123 - Guia de segurança geral do servidor
• NSA Hardening Factsheets - Não atualizado tão recentemente quanto o CIS, mas ainda é aplicável principalmente
• Tiger - Software de auditoria de segurança do sistema ao vivo

O A
Apache pode ser divertido de proteger. Acho mais fácil proteger o sistema operacional e manter a usabilidade do que o Apache ou o PHP.

• Proteção do servidor Apache - Esta pergunta no site irmão de Segurança da TI possui muitas informações boas.
• Center for Internet Security Benchmarks - Novamente, os benchmarks do Apache.
• Dicas de segurança do Apache - Diretamente do projeto Apache, parece que ele cobre o básico
• Lista de verificação de endurecimento da DISA - Lista de verificação da equipe de garantia de informação do DoD

Eles

• Center for Internet Security Benchmarks - Novamente, mas para MySQL
• OWASP MySQL Hardening
• Diretrizes gerais de segurança - lista de verificação básica dos desenvolvedores do projeto

OP
Isso se debruça sobre toda a idéia de práticas seguras de programação, que é toda uma disciplina própria. SANS e OWASP têm uma quantidade ridícula de informações sobre o assunto, então não tentarei replicá-las aqui. Vou me concentrar na configuração do tempo de execução e deixar que seus desenvolvedores se preocupem com o resto. Às vezes, o 'P' no LAMP se refere ao Perl, mas geralmente ao PHP. Estou assumindo o último.

• Endurecendo o PHP - Algumas discussões menores, também no site IT Security SE.
• Projeto PHP reforçado - Projeto principal que produz Suhosin , uma tentativa de corrigir o aplicativo PHP para projetar contra certos tipos de ataques.
• Endurecendo o PHP com Suhosin - Um breve tutorial especificamente sobre Suhosin
• Endurecendo o PHP do php.ini - Discussão curta, mas não ruim, sobre algumas das opções de tempo de execução relacionadas à segurança

Você fez uma pergunta que é, francamente, digna de alguns livros sobre o assunto. Mas existem algumas diretrizes básicas gerais que funcionam bem:

1. Mantenha-se atualizado. Isso significa o sistema operacional, todos os serviços e, ESPECIALMENTE, todos os aplicativos da web em execução.
2. Desative todos os serviços desnecessários, limite os necessários à exposição mínima (se você não estiver se conectando remotamente ao MySQL, não o escute no TCP) e execute um firewall baseado em host. (Se for estritamente LAMP, você deve ser bom com 80 e 443, mas talvez também com SSH para administração.)
3. Use senhas fortes. Melhor ainda, se você usar SSH, use apenas autenticação baseada em chave.
4. Verifique se você não está efetuando login como root. Entre como usuários e use su & sudo.
5. Embora isso não torne as coisas mais seguras, você deve executar ferramentas como o logwatch para estar ciente do que está acontecendo no seu servidor.

Espero que ajude você a começar.

Aqui está uma boa lista de verificação que eu gostaria de começar.

Firewall

• Uma boa abordagem é não permitir o tráfego inicial e, em seguida, abrir apenas o que você precisa , conforme necessário. Isso resulta na abertura das portas / ips mínimos para fazer as coisas funcionarem e isso minimiza sua exposição.
• Para um servidor LAMP, talvez seja necessário abrir portas para http / https no mundo e ssh para sysadmins.
• Certifique-se de que coisas como o tráfego IPv6 estejam bloqueadas se não o estiverem usando
• A AWS fornece grupos de segurança, o linux possui iptables e vários pacotes para você escolher.

SSH e usuários

• Nenhuma senha para acesso ssh (use chave privada)
• Não permita root ao ssh (os usuários apropriados devem ssh, então su ou sudo)
• Use sudo para usuários para que os comandos sejam registrados
• Registre tentativas de login não autorizadas (e considere um software para bloquear / banir usuários que tentam acessar o servidor muitas vezes, como fail2ban)
• ssh na porta não-padrão (isso pode ser útil para garantir que você não fique com pouca fruta e mantenha muito tráfego irritante, mas não fará muito pela segurança, principalmente por si só)
• bloqueie o ssh apenas para o intervalo de ip que você precisa (um grande intervalo é melhor que nenhum intervalo)

Base de dados

• Sanitize dados do usuário
• Parametrizar consultas
• Considere abstrair o banco de dados para sua própria máquina. Essa separação pode dificultar o acesso de um invasor à sua pilha da web e vice-versa.
• Como qualquer software atualizado, é importante.
• Um usuário para cada finalidade . Ao criar usuários, comece sem privilégios e inclua apenas os necessários para executar sua função. Ter usuários separados para aplicativos diferentes (ou às vezes partes distintas dos aplicativos) ajudará a reduzir o benefício que um invasor tem, caso comprometa qualquer conta. Também tenha cuidado com privilégios especiais como GRANT, que não devem ser atribuídos de ânimo leve.
• Ter uma política para alterar senhas periodicamente é uma boa idéia. Se você estiver preocupado com a quantidade de esforço necessária, lembre-se de que menos frequente é melhor do que nunca.
• Entenda a criptografia de senha. Senhas de sal . Não use MD5!

Programas

• Mantenha o software atualizado (SO, servidor Web, linguagem de script, CMS). Muitas pessoas pesquisam vulnerabilidades conhecidas em versões antigas (sem patch)
• Remova qualquer software que você não precisa (idealmente não mantenha o pacote necessário para compilar o software nos servidores de produção, é melhor pré-compilar o software e disponibilizá-lo como um pacote para as suas máquinas de produção)
• Verifique se as permissões de arquivo estão bloqueadas (especialmente para itens como uploads de usuários e arquivos de configuração)
• Proteger com senha a área administrativa do CMS no nível do servidor web (a autenticação http pode ficar na frente de um CMS vulnerável e ajudar a bloquear o acesso, o que é uma boa maneira de evitar ataques)
• Use SSL para a área administrativa e outros dados confidenciais
• Automatize o gerenciamento de seus servidores e infraestrutura (algo como Puppet, Chef ou SaltStack. Se você estiver usando o AWS CloudFormation também). Isso o ajudará a corrigir coisas em vários servidores e reduzirá cenários como corrigir permissões no servidor A, mas esquecer de fazê-lo no servidor B
• Sempre que possível, não forneça a versão específica do seu CMS, PHP ou WebServer. Embora ocultar essas informações não seja segurança, existem muitas pessoas pesquisando versões específicas de diferentes softwares e quanto menos informações você distribuir livremente, mais um invasor precisa trabalhar. Essa é uma boa maneira de garantir que você não seja uma das poucas frutas penduradas. Claro que isso não fará nada para quem quer gastar um pouco mais de esforço entrando
• Limitar as pessoas que têm acesso ao servidor

Adicionando o que David sugere, quanto mais modular sua instalação, refiro-me a restringir o acesso a determinados usuários / grupos criados especificamente para uma tarefa e limitar seu escopo, mais segura sua pilha LAMP: Um exemplo disso é ter um usuário Apache para arquivos / pastas do Apache com permissões definidas de acordo e não em nenhum grupo que possa acessar arquivos / pastas críticos do sistema. Um usuário que pode acessar as tabelas MySql associadas aos seus sites que você servirá e apenas a essas tabelas. Além disso, você pode restringir o acesso deles para fornecer a quantidade mínima de acesso de uma chamada PHP. Além disso, verifique se o nome de usuário MySQL usado / exposto através do arquivo PHP não é o mesmo nome de usuário ou senha usados ​​para outro usuário.

O que isso significa: se o usuário apache ou MySql estiver comprometido, eles não poderão causar nenhum dano fora do escopo das pastas às quais o apache tem acesso (no caso do usuário apache) e fora da tabela ( s) / banco de dados (s) (no caso do usuário para o banco de dados MySQL).

Se, de alguma forma, o usuário do MySQL estivesse comprometido, eles não poderiam, por exemplo, acessar o banco de dados e remover todos os bancos de dados do MySQL e arruinar todos os seus dados. PODEM, em algumas circunstâncias, poder descartar tabelas ou inserir informações em algumas tabelas em um banco de dados isolado, e é por isso que é importante conceder acesso à tabela somente onde for absolutamente necessário e conceder apenas as permissões necessárias ... se você não não é necessário ter privilégios de descarte de tabelas ou privilégios de atualização; então, não os forneça a esse usuário.

Além disso, se por algum motivo seu nome de usuário e senha da conta administrativa forem descobertos no MySQL, se você usar um nome de usuário diferente de qualquer nome de usuário no seu sistema, eles deverão primeiro interromper a segurança do seu sistema antes de entrar no banco de dados para causar danos. O mesmo vale para o usuário apache e o acesso aos arquivos.

Hora do exemplo! Vou dar um exemplo de sistema para simplificar a ideia.

digamos que você tenha usuários em seu sistema (o root deve ser desabilitado por questões de segurança através de algo como umod -l ou passwd -l, etc.): john, barney, terence e lisa.

você pode criar um usuário no MySQL com o nome de bigbird (certifique-se de usar uma senha com hash). O Bigbird possui apenas privilégios de seleção e atualização, mas não descarta ou cria, e certamente não . Além disso, você cria outro usuário administrativo do MySQL com o nome garfield para trabalhar no banco de dados MySQL e exclui o usuário raiz do banco de dados MySQL para que não possa ser comprometido. Garfield foi concedido . privilégios em todo o MySQL (efetivamente, isso é apenas renomear raiz).

agora, você cria um grupo apache ou um usuário e nós o chamaremos apweb2. O Appweb2 não é membro de outros grupos e todos os arquivos / pastas do apache são armazenados em / home / apweb2 /. Cada host virtual teria sua própria subpasta e cada um desses hosts teria a raiz do documento definida para essa subpasta. Os links simbólicos seriam desativados para não fornecer acesso acidental ao restante do sistema.

Além disso, você pode restringir o acesso do ssh apenas a determinados usuários (ou a certos grupos, gosto de colocá-los no grupo ssh e tornar essa a única coisa capaz de usar o ssh).

Além disso, você pode escolher quais usuários têm privilégios de sudo para restringir ainda mais as coisas. Outra etapa que você pode levar adiante é tornar os usuários do ssh incapazes de sudo, você pode criar usuários especiais que podem usar o sudo que não podem usar o ssh, para que, uma vez que você faça o ssh, faça login em outro usuário para ter acesso ao sudo.

Assim, modularizando cada segmento, se um deles estiver comprometido, toda a pilha não estará comprometida e você poderá solucionar o problema 1 em vez de ter que começar tudo de novo do zero.

Achei este documento do SANS.org realmente útil http://www.sans.org/score/checklists/linuxchecklist.pdf

No momento, não negligencie a virtualização de contêiner, como Docker, systemd-nspawn e os mecanismos de virtualização de contêiner nos quais eles são criados (namespaces, cgroups). O uso da virtualização de contêiner permite isolar processos, por exemplo, se um dos serviços for comprometido, um invasor não terá acesso a outros serviços.

No caso do LAMP, é possível usar, por exemplo, quatro contêineres do Docker com servidor SSH, Apache, MySQL, PHP-FPM / Python / Perl / etc.