Apache

Autenticação do Mod Cluster Manager no Active Directory

Postado em Atualizado em

Olá,

No post https://jbossdivers.wordpress.com/2013/11/11/protegendo-o-mod-cluster-manager/ aprendemos a configurar autenticação baseada em arquivo. O Marco Simões  realizou a configuração para autenticação do AD e me enviou para que eu pudesse colocar aqui. Segue Abaixo o exemplo:


<Location /mod_cluster_manager>
    SetHandler mod_cluster-manager
    Order deny,allow
    Allow from all

    # Usar credenciais para listar usuário no AD
    AuthLDAPBindDN "DefaultUserForLdap@example.com"
    AuthLDAPBindPassword "mySecret"
    # URL para localizar usuários no AD
    AuthLDAPURL "ldap://192.168.10.22:389/ou=Accounts,dc=example,dc=com?sAMAccountName?sub?(objectClass=*)"

    AuthType Basic
    AuthName "Use suas credenciais do AD para logar"
    AuthBasicProvider ldap
    require valid-user

</Location>

Abraços

Protegendo o Mod Cluster Manager

Postado em Atualizado em

Olá amigos,

Atualmente o Mod Cluster é um dos principais módulos para realização de balanceamento de carga em ambientes JBoss. Quando configuramos o Mod Cluster com o Apache Web Server “ganhamos” de presente um pequeno gerenciador para habilitar/desabilitar os contextos, grupos e mais algumas outras configurações. Veja abaixo:

mcm

Perceba que o painel está totalmente vulnerável a um ataque. O atacante poderia facilmente desabilitar alguns contextos ou mesmo grupos de servidores causando instabilidade em todo ambiente.

Uma forma simples de proteger esse recurso é utilizando a autenticação basic baseada em arquivos oferecido pelo próprio Apache.  Basicamente os atributos AuthType e AuthUserFile devem ser utilizados.

Por exemplo, adicione um usuário chamado admin:

htpasswd -c /etc/modclusterpassword admin

No arquivo de configuração do Mod Cluster adicione os atributos AuthType e AuthUserFile como abaixo:

<Location /mod_cluster_manager>
SetHandler mod_cluster-manager
Order deny,allow
Deny from all
Allow from 127.0.0.1
AuthType Basic
AuthName "Mod Cluster Manager"
AuthUserFile /etc/modclusterpassword
Require user admin
</Location>

Reinicie o Apache e Pronto!!! Agora o ambiente está um pouco mais protegido 🙂

Eu não testei mas acredito que essa autenticação também possa ser realizada utilizando o Active Directory com módulos específicos do Apache.

Grande Abraço,

Mauricio Magnani

Ref: http://httpd.apache.org/docs/2.0/mod/mod_auth.html

Proteja-se Contra Ataque de Negação de Serviço com Mod Evasive

Postado em Atualizado em

en_t_dds_sh

Olá,

Mod_evasive é um módulo para Apache Web Server que previne ataques do tipo DDoS.  Ele é projetado para “barrar” conexões HTTP e HTTPS quando as mesmas ultrapassam os limites preestabelecidos.  Ataques de negação de serviço são cada vez mais comuns acredito que pela facilidade da realização de um ataque básico. O ataque baseia-se em executar no alvo  enormes quantidades de tráfego, em uma tentativa de deixá-lo inacessível.   Normalmente utilizamos o Apache em conjunto com o JBoss o que torna essa configuração essencial para termos um ambiente mais seguro e menos sujeito a ataques desse tipo.

Uma maneira rápida e simples de verificar se o servidor está sofrendo um ataque DDoS é verificar o número de conexões ativas que estão abertas no servidor. Se estiver acima de 500 é um indício de que um ataque pode estar ocorrendo. Para visualizar essas conexões execute:

 netstat -n | grep :80 |wc -l

Para instalar o Apache Web Server execute:

 sudo yum install httpd -y

Inicie o Apache:

 sudo service httpd start

Para ter certeza de que o Apache está realmente iniciado basta abrir o navegador e acessar o IP do servidor. O Apache estará respondendo por padrão na porta 80:

Apache

Agora precisamos “inundar” o nosso apache com requests. Para realização dos testes vamos utilziar o T50.

O T50 é uma ferramenta  para teste de invasão que permite a realização de ataques DoS(denial of service). Essa ferramenta foi criada  pelo brasileiro Nelson Brito.

Site oficial para Download do T50 http://t50.sourceforge.net.

