Nomenclatura Debian

Logo Debian

 

Muitas vezes ao atualizar um Debian, precisamos ver sua versão no /etc/debian_version e depois procurar a source-list correspondente a esta numeração, sendo que nem sempre lembramos a o nome da versão do debian.

Todos os codinomes das versões Debian seguem nomes de personagem da saga Toy Story.

O ciclo de desenvolvimento das versões do Debian passa por três fases:

• “Unstable” – instável
• “Testing” – teste
• “Stable” – estável

A versão unstable tem sempre codinome SID.

Segue abaixo versões:

9.0 — Strech 05 de Janeiro de 2017
8.0 — Jessie 25 de abril de 2015
7.0 — Wheezy 4 de maio de 2013
6.0 — Squeeze 6 de fevereiro de 2011
5.0 — Lenny 15 de fevereiro de 2009
4.0 — Etch, 8 de abril de 2007
3.1 — Sarge, 6 de junho de 2005
3.0 — Woody, 19 de julho de 2002
2.2 — Potato, 15 de agosto 2000
2.1 — Slink, 9 de março de 1999
2.0 — Hamm, 24 de julho 1998
1.3 — Bo, 2 de junho de 1997
1.2 — Rex, 1996
1.1 — Buzz, 1996

 

Lista de IPS atualizada do WHATS APP

IPS WHATSAPP

Lista atualizada de IP’s que o Whats App utiliza para a comunicação do aplicativo com os servidores.  A relação contém todos os blocos IPV4 e IPV6 utilizadas pelo app.

No caso de você querer bloquear o tráfego em sua rede para o Whats App, terá que bloquear todos os IPS na lista. Se não tiver saída v6, bloqueie apenas os IPv4.

LISTA DE IP’s: Clique aqui.

Para bloquear por nome, utilize os DNS listados nesta página: https://github.com/ukanth/afwall/wiki/HOWTO-blocking-WhatsApp

 

Aumentando segurança contra Exploits!!!

Security_Exploits

Um exploit é um software cuja finalidade é explorar algum bug conhecido em outro software fazendo com que este bug explorado tenha algum tipo de comportado determinado, como os abaixo:

– Conceder permissão de acesso a algumas informações,

– Acesso de escrita e leitura nos files do software explorado,

– Que faça com que o software explorado deixe de funcionar,

– Que apague os arquivos do software explorado

– Ou uma das piores formas, conceder acesso privilegiado ao Sistema Operacional

– Dentre outras ações.

 

Em resumo, um exploit é um software mal intencionado que geralmente vai trazer problemas ao Administrador da Rede, principalmente se ele tiver servidores de bunda da lua (Nunca faça isso, tenha amor próprio!!!).

Bom, a solução que vou citar aqui, é a que eu utilizo no meu dia-a-dia. Claro que junto com algumas outras regras de segurança. Enfim, vamos lá.

Na empresa onde eu trabalho, não tenho a necessidade de estar recebendo muitos acessos de fora do Brasil, todos os nossos serviços online são consumidos por IP’s nacionais. Raras são as exceções em que um cliente viaja para fora do Brasil e precisa imprimir um boleto e etc e tal.

Mas como disse, todos os nossos serviços que são disponibilizados na web, são consumidos por IP’S brasileiros. Então por quais motivos eu deixaria o resto do mundo ficar acessando meus serviços on line? Nenhum.

Você já reparou o log de acesso SSH no ser roteador de borda? O log de tentativas telnet? Melhor, dá uma olhada no teu mail.log e veja a quantidade de conexões maliciosas vindas de fora do Brasil. São muitas.

Por conta do exposto acima, eu resolvi bloquear o resto do mundo inteiro da minha rede, conexões do resto do mundo só são permitas caso o Socket já esteja aberta e tenha sido solicitado por parte da minha rede, caso contrário: “Tchau pacote malicioso!”.

Mas antes, vamos pensar numa situação, muitas empresas colocam seus servidores de email em Hosting’s, alguns deles brasileiros outros não, algumas empresas de hosting do Brasil, mantém servidores dedicados fora do Pais pela relação custo-benefício.

Isso acaba gerando um tráfego “gringo” na porta 25, que faz com que muitos pacotes de IPS fora do Brasil cheguem em suas rede sem intenção maliciosa, que no caso, DEVEM ser liberados.

