Apache seguro

Hoje em dia a segu­rança é de um servi­dor que esteja lig­ado a inter­net é muito impor­tante, emb­ora exis­tam algu­mas empre­sas / pes­soas a descoroar a segurança.

Para vos mostrar que não esta­mos seguros, deixo aqui um soft­ware gra­tu­ito que per­mite detec­tar algu­mas fal­has de segu­rança em servi­dores. Para que pos­sam corrigi-las

http://www.mavitunasecurity.com/communityedition/

Abaixo segue um texto reti­rado do blog do Amigo Ruben Alves, que explica como tornar mais seguro um servi­dor apache..

Hoje fiquei fasci­nado com a leitura de um artigo sobre uma empresa de segu­rança (audi­to­rias, pen­test­ing etc..) que para mostrar o exem­plo, tin­ham tudo con­tra eles… Basi­ca­mente, estão num host da Amen com servi­dores próprios, cor­rem um joomla da treta, Apache 2, PHP, etc… Enfim, o servi­dor nor­mal de qual­quer mor­tal.
Cer­ta­mente que o meu fascínio teria ter­mi­nado bem rap­i­da­mente caso não fosse o site da empresa estar no ramo da segu­rança infor­mática. Foi então que me lem­brei em escr­ever uma série de pequenos tex­tos sobre segu­rança infor­mática e como silen­ciar os malditos serviços que tan­tas fin­ger­prints geram.
As evidên­cias resid­u­ais ou efec­ti­vas das apli­cações em pro­dução são de facto os primeiros ele­men­tos em qual­quer tipo de ataque. Nos ataques web, o primeiro a ser ver­i­fi­cado é sem dúvida o servi­dor web, seguindo da camada apli­ca­cional. A metodolo­gia para desco­brir as fin­ger­prints segue os seguintes pontos:

• Iden­ti­ficar a arqui­tec­tura web/topologia
  Ver­i­ficar a existên­cia de DMZ, servi­dor Proxy/Reverse Proxy, Load­bal­ancer, Fire­wall apli­ca­cional (Ex: Mod­Se­cu­rity) etc…
• Iden­ti­ficar a ver­são do servi­dor web
  Ver­i­ficar de qual é o tipo do servi­dor – Microsoft, Apache, Ngnix etc.. E claro a sua versão.
• Iden­ti­ficar a(s) aplicação(ões) web
  Ver­i­ficar o tipo das apli­cações web estão a cor­rer no servi­dor como por exem­plo Web­min, Joomla, PhpMyAdmin
• Iden­ti­ficar a base de dados
  Ver­i­ficar se o sis­tema pos­sui um sis­tema de base de dados, se sim, os ataques por SQL Injec­tion podem sofrer alter­ações caso trate-se de um MySQL, Post­greSQL, SQL SERVER. O ataque directo ao SGBD tam­bém pode ser real­izado caso este último não esteja dev­i­da­mente protegido.
• Iden­ti­ficar web ser­vices
  CrossOver com o WSDL e acesso directo à plataforma de serviços.

Neste texto ire­mos ver como difi­cul­tar o segundo ponto ape­nas com algu­mas alter­ações no ficheiro de con­fig­u­ração do Apache.

Server­To­ken

Com ape­nas uma linha, podemos silen­ciar o apache de forma quase per­feita. Em tudo o que é Debian e Ubuntu (ainda tenho de ver­i­ficar isso em Cen­tOS) o ficheiro de con­fig­u­ração prin­ci­pal omite o valor Server­Prod, tomando a por valor por omis­são Full. A ideia, é criar uma nova linha com o valor cor­recto, neste caso Prod.

Server­To­kens prod

Basta esta pequena alter­ação para pas­sar de um servi­dor web muito con­ver­sador para algo de reservado.

A ideia por trás desta manip­u­lação é obvi­a­mente escon­der o máx­imo de detal­hes pos­sível sobre o tipo de apli­cações que estão a cor­rer no nosso servi­dor. Ao dar o número de ver­são do Apache, do PHP e infor­mar sobre a existên­cia do Suhosin-Patch, esta­mos de certa forma a dar a estru­tura da porta de casa ao ata­cante.  Ao ter o con­hec­i­mento destes dados, facil­mente procu­ram exploits, lim­i­tações que podem ser explo­radas com a final­i­dade de com­pro­m­e­ter a máquina.
Exis­tem out­ras alter­ações ao Apache que podem ser feitas de forma a sim­ples­mente elim­i­nar o nome do servi­dor, ou mesmo ainda invo­car o erro por parte do ata­cante ao especi­ficar outro tipo de servi­dor (de outra empresa, ou mesmo outro de tipo de ver­sões). Mais com­plexo, pode-se igual­mente com­pi­lar o código fonte do Apache já com o nome do servi­dor que dese­jamos no código fonte (um texto para breve). Para os menos aven­tureiros, é pos­sível igual­mente mudar o nome do servi­dor através do Mod­Se­cu­rity. A solução ideal é mesmo disponi­bi­lizar o mín­imo de infor­mações pos­síveis sobre o servi­dor de forma a difi­cul­tar a vida ao ata­cante de uma forma ou de outra.

ServerSig­na­ture

Depois de indicar o tipo de server­to­ken, a própria assi­natura do servi­dor fica difer­ente. Os famosos erros 404 por omis­são apre­sen­tam uma página branco com o erro, e claro toda a infor­mação do servidor.

ServerSig­na­ture Off

Ao desli­gar o ServerSig­na­ture, toda a infor­mação com­ple­men­tar e inútil sim­ples­mente desaparece.

Homes Direc­to­ries

Nada de mel­hor do que as homes direc­to­ries para desco­brir os uti­lizadores do servi­dor. Um ataque por brute­force aos uti­lizadores sim­pli­fica em muito o processo de descoberta das palavras chaves.
Uma das for­mas para impedir a cri­ação das homes direc­to­ries é sim­ples­mente adi­cionar a seguinte configuração:

<Direc­tory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Direc­tory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>

robots.txt

O ver­dadeiro falso amigo! Todos o uti­lizam para impedir os crawlers (ex: Yahoo, Google­bot etc..) em nave­gar em zonas restri­tas (geral­mente em direc­to­rias do tipo: /admin, /gestao, /root, /administration). Mau, muito mau! Ao indicar este tipo de infor­mações ao ficheiro, estão direc­ta­mente a dizer ao ata­cante onde está escon­dida o vosso back­end! O mel­hor é mesmo criar uma pasta com­ple­ta­mente difer­ente (ex: como se fosse uma pass­word: /W31rd0—here) sem qual­quer refer­ên­cia no código HTML a ficheiros, sitemap, e claro no robots.txt.

Ao longo dos próx­i­mos tem­pos irei descr­ever um pouco mais sobre metodolo­gias de fin­ger­print­ing, e como pro­te­ger os servi­dores mais efi­caz­mente. Antes de ter­mi­nar este texto, que­ria referir, que ape­sar de mais com­plexo, a com­pi­lação própria do Apache (em vez dos RPM ou DEB) mel­hora o desem­penho do servi­dor, tanto a nível de desem­penho como de segu­rança (com­pi­lando ape­nas o que é necessário – criando assim um servi­dor à medida).

Fonte: Ruben Alves