Origin IP Gizleme ve Origin Lock: Sızıntı Yolları ve Çözüm

Origin IP sızıntısı neden bu kadar kritik?

Ters proxy kullandığınızda ziyaretçiler sunucunuza değil proxy'ye bağlanır. WAF, DDoS azaltma ve bot doğrulaması bu bağlantı yolunda çalışır. Saldırgan gerçek sunucu adresini (origin IP) öğrenirse yolu tamamen atlar ve korumasız sunucuya doğrudan istek gönderir.

Bu yüzden origin IP'si, ters proxy kurulumunun en zayıf halkasıdır. Ters proxy nedir rehberinde trafiğin nasıl aktığını görebilirsiniz. Bu yazıda sızıntı yollarını, "sadece gizlemek" yaklaşımının neden yetmediğini ve kalıcı çözümü anlatıyoruz.

Origin IP hangi yollarla sızar?

Saldırganlar adresi çoğu zaman karmaşık bir saldırıyla değil, herkese açık kayıtlara bakarak bulur. En sık görülen yollar şunlardır.

• Eski DNS kayıtları. Proxy'ye geçmeden önce alan adınız doğrudan sunucuya işaret ediyordu. Geçmiş DNS kayıtlarını arşivleyen servisler bu A kaydını saklar.
• Unutulmuş alt alan adları. mail., ftp., direct., cpanel., dev. gibi alt alanlar proxy üzerinden geçmiyorsa doğrudan origin IP'sini gösterir.
• MX ve SPF kayıtları. Posta sunucusu web sunucusuyla aynı makinedeyse MX kaydı veya SPF içindeki ip4: girdisi adresi açık eder.
• Giden e-posta başlıkları. Sunucunuzdan gönderilen bir e-postanın Received başlığı gönderen IP'yi taşır. Parola sıfırlama veya bildirim e-postaları yeterlidir.
• Sertifika şeffaflık günlükleri. Her sertifika, ilgili alan adlarıyla birlikte herkese açık günlüklere yazılır. Bu günlükler RFC 9162 ile tanımlıdır. Günlükte staging.example.com gibi unutulmuş bir ad görünür ve bu ad doğrudan sunucuya çözülebilir.
• Unutulmuş test ortamları. Proxy arkasına alınmamış staging veya test sunucuları aynı IP aralığında çalışır.
• İnternet çapında tarama verileri. Tüm IPv4 uzayını tarayan servisler, 443 portunda sizin sertifikanızı sunan IP'leri indeksler. Sertifikadaki alan adından origin'e ulaşılır.

Ayrıca uygulama düzeyinde sızıntılar da vardır: hata sayfaları, phpinfo() çıktıları, sunucu adı veya iç IP yazan yanıt başlıkları.

Neden yalnızca gizlemek yetmez?

Yukarıdaki listenin tamamını temizlemeniz mümkün olsa bile geçmiş kayıtlar kalıcıdır. Arşivlenmiş DNS kayıtlarını ve günlüğe yazılmış sertifikaları siz silemezsiniz. Bir kez sızan adres, kapatılmadığı sürece kalıcı olarak tehlikededir.

Gizleme, "adres bilinmiyor" varsayımına dayanır. Kalıcı çözüm, adresi bilinse bile işe yaramaz hâle getirmektir: origin yalnızca proxy'den gelen isteği kabul etmelidir. Bunu üç yöntemle sağlarsınız.

Çözüm 1: Güvenlik duvarında proxy IP izin listesi

Origin'in 80 ve 443 portlarını yalnızca proxy'nin IP adreslerine açın, geri kalan her kaynaktan gelen bağlantıyı düşürün. Bu yöntem L3/L4'te çalışır: saldırganın paketi HTTP katmanına ulaşmadan elenir. SYN seli gibi saldırılar da bu sayede sunucuda iş yükü oluşturmaz.

