Teoria - Segurança em Servidores Linux

É verídico que o Linux é de longe o mais seguro dos sistemas operacionais, mas, vale sempre um pouco mais de precaução, pois nenhum sistema é de fato 100% seguro e principalmente quando se trata de administração de servidores, iremos aqui abordar alguns conceitos sobre a segurança nos servidores Linux.

Mas o que protejer com isso? Coisas importantes devem ser questão de preocupação como a Disponibilidade, confidencialidade e integridade. A segurança deve sempre ter início na hora da instalação dos servidores, o administrador deve sempre se preocupar na inserção de senhas no setup entre outros, para evitar o acesso indevido às configurações e sempre manter o foco nas atualizações dos sistemas operacionais, algumas distribuições como o Linux CentOS, Debian, Redhat e OpenSuse são ótimas e seguras na administração de servidores.

Sempre manter o Backup dos arquivos; é uma das melhores maneiras de prevenção caso aconteca o inesperado, o problema é que muitos que administram servidores não estão preocupados com a recuperação dos arquivos, como se nunca fossem passar por prejuísos iminentes ou serem vítimas de ataque de Crackers. É sempre bom criar um particionamento para manter o Backup. Outra dica que vale ressaltar é sempre instalar apenas os pacotes necessários e notar se os mesmos são de fontes seguras, pois muitos pacotes suspeitos podem acabar enviando informações indevidamente para qualquer mal intencionado.

Usar IDSs (Sistemas de Detecção de Intrusos) e principalmente bons Firewalls para monitorar todo o tráfego de informações da rede, assim estará mais seguro e informado sobre o que se passa na rede. Ativar apenas as portas de conexão necessárias e desabilitar as demais, pois um Cracker pode usar qualquer uma das 65.536 portas disponíveis para ter acesso indevido ao servidor.

Sempre manter os serviços SSH atualizados, com isso você poderá fazer acesso remotamente aos servidores com mais integridade e segurança, com todo o tráfego criptografado e usando autenticações com senhas e/ou certificado, também vale manter atualizados outros serviços como o FTP. Utilize mapeadores de redes como o Nmap, Wireshark, NetCap e também algumas distribuições para fazer pen-tests no seu próprio servidor, com isso você saberá como agir e se defender, umas distribuições adequadas para esse tipo de teste é o Backtrack Linux, Kali Linux ou Blackbuntu. Configurar os servidores para a proteção de ataques como DDoS, pois esses tipos de atques tendem a deixar qualquer servidor inativo e vulnerável.

Abraços, Schmitz

FB: /skyfall.schmitz

Read More

Guia - Apache - Aumentando a segurança do seu site usando o .htacess

Nesse post estarei "dando uma luz" para quem usa o Apache como servidor web.

Ao instalar seus serviços web, o apache não cria o arquivo .htaccess em seu servidor, exceto se você está usando uma CMS (Sistema de Controle de Conteúdo, sigla em inglês) como por exemplo o WordPress ou o Joomla!.

Visualizando o arquivo no navegador

Para achar seu arquivo pelo navegador, digite na barra de endereços a URL:

http://seusite/.htacess

Substituindo "seusite" pelo link (URL) do seu site.

Dependendo das configurações do servidor, podem aparecer de muitas formas diferentes o seu conteúdo.

Acessando o .htaccess em servidores linux

Por padrão ele vem oculto dentro de /var/www/ do seu servidor, para ativá-lo entre no terminal e digite

sudo nano /etc/apache2/site-a-editar/default

Substitua "site-a-editar" pelo nome do diretório do seu site.

Se tudo correr bem, você deverá ver algo assim:

<Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
 </Directory>

Salve o arquivo e depois reinicie o serviço web do seu apache digitando:

sudo service apache2 restart

Pronto, agora ele já está funcionando.

Editando o .htaccess em servidores linux

Você pode criá-lo por um editor de textos gráfico e salvá-lo como ".htaccess", tendo cuidado para que seja somente esse o nome do arquivo, sem extensões ou outras palavras e colocá-lo no servidor por meio de um upload.

Ou então no terminal digite

sudo nano /var/www/exemplo.com/.htaccess

Substitua "exemplo.com" para o nome do seu site no apache.

Alterando as permissões de autenticação

Usando o atributo "Authentication" podemos restringir o acesso a certas áreas do site. Usar o htaccess é mais efetivo que o apache2.conf pois este necessita de permissões especiais e muito mais conhecimento técnico.

Para que isso funcione bem, existe a necessidade de criar um arquivo chamado .htpasswd para que este seja o banco de usuários e senhas aceitas na autenticação. Para criá-lo recomendo que use um editor gráfico de texto.

A criação e edição do .htpasswd é muito fácil, após ter criado o arquivo, abra-o e coloque nele os usuários e suas respectivas senhas como exemplo:

joao:senhadeleaqui
maria:amo!minhamae
lucas:sacul2015

Não escreva mais nada nele e tenha cuidado para que cada usuário esteja em uma linha sozinho com sua senha e com entradas duplicadas (que podem causar "bugs" no sistema).

