Melhorando a segurança do seus servidores em FreeBSD

[helldanger1]

Pra quem me conhece ou já leu meus outros artigos, já percebeu que minha vida é o FreeBSD. Sinceramente nunca usei o Linux como sistema de um servidor (apenas como desktop), mas este artigo, apesar de ser voltado para o FreeBSD (hihi), com certeza ajudará a você que usa Linux a melhorar a segurança dos seus servidores.

Por: Alcir Cardoso


Definições gerais


Com certeza um dos principais problemas hoje não são os verdadeiros crackers que potencialmente tem capacidade de tomar posse dos nossos sistemas, mas sim, aqueles "metidos a crackers" que vivem scaneando nossos sistemas, procurando portas, usando o brute force e fazendo conexões telnet em todas as portas abertas que encontram.

Apesar de na maioria das vezes não representarem um risco real, já que ninguém mais usa "love" como senha, sempre são uma pedra no sapato, lotando nossa conexão, aumentando o tamanho dos nossos logs, deixando serviços assoberbados com tantas conexões. Para ter uma noção de como são chatos esses "metidos a sabichão" certa vez tive um link de 2Mb lotado apenas com ICMP. É dose pra elefante.

Nesse artigo pretendo dar algumas dicas de segurança que eu comecei a usar ao longo do tempo que uso FreeBSD. Talvez os exemplos não sirvam para outras distribuições, mas os princípios com certeza lhe ajudarão a chegar a uma solução para a sua distribuição.

 

[helldanger1]

Parando o que não usa
Mais ou menos 70% das minhas instalações de FreeBSD são para fazer router com proxy, e por padrão meu se eu não uso eu paro, por exemplo, em um firewall pra que usar as portas USB?? Adicione estas linhas no teu /etc/rc.conf.

#Desabilita os USBs
usb_enable="NO"

#Desabilita o file server padrão do free
nfs_reserved_port_only="NO"

#para o sendmail, que é default do free
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

#Desativa o syslog na porta udp 514
#isso só é usado para servidor de log
#e é mais uma porta esperando um scan
syslogd_flags="-ss"

#O portmap é utilizado para RPC - Remote Procedure Call
portmap_enable="NO"

#Limpa o temp
clear_tmp_enable="YES"

Com certeza tem mais coisas, mas aí depende da realidade de cada sistema e também do que você usa no teu server, por exemplo, se você tem um script que manda email, não vai parar o sendmail.

Outro pacote default do FreeBSD é o named, mas esse eu sempre configuro nos meus routers, um resolução DNS na rede local é melhor do que ir buscar lá longe...

 

[helldanger1]

Serviços
Bom, lembram que no inicio do arquivo eu falei que certa vez tive um link de 2Mb lotado apenas com ICMP (ping). Pois é, sei que parece brincadeira mas foi.

Desde então sempre uso umas regrinhas a mais nos meus arquivos /etc/rc.local.

#fechando o icmp na interface externa
/sbin/ipfw add deny icmp from any to any in via bge1 icmptypes 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18

Com essa regra eu bloqueio todo o icmp que passa na interface externa (bge1) do servidor. Ela também irá bloquear um ping vindo da rede interna para a rede externa.

Outro problema é o ssh. Este serviço com um pouco de planejamento pode ser liberado para apenas alguns hosts dos quais você acessa os teus sistemas.

No exemplo abaixo vou mostra como liberar a conexão ssh vinda de um host e bloqueando toda tentativa fora dessa regra. Adicione estas linhas no /etc/rc.local.

/sbin/ipfw add allow tcp from 200.xxx.xxx.98 to 200.yyy.yyy.38 22
/sbin/ipfw add allow tcp from 200.yyy.yyy.38 to 200.xxx.xxx.98 22 

/sbin/ipfw add deny all from any to any 22 in via bge1

No exemplo acima entenda 200.yyy.yyy.38 como o ip da sua casa por exemplo, e 200.xxx.xxx.98 o ip do servidor onde você irá conectar. Na outra linha, bge1 é a interface externa.

Um outro serviço que as vezes instalamos para uso próprio mas que não precisa ficar aberto ao público é o ftp, o exemplo acima pode ser utilizado alterando-o para a porta 21.

Mais uma coisa a seu preocupar, normalmente quando você instala um proxy como o Squid, nunca fecha a 3128 na interface externa. Já pensou nisso? O teu proxy não é público para que outras pessoas fiquem utilizando ele...

 

[helldanger1]

Spoofing e outros



Sinceramente o UDP é mais usado para p2p, mas alguns serviços que são muitos necessários o udp é super necessário, é o caso do DNS. Essas linhas são do rc.local.

#Aqui libero o dns e fecho todo o resto do udp nas duas interfaces
#Bloqueio de udp
/sbin/ipfw add allow udp from any to any 53
/sbin/ipfw add allow udp from any to any 53
/sbin/ipfw add deny udp from any to any in via bge0
/sbin/ipfw add deny udp from any to any out via bge0
/sbin/ipfw add deny udp from any to any in via bge1
/sbin/ipfw add deny udp from any to any out via bge1


