Claudinei Pereira [Blog] (Posts sobre configuração)

VPS: configuração básica

Claudinei Pereira — Thu, 16 Apr 2015 04:00:00 GMT

Este artigo integra o tutorial em três partes sobre como Configurar e Administrar um VPS para diversos usos, como hospedagem de sites, backups, etc. Para ter acesso às outras partes visite os links a seguir:

O presente texto objetiva documentar os passos gerais para a configuração inicial de um VPS (Virtual Private Server). Optou-se por escolher softwares e configurações que ofereçam um consumo baixo de memória, visto que o servidor de teste possui 128 MB de memória RAM disponível.

Segurança Básica

Os primeiros passos na configuração do servidor devem ser aqueles relacionados à segurança básica. É necessária a criação de um usuário que executará tarefas administrativas por intermédio do comando sudo. O acesso seguro será feito pelo servidor dropbear (mais leve que o openssh) via par de chaves pública/privada e o firewall iptables deixará abertas apenas as portas necessárias.

Senhas e Usuários

Fazer o primeiro login com a senha de root oferecida pela empresa. Mudar a senha do root para uma forte (que pode ser gerada no site www.random.org).

# passwd

Criar um usuário para administração, instalar o programa sudo (caso ainda não esteja instalado) e adicionar o usuário ao grupo sudo.

# adduser nome-do-usuário
# apt-get update && apt-get upgrade
# apt-get install sudo
# adduser nome-do-usuário sudo
# visudo

O comando visudo abre o arquivo /etc/sudoers para edição. A seguinte linha deve ser descomentada e alterada de:

# %sudo ALL=NOPASSWD: ALL

para:

%sudo ALL=(ALL) ALL

Assim, já é possível sair da conta root e fazer login com o novo usuário paraos próximos passos.

SSH

Instalação do Dropbear

O openssh será substituído pelo dropbear que, por sua vez, será gerenciado pelo xinetd:

# apt-get update && apt-get upgrade
# apt-get install dropbear
# apt-get install xinetd

Configurar o xinetd, criando o arquivo /etc/xinetd.d/dropbear com o seguinte conteúdo:

service dropbear
{
     socket_type  = stream  
     only_from    = 0.0.0.0  
     wait         = no  
     user         = root  
     protocol     = tcp  
     server       = /usr/sbin/dropbear  
     server_args  = -i -w  
     disable      = no  
     port         = número-da-porta  
     type         = unlisted  
}

É interessante mudar o valor de port para uma porta de acesso que seja diferente da padrão (22). Talvez 2222 ou alguma porta mais alta, como 50000. Os valores de server_args significam:

-i = Roda como serviço
-w = Não permite login do usuário root

Parar o servidor openssh, evitar que ele inicie ao boot e reiniciar o xinetd para que o dropbear passe a ser o servidor ssh padrão:

# invoke-rc.d ssh stop
# update-rc.d -f ssh remove
# invoke-rc.d xinetd restart

Login via chaves pública/privada

O login utilizando-se de um par de chaves pública/privada adiciona uma camada extra de segurança. Caso ainda não se possua um par de chaves, deve gerá-lo localmente (assumindo-se que há uma distribuição GNU/Linux instalada com openssh):

$ ssh-keygen -t dsa

Isso criará duas chaves, uma pública (id_dsa.pub) e uma privada (id_dsa) no diretório ~/.ssh. Será requisitada uma senha, que pode ser definida ou não.

Caso se possua uma chave privada, basta extrair a pública com o seguinte comando:

$ ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

Em poder da chave pública, deve-se copiá-la para o servidor:

$ scp -P porta ~/.ssh/id_dsa.pub usuário@servidor:~

Fazer login no servidor e adicionar o conteúdo do arquivo id_dsa.pub ao arquivo ~/.ssh/authorized_keys, configurando as permissões necessárias:

$ ssh -p porta usuário@servidor
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
$ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_dsa.pub

Modificar o arquivo /etc/xinetd.d/dropbear para permitir somente o login sem senha, adicionando a opção -s a server_args. Reiniciar o xinetd para que a mudança tenha efeito.

Firewall

A configuração do Firewall seguinte libera apenas as portas necessárias (por enquanto, 80 para o servidor web e a porta para acesso seguro). Colocar o seguinte conteúdo no arquivo /etc/iptables.up.rules:

*filter

# http://articles.slicehost.com/2010/4/30/ubuntu-lucid-setup-part-1

#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allows all outbound traffic
#  You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
#-A INPUT -p tcp --dport 443 -j ACCEPT

