systemd-resolved ile DNS-over-TLS ve DNSSEC yapılandırılması

DNS gizliliği ve bütünlüğünün önemli olduğu sunucular ve iş istasyonlarının bir karışımında çalışıyorum. Sadece UDP DNS kullanmak, sorguları dinlenmeye ve manipülasyona açık bırakır. Bu yüzden, systemd-resolved’i DNS-over-TLS (DoT) ve DNSSEC doğrulaması için yapılandırıyorum. Bu, yukarıdaki çözümleyicilere trafiği şifreler ve yanıtların kimliğini doğrular. Bu sadece dizüstü bilgisayarlar için değil—güvenilmeyen ağlara açık herhangi bir Linux konağı faydalanır.

systemd-resolved ile DoT ve DNSSEC Kullanma Nedeni

systemd-resolved, çoğu modern dağıtımla birlikte gelen yerel stub çözümleyicidir. Uygulamalar, yerel DNS stub'u (127.0.0.53) üzerinden ona iletişim kurar ve yapılandırılmış protokolleri kullanarak sorguları iletir. DoT'yi etkinleştirerek, ana bilgisayar ve çözümleyici arasındaki DNS trafiğinin dinlenmesini önlerim. DNSSEC ise şifreli doğrulama ekleyerek yanıtların değiştirilmemiş olduğundan emin olur. Bu iki özellik birlikte, geleneksel DNS'deki iki büyük boşluğu kapatır.

DNS yönlendirme saldırısıyla kullanıcıların sahte giriş sayfalarına yönlendirildiği ağlar gördüm. DoT ve DNSSEC aktif olduğunda, bu tür saldırılar başarısız olur çünkü çözümleyici ya sorguyu şifreler ya da geçersiz imzalı yanıtları reddeder. Bu kurulum, SSH erişimini sınırlama veya denetim günlüklerini izleme gibi daha önce ele aldığım diğer sertleştirme adımlarıyla iyi bir uyum içinde çalışır.

systemd-resolved'i kurma ve etkinleştirme

Debian/Ubuntu'da paket genellikle varsayılan olarak kuruludur. Eğer değilse:

sudo apt update
sudo sudo apt install systemd-resolved

Servisi etkinleştir ve başlat:

sudo systemctl enable --now systemd-resolved

Etkin olduğunu doğrula:

systemctl status systemd-resolved
journalctl -u systemd-resolved --since "10 minutes ago"

Uygulamaların gördüğü DNS stub adresini kontrol et:

resolvectl status

Current DNS Server: 127.0.0.53 gibi bir satır görmelisin. Hala ISP tarafından atanan sunucular görüyorsan, /etc/resolv.conf dosyasını kontrol et—bu dosya 127.0.0.53'e bir sembolik bağ veya statik yapılandırma yoluyla işaret etmelidir. Bazı minimal kurulumlarda, bu dosyanın üzerine yazılmasını önlemek için Netplan veya NetworkManager ayarlarını ayarlaman gerekebilir.

DNS-over-TLS Upstream Yapılandırması

/etc/systemd/resolved.conf dosyasını düzenleyerek DoT sunucularını tanımlarım. Cloudflare ve Quad9, DNSSEC doğrulamasıyla güvenilir DoT uç noktaları sunar.

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
FallbackDNS=8.8.8.8#dns.google 8.8.4.4#dns.google
DNSOverTLS=yes
DNSSEC=yes

#hostname sözdizimi, resolved’in TLS sertifikasını bu hostname’e göre doğrulamasını söyler—MITM saldırılarını önlemek için kritik öneme sahiptir. Kaydedildikten sonra hizmeti yeniden başlatırım:

sudo systemctl restart systemd-resolved

Yapılandırmayı test ederim:

resolvectl query example.com

Çıktıda DNSSEC: yes ve Transaction ID: ... ifadelerini ararım. Eğer DNSSEC: no veya doğrulama hataları görürsem, upstream sunucunun DoT hostname yazımını tekrar kontrol ederim.

Şifreleme ve doğrulama kontrolü

DoT'nin aktif olduğunu onaylamak için, standart DoT portu olan 853 numaralı porta tcpdump kullanıyorum:

sudo tcpdump -i any port 853 -n

Başka bir terminalde bir DNS sorgusu çalıştırmanız gerekir—TLS el sıkışma paketlerini görmelisiniz. Upstream'e doğru düz UDP port 53 trafiği görünmemelidir.

DNSSEC doğrulaması için, bilinen hatalı bir alanla test yapıyorum:

resolvectl query dnssec-failed.org

Yapılandırılmış bir çözümleyici, DNSSEC: no döndürür ve sonucu politika bağlı olarak güvensiz veya bozuk olarak işaretler. DNSSEC seçeneği üzerinden (no, allow-downgrade, yes, validate) çözümleyicinin hataları nasıl ele alacağını ayarlayabilirsiniz. Ben sıkı doğrulama için yes seçeneğini kullanıyorum.

Yaygın Sorunların Giderilmesi

Yapılandırma değişikliği sonrası çözümleme başarısız olur: TLS el sıkışması hataları için journalctl -u systemd-resolved komutunu kontrol edin. Sık sık, bu bir DoT ana bilgisayar adı yazım hatası veya engellenmiş 853 numaralı porttur.
Yerel hizmetler resolved'i görmez: Bazı konteynerler veya chroot ortamları 127.0.0.53'i atlar. Bunların ağ ad alanını ana makineninla paylaşmasını sağlayın veya DNS'lerini açıkça ayarlayın.
İlk sorguda yüksek gecikme: DoT, TLS el sıkışması nedeniyle ek yük getirir. Ancak sonraki sorgular bağlantıyı yeniden kullanır, bu yüzden gecikme normalleşir. Uplink'iniz yüksek gecikmeli ise, dnscrypt-proxy veya unbound gibi bir ara sunucu ile yerel önbellekleme düşünebilirsiniz—ancak bu ek karmaşıklık getirir.
NetworkManager veya netplan ile çakışma: Bu araçlar /etc/resolv.conf dosyasını üzerine yazabilir. Ben ya resolved'i sembolik bağ üzerinden yönetirim (ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf) ya da bu araçların DNS işleme özelliğini devre dışı bırakırım.

Bu kurulum ne zaman mantıklı olur

DoT ve DNSSEC'i şu durumlarda etkinleştiririm:

Kamu Wi-Fi'ne bağlanan dizüstü bilgisayarlar
DMZ'deki kenar sunucular
Sıfır güven ortamındaki iş istasyonları
DNS bütünlüğü uyumluluk kapsamındaki herhangi bir konak

Bu, uç nokta güvenlik duvarları veya şifrelenmiş SNI'nin yerini tutmaz, ancak temel bir katmanı oluşturur. Daha önce belirttiğim gibi, bu kurulumu DNS tabanlı tehdit önleme ile (örneğin çözümleyici seviyesinde bilinen kötü amaçlı alan adlarını engelleme) birleştirmek, saldırıların maliyetini önemli ölçüde artırır.

Son notlar

systemd-resolved mükemmel değil—özel çözümleyicilerin bazı gelişmiş özelliklerini eksik—but systemd ile sıkı entegrasyonu, ek daemonlar olmadan DoT ve DNSSEC'i çalıştırmanın en kolay yoludur. Yapılandırıldıktan sonra, açıkça atlanmadığı sürece arka planda sessizce çalışır ve her DNS sorgusunu şifreler ve doğrular.

Birden fazla konak yönetiyorsanız, yapılandırmayı Ansible veya benzer bir araçla dağıtmayı düşünün. Ops repomda, yedek sunucular ve cron üzerinden periyodik doğrulama kontrolleri içeren bir şablon bulunduruyorum.

Linux ağ güvenliği sertleştirmesi hakkında daha fazla bilgi için, [VoIP DSCP işaretlemesi ile tc kullanımı](https://furkanikkan.com/urun/linux-tc-ile-voip-dscp-ef-isaretleme-ve-oncelik-kuyrugu-yapilandirmasi-104) konulu yazıma bakın.

Kapak görseli: USDAgov · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/41284017@N08/52288969818