Pergunta de segurança relativa à implantação de aplicativos da web

Question

Estou prestes a implantar um aplicativo da Web (em alguns meses) com a seguinte configuração (talvez de qualquer maneira):

Ubuntu Lucid Lynx com:

1. IP Tables firewall (estilo de lista branca com apenas 3 portas abertas)
2. Porta SSH personalizada (como 31847 ou algo assim)
3. Nenhum acesso SSH "raiz"
4. Nome de usuário longo e aleatório (não apenas "admin" ou algo assim) com uma senha longa (65 caracteres)
5. PostgreSQL que apenas escuta localhost
6. Certificado SSL de 256 bits
7. Proxy reverso do NGINX para o meu servidor de aplicativos (UWSGI)
8. Suponha que minha cor é segura (acesso físico não é minha preocupação por enquanto)
9. Segurança em nível de aplicativo (injeção SQL, XSS, Directory Traversal, CSRF, etc)
10. Talvez o mascaramento de IP (mas eu realmente não entendo isso ainda)

Isso soa como uma configuração segura? Eu ouço sobre os aplicativos da web das pessoas sendo hackeados o tempo todo, e parte de mim pensa: "talvez eles estejam negligenciando algo", mas a outra parte pensa: "talvez não haja nada que você possa fazer para proteger seu servidor, e as coisas são apenas medidas para tornar um pouco mais difícil para os kiddies de script entrarem ". Se eu lhe dissesse tudo isso, fornecesse o meu endereço IP e informasse quais portas estavam disponíveis, seria possível entrar (supondo que você tenha uma ferramenta de teste de invasão) ou isso é realmente bem protegido.

    

Answer 1

1. Se as 3 portas são 80/443/22, então você é bom;)
2. Isso não ajuda muito, já que o servidor SSH se identifica ao 'bater', então ferramentas como o NMap irão lhe dizer o que realmente roda naquela porta alta. Segurança por obscuridade é bastante inútil.
3. Se você não quer dizer login root remoto, então sim, isso ajuda. Se você quer dizer que você tem outra conta com UID de 0, então é menos bom. Ter outra conta não particular usada para se conectar, depois su / sudo para a raiz real somente quando necessário.
4. Senhas longas são impossíveis de lembrar, então você vai armazená-las em algum lugar. Nesse ponto também pode desativar logins de senha completamente e ir apenas certificado. Isso BTW, resolve 99% de todas as tentativas de bater SSH.
5. Se o seu DB escuta localmente, por que escutar em um soquete de rede? Por que não passar por um soquete do sistema de arquivos? Não só é mais seguro (nada escuta), mas se você está se conectando de uma fonte local de qualquer maneira, é realmente mais rápido (sem sobrecarga de protocolos de rede)
Os certificados SSL
6. geralmente são mal configurados. Verifique se os domínios e as datas estão configurados corretamente.
7. Mesmo que a segurança física não seja uma grande preocupação, você ainda pode impedir seus próprios 'brainfarts', como reinicializar o 'ctrl-alt-del' e o bloqueio automático de um terminal inativo conectado.

Answer 2

www.insecure.org é um ótimo lugar para começar a procurar por softwares de teste de vulnerabilidades e, claro, o google.

No topo da minha mente, algumas ferramentas me vêm à mente ... - nmap - metasploit - santo - arroto suite - guarda de lan

Um para lembrar ao proteger qualquer coisa conectada à Web ... Ele nunca pode ser totalmente protegido até que seja desconectado da Internet. Parece que você está tomando todas as medidas apropriadas para manter o script kiddies, e provavelmente a maioria das ferramentas automagic h4ck. Mas lembre-se, com a motivação certa / talento / tempo, não há nada que você possa fazer para se proteger de "acesso não autorizado".

    

Answer 3

Esse é um ótimo começo, mas lembre-se de que suas precauções precisam ser reavaliadas sempre que forem testadas.

Considere DenyHosts , SentryTools e / ou qualquer outra ferramenta de monitoramento que lhe agrade.

    

Answer 4

Eu testaria com o Nessus, e se você estiver se sentindo aventureiro, tente o Nikto.

Além disso, pegue um IDS na frente dele, como Snort.

Você pode querer alertar seu ISP de que está fazendo testes de vulnerabilidade, dependendo da sua configuração.

Parece que você está no caminho certo.