Ou seja, pode bloquear tudo que for de fora do Brasil, mas mantenha aberta a porta 25, que é por onde os servidores de email (Mail Transfer Protocol) se comunicam entre sim para entrega de mensagens.

Para pegar os IPS Brasileiros, eu consulto o site http://www.blockcountryip.com/ onde tem a relação de ips de todos os países (IPv4). A relação já vem pronta pro modelo Cisco IOS (DENY FROM). Este site diz todos os ips que devem ser bloqueados de determinado país.

deny_from_brazil

A lista é grande, são 278 prefixo brasileiros.

Claro que não vamos colocar uma regra bloqueando cada prefixo que não esteja na lista acima, mas sim permitir todos os ips brasileiros e em no final bloquear o resto 0.0.0.0/0. Afinal de contas, devemos sempre otimizar o processamento do roteador

Ou seja, para que possamos fazer um bloqueio bonitinho para IP’s estrangeiros que detém cerca de 95% do tráfego malicioso (Spam, sniffers, exploits, brute force, Pings, Flood UDP), devemos (no meu caso, avalie o seu!) proceder da seguinte forma.

01 – Liberar todo o tráfego na porta 25, independente se o IP é brasileiro ou não.

02 – Manter seu servidor web sempre atualizado e estar antenado em patches de segurança.

03 – Liberar a porta 80 dele, independente se o IP é brasileiro ou não. Sempre tem clientes que viajam para o exterior e precisam gerar o boleto para enviar para alguém no Brasil pagar.  Tenha atenção quanto a regra 02 por favor.

04 – Criar regras para LIBERAR (permit ou accept, varia de IOS para IOS) os 278 prefixos v4 de Origem nacional.

05 – Bloquear todo o tráfego restante representado por 0.0.0.0/0

06 – Observando se houve atualizações na lista (próximo post será sobre atualizações de Ips Brasileiros)

 

Pronto, com isso você eliminou os sniffadores chineses que todo dia varrem todas as portas de todos os seus IP’S, você bloqueou robos de estarem varrendo seu servidor WEB, você bloqueou um ataque de smtp autenticado no seu servidor de email. Você bloqueou qualquer tentativa de acesso SSH, Telnet, FTP ou qualquer outro serviço que o estagiário tenha levantado de teste e esqueceu de stopar o serviço (FDP!!!).

Entretanto, tudo o que foi falado acima não lhe protege contra ataques vindo de IP’S nacionais. 

Com certeza a China, EUA, Coréia… Devem ter servidores no Brasil com o intuito de continuar a sniffar suas portas, seus serviços e seus IP’s, mas dificilmente irão atacar por esses servidores.

Tem dois ditados na área de TI que devem sempre ser seguidos:

– Só Jesus salva, o resto faz Backup!

– Quem AMA, BLOQUEIA!

Se você ainda não teve a chance de contornar um ataque, ouça, é uma situação horrível. Portanto, BLOQUEIE!

IPS da APNIC – Ásia e Pacífico!

IPS DA APNIC

Regional Internet Registries

Algumas pessoas como eu, tem um certo receio com relação aos IPS asiáticos, tanto por questões de DOS distribuído, quanto por segurança mesmo. Os caras tão sniffando tudo que encontram pela frente. Caso tenha dúvida, analise as entradas de seu firewall ou roteador de borda. O que mais me chama atenção é o teste de todas as portas em todos os ips… Principalmente de IPS que fazem parte de algum ASN chinês.

Grandes blocos de IPS chineses, eu libero apenas a 80 e 25 in/out no firewall, o resto eu bloqueio.

A questão é… Como saber os blocos da APNIC para que possamos avaliar e bloquear? Simples, basta pegar os últimos reports da APNIC e utilizar um pouco de regex e fazer upload via shell no router ou firewall.

Nesta url tem os últimos registros da APNIC de blocos divulgados: ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-extended-latest

PS: Claro, ips chineses podem tunelar, comprar blocos africanos e propagar no seu ASN, fazer uso de um hosting… e etc..

Instalando Fail2ban no Debian Wheezy!

Fail2Ban

Evitando ataques bruteforce de SSH utilizando o Fail2ban

