Con­fi­gu­rar um servidor seguro é uma das tarefas mais im­por­tan­tes para os ad­mi­nis­tra­do­res. Isto aplica-se não só aos ser­vi­do­res au­to­ge­ri­dos, mas também ao hardware alugado. Medidas como a proteção por senhas, con­fi­gu­ra­ções adequadas do SSH e atu­a­li­za­ções regulares garantem um pacote de segurança abran­gente.

Con­fi­gu­rar um servidor seguro: quem é o res­pon­sá­vel?

Alugar um servidor próprio é a melhor solução para desfrutar da máxima liberdade na sua con­fi­gu­ra­ção. Os ser­vi­do­res root ou ser­vi­do­res dedicados são uma al­ter­na­tiva con­ve­ni­ente, e muitos for­ne­ce­do­res dis­po­ni­bi­li­zam-nos para conceder acesso à conta de uti­li­za­dor root. Em ambos os casos, tarefas fun­da­men­tais como a ins­ta­la­ção, a con­fi­gu­ra­ção e a ma­nu­ten­ção do servidor são da exclusiva res­pon­sa­bi­li­dade da pessoa que aluga o serviço.

In­de­pen­den­te­mente da solução escolhida, a segurança de­sem­pe­nha um papel essencial, pois um erro no ambiente root pode ter con­sequên­cias graves. No entanto, se forem seguidas as práticas corretas, é possível es­ta­be­le­cer a base perfeita para obter um servidor estável, potente e seguro.

Como proteger o seu servidor: guia passo a passo

Quer pretenda proteger um servidor com Windows, Ubuntu ou Debian, existem medidas gerais que o ajudarão a es­ta­be­le­cer uma base sólida de segurança. Resumimos os passos mais im­por­tan­tes para que os possa im­ple­men­tar e desfrutar de um servidor seguro.

Passo 1: efetuar uma ins­ta­la­ção mínima

Antes mesmo de tomar as pre­cau­ções ne­ces­sá­rias para con­fi­gu­rar um servidor seguro, já podes in­flu­en­ciar o potencial de segurança futuro do teu projeto web. In­de­pen­den­te­mente de optares por um sistema Windows ou Linux, na ins­ta­la­ção aplica-se o princípio de que um servidor só deve conter o software ne­ces­sá­rio para realizar as suas tarefas.

Isto deve-se ao facto de cada aplicação instalada re­pre­sen­tar um risco potencial para a segurança e poder afetar ne­ga­ti­va­mente o de­sem­pe­nho. Para reduzir o número de ataques, devem ser ins­ta­la­dos ou ativados apenas os com­po­nen­tes ne­ces­sá­rios do sistema ou deve recorrer-se apenas a software de terceiros de­vi­da­mente ve­ri­fi­cado.

Passo 2: definir uma palavra-passe segura

Após a ins­ta­la­ção, a primeira coisa que deve fazer é definir uma palavra-passe segura para o uti­li­za­dor ad­mi­nis­tra­dor (Windows) ou root (Linux). Por pre­de­fi­ni­ção, não é definido qualquer valor e a conta de ad­mi­nis­tra­dor permanece bloqueada até que seja definida uma palavra-passe. Nor­mal­mente, após a ins­ta­la­ção, o sistema operativo solicita au­to­ma­ti­ca­mente a criação de uma conta de uti­li­za­dor com uma palavra-passe que sirva de acesso de ad­mi­nis­tra­dor ou root.

Se alugou um servidor Linux a um for­ne­ce­dor e já tem um login de root pre­de­fi­nido, é im­por­tante que altere a palavra-passe ime­di­a­ta­mente. Para tal, ligue-se ao seu servidor através de SSH e execute o seguinte comando no terminal cor­res­pon­dente:

passwd
bash

Em seguida, pode definir a sua palavra-passe segura, que deverá confirmar pos­te­ri­or­mente. Cer­ti­fi­que-se de que a palavra-passe é o mais longa possível e utilize uma com­bi­na­ção de letras, ca­rac­te­res especiais e números. Recomenda-se também guardar a palavra-passe num gestor de palavras-passe, para a ter sempre dis­po­ní­vel caso precise.

Passo 3: alterar a porta SSH

