Django çalışan bir sunucuda port ve erişim yollarını kontrol ederken üç soruyu ayrı tutuyorum: Servis hangi adreste dinliyor, seçtiğim ağ yolundan yanıt alınabiliyor mu, firewall hangi kuralları bildiriyor? Bu yazı bu kontrolleri yorumluyor. Birkaç komutla bütün sunucunun güvenli olduğunu söylemiyorum.
Eski yazımdaki “UFW devre dışıysa bütün portlar açıktır” ifadesi doğru değildi. inactive, yalnız UFW'nin etkin olmadığını gösterir. Dinleyen servis, ağ yönlendirmesi ve başka filtreler de erişimi etkiler.
Test edilen ortam
7 Ekim 2026'da macOS 27.0.1 / arm64 üzerinde Docker Engine 29.8.0 ve Compose 5.5.1 kullandım. HTTP kontrolü Debian GNU/Linux 13 (trixie) container'ında, Python 3.13.16, ss / iproute2 6.15.0 ve curl 8.14.1 ile çalıştı. HTTP yanıtını üreten küçük Python servisi sentetik bir örnek; bir üretim Django uygulaması değil.
UFW, systemd, SSH yapılandırması, gerçek sunucu ve farklı bir cihazdan erişim/engelleme testi çalıştırılmadı. Container ve host loopback testinden internet erişimi sonucu çıkarmıyorum. Aşağıdaki gerçek çıktılarda bu izole ortamın komutları var; üretim logu yok.
Örnek paketi indir ve access-scheduler-validation dizinini kullan. Docker çalışırken python lab.py init ve python lab.py up komutları yalnız bu örneği başlatır. README bütün adımları ve temizliği içerir.
1. Dinleyen soketi görmek
Başlatılan örnekte:
docker compose --env-file .env.local exec -T web ss -lntp '( sport = :18880 )'
İzole testte alınan gerçek çıktı:
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 5 0.0.0.0:18880 0.0.0.0:* users:(("python",pid=1,fd=3))
LISTEN, servisin bu ağ alanında bağlantı beklediğini gösteriyor. Buradaki 0.0.0.0, container'ın bütün IPv4 arayüzleri; host'un internetten erişilen bütün arayüzleri anlamına gelmiyor. ss belgesi dinleyen soket, adres ve süreç seçeneklerini açıklıyor. Aynı komut host üzerinde çalıştırılırsa host'un ağ alanını inceler; container sonucuyla karıştırmıyorum.
127.0.0.1:5432, yalnız o ağ alanının IPv4 loopback adresidir. 0.0.0.0:5432, bütün IPv4 arayüzlerinde dinlemeyi belirtir. IPv6'yı ayrıca kontrol etmek gerekir. Süreç adının görünmemesi de servisin yokluğu anlamına gelmez; kullanıcı yetkisi sonucu etkileyebilir.
2. Belirli bir erişim yolunu denemek
Container içinden HTTP yanıtını, ardından host port eşlemesini kontrol ettim:
docker compose --env-file .env.local exec -T web curl --fail --silent http://127.0.0.1:18880/
docker compose --env-file .env.local port web 18880
Gerçek çıktılar sırasıyla:
{"example":"local-access-check","ok":true}
127.0.0.1:18882
Host üzerinde http://127.0.0.1:18882/ isteği de HTTP 200 ve aynı gövdeyi verdi. İlk istek container loopback yolunu, ikinci kontrol yayımlanan host adresini, host isteği ise bu yerel eşleme üzerinden uygulama yanıtını doğruluyor. Bunlar uzak bir istemcinin ulaşabildiğini veya engellendiğini ölçmüyor. python lab.py verify bu kontrolleri tekrarlar ve tarihli JSON kanıtı üretir.
Compose dosyası 127.0.0.1:18882:18880 kullanıyor. Host IP'si belirtilmeyen eşlemeler varsayılan olarak bütün host arayüzlerine bağlanır. Docker ayrıca 28.0.0 öncesi sürümlerde loopback portlarına aynı L2 ağından erişim sınırını belirtir. Ayrıntılar Docker port yayımlama belgesinde var.
Tek sunuculu basit Django düzeninde Nginx web trafiğini kabul eder; Gunicorn'a Unix socket veya loopback üzerinden ulaşabilir. PostgreSQL ve Redis'in herkese açık porta ihtiyacı yoksa bu portları internete açmam. Birden fazla sunucu varsa gereken özel ağ yolunu ayrıca planlarım.
3. Firewall durumunu ayrı okumak
Ubuntu üzerinde salt okunur kontrol komutları:
sudo ufw status verbose
sudo ufw status numbered
Temsili çıktı; bu çalışmada UFW çalıştırılmadı:
Status: inactive
Bu satır “UFW etkin değil” demektir; “bütün portlara dışarıdan erişiliyor” demek değildir. active sonucu da tek başına belirli bir bağlantının engellendiğini kanıtlamaz. Kural listesini ve beklenen istemci yolundan bağlantı sonucunu ayrıca incelemek gerekir. Komutlar ve kural sözdizimi Ubuntu firewall belgesinde açıklanıyor.
ufw allow from 127.0.0.1 ... gibi bir izin eklemek, eski geniş bir izin kuralını kaldırmaz. Linux'ta Docker'ın yayımladığı trafik UFW kurallarından önce yönlenebilir. Bu nedenle ufw status çıktısını Docker portlarının güvenlik kanıtı saymam. Bu ilişki Docker firewall belgesinde açıklanıyor.
SSH erişimini korumak
SSH portu veya firewall kuralı değiştirilecekse mevcut oturumu kapatmadan yeni bağlantıyı denemek gerekir. İkinci bir erişim yolu hazır olmadan eski portu kapatmam. Port numarasını değiştirmek anahtarla girişin yerine geçmez. Ubuntu OpenSSH belgesi yapılandırma ve anahtar kullanımını ayrı ele alıyor. Bu yazının örnek paketi SSH veya firewall ayarı değiştirmiyor.
