Selfhost on Crimideias do caioau

Slides: Primeiros passos com self-hosting (cryptorave 2024)

Tue, 07 May 2024 08:00:00 -0300

Atividade realizada dia 11 maio 2024, na cryptorave.

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Slides: Primeiros passos com self-hosting (cryptorave 2023)

Thu, 04 May 2023 08:00:00 -0300

Atividade realizada dia 5 maio 2023, na cryptorave.

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Slides: Primeiros passos com self-hosting (TOSCONF[3])

Fri, 17 Mar 2023 08:00:00 -0300

Atividade realizada dia 18 março 2023, na TOSCONF[3] no Laboratório Hacker de Campinas – LHC

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Slides: Como operar uma infra on premisses

Wed, 15 Dec 2021 08:00:00 -0300

Atividade realizada dia 15 dezembro 2021, no Eldorado

Palestra baseada no texto Primeiros passos com self-hosting

slides (arquivo markdown editável feito com Marp).

Primeiros passos com self-hosting

Sun, 04 Jul 2021 14:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 05Julho2021

Neste post vamos fazer uma visão geral das principais partes do self-hosting.

Foto de Jainath Ponnala, unsplash

Vai usar a nuvem? Ou apenas on-premise? Que tal ambos?

Acredito que umas das primeiras considerações quando montamos nosso setup de self-hosting é pensar como isso vai se organizar e onde vai ficar cada coisa.

Self-hosting não é ser “contra a nuvem” mas sim um movimento para ter controle dos nossos dados e aplicações que usamos, mesmo usando a nuvem nós que vamos configurar tudo e ter controle de como cada coisa funciona.

Outro modelo é hospedar “tudo em casa” (chamado de on-premise), funciona muito bem. Mas um desafio que logo vamos abordar é abrir a conexão da sua operadora para acessar seus serviços fora de casa.

Daí surge um terceiro modelo: o híbrido, parte das coisas que necessitam de velocidade ficam em casa e o restante que precisa acessar fora de casa na nuvem. No meu caso, coloco na nuvem (uma virtual private server (VPS) da digital ocean) o nextcloud com apenas meus contatos e calendário (no android uso o davx5 para sincronizar a agenda e os contatos com o nextcloud) e em casa guardo meus backups (com uma cópia no rsync.net) e todo resto :P

Além de ser muito bonito e divertido de fazer, recomendo fazer um diagrama de como vai se organizar suas aplicações e dispositivos, acima é como organizo tudo.

Hardware usado para hospedar

Para hospedar nossas coisas em casa, precisamos de um hardware para fazê-lo, pode ser usado com computador velho ou, outras opções populares, são usar a Raspberry Pi, mini pc (tipo intel NUC) ou por fim um servidor de armazenamento conectado em rede (NAS, de Network Attached Storage). Embora seja uma melhor opção pelo reuso e sobrevida de um equipamento obsoleto, é importante ficar ciente e atento a falhas por fadiga que podem comprometer a disponibilidade ou a confiabilidade do serviço.

Quando eu comecei nessa jornada do self-hosting, havia comprado um SSD para meu notebook então peguei o disco que veio nele e conectei numa Raspberry Pi. Começar com uma Raspberry Pi é ótimo: é barato, consome pouca energia e atende aos requisitos de recursos de várias aplicações.

Mas existem outras necessidades que uma Raspberry Pi não consegue atender, como por exemplo rodar máquinas virtuais, e daí surge a necessidade de outros hardwares apropriados. Como um mini-pc (ou Intel NUC) que é literalmente um mini pc e os componentes tradicionais como processador x86 (ao invés do ARM do Raspberry Pi), slots de memória RAM que pode ser trocada, etc.

NAS Synology DS920+

Quer armazenar muitos arquivos? Talvez um NAS seja mais adequado. Este equipamento conta com conexão à rede e diversos slots para colocar os discos.

Por fim, um item de hardware que é opcional mas recomendo é um “no break”, para que em caso de cair a energia na sua casa não aconteça nada.

Storage e backups

Tudo, inclusive toda forma de tecnologia, está sujeita a falhas, mas enquanto peças podem ser substituídas, arquivos perdidos podem não serem recuperáveis, por isso surge a necessidade de cópias de segurança, os famosos backups. A regra de ouro é quanto mais importante, raro ou caro mais versões e de mais difícil acesso elas devem ser.

Isso é uma consideração importante principalmente com a Raspberry Pi, os SD cards não são muito confiáveis, depois de alguns anos de uso eles acabam “morrendo”. Comigo foi muito nítido isso, teve um SD card que me serviu fielmente por 2 anos, enquanto outros logo depois de 1 ano de uso contínuo eles morreram. Mesmo adotando alguns truques para diminuir sua leitura e escrita, como montar com a flag noatime, os logs e outras pastas como tmpfs e desativar o swap.

Outra preocupação com os backups são os ataques ransomware, se seu computador teve os arquivos sequestrados, depois de sincronizar os backups também podem estar comprometidos. Por isso é aconselhável ter backups versionados, no qual teremos um “histórico” dos arquivos e no caso de um ransomware, basta restaurar a penúltima versão dos backups no qual os arquivos originais estarão lá.

Uma prática indispensável quando falamos de storage é o Redundant Array of Independent Disks (RAID: Arranjo redundante de discos baratos) que permite combinar os discos para que o sistema operacional os enxergue tudo como um disco só. Os dois modos mais básicos são o RAID 0 e RAID 1. No RAID 0 temos 2 discos que vão somar suas capacidades, enquanto no RAID 1 teremos a capacidade de apenas 1 disco e outro é usado como redundância caso um disco falhe, bastando trocar o disco quebrado que os dados serão espelhados nele.

Existem outros níveis de RAID, que são no fundo combinações do 0 e 1, como o RAID 5 (no qual teremos 4 discos, mas apenas podendo utilizar apenas o espaço de 3, pois 1 drive é usado como redundância).

A fim de combinar os discos utilizando o RAID temos diversas implementações que podem ser usadas no Linux. A mais simples é o mdadm que mapeia os drives num “disco virtual”.

Outra solução um pouco mais avançada é utilizar o LVM que é um gerenciador de volumes que permite coisas mais avançadas como diminuir e aumentar as partições usadas e realizar snapshots, que é um “retrato” do sistema de arquivos que pode ser acessado depois, dessa forma criando um “ponto de restauração”.

Por fim os sistemas de arquivos recentes como BTRFS e ZFS podem ser usados RAID e tem recursos legais como os snapshots, compressão nativa dos arquivos (dessa forma aqueles arquivos de texto como dados em csv ficam bem menor) e por fim como esses sistemas de arquivos usam o conceito de copy-on-write ou seja para toda escrita será feita uma cópia para manter a versão anterior, isso permite que para realizar a manutenção dos disco (o fsck, a checagem da integridade do sistema de arquivos) não precise desligar tudo (nesses sistemas o equivalente do fsck é o scrub).

A única ressalva para usar o ZFS e BTRFS são bancos de dados, o copy-on-write nos bancos de dados prejudica o desempenho, nesses casos talvez seja uma boa manter o sistema operacional num sistema de arquivos tradicional como ext4 e os bancos de dados nele e o armazenamento restante no ZFS ou BTRFS.

Outra preocupação é a criptografia dos discos, para proteger os arquivos em caso de furto, nesses casos é uma boa instalar o pacote dropbear-initramfs (tutorial) que permite entrar com a senha da criptografia de forma remota (por ssh), sem precisar ter um teclado in loco.

Fonte: https://twitter.com/nixcraft/status/1313909322905083905

Uma regra de ouro dos backups é a regra 3-2-1, que diz que devemos ter ao menos 3 cópias, em 2 mídias diferentes e 1 “fora de casa” em caso de incêndio. Para ter esse backup fora de casa é mais prático usar a nuvem, mas como utilizar a nuvem de forma segura? Podemos utilizar uma solução de backup que tenha criptografia, como o borgbackup, outra opção para utilizar o Google Drive, Dropbox e similares é utilizar o cryptomator.org que criptografa seus dados antes de enviá-los para a nuvem.

Partindo para as indicações, veja o vídeo do Fabio Akita: Quebrei 3 HDs: Entendendo Armazenamento explicando como os discos rígidos funcionam. E o meu texto de como montei minha solução de backups criptografados com o borgbackup e syncthing no Android: Como parei de me preocupar e passei a adorar minha solução de backups.

Como acessar meus serviços fora de casa?

Em algumas operadoras como a NET, seu modem tem um IP “interno” dentro da rede da operadora, pois os IPs IPV4 são muito escassos, o famigerado Carrier-grade NAT (CGNAT), dessa forma não é possível acessar sua casa através da internet.

Explicação sobre o NAT (fonte)

O único jeito é ligar na operadora e pedir para sair do CGNAT, permitindo assim hospedar na internet seus serviços. Foi o que fiz (tenho NET), mas não consigo abrir algumas portas como a 80 (http) e 443 (https), pois na NET isso só é permitido comprando o plano para empresas 😞

Pesquise e pergunte no /r/InternetBrasil, lá tem muito conteúdo sobre isso.

