Template de Servidor Debian GNU/Linux

Introdução

Certa vez ouvi de um amigo, que todo bom sysadmin é preguiçoso e existe uma certa verdade nisso. Sempre que existe uma tarefa ou processo que se repete inúmeras vezes, tratamos de criar ferramentas para automatizar essas tarefas. Existem diversas ferramentas para automatizar nossa vida com por exemplo o Ansible e containers personalizados em Docker. Enfim, cabe aqui o conhecimento e a criatividade de cada profissional para resolver os problemas e agilizar os processos, mas temos que ter sempre a qualidade e segurança em mente.

Configurar um ou mais serviços de Redes em um servidor pode ser rápido mas às vezes muitos sysadmins pecam em alguns cuidados de segurança como:

• Fazer sempre uma instalação limpa e básica do sistema para começar. Não adicionar nada que não seja realmente necessário para o projeto. Quanto mais coisas rodando em seu servidor, mais chances dele se tornar inseguro em algum momento.
• Não ter bem definido o que precisa e o que não precisa estar público no servidor.
• Deixar de criar um sistema de segurança para o seu servidor e quando digo isso não estou falando somente de um simples filtro de pacotes mas também de outros elementos que monitoram a integridade do sistema de arquivos, as tentativas de invasão, que executam ações de defesa e que nos avisam de que algo está acontecendo. A junção de todos esses elementos forma o que conhecemos como Firewall.
• Não ter nenhum monitoramento do sistema como: serviços, atualizações, logs, etc.
• Não fazer nenhuma atualização ou correção dos sistemas, deixando-os cheios de falhas e vulneráveis. Já ouviu falar sobre Portas de Amplificação DDoS? Elas surgem desses sistemas abandonados, mal configurados e também de dispositivos de Internet, que não tem atualização por parte do fabricante; que são também instalados incorretamente e ficando expostos na Internet.

Fazer tudo isso pode ser trabalhoso e cansativo quando administramos diversos servidores, mas neste artigo vou ajudar a simplificar um pouco a sua vida e trazer mais segurança para a sua Operação. Como sempre trabalhando com sistemas Debian GNU/Linux, estou trazendo aqui um shell script em bash que me ajuda na configuração básica de cada servidor, automatizando algumas tarefas e deixando meu ambiente praticamente pronto para o projeto.

O que o script faz

Esse script vai preparar o básico para o seu servidor, seja ele qual for, vai configurar todo o ambiente para que você tenha:

• Configuração dos repositórios do Debian.
• Configuração de ambiente como: hostname, prompt, lang, sysctl, irqbalance.
• Instalação de algumas ferramentas úteis: neofetch, net-tools, nftables, htop, iotop, sipcalc, tcpdump, vim-nox, curl, gnupg, rsync, wget, host, dnsutils, mtr-tiny, bmon, sudo, expect, tmux, whois, ethtool, dnstop.
• Configurar o timezone do sistema. Eu tenho sempre por preferência e quando posso, escolher o UTC.
• Configurar o MSMTP para enviar as notificações de atualizações e logs do sistema via e-mail. Utilizo ele apenas quando o servidor sendo configurado não é um servidor de e-mail (MTA). Nesse caso ele tem essa função de enviar os e-mails. Por exemplo se você estiver montando um servidor Web, com o MSMTP o sistema pode enviar e-mails mais facilmente. Após a configuração, ele te envia um e-mail de teste para sabermos se está tudo OK com ele.
• Coloca APPARMOR em modo complain. Alguns programas podem necessitar de uma configuração mais aprofundada do APPARMOR para que funcionem 100%.
• Instala e configura o chrony para usar os servidores NTP/NTS do NIC.br. É importantíssimo que todo servidor tenha data e hora corretos.
• Instala o iWatch para monitorar em real time o sistema de arquivos e te enviar notificações quando houver alguma mudança nesses locais: /bin, /sbin/ e /lib.
• Instala o fail2ban habilitando pelo menos o monitoramento do ssh. Em caso de detecção o IP do atacante é colocado em blackhole via ip route e o sistema envia um e-mail sobre o incidente para o contato de abuse responsável do IP banido.
• Instala e configura o apticron que envia notificações de atualizações do sistema por e-mail.
• Instala e configura o logwatch que envia diariamente um relatório de diversas coisas que aconteceram no sistema, via e-mail.

