Pesquisar neste blog

segunda-feira, 23 de abril de 2012

Aprenda Linux, 101: Gerenciar bibliotecas compartilhadas

Resumo:  Aprenda a determinar quais são as bibliotecas compartilhadas necessárias aos seus programas executáveis do Linux® e como carregá-las. Use o material deste artigo para se preparar para o exame LPI 101 de certificação de administrador de sistema Linux ou simplesmente por diversão.





Neste artigo, você aprenderá a localizar e carregar as bibliotecas compartilhadas necessárias aos seus programas do Linux. Aprenda a:
  • Determinar quais bibliotecas um programa necessita
  • Saber como o sistema localiza bibliotecas compartilhadas
  • Carregar bibliotecas compartilhadas
Este artigo lhe ajuda na preparação para o objetivo 102.3 do tópico 102 do exame Junior Level Administration (LPIC-1) 101 do Linux Professional Institute. O objetivo tem peso 1.
Para tirar o máximo dos artigos desta série, é necessário ter conhecimento básico de Linux e possuir um sistema Linux funcional em que seja possível praticar os comandos aqui abordados. Algumas vezes, é possível que versões diferentes de determinado programa formatem a saída de modo diferente, assim, pode ser que seus resultados não sejam exatamente iguais às listas e figuras exibidas neste documento. Particularmente, muitos dos exemplos deste artigo vêm de sistemas de 64 bits. Nós incluímos alguns exemplos de sistemas de 32 bits para ilustrar diferenças importantes.


Entre em contato com Ian

Ian é um dos nossos autores mais populares e produtivos. Pesquise todos os artigos do Ian no developerWorks. Confira o perfil de Ian e entre em contato com ele, com outros autores e leitores no My developerWorks.
Os sistemas Linux têm dois tipos de programas executáveis:
  • Executáveis vinculados estaticamente contêm todas as funções da biblioteca que eles têm de executar; todas as funções da biblioteca estão vinculadas no executável. Eles são programas completos que não dependem de bibliotecas externas para execução. Uma vantagem de programas vinculados estaticamente é que eles funcionam sem pré-requisitos de instalação.
  • Os executáveis vinculados dinamicamente são programas muito menores e incompletos, ou seja, eles precisam de funções de bibliotecas compartilhadas externas para serem executados. Além de ser menor, o link dinâmico permite que um pacote especifique bibliotecas de pré-requisito sem a necessidade de incluí-las no pacote. O uso de link dinâmico também permite que muitos programas em execução compartilhem uma cópia de uma biblioteca em vez de ocupar a memória com muitas cópias do mesmo código. Por esses motivos, a maioria dos programas atualmente usa link dinâmico.
Um exemplo interessante em muitos sistemas Linux é o comando ln (/bin/ln), que cria links entre arquivos, sejam eles linksfísicos ou não-físicos (ou simbólicos). Este comando usa bibliotecas compartilhadas. Bibliotecas compartilhadas frequentemente envolvem links simbólicos entre um nome genérico para a biblioteca e um nível específico da biblioteca, assim, se os links não estão presentes ou estão quebrados por algum motivo, o próprio comando In pode estar inoperante, criando um problema circular. Para proteger-se contra essa possibilidade, alguns sistemas Linux incluem uma versão vinculada estaticamente do programa In como o programa sln (/sbin/sln). A Listagem 1 ilustra as grandes diferenças de tamanho entre o In dinamicamente vinculado e o sln estaticamente vinculado. O exemplo é do sistema Fedora 12 de 64 bits.

Listagem 1. Tamanhos de sln e In
[ian@echidna ~]$ ls -l /sbin/sln /bin/ln
-rwxr-xr-x. 1 root root  47384 2010-01-12 09:35 /bin/ln
-rwxr-xr-x. 1 root root 603680 2010-01-04 09:07 /sbin/sln

