Logar IP do Cliente e IP X-Forwarded-For IP no Apache

Quando o servidor apache fica atrás de um proxy ou loadbalancer o IP do cliente é substituido pelo IP do balanceador/proxy. Para ultrapassar esta limitação um cabeçalho/header costumizado foi desenvolvido pela equipe de desenvolvimento do squid, o X-Forwarded-For header.

A configuração default de logging do apache tem o seguinte formato:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/acces_log combined

São necessárias varias alterações à configuração por defeito de forma a que o X-Forwarded-For e o ip real do visitante seja logado. As alterações são as seguintes:

LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
LogFormat “%{X-Forwarded-For}i %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” proxy
SetEnvIf X-Forwarded-For “^.*\..*\..*\..*” forwarded
CustomLog “logs/access_log” combined env=!forwarded
CustomLog “logs/access_log” proxy env=forwarded

Estas alterações resultam no log do endereço IP de cada pedido.

Configurar Liferay para responder corretamente atrás de um Balaceador de SSL Offload

Recentemente tive a necessidade de configurar um servidor aplicacional Tomcat/Liferay, para tal depois de muitas voltas conclui que para se conseguir ter o servidor atrás de um balaceador que faz o offload de SSL. Recorrer ao mod_proxy do apache não satisfaz os resultados pretendidos uma vez que o post do formulário de login segue sempre em http, impedindo assim os utilizadores de fazer login.

Consegui um comportamento correto com recurso ao mod_jk com as seguintes configurações:

Ficheiro workers.properties (/etc/httpd/conf.d/):

#Name of the load balancer workers
worker.list=loadbalancer
#Worker configuration for liferay-node-01
#AJP Connector port of node-01 on liferay-node-01 server
worker.node-01.port=8009
worker.node-01.host={IP do servidor onde está o Liferay}
worker.node-01.type=ajp13
worker.node-01.lbfactor=1
#load balancer configuration properties
worker.loadbalancer.type=lb
#list of worker nodes that are part of the cluster
worker.loadbalancer.balance_workers=node-01
worker.loadbalancer.sticky_session=1

Ficheiro mod_jk.conf em (/etc/httpd/conf.d/):

LoadModule jk_module modules/mod_jk-1.2.28-httpd-2.2.X.so
JkWorkersFile /etc/httpd/conf.d/workers.properties
JkShmFile /var/log/httpd/mod_jk.shm
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkLogStampFormat “[%a %b %d %H:%M:%S %Y] “

No ficheiro server.xml do servidor Tomcat foi necessário mudar a tag:

<Engine name=”Catalina” defaultHost=”localhost”>

Para:

<Engine name=”Catalina” defaultHost=”localhost” jvmRoute=”node-01″>

A configuração do Virtual host apache foi a seguinte (virtualhost.conf em /etc/httpd/conf.d/):