# UN-COMMENT THESE IF YOU USE INCOMING MAIL!

# Allows POP (and SSL-POP)
#-A INPUT -p tcp --dport 110 -j ACCEPT
#-A INPUT -p tcp --dport 995 -j ACCEPT

# SMTP (and SSMTP)
#-A INPUT -p tcp --dport 25 -j ACCEPT
#-A INPUT -p tcp --dport 465 -j ACCEPT

# IMAP (and IMAPS)
#-A INPUT -p tcp --dport 143 -j ACCEPT
#-A INPUT -p tcp --dport 993 -j ACCEPT

#  Allows SSH connections (only 3 attempts by an IP every minute, drop the rest to prevent SSH attacks)
-A INPUT -p tcp -m tcp --dport PORTA -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -p tcp -m tcp --dport PORTA -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m state --state NEW --dport PORTA -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls (Can grow log files fast!)
#-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
#-A INPUT -j REJECT
#-A FORWARD -j REJECT

# It's safer to just DROP the packet
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT

IMPORTANTE: mudar o valor de PORTA para a porta que reflita sua configuração de acesso do dropbear. Para que as regras tenham efeito a cada boot, é necessário adicionar o script na inicialização. Para tanto, adicionar um arquivo com o seguinte conteúdo em /etc/network/if-pre-up./iptables:

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules

Também é necessário fazê-lo executável com o comando:

# chmod +x /etc/network/if-pre-up.d/iptables

Logs

O logwatch é uma ferramenta útil para acompanhar os logs do sistema via email. Instalação:

# apt-get install logwatch

Para configuração, verificar os arquivos de exemplo em /usr/share/logwatch/default.conf/.

Servidor de email

Por fim, é interessante deixar um servidor de email rodando, para receber via email os logs do sistema gerados pelo logwatch. Para tanto, vamos instalar o exim configurado com uma conta comum do gmail.

Instalação:

# apt-get install exim4-daemon-light mailutils

Configuração:

# dpkg-reconfigure exim4-config

passwd.client

*.google.com:email@gmail.com:senha

exim4.conf.localmacros

MAIN_TLS_ENABLE = 1

Para outros detalhes sobre este tipo de configuração de email, verificar a página GmailAndExim4.

Outras ações

Syslog

Para gerenciar os logs do sistema iremos utilizar o daemon syslog. O VPS de teste possui o rsyslogd, então vamos removê-lo:

# invoke-rc.d rsyslog stop
# update-rc.d -f rsyslog remove

Instalar syslogd:

# apt-get install inetutils-syslogd

Configurar syslogd:

# invoke-rc.d inetutils-syslogd stop
# rm -rf /var/log/*.log
# rm -rf /var/log/mail.*
# rm -rf /var/log/debug
# rm -rf /var/log/syslog
# rm -rf /var/log/fsck
# rm -rf /var/log/news

Arquivo de configuração do syslog (/etc/syslog.conf):

*.*;mail.none;cron.none -/var/log/messages
  cron.*                -/var/log/cron
  mail.*                -/var/log/mail

Adicionar ao logrotate (/etc/logrotate.d/inetutils-syslogd):

/var/log/cron
/var/log/mail
/var/log/messages {
    rotate 4
    weekly
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
    /etc/init.d/inetutils-syslogd reload >/dev/null
endscript
}

Reiniciar syslog:

# invoke-rc.d inetutils-syslogd start

Remoção de pacotes

Alguns pacotes pré instalados no VPS não são necessários, ou serão substituídos por outros, então vamos removê-los:

# apt-get remove bind9
# apt-get remove 'samba*'
# apt-get remove portmap
# invoke-rc.d apache2 stop
# update-rc.d -f apache2 remove
# apt-get remove 'apache2*'
# invoke-rc.d nscd stop
# update-rc.d -f nscd remove
# apt-get remove nscd  
# invoke-rc.d sendmail stop
# update-rc.d -f sendmail remove
# apt-get remove 'sendmail*'

Locales e tempo do servidor

# dpkg-reconfigure locales
# dpkg-reconfigure tzdata

Mudar Shel

Para mudar o shell de bash para mksh:

# apt-get install mksh

Mudar /etc/passwd trocando o bash pelo mksh.

Conclusão

Estes foram os passos inicais para configurar um VPS de 128 mb, procurando deixá-lo preparado para a instalação de outros servidores (web, base de dados, backup). Ãpós o conjunto de instruções relatadas neste artigo, o VPS em questão está consumindo 15 mb de memória RAM, deixando espaço para um servidor web com suporte a PHP, que será o foco do próximo tutorial.

