Docker'ın yayınladığı portlar UFW'yi atlıyor, engellenen servisler internete açık kalıyor

Baypas nasıl çalışıyor

dev.to'da yazan bir geliştirici, UFW'de açıkça engellediği üç sunucu portunun — 5432'deki PostgreSQL, 6379'daki Redis ve 8081'deki iç yönetim paneli — internetten tamamen erişilebilir olduğunu fark etti. Bir kafe ağındaki dizüstü bilgisayardan yapılan bağlantı testi, ilk denemede PostgreSQL portuna ulaştı ve bir port taraması, engellenen üç portun da açık olduğunu doğruladı. Bunun nedeni bir hata veya yanlış yapılandırılmış bir kural değildi; Docker ile UFW'nin Linux güvenlik duvarına nereden bağlandığı arasındaki yapısal bir boşluktu.\n Container portu, ister docker run -p 5432:5432 ile ister eşdeğer bir Compose ports girdisiyle yayınlandığında, Docker onu her arayüze bağlar ve kendi iptables kurallarını ekler. dev.to yazısına göre, gelen bir paket önce önce nat tablosunun PREROUTING zincirine denk geliyor; buraya Docker kendi DOCKER zincirine bir atlama kuralı yerleştirmiştir. Oradaki bir DNAT kuralı, paketin hedefini container'ın dahili IP adresine yeniden yazar.

Çekirdek daha sonra paketi, host'un kendisine teslim edilen trafik değil, bir container'a yönlendirilecek trafik olarak ele alır. Yönlendirilen paketler filter tablosunun FORWARD zincirinden geçer; Docker buraya yayınlanan portlar için kendi kabul kurallarını eklemiştir. UFW'nin reddetme kuralları ise INPUT zincirinde bulunur ve paket bu zincire hiç girmez. UFW yalnızca host'a adreslenen trafiği denetlediği için, port dış dünyaya açık olsa bile durum çıktısı portu engellenmiş olarak göstermeye devam eder.

Bunun için nasıl test yapılır

Yazar, localhost'tan yapılan kontrollerin hiçbir şey kanıtlamadığını vurguluyor, çünkü loopback trafiği güvenlik duvarından farklı bir yoldan geçer. Güvenilir test, farklı bir makineden yapılan taramadır; örneğin sunucunun genel adresine karşı nmap çalıştırmak. Host'un kendisinde ise ss -tlnp, yayınlanan portta docker-proxy'nin 0.0.0.0 üzerinde dinlediğini gösterir ve iptables -t nat -L DOCKER, DNAT kuralını ortaya çıkarır — ikisi de portun UFW'yi aştığının işaretleridir.

Yazıda ayrıca bunun pratikte ne kadar kolay gerçekleştiği anlatılıyor: Geliştirme sırasında bir GUI veritabanı istemcisinin bağlanabilmesi için eklenen Compose port eşlemeleri daha sonra bir üretim VPS'sine kopyalandı ve hiç kaldırılmadı. Redis örneği, Docker ağına hapsedildiği varsayımıyla şifresiz çalışıyordu ve PostgreSQL günlükleri, varsayılan kimlik bilgilerini arayan botlarla tutarlı biçimde bilinmeyen IP adreslerinden gelen başarısız oturum açma denemeleri gösteriyordu. Yazar bir ihlal kanıtına rastlamadı, ancak bunu mühendislikten çok şansa bağlıyor.

Önerilen çözümler

Yazıda dört çözüm sıralanıyor. Birincisi, dahili servisler için hiç port yayınlamayın — aynı Compose ağındaki container'lar birbirlerine servis adıyla ulaşabilir, dolayısıyla bir uygulama herhangi bir ports bölümü olmadan postgres:5432'ye bağlanabilir. İkincisi, host erişimi gerçekten gerektiğinde 127.0.0.1:5432:5432 gibi bir eşlemeyle loopback'e bağlayın ve SSH üzerinden tünelden girin. Bu kurulumda DNAT kuralı hâlâ vardır, ancak yalnızca localhost'a adreslenen trafikle eşleşir; böylece genel arayüzden gelen hiçbir şey içeri giremez.

Üçüncüsü, /etc/docker/daemon.json dosyasına "ip": "127.0.0.1" ekleyerek loopback'i varsayılan yapın. Bu durumda çıplak bir -p bayrağı 0.0.0.0 yerine 127.0.0.1'e bağlanır ve bir şeyi herkese açık hale getirmek açıkça 0.0.0.0 öneki gerektirir. Mevcut container'lar, oluşturuldukları bağlamaları korudukları için bu değişiklikten sonra yeniden oluşturulmalıdır. Dördüncüsü, herkese açık olması gereken ama kısıtlanacak portlar için, Docker'ın FORWARD'un en üstünde atladığı ve dokunmadığı DOCKER-USER zincirinde trafiği filtreleyin. O noktaya gelindiğinde DNAT hedefi zaten yeniden yazmış olduğundan, kuralların conntrack kullanarak orijinal portla eşleşmesi gerekir. Yazar, Docker'ın iptables yönetimini "iptables": false ile devre dışı bırakmaktan sakının diyor; bu, bir sürprizi, container ağlandırmasında daha sessiz birkaç bozulma biçimiyle takas etmek anlamına gelir.

Neden önemli

UFW, Linux sunucularında en yaygın çevre güvenliği araçlarından biridir ve bu senaryoda durum çıktısı aktif biçimde yanıltıcıdır: engellenen portları kapalı gösterirken internet onlara hâlâ ulaşabilir. Güvenlik duvarı arkasındaki bir host'ta Docker çalıştıran herhangi bir ekip — özellikle kolaylık için veritabanları, önbellekler veya yönetim araçları yayınlayanlar — kapalı olduğuna inandıkları servisleri açığa çıkarıyor olabilir. Bu başarısızlık sessizdir, denetim ucuzdur çünkü herhangi bir dış makineden yapılan bir tarama bunu ortaya çıkarır ve çözümler yapılandırma düzeyinde değişikliklerdir. Bu birliktelik, bunu bir dizüstü bilgisayardan sunucuya Compose dosyası taşıyan herkes için varsayılan bir kontrol haline getiriyor.