<VirtualHost *:443>
ServerName dominio.autilizar.com
ServerAdmin it@dominio.autilizar.com
ErrorLog “/var/log/httpd/error_log”
TransferLog “/var/log/httpd/access_log”
SSLEngine on
SSLCertificateFile /caminho/para/o/certificado/dominio.autilizar.com.crt
SSLCertificateKeyFile /caminho/para/a/chave/privada/dominio.autilizar.com.crt
JkMount /* loadbalancer
</VirtualHost>

Já havia tido a necessidade de utilizar o mod_jk com o tomcat anteriormente, mas devido a situações particulares em que os frontends Apache balanceavam pedidos para multiplos servidores aplicacionais. A prévia utilização deste método para situações especificas de balanceamento de aplicações facilitou a resolução deste desafio com que me deparei.

Comando “screen”

O comando screen é uma ferramenta muito pouco utilizada mas de grande utilidade uma vez que permite correr processos em background independentes da sessão do utilizador. Seguem alguns atalhos de teclas utilizados no screen.
Combinação Acção
Ctrl+a c nova janela
Ctrl+a n próxima janela
Ctrl+a p janela anterior
Ctrl+a “ escolher janela da lista
Ctrl+a Ctrl+a ultima janela ativa
Ctrl+a S dividir terminal horizontalmente em regiões
Ctrl+a | dividir terminal verticalmente em regiões
Ctrl+a :resize redimensionar região
Ctrl+a :fit adaptar a resolução do monitor ao tamanho do novo terminal
Ctrl+a :remove remover região
Ctrl+a tab mover para a próxima região
Ctrl+a d desanexar o screen do terminal
Ctrl+a A definir titulo da janela
Ctrl+a x bloquear sessão
Ctrl+a [ entrar no modo de copia
Ctrl+a ] buffer de paste
Ctrl+a > escrever  o paste buffer para fichero
Ctrl+a < ler o paste buffer do ficheiro
Ctrl+a ? ver key bindings/nomes dos comandos
Ctrl+a : screen command prompt

Configurar Liferay/Tomcat para responder a pedidos https (proxyed)

Por vezes existe a necessidade de configurar o servidor aplicacional Liferay/Tomcat para aceitar e responder corretamente pedidos https sem que exista configuração de SSL no Tomcat. Esta situação acontece quando o servidor aplicacional está atrás de um balanceador ou proxy, podendo este proxy ser por exemplo Nginx ou Apache.

De forma a que o servidor aplicacional responda devidamente aos pedidos devem adicionar-se as seguintes propriedades ao ficheiro portal-ext.properties

web.server.https.port=443
web.server.protocol=https

Como configurar um “reverse tunel SSH” em Linux para utilizar com privoxy

O Reverse “SSH Tunneling” é uma técnica que permite aceder a sistemas que se encontram bloqueados, por exemplo com uma firewall.

Por vezes é necessário aceder a partir de um sistema sem acesso à internet aos repositórios da distribuição ou a outros recursos expostos na internet.

No nosso exemplo este acesso faz-se com o privoxy, sendo que a maquina que vai servir de proxy é um servidor debian.

Para instalar o privoxy deve executar-se o seguinte comando:

$ sudo apt-get install privoxy

Uma vez instalado deve fazer-se start ao serviço com o seguinte comando:

$ sudo systemctl start privoxy

Para configurar o serviço para arrancar durante o boot executa-se o seguinte:

$ sudo systemctl enable privoxy

As configurações por defeito são suficientes para o nosso objetivo, deverá ter-se em conta que este servidor que irá servir de proxy tem de ter acesso à internet.

Uma vez instalado e feito o arranque do privoxy procedemos à criação do reverse tunel, com recurso ao seguinte comando:

$ ssh -R 8118:localhost:8118 username@REMOTEIP

Neste momento o servidor remoto que não tinha acesso à internet já tem neste momento ligação ao nosso servidor privoxy.

Para concluirmos a operação devemos configurar o proxy no servidor remoto, para tal executam-se os seguintes comandos no servidor remoto:

# export http_proxy="http://localhost:8118"
# export https_proxy="https://localhost:8118"
# export ftp_proxy="ftp://localhost:8118"

Converter imagens qcow (KVM) para VmWare vmdk

Converter imagens qcow para vmdk é um processo de extrema simplicidade. Dependendo do objetivo pode usar-se um dos seguintes comandos:

# qemu-img convert -f qcow2 file.qcow2 -O vmdk file.vmdk

# qemu-img convert -f qed file.qed -O vmdk file.vmdk

# qemu-img convert -f qcow2 file.qcow2 -O qed file.qed

HTTP Strict Transport Security para o Apache, NGINX e Lighttpd

HTTP Strict Transport Security (abreviado HSTS) é uma funcionalidade de de segurança que permite a um website informar o browser que deve comunicar utilizando apenas HTTPS, em vez de utilizar HTTP

Configuração para Apache

Deve adicionar-se ao virtualhost configurado para responder por HTTPS o seguinte:

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

O Apache deve ser reiniciado depois de ser efetuada a alteração à configuração

Configuração para Lighttpd

Para configuração no Lighttpd deve adicionar-se ao ficheiro /etc/lighttpd/lighttpd.conf a seguinte configuração:

server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=63072000; includeSubdomains; preload")
}

Deve reiniciar-se o Lighttpd para que as alterações sejam aplicadas.

Configuração para NGINX

A configuração para NGINX é ainda mais sucinta, deve ser adicionado ao bloco SERVER da configuração HTTPS a seguinte linha:

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

Comandos OpenSSL para converter certificados SSL

Por vezes a configuração de SSL requer que os certificados SSL estejam em determinados formatos, por exemplo um servidor Windows importa e exporta ficheiros .pfx enquanto um servidor apache utiliza ficheiros individuais em formato PEM.

Os comandos abaixo permitem converter certificados SSL em diferentes formatos:

OpenSSL Convert PEM
Convert PEM to DER

# openssl x509 -outform der -in certificate.pem -out certificate.der

Convert PEM to P7B

# openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer

Convert PEM to PFX

# openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

OpenSSL Convert DER
Convert DER to PEM

# openssl x509 -inform der -in certificate.cer -out certificate.pem

OpenSSL Convert P7B
Convert P7B to PEM

# openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

Convert P7B to PFX

# openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

# openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer

OpenSSL Convert PFX
Convert PFX to PEM

# openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

Preparar uma maquina virtual Red Hat Enterprise Linux para ser usada como template

No mundo do IT a automatização e agilização de tarefas é são factores determinantes para o sucesso das organizações. Face à necessidade constante de deploy de novas maquinas virtuais com características semelhantes tornou-se frequente fazer clones de máquinas, desta forma seguem algumas guidelines e comandos para criação de um clone de Red Hat Linux para ser usado como template.

# touch /.unconfigured
# rm -rf /etc/ssh/ssh_host_*
# ifdown eth0

Com recurso a um editor de texto modificar o ficheiro /etc/sysconfig/network-scripts/ifcfg-eth0 e remover a entrada HWADDR.

# ifup eth0

Utilizando um editor de texto remover a entrada para o interface de rede eth0 no ficheiro /etc/udev/rules.d/70-persistent-net.rules

# poweroff

Desta forma temos um template criado e pronto a utilizar para aprovisionamento de novas máquinas virtuais.

Ver progresso de backups e restores em MSSQL

Por vezes acompanhar o processo de restore e backup de bases de dados MSSQL pode ser uma tarefa desafiante, o contador “default” que apenas regista o progresso a cada 10% concluídos, para ultrapassar esta dificuldade pode ser executada a seguinte query que vai repostar o estado atual do backup ou restore:

SELECT session_id as SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time

FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a

WHERE r.command in (‘BACKUP DATABASE’,’RESTORE DATABASE’)