Spawnzao

Recentemente fui atualizar o meu servidor que roda o OpenVas, ele é um CentOS 7, e obtive o seguinte erro ao executar o yum update:

Transaction check error:
file /usr/lib/python2.7/site-packages/socks.py conflicts between attempted installs of python2-pysocks-1.6.8-5.el7.noarch and python-SocksiPy-1.00-4.el7.art.noarch
file /usr/lib/python2.7/site-packages/socks.pyc conflicts between attempted installs of python2-pysocks-1.6.8-5.el7.noarch and python-SocksiPy-1.00-4.el7.art.noarch
file /usr/lib/python2.7/site-packages/socks.pyo conflicts between attempted installs of python2-pysocks-1.6.8-5.el7.noarch and python-SocksiPy-1.00-4.el7.art.noarch

Pesquisei no Google e encontrei outras pessoas com o mesmo problema, mas nenhuma solução. Analisando melhor o problema, encontrei no Google a função “yum swap” que substitui um pacote por outro, e com ele consegui resolver o problema.

Segue a solução:

yum swap python2-pysocks python-SocksiPy

De maneira geral, o mDNS [RFC 6762] é um protocolo DNS Multicast, isto é, repassa a mesma mensagem para múltiplos destinatários simultaneamente, e o DNS-SD [RFC 6763] permite encontrar e divulgar instâncias de um serviço desejado na rede. É um método para descoberta de vizinhos em uma LAN, similar ao protocolo UPnP que usa HTTP, ao invés do DNS.

• mDNS: usa UDP porta 5353 (origem e destino)
• DNS-SD: usa o DNS unicast e multicast

Os 2 protocolos foram projetados pela Apple, e formam o ZeroConf (Zero Configuration Networking), um conjunto de técnicas que criam de forma automática uma rede IP, sem a necessidade de configuração ou servidores. Ele é usado por muitos dispositivos (Apple TV, Chromecast, home speakers, NAS devices, etc.)

Zero Conf = automatic IP configuration + host name resolution + target service discovery

(continue reading…)

Manter um servidor hoje na internet requer alguns recursos mínimos de segurança, e hoje vamos configurar o Fail2ban, uma ótima ferramenta para evitar atauqes de força bruta no servidor.
O fail2ban fica auditando os arquivos de logs, procurando por múltiplos erros de login, e caso encontre 5 erros seguidos ele executa uma action, que normalmente é um bloqueio do ip de origem por 600 segundos. Podemos também configurá-lo para toda vez que ocorra um bloqueio ele nos informe por e-mail e também nos diga um WHOIS desse ip, para termos mais informações sobre o ip atacante.

A nova versão do Fail2ban além de ficar muito mais robusta e completa, trás suporte a multiplos serviços, como por exemplo: apache, modsecutiry, proftpd, vsftpd, mysqld, dentre outros, importantíssimo para manter a segurança de nossos servidores.

Instalar o Repositório epel:

yum install https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm

Instalar os pacotes do Fail2ban:

yum install fail2ban-systemd fail2ban-sendmail fail2ban-server whois

Eu não utilizo o Firewalld, mas quem utiliza precisa instalar o pacote:

yum install fail2ban-firewalld

Antes de fazer a nossa configuração, precisamos acertar um erro no arquivo jail.conf, que impede que o sistema envie e-mail caso haja algum bloqueio.

(continue reading…)

Quando utilizamos o Squid autenticando usuários ou grupos no Active Directory, temos a possibilidade de fazê-lo utilizando o serviço winbindd.

Entretanto a permissão default da pasta /var/lib/samba/winbindd_privileged está incorreta e não permite que o squid tenha acesso, além disso se você alterar a permissão para squid:squid ou para o modo 777, o serviço winbindd não aceitará a configuração e dará o seguinte erro: “invalid permissions on socket directory /var/lib/samba/winbindd_privileged”.

Para corrigirmos o problema teremos que acertar as configurações da pasta “/var/lib/samba/winbindd_privileged”, para que então os serviços winbindd e squid funcionem perfeitamente.

(continue reading…)

A porta default do SSH (tcp 22) recebe uma quantidade enorme de ataques, e a maioria delas podem ser evitadas modificando a porta de acesso do SSH.

Nesse tutorial vamos ver o passo a passo completo para alterarmos a porta de acesso do serviço SSH.

