Gerenciamento de Máquinas Virtuais#

A infraestrutura das máquinas virtuais do C3SL é gerenciada pelos roots, um grupo de professores e bolsistas que respondem pelo e-mail root@c3sl.ufpr.br. A responsabilidade de manutenção do sistema operante dentro da máquina virtual, porém, é atribuída aos responsáveis assinalados para a máquina virtual. Mas note que os roots regularmente intervém nas máquinas:

  • Diariamente, os arquivos relacionados ao acesso SSH das máquinas virtuais são sobrescritos por processos automatizados, então o controle de acesso SSH para as máquinas virtuais é feito pelos roots.

  • Os roots gerenciam um sistema de renovação automática de certificados via Let’s Encrypt através de desafios de DNS. Usuários podem pedir a configuração desse serviço via e-mail.

  • O serviço Zabbix é instalado para monitoramento da máquina e envio de alertas aos responsáveis por exemplo para alertar sobre falta de espaço em disco ou alto uso de recursos computacionais.

  • Configuração de envio de e-mail utilizando a infraestrutura interna é gerenciada pelos roots, sendo que o envio de e-mail é liberado caso a caso, sendo a máquina configurada para enviar e-mail via sendmail.

  • Portas são liberadas no firewall mediante pedido. Inicialmente apenas o acesso interno é liberado, sendo necessário pedir a liberação de portas adicionais que estão sujeitas a nossa política de firewall.

  • Gerenciamento de registros de DNS e assinalamento de IPs. A máquina virtual recebe seu nome e IPs via DHCP, e o DNS é configurado pelos roots para ser {hostname}.c3sl.ufpr.br. Os IPv4s e IPv6s assinalados são públicos e tecnicamente acessíveis de qualquer lugar da Internet, sendo o único obstáculo o firewall.

  • Caso exista algum tipo de falha de segurança, ou algum alerta acenda, podem entrar na máquina e desligar a máquina virtual ou fazer atualização obrigatória de algum pacote.

Pedidos de alteração do controle de acesso, envio de e-mail, liberação de portas no firewall, aumento dos recursos computacionais e dúvidas devem ser feitos por e-mail.

Política de portas do firewall#

Inicialmente, uma máquina virtual tem acesso pleno a serviços externos. Porém, o acesso de fora para dentro é completamente bloqueado, sendo possível acessar a máquina via SSH apenas através da rede interna do C3SL. Alterações nessa configuração devem ser feitas através de pedidos via root@c3sl.ufpr.br de acordo com as seguintes regras:

  • A liberação da portas de e-mail não é permitida. O envio de e-mails pode ser feito através do nosso relay, cuja configuração pode ser requisitada.

  • A liberação de portas para acesso externo SSH só é permitida caso haja necessidade de acesso para usuários externos ao Departamento de Informática, sendo cada situação avaliada caso a caso.

  • A liberação de portas HTTP/HTTPS é feita com a contrapartida de que todo acesso de dentro para fora é limitado. Acesso a servidores web assim devem ser intermediados pelo nosso proxy HTTP.

Proxy HTTP/HTTPS#

Temos uma máquina chamada httpproxy.c3sl.ufpr.br que pode ser usada para acessar uma quantidade limitada de domínios externos. Pode ser utilizadas as seguintes variáveis de ambiente:

http_proxy="http://httpproxy.c3sl.ufpr.br:3128"
https_proxy="http://httpproxy.c3sl.ufpr.br:3128"

Essa configuração de proxy deve ser utilizada para produção mas é possível ter um acesso menos restrito gerenciado através da criação de um tunelamento SSH de dentro da máquina virtual:

  1. Acesse de dentro da máquina virtual um usuário do DINF via ssh -D 9050 usr99@macalan -FN, que abre uma porta SOCKS na porta 9050 para o mundo externo intermediado pela macalan.

  2. Ao utilizar aplicações rode usando a aplicação proxychains4 antes do comando; este comando faz com que certas requisições sejam feitas através do tunelamento disponível na porta SOCKS 9050.

  3. Alguns comandos escapam esse controle mas respeitam as variáveis http_proxy e https_proxy. Você pode utilizar uma aplicação como o Privoxy para criar um Proxy HTTP/HTTPS que conversa com o proxy SOCKS do SSH utilizando a configuração forward-socks4a / 127.0.0.1:9050 e as variáveis de ambiente de Proxy HTTP/HTTPS com valor http://localhost:8118.

