Template Servidor Debian: mudanças entre as edições

De ISPUP!
Ir para navegação Ir para pesquisar
Sem resumo de edição
Sem resumo de edição
Linha 32: Linha 32:
A programação do script não faz algumas coisas como:
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, você precisa criar as regras e fechar ao máximo seu sistema.
* 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 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.
* 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 seguranca servico sshd|'''"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"

Edição das 15h06min de 22 de janeiro de 2023

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.
  • Desabilita o APPARMOR. Alguns programas podem necessitar de uma configuração mais aprofundada do APPARMOR para que funcionem 100%. Como é um item de segurança do sistema, no script você pode optar por não remove-lo.
  • 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 responsável do IP.
  • 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"