Atualmente ataques bruteforce (força bruta, aquele em que o atacante tenta n possibilidades de usuário/senha por segundo até conseguir quebrar a senha e entrar no sistema) estão muito mais frequentes do que nós imaginamos, basta uma leitura rápida (like debian) no arquivo auth.log para visualizarmos a quantidade de tentativas com milhares de usuários e senhas por dia.

O que cabe a um administrador de redes é prevenir o sistema contra estas ações maliciosas que muitos robôs e máquinas zumbis são programadas para fazer. Para evitar ataques deste tipo, eu utilizo algumas acl’s na borda e o Fail2Ban no firewall que analisa o tráfego e dependendo da análise ele bloqueia o IP ou range de ip por tempo determinado inserindo regras no firewall. O bom é que não é apenas no protocolo SSH, você pode configurar para conexões SMTP, TELNET, FTP e etc…

O Fail2Ban na verdade é uma estrutura de prevenção de intrusão, escrito na linguagem de programação Python que filtra os logs de entrada de logins no sistema e a partir desta análise insere regras no firewall para bloqueio destes acessos.

Em distribuições Linux Debian e like Debian você pode instalar via apt-get com o comando:

# apt-get install fail2ban

Ele irá instalar automaticamente. Após instalar você deve configurar o fail2ban editando o arquivo:

# vim /etc/fail2ban/jail.conf

Algumas variáveis importantes deste arquivo são estas:

• “ignoreip” se encontram os endereços de IPs que não vão ser bloqueados pelo programa.
• “bantime” se encontra o tempo em que o IP ficará banido/bloqueado pelo programa (o tempo é contado em segundos).
• “maxretry” temos o número máximo em que o IP pode tentar logar-se no seu servidor até ser bloqueado (recomendo que ponha no máximo 3).
• “logpath” refere-se ao arquivo de log onde são checadas as tentativas frustradas de login.

Recomendo que antes de editar o mesmo, você faça um backup do arquivo evitando que seja feita qualquer equívoco no fileconf do fail2ban:

# cp -ar /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.ori

Feito o backup, vamos implementar algumas configurações básicas editando o arquivo

# vim /etc/fail2ban/jail.conf

Importante inserir alguns hosts ou range de hosts que não serão bloqueados, afinal ninguém bloqueia a si mesmo. Então na linha ignoreip coloque o ip de localhost e o range da sua rede a qual você não gostaria de bloquear, deixe separados por um espaço:

ignoreip = 127.0.0.1/8 192.168.0.0/16

Após isso, sete a variável bantime para o tempo que você deseja que o ip fique bloqueado no firewall. Este tempo é em segundo, eu geralmente configuro um ban para 10 minutos. Se você quiser banir o IP ou range permanentemente, basta atribuir a esta variável um valor negativo.

bantime  = 600

Configure o tempo de varredura em segundos passados em que o Fail2Ban procura por IP’s abusivos ao sistema.

findtime = 600

E por final configure o número máximo de entradas frustradas que o atacante tentou acessar seu sistema errando login e senha.

maxretry = 3

Pronto, salve o arquivo e reinicie o Fail2ban:

# /etc/init.d/fail2ban restart

O programa está configurado e poderá ver ver os IPs bloqueados em /var/log/fail2ban.log.

Quando um atacante for bloqueado, ao tentar acessar seu servidor ele irá exibir a mensagem de conexão recusada para o atacante, algo similar a mensagem abaixo:

ssh: connect to host 10.10.58.5 port 22: Connection refused

No iptables, você visualiza as regras inseridas através da sintaxe:

iptables -nL fail2ban-ssh

Que deverá listar algo assim:

root@takakaos:/etc/fail2ban# iptables -nL fail2ban-ssh

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
REJECT     all  --  10.10.58.5        0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Para remover basta inserir o comando abaixo com o numero da regra (chain number) que você deseja remover. No meu caso seria remover o bloqueio para a primeira regra, que contém o IP 10.10.58.5

iptables -D fail2ban-ssh 1

Ou através da remoção do ip bloqueado (notar se na exibição do bloqueio através do iptables, a chain está dropando -j DROP ou está rejeitando -j REJECT)

iptables -D fail2ban-ssh -s 10.10.58.5 -j REJECT

Qualquer dúvida você pode acessar o manual (in english) na url abaixo.

http://www.fail2ban.org/wiki/index.php/MANUAL_0_8

Nota: Versão utilizada: 0.8.9-1