Para aceder ao servidor via SSH, utiliza-se por pre­de­fi­ni­ção a porta TCP/UDP 22, que é a que aparece au­to­ma­ti­ca­mente aquando da ins­ta­la­ção do sistema. Os ci­ber­cri­mi­no­sos que procuram sistemas com falhas de segurança realizam os seus ataques, nor­mal­mente ten­ta­ti­vas de registo au­to­má­tico, através desta porta; por isso, ao definir uma porta diferente para as ligações remotas en­crip­ta­das, é possível minimizar o risco de acessos in­de­se­ja­dos.

Para tal, é ne­ces­sá­rio abrir o ficheiro de con­fi­gu­ra­ção SSH sshd_config com um editor de texto. O comando apre­sen­tado no exemplo de código seguinte abre o ficheiro com o editor padrão do Linux, ou seja, o nano:

nano /etc/ssh/sshd_config

Procure a linha cor­res­pon­dente e substitua o número da porta 22 por um número à sua escolha. No entanto, não se esqueça de que existem outras portas padrão para outros serviços (por exemplo, a porta 80 para HTTP).

Nota

Antes de as al­te­ra­ções no ficheiro sshd_config entrarem em vigor, é ne­ces­sá­rio reiniciar o serviço SSH. No Debian, isto é feito com o comando /etc/init.d/ssh restart, enquanto os uti­li­za­do­res do Ubuntu podem iniciar o serviço com o comando service ssh restart.

Passo 4: desativar o login via SSH para o ad­mi­nis­tra­dor

Para garantir a segurança do servidor, recomenda-se desativar o acesso SSH para a conta root ou de ad­mi­nis­tra­dor. Se esta conta per­ma­ne­cer ativada, um invasor que obtenha a palavra-passe poderá aceder ao servidor através de acesso remoto.

Antes de im­ple­men­tar esta medida, cer­ti­fi­que-se de criar pelo menos mais uma conta que possa iniciar sessão no servidor. Caso contrário, poderá ficar com­ple­ta­mente bloqueado fora do sistema. Em sistemas Linux, pode criar uma nova conta com o seguinte comando:

useradd -g users -d /home/usuario1 -m -s /bin/bash usuario1

Desta forma, é criada a conta de uti­li­za­dor «usuario1». Em seguida, define-se uma palavra-passe segura para esta nova conta de início de sessão:

passwd usuario1

Verifique se o login com essa conta de uti­li­za­dor funciona e prossiga com o passo para bloquear o acesso SSH à conta root. Para tal, será ne­ces­sá­rio aceder ao ficheiro de con­fi­gu­ra­ção SSH sshd_config, que pode abrir com o editor da sua escolha. Procure a entrada PermitRootLogin yes e substitua-a por PermitRootLogin no. Após reiniciar o serviço SSH, o acesso remoto à conta root estará de­sa­ti­vado.

No ficheiro de con­fi­gu­ra­ção, também pode es­pe­ci­fi­car quais os uti­li­za­do­res que podem aceder ao servidor via SSH uti­li­zando a diretiva AllowGroups. Para tal, crie um grupo (addgroup) e adicione os uti­li­za­do­res pre­ten­di­dos ao grupo (adduser). Em seguida, inclua o nome do grupo no ficheiro sshd_config (por exemplo, AllowGroups usuarios_ssh).

Passo 5: no­ti­fi­ca­ções por e-mail para mensagens de início de sessão via SSH

In­de­pen­den­te­mente da forma como se procede para proteger o acesso SSH, é ne­ces­sá­rio ter em conta todas as ati­vi­da­des remotas. Desta forma, é possível de­ter­mi­nar se o serviço SSH do servidor em questão foi protegido cor­re­ta­mente. Ao mesmo tempo, uma boa mo­ni­to­ri­za­ção das ligações es­ta­be­le­ci­das irá alertá-lo em caso de acessos não au­to­ri­za­dos, para que possa tomar as medidas ne­ces­sá­rias. Para tal, basta um script de shell que envie au­to­ma­ti­ca­mente um e-mail de aviso para o seu endereço caso o registo remoto seja efetuado com sucesso no servidor.

Um script de exemplo para o Linux /opt/shell-login.sh, que podes criar fa­cil­mente, deve conter apenas o seguinte código:

#!/bin/bash
echo "Login en $(nombre del host) el $(date +%Y-%m-%d) a las $(date +%H:%M)"
echo "Usuario: $USER"
echo
finger