O que o script não faz

A programação do script não faz algumas coisas como:

• Não cria as regras de filtros de pacote. Isso dependerá muito do que rodará no sistema, se vai usar IPTables ou NFTables por exemplo; quais serviços serão instalados, enfim, essa parte é muito pessoal. Embora não tenha neste artigo, você precisa criar as regras e fechar ao máximo seu sistema.
• Ele não olha os e-mails por você, então crie um hábito de checar regularmente os e-mails e ver se não existe alguma notificação a ser tratada.
• Ele não configura nada que não tenha sido comentado neste artigo. Na dúvida sempre examine o código para tentar entender e adaptar mudanças que te sejam interessantes.
• Como comentei o fail2ban estará configurado para o serviço sshd, mais para frente neste artigo vou comentar sobre os 2 arquivos dele e caso tenha outros serviços abertos na Internet, procure dar uma estudada no fail2ban para monitorá-los. Dê uma lida nesse meu outro artigo "Melhorando a segurança do serviço sshd" para reforçar a segurança desse serviço.

Variáveis do script

Dentro do script coloquei algumas variáveis para que o script possa automatizar as tarefas e procure configurá-las se quiser ter sucesso no uso dele. Vamos conhecê-las:

• EMAIL_LOGS: essa variável é obrigatória porque faz parte do monitoramento do seu sistema de logs, não queremos um servidor zumbi na Internet. Aqui você coloca um e-mail para onde serão enviados os logs sobre o sistema operacional e serviços rodando. Esses e-mails são diários e falam de diversas coisas que aconteceram no sistema como por exemplo: as diversas tentativas de conexão ssh, tentativas de acesso à paginas do seu site que não existem, usuários que se logaram recentemente no seu servidor, espaço em disco e muitas outras informações interessantes que o logwatch proporciona. Aqui estamos falando de informações que vão te fazer perceber que alguém ou algum bot está tentando fazer algo errado com teu servidor ou que teu sistema precisa de alguma atenção.
• EMAIL_UPGRADES: essa também é uma variável obrigatória e pode ser o mesmo valor de EMAIL_LOGS se preferir. Para esse e-mail serão enviadas as notificações que o sistema precisa de atualização e que tipo de atualização para que você possa avaliar se são urgentes ou não.
• HOSTNAME: o próprio nome já sugere o que seja. Todo servidor precisa ter um hostname até mesmo para que você possa identificá-lo no meio das notificações que irá receber. Crie nomes padronizados e que possam te ajudar a identificar onde estão esses equipamentos. Eu sei que é bacana dar nomes do tipo: bart, lisa, burn, homer, mail, ftp, http ou coisas do gênero mas esses nomes não te deixam claro onde que esses sistemas estão localizados certo? Se você tiver por exemplo 2 servidores com o mesmo hostname, quem é quem? Eu fazia assim também no passado e hoje procuro fazer bom uso e sentido dos hostnames. Um exemplo de boa prática para hostname: RJO-DC01-WEBSERVER-01. Nesse exemplo consigo identificar pelo hostname que esse servidor estaria no Rio de Janeiro, no Datacenter 01 e é o servidor Web de número 01. Conseguiu enxergar a diferença? Uma informação tão simples, mas que pode ser muito útil.
• MTA: essa variável por padrão é N (não). Quando que essa variável seria um Y(sim)? Se você tiver montando um servidor de correio (MTA server), por exemplo: um servidor postfix, exim, sendmail, etc. Na maior parte das vezes montamos diversos servidores e em sua grande maioria não será um MTA server. Nesse caso precisamos ter um sistema para facilitar o envio das notificações por e-mail. Aqui usaremos os pacotes msmtp e msmtp-mta que terão a função de se conectar em um MTA server de sua escolha e enviar as notificações que precisamos. Eu por exemplo uso o Google para os meus sistemas: crio uma conta no GMail, habilito o 2FA e gero uma senha para "sistemas não confiáveis" e utilizo essa conta para enviar os e-mails a partir dos servidores.
• MSMTP_FROM, MSMTP_HOST, MSMTP_USER e MSMTP_PASS: essas são as informações que usaremos no msmtp e são bem intuitivas. O MSMTP_FROM será o e-mail de quem enviará as notificações, por exemplo a conta que criamos no Gmail. O MSMTP_HOST é o endereço do servidor de e-mail (MTA server) que usaremos e MSMTP_USER e MSMTP_PASS formam a credencial de acesso para poder enviar os e-mails. Por padrão a configuração assume que usará a porta 587/TCP. Abaixo um exemplo de como ficaria essa configuração:

MTA="N"
MSMTP_FROM="[email protected]"
MSMTP_HOST="smtp.gmail.com"
MSMTP_USER="[email protected]"
MSMTP_PASS="pnxxxxxxxxxxlupw"

• APPARMOR: por padrão o script coloca o APPARMOR como desabilitado "0" mas se quiser manter habilitado e depois colocar em modo complain, basta colocar como "1". Isso é apenas para que não cause problemas com algum serviço que você irá configurar posteriormente. Se você for utilizar o APPARMOR mude a variável para "1" e deixe como enforced mas saiba que você poderá, em algumas situações, ter que estudar e configurar corretamente este sistema. Muitos artigos na Internet inclusive solicitam que desabilite este serviço para não causar problemas com seus programas. Ele é excelente para a segurança desde que esteja devidamente configurado mas se estiver apenas instalado poderá te causar algumas dores. Vou citar apenas um exemplo: na configuração do unbound se você não configurar o APPARMOR corretamente, nem o arquivo de log do unbound em /var/log/unbound, ele permitirá ser usado.
• MITIGATIONS: essa variável controla a mitigação no kernel para vulnerabilidades encontradas nos processadores. Vulnerabilidades como Spectre e Meltdown. Mitigar essas vulnerabilidades reduz o poder de processamento e às vezes podem não ser necessárias em um ambiente mais controlado. Nesse caso manter desabilitado pode trazer benefícios de processamento em detrimento à segurança. Para habilitar a mitigação no modo default, mude o valor para "auto".
• LANG, LANGUAGE e DISTRO_NAME: são variáveis de ambiente do sistema para setar a linguagem e capturar o nome da distribuição Debian que está usando. Se for alterar só altere a LANG e LANGUAGE.
• TIMEZONE: como eu havia comentado, costumo usar o padrão em UTC. Imagine que você tem servidores espalhados pelo mundo, fica mais fácil configurar todos para UTC e ter um controle melhor do que cada um com um timezone diferente. Sem falar que a grande maioria das notificações de segurança chegam com logs em horário UTC e isso facilita sua vida. Se quiser mudar utilize o comando: timedatectl list-timezones e veja qual usar na variável.
• F2B_ENABLE: default é "Y", se não desejar instalar e habilitar o Fail2Ban, mude para "N".
• F2B_IGNOREIP: essa variável é muito importante para que o fail2ban não bloqueie IPs confiáveis e evitar que algum ataque de spoofing cause um bloqueio indevido de acesso. IPs que costumo colocar nessa variável: 127.0.0.1, ::1, o IPv4 e IPv6 do servidor, o IPv4 e IPv6 do gateway do servidor, IP do DNS usado no servidor e IPs e/ou redes que uso como origem do acesso remoto. Os IPs e prefixos podem ser colocados usando espaço entre eles na variável.
• F2B_BANTIME: tempo de banimento do fail2ban, nesse caso por padrão no script está configurado para 72h mas fique à vontade de alterar.
• F2B_MAXRETRY: número de tentativas para o acionamento do banimento. Também altere como desejar, por padrão está como 5.
• F2B_XARF: por padrão o fail2ban será configurado para notificar os contatos de abuse dos IPs banidos usando o XARF. Caso só queria apenas banir, sem notificar, basta mudar essa variável para N(não).

Estas são as variáveis que o script utiliza para a configuração inicial do seu sistema. O bom é que você poderá deixar sempre pré-configurado e executar nos novos sistemas, agilizando seu processo e deixando o sistema com uma certa condição de segurança e monitoramento.