Embora não seja parte dos requerimentos atuais do exame LPI para este tópico, você deve saber que, hoje em dia, muitos sistemas Linux são executados em hardware que suporta executáveis tanto 32, quanto de 64 bits. Assim, muitas bibliotecas são compiladas em versões 32 e de 64 bits. As versões de 64 bits são normalmente guardadas sob a árvore /lib64 no sistema de arquivos, enquanto as versões de 32 bits ficam normalmente na árvore tradicional /lib. Você provavelmente irá achar tanto /lib/libc-2.11.1.so quanto /lib64/libc-2.11.1.so em um típico sistema Linux de 64 bits. Estas duas bibliotecas permitem que programas C 32 e de 64 bits sejam executados em um sistema Linux de 64 bits.
Apesar de sabermos que um programa vinculado estaticamente provavelmente é grande, como dizemos se um programa é vinculado estaticamente? E se for vinculado dinamicamente, como sabemos de quais bibliotecas ele precisa? O comando Iddpode responder ambas as questões. Se você está executando um sistema como Debian ou Ubuntu, provavelmente não tem o executável sln, assim, recomenda-se verificar também o executável /sbin/ldconfig. A Listagem 2 mostra a saída do comandoldd para os executáveis ln e sln, assim como para o executável ldconfig. O exemplo é do sistema Fedora 12 de 64 bits (echidna). Para comparação, a saída de um antigo sistema Fedora 8 de 32 bits (pinguino) é exibida para /bin/ln.

Listagem 2. Saída de ldd para sln e ln.
[ian@echidna ~]$ #Fedora 12 64-bit
[ian@echidna ~]$ ldd /sbin/sln /sbin/ldconfig /bin/ln
/sbin/sln:
        not a dynamic executable
/sbin/ldconfig:
        not a dynamic executable
/bin/ln:
        linux-vdso.so.1 =>  (0x00007fff644af000)
        libc.so.6 => /lib64/libc.so.6 (0x00000037eb800000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037eb400000)

[ian@pinguino ~]$ # Fedora 8 32-bit
[ian@pinguino ~]$ ldd /bin/ln
        linux-gate.so.1 =>  (0x00110000)
        libc.so.6 => /lib/libc.so.6 (0x00a57000)
        /lib/ld-linux.so.2 (0x00a38000)

Devido ao fato de Idd dizer respeito a vínculos dinâmicos, ele nos informa que sln e ldconfig estão estaticamente vinculados dizendo que eles "não são executáveis dinâmicos", ao mesmo tempo em que nos informa o nome de três bibliotecas compartilhadas (linux-vdso.so.1, libc.so.6 e /lib64/ld-linux-x86-64.so.2) que o comando ln necessita. Observe que .so indica que eles são objetos compartilhados ou bibliotecas dinâmicas. Esta saída também ilustra três tipos diferentes de informações que você provavelmente verá.
linux-vdso.so.1
é o Objeto Compartilhado Dinâmico Virtual do Linux, que vamos discutir em breve. Você também poderá ver linux-gate.so.1, como no exemplo do Fedora 8.
libc.so.6
contém um ponteiro para /lib64/libc.so.6.
/lib64/ld-linux-x86-64.so.2
é o caminho absoluto para outra biblioteca.
Na Listagem 3, usamos o comando ls -l para mostrar que as últimas duas bibliotecas são, uma após a outra, links simbólicos para versões específicas das bibliotecas. O exemplo é do sistema Fedora 12 de 64 bits.

Listagem 3. Links simbólicos da biblioteca
[ian@echidna ~]$ ls -l /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx. 1 root root 12 2010-01-14 14:24 /lib64/ld-linux-x86-64.so.2 -> ld-2.11.1.so
lrwxrwxrwx. 1 root root 14 2010-01-14 14:24 /lib64/libc.so.6 -> libc-2.11.1.so

Antigamente, no começo dos processadores x86, as comunicações dos programas do usuário para os serviços do supervisor eram realizadas através da interrupção de um software. Conforme a velocidade dos processadores foi aumentando, isso resultou em um gargalo muito sério. Começando com os processadores Pentium® II, a Intel® introduziu uma instalação Fast System Call para aumentar a velocidade das chamadas do sistema usando instruções SYSENTER e SYSEXIT em vez de interrupções.
A biblioteca que você vê como linux-vdso.so.1 é uma biblioteca virtual ou um Objeto Compartilhado Dinâmico Virtual, que reside somente no espaço de endereço de cada programa. Sistemas antigos chamavam isto de linux-gate.so.1. Esta biblioteca virtual fornece a lógica necessária para permitir que os programas do usuário acessem funções do sistema através dos meios mais rápidos disponíveis no processador em particular, interrompendo ou, nos processadores mais modernos, com o Fast System Call.
A partir do precedente, você pode se surpreender ao aprender que /lib/ld-linux.so.2 e seu primo de 64 bits, /lib64/ld-linux-x86-64.so.2, se parecem com bibliotecas compartilhadas, mas que são, de fato, executáveis por si mesmo. Eles são o código responsável pelo carregamento dinâmico. Eles leem as informações do cabeçalho do executável, que está no formatoExecutable and Linking Format (ELF). Com base nessas informações, eles determinam quais bibliotecas são necessárias e quais precisam ser carregadas. Em seguida, eles executam vínculos dinâmicos para corrigir todos os ponteiros de endereço do executável e das bibliotecas carregadas, para que o programa seja executado.
A man page para o ld-linux.so também descreve o ld.so, que executa funções similares para o formato binário anterior a.out. A Listagem 4 mostra o uso da opção --list dos primos do ld-linux.so para exibir as mesmas informações do comando ln que mostramos com o comando ldd na Listagem 2.