Outra questão é que os IPs não são fixos. Dentro da sua casa, quando a Raspberry Pi liga ela “pede” um IP pro seu roteador, o Dynamic Host Configuration Protocol (DHCP) que atribui um IP para a Raspberry Pi, mas os IPs muitas vezes são alocados de sequencial, ou seja nem sempre a Raspberry Pi vai ter o mesmo IP, quebrando o encaminhamento de portas do roteador. Então no roteador na configuração do DHCP atribua um IP fixo para a Raspberry Pi.

Outro IP que não é fixo é o do seu modem, que é o seu IP público na internet, infelizmente às vezes ele acaba mudando (de novo no plano para empresas o IP é fixo), daí surgem os serviços de DNS dinâmico, como o DynDNS ou NOIP, eu utilizo o duckdns e no google domínios tem a opção de DNS dinâmico.

A partir daí é só fazer os encaminhamentos de portas no seu modem, evite a opção DMZ, que expõe completamente a Raspberry Pi na internet, encaminhe apenas as portas que realmente precisa expor. Outra opção é ter um roteador próprio, e o usar o modem da operadora apenas como modem colocando no modo bridge e o seu roteador vai atuar como firewall encaminhando apenas algumas portas. Eu faço isso com meu roteador usando o OpenWRT e criei algumas VLANs (redes lógicas separadas para segregar os equipamentos) para minha rede.

Diagrama do proxy reverso (ngrok)

Outra opção é utilizar um serviço de proxy reverso, que basicamente torna seu localhost público, como ngrok, ou a solução open source pagekite.

Na mesma linha pode ser utilizada a sua VPS na cloud como proxy para acessar suas coisas em casa, pode ser algo simples como o autossh que cria tunnels ssh permitindo acessar sua casa passando pela VPS.

Ou criar uma VPN com wireguard na sua VPS e conectar sua Raspberry Pi, viabilizando seu acesso externo. O legal dessa solução é que você pode criar duas configurações no seu computador/celular: uma que usa a VPN apenas para acessar seus serviços e uma que passa todo seu tráfego pela VPN para usar em WiFis não confiáveis como WiFis públicos.

Por fim, outra possibilidade é usar o Tor, para criar um .onion que permite hospedar seus serviços em casa, sem precisar abrir suas portas, veja a documentação: onion-services.

Uma preocupação em expor seus serviços na internet é a de segurança, pois os mesmos podem ser hackeados e o hacker estará na sua rede. Isso pode ser feito de forma segura adotando as medidas de segurança que falaremos, mas outra possibilidade é utilizar o port knocking, no qual as portas dos seus serviços ficam fechadas e depois de “bater” numa sequência de portas corretas (tipo uma senha) a porta é aberta, apenas para o IP, e por um período de tempo, escondendo e protegendo seus serviços. Utilizo o knockd com o firewall ufw.

Contêiners

Os contêineres vieram para ficar e são uma maneira simples e rápida para colocar seus serviços no ar. Mas é preciso tomar cuidado em usar apenas imagens confiáveis, no fundo você está rodando um software feito por um terceiro na sua máquina.

Foram encontradas imagens maliciosas minerando bitcoin, ou imagens desatualizadas e vulneráveis. Antes de utilizar uma imagem dá uma olhada no Dockerfile no github para procurar por coisas suspeitas.

Imagens oficiais do dockerhub são confiáveis, outra fonte excelente de imagens é o LinuxServer.io com diversas imagens ótimas.

Partiu para as indicações? Tem um site excelente para aprender docker, bem direto ao ponto o docker-curriculum.com, curso eu indico o docker-mastery na udemy que até fala um pouco de clusters com docker swarm e kubernetes, por fim no youtube tem o vídeo excelente da TechWorld with Nana Docker Tutorial for Beginners.

Proxy Reverso

Quando vamos hospedar diversos serviços uma construção comum que é utilizada é o proxy reverso, com ele quando vamos acessar nossos serviços evitamos de ter que usar uma porta diferente para cada coisa, dessa forma podemos configurar o proxy reverso para como cada serviço vai ser acessado, normalmente por um subdomínio tipo nextcloud.seu-dominio.tld ou como uma subpasta seu-dominio.tld/nextcloud.

Ilustração de um proxy reverso

As opções mais populares são o Secure Web Application Gateway (swag), da linuxservers.io, que é um nginx, com let’s encrypt (para ter o https) e fail2ban (que bloqueia bots e IPs que estão tentando te invadir).

A outra opção é o traefik que tem a vantagem de já ser integrado com o docker e kubernetes, dessa forma ao invés de configurar as “rotas” de cada serviço em arquivos de configuração (como é feito no nginx) as configurações vivem nos labels do contêiner de cada serviço, muito mágico ✨

Aliado com o proxy reverso, podemos utilizar o authelia, que permite ter o mesmo usuário e senha (single sign-on) sincronizado com todos seus serviços e autenticação em 2 fatores integrada em todos seus serviços, tornando tudo mais prático e seguro.

Bora para um exemplo?

version: "2.1"

services:

  traefik:
    image: "traefik:v2.4"
    container_name: "traefik"
    restart: unless-stopped
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=PathPrefix(`/whoami/`)"
      - "traefik.http.routers.whoami.entrypoints=web"

  bitwarden:
    image: bitwardenrs/server
    container_name: bitwarden
    restart: unless-stopped
    #environment: 
    #- SIGNUPS_ALLOWED=false
    volumes:
      - ./docker_vols/bwdata/:/data/
    labels: 
      - "traefik.enable=true"
      - "traefik.http.routers.bitwarden.rule=PathPrefix(`/vault/`)"
      - "traefik.http.routers.bitwarden.entrypoints=web"
      - "traefik.http.middlewares.bw.stripprefix.prefixes=/vault/"
      - "traefik.http.routers.bitwarden.middlewares=bw"

Esse é um arquivo docker-compose, é um arquivo yaml que define vários contêineres, no fundo é como se o fizesse vários docker run, um para cada contêiner.

Para executá lo, basta baixar esse arquivo como docker-compose.yml e rodar o docker-compose up -d

Temos 3 contêineres definidos: o traefik, o whoami (usado para debugar o traefik) e o bitwarden (gerenciador de senhas). Repare como as “rotas” para o traefik estão definidas nos labels de cada contêiner ✨

Espere um pouco e vamos testar tudo: abra seu navegador no endereço localhost/whoami/ , e veja a rota para o whoami funcionando. Depois vá para localhost/vault/ e acesse o bitwarden. Por fim localhost:8080 e veja o dashboard do traefik (não se esqueça de colocar uma senha depois).

No bitwarden, repare na parte volumes, aqui os dados da aplicação serão salvos na pasta docker_vols/bwdata, para ser feito o backup.

No traefik, veja em volumes: /var/run/docker.sock:/var/run/docker.sock:ro, isso vai “conectar” o docker no contêiner do traefik, fazemos isso para que o mesmo consiga “mapear” os outros contêineres e ler suas regras de roteamento em suas labels. Tome cuidado e só faça isso com contêineres que confia pois isso pode dar a permissão de acessar e comprometer os todos seus contêineres e seu computador.

Por fim repare que todos os contêineres têm restart: unless-stopped, isso é a política de restart do docker, dessa forma caso o computador seja desligado quando for ligado os contêineres serão iniciados automaticamente, unless stopped, ou seja a menos que sejam parados.

Ultimo exemplo:

version: "2.1"

networks:
  web:
    external: true
  internal_net:
    external: false

services:

  traefik:
    image: "traefik:v2.4"
    container_name: "traefik"
    restart: unless-stopped
    networks:
      - web
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  ttrss:
    image: wangqiru/ttrss:latest
    container_name: ttrss
    restart: unless-stopped
    networks:
    - internal_net
    - web
    environment:
      - DB_PASS=E7WaTdu9KPLXxYXTqtrA
      - SELF_URL_PATH=http://localhost/
      - DB_HOST=ttrss_db
      - PUID=1000
      - PGID=1000
      - TZ=America/Sao_Paulo
    depends_on:
      - ttrss_db
    labels: 
      - "traefik.enable=true"
      - "traefik.http.routers.ttrss.rule=PathPrefix(`/ttrss/`)"
      - "traefik.http.routers.ttrss.entrypoints=web"
      - "traefik.http.middlewares.sp1.stripprefix.prefixes=/ttrss/"
      - "traefik.http.routers.ttrss.middlewares=sp1"
      - "traefik.docker.network=web"

  ttrss_db:
    image: postgres:13-alpine
    container_name: ttrss_db
    restart: unless-stopped
    networks:
      - internal_net
    environment:
      - POSTGRES_PASSWORD=E7WaTdu9KPLXxYXTqtrA
    volumes:
      - ./docker_vols/ttrss_db/:/var/lib/postgresql/data
    labels:
      - "traefik.enable=false"

