Apache com mod_cluster e SSL com JBoss7

[adrianoschmidt]

Olá,

Estou com um ambiente assim:

Apache com mod_cluster e 3 JBoss AS 7.1.3 (um domain controller e dois host controller)

Como faço para utilizar SSL no meu apache?

Vocês tem algum material que ajude?

Abraço!

Adriano Schmidt

http://www.localhost8080.com.br

[mauriciomag]

E ai Adriano...

Acho que com essa deve fechar o ambiente quase que por completo...

Chegamos em um momento de decisão rsrs   Como voce deve saber utilizar SSL causa uma queda na performance pelo fato da encriptação dos dados.

Atualmente voce tem o seguinte cenário:

O dados estão trafegando sobre HTTP sem nenhuma criptografia podendo ser interceptado fácilmente.

Como eu disse voce terá que tomar uma decisão nesse momento. Vale a pena encriptar o tráfego entre o  Balancer (Apache) e as Instâncias JBoss?  Eu digo isso pois já vamos ter o primeir overhead entre o Cleinte e o Balancer:

Seria mais viável na minha opnião utilizar SSL somente entre o client e o Balancer(Apache) e depois protoger a rede na comunicação entre o Domain Controller e os Host Controllers. Novamente quero repetir que  vai ocorrer perda de performance já que o tráfego será encriptado.

Cenário 1:

Cliente<--- SSL---> Balancer <---AJP ---> Instâncias JBoss

Cenário 2:

Cliente<--- SSL---> Balancer <---SSL---> Instâncias JBoss

O que acha?

Abraço

-- Mauricio Magnani

[adrianoschmidt]

Não sei se eu entendi muito bem..

Vou te dizer como está hoje...

O cliente acessa o site http://www.siteexemplo.com e aí cai no apache.. caindo no apache ele é redirecionado para o ssl e depois para a aplicação em si...

Porém, hoje está usando só o apache e só um jboss... agora vou colocar o ambiente com apache com mod_cluster e vários jboss.. e gostaria de manter a mesma segurança existente...

Consegui explicar direito minha situação?

Att,

Adriano

[mauriciomag]

Sim é isso que quis dizer...

Atualmente você tem isso:

Cliente<--- HTTPS---> Balancer <---AJP ou HTTP---> Instância JBoss ( Atual )

Eu estou propondo isso:

Cliente<--- HTTPS---> Balancer <--- AJP ---> Instância JBoss  ( O que eu recomendo )

Mas pode ser feito isso se for necessário encriptar o tráfego entre o Apache e o JBoss:

Cliente<--- HTTPS---> Balancer <--- SSL---> Instância JBoss ( O mais seguro, mas com mais perda de performance -- Não recomendo na sua situação)

Sacou?! rsrs

Abraços

[adrianoschmidt]

Hoje o http.conf tem isso:

<VirtualHost *:80>

   ServerName siteexemplo.com.br

   RedirectPermanent / https://siteexemplo.com.br

   UseCanonicalName Off

</VirtualHost>

e no ssl.conf

<VirtualHost *:443>

   ServerName siteexemplo.com.br

   DocumentRoot /var/www/html/siteexemplo

[.]

</VirtualHost>

ou seja.. o http redireciona para o ssl que redireciona para a aplicação... caso o usuário digite diretamente no browser https://siteexemplo.com.br ele já vai pro sslconf e depois pra aplicação...

Att,

Adriano

[adrianoschmidt]

Entendi... Se o que eu tenho é o você disse, quero fazer isso que você propôs.. pois vai manter a mesma segurança que tem atualmente..

Atualmente você tem isso:

Cliente<--- HTTP---> Balancer <---AJP ou HTTP---> Instância JBoss ( Atual )

Eu estou propondo isso:

Cliente<--- HTTPS---> Balancer <--- AJP ---> Instância JBoss  ( O que eu recomendo )

Tenho uma dúvida sobre esse HTTPS ali... eu não posso forçar o cliente a digitar https no browser.. isso não vai acontecer neh?