Caso necessite de criptografia para essas senhas, acesse este site aqui (em inglês) para que não ocorram erros nas configurações do arquivo de senhas.

Por razões de segurança, não coloque o arquivo .htpasswd no mesmo diretório do .htaccess.

Voltando ao .htaccess, adicione o código abaixo em seu arquivo para que o .htpasswd seja encontrado pelo servidor.

AuthUserFile /usr/local/nome-usuario-local/pasta-diferente-qualquer/.htpasswd
AuthGroupFile /dev/null
AuthName "Mensagem a ser exibida solicitando a senha"
AuthType Basic
Require valid-user

Substitua "nome-usuario-local" pelo nome do usuário do servidor local e "pasta-diferente-qualquer" pelo nome da pasta que escolheste para o arquivo .htpasswd . Ao lado de "AuthName" coloque a mensagem entre aspas que vai ser vista no navegador pelo usuário. Somente altere a segunda linha se for necessário, caso contrário deixe-a como está.

Não altere as duas últimas linhas, pois elas que vão tratar e filtrar os dados inseridos pelo usuário no navegador.

Pronto, agora o .htaccess está funcional e com um sistema básico de credenciais para acesso.

Alterando as páginas de erro padrão

Página de erro 404 padrão do apache

Você pode perguntar-se, "Por que eu faria isso? Elas não estão funcionando bem?". Sim, porém quando não muda-se as páginas padrão, elas exibem informações como a porta do seu servidor que está com o serviço httpd rodando, além de qual sistema operacional está rodando o apache (veja a imagem acima), então não é recomendável deixá-las padrão.

Para alterá-la é bem simples, vá até o .htaccess e adicione a seguinte linha

ErrorDocument 404 /new404.html

Substitua "404" pelo erro que deseja mudar e "/new404.html" pela página a qual deva ser exibida caso o erro ocorra. Não esqueça que cada redirecionamento tem de estar em uma linha sozinho.

Outro exemplo fictício:

ErrorDocument 404 /index.php
ErrorDocument 500 /index.php
ErrorDocument 401 /index.php
ErrorDocument 402 /index.php
ErrorDocument 403 /index.php

No exemplo acima, os erros foram redirecionados para a página principal do site.

Se quiser um guia completo de quais códigos numéricos de erro colocar no seu arquivo entre aqui na Wikipedia.

Bloqueando acesso a todas as pastas do servidor

Porque fazer isso? Para que evite que o usuário caia em páginas do tipo "index of /". Partindo do pressuposto de que seu servidor só precisa exibir páginas web, não é necessário deixar as pastas acessáveis externamente.

Fazer isso é bem simples, é só adicionar o código abaixo no arquivo .htaccess

Options All -Indexes

Pronto, as páginas do tipo "index of /" estarão inacessíveis pelo navegador.

Restringindo acesso a qualquer outro arquivo pelo navegador

Com o código abaixo colocado no seu arquivo .htaccess

<Files .htaccess>
Order Allow,Deny
Deny from all
</Files>

Substitua ".htaccess" na primeira linha pelo caminho do arquivo que quer bloquear.

Caso necessário, substitua a última linha por "Allow nome-usuario" (para liberar um usuário específico) ou "Allow valid-user" (para liberar qualquer usuário logado).

Dica extra

Uma ideia para bloquear o acesso remoto é bloquear qualquer arquivo de log, de backup e, caso seja da política da sua empresa, qualquer outro que não é para ser visto por ninguém, usando o código acima.

Já aviso que para cada arquivo vai ser necessário um novo bloco de código com o seu caminho, etc.

Conclusão

É possível que somente configurando corretamente o arquivo .htaccess a segurança do seu servidor seja aumentada drasticamente, principalmente contra as chamadas "dorks" e os script kiddies da vida.

Referências (em inglês)

http://stackoverflow.com/questions/11728976/how-to-deny-access-to-a-file-in-htaccess
http://httpd.apache.org/docs/current/howto/htaccess.html
https://www.digitalocean.com/community/tutorials/how-to-use-the-htaccess-file

Espero que tenha ficado claro e até a próxima pessoal.

"Grandes conhecimentos trazem grandes responsabilidades"

Read More

Windows 8: Acabando com a festa dos hackers

Este foi o tema do painel apresentado pelos profissionais de segurança Chris Valasek e Tarjei Mandt na Black Hat USA de Las Vegas deste ano.

Valasek e Mandt são hackers White Hat, profissionais de segurança que testam vulnerabilidade em sistemas e componentes Windows, como o kernel do Windows.

De acordo com Valasek, pesquisador de segurança sênior da Coverity, uma empresa especializada em desenvolvimento de softwares de testes e hardening, o seu trabalho está para se tornar cada vez mais difícil.

Isso porque a Microsoft mudou diversas coisas no seu novo sistema o Windows 8 que vai parar vários ataques já conhecidos. "Se você tem algum exploit de transbordo da pilha que funciona no Windows 7, provavelmente ele não vai funcionar no Windows 8", disse Valasek na sua apresentação.