Continuamos com o nosso conhecido traefik, mas agora vamos colocar no ar o tt-rss, que é um leitor de feeds RSS, que utiliza um banco de dados postgres, essa é a primeira coisa diferente nesse exemplo repare que no topo estão definidas 2 redes (uma chamada web e outra internal_net). O traefik que é o contêiner que está exposto está apenas na web, a aplicação (ttrss) em ambas as redes e o banco de dados apenas na internal_net. Fizemos isso para segregar o banco de dados (que contêm dados sensíveis) do traefik para que o mesmo caso comprometido não acesse o(s) banco de dados.

Outra coisa a destacar é a opção depends_on, que cria um relação de dependência entre o contêiner da aplicação (ttrss) e o seu banco de dados, iniciando o banco de dados antes da da aplicação.

Segurança

A fim de manter tudo isso seguro, existem diversas práticas e níveis de segurança, um bom começo é ter senhas fortes e únicas (evitar o famoso usuário admin com senha admin) com um gerenciador de senhas e realizar as atualizações de segurança.

Para deixar todos seus contêineres atualizados, tem o Diun, que “conecta” no docker (como fizemos com o traefik) e verifica periodicamente se existem atualizações para seus contêineres, disparando uma notificação via email ou telegram etc …

Já para manter o host atualizado, uma possibilidade é utilizar o UnattendedUpgrades que atualiza os pacotes automaticamente, e se quiser pode até reiniciar automaticamente quando necessário. Porém, talvez seja melhor assinar as listas de email/rss de segurança da sua distro (debian security-announce, Ubuntu USN), do docker e das suas aplicações e frameworks e veja se faz aquelas atualizações de fato te afetam e se realmente faz sentido aplica-lás.

https://twitter.com/nixcraft/status/878903460871061504

Um site excelente para deixar nos favoritos é o Open Web Application Security Project (owasp) é uma comunidade de segurança com diversas dicas e recomendações, por exemplo: como armazenar senhas de forma segura e no nosso caso Docker security.

Uma forma excelente para aprender segurança é praticar nas Capture the flag (CTF) que são ambientes controlados para testar a segurança como um todo e revelar a flag (tipo uma senha), comprovando que conseguiu comprometer a segurança. Tem vários sites, tenho mais contato com o overthewire e o hackthebox.

Um vídeo que gostei foi do LiveOverflow: Protect Linux Server From Hackers, no qual ele disseca as dicas populares de boas práticas para proteger seus servidores linux e ele mostrou que essas boas práticas nem sempre são tão positivas e “preto no branco”. Depois ele fez uma continuação bem interessante: Understand Security Risk vs. Security Vulnerability! pontuando as diferenças e semelhanças entre riscos de segurança e vulnerabilidades.

Monitoramento

Na seção anterior sobre storage, como saberemos se um disco falhou? Quando tudo parar de funcionar? Ou tem algum jeito de “ficar de olho”, por isso que precisamos ter uma solução de monitoramento.

As soluções mais populares de monitoramento são o zabbix e o prometheus, que depois de configurados te notificam em caso de alguma falha.

No caso dos discos, temos dois indicativos que os discos estão para falhar: As informações S.M.A.R.T. – Self-Monitoring, Analysis, and Reporting Technology (tecnologia de automonitoramento, análise e relatório) geradas pelo próprio disco com diversas informações da “saúde” do disco, o disco não gera isso sozinho, sua solução de monitoramento precisa disparar os auto-testes e monitorar essas infos. Porém um estudo de 2007 do Google, mostrou que os dados S.M.A.R.T sozinho não são um bom indicativo da falha dos discos, daí surgem o segundo indicativo o tempo de escrita e leitura, se o disco começa a demorar muito para ler ou escrever isso pode indicar uma falha, essa informação é gerada na solução de monitoramento.

Outra solução legal de monitoramento é o healthchecks.io, serviço para monitorar seus cronjobs (tarefas executadas periodicamente), por exemplo imagine que você configurou para fazer backup do seu laptop na sua Raspberry Pi, mas por algum problema o backup para de ser feito com sucesso. Como vai saber que parou de funcionar? No healthchecks.io você configura uma periodicidade que os backups devem ser feitos e quando é feito o backup seu laptop “pinga” o serviço, e em caso de falha ou o backup deixou de rodar uma notificação é enviada.

Infraestrutura como código

Essa é a parte mais legal 🤩, chegou o dia que seu SD card da Raspberry Pi morreu 😞 , tranquilo só fazer a restauração do backup no SD novo e instalar e configurar tudo mas isso pode ser demorado, com a infraestrutura como código (IaC) você cria uma “receita” que configura toda sua infra automaticamente.

A ferramenta que tenho mais contato é o ansible, ele é similar ao chef e puppet. A principal vantagem do ansible é que ele é agentless, ou seja não precisa de um ter software instalado esperando por instruções do controle, basta ter o python instalado e acesso ssh e na máquina que vai disparar o ansible basta instalar com um pip install, super prático.

Apesar de ser muito legal automatizar a configuração dos ambientes com IaC, se tudo é importante nada é importante, a IaC não precisa estar no topo das suas prioridades quando configurando seu setup.

Considerações finais

Espero com essa visão geral dos aspectos do self-hosting tenha uma noção do que se trata e comece a aprender mais sobre o tema e adotar esse movimento.

Além de todas indicações que já fiz vou fechar indicando um podcast: o Self-Hosted podcast que me ajudou muito a aprender sobre esses tópicos e o canal do YouTube: Techno Tim que tem várias dicas de como montar seu homelab.

O que é selfhosting e por que adotá-lo

Fri, 28 May 2021 16:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 28Maio2021

Muitos dos serviços digitais que utilizamos no nosso dia a dia estão na “nuvem”, como Gmail, LinkedIn, Google Drive/Docs etc … e como diria um famoso ditado “essa tal de “nuvem” não existe, são apenas computadores de outras pessoas”. Mas, então quais as implicações da maioria das nossas vidas digitais estar nesses computadores dessas grandes empresas? Essas implicações no geral são positivas para os usuários?

Neste texto, que vai ser o primeiro de uma série, vamos falar de uma alternativa simples chamada self hosting, ou seja, hospedar os serviços que usamos em computadores que de fato temos controle, e como fazê-lo.

Motivos para adotar o self-hosting

Dentre todos os motivos para adotar o self-hosting, vale destacar os seguintes:

Segurança

Com muita frequência, vemos notícias de vazamentos envolvendo nossos dados, e mesmo assim muitos dos vazamentos não são percebidos pelas próprias empresas e logo não são noticiados, ou seja, a quantidade de vazamentos pode ser ainda maior.

Hospedando as próprias coisas não é um alvo tão grande para os cibercriminosos quanto das big tech, pense nos incentivos, se comprometer uma big tech o cibercriminoso vai ter os dados de milhões de pessoas , enquanto comprometer sua pequena infra não rendera tanto dados assim. Além disso outro incentivo para atacar as big tech é que muitas delas tem programas de bug bounty para recompensar a descoberta da suas inseguranças.

E também isso vai te ensinar quais são as boas práticas de segurança e como adota-lá.

Privacidade

Outro ditado famoso diz que se o serviço é gratuito, o produto é você. E isso é verdade, você está pagando o serviço com seus dados.

Com selfhosting, seus dados ficam apenas com você, retomando totalmente sua privacidade, afinal foi você quem montou o esquemas de criptografia de disco, gerenciamento de senhas (afinal como as senhas sempre vazam não pode usar a mesma senha em mais de um lugar, é bom se inscrever no haveibeenpwned.com para ser notificado se suas senhas vazaram)

Aprendizado e experiência

Pra min essa é a principal vantagem, hospedar suas próprias coisas vai proporcionar um conhecimento e experiência enorme em diversas disciplinas como:

Sistemas operacionais (principalmente Linux e talvez BSD).
Redes
Segurança
Contêineres
Linguagens de script
Infraestrutura como código
Monitoramento
E principalmente Inglês

Ter o seu “ambiente controlado” vai te possibilitar aprender, testar e quebrar as coisas que te proporcionará um aprendizado enorme que num ambiente profissional do trabalho muitas vezes não te permitiria.

Exemplos de aplicações

As aplicações mais comuns que normalmente são hospedadas são:

Pi-Hole: Permite bloquear anúncios, domínios que te rastreia e maliciosos a nível de rede, ou seja em todos seus dispositivos não apenas no navegador.
syncthing: É um app pra Android no PC que permite sincronizar pastas do seu android com o PC e vice versa. Dessa forma você consegue fazer backup do seu celular e sincronizar arquivos sem precisar de uma nuvem das big tech. Se tiver interesse leia meu texto de como montei meu setup de backups: Como parei de me preocupar e passei a adorar minha solução de backups.
nextcloud: É uma solução de nuvem completa, permite sincronizar arquivos como dropbox, sincronizar contatos e agenda, quadro kanban (tipo trello), videochamadas e muito mais.
Home Assistant: Gosta da sua alexa ou google assistant controlando suas luzes e outras coisas da sua smart home? Com o Home assistant você consegue ter seu próprio hub de automação com total privacidade e controle. Gosta de eletrônica? O projeto esphome consegue integrar suas plaquinhas ESP8266/ESP32 com o Home Assistant.

Considerações finais