Att,

Adriano

[mauriciomag]

A OK Eu até corrigi o meu desenho voce já tem o SSL então.... vai ficar a mesma coisa praticamente...  vou te ensinar a gerar os certificados.. saca só:

Vamos gerar os certificado para ser utilizado no Apache Web Server que é o nosso Balancer.  Pelo fato de  utilizar o SSL/HTTPS devemos instalar o Mod SSL. Para isso, execute :

yum install mod_ssl

Vamos utilizar o openssl para geração dos certificados. Instale os pacotes necessários:

yum install openssl ca-certificates

Para melhor organização crie  um diretório dentro de /etc/ssl com o nome de server-certs:

mkdir /etc/ssl/server-certs

O primeiro passo é gerar uma chave privada.  Navegue até o diretório /etc/ssl/server-certs  e execute:

openssl genrsa -des3 -out my-server.key 2048

A chave gerada está encriptada e protegida por uma senha ou seja se nós utilizarmos essa chave no Apache, toda vez que reiniciarmos o serviço essa senha será solicitada causando alguns transtornos. Para solucionarmos essa questão podemos gerar uma chave "desprotegida" baseada na chave privada  my-server.key que não irá solicitar qualquer tipo de senha.

Execute comando abaixo para que a chave seja gerada:

openssl rsa -in my-server.key -out my-server.key.public

Tenha muito cuidado com a chave privada my-server.key, guarde-a em um local seguro e que seja acessível somente pelo root.

O próximo passo é gerar o Certificate Signing Request. Execute o comando abaixo:

openssl req -new -key my-server.key -out my-server.csr

O arquivo my-server.crt deveria ser enviado para a autoridade certificadora, que devolveria o certificado assinado. Neste caso, vamos utilizá-lo para criar um certificado auto assinado válido por 365 dias. Para isso execute:

openssl x509 -req -days 365 -in my-server.csr -signkey my-server.key -out my-server.cer

A criação dos certificados está concluída. Foram gerado os seguintes arquivos:

• my-server.key – Chave privada.
• my-server.key.public -  Chave sem password.
• my-server.csr – Pedido de assinatura do certificado.
• my-server.cer – Certificado auto assinado.

Edite o arquivo  vim /etc/httpd/conf.d/mod_cluster.conf  e deixe-o como  abaixo:

<VirtualHost ipapache:443>

SSLEngine on
SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
SSLVerifyDepth 10
SSLCertificateFile /etc/ssl/server-certs/my-server.cer
SSLCertificateKeyFile /etc/ssl/server-certs/my-server.key.public

<Directory />
Order deny,allow
Allow from all
</Directory>

KeepAliveTimeout 60
ManagerBalancerName mycluster
MaxKeepAliveRequests 0
ServerAdvertise On

EnableMCPMReceive On

</VirtualHost>

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

Reinicie o Apache e acesse  por exemplo https://ipapache/mod_cluster-manager e observe que agora os dados já trafegam encriptados.

Pronto Brother

Espero que tenha ajudado.

Abraços

--Mauricio Magnani

[mauriciomag]

Tenho uma dúvida sobre esse HTTPS ali... eu não posso forçar o cliente a digitar https no browser.. isso não vai acontecer neh?

Do jeito que está ai vai sim....

Eu não testei isso mas tenta algo do tipo:

<VirtualHost *:80>

   ServerName siteexemplo.com.br

   RedirectPermanent / https://siteexemplo.com.br

   UseCanonicalName Off

</VirtualHost>

<VirtualHost ipapache:443>

ServerName siteexemplo.com.br

DocumentRoot /var/www/html/siteexemplo

SSLEngine on

SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL

SSLVerifyDepth 10

SSLCertificateFile /etc/ssl/server-certs/my-server.cer

SSLCertificateKeyFile /etc/ssl/server-certs/my-server.key.public

<Directory />

Order deny,allow

Allow from all

</Directory>

KeepAliveTimeout 60

ManagerBalancerName mycluster

MaxKeepAliveRequests 0

