Apache
Protegendo o Mod Cluster Manager
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:
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
Proteja-se Contra Ataque de Negação de Serviço com Mod Evasive
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:
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
- http://www.atomicorp.com/wiki/index.php/Mod_evasive
- https://library.linode.com/web-servers/apache/mod-evasive
Repositório:
Configurando Apache Web Server e Mod Proxy com TorqueBox 2.x
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
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:
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
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
Instalando SVN no CentOS 5.6
SVN é um sistema de controle de versão open source, que permite o controle de projetos através da criação de repositórios especificos. Hoje vamos aprender como instalá-lo, e criar os repositórios iniciais.
Quando solicitamos ao yum instalar o modulo “mod_dav_svn” o yum procurará a dependências que serão os serviços: httpd(apache) e subversion.
yum install mod_dav_svn
Após o fim da instalação, vá até cd /etc/httpd/conf.d/, e crie o arquivo subversion.conf, adicionando o seguinte conteúdo:
#Primeiro Repositorio <Location /nomerepositorio1> DAV svn SVNPath /var/www/svn/nomerepositorio1 AuthType Basic AuthName "Repositorio Exemplo1" AuthUserFile /etc/svn-auth-conf AuthzSVNAccessFile /etc/svn-acl-conf Require valid-user </Location> #Segundo Repositorio <Location /nomerepositorio2> DAV svn SVNPath /var/www/svn/nomerepositorio2 AuthType Basic AuthName "Repositorio Exemplo2" AuthUserFile /etc/svn-auth-conf AuthzSVNAccessFile /etc/svn-acl-conf Require valid-user </Location>
As tags acima realizam a configuração inicial nos repositórios, como configuração de caminho ( SVNPath ), tipo de autenticação ( AuthType ) e arquivo de autenticação ( AuthUserFile ).
Como podemos ver a tag AuthUserFile, aponta para o arquivo a onde estão armazenadas as credenciais de acesso aos repositórios.
Para adicionar usuários, digite os comando abaixo:
htpasswd -cm /etc/svn-auth-conf eusouadmin ( Adiciona o Usuário Master/Admin) htpasswd -m /etc/svn-auth-conf eusounormal ( Adiciona um Simples Usuário: desenvolver, dba, etc ) htpasswd -m /etc/svn-auth-conf eusounormaldba
Se desejar remover o usuário criado digite:
htpasswd -D /etc/svn-auth-conf nomedousuairo ( Remove Usuário Criado )
Agora vamos criar o repositório, que armazenará os nossos projetos. Navegue até cd /var/www/ e execute os seguintes comandos:
mkdir svn cd svn svnadmin create nomerepositorio1 chown -R apache.apache nomerepositorio1 svnadmin create nomerepositorio2 chown -R apache.apache nomerepositorio2
service httpd restart
Pronto, os repositórios estão criados, agora devemos criar a politíca inicial de acesso.
Crie o arquivo /etc/svn-acl-conf, e adicione o conteúdo abaixo:
[groups] admin = eusouadmin developers =eusounormal dba = eusounormaldba [/] @developers = rw @dba = r [/nomerepositorio1] @developers = rw @dba = r [/nomerepositorio2] @developers = r @dba = rw
Bom é isso, salve o arquivo reinicie o Apache . Lembre-se de Liberar o Firewall do CentOS para aceitar conexões HTTP, você poderá visualizar os repositórios e seus respectivos arquivos utilizando o browser.
Aqui no trabalho, nós utilizamos o SVN no CentOS em conjunto com o Eclipse e o plugin http://subclipse.tigris.org.
Espera que seja util
Abraços!
JBossDivers 