Com o selfhosting você terá privacidade e controle total dos seus dados e vai aprender muito nessa jornada, nós próximos textos vamos abordar de fato começar.

Vale uma pequena ressalva, casos você seja uma pessoa dev e só quer colocar seu app no ar, e seu objetivo principal agora é apenas isso, talvez ir pelo caminho do selfhosting não seja a melhor alternativa agora, administração de sistemas é muitas vezes um trabalho de tempo integral e talvez seja melhor usar serviços como heroku, vercel e netlify que cuidaram de tudo para você, para que consiga fazer essa entrega mais rápido. E quanto tiver disponibilidade estudar e adotar o selfhosting :P

Utilizando o RSS para "furar a bolha"

Tue, 27 Apr 2021 13:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 27Abr2021

Já percebeu que o seu feed da rede social está cheio de notícias que fazem você “passar raiva”? O fenômeno é chamado de doomscrolling, e apesar que de termos mais notícias desse tipo, as redes sociais as exibem com mais frequência.

A conhecida “bolha” (filter Bubble) das redes sociais faz com fiquemos mais tempo nas redes, exibindo apenas posts que engajamos mais, e isso está causando diversas consequências nefastas desde potencializar fake news e desinformação a ansiedade e depressão nos internautas.

Mas se eu te disser que existe uma alternativa? Um meio de receber as informações diretamente, sem nenhum filtro ou algoritmo. É disto que vamos falar hoje, o RSS.

Logo do RSS

O que é o RSS?

RSS é a sigla para Really Simple Syndication, sincronização realmente simples, é um arquivo XML gerado por muitos sites que exibe os posts que o site tem, dessa forma a pessoa com um leitor de RSS consegue acompanhar diversos blog, sites de noticia e etc … centralizados no seu leitor.

Quem criou o RSS?

Uma das pessoas responsáveis pela criação do RSS foi o Aaron Swartz, um hacker conhecido por diversas coisas como o Creative Commons e da melhor rede social o Reddit 😛

Aaron Swartz (2008), Fonte: wikimedia

Quem se interessou pela historia do Aaron recomendo os seguintes conteúdos:

O documentário: O Menino da Internet: A História de Aaron Swartz: LibreFlix
E pra quem gosta de podcast Engenharia Reversa #1: Aaron Swartz, a história do ativista e co-criador do Reddit e do RSS

Como usar o RSS? Parte 1: Os leitores

Para usar o RSS você precisa de um leitor de RSS, e não faltam opções! A primeira classe de leitores são os locais, um app local no seu computador ou celular que infelizmente não sincroniza entre seus dispositivos, se isso não é um problema para você é uma ótima opção.

O thunderbird (cliente livre de emails) é a opção mais tradicional.

Gosta de programas que rodam no terminal? tem o newsboat.

Para Linux tem o liferea que está disponível na maioria das distribuições.

No Android tem o Feeder, que também está disponível na Fdroid (loja de aplicativos livres).

Tem Mac ou iOS? Uma opção ótima é o NetNewsWire.

Depois desse monte de opções, se não quiser instalar nada 😛 tem o Feedbro extensão para os navegadores (chrome e firefox).

Essas são todas as opções de leitores locais que conheço.

Vamos agora para as opções online, que permitem sincronizar entre seus dispositivos, é muito prático pois se viu algo interessante no computador pode marcar para ler depois no celular e vice versa.

O Feedly é o serviço mais conhecido, tem um plano básico gratuito, bem amigável, para quem está começando recomendo ir com ele.

Captura de tela do Feedly

Por fim, a opção que eu uso, para quem gosta de software livre e se preocupa com sua privacidade, o Tiny Tiny RSS (tt-rss.org). Você pode instalar numa raspberry-pi e acessar na sua rede local (caso precise acessar fora de casa pode usar serviços como Pagekite e ngrok para torna-ló acessível pela internet) ou alugar uma cloud e hospedar lá.

Outra opção para usar o tt-rss é utilizar a instancia do Snopyta (grupo sustentado por doações que hospeda diversos softwares livres).

Como usar o RSS? Parte 2: Assinando os feeds

Com um leitor de RSS da sua preferencia funcionando, bora assinar os feeds!

Vamos começar pelo YouTube, os feeds são assim:

www.youtube.com/feeds/videos.xml?channel_id=<id_do_canal>

Substitua no final pelo channel_id do canal que quer assinar. Um truque para descobrir o id que tem interesse: Selecione um vídeo, em seguida clique no ícone do canal e daí o channel_id vai aparecer na url. Por exemplo, o feed do canal da Jana Viscardi é o seguinte:

www.youtube.com/feeds/videos.xml?channel_id=UC9h2vDtQXEiD0O4aVubsYYA

Caso o truque não funcione, com o vídeo aberto, abra o código fonte da página (use o atalho control+u) e procure (control+f) por channelId.

Para acessar os feeds da melhor rede social 😛, o Reddit:

Na wiki tem uma seção sobre RSS, basta colocar um .rss no final. Por exemplo o feed do /r/dataisbeautiful é:

old.reddit.com/r/dataisbeautiful/.rss

Precisa acompanhar projetos do github? Por exemplo, utilizo aqui em casa um firmware livre no meu roteador, o OpenWRT, para acompanhar as releases o feed é:

github.com/openwrt/openwrt/releases.atom

No mesmo padrão para acompanhar os commits, da branch master:

github.com/openwrt/openwrt/commits/master.atom

Obs.: Os feeds atom na prática são a mesma coisa que feeds RSS, alguns sites adotam isso.

Gosta de Newsletters? O serviço kill-the-newsletter.com cria um e-mail para você cadastrar na newsletter e um feed para assinar.

Veja o diretório de Newsletters brasileiras que o manual do usuário fez.

Gosta do medium? o feed é assim: medium.com/feed/nome-do-usuario, por exemplo, o feed do computando arte 🤭 é:

medium.com/feed/computando-arte

E o Twitter? Infelizmente o twitter descontinuou os seus feeds RSS 😞 Mas tem um software livre chamado Nitter que permite navegar pelos posts do twitter com privacidade e gerar um feed rss.

Tentei mostrar como chegar nos feeds de alguns serviços populares, mas e os outros? Então muitos sites e podcasts tem o ícone e/ou o link do seu feed, caso não encontre procure no código fonte da pagina por rss ou feed ou xml ou atom e você vai acabar encontrando. A maioria das tecnologias por trás dos sites como o super popular WordPress gera nativamente os feeds RSS.

Por exemplo, até meu site pessoal simples uso o Hugo (gerador de sites estáticos, semelhante ao Jekyll) e coloquei o link pro meu feed, mas se for procurar no código fonte da página encontrará:

<link rel="alternate" type="application/rss+xml" href='https://caioau.net/blog/index.xml' title="Blogs on Pagina do caioau">

Pronto, aqui você encontra o meu feed RSS:

caioau.net/blog/index.xml

Por fim, não poderia fazer um texto sobre RSS sem falar do RSS-Bridge, software livre que gera feeds RSS apartir de páginas do facebook, instagram (dá até pra seguir hashtags ✨) , Wikipedia e várias outras integrações.

Considerações finais

Com o RSS podemos “furar a bolha” e receber toda a informação sem filtros e algoritmos. Usando o RSS logo vai perceber uma das razões (além do lucro das big tech 💸) do porque desses filtros, é muita informação! Então use com moderação (para evitar o famoso FOMO, fear of missing out, a sensação de que não posso ficar minutos longe do meu celular pois estou perdendo algo) e tentar uma relação mais saudável com a tecnologia.

Vale recomendar o episódio #41 do tecnocracia, é um podcast excelente sobre as consequências da tecnologia e vou indicar justamente o ep. #41: Manual prático para retomar sua atenção do calabouço das redes sociais com várias dicas 🧘🔕 de como controlar o celular e as redes sociais e não o contrário.

Estamos usando a tecnologia? Ou sendo usados? (Fonte)

Por fim, pra quem gosta do tema, vou indicar alguns conteúdos muito interessantes 🤯

Crédito: Cryptorave no twitter

O documentário Dilema nas Redes (2020), disponível na Netflix, bombou! Adoro como ele é muito didático e expões as principais questões do tema, recomendo muito pra quem ainda não viu. Outro doc, é o Coded Bias (2020) que foca mais nas tecnologias de reconhecimento facial e seus vieses e contou com a presença da Cathy O’Neil, autora do livro fenomenal Weapons of Math Destruction traduzido no Brasil como Algoritmos de Destruição em Massa.

Uma talk recente, que eu adorei foi a Rage Against The Machine Learning, onde o Dr. Hendrik Heuer fala da sua pesquisa de auditoria dos algoritmos das redes sociais para o interesse público.

Para podcast, vou indicar outros episódios do tecnocracia, é difícil indicar só alguns, todos são ótimos:

O que é um tarpit de rede e como colocar um no ar

Mon, 18 Jan 2021 13:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 18Jan2021

Foto de Ariel Besagar, Unsplash

