GuardianKey é um sistema que utiliza IA (Inteligência Artificial) para prover mais segurança em operações de “login”. Ele utiliza dados contextuais, dados de threat intelligence, entre outros, para verificar se o usuário é quem diz ser. Ou seja: Mesmo que o usuário tenha a senha comprometida, o sistema analisará se o perfil de quem está acessando coincide com o padrão utilizado, caso não ele pode enviar alerta para o usuário/administrador ou até bloquear o acesso.

Aqui no blog já postei sobre o plugin para Zabbix. Recentemente, eles lançaram plugin para esse tipo de análise para o serviço de SSH. Basta instalar o pacote (via yum ou apt), fazer o registro, colocar as informações de registro no arquivo de configuração (/etc/guardiankey/gk.conf), iniciar o serviço e pronto, o serviço já estará funcional.

Saiba mais nos links abaixo:

• Página do GuardianKey
• Página do Plugin SSH
• Plugin SSH do GuardianKey no Github

The post Plugin GuardianKey para SSH appeared first on Blog do Gesiel Bernardes.

O GuardianKey é um serviço que protege a autenticação do sistema (nesse caso o Zabbix) usando técnicas de Machine Learning, e incrementa recursos valiosos contra acessos não autorizados. Farei um post mais detalhado sobre ele futuramente. Nessa implementação irei abordar a utilização do GuardianKey Security Auth Lite, que é gratuito até 10 usuários. Mais detalhes em: https://guardiankey.io/pt-br/services/guardiankey-auth-security-lite/ .

Instalação do Plugin

Basta fazer o download do plugin, e executa-lo na pasta de arquivos frontend do Zabbix (normalmente /usr/share/zabbix):

# cd /usr/share/zabbix
# wget https://raw.githubusercontent.com/pauloangelo/guardiankey-plugin-zabbix/master/install.sh

# sh install.sh

Por fim, você deve logar no painel do GuardianKey para configurar: Envio de e-mails, notificar os usuários, etc. Você pode ter informações detalhadas do painel do GuardianKey no link:
https://guardiankey.io/pt-br/documentation/panel-documentation/

The post Integrando o Zabbix com o GuardianKey appeared first on Blog do Gesiel Bernardes.

Utilizando o mesmo modelo de pesquisa, e com o auxílio da ferramenta da SSL Labs, verifiquei que, com exceção do Santander, todos os sites testados possuem deficiências na criptografia da conexão ao Site. Tais deficiências podem ser exploradas para obter dados que trafegam durante a conexão (usuário, conta, senha, etc) por meio de um ataque MITM. Tal ataque poderia ser realizado enquanto o usuário utiliza o site em uma rede Wifi aberta, por exemplo.

Segue abaixo, ordenado por nota de classificação, o resumo dos sites testados:

  Santander

Nota: A
URL testada: www.santander.com.br  Data do teste:  15 de Fevereiro, 08:15 hrs
Observações: Além de utilizar apenas bons algorítimos, implementou mecanismos de segurança importantes, como Prevenção de ataques de downgrade e Segredo Futuro.

 Itaú

Nota: B
URL Testada: www.itau.com.br
Data do teste:15 de Fevereiro, 08:16 hrs
Observações: Talvez por motivos de compatibilidade, mantém o suporte á MD5 e RC4, o que pode enfraquecer a criptografia da conexão. Possui suporte a Prevenção de ataques de downgrade e Segredo Futuro.

HSBC

Nota: C
URL testada: wwws3.hsbc.com.br  Data do teste:15 de Fevereiro, 08:17 hrs
Observações: Mantém suporte ao SSLv3, o que o torna vulnerável ao ataque SSL Poodle. O algorítimo de assinatura do certificado (SHA1 com RSA) é considerado fraco.

Citibank

Nota: C
URL testada: www.citibank.com.br Data do teste:15 de Fevereiro, 08:18 hrs
Observações: É o caso mais intrigante. De certa forma, não está vulnerável, mas utiliza apenas TLS1.0, que já é um tanto antigo.

Caixa

Nota: C
URL testada: internetbanking.caixa.gov.br Data do teste:15 de Fevereiro, 08:19 hrs
Observações: Teria nota máxima se não mantivesse suporte a SSLv3, o que o torna vulnerável ao SSL Poodle.