Listagem 4. Usando ld-linux.so para exibir os requerimentos da biblioteca
[ian@echidna ~]$ /lib64/ld-linux-x86-64.so.2 --list /bin/ln
        linux-vdso.so.1 =>  (0x00007fffc9fff000)
        libc.so.6 => /lib64/libc.so.6 (0x00000037eb800000)
        /lib64/ld-linux-x86-64.so.2 (0x00000037eb400000)

[ian@pinguino ~]$ /lib/ld-linux.so.2 --list /bin/ln
        linux-gate.so.1 =>  (0x00110000)
        libc.so.6 => /lib/libc.so.6 (0x00a57000)
        /lib/ld-linux.so.2 (0x00a38000)

Observe que os endereços hexa podem ser diferentes entre as duas listagens. Eles também serão provavelmente diferentes se ldd for executado duas vezes.
Então, como o loader dinâmico sabe onde procurar os executáveis? Assim como muitas coisas no Linux, há um arquivo de configuração em /etc. De fato, há dois arquivos de configuração, /etc/ld/so/conf e /etc/ld.so.cache. A Listagem 5 mostra o conteúdo de /etc/ld.so.conf em um sistema Fedora 12 de 64 bits. Observe que /etc/ld.so.conf especifica que todos os arquivos .conf do subdiretório ld.so.conf.d devem ser incluídos. Sistemas mais antigos podem conter todas as entradas em /etc/ld/so/conf e não incluir entradas do diretório /etc/ld.so.conf.d. O conteúdo real de /etc/ld.so.conf ou do diretório /etc/ld.so.conf.d pode ser diferente no seu sistema.