Quando vemos as notícias de cyber ataques, como o WannaCry, é impressionante o impacto desses ataques, infectando milhares de computadores. No caso do WannaCry existia uma atualização de segurança que foi publicada 1 mês antes do ataque, quem não atualizou e estava exposto na internet provavelmente foi infectado. Moral da historia é deve se tomar todas precauções de segurança antes de expor algum computador na Internet. Se tiver interesse, leia as essas estatísticas:

Assim que se coloca algum serviço na internet pública, em poucos minutos, já vemos que os logs de acesso do ssh (protocolo para acessar remotamente computadores) estão lotados de tentativas de combinações de usuário e senha, para conseguir acesso no servidor. Neste texto vamos mostrar como se proteger e como colocar um tarpit no lugar, uma especie de “armadilha” que deixa os atacantes “parados” perdendo tempo e recursos sem atacar ninguém, protegendo quem está vulnerável.

Logs de acesso do ssh: Fonte

Começando pelo começo: protegendo seu servidor ssh

De todas as mitigações para proteger seu servidor ssh, a medida mais efetiva é desativar a autenticação por senha e utilizar apenas a autenticação por chaves privadas. Se ainda não tem uma chave ssh, gere uma com o comando ssh-keygen.

Copie sua chave pro seu servidor: ssh-copy-id -i ~/.ssh/id_rsa usuario@servidor, se necessário ajuste o caminho da chave depois do -i .
Teste se está funcionando: ssh usuario@servidor , se o ssh conectar sem pedir senha então está tudo certo.

Desativando autenticação por senha: logue no servidor (ssh usuario@servidor), e edite o arquivo /etc/ssh/sshd_config como root (sudo nano /etc/ssh/sshd_config), por fim encontre a linha PasswordAuthentication e coloque no, não se esqueça de não deixar a linha comentada (tire o # no começo da linha). Por fim, reinicie o ssh, sudo systemctl restart sshd

Testando: Tente logar com um usuário que não existe: tipo ssh usr123321@servidor, e deve aparecer Permission denied (publickey).

É isso que vai acontecer com quem tentar acessar seu servidor, uma permissão negada sem nem pedir senha.

endlessh: O que faz um tarpit?

A tradução de Tarpit é “poço de areia movediça”, no nosso contexto de redes é um serviço que intencionalmente insere um atraso, atrasando os clientes que estão conectando e os forçando esperar.

O endlessh é um tarpit de ssh, ele explora um “brecha” na especificação do ssh (RFC 4253) que diz que quando um cliente está conectando o servidor pode mandar um “banner” (aqueles avisos legais avisando a politica de segurança), mas a especificação não coloca um limite do tamanho desse banner. É assim que o endlessh funciona, um cliente conectando fica esperando mandar o resto do banner, e o endlessh fica mandando o banner de pouco em pouco só pra manter a conexão ativa. Dessa forma o atacante fica gastando banda e recursos sem acontecer nada ao invés de atacar os clientes que de fato estão inseguros.

Exemplo de banner ssh, Fonte: https://www.healthcareitnews.com/news/warning-banners-often-work-heres-how-hospitals-can-use-them-ward-hackers

Colocando o endlessh no ar

Primeiramente vamos instalar as dependências necessárias:

sudo apt install git build-essential

O apt , ou similarmente apt-get, é um gerenciador de pacotes de distribuições Debian. Pense no gerenciador de pacotes como a app store de seu celular, um programa que instala, remove e atualiza os softwares do seu sistema. É uma maravilha, pois imagine que precisa atualizar o VLC, ao invés de ir ao site e baixar o instalador mais recente basta fazer sudo apt update, para verificar se existem atualizações e finalmente sudo apt upgrade para baixar e instalar as atualizações.

O comando acima então instala o git e o pacote build-essential.

Para saber o que um pacote é, podemos utilizar o info do apt, com apt into build-essential temos:

Package: build-essential
Version: 12.9
Priority: optional
Build-Essential: yes
Section: devel
Maintainer: Matthias Klose <doko@debian.org>
Installed-Size: 20.5 kB
Depends: libc6-dev | libc-dev, gcc (>= 4:10.2), g++ (>= 4:10.2), make, dpkg-dev (>= 1.17.11)
Tag: devel::packaging, interface::commandline, role::data, role::program,
 scope::utility, suite::debian
Download-Size: 7,704 B
APT-Manual-Installed: yes
APT-Sources: <https://deb.debian.org/debian> bullseye/main amd64 Packages
Description: Informational list of build-essential packages
 ...
 This package contains an informational list of packages which are
 considered essential for building Debian packages.  This package also
 depends on the packages on that list, to make it easy to have the
 build-essential packages installed.
 ...

Instalamos o build-essential pois ele instala o compilador gcc e o make que vamos utilizar (veja na linha Depends).

Clonando o projeto:

git clone https://github.com/skeeto/endlessh.git

Agora precisamos compilar o projeto. Felizmente o projeto tem um makefile, que é um arquivo com os comando de compilações configurados. Dessa forma basta fazer make e sudo make install para gerar o binário do endlessh e copiar para /usr/local/bin.

Agora pasta rodar o endlessh:

/usr/local/bin/endlessh -v

2021-01-14T01:22:10.091Z Port 2222
2021-01-14T01:22:10.091Z Delay 10000
2021-01-14T01:22:10.091Z MaxLineLength 32
2021-01-14T01:22:10.091Z MaxClients 4096
2021-01-14T01:22:10.091Z BindFamily IPv4 Mapped IPv6

O endlessh está rodando na porta 2222, então abra outra aba no terminal e faça ssh usuario@servidor -p 2222 e veja o que acontece … ou seja nada 😆

Mas como faço pro endlessh iniciar sozinho? Na próxima secção vamos mostrar como :)

systemd: Como manejar serviços

O systemd é um sistema init, que é o primeiro processo iniciado durante o boot do sistema e ele é responsável por iniciar e gerenciar todos os serviços do sistema. Por exemplo, se está rodando um servidor web com nginx, o systemd vai iniciar o nginx automaticamente e em caso dele travar vai ser iniciado novamente, certificando-se que está sempre no ar.

Na maioria das distribuições Linux, o systemd é o sistema init padrão, que é controlado através do comando systemctl. Por exemplo: veja o status de todos os serviços: sudo systemctl status --all . aqui podemos ver a que serviço cada processo está associado.

Mão na massa: na pasta util do endlessh temos o arquivo para subir o endlessh como serviço, o endlessh.service (dentro da pasta util). Não vamos entrar no detalhe das diretivas definidas desse arquivo, aos interessados veja o artigo sobre systemd na arch wiki.

Vamos apenas mudar apenas uma coisa no arquivo, na linha exec coloque o -v, para ele rodar mostrando mais detalhes, como os exibir os clientes conectando, ficando assim: ExecStart=/usr/local/bin/endlessh -v

Vamos copiar o arquivo para ser identificado: sudo cp endlessh.service /etc/systemd/system/, agora faça sudo systemctl daemon-reload para que seja reconhecido, e então finalmente sudo systemctl enable endlessh, agora o endlessh está habilitado e deve iniciar automaticamente, para iniciá-lo agora faça sudo systemctl start endlessh.

Só para ter certeza, faça sudo systemctl status endlessh. Podemos ver o status do serviço

Como queríamos, o serviço está rodando.

Também podemos reiniciar o serviço com restart (sudo systemctl restart endlessh), e stop para parar. Para desativar temos o disable, porém caso o serviço seja dependência de outro serviço ele pode acabar sendo iniciado. Nesses casos utilize o mask que previne que o serviço seja iniciado. Por fim, temos o reload que faz que com o serviço carregue sua nova configuração sem derrubar o serviço.

journalctl: Acessando os logs

Agora que o endlessh está rodando e é iniciado automaticamente, como faço para acessar a saída dele para vem quem está conectando?

No systemd os logs de todos serviços podem ser acessados através do comando journalctl, faça sudo journalctl e veja os logs de todos serviços, inclusive do kernel.

Para vermos apenas do endlessh: sudo journalctl -u endlessh

logs do endlessh

Bora analisar os dados? 🤓

Podemos pegar a saída do journalctl e jogar num arquivo para ser lido e parseado para ser colocado num dataframe, por exemplo.

para fazer isso, basta rodar o comando:

journalctl -u endlessh.service > /tmp/endlessh.log

Dessa forma os logs estarão em /tmp/endlessh.log. Depois disso basta fazer um programa que lê o arquivo, para fazer suas análises. Mas né, sem tempo irmão 😛. Vamos pela solução simples, usar comandos de processamento de texto, do Unix ✨:

sudo journalctl -u endlessh --since 2021-01-15 --until 2021-01-16 | grep CLOSE | wc -l
1044

Da mesma forma que o operador > joga a saída pra um arquivo o | (chamado de pipe) redireciona a saída para o outro comando, dessa forma o commando acima conta quantas linhas CLOSE tinha. Ou seja no período de 1 dia tivemos 1044 conexões.