ServerAdvertise On

EnableMCPMReceive On

</VirtualHost>

Me diz ai se funcionou assim..

Abs

[adrianoschmidt]

Deu tudo certo Mauricio!!!

Mais uma vez obrigado!! Acho q já te disse uns 39472397293 obrigados nessa semana hahah

Abração!!!

Adriano Schmidt

[mauriciomag]

E ai Adriano,

Fico feliz que tenha dado tudo certo 

Cara eu gosto muito de compartilhar o conhecimento pois cada vez que ajudo eu também aprendo...   pode contar sempre comigo por aqui!

Se eu tiver o conhecimento sempre vou passar pode ter certeza.

Grande Abraço

--Mauricio Magnani

[adrianoschmidt]

Fala Maurício,

Eu tinha feito testes bem básicos com o SSL e aí funcionou.

Eu fiz a porta 80 apontar para a 443, e a 443 apontava para o mod_cluster-manager.. show de bola!!

<VirtualHost *:80>

   ServerName test002

   RedirectPermanent / https://192.168.16.136

   UseCanonicalName Off

</VirtualHost>

<VirtualHost *:443>

ServerName test002

RedirectPermanent / https://192.168.16.136/mod_cluster-manager

SSLEngine on

SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL

SSLVerifyDepth 10

SSLCertificateFile /etc/ssl/server-certs/my-server.cer

SSLCertificateKeyFile /etc/ssl/server-certs/my-server.key.public

<Directory />

Order deny,allow

Allow from all

</Directory>

KeepAliveTimeout 60

ManagerBalancerName mycluster

MaxKeepAliveRequests 0

ServerAdvertise On

EnableMCPMReceive On

</VirtualHost>

<Location /mod_cluster-manager>

SetHandler mod_cluster-manager

Order deny,allow

Allow from all

</Location>

maaaas, quando alterei de:

RedirectPermanent / https://192.168.16.136/mod_cluster-manager

para:

RedirectPermanent / https://192.168.16.136/systemprops

não funcionou..

E ao acessar a URL https://192.168.16.136/mod_cluster-manager eu vi que não apareciam o slave01 e o slave02 lá...

Voltei o mod_cluster.conf para:

<VirtualHost 192.168.16.136:80>

<Directory />

Order deny,allow

Allow from all

</Directory>

ServerName teste001

KeepAliveTimeout 60

ManagerBalancerName mycluster

MaxKeepAliveRequests 0

ServerAdvertise On

EnableMCPMReceive On

</VirtualHost>

<Location /mod_cluster-manager>

SetHandler mod_cluster-manager

Order deny,allow

Allow from all

</Location>

reiniciei o apache e os jboss e os slaves apareceram no mod_cluster-manager...

voltei o mod_cluster.conf para usar SSL e os slaves não apareceram..

O que estou fazendo de errado?

Outro detalhe.. quando eu inicio com SSL acontece o seguinte:

[root@localhost ~]# /etc/init.d/httpd start

Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain for ServerName

[Thu May 02 09:25:59 2013] [warn] _default_ VirtualHost overlap on port 443, the first has precedence

                                                           [  OK  ]

e no error_log acontece o seguinte:

[Thu May 02 10:50:50 2013] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)

[Thu May 02 10:50:50 2013] [notice] Digest: generating secret for digest authentication ...

[Thu May 02 10:50:50 2013] [notice] Digest: done

[Thu May 02 10:50:50 2013] [notice] Advertise initialized for process 8185

[Thu May 02 10:50:50 2013] [notice] Apache/2.2.15 (Unix) DAV/2 mod_cluster/1.2.3.Final mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured -- resuming normal operations

Tem ideia do que estou fazendo errado?

Att,

Adriano Schmidt

[adrianoschmidt]

Deixei o mod_cluster.conf mais simples:

<VirtualHost 192.168.16.136:443>

SSLEngine on

SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL

SSLVerifyDepth 10

SSLCertificateFile /etc/ssl/server-certs/my-server.cer