Listagem 5. Conteúdo de /etc/ld.so.conf.
[ian@echidna ~]$ cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
[ian@echidna ~]$ ls /etc/ld.so.conf.d/*.conf
/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.19.fc12.x86_64.conf
/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.22.fc12.x86_64.conf
/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.3.fc12.x86_64.conf
/etc/ld.so.conf.d/mysql-x86_64.conf
/etc/ld.so.conf.d/qt-x86_64.conf
/etc/ld.so.conf.d/tix-x86_64.conf
/etc/ld.so.conf.d/xulrunner-64.conf

O carregamento dos programas deve ser rápido, assim, use o comando ldconfig para processar o arquivo ld.so.conf e todos os arquivos incluídos do ld.so.conf, assim como bibliotecas dos diretórios confiáveis, /lib e /usr/lib, e quaisquer outras na linha de comando. O comando ldconfig cria os links e o cache necessários para bibliotecas compartilhadas recentemente usadas em /etc/ld.so.cache. O loader dinâmico usa a informação em cache para localizar arquivos que devem ser carregados e vinculados dinamicamente. Se você alterar ld.so.conf (ou adicionar novos arquivos incluídos a ld.so.conf.d), será preciso executar o comando ldconfig (como root) para criar novamente o arquivo ld.so.cache.
Normalmente, você usa o comando ldconfig sem parâmetros para criar novamente ld.so.cache. Há vários outros parâmetros que podem ser especificados para substituir esse comportamento padrão. Como de costume, tente man ldconfig para mais informações. A Listagem 6 mostra o uso do parâmetro -p para exibir os conteúdos de ld.so.cache.

Listagem 6. Usando ldconfig para exibir ld.so.cache
[ian@lyrebird ian]$ /sbin/ldconfig -p | less
1602 libs found in cache `/etc/ld.so.cache'
        libzip.so.1 (libc6,x86-64) => /usr/lib64/libzip.so.1
        libz.so.1 (libc6,x86-64) => /lib64/libz.so.1
        libz.so (libc6,x86-64) => /usr/lib64/libz.so
        libx86.so.1 (libc6,x86-64) => /usr/lib64/libx86.so.1
        libx11globalcomm.so.1 (libc6,x86-64) => /usr/lib64/libx11globalcomm.so.1
        libxul.so (libc6,x86-64) => /usr/lib64/xulrunner-1.9.1/libxul.so
        libxtables.so.2 (libc6,x86-64) => /usr/lib64/libxtables.so.2
        libxslt.so.1 (libc6,x86-64) => /usr/lib64/libxslt.so.1
        libxslt.so (libc6,x86-64) => /usr/lib64/libxslt.so
        libxpcom.so (libc6,x86-64) => /usr/lib64/xulrunner-1.9.1/libxpcom.so
        libxml2.so.2 (libc6,x86-64) => /usr/lib64/libxml2.so.2
        libxml2.so (libc6,x86-64) => /usr/lib64/libxml2.so
       ...
        libABRTdUtils.so.0 (libc6,x86-64) => /usr/lib64/libABRTdUtils.so.0
        libABRTUtils.so.0 (libc6,x86-64) => /usr/lib64/libABRTUtils.so.0
        ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
        ld-linux-x86-64.so.2 (libc6,x86-64) => /lib64/ld-linux-x86-64.so.2

Caso você esteja executando um aplicativo mais antigo, que necessite de uma versão específica mais antiga de uma biblioteca compartilhada, ou se você está desenvolvendo uma nova biblioteca compartilhada ou versão de uma biblioteca compartilhada, é recomendado substituir os caminhos padrões de procura usados pelo loader. Isso pode também ser solicitado pelos scripts que usam bibliotecas compartilhadas específicas de produto, que podem estar instaladas na árvore /opt.
Do mesmo modo que é possível definir a variável PATH para especificar um caminho de procura para executáveis, é possível definir a variável LD_LIBRARY_PATH para uma lista de diretórios separados por sinais de dois pontos, onde se deve procurar por bibliotecas compartilhadas antes das bibliotecas do sistema especificadas em ld.so.cache. Por exemplo, você pode usar um comando como:
export LD_LIBRARY_PATH=/usr/lib/oldstuff:/opt/IBM/AgentController/lib


Não Fazer cache de determinados sites no SQUID


acl SITE dstdomain www.site.com.br
no_cache deny SITE
Ele não criará cache para os acesso feitos para o dominio www.site.com.br
Observe que no arquivo /var/log/squid/access.log, ele apresentará a seguinte mensagem “TCP_MISS” nas visitas consecutivas.

quarta-feira, 18 de abril de 2012

MANUAL DE PREVENÇÃO E SEGURANÇA DO USUÁRIO DO PABX

PROTEJA MELHOR OS PABXS DA SUA EMPRESA CONTRA FRAUDES E EVITE PREJUÍZOS


Para reduzir os riscos de invasão dos PABXs em sua empresa por pessoas mal-intencionadas, que utilizam as senhas iniciais dos equipamentos para realizar, além de outros malefícios, ligações para o exterior, reunimos neste manual, algumas informações e dicas que poderão auxiliá-lo na prevenção de fraudes e possíveis prejuízos.

Leia com atenção e siga as orientações para deixar sua empresa mais protegida.



O QUE É FRAUDE EM PABX?


As fraudes em PABX acontecem quando pessoas mal-intencionadas utilizam programas de computador chamados de “discadores”, que geram repetidas chamadas para todos os diferentes ramais de um PABX suscetível a invasões.

Quando descobrem um ramal desprotegido, que possibilite completar chamadas de longa distância (DDD ou   DDI), o ataque é feito usando as facilidades: siga-me, DISA1 e correio de voz. As ações contra o PABX
 podem gerar inúmeros prejuízos, originando chamadas indevidas através de seu PABX e ocasionando despesas indesejadas ao seu negócio.



COMO SE PREVENIR DA FRAUDE DE PABX?


ALGUMAS AÇÕES AJUDAM A PREVENIR FRAUDES:

• Implemente uma Política de Segurança na sua empresa e multiplique-a entre todos os colaboradores;
• Proteja as instalações do PABX e a rede de ramais;
• Programe o PABX para impedir ou controlar o recebimento de ligações a cobrar;
• Oriente a Central de Atendimento da sua empresa para não completar ligações externas;
• Determine restrições de destinos por ramais (local, móvel, DDD e DDI);
• Determine restrições de utilização do correio de voz;
• Altere periodicamente a senha do correio de voz;
• Iniba, via programação no PABX ou no correio de voz, transferências internas para outros ramais, bem como a origem de ligações externas a partir do correio de voz;
• Determine restrições de utilização de conferência;
• Determine restrições de acesso à facilidade DISA1;
• Altere periodicamente a senha do acesso DISA1;
• Altere as senhas sempre que ocorrer troca do quadro pessoal responsável pela manutenção e operação dos
 equipamentos PABX;
• Utilize mecanismos mais controlados de acesso remoto;
• Impeça a transferência de chamadas recebidas na Central de Atendimento da sua empresa para outros
departamentos internos;
• Dissemine entre seus colaboradores a cultura de que as informações de acesso e senha devem ser confidenciais;
• Coloque em prática auditorias periódicas no tráfego telefônico da sua empresa, e acompanhe os destinos das chamadas nacionais e internacionais, o tempo médio dessas chamadas e as ocorrências de ligações a cobrar, comparando com o perfil histórico dessas chamadas;
• Efetue a auditoria periódica das funcionalidades e restrições anteriormente aplicadas.

O QUE É ASTERISK?


Asterisk é um software livre de PABX IP de código aberto que permite que telefones convencionais e  terminais VoIP comuniquem-se entre si. Ele pode rodar na plataforma GNU/Linux, e implementa diversas
funcionalidades de um PABX moderno, além de suportar VoIP com vários protocolos.

Cada telefone é configurado como um ramal/extensão do PABX e a maior vantagem do Asterisk é que os
ramais/extensões não precisam estar na mesma localização física. Isso significa que você pode ter ramais/extensões espalhados pelo mundo, desde que estes estejam conectados à Internet e propriamente  configurados para se conectar com seu servidor.

Como em qualquer outro sistema PABX, o Asterisk possui recursos como: secretária eletrônica, conferências e distribuição de chamadas entre ramais, IVR (interactive voice response) ou URA (unidade de resposta  audível) e identificador de chamadas. Outra vantagem do Asterisk é que ele permite que você altere seu Plano de Discagem e outros Códigos de Chamada de acordo com sua necessidade.


Por tratar-se de um sistema informatizado, o mesmo está exposto a diversos tipos de ataques que podem
ser realizados com o objetivo de tentar comprometer alguns dos três fatores da segurança da informação:
disponibilidade, integridade e confidencialidade. Assim, além do acesso normal às facilidades do PABX, a
segurança da infraestrutura computacional e de redes poderá ser também afetada.


DOS (DENIAL OF SERVICE)
Ataques de navegação de serviço acontecem quando o invasor tenta fazer com que o serviço ou o servidor pare de responder devido a um excesso de solicitações enviadas a ele. Um dos tipos de ataque de navegação de serviço é o Net Flood.

NET FLOOD
Esse tipo de ataque acontece quando invasores tentam saturar a capacidade de conexão de rede de um determinado sistema. Por exemplo: caso o link de dados de um servidor seja de 1 Mbps e sejam enviados pacotes à velocidade de 10 Mbps, esse link ficará saturado e haverá grandes perdas de informações. Dentre os diversos ataques do tipo Net Flood, podemos citar:





• Ping Flood: acontece quando o invasor tenta enviar uma grande quantidade de mensagens ICMP de requisição de eco, com o objetivo de saturar o link de dados da vítima. Esse é um dos mais simples ataques do tipo Net Flood.  Alguns sistemas operacionais, como, por exemplo, o Linux, já possuem uma ferramenta
nativa que pode realizar esse ataque.

• UDP Flood: neste caso, o invasor envia uma grande quantidade de pacotes UDP com o objetivo de saturar o link de dados da vítima.

MAC FLOODING
MAC Flooding é uma técnica utilizada por invasores para tentar se aproveitar da limitação na quantidade de números diferentes de endereços MAC que um switch2 é capaz de armazenar. Essa técnica é realizada quando são enviados diversos pacotes com diferentes endereços MAC, fazendo com que sua capacidade chegue ao limite. Dependendo do switch2, ele poderá entrar no modo de operação failopen, e, neste caso, funcionar como um hub3. Como consequência, a rede fica mais lenta, já que todos os pacotes estarão sendo enviados para todos os equipamentos ligados ao switch2. Dessa forma, caso seja colocado um sniffer4 na
rede, ele será capaz de capturar todo o tráfego, comprometendo a confidencialidade, caso a informação não esteja cifrada.

ARP SPOOFING
ARP Spoofing, também conhecido como ARP Poisoning, é uma técnica utilizada para enviar mensagens ARP falsas para o switch2. Essas mensagens contêm endereços MAC falsos que confundem os equipamentos de rede, como por exemplo, os switches2. Dessa forma, informações com destino a uma determinada interface do switch2 podem ser enviadas para outra interface, que pode analisar as informações e reenviar os pacotes  para o destino original, comprometendo a confidencialidade da informação, caso a mesma não esteja cifrada.



COMO SE PREVENIR A UM ATAQUE ASTERISK?



• Basta restringir o acesso ao manager. É uma ferramenta muito poderosa que pode permitir a criação de aplicações bastante sofisticadas envolvendo o Asterisk. Devido a toda sua flexibilidade, o mesmo permite a execução de diversas modificações no Asterisk. Portanto, é interessante restringir o acesso ao manager a partir de endereços IPs conhecidos e utilizar senhas complexas para os usuários do manager;

• É muito comum utilizar como usuário SIP o número do ramal, entretanto, tal prática é desaconselhável, pois
permite ao fraudador descobrir facilmente quem são os usuários SIP e com isso ele já tem meio caminho
andado;

• Limite o número de ligações simultâneas permitidas para cada usuário, pois em caso de um ataque bem-sucedido o estrago será limitado;

• Cuidado com os seus contextos. Não permita ligações para números tarifáveis a partir de qualquer contexto. Limite esse tipo de ligações a contextos que não são acessíveis externamente.

Os pontos anteriores lidam com os principais problemas relacionados ao SIP em uma instalação típica de Asterisk. Como vimos, existem diversas ferramentas disponíveis para tornar o Asterisk mais seguro, desde ferramentas técnicas, passando pela configuração do sip.conf corretamente, até ferramentas administrativas de usuários e senhas complexas. É importante também a atualização de novas versões do Asterisk.


Fonte: GVT

terça-feira, 17 de abril de 2012

ModSecurity: Open Source Web Application Firewall - Segurança no Apache

ModSecurity Instalação e Configuração


O ModSecurity é um firewall de aplicação de código livre que roda como um módulo do servidor Web Apache e possui versões para Linux e Windows. O firewall de aplicação, também conhecido como WAF (Web Application Firewall) tem por objetivo bloquear diversos tipos de ataques, como o Cross-Site Scripting (XSS), SQL Injection, Command Injection, ASP e PHP Injection, Trojans & Backdoors Detection, dentre outros, que variam de acordo com as regras existentes.

Apesar do conjunto de regras pre-existentes no ModSecurity ser funcional, a OWASP mantém um projeto que possui um conjunto de regras mais elaboradas e atualizadas, o ModSecurity Core Rule Set Project. Também é possível fazer o download de outras regras na Internet, sites de segurança ou ainda criar suas próprias regras e alterar as já existentes.

Nesse tutorial será descrito como efetuar uma completa instalação da versão 2.5.12 do Modsecurity de modo que não haja erros durante a instalação.

Para instalar o ModSecurity, você deve ter o Apache instalado. Se não tiver, você deve instalá-lo, conforme a seguir:

# sudo apt-get –f install apache2

É importante configurar a opção -f no apt-get para o aplicativo já procurar e tentar instalar as possíveis dependências do Apache2. Depois verifique se o Apache está rodando corretamente com o comando:

# /etc/init.d/apache2 status

E inicie o serviço, caso não esteja rodando:

# /etc/init.d/apache2 start

Agora, vamos criar uma página php vulnerável para podermos testar o comportamento da aplicação antes e o depois do ModSecurity.

# vi /var/www/index.php



Para salvar e sair do vi: (ESC : x)

Agora, faça a requisição para a página criada usando seu navegado, curl ou links, com a seguinte sintaxe:

http://localhost/index.php?secret_file=/etc/passwd


Observe que ao invés de mostrar o conteúdo da página, a requisição traz o conteúdo do arquivo de senhas (passwd), isso porque no arquivo que criamos inserimos propositalmente uma vulnerabilidade que permite apontar para qualquer arquivo do sistema operacional por meio da variável “secret_file”.

Agora, vamos partir para a instalação do ModSecurity para ver se a mesma vulnerabilidade poderá ser explorada com o Firewall de aplicação instalado:


Instalação do ModSecurity

Agora que temos o Apache rodando, vamos fazer o download do ModSecurity.

# wget http://www.modsecurity.org/download/modsecurity-apache_2.5.12.tar.gz

Descompacte o arquivo e entre no diretório criado:

# tar zxvf modsecurity-apache_2.5.12.tar.gz

# cd modsecurity-apache_2.5.12/apache2

ATENÇÃO: Essa parte é muito importante, pois o ModSecurity necessita de uma ferramenta, o apxs ou apxs2 (APache eXtension Tool) para sua perfeita instalação. Antes de prosseguir, verifique se ele existe:

# find / -name apxs*

Se já existir ótimo, já é possível começar a instalar o ModSecurity. Caso não exista, teremos que instalar alguns pacotes que trazem o apxs:

# sudo apt-get -f install libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev

Agora já podemos instalar o ModSecurity!

# sudo ./configure && make && make install

Após a instalação, deverá aparecer a seguinte mensagem:

See any operating system documentation about shared libraries for

more information, such as the ld(1) and ld.so(8) manual pages.

----------------------------------------------------------------------

Altere a permissão do arquivo abaixo e reinicie o sistema.

# chmod 644 /usr/lib/apache2/modules/mod_security2.so

Quando o sistema subir, iremos alterar o arquivo de configuração de módulos do Apache para carregar os módulos do ModSecurity:

# sudo vi /etc/apache2/mods-available/mod-security2.load

E adicionamos as seguintes linhas:

LoadFile /usr/lib/libxml2.so

LoadFile /usr/lib/liblua5.1.so.0

LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

Salve e feche o arquivo.

Agora, vamos ativar os módulos adicionados:

# sudo a2enmod mod-security2

# sudo a2enmod unique_id

Deve aparecer a seguinte mensagem para ambos os comandos, mas ainda não há necessidade de reiniciar o serviço.

Run '/etc/init.d/apache2 restart' to activate new configuration!


Configuração

Vamos configurar o ModSecurity:

# sudo vi /etc/apache2/conf.d/mod-security2.conf

# Include /etc/modsecurity2/*.conf

Salve e feche o arquivo.

Vamos criar um diretório para o ModSecurity e copiar as regras de detecção para o diretório criado:

# sudo mkdir /etc/modsecurity2

# sudo cp modsecurity-apache_2.5.12/rules/*.conf /etc/modsecurity2/

# sudo cp rules/base_rules/*.conf /etc/modsecurity2/

Precisamos criar também o diretório e arquivos de log e debug:

# mkdir /var/log/modsecurity2

# touch /var/log/modsecurity2/modsec_audit.log

# touch /var/log/modsecurity2/modsec_debug.log

E atualizar a localização desses arquivos no arquivo de configuração:

#sudo vi /etc/modsecurity2/modsecurity_crs_10_config.conf

Adicione o seguinte script no meio do arquivo.

#++++ Configure ModSecurity +++++

SecDebugLog /var/log/modsecurity2/modsec_debug.log

SecAuditLog /var/log/modsecurity2/modsec_audit.log

Salve e feche o arquivo.

Agora, vamos verificar se a configuração do Apache está correta com o comando:

# sudo apache2ctl configtest

Deverá retornar a mensagem “Syntax OK”

E, por último, vamos reiniciar o Apache:

# sudo /etc/init.d/apache2 restart

Verifique se o ModSecurity está rodando junto com o Apache:

# sudo cat /var/log/apache2/error.log | grep ModSecurity

Pronto! Se aparecer a mensagem abaixo seu ModSecurity está rodando!

[Mon Apr 26 08:47:07 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured

Agora, vamos realizar o teste novamente para ver se conseguimos explorar a vulnerabilidade testada anteriormente.



Como podemos observar pela mensagem retornada “403 Forbidden – You don’t have permission to Access /índex.php on this server”, o ModSecurity bloqueou o acesso ao arquivo índex.php, uma vez que por trás dele havia uma função maliciosa (ler o arquivo de senhas “passwd”).

Este é só um exemplo de como um firewall de aplicação pode ajudar a “tapar buracos” de uma aplicação mal desenvolvida, enquanto se providencia um código seguro, com os devidos controles de segurança e livre de vulnerabilidades.

Isso é tudo pessoal, até a próxima!