sudo journalctl -u endlessh --since 2021-01-15 --until 2021-01-16 | grep CLOSE | awk '{print $8}' | sort | uniq -c | sort -hr
    
    705 host=::ffff:218.92.0.210
     32 host=::ffff:87.251.77.206
     12 host=::ffff:81.161.63.103
     10 host=::ffff:221.181.185.220
      9 host=::ffff:81.161.63.100
      9 host=::ffff:222.187.222.53
      9 host=::ffff:221.181.185.148
      8 host=::ffff:221.181.185.135
      8 host=::ffff:122.194.229.122
      7 host=::ffff:218.92.0.211
      6 host=::ffff:81.161.63.252
      6 host=::ffff:81.161.63.101
[...]

O comando acima mostra os IPs que fizeram mais conexões.

Conclusão

Neste texto aprendemos como proteger seu servidor ssh, dessa forma ninguém não autorizado vai conseguir acessar seu servidor. E mostramos como colocar no ar um tarpit para ajudar a proteger quem ainda está vulnerável. Além disso aprendemos como manejar serviços e fazer processamento de texto de uma forma bem rápida, usando ferramentas Unix, que são tarefas muito importantes na administração de sistemas.

Como continuação dessa jornada de implementar as boas praticas de segurança, sugiro o seguinte tutorial da DigitalOcean: 7 Medidas de Segurança para Proteger Seus Servidores. Para segurança digital pessoal, o vídeo da Eva Galperin é excelente: Especialista em Internet desmistifica cyber segurança.

Como parei de me preocupar e passei a adorar minha solução de backups

Sat, 12 Sep 2020 18:00:00 -0300

Nesse texto vou mostrar como montei minha solução de backup com algumas propriedades interessantes:

Sincroniza com Android, usando syncthing.
Caso os dispositivos sejam comprometidos, os backups não poderão ser deletados/sequestrados (modo append-only).
Monitorado: caso um backup falhe, um alerta será gerado, usando healthchecks.io.
Caso tudo pegue fogo, como utilizar serviços em nuvem de forma segura.

Edits

10Apr2021: Adicionado observação para rodar o borg como usuário root e salvar pacotes instalados (diff)
16Nov2021: Nova localização da pasta do WhatsApp no Android 11 e outras pequenas atualizações (diff)
27Mar2022: Atualização das dependências para o borg 1.2 e dump banco de dados postgres em container (diff)
14Ago2022: Comentário sobre a mudança da operação prune, a partir da versão 1.2 (diff)
25Nov2024: Avisos de descontinuação, atualização na configuração do borgmatic e usando systemd (diff)
10dez2025: Atualização do borgmatic (usando a versão do debian trixie) (diff)

Agradecimentos

Primeiramente, esse texto não seria possível sem o apoio do Gustavo Gus, que além de sempre me incentivar e orientar nesses desafios, me introduziu ao borg e revisou esse texto. Confira a pagina pessoal dele: gus.computer.

Também gostaria de agradecer os amigues que sempre me apoiam e incentivam a disseminar o conhecimento.

Backup: Uma medida para evitar desastres

Toda forma de armazenamento digital de dados pode falhar. Ter backups é importante, pois precisamos ter cópias reservas caso o disco rígido falhe ou em caso de furto do computador/celular.

Regra 3-2-1

A regra 3-2-1 é uma recomendação muito popular de como fazer backups, ela diz:

3: mantenha 3 cópias dos dados importantes: 1 original e mais 2 backups.
2: salve os backups em 2 tipos de mídias: por exemplo, se você tiver um backup num HD externo e caso o seu computador seja infectado por um ransomware, o seu backup pode ser comprometido.
1: tenha 1 backup “fora de casa” (pode ser outro local físico ou na nuvem).

Um vídeo excelente explicando essa regra é: Data Backup: The 3-2-1 Rule – canal ExplainingComputers.

A ideia geral dessa regra é a seguinte: caso tenha um problema no computador, temos uma cópia local de fácil e rápido acesso. E em caso de um desastre no local, temos uma cópia remota reservada que podemos restaurar.

Começando pelo começo: Fazendo backup do Android com Syncthing

Por padrão, a maioria dos Android já faz backup das fotos (via Google Fotos) e das conversas do WhatsApp (via Google drive). Ou seja, esses dois Apps mais comuns já estão replicados.

Mas o diabo está nos detalhes. O backup do WhatsApp (e das Fotos), por padrão, está descriptografado, ou seja, o Google e qualquer um que conseguir acesso a sua conta do Google Drive conseguirá acessar todo o histórico de conversas do WhatsApp (e seus nudes do Google Fotos).

Edit: Em setembro de 2021, o WhatsApp disponibilizou a opção de criptografar os backups, veja as instruções para habilitar a criptografia dos backups.

Além disso, como já vamos montar uma infraestrutura para fazer backup para o computador é interessante aproveitá-la para fazer backup do seu dispositivo Android com mais controle e privacidade.

O Syncthing é uma forma para sincronizar os seus arquivos entre os seus dispositivos, de forma fácil, segura e sem armazenar na nuvem (ou qualquer dispositivo que não seja seu).

Como usar o Syncthing

O primeiro passo pra usar o syncthing é instalar no seu computador. Se você usa um sistema operacional baseado no Debian GNU/Linux, basta digitar sudo apt install syncthing.

Vale observar que a versão do Syncthing que muitas distros empacotam tende a ser uma versão mais antiga, então, é recomendado instalar a versão mais recente pelo site do desenvolvedor.

Além de GNU/Linux, o Syncthing funciona no Windows, macOS e *BSD.

No celular, infelizmente ele só está disponível para Android.

Uma vez instalado no computador, vamos agora instalar no Android: ele está disponível na loja de aplicativos livres F-droid e na Play Store.

Obs.: A partir de dez23 o aplicativo original (com.nutomic.syncthingandroid) será descontinuado em favor do Syncthing-Fork (com.github.catfriend1.syncthingandroid). Veja o passo-a-passo para migrar pra o novo app.

Linkando o computador com o Android

Primeiro, no computador,

Execute o Syncthing no computador e uma interface web será aberta.
clique no canto superior direito: Actions -> Show ID. Um QR code será exibido.

Segundo, no seu dispositivo Android,

Abra o Syncthing no Android e libere as permissões necessárias.
Toque na aba “devices”, e depois toque no “+” no canto superior direito. No campo “Device ID” no canto direito toque no ícone de QR code.
Será necessário instalar o app Barcode scanner. Uma vez instalado, toque novamente no ícone do QR code e escaneie o QR code do seu computador.
Por fim, de um nome para o computador no Android.

Último passo, volte para o seu computador,

Na interface web aberta haverá um aviso informando que um dispositivo novo quer se conectar. Aceite e dê um nome para o seu Android.

Sincronizando uma pasta entre o Android e o computador

Primeiro, no Android,

No Syncthing, vá na aba “Folder”, toque no ícone “+” no canto superior direito.
Dê um nome para a pasta, toque no ícone de pasta, e escolha a pasta que quer sincronizar e ative o computador.
Opcional, mas uma boa pratica, toque na opção “file versioning” e selecione a opção “TrashCan”. Dessa forma caso o computador delete um arquivo haverá um backup.
Por fim, toque no ícone de check (✔️) no canto superior direito.

Segundo, no computador,

Um aviso aparecerá na interface web informando que o dispositivo quer compartilhar uma pasta. Clique em “Add”, coloque o caminho do local para ser armazenado.
Opcional, mas uma boa prática, clique na opção “file versioning” e selecione a opção “TrashCan”. Dessa forma caso o android delete um arquivo haverá um backup.
Por fim clique em “Save”.

Pronto! Agora a pasta selecionada estará sincronizada entre o computador e o Android.

Eu pessoalmente sincronizo as seguintes pastas:

Print do syncthing: sincronizo as pastas: WhatsApp, Pictures, DCIM, Signal e syncthing

Edit 16Nov2021: A partir do Android 11 a pasta do WhatsApp mudou: antes era /storage/emulated/0/WhatsApp agora está em /storage/emulated/0/Android/media/com.whatsapp/WhatsApp (conforme o printscreen atualizado acima).

Syncthing - considerações finais

Como não esquecer executar o Syncthing? Para os backups sempre serem feitos, você pode deixar o Syncthing sempre rodando no Android, mas outra opção é abrir uma vez por dia apenas. Um app que me ajuda muito para não esquecer é o Habits, também disponível na F-droid.

Caso você tenha algum firewall instalado no seu computador, é importante liberar as portas do Syncthing, assim a transferência de dados quando você estiver na sua rede local será bem mais rápida. As portas usadas pelo Syncthing são: 22000/tcp e 21027/udp. Caso utilize o ufw, veja as instruções na documentação oficial syncthing-ufw-firewall.

Para melhorar a experiência de usuário, uma boa sugestão é instalar o cliente gráfico do Syncthing disponível no pacote syncthing-gtk. Caso utilize Windows: SyncTrayzor e macOS: syncthing-macos. Com o ícone na barra de tarefas, utilizar o syncthing é muito mais amigável e fácil.

A seguir no texto vou ensinar como configurar para fazer backup do computador num Raspberry Pi. Pode ser interessante rodar o Syncthing diretamente no Raspberry, dessa forma o backup do Android não dependerá do computador. No site tem instruções de como acessar a interface web do Syncthing no Raspberry e as instruções para iniciar o Syncthing automaticamente via Systemd.