Para concluir a con­fi­gu­ra­ção, edite o ficheiro /etc/profile e adicione a seguinte linha:

/opt/shell-login.sh | mailx -s "Login SSH en TU-NOMBRE DEL HOST" direcciondecorreo@example.com
txt

Com a seguinte con­fi­gu­ra­ção, garante-se que o script seja executado e que, caso o login seja bem-sucedido, seja enviado um e-mail de no­ti­fi­ca­ção para o endereço pre­ten­dido. A única condição é que ao script seja atribuída a permissão 755, que permite a leitura e a execução a todos os uti­li­za­do­res, e a escrita apenas ao pro­pri­e­tá­rio. Isto é con­se­guido com o seguinte comando:

chmod 755 /opt/shell-login.sh
bash

Passo 6: bloquear as portas não uti­li­za­das

Em geral, as portas abertas não costumam re­pre­sen­tar qualquer risco para a segurança. Uma vez que são ne­ces­sá­rias para a co­mu­ni­ca­ção com cada um dos serviços e apli­ca­ções, é mesmo essencial que de­ter­mi­na­das portas sejam abertas, como é o caso das portas 80 e 443 para ligações HTTP ou HTTPS, ou da porta SSH se­le­ci­o­nada. Se realizar uma ins­ta­la­ção mi­ni­ma­lista dos sistemas e recorrer a um número reduzido de apli­ca­ções de terceiros, o número de portas de que necessita não é ex­ces­si­va­mente elevado. Estas in­ter­fa­ces abertas só re­pre­sen­tam um risco quando os programas que têm de responder apre­sen­tam falhas de segurança e os cri­mi­no­sos se apro­vei­tam delas, perigo esse que aumenta se o número de apli­ca­ções for maior.

Se tiver feito uma ins­ta­la­ção básica do sistema e tiver instalado apenas um número limitado de apli­ca­ções de terceiros, é provável que o número de portas ne­ces­sá­rias seja reduzido.

Perante possíveis ataques, é fun­da­men­tal dispor de um servidor seguro para bloquear as portas abertas que não sejam ne­ces­sá­rias, através da con­fi­gu­ra­ção do seu firewall. Em geral, com o software de filtragem de pacotes iptables, todos os sistemas ope­ra­ti­vos já dispõem da fer­ra­menta adequada para o efeito. Com a sua ajuda, é possível criar regras fixas para regular o tráfego de dados, onde também é possível, entre outros fatores, definir as portas desejadas e as in­de­se­ja­das.

Passo 7: atu­a­li­za­ção periódica do software

Em geral, as vul­ne­ra­bi­li­da­des de segurança co­nhe­ci­das podem ser re­sol­vi­das ra­pi­da­mente através da pu­bli­ca­ção de atu­a­li­za­ções. Se se mantiver re­gu­lar­mente informado sobre as atu­a­li­za­ções dis­po­ní­veis para os sistemas ope­ra­ti­vos e os programas ins­ta­la­dos e se as instalar, poderá proteger o seu servidor da melhor forma possível. Quase todos os sistemas de servidor permitem, além disso, des­car­re­gar e instalar atu­a­li­za­ções de segurança em segundo plano.

Se pretender proteger um servidor Windows, a secção**«Windows Update»**permite-lhe definir di­re­tri­zes es­pe­cí­fi­cas para o processo de atu­a­li­za­ção. Assim, pode de­ter­mi­nar quando e com que frequên­cia devem ser pro­cu­ra­das atu­a­li­za­ções, se as atu­a­li­za­ções en­con­tra­das devem ser ins­ta­la­das au­to­ma­ti­ca­mente ou o momento em que o sistema deve ser rei­ni­ci­ado. No caso dos sistemas Linux, existem scripts es­pe­cí­fi­cos, como o apt-list­chan­ges ou o apticron, que informam di­a­ri­a­mente sobre a exis­tên­cia de um novo pacote de software e também o des­car­re­gam. Outros scripts, como o unat­ten­ded-upgrades, realizam por si próprios a ins­ta­la­ção au­to­má­tica.

Nota

Cer­ti­fi­que-se de que, durante um processo de atu­a­li­za­ção au­to­ma­ti­zado, mantém uma visão geral das atu­a­li­za­ções re­a­li­za­das, pois assim é possível detetar os erros que possam surgir durante o processo de atu­a­li­za­ção e reagir a eles.