VPS: O que é?

Claudinei Pereira — Thu, 09 Apr 2015 01:00:00 GMT

O tutorial ao qual esta introdução se refere foi dividido em trê partes e tem o objetivo de mostrar como Configurar e Administrar um VPS para diversos usos, como hospedagem de sites, backups, etc. Para ter acesso às partes visite os links a seguir:

Um VPS (do inglês Virtual Private Server) é uma máquina virtual que executa um sistema operacional completo. É instalada em um hardware real que pode trazer várias máquinas virtuais rodando ao mesmo tempo dividindo os recursos existentes entre si. Podem ser utilizados de diversas maneiras, sendo a hospedagem de websites um dos usos mais correntes.

A utilização de um VPS requer um certo conhecimento do sistema operacional em uso, visto que o administrador precisa executar tarefas pertinentes ao gerenciamento de usuários, instalação, configuração e atualização de pacotes, segurança, etc. O acesso a essas máquinas, via de regra, é feito por SSH (Secure SHell) e, nesta modalidade de acesso, as ações nelas executadas são por linha de comando.

Eu adquiri um VPS em 2011, com o intuito de aprendizado e para hospedar alguns websites. Ele possui 256 mb de memória RAM disponível, 10 gb de disco rígido e transferência mensal de 250 gb. Ele roda atualmente um servidor de banco da dados (MySQL) e um servidor web (nginx) com suporte a PHP. Com esta configuração possuo um website pessoal (HTML + CSS), este blog (HTML + CSS), um website de empresa (PHP) e um ambiente virtual de aprendizagem (PHP + MySQL).

O que me motivou a escrever este conjunto de artigos foi a obtenção de mais uma máquina virtual, desta vez para configurar um servidor de backup remoto. Resolvi escrevê-los para referência pessoal futura e também para compartilhar o conhecimento que adquiri durante o processo de administração destes sistemas.

Caso alguém tenha interesse adquirir uma máquina virtual para aprendizado, pode obter uma na mesma empresa em que adquiri a que me servirá de backup remoto: a RamNode. Por 15 doláres AO ANO é possível adquirir um VPS com 128 mb de memória RAM, 12 gb de espaço em disco e 500 gb de transferência mensal.

Vamos botar a mão na massa? :)

Google Apps: Configuração de DKIM

Claudinei Pereira — Wed, 06 Jul 2011 11:40:00 GMT

Este artigo integra o tutorial em duas partes sobre como configurar SPF e DKIM para os emails do Google Apps de forma a demonstrar sua legitimidade. Para ter acesso à outra parte visite o link a seguir:

Google Apps: Configuração de SPF

A configuração de DKIM (do inglês DomainKeys Identified Mail) é outra ferramenta que inibe a utilização de determinado domínio de forma não lícita por spammers. Consiste em adicionar uma assinatura digital aos email, por meio de um par de chaves pública e privada. Com esta configuração, cada email é assinado no servidor de origem pela chave privada e, em seguida, a assinatura é verificada pelo servidor de destino por meio da chave pública disponível vi DNS.

Geralmente, ao configurarmos um servidor de emails, as chaves são criadas no próprio servidor. A chave privada fica gravada num arquivo protegido no sistema de arquivos da máquina e a chave pública é publicada como registro DNS do tipo TXT. Já no Google Apps, a geração das chaves é feita via interface de administração do domínio. O caminho é o que se segue:

Logar na conta de administração do Google Apps e clicar no link Administrar este domínio;
Clicar no menu Ferramentas Avançadas;
Clicar no link Configurar autenticação de e-mails (DKIM);
Clicar no link Gerar novo registro. Abrirá uma caixa de diálogo perguntado sobre o "selecionador de prefixo". É uma configuração opcional e pode ser deixada no padrão (google).

Após os passos anteriores, a chave pública é informada, tendo o seguinte formato:

v=DKIM1; k=rsa; p=VALOR-DA-CHAVE

Também é informado o "selecionador de prefixo", por padrão:

google._domainkey

Devemos atualizar o DNS com um registro TXT com esses valores, sendo que o selecionador deve ser informado como subdomínio. Após a atualização, a propagação da informação pode levar até 48 horas. Para verificar se foi feita a propagação, podemos utilizar o comando host no Linux ou o nslookup no Windows. No Linux, o comando é o seguinte:

$ host -t TXT google._domainkey.dominio.com 8.8.8.8

No Windows:

>nslookup -type=TXT google._domainkey.dominio.com 8.8.8.8

