Delete HTTP Header

Delete HTTP Header Aksiyonu Nedir?

Delete HTTP Header aksiyonu, HTTP trafiğinden belirli bir başlığı (header) kaldırmak için kullanılır. Silinen başlık, istek veya yanıt trafiğinden çıkarılarak Kurum Servislerine veya istemcilere iletilmez.

Bu aksiyon hem istek (request) hem de yanıt (response) aşamasında çalışabilir. Execution Level seçimine göre başlık, Kurum Servisine gönderilmeden önce istekten veya istemciye döndürülmeden önce yanıttan kaldırılır.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024

− Server: Apache/2.4.41 (Ubuntu)

Silinen Başlık

Delete HTTP Header Aksiyonunun Önemi

HTTP başlıklarının kontrolü, güvenlik ve gizlilik açısından kritik öneme sahiptir. Gereksiz veya hassas başlıkların kaldırılması, saldırı yüzeyini daraltır ve bilgi sızıntısını önler.

Delete HTTP Header aksiyonu;

• Sunucu parmak izi bilgilerinin (Server, X-Powered-By vb.) gizlenmesini sağlar,
• Hassas dahili başlıkların dış dünyaya sızmasını engeller,
• İstemciden gelen güvenilmeyen başlıkların Kurum Servisine iletilmesini önler,
• Gereksiz başlıkların kaldırılmasıyla bant genişliği tasarrufu sağlar,
• Uygulama güvenlik politikalarının uygulanmasını mümkün kılar.

Bu nedenle Delete HTTP Header aksiyonu, güvenlik odaklı trafik yönetiminin temel bileşenlerinden biridir.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Nasıl Eklenir?

Yeni bir Delete HTTP Header Aksiyonu, TR7 web yönetim arayüzü üzerinden aşağıdaki adımlar izlenerek eklenebilir:

1. Sol altta bulunan TR7 logosuna tıklanarak Configuration Menu açılır.
2. Load Balancer → Actions → Add adımları takip edilir.
3. Aksiyon için benzersiz ve açıklayıcı bir isim girilir.
4. Action Type olarak Delete HTTP Header seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Conditions sekmesinden aksiyonun hangi koşul/koşullarda devreye gireceği belirlenir.
7. Add butonuna tıklanarak aksiyon eklenir.

Delete HTTP Header Aksiyonu Ekleme Formu

Delete HTTP Header Aksiyonu Ekleme Formu

INFO

Action Name

Oluşturulacak olan aksiyona benzersiz ve açıklayıcı bir isim girilir.

INFO

Action Type

Aksiyon tipi olarak Delete HTTP Header seçilir.

INFO

Execution Level

Aksiyonun hangi aşamada çalıştırılacağını belirler.

• On Request: Aksiyon, istek ilgili Kurum Servisine iletilmeden önce uygulanır. Bu seviye, istek üzerinde değişiklik yapılması veya Kurum Servisine ek bilgi iletilmesi gereken durumlarda kullanılır.
• On Response: Aksiyon, yanıt istemciye iletilmeden önce uygulanır. Bu seviye, istemciye gönderilen yanıt üzerinde düzenleme veya ekleme yapılması gereken durumlarda kullanılır.

INFO

Hit Counter Varsayılan: Kapalı

Hit Counter, aksiyonun her çalışmasını sayar (aksiyonun kendi koşuluyla birlikte değerlendirilir; Deny gibi sonlandırıcı aksiyonlarda bile sayım kaybolmaz). Aksiyon bazlı hız ve toplamlar, vService panosundaki Action Hits sekmesinde ve canlı istatistik ekranında görüntülenir; listelerde ayrıca bir kolon olarak görünmez. Sayaç kümülatiftir; elle sıfırlama arayüzü yoktur: sayılan aksiyon kümesi değiştiğinde veya vService yeniden yüklendiğinde sıfırdan başlar, geçmiş ise panoda hız (hit/s) olarak korunur.

INFO

Set Variable on Hit

Aksiyon her çalıştığında değeri atanacak bir değişken adı girilebilir (isteğe bağlı; varsayılan boş). Ad; harf, rakam ve alt çizgiden oluşabilir (en fazla 32 karakter). Aksiyon tetiklendiğinde değişken 1 değerine atanır ve aynı vService'teki diğer koşul ve aksiyonlarda %TR7VAR(ad) akıllı değişkeniyle okunarak zincirleme davranışlar kurulabilir.

INFO

Header to Delete Zorunlu

Silinecek HTTP başlığının adı bu alana girilir.