Passo 8: proteger ser­vi­do­res Windows e Linux contra ataques de força bruta

Um dos ataques mais simples e mais comuns é o chamado método de força bruta. Com ele, o atacante utiliza uma fer­ra­menta que efetua várias ten­ta­ti­vas de início de sessão para descobrir as senhas. Quanto mais cuidado tiveres com as tuas senhas, menores serão as pro­ba­bi­li­da­des de este método ser bem-sucedido.

Es­pe­ci­al­mente se ofereces um serviço com mecanismo de registo, deves ter em conta que nem todos os uti­li­za­do­res são tão cui­da­do­sos e prudentes como deveriam. Para te pro­te­ge­res contra este tipo de ataques, podem ser úteis algumas fer­ra­men­tas de análise, como o Fail2ban (para sistemas Linux e POSIX) ou o RdpGuard (para Windows). Estas soluções analisam os ficheiros de registo do servidor, iden­ti­fi­cam com­por­ta­men­tos in­vul­ga­res e bloqueiam o endereço IP dos uti­li­za­do­res suspeitos. Além disso, também é possível ajustar o número de ten­ta­ti­vas falhadas ne­ces­sá­rias para que o bloqueio ocorra ou o período de validade que este deve ter.

Passo 9: utilizar fer­ra­men­tas de mo­ni­to­ri­za­ção

Se pretende ter um servidor seguro, é igual­mente im­por­tante garantir que a com­bi­na­ção entre hardware e software funcione da forma pre­ten­dida, não só após o arranque do ambiente do servidor, mas também a longo prazo. Uma vez que su­per­vi­si­o­nar os inúmeros processos do sistema pode ser complexo, é re­co­men­dá­vel utilizar fer­ra­men­tas de mo­ni­to­ri­za­ção desde o início. Estas fer­ra­men­tas su­per­vi­si­o­nam as ati­vi­da­des do servidor e emitem alertas em caso de qualquer anomalia.

Um programa simples e de con­fi­gu­ra­ção rápida é, por exemplo, o Monit, que pode ser fa­cil­mente instalado em muitas dis­tri­bui­ções Linux através do sistema de gestão de pacotes. Após o arranque, a aplicação de código aberto (licença AGPL da GNU) mo­ni­to­riza, de forma opcional , processos, ficheiros, nuvens, hosts, programas ou scripts, onde também entram em jogo recursos do sistema como CPU, memória ou consumo do sistema. Se forem ne­ces­sá­rias mais in­for­ma­ções, recomenda-se recorrer ao software de mo­ni­to­ri­za­ção Nagios, outra solução de código aberto dis­po­ní­vel para Linux e Windows, que pode ser ampliada através de plugins es­pe­cí­fi­cos para o Nagios.

Passo 10: con­fi­gu­rar cópias de segurança

Embora as con­fi­gu­ra­ções re­co­men­da­das aumentem sig­ni­fi­ca­ti­va­mente a segurança do servidor, nenhum sistema pode garantir uma proteção absoluta. Por isso, uma es­tra­té­gia de cópias de segurança abran­gente deve ser um pilar fun­da­men­tal do seu sistema de segurança. Esta es­tra­té­gia permitirá restaurar ficheiros em caso de perda ou falha do sistema.

Hoje em dia, existem fer­ra­men­tas de alto de­sem­pe­nho que não só ajudam a criar cópias, como também a restaurá-las. Uma aplicação gratuita útil neste sentido é o programa de sin­cro­ni­za­ção rsync, cujo nome deriva do protocolo homónimo e que está dis­po­ní­vel em di­fe­ren­tes versões para quase todas as pla­ta­for­mas (macOS, Windows e Linux). Esta fer­ra­menta mantém a cópia dos dados do servidor atu­a­li­zada e, para tal, efetua al­te­ra­ções no ficheiro original em tempo real.

Além do backup geral do servidor, outra das tarefas mais im­por­tan­tes é a proteção das bases de dados.

Nota

Para proteger os backups de forma segura, recomenda-se que a pasta de backup seja guardada num suporte de ar­ma­ze­na­mento externo, como, por exemplo, um disco rígido portátil ou outro servidor, e não no próprio servidor que se pretende proteger.

Ir para o menu principal