Banco do Brasil

Nota: C
URL testada: www2.bancobrasil.com.br Data do teste:15 de Fevereiro, 08:2 hrs
Observações: Utiliza um protocolo morto e outro quase (SSLv3 e TLS 1.0).

Bradesco

Nota: F
URL testada: www.ib2.bradesco.com.br
Data do teste:15 de Fevereiro, 08:21 hrs
Observações:  De longe, a pior nota. Suporta apenas TLS 1.0 e SSLv3. Interessante é que, para o SSLv3 a vulnerabilidade Poodle foi mitigada, mas não foi tratada no TLS 1.0.  Além disso, a chave da criptografia é  fraca (RSA 1024 bits), e a chave da assinatura também é fraca (SHA1 com RSA).

Segue abaixo a tabela com os resultados. Itens bons destacados em verde e ruins destacados em vermelho:

The post Segurança em Sites de Bancos: Suas informações estão seguras? appeared first on Blog do Gesiel Bernardes.

• Nginx: Servidor HTTP de alta performance,  muito conhecido pela sua estabilidade  e facilidade de configuração.
• Naxsi: Firewall de aplicação Web de alta performance e baixa manutenção, para uso com Nginx.
• Php-fpm: (FastCGI Process Manager) é uma alternativa para a implementação PHP FastCGI com alguns recursos adicionais (principalmente) usado em sites pessados.¹

Este tutorial foi feito utilizando CentOS 6.5.

1 –  Suprir dependências

# yum install git mysql mysql-server openssl openssl-devel wget make gcc
Obs: Um passo recomendado é utilizar o mysql_secure_installation:

# service mysqld start
# mysql_secure_installation

2 – Instalando Nginx e Nasxi

Muito embora o Nginx possa ser instalado via Yum, teremos que compilar ele manualmente. Isto porquê o nasxi deve ser compilado junto com o Nginx.
Obs: Substituir o “x” pela versão (utilizar sempre a ultima stable).

# wget http://nginx.org/download/nginx-1.x.x.tar.gz
# git clone https://github.com/nbs-system/naxsi
# tar zvfx nginx-1.x.x.tar.gz
# cd nginx-1.x.x
#./configure –conf-path=/etc/nginx/nginx.conf –add-module=../naxsi/naxsi_src/ –error-log-path=/var/log/nginx/error.log –http-client-body-temp-path=/var/lib/nginx/body –http-fastcgi-temp-path=/var/lib/nginx/fastcgi –http-log-path=/var/log/nginx/access.log –http-proxy-temp-path=/var/lib/nginx/proxy –lock-path=/var/lock/nginx.lock –pid-path=/var/run/nginx.pid –without-http_uwsgi_module –without-http_scgi_module –with-http_ssl_module  –with-ipv6 –prefix=/usr
# make && make install
# mkdir /var/lib/nginx
# useradd -s /bin/false -M -d /var/www  nginx
 

Caso esteja utilizando CentOS, utilizar o script de inicialização contido aqui .

Instalando php-fpm

# yum install php php-devel php-common php-gd php-mysql php-fpm

3 – Configurando ambiente

Configurando Nginx e Naxsi

Visando simplificar a configuração, iremos criar um nginx.conf “genérico”, e as configurações de cada site irão ficar em /etc/nginx/conf.d . As “rules” do naxsi de cada site irão ficar em /etc/nginx/rules.d/. Você pode clicar aqui para baixar o nginx.conf ou executar o comando abaixo:

# wget -O /etc/nginx/nginx.conf https://gesielbernardes.eti.br/wp-content/uploads/2014/04/nginx.conf_.txt

Vamos criar agora a estrutura do naxsi:

# cd ../naxsi
# cp naxsi_config/naxsi_core.rules /etc/nginx/naxsi_core.rules
# cd nx_util
# python setup.py build
# python setup.py install
# mkdir /etc/nginx/conf.d
# mkdir /etc/nginx/rules.d

 [AdSense-A]

4 – Adicionando Sites

Para cada site adicionado, o ideal é que seja criado um arquivo no nginx, um arquivo de regras do naxsi e um arquivo de configurações do php-fpm. Isso faz com que seja possível “isolar” os ambientes, fazendo com que a segurança seja um pouco mais reforçada. Para este tutorial, iremos adicionar um site chamado “meusite.com”. A página inicial consultara a data e hora no banco e exibirá juntamente com a pagina phpinfo. O código dela está abaixo:

# cat /var/www/html/index.php
<?php

$db = mysqli_connect(“localhost”,”meuuser”,”minhasenha”,”mysql”);
$consulta = “SELECT NOW()”;
$result = mysqli_query($db,$consulta);
$data = mysqli_fetch_row($result);
echo $data[0];
phpinfo();

?>

Agora vamos adicionar o site no Nginx:

# vi /etc/nginx/conf.d/meusite.conf
####################################
server {
listen 80;
        server_name meusite.com.br;

location / {
root /var/www/meusite/;
index index.php index.html ;
include /etc/nginx/rules.d/meusite.rules;

}

location ~ \.(php|html)$ {
root /var/www/meusite ;
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.html;
fastcgi_param SCRIPT_FILENAME /var/www/meusite/$fastcgi_script_name;
include fastcgi_params;
include /etc/nginx/rules.d/meusite.rules;
access_log /var/log/nginx/access_meusite.log;
error_log /var/log/nginx/error_meusite.log;
}

}
#######################################

Nesse exemplo acima, as extensões “.html” e “.php” serão passadas ao php-fpm, enquanto o restante do conteúdo será processado pelo nginx. Agora será necessário criar o arquivo de regras do naxsi para este site. O padrão é o conteúdo abaixo:

# vi /etc/nginx/rules.d/meusite.rules
#####################
LearningMode; #Enables learning mode
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl “/RequestDenied”;
## check rules
CheckRule “$SQL >= 8” BLOCK;
CheckRule “$RFI >= 8” BLOCK;
CheckRule “$TRAVERSAL >= 4” BLOCK;
CheckRule “$EVADE >= 4” BLOCK;
CheckRule “$XSS >= 8” BLOCK;
########################

A opção “LearningMode” refere-se ao modo de aprendizagem. O naxsi é um WAF baseado em detecção de anomalias, portanto, para que ele possa identificar o que é “anormal”, é necessário gerar uma whitelist. Posteriormente, iremos ver como gerar essa whitelist.

Resta agora configurar o php-fpm. Iremos utilizar o arquivo default para esse exemplo, mas é recomendável criar um arquivo para cada site. Mantenha o conteúdo do arquivo e modifique APENAS as opções abaixo:

# vi /etc/php-fpm.d/www.conf
user = nginx
group = nginx
chdir = /var/www/meusite/

Basta agora apenas iniciar os serviços:

# service mysqld start
# service php-fpm start
# service nginx start

E pronto. O Servidor já está funcionando com suporte á PHP e Mysql

Por fim, resta apenas gerar a whitelist do naxsi. Com os site em funcionamento, navegue por ele, simulando um acesso. Teste de diversos navegadores, se possível em sistemas operacionais diferentes. Agora vamos gerar o relatório a partir dos logs:

# nx_util.py -l /var/log/nginx/error_meusite.log -o

Ele vai processar os arquivos e apresentar sugestões de regras, algo com abaixo:

BasicRule wl:1011 “mz:$HEADERS_VAR:cookie”;
BasicRule wl:1010 “mz:$HEADERS_VAR:cookie”;

Essas sugestões você adiciona no seu arquivo de rules do site, neste caso em /etc/nginx/rules.d/meusite.rules. No mundo ideal, isso seria o suficiente. Todavia, a amostragem (acessos de teste) nem sempre são suficientes para gerar a whitelist. Ideal é se ele ficasse no modo de aprendizagem um determinado tempo, algo como uma semana, para que seja gerada uma whitelist ampla. Vale ressaltar que, neste caso, deve-se tomar cuidado para não incluir um ataque em uma whitelist.

Posteriormente, veremos  como utilizar SSL , e também outros ajustes que podem tornar o ambiente ainda mais seguro.

Referências:

¹ http://www.php.net/manual/pt_BR/install.fpm.php
Naxsi Wiki

 [AdSense-A]

The post Configurando Servidor Web Seguro com suporte a Php e Mysql utilizando Nginx + Naxsi + php-fpm appeared first on Blog do Gesiel Bernardes.