Alan yazılırken TR7, yaygın başlık adlarını otomatik tamamlama olarak önerir; öneri listesi seçili Execution Level'a (istek/yanıt) göre değişir. Listede olmayan başlık adları elle yazılabilir.

WARNING

Başlık adı birebir eşleşir: X-* gibi joker ifadeler ve düzenli ifade (regex) desteklenmez: desene göre işlem gerekiyorsa Replace HTTP Header Content aksiyonu kullanılır. Eşleşme büyük/küçük harfe duyarsızdır ve aynı ada sahip tüm başlık tekrarları silinir.

Protokol-kritik başlıkları silmeyin

TR7 hiçbir başlığı korumaz; öneri listesinde protokol açısından kritik başlıklar da yer alır. Host, Content-Length, Transfer-Encoding, Connection, Content-Type, Location, Set-Cookie, WWW-Authenticate gibi başlıkların silinmesi servis kesintisine, bozuk yanıtlara veya oturum kaybına yol açar.

Başlık adları büyük/küçük harf duyarsızdır. Örneğin Server veya server aynı başlığı hedefler.

TIP

Sıkça silinen başlıklar

Yanıttan silinmesi önerilen başlıklar:

• Server: Web sunucu bilgisi
• X-Powered-By: Uygulama framework bilgisi
• X-AspNet-Version: ASP.NET versiyon bilgisi
• X-AspNetMvc-Version: ASP.NET MVC versiyon bilgisi

İstekten silinmesi düşünülebilecek başlıklar:

• X-Forwarded-For: Spoofing riski taşıyan proxy başlığı
• X-Custom-Debug: Debug amaçlı özel başlıklar

INFO

Conditions

Bu alanda, ilgili aksiyonun hangi koşul veya koşullar sağlandığında devreye gireceği tanımlanır.

Bir veya birden fazla koşul eklenerek, and/or yapısı ile davranışın hedefli ve kontrollü şekilde uygulanması sağlanabilir.

Koşullar hakkında detaylı bilgi Conditions sayfasında yer alır.

WARNING

Bu alanda herhangi bir koşul tanımlanmazsa, ilgili aksiyon koşulsuz (Always) olarak çalışır. Bu durumda aksiyon, ilgili vService'e gelen tüm trafiğe uygulanır.

Canlı ortamlarda, koşul tanımlanmadan aksiyon kullanılması beklenmeyen durumlara (servis kesintilerine) yol açabilir. Bu nedenle aksiyon oluşturulurken mutlaka en az bir koşul tanımlanması önerilir.

INFO

Form Butonları

Add

Add butonuna tıklanarak aksiyon ekleme işlemi tamamlanır.

Add & Repeat

Add & Repeat butonu ile aksiyon ekleme işlemi tamamlanır ve farklı konfigürasyonlarla ilgili pencereden çıkılmadan yeni bir aksiyon daha eklenebilir.

Aksiyon Eklendi

Operasyonel ve Güvenli Kullanım Önerileri

• Sunucu parmak izleri kaldırılır. Saldırganların hedefli saldırı yapmasını zorlaştırmak için Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version başlıkları yanıttan kaldırılır. Alternatif: birden fazla güvenlik başlığının tek seferde yönetilmesi için Manage HTTP Security Headers aksiyonundaki "Remove Server Fingerprints" seçeneği kullanılır.
• Spoofing riskli başlıklar temizlenir. İstemcilerden gelen X-Forwarded-For gibi başlıklar spoofing riski taşır; bu başlıklar istekten silinir ve TR7'nin kendi eklediği güvenilir değerler kullanılır.
• Dahili başlıklar sızdırılmaz. Kurum Servisleri arasında kullanılan dahili başlıklar (örn. X-Internal-User-ID, X-Debug-Info) yanıttan kaldırılmalıdır.
• Birden fazla başlık için ayrı aksiyonlar oluşturulur. Silinecek her başlık için ayrı bir aksiyon tanımlanması gerekir; aynı koşulları paylaşan aksiyonlar aynı vService'e eklenir.

Canlı Ortamlarda Yaygın Kullanım Senaryoları

Aşağıdaki örnekler, ilgili aksiyonun gerçek sistemlerde en sık karşılaşılan kullanım senaryolarında nasıl uygulandığını göstermektedir. Bu senaryolar, canlı ortamlarda yaygın olarak tercih edilen ve sahada edinilmiş deneyimlere dayanan pratikleri temel alır.