Realize o download do arquivo t50-5.4.1-rc1.tgz ou siga os procedimentos abaixo:

 cd /tmp/
 wget http://downloads.sourceforge.net/project/t50/t50-5.4.1/t50-5.4.1-rc1.tgz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Ft50%2Ffiles%2Ft50-5.4.1%2F&ts=1370312029&use_mirror=ufpr
 tar -vxzf t50-5.4.1-rc1.tgz
 cd t50-5.4.1-rc1/src
 make -W Makefile

Agora o T50 está pronto para os ataques.

Execute o seguinte comando utilizando o IP do alvo que em nosso caso é o IP onde está o Apache Web Server:

 sudo ./t50 190.199.80.239 --flood --turbo -S --dport 80
 T50 is RFC 1700, RFC 1918 and RFC 3330 compliance

Perceba que um  erro foi gerado pois o T50 só permite ataques na rede interna. Para remover essa limitação edite o arquivo /tmp/t50-5.4.1-rc1/src/check.c e comente o bloco de código das linhas 67 até 112.  Para comentar utilize /* */.

Compile novamente:

 pwd
 /tmp/t50-5.4.1-rc1/src
 make -W Makefile

Execute novamente o T50:

 sudo ./t50 190.199.80.239 --flood --turbo -S --dport 80
 entering in flood mode...
 activating turbo...
 T50 5.4.1-rc1 successfully launched on Jun  3rd 2013 20:47:55

No servidor onde está o Apache execute o comando para verificar as conexões ativas e perceba o nível elevado  de conexões em nosso servidor devido ao ataque:

while true; do netstat -n | grep :80 |wc -l; sleep 1; done
0
0
33
42
100
100
128
175
228
231
228
296
359
413
413
413
472
472
472
472
472
474
474
474
474
474
474
474
474
474
474
474
474
485
505
543
541
538
540
540
539

Se tentar o acessar o Apache utilizando um navegador irá perceber a lentidão na resposta causada por esse ataque.

Para contornar essa situação vamos utilizar o Mod_evasive.  Para instalar execute:

 sudo  yum install mod_evasive -y

Ao ser instalado um arquivo em  /etc/httpd/conf.d/mod_evasive.conf é criado com a configuração padrão.

Execute novamente o ataque:

 sudo ./t50 190.199.80.239 --flood --turbo -S --dport 80
 entering in flood mode...
 activating turbo...
 T50 5.4.1-rc1 successfully launched on Jun  3rd 2013 20:54:43

No servidor execute o comando para verificar as conexões ativas e veja que se manteve mais estável e em determinado momentos as conexões começaram a ser negadas:

while true; do netstat -n | grep :80 |wc -l; sleep 1; done
0
0
0
0
17
95
95
95
123
188
226
273
270
284
327
374
372
394
442
446
446
446
448
448
448
448
448
448
450
450
450
450
450
450
450
450
450
450
450
450
296
296
299
260
239
239
266
218
191

As configurações default podem ser melhoradas! Existe muita coisa ai na web sobre esse assunto 🙂

Espero que seja útil!

Abraços 🙂

Links

Repositório:

Configurando Apache Web Server e Mod Proxy com TorqueBox 2.x

Postado em

Olá amigos,

Continuando o post anterior em que nós aprendemos a instalar o TorqueBox e a criar uma aplicação utilizando Ruby on Rails, hoje vamos aprender como deployar a aplicação criada nesse post no context root “/” e como integrar tudo isso ao Apache Web Server tornando o nosso ambiente  um pouco mais profissional.

Atualmente a nós estamos acessando a nossa aplicação utilizando o seguinte formato: http://ip(servidor):porta/contexto/recurso

Então o objetivo aqui é configurar a nossa aplicação para que seja acessada da seguinte form: http://ip(servidor)/recurso

No post anterior nós realizamos o deploy da seguinte maneira:

jruby -S rake torquebox:deploy['/store']

Então realize o undeploy da aplicação de maneira similar:

jruby -S rake torquebox:undeploy['/store']

Por default torquebox:deploy já publica a aplicação no context root ou seja respondendo no “/”. Então o primeiro passo é realizar o deploy da aplicação sem utilizar o contexto. Veja:

jruby -S rake torquebox:deploy

Agora a nossa aplicação está respondendo no context root: http://ip(servidor):porta/recurso .

Pronto! Nos livramos do contexto agora só falta a porta.

Desde de o Apache 1.3 existe suporte opcional para o módulo chamado mod_proxy.so. Esse módulo  configura o Apache para agir como um servidor proxy, transmitindo as requisições para outras aplicações web como JBoss, Jetty e Tomcat.