Backup do computador: quando tudo era mato: rsync e rssh para security

Antes de eu conhecer o borg, usava o clássico Rsync para fazer os backups do computador no Raspberry Pi.

O Rsync é um programa que faz backups incrementais de forma rápida.

Como eu tinha um receio de caso meu computador fosse comprometido ele poderia comprometer o Raspberry. Descobri o rssh. Ele é um shell restrito que permite apenas o scp, rsync, sftp etc … dessa forma caso comprometido, se tentar acessar o raspberry, mesmo com as credenciais corretas não será permitido, exibindo o erro abaixo:

This account is restricted by rssh.
Allowed commands: scp sftp rsync

If you believe this is in error, please contact your system administrator

Usava o Rsync com os seguintes argumentos, executado pelo cron:

rsync -avh --stats -P --log-file=~/rsync-home.log /home/ rasp:/caminho/na/rasp

Obs.: O rssh foi descontinuado em 2019, podemos ter um comportamento semelhante usando o rssync que já vem incluso no rsync: manpage do rrsync.

BorgBackups: O Santo graal dos backups

Quando conheci o Borgbackup (vulgo borg) minha mente explodiu! Tem tudo que eu sentia que o Rsync não entregava, como:

Todos os backups são backups completos, não incrementais, dessa forma tenho o “histórico” (versionamento) dos arquivos.
- E muito mais eficiente em espaço! O Borg ocupa bem pouco espaço em disco!
Os backups são criptografados!
Os backups são comprimidos, dessa forma os meus arquivos csv enormes ficam bem menores.
Tem um modo, que vamos detalhar logo menos, chamado “append-only” dessa forma o backup só será acessado para acrescentar novas coisas, não deletar; ótimo para a segurança!

Não por acaso o Borg já foi chamado como o Santo Graal dos backups.

Borg em ação:

$ borg create -v --stats /path/to/repo::{hostname}-{now:%Y-%m-%dT%H:%M:%S.%f} /path/to/be/backuped
------------------------------------------------------------------------------
Archive name: nuc-2020-09-06T10:38:03.675158
Archive fingerprint: 8a7d8a10a54211c74e3dff1e3f5f67f65c1a85935d5e2a5ee23adb8d0fce588c
Time (start): Sun, 2020-09-06 10:38:03
Time (end):   Sun, 2020-09-06 10:38:09
Duration: 5.21 seconds
Number of files: 11645
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:                4.78 GB              4.38 GB            103.36 MB
All archives:               84.61 GB             77.59 GB              9.51 GB
                       Unique chunks         Total chunks
Chunk index:                   16246               228864
------------------------------------------------------------------------------

Acima temos a saída do borg depois de adicionados alguns arquivos num repositório de backup e executado para fazer um novo backup. Note o quão eficiente em espaço é o borg: se cada backup fosse um “tar” seriam gastos 84.61 GB . Se o tar fosse comprimido 77.59 GB, mas o borg gastou apenas 9.51GB! Esses números se referem a todos os backups do repositório (all archives).

Interfaces do Borg: borgmatic e Vorta:

O borg é utilizado através da linha de comando. Para automatizar e tornar mais fácil a operação dele temos algumas interfaces:

Pra quem usa desktop temos o Vorta:

Vamos falar mais do Borgmatic, mas para quem quer uma interface gráfica linda pro borg temos o Vorta.

Borgmatic: Torna o borg automático e completo

O Borgmatic permite que através de um único arquivo de configuração yaml seja gerenciado todas as ações do borg, além de coisas como fazer backups de bancos de dados, além de outras integrações.

Borgmatic: instalando e configurando

Podemos instalar através do pacote do Debian com um sudo apt install borgbackup borgmatic, mas não teremos a versão mais recente. Há três opções: Instalar uma versão mais recente através do backports ou baixar o binário para o computador e o Raspberry Pi (não oficial), ou compilar via pip como demonstrado a seguir.

Instalando através do gerenciador de pacotes do Python Pip

Primeiro, instale as dependências:

sudo apt-get install python3-venv python3-dev python3-pip \
libacl1-dev libacl1 \
libssl-dev openssl \
liblz4-dev libzstd-dev libxxhash-dev \
build-essential \
pkg-config python3-pkgconfig

Depois, instale o Borg e Borgmatic (instale no computador e no Raspberry Pi) dentro de um venv:

python3 -m venv ~/venv
source ~/venv/bin/activate
pip3 install -U pip setuptools wheel
pip3 install -U borgbackup borgmatic

Observação: no meu Raspberry Pi 3 demorou 7 minutos os comandos acima.

Adicionando no $PATH: tive alguns problemas dizendo que o Borg não estava instalado, porém como ele está instalado em ~/venv/bin/borg, só precisei criar um link simbólico com sudo ln -s $(which borg) /usr/bin/.

Observação: O método acima funciona bem para a maioria das situações, mas tive alguns problemas de permissão, principalmente com contêineres docker pois os arquivos dos volumes dos mesmos estavam sendo gerados com outro usuário e grupo do usuário atual. Nesses casos podemos rodar o borg com super usuário root, fazendo:

python3 -m venv ~/venv
source ~/venv/bin/activate
sudo pip3 install --user -U pip setuptools wheel
sudo pip3 install --user -U borgbackup borgmatic

Se atente para não esquecer o –user (como root/sudo), pois sem isso o pip vai sobre sobrescrever o python da sua distro, podendo causar problemas.

Arquivo de configuração borgmatic

Para gerar o seu arquivo de configuração, basta rodar o comando generate-borgmatic-config. Por exemplo, o arquivo no Borgmatic que uso é:

source_directories:
    - /etc/
    - /home/
    - /root/
    - /var/spool/ # salvar as crontabs
repositories:
    - path: usuario@rasp:/mnt/bak/borgbackups/borg_pc # hd_externo na rasp
      label: rasp-hdexterno
    - path: usuario@rasp:/mnt/borgbackups/borg_pc
      label: rasp-sdcard
    - usuario@repo2:/mnt/borgbackups/borg_pc
      label: repo2-hdd
exclude_patterns:
    - '*/.cache/'
    - '*.pyc'
exclude_caches: true
flags: false
exclude_if_present:
    - .nobackup

encryption_passphrase: "# senha gerada no keepassxc"

keep_within: 48H
keep_hourly: 2
keep_daily: 7
keep_weekly: 12
keep_monthly: -1
keep_yearly: -1
match_archives: '*'

checks:
    - name: repository
      frequency: 1 weeks
    - name: archives
      frequency: 2 weeks
    - name: data
      frequency: 4 weeks

healthchecks:
    ping_url: https://hc-ping.com/seu_uuid

before_backup:
    - /script_que_faz_port_knocking
    - docker exec -i postgres_container /bin/bash -c "pg_dumpall -U postgres" > /caminho/db.sql
    - apt list --installed > ~/apt.installed # salva a lista de pacotes instalados

Esse arquivo faz o backup dos diretórios /etc/ e /home/, no Raspberry Pi (no HD externo e outro diretório) e repo2 não incluindo caches.

Além disso, para não ocupar todo o disco, é definida uma política de retenção (prune). Dessa forma os backups antigos serão deletados. Os backups das últimas 48 horas jamais serão deletados e teremos no máximo dois backups por dia, os backups dos últimos 7 dias, 12 semanais etc … e mantemos todos os mensais e todos anuais.

Observação: A partir da versão 1.2 do borg, a operação prune não libera de fato o espaço em disco, foi criada uma nova operação chamada compact, então quando rodar o prune chame o compact em seguida.

O Borgmatic também checa a integridade dos backups (opção check do borg/borgmatic) (parte consistency), caso os arquivos sejam corrompidos no disco.

Também salva o dump de bancos de dados PostgreSQL.

No meu caso, o meu Raspberry Pi está protegido por port knocking (técnica para proteger serviços numa rede). A porta do ssh fica fechada e só abre após uma sequência de portas são batidas apenas para o IP que acertou e por um período de tempo. Então o Borgmatic executa esse script antes do backup.

healthchecks.io: É um serviço que monitora se uma tarefa (no nosso caso o backup) está sendo feito na frequência esperada. Caso o backup deixe de ser feito com exito vamos receber um email e/ou uma mensagem no Telegram (tem outras integrações). Crie sua conta no site e coloque o link que o borgmatic deve pingar.

Passo a passo

Crie o seu arquivo de configuração do Borgmatic, se quiser, adapte a partir do meu arquivo e mude as pastas que você deseja fazer backup (source_directories) e onde serão salvos (repositories).

Vale lembrar que devido ao cartão SD do Raspberry Pi, não é aconselhável salvar nada crítico nele pois depois de algum tempo o cartão simplesmente corrompe e tudo é perdido. Há algumas boas práticas para mitigar isso, mas não há milagres! Então conecte um HD externo criptografado no Raspberry Pi e salve os backups lá.