Certificados TLS#

O nosso sistema de renovação de certificados TLS usando Let’s Encrypt roda diariamente e realiza as seguintes etapas ao renovar o certificado:

  1. Coloca a cadeia de certificados públicos e intermediários gerados em /etc/ssl/certs/c3sl.pem.

  2. Coloca o certificado privado em /etc/ssl/private/c3sl.pem.

  3. Chama o executável /etc/c3sl/upgrade-cert. Para que isso funcione este executável deve ter permissão de execução (chmod +x). Use este executável para recarregar os seus serviços, por exemplo:

    #!/bin/bash
systemctl reload nginx

Exemplo de configuração do nginx#

Para utilizar o certificado na porta 443, lembre-se da diretiva ssl e de escutar nos endereços IPv4 e IPv6:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name examplo.c3sl.ufpr.br;
    ssl_certificate /etc/ssl/certs/c3sl.pem;
    ssl_certificate_key /etc/ssl/private/c3sl.pem;
}

É obrigatório mandar uma resposta de redirecionamento para toda requisição na porta 80 para a porta 443:

server {
     listen  80;
     listen [::]:80;
     server_name exemplo.c3sl.ufpr.br;
     location / { return 301 https://$host$request_uri; }
}

Exemplo de configuração do Apache#

Para utilizar o certificado na porta 443:

<VirtualHost _default_:443>
    ServerName exemplo.c3sl.ufpr.br
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/c3sl.pem
    SSLCertificateKeyFile   /etc/ssl/private/c3sl.pem
</VirtualHost>

É obrigatório mandar uma resposta de redirecionamento para toda requisição na porta 80 para a porta 443. Isso pode ser feito de duas maneiras. O método recomendado é fazer isso estaticamente, para cada ServerName:

<VirtualHost _default_:80>
  ServerName exemplo.c3sl.ufpr.br
  Redirect / https://exemplo.c3sl.ufpr.br/
</VirtualHost>

Porém isso pode ser feito também de forma dinâmica:

<VirtualHost _default_:80>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Domínios externos#

Quando existe um domínio externo ao C3SL apontando para a máquina (sendo que é recomendado que isso seja feito através de um registro CNAME), os certificados TLS precisam ser gerados através do desafio do servidor web. Isso significa que será necessário importar um snippet como este do nginx na configuração, e criar todos os diretórios do caminho /var/www/letsencrypt/.well-known/acme-challenge para que a automação possa copiar arquivos para lá:

# Rule for legitimate ACME Challenge requests (like /.well-known/acme-challenge/xxxxxxxxx)
# We use ^~ here, so that we don't check other regexes (for speed-up). We actually MUST cancel
# other regex checks, because in our other config files have regex rule that denies access to files with dotted names.
location ^~ /.well-known/acme-challenge/ {

    # Set correct content type. According to this:
    # https://community.letsencrypt.org/t/using-the-webroot-domain-verification-method/1445/29
    # Current specification requires "text/plain" or no content header at all.
    # It seems that "text/plain" is a safe option.
    default_type "text/plain";

    # This directory must be the same as in /etc/letsencrypt/cli.ini
    # as "webroot-path" parameter. Also don't forget to set "authenticator" parameter
    # there to "webroot".
    # Do NOT use alias, use root! Target directory is located here:
    # /var/www/common/letsencrypt/.well-known/acme-challenge/
    root         /var/www/letsencrypt/;
}

# Hide /acme-challenge subdirectory and return 404 on all requests.
# It is somewhat more secure than letting Nginx return 403.
# Ending slash is important!
location = /.well-known/acme-challenge/ {
    return 404;
}