Conclusão

Tanto a configuração de SPF quanto de DKIm são desejáveis e até mesmo necessárias para demonstrar a legitimidade dos emails enviados por um domínio, aumentando sua proteção contra uso indevido por spammers. O Google Apps facilita as configurações, ficando a cargo do administrador de domínio as alterações de DNS necessárias, conforme mostradas neste tutorial.

Google Apps: Configuração de SPF

Claudinei Pereira — Wed, 06 Jul 2011 11:35:00 GMT

Este artigo integra o tutorial em duas partes sobre como configurar o SPF e DKIM para os emails do Google Apps de forma a demonstrar sua legitimidade. Para ter acesso à outra parte visite o link a seguir:

Google Apps: Configuração de DKIM

A configuração de SPF (do inglês Sender Policy Framework) permite ao administrador do domínio autorizar determinados servidores para envio de emails. Desta maneira, o servidor que recebe a mensagem pode verificar que o servidor que a enviou foi autorizado pelo detentor do domínio.

Ao utilizarmos o Google Apps para email e não termos o SPF configurado, quem recebe o email pode verificar conteúdo parecido com o seguinte nos cabeçalhos:

Received-SPF: neutral (google.com: 209.85.210.48 is neither permitted 
nor denied by best guess record for domain of email@dominio.com) 
client-ip=209.85.210.48;
Authentication-Results: mx.google.com; spf=neutral 
(google.com: 209.85.210.48 is neither permitted nor denied by best 
guess record for domain of email@dominio.com)

Ou seja, o servidor que recebeu o email não pôde determinar se a máquina que o enviou era autorizada ou não pelo domínio para envio de emails, dando a ele uma classificação neutra (spf=neutral). Pode ocorrer que emails com SPF neutro acabem sendo marcados como spam por certos servidores receptores, principalmente se o volume de mensagens enviadas for relativamente grande.

Para configurar o SPF para o Google Apps devemos publicar um registro DNS do tipo TXT. Como há variações nos gerenciadores de DNS para domínios, indicaremos somente a linha a ser adicionada ao registro:

v=spf1 include:_spf.google.com ~all

Deve-se esperar um tempo para que o DNS seja propagado (até 48 horas). Para verificar se o registro já está ativo, podemos usar o com o comando host no terminal do Linux:

$ host -t TXT dominio.com

No Windows, o comando é o nslookup:

>nslookup -type=TXT dominio.com 8.8.8.8

Com o registro TXT publicado e funcionando, ao enviarmos um email o receptor poderá verificar o cabeçalho, que agora terá conteúdo parecido com o seguinte, indicando que o teste de SPF teve êxito (pass):

Received-SPF: pass (google.com: domain of email@dominio.com designates 
209.85.210.48 as permitted sender) 
client-ip=209.85.210.48;
Authentication-Results: mx.google.com; spf=pass (google.com: 
domain of email@dominio.com designates 209.85.210.48 as permitted sender)

Google Apps: Emails personalizados para seu domínio

Claudinei Pereira — Wed, 06 Jul 2011 11:30:00 GMT

O tutorial ao qual esta introdução se refere foi dividido em duas partes e tem o objetivo de mostrar como configurar SPF e DKIM para os emails do Google Apps de forma a garantir sua legitimidade. Para ter acesso às partes visite os links a seguir:

Quem deseja dar um aspecto mais profissional ao seu blog, site ou quer ter endereços de email personalizados deve, inevitavelmente, investir num domínio próprio. Domínios .com custam cerca de R$ 18,00 ao ano, os .info custam menos da metade deste valor e há até mesmo os gratuitos como os oferecidos pelo co.cc.

Google Apps Logo.

Ao se possuir um domínio .com, o serviço gratuito Google Apps pode ser usado para personalizar emails (seunome@dominio.com) e até mesmo hospedar sites. Também há a possibilidade de obter uma solução completamente gratuita ao configurar um domínio do co.cc com o Google Apps.

Independente do tipo de domínio utilizado com o Google Apps, pode-se configurar o serviço de maneira que os emails tenham sua origem certificada e sejam assinados digitalmente. Isto diminui as chances de que o endereço de email configurado para o domínio seja utilizado por spammers e / ou acabe sendo marcado como spam pelo receptor.

As configurações citadas são opcionais porém altamente recomendáveis, visto que visam garantir a autenticidade dos emails enviados por determinado domínio. Assim, pode-se ter certeza que as mensagens serão entregues aos seus destinatários, sem serem desviadas para a caixa de spam e podendo não serem vistas.