E no fim de 2024, porque não fechar o ano com um ataque de DoS? Aparentemente alguém achou isso uma boa ideia. Ao menos o site não foi afetado.
Claro que também podem ter sidos acessos legítimos. Principalmente no https://linux-br.org mas eu particularmente não boto muita fé nisso.
Se você nunca ouviu falar de DoH além do Homer reclamando que fez alguma bobagem, então não está na Internet tempo o suficiente. E talvez não esteja protegendo sua privacidade como poderia.
DNS, de Domain Name Service (serviço de nomes de domíno), é o que traduz um nome de domínio como helio.loureiro.eng.br pra um endereço IP. No caso de helio.loureiro.eng.br o nome é resolvido tanto pra IPv4 quanto pra IPv6.
Por mais inocente que seja essa tradução, esse dado não tem criptografia ou qualquer outro tipo de proteção. Pode e provavelmente é usado por seu provedor de Internet pra conhecer seus hábitos de navegação e até vender esse dado pra alguém.
Pra coibir tal uso de sua informação pessoal foi criado o protocolo DoH, ou DNS over HTTPS, que é a requisição de DNS enviada por HTTPS. A vantagem desse método é que ninguém consegue diferenciar seu tráfego HTTPS como sendo uma requisição DNS ou acesso a uma página web, que é protegida por uma camada de SSL de criptografia. O firefox permite a configuração de forma bastante fácil.
Mas claro que em alguns lugares o acesso pode ser barrado pra dificultar seu acesso ao DoH e forçar o uso de um serviço de DNS local. Por padrão o firefox permite usar o serviço do Cloudflare ou do NextDNS. O que fazem alguns provedores é bloquear requisições pra esses destinos. Mesmo o serviço de DoH do OpenDNS é bloqueado.
Pra previnir isso eu habilitei um DoH relay que recebe as requisições e envia para https://doh.opendns.com/dns-query pra resolver. Então para usar o serviço, basta configurar como fiz acima no Firefox e usar o destino:
E claro que esse artigo não é só pra dizer que esse serviço está habilitado. É pra mostrar como montar o seu.
Eu usei o binário de um doh-relay escrito em Go e disponível no github aqui:
https://github.com/tinkernels/doh-relay
A compilação foi um simples comando, assumindo que tenha o Go pra fazer a compilação:
macOS in ~
✦ ❯ cd /tmp
macOS in /tmp
✦ ❯ git clone https://github.com/tinkernels/doh-relay.git
Cloning into 'doh-relay'...
remote: Enumerating objects: 461, done.
remote: Counting objects: 100% (192/192), done.
remote: Compressing objects: 100% (136/136), done.
remote: Total 461 (delta 127), reused 117 (delta 56), pack-reused 269
Receiving objects: 100% (461/461), 180.87 KiB | 3.17 MiB/s, done.
Resolving deltas: 100% (307/307), done.
macOS in /tmp
✦ ❯ cd doh-relay
macOS in doh-relay on master via 🐹 v1.22.0
✦ ❯ make linux-amd64
mkdir -p release
GOOS=linux GOARCH=amd64 go build -ldflags "-extldflags=-static -w -s" -o release/doh-relay_linux-amd64 .
go: downloading github.com/ReneKroon/ttlcache v1.7.0
go: downloading github.com/miekg/dns v1.1.54
go: downloading github.com/buraksezer/connpool v0.6.0
go: downloading github.com/gin-gonic/gin v1.9.0
go: downloading github.com/oschwald/geoip2-golang v1.8.0
go: downloading github.com/sirupsen/logrus v1.9.1
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading golang.org/x/sys v0.8.0
go: downloading golang.org/x/net v0.10.0
go: downloading github.com/gin-contrib/sse v0.1.0
go: downloading github.com/mattn/go-isatty v0.0.18
go: downloading github.com/go-playground/validator/v10 v10.13.0
go: downloading github.com/ugorji/go/codec v1.2.11
go: downloading github.com/pelletier/go-toml/v2 v2.0.7
go: downloading github.com/oschwald/maxminddb-golang v1.10.0
go: downloading github.com/leodido/go-urn v1.2.4
go: downloading golang.org/x/crypto v0.9.0
go: downloading github.com/go-playground/universal-translator v0.18.1
go: downloading golang.org/x/text v0.9.0
go: downloading github.com/go-playground/locales v0.14.1
macOS in doh-relay on master via 🐹 v1.22.0 took 9s
✦ ❯ mv release/doh-relay_linux-amd64 release/doh-relay
No servidor truta.org, copiei o binário pra /usr/local/bin. E criei grupo e usuário.
root@truta /u/l/bin# addgroup --system doh-relay
Adding group `doh-relay' (GID 135) ...
Done.
root@truta /u/l/bin# adduser --system --gid 135 doh-relay
Adding system user `doh-relay' (UID 129) ...
Adding new user `doh-relay' (UID 129) with group `doh-relay' ...
Not creating `/nonexistent'.
Em seguida adicionei um serviço ao systemd e habilitei.
root@truta /# cd /etc/systemd/system
root@truta /e/s/system# vim doh-relay.service
root@truta /e/s/system# cat doh-relay.service
[Unit]
Description=Dns-over-HTTPS relay
After=syslog.target network.target
[Service]
User=doh-relay
Group=doh-relay
WorkingDirectory=/tmp
ExecStart=/usr/local/bin/doh-relay --cache=true --doh -doh-upstream=https://doh.opendns.com/dns-query
Type=simple
Restart=always
RestartSec=3
[Install]
WantedBy=default.target
root@truta /e/s/system# systemctl daemon-reload
root@truta /e/s/system# systemctl enable --now doh-relay.service
Created symlink /etc/systemd/system/default.target.wants/doh-relay.service → /etc/systemd/system/doh-relay.service.
root@truta /e/s/system# systemctl status doh-relay
● doh-relay.service - Dns-over-HTTPS relay
Loaded: loaded (/etc/systemd/system/doh-relay.service; enabled; preset: enabled)
Active: active (running) since Thu 2024-03-07 09:47:09 -03; 5s ago
Main PID: 819347 (doh-relay)
Tasks: 6 (limit: 3535)
Memory: 4.0M
CPU: 15ms
CGroup: /system.slice/doh-relay.service
└─819347 /usr/local/bin/doh-relay --cache=true --doh -doh-upstream=https://doh.opendns.com/dns-query
Mar 07 09:47:09 truta.org systemd[1]: Started doh-relay.service - Dns-over-HTTPS relay.
Mar 07 09:47:09 truta.org doh-relay[819347]: *** Starting ***
Mar 07 09:47:09 truta.org doh-relay[819347]: time="2024-03-07T09:47:09" level=info msg="open : no such file or directory" file="geoip.go:41"
Mar 07 09:47:09 truta.org doh-relay[819347]: time="2024-03-07T09:47:09" level=info msg="resolver: [https://doh.opendns.com/dns-query], fallback: []" file="main.go:339"
O último passo foi adicionar a configuração ao apache com proxy interno conectando com a porta 15353 onde roda o doh-relay.
root@truta /e/a/conf-enabled# cat /etc/apache2/conf-enabled/doh-enabled.conf
<IfModule mod_proxy.c>
ProxyVia On
ProxyRequests Off
ProxyPass /dns-query http://localhost:15353/dns-query retry=0 timeout=10
ProxyPassReverse /dns-query http://localhost:15353/dns-query
ProxyPreserveHost on
<Proxy *>
Options FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Proxy>
</IfModule>
root@truta /e/a/conf-enabled# a2enmod proxy
Module proxy already enabled
root@truta /e/a/conf-enabled# a2enmod proxy_html
Considering dependency proxy for proxy_html:
Module proxy already enabled
Considering dependency xml2enc for proxy_html:
Enabling module xml2enc.
Enabling module proxy_html.
To activate the new configuration, you need to run:
systemctl restart apache2
root@truta /e/a/conf-enabled# a2enmod proxy_http
Considering dependency proxy for proxy_http:
Module proxy already enabled
Enabling module proxy_http.
To activate the new configuration, you need to run:
systemctl restart apache2
root@truta /e/a/conf-enabled# a2enmod proxy_http2
Considering dependency proxy for proxy_http2:
Module proxy already enabled
Considering dependency http2 for proxy_http2:
Enabling module http2.
Enabling module proxy_http2.
To activate the new configuration, you need to run:
systemctl restart apache2
root@truta /e/a/conf-enabled# apachectl configtest
Syntax OK
root@truta /e/a/conf-enabled# apachectl restart
E pronto. Um relay de DoH pronto pra servir.
06-05-2025: deu algum ziriguidum no serviço e no momento não está funcionando. Se alguém, além de mim, usava pra alguma coisa, sinto muito. Atualizo aqui quando voltar.
Finalmente criei vergonha na cara e criei um certificado pra usar https no site. Não que eu não usasse criptografia antes, mas era um certificado auto-assinado com aquele "SnakeOil". Motivo? Simplesmente uso conexão segura pra postar no site, e mais nada.
E os usuários? Bom... eu não tenho um "grande" site com muito tráfego. Acho que ninguém vai se sentir ofendido pelo fato de não ser possível acessar o conteúdo via https. Aliás, até é mas vi que várias coisas no Joomla estão apontando pra http ao usar https. Um dia eu devo arrumar isso. Ou mudar o tema pra algum que tenha isso corrigido.
Mas o importante de ter um certificado ssl pro meu https é que consegui um assinado. E gratuitamente. A autoridade certificadora startssl fornece gratuitamente certificados de nível 1. São os mais simples, mas pra quem quer algo gratuito, vale a pena.
O melhor é que bastou seguir uma receita de bolo que o pessoal da DigitalOcean fez:
Rápido, fácil e funcional. Quem ainda não tiver um certificado assinado, vale a pena tanto por ser gratuito quanto pelo aprendizado.
Como descrito e previsto anteriormente em "o último dos apaches", o servidor web IIS da Microsoft tornou-se o líder de mercado, de acordo com medições da Netcraft.
Netcraft's July 2014 Web Server Survey
Com isso chegamos ao fim de uma era de dominação do software livre. Claro que se somarmos as quantidades de servidores Apache e Nginx, teremos uma quantidade maior de servidores de software livre. Mas então teríamos de somar o IIS com os outros servidores proprietários, como Sun e NCSA.
Em números, a virada se deve à queda do uso do Apache, além do crescimento do IIS.
Em termos de sites realmente ativos, o Apache ainda continua líder, o que mostra uma certa "inflada" nesse número de servidores IIS.
Ainda de acordo com a Netcraft, essa inflada do IIS nos últimos tempos se deve aos sites chineses, principalmente os de compras, que apesar de serem chineses, estão hospedados em servidores americanos. Imagino que seja por conta dos serviços de cloud disponíveis por lá.
Fui verificar se meu querido site DealExtreme está entre os chineses que adotaram Microsoft, mas pude ver pelo Netcraft que ele está firme e forte com Linux.
Então posso continuar com minhas compras e com consciência tranquila.
Já outro dado que vi na Internet, e que aliás me faz lembrar de olhar o Netcraft, mostra que o uso de cloud Microsoft aumentou muito no último ano. Então esse efeito "inflado" de aumento de servidores, mas não ativos, deve ser com certeza o Azure.
Seria isso um reflexo da melhor qualidade do IIS? Acho que não. Apache sempre liderou com folga esse espaço. Seria então por ser gratuito? Nesse quesito, o Amazon AWS também é por 1 ano. Então não acho que seja um espaço de "servidores de experimentação", de quem está aprendendo, mas de coisa profissional, de site de e-commerce mesmo, como é dito pela Netcraft. Mas qual o motivo de escolherem IIS? Eu acho que é falta de conhecimento aliada com forte propaganda da Microsoft - e cursos - de Azure e .Net. Muitas pessoas saem das universidades sabendo isso, e nem mesmo olham pra outra coisa. Azure e .Net de hoje é o VB e Delphi de 15 anos atrás. A diferença é que estão entrando numa área que era dominada pela qualidade do software livre, mas que agora será tomada pela quantidade de uso. Assim foi com o navegador Internet Explorer 6. Riscos? Teremos novamente padrões web ditados pela Microsoft.
2014 será marcado como o ano de grandes perdas. Falecimentos de grandes personagens da história, como o autores Ariano Suassuna e João Ubaldo, e morte da presença do software livre na web. E da web livre.
Estamos em risco.
Na última edição da newsletter do site Netcraft, vi uma estatística sobre o uso do Apache webserver que me deu um frio na barriga. Assim como o clássico americano "o último dos moicanos", parece que estamos vivendo tempos de extinção também de projetos open sources.
Não, o projeto Apache não está acabando.
De acordo com as estatísticas de servidores web no ar, coletada mensalmente pela Netcraft desde quando eu soube o que era Internet (na verdade desde que eu soube o que era Linux), mostra que o uso do Apache nunca esteve num patamar tão baixo de uso. Os dados se comparam com os de 1995! Ou seja, depois de quase 20 anos reinando como o melhor webserver de todos, desbancando até os servidores proprietários da época como o da NCSA (era o Netscape?) e da própria Sun, agora o Apache vê seu rival IIS pronto pra tirar seu pódio e se tornar o mais usado servidor web.
Parte da culpa disso, é claro, vem da adoção do cloud da Microsoft, o Azure. Tem também a parcela de crescimento do "new kid on the block" do pedaço, o nginx. Mas parece ser inevitável uma mudança no comportamento de uso dos servidores web, trocando o open source pelo proprietário.
As consequências podem ser as piores possíveis, indo da diminuição de contribuições ao projeto Apache, o que talvez leve a um total abandono de seu uso, até o risco da Microsoft enfiar algum serviço proprietário web, como um protocolo fechado, que só funcione em servidores IIS/Azure com browser Internet Explorer (vide protocolo do Exchange Server com o Outlook, o MAPI). Esse risco sempre existe quando se trata de Microsoft, que não pensa duas vezes em criar barreiras de uso pra aprisionar ainda mais seus usuários.
Por outro lado mostra também que a grande maioria dos desenvolvedores estão migrando pra web. E infelizmente trazendo as péssimas práticas que aprenderam nas escolas, aquelas que têm todo um parque de ferramentas e máquinas doados pela Microsoft.
É triste de ver...