Senaryo 1: API Endpoint'lerinde Sunucu Bilgilerini Gizleme

Problem: API endpoint'lerinde (/api/ path'i) Kurum Servisi yanıtlarında Server: Apache/2.4.41 (Ubuntu) başlığı görünüyor. API'yi kullanan üçüncü parti geliştiriciler ve potansiyel saldırganlar sunucu versiyonunu öğrenerek hedefli saldırı hazırlayabiliyor.

Çözüm: Sadece API endpoint'lerinde Server başlığını silerek sunucu bilgilerini gizleyin.

Konfigürasyon:

• Execution Level: On Response
• Header to Delete: Server
• Conditions: Path STARTS WITH /api/

Sonuç:

• ✅ /api/ path'indeki yanıtlar → Server başlığı kaldırılır, sunucu türü gizlenir.
• ✅ Güvenlik → API üzerinden sunucu versiyonu öğrenilemez, hedefli exploit zorlaşır.
• ❌ Diğer path'ler (örn: /web/, /) → Server başlığı korunur (isteğe bağlı).

Senaryo 2: Hata Sayfalarında Framework Bilgilerini Gizleme

Problem: 4xx ve 5xx hata sayfalarında X-Powered-By: ASP.NET ve X-AspNet-Version: 4.0.30319 başlıkları görünüyor. Özellikle hata durumlarında framework bilgileri saldırganlara önemli ipuçları veriyor ve stack trace analizi için kullanılıyor.

Çözüm: Sadece hata yanıtlarında (status code >= 400) framework başlıklarını silerek teknoloji stack'i gizleyin.

Konfigürasyon:

• Execution Level: On Response
• Header to Delete: X-Powered-By
• Conditions: Status Code >= 400

Sonuç:

• ✅ 4xx ve 5xx hata yanıtları → X-Powered-By başlığı kaldırılır.
• ✅ Güvenlik → Hata sayfalarında framework versiyonu sızmaz, saldırganlar bilgi toplayamaz.
• ❌ 2xx ve 3xx başarılı yanıtlar → X-Powered-By korunur (isteğe bağlı).

Başlığın tüm yanıtlarda kaldırılması için Conditions boş bırakılır; X-AspNet-Version için ayrı bir aksiyon da oluşturulabilir.

Senaryo 3: İstemci IP Spoofing Önleme

Problem: İstemciler X-Forwarded-For başlığını kendileri ekleyerek farklı bir IP adresinden geliyormuş gibi görünebiliyor. Kurum Servisi bu başlığa güvenerek yanlış IP'yi loglara yazıyor ve IP bazlı güvenlik kuralları atlatılabiliyor.

Çözüm: İstemciden gelen güvenilmeyen X-Forwarded-For başlığı silinir ve TR7'nin eklediği güvenilir değer kullanılır.

Konfigürasyon:

• Execution Level: On Request
• Header to Delete: X-Forwarded-For
• Conditions: Koşulsuz (tüm isteklere uygulanır)

Sonuç:

• ✅ İstemciden gelen istekler → Sahte X-Forwarded-For başlığı kaldırılır.
• ✅ TR7 → Gerçek istemci IP'sini güvenilir şekilde ekler. (Aksiyon ile XFF eklemek için Add HTTP Header aksiyonu; vService içerisinde XFF eklemek için ilgili HTTP vService ayarı kullanılabilir.)
• ✅ Kurum Servisi → Doğru IP adresini alır, spoofing engellenir.
• ❌ IP bazlı güvenlik kuralları → Artık atlatılamaz.

Senaryo 4: Internal Debug Başlıklarını Temizleme

Problem: Development ortamında kullanılan X-Debug-Token, X-Internal-User-ID gibi debug başlıkları production ortamında da yanıtlara ekleniyor. Bu başlıklar hassas bilgi içeriyor ve güvenlik riski oluşturuyor.

Çözüm: Production ortamında debug başlıkları yanıtlardan silinerek bilgi sızıntısı önlenir.

Konfigürasyon:

• Execution Level: On Response
• Header to Delete: X-Debug-Token
• Conditions: Koşulsuz (production ortamında tüm yanıtlara uygulanır)

Sonuç:

• ✅ Production yanıtları → X-Debug-Token başlığı kaldırılır.
• ✅ Hassas bilgi → Internal user ID, debug token sızmaz.
• ✅ Güvenlik → Development bilgileri production'da görünmez.

X-Internal-User-ID, X-Backend-Server gibi diğer internal başlıklar için de ayrı aksiyonlar eklenebilir.