Reverse Proxy Arkasındaki Sunucular Gerçekten Güvende mi? Cloudflare, Nginx ve Origin IP Sızıntıları

Birçok sistem yöneticisi Cloudflare veya başka bir reverse proxy servisini aktif ettikten sonra origin sunucunun tamamen gizlendiğini düşünür. Gerçekte ise yanlış yapılandırılmış bir sistemde origin IP adresi dakikalar içinde tespit edilebilir.

Bu yazıda reverse proxy mimarisinin nasıl çalıştığını, origin IP sızıntılarının nasıl oluştuğunu ve production ortamlarında bu riskin nasıl azaltılması gerektiğini detaylı şekilde inceleyeceğiz.

---

Reverse Proxy Mantığı Nasıl Çalışır?

Normal senaryoda istemci doğrudan origin sunucuya bağlanır:

Client -> Origin Server

Cloudflare gibi bir reverse proxy kullanıldığında trafik şu hale gelir:

Client -> Cloudflare Proxy -> Origin Server

Bu yapı sayesinde:

• Origin IP gizlenir
• DDoS koruması sağlanır
• Cache performansı artar
• WAF filtreleri uygulanır

Ancak bu mimarinin güvenli olması için origin sunucunun doğrudan erişime kapatılması gerekir.

---

En Büyük Hata: Origin Sunucunun Açık Kalması

Birçok kişi Cloudflare proxy aktif olduktan sonra sunucunun güvenli olduğunu varsayar fakat firewall yapılandırması değiştirilmez.

Sonuç:

Internet -> Origin Server (hala erişilebilir)

Bu durumda saldırgan:

• Gerçek IP adresini bulabilir
• Cloudflare bypass yapabilir
• Rate limit kurallarını atlatabilir
• Doğrudan Layer 7 saldırısı gerçekleştirebilir

Aslında Cloudflare yalnızca bir katmandır. Origin erişimi kapatılmazsa koruma büyük ölçüde etkisiz hale gelir.

---

Origin IP Nasıl Bulunur?

Production ortamlarında en sık görülen sızıntılar şunlardır:

1. DNS Geçmişi

Eski A kayıtları hala internette bulunabilir.

Özellikle:

• SecurityTrails
• Shodan
• Censys

gibi servisler eski IP kayıtlarını tutar.

Alan adı daha önce proxy olmadan kullanıldıysa gerçek IP kolayca ortaya çıkabilir.

---

2. Mail Sunucuları

En büyük sızıntı kaynaklarından biri mail altyapısıdır.

Örnek:

mail.domain.com -> doğrudan origin IP

Saldırganlar MX kayıtlarını analiz ederek gerçek IP adresine ulaşabilir.

Özellikle aynı sunucuda:

• Web servisleri
• SMTP servisleri
• Panel servisleri

çalışıyorsa risk büyür.

---

3. Outbound Trafik

Origin sunucu dış dünyaya doğrudan bağlantı kuruyorsa IP sızıntısı oluşabilir.

Örneğin:

• Webhook servisleri
• SMTP gönderimleri
• API callback sistemleri

gerçek IP adresini expose edebilir.

---

4. Yanlış Nginx Yapılandırmaları

Bazı sistemlerde aşağıdaki gibi proxy bypass oluşur:

listen 80 default_server;

veya:

server_name _;

Bu tarz generic virtual host yapılandırmaları origin erişimini açık bırakabilir.

---

Gerçek Güvenlik Nasıl Sağlanır?

En kritik nokta:

Origin Sunucu Sadece Proxy IP'lerine Açık Olmalı

Örneğin yalnızca Cloudflare IP bloklarına izin verilmelidir.

UFW örneği:

ufw default deny incoming

ufw allow from 173.245.48.0/20 to any port 443
ufw allow from 103.21.244.0/22 to any port 443

Bu yapı sayesinde internetten doğrudan erişim engellenir.

---

Gerçek IP Yönetimi

Nginx varsayılan olarak istemci IP adresi yerine proxy IP adresini görür.

Doğru yapılandırma:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

Bu olmadan:

• Fail2Ban yanlış çalışır
• Rate limiting bozulur
• Log analizi anlamsız hale gelir

---

Rate Limiting Neden Tek Başına Yetmez?

Birçok kişi rate limiting'i “DDoS koruması” olarak görüyor.

Gerçekte:

• Distributed saldırılar
• Residential proxy ağları
• ASN dağıtımlı botnetler

IP bazlı limitlemeyi aşabilir.

Bu yüzden modern koruma yaklaşımı:

• Behavioral analysis
• JA3 fingerprinting
• Bot scoring
• Request entropy analizi

gibi yöntemlerle desteklenmelidir.

---

Production Ortamlarında Gerçek Problem: False Positive

En zor konu saldırıları engellemek değil, gerçek kullanıcıyı yanlışlıkla engellememektir.

Özellikle:

• Mobil operatör NAT ağları
• Kurumsal proxy sistemleri
• Carrier-grade NAT yapıları

aynı IP üzerinden binlerce kullanıcı çıkarabilir.

Aşırı agresif limitler:

• Login problemleri
• API timeout
• Session kayıpları

oluşturabilir.

---

WAF Sistemlerinin Gerçek Hayattaki Problemi

Birçok kişi ModSecurity kurup OWASP ruleseti yükledikten sonra sistemi koruduğunu düşünüyor.

Gerçekte production ortamında:

• False positive tuning
• Endpoint bazlı exception
• Rule exclusion
• Score threshold optimizasyonu

olmadan WAF kullanımı ciddi problem yaratabilir.

Özellikle API sistemlerinde default OWASP kuralları yoğun şekilde false positive üretir.

---

Monitoring Olmadan Güvenlik Olmaz

En büyük hatalardan biri yalnızca engelleme odaklı düşünmektir.

İzlenmeyen sistem güvenli değildir.

Takip edilmesi gereken temel metrikler:

• 403 oranları
• 429 yoğunluğu
• ASN dağılımı
• Bot entropy
• Request spike analizi
• Upstream saturation
• TCP connection yoğunluğu

Gerçek saldırılar genellikle loglarda küçük anomalilerle başlar.

---

Sonuç

Reverse proxy kullanmak tek başına güvenlik sağlamaz.

Gerçek güvenlik için:

• Origin izolasyonu
• Firewall katmanı
• Gerçek IP doğrulaması
• Akıllı rate limiting
• Log korelasyonu
• WAF tuning
• Sürekli monitoring

birlikte çalışmalıdır.

Production ortamlarında güvenlik “tek ürün” değil, birbirini tamamlayan katmanlardan oluşan bir mimaridir.