Primeiro vamos editar o arquivo de configuração do SSH, para isso digite:

vim /etc/ssh/sshd_config

Vamos alterar a porta que default é 22 para 2242:

Port 2242

(continue reading…)

Pessoal, mais um artigo que complementa a série de artigos sobre o Snort.

O Barnyard2 utiliza o arquivo sid-msg.map para indexar a descrição dos eventos do Snort, e quando ativamos algumas regras que não estão no arquivo sid-msg.map o Barnyard2 gera um erro no syslog e consequentemente adiciona no Banco de Dados uma descrição padrão: “Snort Alert [gid:sid:revision]”.

Segue o erro do syslog:

Aug 18 06:43:51 snort barnyard2: INFO [dbProcessSignatureInformation()]: [Event: 157] with [gid: 1] [sid: 21355] [rev: 3] [classification: 4] [priority: 2]
Aug 18 06:43:51 snort barnyard2: was not found in barnyard2 signature cache, this could lead to display inconsistency.
Aug 18 06:43:51 snort barnyard2: To prevent this warning, make sure that your sid-msg.map and gen-msg.map file are up to date with the snort process logging to the spool file.
Aug 18 06:43:51 snort barnyard2: The new inserted signature will not have its information present in the sig_reference table.
Aug 18 06:43:51 snort barnyard2: Note that the message inserted in the signature table will be snort default message “Snort Alert [gid:sid:revision]”
Aug 18 06:43:51 snort barnyard2: You can allways update the message via a SQL query if you want it to be displayed correctly by your favorite interface

Para resolver o problema vamos atualizar o arquivo sid-msg.map.

(continue reading…)

Bom pessoal,

Quem seguiu até o último tutorial deve ter percebido que o script de inicialização do Barnyard2 fica no diretório /etc/init.d/, como o CentOS 7 está descontinuando essa forma de trabalho, o script está dando alguns erros, mas mesmo assim o barnyard2 é iniciado. Entretanto, podemos abandonar esse script de inicialização e criarmos um novo script para iniciarmos o Barnyard2 com o SystemD e já utilizarmos algumas melhorias que a ferramenta oferece, como por exemplo: dependência do serviço do Mysql (MariaDB) e reinicialização automática caso o serviço pare de funcionar. ;D
(continue reading…)

Dando continuidade ao artigo anterior (Instalando o Snort (NIDS) no CentOS 7), vamos agora instalar o Barnyard2, responsável por vigiar a inclusão de novos registros no arquivo de log do Snort e enviá-los para um Banco de Dados, no nosso caso vamos utilizar o Mysql ou MariaDB no CentOS 7.

Vamos instalar as dependências:

yum install mariadb-devel mariadb-server

Criar uma pasta temporária para compilar o Barnyard2:
(continue reading…)

Hoje nenhum administrador de redes pode abrir mão da segurança da rede que administra, pensando nisso fiz esse tutorial explicando passo a passo a instalação e configuração do Snort um NIDS (network intrusion detection system) e em NIPS (network intrusion prevention system).

No nosso tutorial vamos supor o seguinte cenário:

Na imagem acima, vemos que é feito um mirror (espelho) de 3 portas importantes, 1 do firewall (interface interna) e 2 do cluster do XenServer (interface interna), no qual reside todos os servidores virtuais, consequentemente todo tráfego é direcionado para a segunda interface de rede do nosso servidor, no qual eth0 é a interface conectada a rede local e a eth1 é a interface que vai receber o tráfego a ser analisado. A interface eth1, que vai receber o tráfego a ser analisado, não terá configuração ip, a fim de evitar a mistura de tráfegos.
(continue reading…)

Continuando o artigo anterior, já temos o nosso Servidor Windows rodando o Active Directory com a hora atualizada com os servidores NTP do www.ntp.br Oficiais:

• a.st1.ntp.br
• b.st1.ntp.br
• c.st1.ntp.br
• d.st1.ntp.br
• a.ntp.br
• b.ntp.br
• c.ntp.br
• gps.ntp.br

Agora vamos configurar os nossos servidores Linux para sincronizar o NTP com o Servidor principal de NTP interno, que no nosso tutorial é o domainserver.local.seweb.corp, no qual possui o Active Directory.

Abaixo segue a topologia sugerida:

(continue reading…)