SSLCertificateKeyFile /etc/ssl/server-certs/my-server.key.public

<Directory />

Order deny,allow

Allow from all

</Directory>

ServerName teste001

KeepAliveTimeout 60

ManagerBalancerName mycluster

MaxKeepAliveRequests 0

ServerAdvertise On

EnableMCPMReceive On

</VirtualHost>

<Location /mod_cluster-manager>

SetHandler mod_cluster-manager

Order deny,allow

Allow from all

</Location>

E quando inicio o slave01 acontece o seguinte:

[Server:server-one] 15:20:29,999 ERROR [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Error [null: null: {4}] sending command INFO to proxy 192.168.16.136/192.168.16.136:443, configuration will be reset

[Server:server-one] 15:20:40,017 ERROR [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Error [null: null: {4}] sending command INFO to proxy 192.168.16.136/192.168.16.136:443, configuration will be reset

[adrianoschmidt]

consegui resolver \o)

<VirtualHost 192.168.16.136:80>

<Directory />

Order deny,allow

Allow from all

</Directory>

ServerName teste001

KeepAliveTimeout 60

ManagerBalancerName mycluster

MaxKeepAliveRequests 0

ServerAdvertise On

EnableMCPMReceive On

RedirectPermanent / https://192.168.16.136/

</VirtualHost>

<VirtualHost 192.168.16.136:443>

SSLEngine on

SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL

SSLVerifyDepth 10

SSLCertificateFile /etc/ssl/server-certs/my-server.cer

SSLCertificateKeyFile /etc/ssl/server-certs/my-server.key.public

<Directory />

Order deny,allow

Allow from all

</Directory>

ServerName teste001

RedirectPermanent / https://192.168.16.136/cluster

</VirtualHost>

<Location /mod_cluster-manager>

SetHandler mod_cluster-manager

Order deny,allow

Allow from all

</Location>

só não sei se essa eh a melhor forma :/

Att,

Adriano

[rylphs]

Mauricio,

Aproveitando a thread (e sua boa vontade), estou tentando implementar o SSL na conexão entre o balanceador e as instâncias do JBoss. Estou fazendo isso somente pra aprender e nesse caso não me preocupo com o overhead. Olhando na documentação do mod_cluster (http://docs.jboss.org/mod_cluster/1.2.0/html/UsingSSL.html), lá fala que existem duas conexões entre o balanceador e as instâncias e que ambas podem ser criptografadas. Você sabe quais são as duas? Eu precisaria implementar o SSL nas duas?

Obrigado.

[mauriciomag]

Oi Raphael,

Boa vontade até sobra rsrs o tempo que é curto

Então quando ele diz:

There are 2 connections between the cluster and the front-end. Both could be encrypted. That chapter describes how to encrypt both connections.

Acredito que ele esteja se referindo ao seguite cenário:  Client | Front-end <--  SSL   --> Apache <--  SSL --> JBoss Instances.  Ou seja nesse capítulo ele explica como critografar essas conexões entre o Client para Balancer (Apache) e depois Entre o Balancer para as Instâncias JBoss.

Como voce mesmo já sabe o overhead causado pela critpgrafia é custoso. Em ambientes "profissionais" normalmente o JBoss é colocado em uma DMZ  então raramente é necessário ativar o SSL entre o Apache e as instâncias JBoss.

Mas tudo vai depender de como voce montou a sua "infra".

Imagine a seguinte situação:  Um Domain Controller no servidor   171.x.x.10 , Um Host Controller no servidor 171.x.x.20 e outro Host Controller no 171.x.x.30.  Cada um desses elementos em um servidor específico em ambiente de Cloud por exemplo a Amazon EC2.  Se o ambiente não estiver utilizando uma VPC o tráfego poderia ser interceptado e alterado em um ataque do tipo man-in-the-middle e nós seríamos enganados sem saber rsrs

Então uma pergunta chave aqui você está utilizando em seus testes Domain ou Standalone? pois posso te passar o melhor para cada Modelo.

Abs