Gere sua senha segura usando um gerenciador de senhas como o KeePassXC e coloque no campo encryption_passphrase.
Por fim, crie a sua conta no healthchecks.io, configure as integrações (se quer receber alertas por email, Telegram etc …), e coloque o link do check no arquivo.
Com o seu arquivo de configuração pronto, salve-o em: ~/.config/borgmatic/config.yaml (se for rodar como root coloque-o em /etc/borgmatic/config.yaml, certifique-se que suas permissões seja 0600 e pertence a root:root)

O próximo passo é criar uma chave ssh para conectar no seu Raspberry Pi,

No terminal, faça: ssh-keygen -t ed25519 -C "usuario@PC.borg", lembrando que essa chave não pode ter senha (então só de um enter sem digitar nada), pois o backup vai rodar automaticamente. Caso já tenha uma chave importante com senha que usa pra outras coisas é interessante ter uma chave dedicada pro borg sem senha (configure seu ~/.ssh/config para controlar qual chave usar etc …)
Copiando a sua nova chave ssh no Raspberry Pi: ssh-copy-id -i ~/.ssh/id_ed25519 usuario@192.168.1.160 (ajuste o usuário e o IP) e digite a senha, depois veja se fazendo ssh usuario@192.168.1.160 ele logará no Raspberry Pi automaticamente sem pedir senha.
Para iniciar o repositório: borgmatic init -e repokey-blake2
Adicionando no crontab: para rodar o backup automaticamente, vamos colocar para ser executado via cron, faça:

$ crontab -e
5 */2 * * * ~/.local/bin/borgmatic create --stats --files --log-file ~/borgmatic.log --verbosity 1 --monitoring-verbosity 1 --log-file-verbosity 2

Repare que a opção create do borgmatic foi especificada, dessa forma o borgmatic vai apenas criar o backup, caso queira que o Borgmatic além de criar seja feito o check e prune, retire a opção create, dessa forma o Borgmatic fará o prune, depois o create e por fim o check.

Isso fará que o backup seja executado a cada 2 horas no minuto 5, dica: o site crontab.guru ajuda a entender a sintaxe do cron.

Observação, se optou por rodar o borg como root (por causa dos problemas de permissão), faça:

$ sudo crontab -e -u root
5 */2 * * * PATH=$PATH:/usr/bin:/usr/local/bin /root/.local/bin/borgmatic create --stats --files --log-file ~/borgmatic.log --verbosity 1 --monitoring-verbosity 1 --log-file-verbosity 2

Por fim, é preciso testar se o backup funcionou. Vamos restaurar um backup feito pelo borg para ver se todos os arquivos estão lá e se tudo funciona como deveria:

$ borgmatic list

t430-2020-09-07T16:00:09.936979  Mon, 2020-09-07 16:00:12 [c9...5f]
t430-2020-09-07T16:24:16.752983  Mon, 2020-09-07 16:24:21 [fa...97]
t430-2020-09-07T16:28:19.692725  Mon, 2020-09-07 16:28:22 [93...9d] <--(mais recente)

$ mkdir /tmp/borg_teste
$ borg mount /mnt/bak/borgbackups/borg_pc/::t430-2020-09-07T16:28:19.692725 /tmp/borg_teste/
$ cd /tmp/borg_teste/
$ du -shxc *
6.1G	home
6.1G	total

Repare como o du reportou que temos 6 GB de arquivos, ou seja, tudo funcionando como deveria! Outra opção é gerar um tar com a opção export-tar.

Modo append-only

Chegamos na esperada parte do modo append-only. Esse modo faz com que o borg não possa deletar ou sobrescrever os dados inseridos anteriormente.

Afim de habilitar esse modo, nós vamos especificar que quando conectado no Raspberry Pi, o Borg deve rodar no modo append-only. No Raspberry Pi edite o arquivo ~/.ssh/authorized_keys, e adicione:

Edite o arquivo para ficar:

~/.ssh/authorized_keys:
command="borg serve --append-only --restrict-to-path /mnt/bak/borgbackups/borg_pc",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGc+rutXNxxYCjFpD5v83kDXUVA8Ffh3dWlIeBOc5HgU usuario@PC.borg

Adicionamos antes da chave o seguinte: command="borg serve --append-only --restrict-to-path /mnt/bak/borgbackups/borg_pc",restrict.

Repare que o borg está sendo instanciado com a opção --append-only e opcionalmente passamos o --restrict-to-path que restringe quais repositórios aquela chave pode acessar (pode ser especificada múltiplas vezes).

Para testar, faça ssh usuario@192.168.1.160 e espere alguns segundos, dê um enter e aparecerá:

$ ssh usuario@192.168.1.160
PTY allocation request failed on channel 0

$LOG ERROR borg.archiver Remote: Borg 1.1.13: Got unexpected RPC data format from client.
Connection to 192.168.1.160 closed.

Repare que agora não é mais aberto um shell como antes, ele executa o borg assim que conecta.

Prune no modo append-only: com o append-only não conseguiremos que o borg faça o prune (deletar backups antigos, pra não encher o disco), nesse caso, copiei o config.yaml do borgmatic no Raspberry Pi e rodo prune e check de lá (não esqueça que na parte de repositories é preciso especificar apenas o caminho da pasta, sem usuario@rasp)(via cron tmb)(também criei um check no healtchecks dedicado pro prune e check).

O crontab na raspberry pi é o seguinte:

$ sudo crontab -e -u borguser

PATH=/home/borguser/.local/bin:/usr/local/bin:/usr/bin:/bin
# prune (e compact) executado diariamente
42 0 * * * borgmatic prune compact --stats --list --log-file ~/borgmatic-prune.log -c ~/.config/borgmatic.d/* --verbosity 1 --monitoring-verbosity 1 --log-file-verbosity 2 > /dev/null 2>&1

# checagem da integridade (check) executada semanalmente
21 2 * * 1 borgmatic check --log-file ~/borgmatic-checks.log -c ~/borgmatic.d/* --verbosity 1 --monitoring-verbosity 1 --log-file-verbosity 2 > /dev/null 2>&1

Trocando o cron pelo timer do systemd

Inicialmente estava usando o cron para disparar os backups, mas acabei esbarando por duas questões:

Primeiro (e mais importante): Quando o backup inicia o computador fica significativamente mais lento.

E nos servidores o arquivo de log acaba enchendo, claro que podemos usar o logrotate para configurar um setup para rotação dos logs, mas no systemd é nativo.

Por essas razões acabei migrando do cron para os timers do systemd.

Para usar o systemd precisamos definir o arquivo de configuração do serviço que roda o borgmatic e um timer que o dispara.

Definindo o serviço:

# /etc/systemd/system/borgmatic.service
[Unit]
Description=borgmatic backup
Wants=network-online.target
After=network-online.target
ConditionACPower=true
# roda apenas se plugado na tomada, se quiser rodar sempre comente a linha acima.
Documentation=https://torsion.org/borgmatic/

[Service]
Type=oneshot

ProtectSystem=full
# protege algumas pastas como /boot e /etc
Nice=19
CPUSchedulingPolicy=batch
IOSchedulingClass=best-effort
IOSchedulingPriority=6
IOWeight=100
# diminui a prioriodade de io

Restart=no
LogRateLimitIntervalSec=0

ExecStartPre=sleep 1m
# espera 1min antes de começar
ExecStart=borgmatic --stats --files -c /etc/borgmatic/config.yaml --monitoring-verbosity 1 --syslog-verbosity -1

E o timer: Nesse exemplo o backup vai rodar duas vezes por dia, uma as 2:10 da manhã e a outra as 4:10 da tarde (a sintaxe é um pouco diferente do as expressões cron). Repare no delay random de 10m, que introduz alguns minutos aleatoriamente para evitar gargalos quando muitas maquinas executam em horarios similares.

# /etc/systemd/system/borgmatic.timer
[Unit]
Description=Run borgmatic backup

[Timer]
OnCalendar=*-*-* 16:10
OnCalendar=*-*-* 02:10
RandomizedDelaySec=10m
Persistent=true

[Install]
WantedBy=timers.target

Habilitando o timer:

sudo systemctl daemon-reload
sudo systemctl enable borgmatic.service
# vendo os logs:
sudo journalctl -u borgmatic

Borg no QubesOS

O cron não vem instalado por padrão nos templates do QubesOS, instale o pacote cronie para templates Fedora e cron templates Debian, e faça qvm-service --enable work crond no dom0 no Debian é apenas cron, para habilitar o cron na Qube work.

Como usar a nuvem de maneira segura

No caso do borg, a criptografia já é nativa, então basta dar um jeito de “transferir” os arquivos do borg para a nuvem, nesses casos podemos usar o rclone.org que permite acessar os provedores de nuvem populares como Google Drive, Dropbox etc…

Outra opção é usar um provedor que suporta o borg, da mesma forma que fizemos com o Raspberry Pi com uma VPS genérica pode ser usada para mesma finalidade. Algumas hospedagens populares são: DigitalOcean, Linode, vultr, buyvm, ovh e hetzner.

Por fim, outra opção é usar um provedor que integra o borg: O rsync.net suporta e tem preço promocional para quem usar o borg, a hetzner tem storage box e o meu favorito é o borgbase.com que tem um plano gratuito com 10 GB.