# bloqueia pacotes fragmentados/alterados/inconformes
/sbin/ipfw add drop tcp from any to any frag
/sbin/ipfw add drop tcp from any to any tcpflags syn,rst
/sbin/ipfw add drop tcp from any to any tcpflags syn,fin
/sbin/ipfw add drop all from any to any ipoptions lsrr
/sbin/ipfw add drop all from any to any ipoptions ssrr
/sbin/ipfw add deny tcp from any to any ipoptions ssrr,lsrr,rr

#Aqui bloqueando o spoofing
# Bloqueio de pacotes com endereço origem de classes 
#de endereçamento IP reservadas
/sbin/ipfw add deny ip from 10.0.0.0:255.0.0.0 to 200.xxx.xxx.98 via bge1 in
/sbin/ipfw add deny ip from 172.16.0.0:255.0.0.0 to 200.xxx.xxx.98 via bge1 in
/sbin/ipfw add deny ip from 192.168.0.0:255.255.0.0 to 200.xxx.xxx.98 via bge1 in

No exemplo acima o 200.xxx.xxx.98 é o ip publico da interface externa.

 

[helldanger1]

Brute Force Blocking



Este aqui é um script que eu achei aqui no VOL e dei uma melhora sem falar na adaptação para FreeBSD.

O primeiro passo foi instalar o bash.

Depois o script:

#!/usr/local/bin/bash

MODE="AUTO"
#MODE="MANUAL"

if [ -f /var/log/auth.log ] ; then
   ips=$(cat /var/log/auth.log | grep -i illegal | grep -i sshd | awk -F" " {'print $15'})

   attempts=1

   for ip in $ips ; do

      lastip=$ip

      if [ "$lastip" == "$ip" ] ; then
         attempts=$(expr $attempts + 1)
         if [ $attempts -ge 3 ] ; then
            echo -n "Brute force SSHD ataque detectado vindo do ip $ip" > /dev/ttyv0
            attempts=1
            lastip=""
            blocked=$(ipfw list | grep $ip | grep deny)
                   if [ "$blocked" ] ; then
               echo -n "> Ip já bloqueado. Continuando com o scan" > /dev/ttyv0
               echo -n " " > /dev/ttyv0
            else
               if [ $MODE == "MANUAL" ] ; then
                  echo "> Você deseja bloquear este ip nas regras do IPFW? (y/n)"
                  read resp
                  if [ "$resp" == "y" ] ; then
                  /sbin/ipfw add deny ip from any to $ip
                  /sbin/ipfw add deny ip from $ip to any
                     echo "> IP $ip adicionado as regras de bloqueio"
                     echo " "
                  fi
               else
                  /sbin/ipfw add deny ip from any to $ip
                  /sbin/ipfw add deny ip from $ip to any

                  echo -n "> IP $ip adicionado as regras de bloqueio" > /dev/ttyv0
                  echo -n " " > /dev/ttyv0
                #echo $ip >> /var/log/ips
               fi
            fi
         fi
      fi

   done

fi

Agora salve, de permissão de executável e agende sua execução no cron, eu coloquei a cada 10 min.

Acredito que lendo ele você já entenderá seu funcionamento, mas explicando ele lê as últimas 15 linhas do arquivo /var/log/auth.log em busca de tentativas de login, e bloqueia os ips que realizaram 3 tentativas infelizes.

Esta solução não precisa ser usada se você esta fazendo controle na conexão na porta 22.

 

[helldanger1]

Considerações finais



Nem todo mundo gosta de deixar seu sistema com regras de acesso tão restritas, porque sempre estão em movimento, utilizando vários locais para realizar suporte e manutenção aos seus sistemas.

Portanto, tudo depende de como e de onde você acessa seus sistemas. Opções web sempre são interessantes, pois dificilmente você terá um firewall bloqueando o teu acesso a determinados serviços disponível no teu servidor.

Espero ter ajudado, minha intenção não foi dar aula de segurança, longe disso, até porque eu também não sou um expert. Mas minha intenção foi alvoroçar seus sentidos a criar regras cada vez mais específicas para cada caso sem prejudicar o rendimento final.

Vale ressaltar que regras de firewall usam memória e processador. Daqui a pouco sua net vai estar lenta devido ao teu router estar "de pernas abertas" com tantas entradas no firewall.

Linuxmaníacos, usem, abusem da criatividade, façam, fucem, mexam, acrescentem, errem, acertem, criem, desenvolvam, apaguem e façam de novo. Com certeza uma ferramenta que você desenvolveu agora pode ser a ideal para esta solução, mas e para a próxima??? Mas e aquelas regras que você criou no verão passado? será que não estão precisando de um novo release? Otimização, essa palavra é chave. Ou então aquele teu 333Mhz com um firewallzinho pode ficar legal né?


By:Alcir Cardoso