UFW ile örnek (IP'ler örnektir, kendi proxy sağlayıcınızın adreslerini kullanın):

sudo ufw allow from 203.0.113.10 to any port 80,443 proto tcp
sudo ufw allow from 203.0.113.11 to any port 80,443 proto tcp
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

Kural sırasına dikkat edin: izin kuralları önce eklenmeli. SSH portunu kapatmadığınızdan emin olun; aksi halde kendi erişiminizi kesersiniz.

Çözüm 2: Gizli başlık denetimi

Proxy her isteğe, yalnızca sizin ve proxy'nin bildiği gizli bir başlık ekler. Web sunucusu bu başlık yoksa veya değer yanlışsa isteği reddeder. Adresi bilen saldırgan başlığı bilmediği için 403 alır.

nginx başlık adlarını küçük harfe çevirir ve tireleri alt çizgiye dönüştürür, yani X-NexrenShield-Key-abc123 başlığına $http_x_nexrenshield_key_abc123 değişkeniyle erişirsiniz. Aşağıdaki başlık adı ve değer yer tutucudur; kendi sitenizde proxy'nin eklediği adı ve değeri kullanın.

server {
    listen 443 ssl;
    server_name example.com;

    if ($http_x_nexrenshield_key_abc123 != "SECRET") {
        return 403;
    }
    # ...
}

Dikkat edilecek noktalar:

• Değeri düz metin olarak depoya koymayın, ortam değişkeninden veya ayrı bir dosyadan okuyun.
• Başlığı yanıtlarda geri döndürmeyin ve erişim günlüklerine yazmayın.
• Başlık sızarsa değeri döndürün (rotate).
• Bu denetim L7'dir: bağlantı açılır, TLS el sıkışması olur, sonra istek reddedilir. Hacimsel saldırıları durdurmaz.

Çözüm 3: Doğrulanmış origin çekimi (authenticated origin pulls)

Daha güçlü bir yöntem karşılıklı TLS'tir (mTLS). Proxy origin'e bağlanırken bir istemci sertifikası sunar ve origin yalnızca bu sertifikayı kabul eder. Başlık sızabilir, istemci sertifikasının özel anahtarını ise çalmak çok daha zordur. Her proxy sağlayıcısı bunu sunmaz ve kurulum sertifika yönetimi gerektirir. Bu yüzden çoğu ekip önce izin listesi ve başlık denetimiyle başlar.

Sızıntıdan sonra ne yapmalısınız?

Adresin sızdığından şüpheleniyorsanız sırayla ilerleyin:

1. Sızıntı kaynağını bulup kapatın: eski A kaydını, açık alt alanı, MX girdisini.
2. Güvenlik duvarı izin listesini ve gizli başlık denetimini açın.
3. Mümkünse origin IP'sini değiştirin. Sağlayıcınızdan yeni bir adres alın ve eskisini serbest bırakın.
4. Posta için ayrı bir sunucu veya ayrı bir gönderim servisi kullanın, böylece e-posta başlıkları web sunucusunu göstermez.
5. Gizli başlık değerini yenileyin.

IP'yi değiştirmek tek başına sorunu çözmez: kaynak açık kaldıysa yeni adres de aynı yoldan sızar. Sıra önemlidir; önce kapatın, sonra değiştirin.

sudo bash protect-origin.sh --dry-run          # kuralları uygulamadan önizleyin
sudo bash protect-origin.sh --ssh-port 2222    # standart dışı SSH portunuzu belirtin
sudo bash protect-origin.sh --revert           # izolasyonu kaldırıp portları açın

Kontrol listesi

Son olarak kontrol edin: curl -I https://203.0.113.50 -H "Host: example.com" --insecure komutu kendi origin IP'nizle 403 veya bağlantı zaman aşımı vermelidir. 200 dönüyorsa origin hâlâ açıktır.

Kaynaklar

• RFC 9162: Certificate Transparency Version 2.0
• nginx: ngx_http_core_module, gömülü değişkenler

İlgili ürün sayfaları:Yardım merkezi Teknoloji