# Anexo: Referências de boas práticas

Traduções: [[Castellano|best practices es]] [[Português|best practices pt]]

*Esse anexo contêm o texto da política com boas práticas específicas adicionadas abaixo das seções correspondentes. É um trabalho em andamento. Por favor, colabore!*

Obviamente, cada nível de segurança/privacidade requer que você mantenha o seu software atualizado dos problemas de segurança conhecidos.

# E-mail com Exim

## Nível 1

…

## Nível 2

### O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com impressão digital.

* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt)

# E-mail com Postfix

## Nível 1

### Se o servidor adiciona o endereço IP de um usuário que está enviando um e-mail através do seu serviço em qualquer lugar do e-mail, o usuário/a é informado sobre isso.

Não é uma questão de configuração do servidor: você deve usar seus canais de comunicação para passar essa informação para os seus usuários/as (p.e. newsletter, lista de anúncio). Os novos usuários/as devem ser informados, como parte do processo de abertura de nova conta. Você pode também explicar sobre isso em seu site.

### As conexões entre o usuário e o servidor são sempre criptografadas.

* Do lado do servidor: [Configurar o Postfix para usar o certificado X.509](http://koti.kapsi.fi/ptk/postfix/postfix-tls-cacert.shtml) acessado em 3 de Abril de 2013
* Do lado do cliente: Peça para seu provedor a documentação :)

### Usar (Start)TLS para trocar e-mails com outros servidores, sempre que disponível

* Isso é chamado de criptografia *oportunística*.

### O servidor deve ter seu próprio certificado X.509 assinado por uma das autoridades certificadoras.

Há muitos problemas com o ecossistema X.509, parcialmente explicados aqui: http://lair.fifthhorseman.net/~dkg/tls-centralization/

Dependendo do quão bem seus usuários entendem os certificados X.509, nós recomendamos 4 diferentes cenários:

a. Autoridade Certificadora Comercial: geralmente é um serviço pago, mas os usuários/as não ficaram confusos porque seus clientes de e-mails já vem com certificados comerciais, então não haverǽ nenhuma mensagem de alerta sobre certificados não confiáveis. Isso não necessariamente aumenta a segurança da conexão uma vez que um atacante pode emitir certificados, pois uma autoridade certificadora pode ser desonesta ou um Estado, por exemplo. Veja a [Seção de Segurança na Wikipedia](https://en.wikipedia.org/wiki/X.509#Security) para mais detalhes.

b. CaCert: os usuários ainda precisarão validar e instalar o certificado de raíz do CaCert, por que não é incluido em nenhum cliente de e-mail. Mas eles podem já terem feito esse procedimento para utilizar outros provedores. Há também um pacote Debian que torna-o fácil para usuários do Debian/Ubuntu instalarem.

c. Certificados auto assinados/Autoridade própria: motivo contra: não está incluído nos clientes padrões de e-mail dos seus usuários. Eles precisam instalar os certificados (raíz). Se eles não controlam ("pinning") os certificados e possuem outras autoridades comerciais instaladas, você terá nada mais do que problemas. Você arrisca ensinar os seus usuários a ignorar as mensagens de alerta de segurança. Se propriamente aplicado por seu coletivo de cripto-ninjas, isso *pode* ser mais seguro.

d. Monkeysphere: você pode usar as chaves OpenPGP (certificados) para autenticar serviços. Essa é uma solução tecnicamente excelente, no entanto, não é suportada por softwares comuns. Se você têm usuários/as com superpoderes, nós recomendamos experimentar. Mais informações no [site do Monkeysphere](http://monkeysphere.info/)

## Nível 2

### O servidor não adiciona o endereço IP de um usuário/a que está enviando um e-mail através do seu serviço, em nenhum lugar do e-mail.

* [IPs nos cabeçalhos](https://we.riseup.net/debian/mail#postfix)

### O TLS é requerido com o nível 2 dos servidores parceiros. Os certificados são verificados com a impressão digital.

Uma solução equivalente é implementar uma conexão IPsec entre os coletivos relevantes, assim torna desnecessário o uso do TLS.
Para implementar isso, você precisa saber as impressões digitais atualizadas dos certificados dos grupos que você planeja cooperar dessa forma. Há várias maneiras de se fazer isso, mas depende tanto de um contexto social e técnico, então não iremos detalhá-los aqui, apenas afirmar que isso é um requerimento. Fixar ("pinning") essas impressões digitais e atualizá-las quando mudarem pode ser um aborrecimento (ao menos que um protocolo e uma implementação segura e automatizada para esse propõsito venha a ser desenvolvida).

* [Postfix TLS LEIAME](http://www.postfix.org/TLS_README.html)

## Nível 3

### O e-mail é também disponível como um serviço oculto (hidden service) do Tor.

* [Torproject: Tor Hidden Service documentation](https://www.torproject.org/docs/tor-hidden-service.html.en) → adaptar para as necessidades do servidor de e-mail.
* Cliente: [torbirdy](https://trac.torproject.org/projects/tor/wiki/torbirdy) é uma extensão útil para fazer uso do serviço oculto.

# Sistemas de arquivos e Armazenamento

## Nível 1

* Os dados do/a usuário/a não são acessíveis publicamente, eles são armazenados criptografados, usando uma senha forte. Veja os documentos de boas práticas para detalhes. Isso inclui e-mails, banco de dados, arquivos de listas, sites restritos e outros.

No GNU/Linux, cryptsetup:

* [Como configurar um sistema de arquivos criptografado em várias etapas?](http://www.debian-administration.org/articles/469)
* [Configurando um sistema Debian criptografado](http://madduck.net/docs/cryptdisk/)

## Nível 2

### A swap é armazenada criptografada.

Para isso você pode usar cryptsetup também.

### O sistema operacional e sua configuração é armazenada criptografada com uma senha forte. Veja os documentos de boas práticas para os detalhes.

Hoje você pode usar muitos instaladores de Sistema Operacional que conseguem isso.

Não confie nos discos rígidos que possuem uma camada de discos criptografada, eles são frequentemente mal implementados ou podem vir com backdoors, por exemplo.

## Nível 3

* A swap é criptografada com uma chave aleatória na inicialização.
* Criar uma área da swap criptografada

http://www.microhowto.info/howto/create_an_encrypted_swap_area.html
https://we.riseup.net/debian/encrypted-swap
http://linux.die.net/man/5/crypttab -> seção "swap"

# Boas práticas (antigo)

## E-mail

* [IPs no cabeçalho](http://riseuplabs.org/privacy/postfix/): o endereço de IP da casa do/a usuário/a não deve aparecer no cabeçalho do e-mail *nível 2*
* Se aparecer, os/as usuários/as devem ser informados sobre isso e *nível 1* talvez mostrar o IP do servidor ao invés de localhost com o [hack do riseup](http://riseuplabs.org/privacy/postfix/)
* A conexão entre o servidor e o usuário/a sempre é criptografada. *Nível 2*
* A opção de comunicação não-criptografada entre o usuário/a e o servidor deve estar visivelmente marcada como insegura. *Nível 1*
* [StartTLS-postfix](http://metatron.sh/kmw/Transformers/PostfixCacertVerifyHowto) ou [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) starttls com outros servidores parceiros, certificados verificados versus cacert/... *nível 1*
* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) - o TLS é requirido com outros servidores parceiros, certificados verificados com impressão digital *nível 2*

## Os certificados e as chaves são criptografados para os serviços baseados em stream

* As chaves privadas são armazenadas criptografadas *Nível 2*
* As chaves privadas são somente armazenadas criptografadas e off-site *Nível 3*
* Comunicação baseada em stream usa apenas uma configuração bem estabelecida de parâmetros criptográficos (cifras, message digests, algoritmos de criptografia assimética, etc). Veja os documentos de boas práticas para detalhes. *Nível 1*

Se você estiver usando mod_ssl com apache e uma chave RSA para o servidor, sugerimos:

<code>SSLCipherSuite TLSv1:!MD5:!EXP:!LOW:!NULL:!MEDIUM:!ADH:!DSS</code>

## Log

* Os logs contendo informação de identificação do usuário/a são armazenados criptografados ou apenas na memória. De outro modo os usuários devem ser informados sobre isso. *Nível 1*
* Os logs não possuem nenhuma informação identificação do usuário/a. *Nível 3*

Logs do Apache sem nenhum endereço IP: [mod_removeip](http://riseuplabs.org/privacy/apache/)

Usando Debian com Apache2:

      apt-get install libapache2-mod-removeip
      a2enmod removeip
      /etc/init.d/apache2 force-reload

* Os logs contendo informação sobre as atividades não-individuais dos usuários/as são armazenados criptografados ou apenas memória. *Nível 1*
* Os logs não possuem nenhum informação sobre as atividades não-individuais dos usuários/as. *Nível 2*
* Os logs do sistema (não relacionados com as atividades dos usuários/as) são armazenados criptografados ou apenas na memória. *Nível 2*

Acompanha "Sistemas de arquivos e Armazenamento Nível 2"

* Os logs do sistema (não relacionados com as atividades do usuário) não são armazenados. *Nível 3*