Etapas e configurações do script

Aqui vou comentar apenas os lugares onde você encontrará informações mais importantes, caso deseje modificar alguma coisa. Procure também dar uma estudada no script e adaptar novas configurações e situações. Aceito contribuições que ajudem a melhorar mais nosso script, só me contactar. Veja como me contactar aqui.

A configuração dos repositórios do Debian é feita aqui: /etc/apt/sources.list.

O hostname é configurado aqui: /etc/hostname.

Os ajustes de sysctl são colocados aqui: /etc/sysctl.d/local.conf detalhe que esse arquivo é lido somente em tempo de boot ou se fizer manualmente sysctl -p /etc/sysctl.d/local.conf.

O prompt do sistema é configurado aqui: /root/.bash_profile.

As configurações do msmtp, que faz a conexão com o MTA server para envio dos e-mails fica aqui: /root/.msmtprc.

O apticron que envia as notificações de atualizações do sistema fica aqui: /etc/apticron/apticron.conf.

O logwatch que envia o log diário sobre as condições do seu sistema fica aqui: /etc/logwatch/conf/logwatch.conf.

A configuração dos servidores NTP/NTS do NIC.br pode ser encontrada aqui: /etc/chrony/sources.d/nic.sources.

O iWatch, que monitora em tempo real seu file system, é configurado em xml e encontra-se aqui: /etc/iwatch/iwatch.xml.

O fail2ban temos 2 arquivos sendo que apenas um pode ser necessário incluir alguma nova configuração: /etc/fail2ban/jail.local. O outro arquivo que não necessita mexer seria esse: /etc/fail2ban/action.d/route.local.

Alguns comandos do fail2ban para administração

Vamos supor que você queira saber quem está bloqueado e de qual serviço ou que queira desbloquear alguém manualmente. Aqui vão alguns comandos:

Para ver o status do fail2ban e quais serviços monitorados:

# fail2ban-client status
Status
|- Number of jail:      6
`- Jail list:   dropbear, nginx-botsearch, nginx-http-auth, php-url-fopen, portsentry, sshd

Para ver um determinado serviço e quem foi bloqueado:

# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     26
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   5.xxx.xxx.115

Para remover do banimento o IP:

# fail2ban-client unban 5.xxx.xxx.115

Uma outra forma de descobrir quem está banido do sistema:

# ip route | grep blackhole

Como comentei no início o fail2ban foi programado por padrão para notificar o contato de abuse responsável do IP banido usando a ação XARF e encontramos em /etc/fail2ban/action.d/xarf-login-attack.conf a configuração e texto usado nas notificações.

A instalação do Debian GNU/Linux

Utilize esse script apenas em sistemas recém instalados, nunca em servidores já configurados e em produção porque ele vai mexer em configurações que talvez você já tenha ajustado. Procure fazer uma instalação limpa do Debian, mantendo apenas o básico. Na seleção de pacotes do Debian deixe apenas esses 2 itens selecionados e o restante desmarcado:

Prompt do sistema após rodar o script

O script utiliza um prompt retirado do programa criado pelo Professor Kretcheu e disponibilizado aqui https://github.com/kretcheu/devel/blob/master/prompt o prompt nada mais é que a configuração da variável bash chamada de PS1. Nosso sistema deve ficar assim:

Nele temos as informações de user do terminal em uso, o hostname, diretório atual em que se encontra o usuário e o horário do sistema.

Após terminar de executar o script, reinicie o sistema para fazer valer algumas configurações e até mesmo para testar se tudo está rodando como deveria.

O script

Finalmente chegamos no nosso script e é este que se encontra aqui no Github: https://github.com/gondimcodes/servidor_template

Finalizando

O script é livre e pode ser modificado e redistribuído mas sempre mantenha os créditos de quem desenvolveu, é um jeito de você valorizar o trabalho do autor.

Estude as aplicações que utilizei no script para que você possa entender melhor o funcionamento delas e até criar novas configurações que te serão úteis.

Essa documentação foi útil? Compartilhe, divulgue e ajude outras pessoas. Meus contatos podem ser vistos aqui.