Nos últimos anos, white hats desenvolveram diversas novas técnicas para comprometer a pilha e o kernel do Windows.

Um dos últimos, por exemplo, refere ao modo de como o Windows distribui dinamicamente a memória. Este é um dos alvos favoritos dos hackers, ou crackers, que tentam exploitar essas vulnerabilidades para causar um overflow de memória, que poderia causar um DoS, ou na pior das hipóteses execução de código.

Um resultado esperado era que estas vulnerabilidades do kernel e da pilha seriam o alvo maior dos malwares. Lá em 2008, por exemplo, o pesquisador de segurança e white hat Ben Hawkes identificou uma falha na pilha do Windows Vista. Hawkes criou um POC (Prova de conceito) que foi capaz de corromper a pilha do Vista e expo-la a execução de código.

Já naquele tempo, Hawkes pode notar que ataques desse tipo antes comuns agora estão ficando mais difíceis e complexos, como o teste dele por exemplo.

O exploit do Hawkes funcionava também no Windows 7, mas não no Windows 8, de acordo com Valasek, a Microsoft fechou a porta na cara do exploit do Hawkes.

E não para por ai. Valasek mostrou um slide comparando o pontencial de exploitabilidade de cada um dos sistemas, entre eles Windows 7, Vista e 8. O que pode-se notar é que no último pode se encontrar muito mais "X" vermelhos do que "√" verdes.

O que a Microsoft mudou na memória que deixou tudo mais difícil, basicamente foi o modo de distribuição em memória, agora sendo aleatório e com alguns outros detalhes mais complexos, como por exemplo, diversos métodos para os programadores encerrarem seus programas caso algo seja modificado de maneira incorreta.

Valasek ainda comenta, "A Microsoft trabalhou duro para cuidar disso e prever problemas antes de ter que reagir e corrigir falhas já expostas".

Ele também adicionou que falhas ainda existem, já com alguns exploits hipotéticos em sua cabeça e confirma que alguns deles irão funcionar.

E o kernel não foi diferente, como Tarjei Mandt comentou, "o kernel continua o mesmo, nenhuma mudança significativa na estrutura foi feita, mas tem alguma camadas de segurança a mais, algo similar a hardening".

Fonte: Redmond Magazine

Read More

Falha no Facebook expõe dados de contato de 6 milhões de usuários

Uma ferramenta do Facebook que permite aos usuários baixar dados de seus perfis (como um tipo de backup) pode ter exposto as informações de contato de 6 milhões de usuários, de acordo com um comunicado da própria rede social, liberado nessa sexta-feira (21), no blog de segurança da empresa.

Os números de telefones celulares e endereços de e-mail armazenados na rede de alguns membros podem ter sido acessados por outros usuários conhecidos, ou que possuem algum tipo de conexão com a pessoa afetada.

O que aconteceu foi o basicamente o seguinte: o Facebook permite a usuários carregar listas de contatos ou listas de endereços em sua rede para que tais dados possam ser combinados com informações de contatos já existentes na plataforma, a fim de sugerir alguns usuários que você possa conhecer, mas que ainda não adicionou em sua rede - o tal "Sugestões de amigos".

Basicamente, a falha "conectou" as informações de colegas ao perfil do usuário. Isso significa que, quando você decidisse baixar os seus próprios dados por meio da ferramenta "Download Your Information" (DYI), pode ser que algumas informações de outros colegas (ou contatos que você tivesse algum tipo de conexão) viessem junto no seu arquivo.

Segundo a empresa, assim que a vulnerabilidade foi analisada e confirmada pela equipe de segurança da empresa, o recurso DYI foi desativado e depois reativado após a correção da falha.

"Concluímos que aproximadamente 6 milhões de usuários no Facebook tiveram seus endereços de e-mail e números de telefone compartilhados. Havia outros endereços ou telefones incluídos nos downloads, mas eles não estavam relacionados a qualquer membro da rede ou mesmo a nomes de indivíduos", diz o comunicado.

A rede social informou ainda que cada dado afetado pela falha foi baixado apenas "uma ou duas vezes". O que na prática significa que as informações afetadas só foram baixadas por um ou dois usuários.

Vale ressaltar que "nenhuma outra informação pessoal ou financeira foi incluída e apenas pessoas no Facebook - desenvolvedores e anunciantes não estão inclusos nisso - tiveram acesso a ferramenta DYI".
A empresa informou que não recebeu qualquer reclamação de que os dados de algum membro possam ter sido usados de forma maliciosa. Os usuários afetados, no entanto, serão notificados por e-mail nos próximos dias.

"Mesmo com uma equipe forte, nenhuma empresa pode garantir 100% de prevenção de bugs e, em casos raros, nós não descobrimos o problema até que ele tenha afetado alguma conta", diz o comunicado.

O bug foi reportado por meio do programa White Hat da empresa, um canal criado para que especialistas externos possam relatar falhas encontradas na rede.

Fonte: IDG Now

Read More