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.

Pré-requisitos:

# yum install httpd epel-release git wget

Instalação do ModSecurity

# yum install mod_security mod_evasive

Instalação das regras:

# cd /etc/httpd/modsecurity.d
# rm -rf activated_rules/
#  git clone https://github.com/SpiderLabs/owasp-modsecurity-crs .
# mv crs-setup.conf.example crs-setup.conf
# vi /etc/httpd/conf.d/mod_security.conf
Altere a linha 4 para:
IncludeOptional modsecurity.d/rules/*.conf

# vi /etc/httpd/modsecurity.d/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
Comente (coloque # no inicio da linha) da linha 37 (SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/…) até a linha 64( setvar:tx.%{rule.id}…), e depois comente da linha 751 até a 779.

# vi /etc/httpd/modsecurity.d/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
Comente da linha 43 até a 68

Reinicie o Apache:
# systemctl restart httpd

Observação: A configuração padrão vem com o nível “paranoico” 1, ou seja, irá fornecer uma proteção básica porém irá gerar muito pouco ou quase nenhum falso positivo. Em minha opinião, o nível “paranoico” 2 tem uma relação custo-benefício melhor, uma vez que oferece um nível maior de proteção com uma quantidade aceitável de falso positivo. Para alterar para o nível paranoico 2, faça a seguinte alteração:

# vi /etc/httpd/modsecurity.d/crs-setup.conf
(linha 171)
SecAction \
“id:900000,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.paranoia_level=2”

Agora reinicie o serviço:
# systemctl restart httpd

The post Instalando ModSecurity no CentOS 7 (com Apache) appeared first on Blog do Gesiel Bernardes.

Instalação no CentOS 7:

# yum install wget vim perl-libwww-perl.noarch perl-Time-HiRes
# cd /usr/src/
# wget https://download.configserver.com/csf.tgz
# tar -xzf csf.tgz
# cd csf
# sh install.sh

Testando a instalação:
# cd /usr/local/csf/bin/
# perl csftest.pl
Resultado esperado:
{…}
RESULT: csf should function on this server

Configurando o CSF

# vi /etc/csf/csf.conf
TESTING = “0”

# systemctl start csf
# systemctl start lfd
# systemctl enable csf
# systemctl enable lfd

Você pode listar as regras digitando:
# csf -l

The post Instalando Config Server Firewall (CSF) no Centos 7 appeared first on Blog do Gesiel Bernardes.

1. Faça o download do agente de acordo com sua arquitetura:
   x86:  https://support.zabbix.com/secure/attachment/40104/Zabbix-3.0.1-with-OpenSSL-1.0.2c-x86.zip
   x64: https://support.zabbix.com/secure/attachment/40105/Zabbix-3.0.1-with-OpenSSL-1.0.2f-x64.zip
2. Extraia o arquivo na pasta que deseja a instalação (ex: C:\zabbix)
3. Crie o arquivo de configuração (ex: c:\zabbix\zabbix_agentd.conf), e adicione na configuração as opções relacionadas a criptografia (PSK ou Certificados). Você pode conferir neste post as configurações de criptografia do Agente, e nesta página você encontra todas as opções de configuração do Agente.
4. Instale o serviço do Zabbix. Neste exemplo, minha instalação está na pasta C:\zabbix:
   Abra o cmd (como Administrador) e digite:
   C:\zabbix\zabbix_agentd -i -c “C:\zabbix\zabbix_agentd.conf”

E pronto! A instalação com suporte a TLS está feita….

The post Configurando Criptografia do Zabbix no Windows appeared first on Blog do Gesiel Bernardes.

Introdução ao SELinux

Mesmo sendo conhecido por grande parte dos administradores de redes/sistemas, o uso mais comum consiste basicamente em “desabilitá-lo”. Por requerer um trabalho adicional, ou por não saber configurar o SELinux, ou por outros motivos, os administradores abrem mão de um importante aliado na proteção do servidor. Segundo estatísticas do CSIRT Unicamp, ao menos 70% dos problemas de Segurança em servidores web no ano de 2013 poderiam ter sido evitados se estivessem com SELinux ativo.

SELinux é a implantação do mecanismo de Segurança MAC (Mandatory Access Control) no kernel do Linux. Foi criado pela NSA (National Security Agency), e impõe regras em arquivos e processos em um sistema Linux.
A maioria dos sistemas utilizam DAC ( Discretionary Access Control) para prover segurança do sistema. De uma forma geral, DAC é um controle de acesso em que o usuário tem controle total dos arquivos que possui e executa. Uma vez definida estas permissões, não há nenhuma outra restrição para execução dos processos/arquivos. Isto pode ser um problema quando, por exemplo, o usuário (ou um processo iniciado pelo mesmo) não atribui a permissão adequada a um determinado arquivo, deixando-o exposto. Ou então quando um programa foge do seu comportamento “normal”. Vejamos um exemplo: O usuário apache está sendo utilizado para executar o software Apache. Durante sua execução, devido uma falha de programação no código da página, o processo recebe uma requisição para acessar o arquivo /etc/passwd. As permissões do arquivo são as seguintes:

# ls -l /etc/passwd
-rw-r–r– 1 root root 1760 Out 23 11:12 /etc/passwd

Segundo as permissões do arquivo /etc/passwd, todos podem ler o arquivo. Logo, o Apache poderá exibi-lo sem nenhum problema. Ainda neste exemplo, se a falha do código da página permitisse, seria possível o Apache salvar um arquivo em qualquer local que tiver permissão de escrita.
Mandatory Access Control (MAC), provido pelo SELinux, restringe o nível de controle que os usuários tem sobre os objetos que eles criam, e adiciona categorias e rótulos a todos os objetos do sistema de arquivos. Usuários e processos devem ter acesso adequado a estas categorias e rótulos para que então possam interagir com esses objetos. Quando corretamente implementado, MAC permite ao sistema defender-se adequadamente. A sua capacidade de limitar os privilégios associados a processos de execução limita o âmbito de dano potencial, que pode resultar da exploração de vulnerabilidades em aplicações e serviços do sistema.
Como aplicação do SELinux, o que se tem são rótulos contendo informações relevantes para a segurança de processos e arquivos. Essa informação é chamada de Contexto SELinux (SELinux context), e pode ser obtida utilizando a opção “-Z” no comando “ls”:

# ls -lZ /etc/passwd
-rw-r–r–. root root system_u:object_r:etc_t:s0 /etc/passwd

No arquivo acima temos o contexto do usuário (system_u), a regra (object_r), o tipo (etc_t) e o nível (s0). Estas informações são utilizadas para determinar o acesso do usuário ao arquivo. Agora, vamos voltar ao exemplo anterior, e considerar que neste sistema o SELinux está ativo. Verificaremos então o contexto do processo do Apache:

# ps axZ | grep httpd
unconfined_u:system_r:httpd_t:s0 6906 ? Ss 0:00 /usr/sbin/httpd

Logo, como o contexto do processo não coincide com o contexto do arquivo, o acesso ao mesmo será NEGADO, mesmo que nas permissões DAC o mesmo tenha permissão para tanto.

Modificando contextos

Conforme visto anteriormente, o SELinux tem seu funcionamento baseado em rótulos e em políticas de segurança. Os rótulos dos usuários, arquivos e processos definem o contexto de segurança de cada objeto. Colocando em uma aplicação prática, vejamos o exemplo a seguir:

# ls -Z /var/www/html/
-rw-r—–. root apache unconfined_u:object_r:user_home_t:s0 index.html

Em quase todos os casos, o campo do contexto que realmente importa é o terceiro campo; ele indica o tipo do objeto (neste caso, user_home_t indica que o tipo de arquivo é um arquivo de usuário “humano”). Considerando que este arquivo é uma página que será utilizada pelo Apache, conclui-se que ele não está com o contexto apropriado (que neste caso seria “httpd_sys_content_t”), logo não irá funcionar. Então, é necessário alterar o tipo de arquivo no contexto para que o mesmo funcione:

# chcon -R -t httpd_sys_content_t /var/www/html/

Assim como o chmod é utilizado para alterar permissões DAC, o chcon pode ser utilizado para alterar o contexto dos arquivos. Porém todas as alterações realizadas com o chcon são desfeitas quando o sistema é reiniciado. Para que a alteração seja permanente, deve-se utilizar o semanage:

# semanage fcontext -m -t httpd_sys_content_t /var/www/html/index.html

Alterar o contexto de arquivo por arquivo não parece ser muito produtivo. Por isso, você pode utilizar expressões regulares para alterar vários arquivos de uma vez só:

# semanage fcontext -m -t httpd_sys_content_t “/var/www/html(/.*)?”

Se o retorno que você tiver for o abaixo, basta você trocar o “-m” (modificar) pelo “-a” (adicionar) no comando:

usr/sbin/semanage: O contexto de arquivo para /var/www/html não está definido

# semanage fcontext -a -t httpd_sys_content_t “/var/www/html(/.*)?”

Após realizar as alterações com o semanage, é necessário utilizar o “restorecon” para aplicar as alterações:

# restorecon -Rv /var/www/html

Agora, o arquivo já está com o contexto que permitirá seu funcionamento:

# ls -Z /var/www/html/
-rwxr-x—. root apache unconfined_u:object_r:httpd_sys_content_t:s0 index.html

Políticas Booleanas

Além do contexto, o SELinux utiliza políticas pré-definidas para cada serviço para restringir/conceder acesso á determinadas funções. Você pode visualiza-las utilizando o comando abaixo:

# semanage boolean -l

Supondo que desejo que o home dos usuários seja acessível pelo apache (crio lá no home do usuário uma pasta public_html para o usuário acessar meusite.com/~usuario). Se não alterar nada, o SELinux irá bloquear o acesso. Então, listando as políticas, temos:

# semanage boolean -l | grep -E ‘httpd.*home’
httpd_enable_homedirs (desativado,desativado) Allow httpd to read home directories

Com isso, confirmamos que a esta opção está desativada. Vamos ativá-la então:

# setsebool -P httpd_enable_homedirs 1

Liberar Portas

O SELinux também provê controle sobre qual serviço pode acessar qual porta (para o desespero de alguns). A lista de portas/serviços liberados você pode obter com o comando abaixo:

# semanage port -l

Usando como exemplo um servidor apache, que quero que o mesmo funcione na porta 25000/TCP. Porém, nas políticas SELinux esta porta não está liberada:

# semanage port -l | grep http _port
http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000

Então, vamos adicionar a porta 25000 á regra:

# semanage port -a -t http_port_t -p tcp 25000

Resolvendo problemas

    Muitas vezes, por diversas razões, não conseguimos impedir que o SELinux interfira no funcionamento adequado de determinados softwares. Para solucionar casos deste tipo, podemos utilizar o audit2allow para entender melhor o problema ou para criar módulos de políticas para SELinux.

O primeiro passo é verificar os logs em /var/log/audit,log, que terá registros semelhantes a esse:

type=AVC msg=audit(1455199601.283:181376): avc: denied { setattr } for pid=7489 comm=”mingetty” name=”tty6″ dev=devtmpfs ino=5354 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1455199601.283:181376): arch=c000003e syscall=92 success=no exit=-13 a0=7ffdf8b4b090 a1=0 a2=0 a3=7ffdf8b4acd0 items=0 ppid=1 pid=7489 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=”mingetty” exe=”/sbin/mingetty” subj=system_u:system_r:getty_t:s0 key=(null)
type=AVC msg=audit(1455199606.148:181377): avc: denied { setattr } for pid=7490 comm=”mingetty” name=”tty2″ dev=devtmpfs ino=5350 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file

Neste exemplo, SELinux está bloqueando a função “setattr” para a aplicação “mingetty”. Iremos usar o audit2allow para criar um módulo de política SELinux para corrigir tal erros.

Para gerar um relatórios “humano” dos eventos do SELinux, você pode utilizar o comando abaixo:
# audit2allow -a

O comando acima irá analisar todos os registros contidos em /var/log/audit.log. Caso queira uma análise apenas para um erro específico, você pode usar o “grep” para filtrar os eventos:
# grep “mingetty” /var/log/audit.log | allow2audit -w

Para criar um modulo de política SELinux, utilze a opção “-M”:
# audit2allow -a -M meumodulo

Posso também utilizar o “grep”, como no exemplo anterior:
# grep “mingetty” /var/log/audit.log | allow2audit -M meumodulo

Ele irá criar um arquivo “.pp” e um .”te” no diretório corrente. Para instalar o módulo, você utilize o comando:
# semodule -i meumodulo.pp

Em seguinda, habilite o módulo:
# semodule -e meumodulo

Referências:

https://www.security.unicamp.br/54-selinux-um-importante-aliado-na-seguranca-de-servidores-linux-parte-1.html

https://www.security.unicamp.br/86-selinux-um-importante-aliado-na-seguranca-de-servidores-linux-parte-2.html

https://www.security.unicamp.br/103-selinux-um-importante-aliado-na-seguranca-de-servidores-linux-parte-3.html

The post Configurar e trabalhar com SELinux (CentOS) 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.

     Muitas vezes preocupamos muito com as invasões e ataques provenientes da Internet para nossa rede local. Porém as vezes o perigo pode estar mais próximo do que imaginamos. Cerca de 70% dos ataques são feitos a partir da rede interna. Por isso senhas absurdamente complexas aliada á algum outro meio de autenticação torna-se quase que obrigatório para uma rede Wireless. Neste pequeno tutorial veremos como um invasor pode capturar informações até mesmo consideradas como seguras e criptografadas.

• Computador com sistema operacional Linux (neste caso usarei o Fedora 15) conectado na mesma rede da vítima.

• Conexão com a Internet;

• Conhecimento intermediário em Redes/Linux.

• IP da vítima: 192.168.0.67
• IP do roteador: 192.168.0.1

     Passo 1 – Baixar e Instalar pacotes

The post Como capturar senhas do Facebook, Gmail, Twitter… appeared first on Blog do Gesiel Bernardes.