Para utilizar o  mod_proxy é bem simples. Verifique se o módulo já está configurado no httpd.conf:

LoadModule proxy_module modules/mod_proxy.so

Ainda no httpd.conf , adicione as seguintes configurações:

#192.168.0.158 --> Ip do Servidor TorqueBox no Windows
ProxyPass / http://192.168.0.158:8080/
ProxyPassReverse / http://192.168.0.158:8080/

Reinicie o Apache e tente acessar a aplicação apenas com o IP ou DNS do servidor Linux em que o Apache o Mod Proxy estão instalados. Não se esqueça de iniciar o TorqueBox com a opção -Djboss.bind.address=0.0.0.0 , caso contrário o Apache não conseguirá se comunicar com o JBoss.

Agora nossa aplicação está respondendo no seguinte formato:  http://ip(servidor)/recurso

Para brincar um pouquinho o servidor de proxy Apache está no CentOS 6.3 e o TorqueBox está no Windows 7. Pelos meus testes tudo funcionou corretamente.

Espero que tenha ajudado.

Abraços

Configurando um Proxy Reverso / Balanceador de Carga com Apache e HTTPS no JBoss AS 7.1.2 – Parte 1

Postado em Atualizado em

Olá amigos,

O post de hoje será dividido em 3 partes, hoje então vamos realizar uma introdução sobre o assunto.

No post de hoje vamos falar de um assunto que pode ser bem útil para pessoas que administram ambientes JBoss, vamos aprender a configurar um ambiente com Apache, JBoss e HTTPS. Então vamos lá.

Antes de tudo vamos fazer algumas considerações. Mas vou logo dizendo que não sou o especialista em Web Server mas me esforço par ter um bom entendimento.

Quando iniciei os meus estudos com JBoss eu tinha algumas dúvidas quanto ao uso do HTTPS, mais ou menos assim: Devo colocar os certificados para tráfego seguro no JBoss ou no Apache?

Depois de estudar um tempo eu aprendi que em Sistemas Operacionais Linux/Unix portas abaixo de 1024 só podem ser utilizadas pelo usuário root. Então se eu quiser utilizar o JBoss na porta 443 (http protocol over TLS/SSL) eu tenho que iniciar o JBoss como root, quebrando totalmente a segurança do meu ambiente. Você que saber o por que? Veja o link abaixo:

Hacking-JBoss-AS

Então não é recomendado deixar o JBoss exposto diretamente na Web. Em ambientes profissionais sempre é utilizado um mecanismo chamado de proxy reverso. Ele realmente funciona como um proxy só que reverso ( gênio 😛 )  pois ele filtra todas as requisições da Web para depois encaminhar para o servidor de aplicação. Eu já vi ambientes em que existia um Apache na frente como proxy reverso  e o JBoss ficava atrás em uma DMZ. Na minha opnião é um pouco confuso para quem está iniciando nesse mundo. Eu mesmo posso estar falando um monte de bobagem aqui… se estiver please me corrigam 😀

Depois desse papinho todo ai, vamos ao que interessa.  Voltando ao assunto dos certificados, a maioria dos ambientes que eu já vi até hoje utilizava o Apache com mod_ssl e depois encaminhava as requisições utilizando (no caso de uma migração do mod_jk) mod_proxy_ajp ou mod_proxy_http.

Então o nosso ambiente é o seguinte:

A imagem acima foi “roubada” no google. A url do roubo está na própria imagem 😛 só a parte do Postgresql  que nao vamos abordar mas acredito que  essa banco também ofereça um módulo para encriptação do tráfego utilizando SSL.

Na próxima  parte vamos aprender a instalar o Apache e o mod_ssl e aprender também a gerar os certificado auto assinados.
Até a próxima parte.

Abraços

Resolvendo o Erro: mod_jk.so: wrong ELF class: ELFCLASS32

Postado em


Olá amigos,

Na semana passada precisei criar um load balance com JBoss AS 7.1.2 (JBoss EAP 6) + Apache 2.2.x para o ambiente em que estou trabalhando.
Quando terminei de fazer todas configurações no servidor iniciei o Apache que retornou o seguinte erro:

Starting httpd: httpd: Syntax error on line 1069 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_jk.so into server: /etc/httpd/modules/mod_jk.so: wrong ELF class: ELFCLASS32

Bom sei que é bem simples identificar isso mas fica a dica, por um pequeno descuido acabei utilizando o connector web server mod_jk da arquitetura i386. Para resolver esse problema, basta apenas remover a lib i386 e utilizar da x86_64.

Espero que tenha ajudado.

Abraços