Liferay – Enumeração de utilizadores utilizando os documentos

Uma das vulnerabilidades existentes no liferay que permite enumerar utilizadores existentes na plataforma encontra-se no caminho dos documentos do Liferay, para corrigir esta vulnerabilidade deve seguir-se o seguinte procedimento:

Editar o ficheiro urlrewrite.xml (\tomcat-7.0.40\webapps\ROOT\WEB-INF

Inserir a seguinte regra:

<rule>
<from>^/documents/([A-Za-z]+)</from>
<to type=”permanent-redirect”>/</to>
</rule>

Erro “Unable to verify leaf signature” no NodeJS

Recentemente, após instalar uma aplicação NodeJS (MEAN Stack) deparei-me com o erro “Unable to verify leaf signature”. Após alguns despites conclui que a dificuldade encontrada estava relacionada com a cadeia de certificação associada ao certificado SSL utilizado pela aplicação. A minha primeira abordagem foi verificar no servidor NGINX a correta configuração do certificado e devida cadeia, no entanto todas as configurações estavam de acordo com as especificações, desta forma conclui que o a situação estava relacionada com servidor aplicacional (NodeJS).

Para tornar a aplicação funcional executei o seguinte procedimento no servidor aplicacional:

npm install ssl-root-cas

Este pacote NodeJS contem vários certificados intermédios que são “confiáveis” pelo browser mas não pelo NodeJS

var sslRootCAs = require('ssl-root-cas/latest')
sslRootCAs.inject()

Desta forma os certificados em falta serão adicionados.

Para além desta situação foi-me necessário adicionar mais certificados a este modulo pois por defeito os que eu necessitava não se encontravam neste “bundle”, para tal foi ncessário fazer o download dos certificados em falta para tal utilizei o seguinte procedimento:

require('ssl-root-cas/latest')
  .inject()
  .addFile(__dirname + '/certificadointermedioemfalta.crt');

Adicionar IP secundário em Linux

Adicionar IP temporário

Utilizando o ifconfig

Caso seja necessário adicionar um ip secundário a um interface que se encontra em uso e esta situação é temporária deve correr-se o seguinte comando:

ifconfig [nic]:0 [IP-Address] netmask [mask] up

Como exemplo:

ifconfig eth0:0 192.168.1.2 netmask 255.255.255.0 up

Para correr este comando é necessário estar autenticado com o user root.

Utilizando o comando ip

Para efetuar esta configuração utilizando o binario ip deve correr-se o seguinte comando:

ip address add [ip]/[mask-digits] dev [nic]

Como exemplo:

ip address add 192.168.99.37/24 dev eth0

Adicionar IP permanentemente

CentoOS/RHEL

Para sistemas Centos/RHEL deve criar-se um ficheiro chamado:

ifcfg-eth0:1

O ficheiro deverá ter os seguintes conteudos:

NAME=""
BOOTPROTO=none
MACADDR=""
IPV6INIT=no
DEVICE=eth0:1
NETMASK=255.255.255.248
MTU=""
ONPARENT=yes
IPADDR=192.168.8.1
ONBOOT=yes

Uma vez efetuada a configuração devem reiniciar-se os serviços de network:

service network restart

JVM 100% CPU Leap Second

Na passagem do ano deparei-me com uma situação no mínimo curiosa, devido ao facto do ultimo minuto do ano ter tido 1 segundo a mais (leap second) várias JVM’s ficaram com uma utilização excessiva de CPU, afetando assim a performance de vários servidores. Depois de várias pesquisas, verifiquei que as recomendações de multiplos fabricantes era: efetuar reboot aos servidores em questão. Por se tratarem de ambientes produtivos, não considerei boa opção reiniciar as máquinas e descobri um “workaround”. Aparentemente forçar um reset à data é suficiente para corrigir o problema.

O comando a utilizar é o seguinte:

date -s "`date`"

 

/bin/tar: Argument list too long

Quando o numero de ficheiros numa diretoria excede 30.000 comprimilos pode ser um desafio. Seguem os passos para concluir esta tarefa com sucesso::

find . -name '*.txt' -print >/tmp/ficheiros
tar -cvzf textfiles.tar.gz --files-from /tmp/ficheiros
find . -name '*.txt' | xargs rm -v

Servidor de mail Zimbra. Erro “Some services are not running”

Por vezes a consola do servidor de correio eletrônico zimbra reporta os serviços como não disponíves quando no entanto os mesmos se encontram online como se pode comprovar atravez do comando:

$ zmcontrol status
Host zimbra
mailbox Running
memcached Running
service webapp Running
snmp Running
spell Running
stats Running
zimbra webapp Running
zimbraAdmin webapp Running
zimlet webapp Running
zmconfigd Running

Para corrigir esta situação devem correr-se os seguintes comandos como root:

# /opt/zimbra/libexec/zmsyslogsetup
# service rsyslog restart
# chkconfig rsyslog on

Init script para SOLR 4.10.2

#!/bin/sh
# description: Solr Server
# Solr Server service start, stop, restart

#solr start -d /opt/solr/core

SOLR_DIR="/opt/solr"
SOLR_CORE="/opt/solr/core"
SOLR_PORT="8983"
case $1 in
start)
echo "Starting Solr..."
$SOLR_DIR/bin/solr start -d $SOLR_CORE
sleep 1
lsof -i :8983
;;
stop)
echo "Stopping Solr..."
$SOLR_DIR/bin/solr stop -d $SOLR_CORE -p $SOLR_PORT
;;
restart)
$0 stop
sleep 2
$0 start
;;
*)
echo "Usage: $0 [start|stop|restart]"
exit 1
;;
esac

exit 0

Criar certificado auto-assinado para servidor Apache

De forma a criar um certificado auto-assinado para um virtualhost Apache deve optar-se pela utilização do OpenSSL. Uma vez que esteja assegurado que o OpenSSL está instalado deve correr-se o seguinte comando para gerar o certificado e chave privada:

# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout mysitename.key -out mysitename.crt

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.