Proxy kullanırken güvenlik: kimlik bilgileri, TLS ve DNS

Proxy kullanırken en büyük riskler, proxy parolasının komut geçmişine ve günlüklere sızması, düz HTTP trafiğin yol üzerinde okunması ve kaynağı belirsiz proxy’lerin trafiğe müdahale etmesidir. Bunların hepsi birkaç alışkanlıkla önlenebilir: kimlik bilgilerini koddan ve URL’lerden ayırın, her yerde HTTPS kullanın, DNS’in hangi yoldan gittiğini bilin ve yalnız güvendiğiniz sağlayıcıları kullanın.

Kimlik bilgileri: URL’ye yazmayın

Birçok araç proxy’yi http://KULLANICI:PAROLA@PROXY_ADRESI:PORT biçiminde kabul eder. Bu biçim kolaydır ama parolayı birçok yere bırakır: kabuk geçmişi, sistemdeki süreç listesi (komut satırı argümanları diğer kullanıcılara görünebilir), CI çıktıları, hata raporları ve URL’yi olduğu gibi yazan uygulama günlükleri. URI standardı da kullanıcı bilgisi alanında “kullanıcı:parola” biçiminin kullanımını önerilmeyen (deprecated) olarak tanımlar (RFC 3986 (yeni sekmede açılır), bölüm 3.2.1).

• Kimlik bilgilerini ortam değişkeninden ya da bir gizli bilgi kasasından okuyun; depoya, betiğe veya paylaşılan yapılandırma dosyasına yazmayın.
• Günlüğe proxy adresi yazdırmanız gerekiyorsa kullanıcı adını ve parolayı maskeleyin.
• Her proje, sunucu ya da ekip üyesi için ayrı kimlik bilgisi kullanın; biri sızarsa yalnız onu yenilersiniz.
• Parolayı düzenli aralıklarla ve ekipten biri ayrıldığında yenileyin.
• Mümkünse en az yetki ilkesini uygulayın: sabit sunuculardan bağlanıyorsanız IP beyaz liste, parolayı tamamen ortadan kaldırabilir. Ayrıntı: proxy kimlik doğrulama.

curl ile çalışırken bilgileri komut satırı yerine yalnız sizin okuyabildiğiniz bir yapılandırma dosyasına koyabilirsiniz (-K seçeneği, curl kılavuzu (yeni sekmede açılır)):

cat > proxy.conf <<'EOF'
proxy = "http://PROXY_ADRESI:PORT"
proxy-user = "KULLANICI:PAROLA"
EOF
chmod 600 proxy.conf

curl -K proxy.conf "https://api.ipify.org?format=json"

Python’da bilgileri ortam değişkeninden okuyun. Parolada @, : ya da / gibi karakterler varsa URL’ye koymadan önce kodlanmaları gerekir; aksi halde adres yanlış ayrıştırılır:

import os
from urllib.parse import quote

import requests

kullanici = quote(os.environ["PROXY_KULLANICI"], safe="")
parola = quote(os.environ["PROXY_PAROLA"], safe="")
proxy = f"http://{kullanici}:{parola}@PROXY_ADRESI:PORT"

yanit = requests.get(
    "https://api.ipify.org?format=json",
    proxies={"http": proxy, "https": proxy},
    timeout=15,
)
print(yanit.json())

Ortam değişkenlerine de dikkat edin: curl ve Python requests gibi birçok araç http_proxy ve https_proxy (çoğu araçta büyük harfli HTTPS_PROXY de) değişkenlerini kendiliğinden okur; curl http_proxy değişkenini yalnız küçük harfle tanır. Bu değişkenlere kimlik bilgisi içeren bir adres koyarsanız o oturumda çalışan her araç hem proxy’yi hem parolayı devralır; bazı araçlar ortam değişkenlerini hata ayıklama çıktısına da yazar. Değişkeni yalnız ihtiyaç duyan sürecin ortamında tanımlayın ve proxy’den geçmemesi gereken adresleri NO_PROXY ile hariç tutun.

TLS ile düz bağlantı arasındaki fark

HTTP ve SOCKS5 proxy protokolleri kendi başına şifreleme eklemez. Bunun iki sonucu vardır. Birincisi, düz HTTP kullanan bir siteye giden istek ve yanıt proxy’den ve yol üzerindeki her noktadan okunabilir. İkincisi, proxy’ye gönderdiğiniz kimlik bilgileri de korunmaz: HTTP Basic kimlik doğrulaması yalnız Base64 kodlamasıdır ve TLS olmadan güvenli değildir (RFC 7617); SOCKS5’in kullanıcı adı/parola yöntemi bilgileri açık metin gönderir (RFC 1929 (yeni sekmede açılır)).

Pratik sonuç: hedef sitelerde her zaman HTTPS kullanın ve proxy’yi güvenilmeyen bir ağdan kullanmanız gerekiyorsa proxy bağlantısının kendisinin de korunduğundan emin olun. Bunun için sağlayıcınıza TLS’li proxy bağlantısı sunup sunmadığını sorun ya da proxy’yi güvendiğiniz bir sunucudan kullanın.

Ücretsiz ve kaynağı belirsiz proxy’ler

İnternette dolaşan açık proxy listelerindeki sunucuların kimin tarafından ve neden çalıştırıldığını bilemezsiniz. Böyle bir proxy:

• düz HTTP sayfaları okuyabilir, değiştirebilir, sayfaya betik ya da reklam ekleyebilir;
• düz HTTP üzerinden giden çerezleri ve form verilerini kaydedebilir;
• HTTPS kullanmayan ilk isteği yakalayıp sizi HTTPS’e hiç yönlendirmeyebilir;
• hangi sitelere bağlandığınızı kaydedebilir;
• sizden kendi kök sertifikasını yüklemenizi isteyerek HTTPS trafiğinizi de çözmeye çalışabilir.

İlk isteğin şifresiz gitmesi riskini HSTS azaltır: site daha önceki bir HTTPS ziyaretinizde HSTS başlığı gönderdiyse (ve bu kaydın süresi dolmadıysa) ya da tarayıcıların ön yükleme listesindeyse tarayıcı doğrudan HTTPS kullanır (RFC 6797 (yeni sekmede açılır), MDN: Strict-Transport-Security (yeni sekmede açılır)). Yine de en iyi önlem, kaynağını bilmediğiniz proxy’yi hiç kullanmamaktır. Ücretli bir hizmet kullanırken de aynı ölçüt geçerlidir: sağlayıcının kim olduğunu, nasıl iletişim kurulacağını ve hizmet koşullarını önceden bilin; yalnız bir IP:port listesiyle gelen, sahibi belli olmayan hizmetlere kimlik bilgisi ya da iş trafiği emanet etmeyin.

Sertifika uyarıları ve sabitleme

Sertifika sabitleme (pinning) kullanan uygulamalar, TLS’i araya girerek çözen bir proxy ile bağlantı kurmayı reddeder; bu bir arıza değil, beklenen korumadır. Tarayıcılarda HTTP Public Key Pinning (HPKP, RFC 7469) desteği kaldırılmıştır; sabitleme bugün daha çok mobil uygulamalarda ve kendi yazdığınız istemcilerde kullanılır. Test amacıyla sabitlemeyi devre dışı bırakmanız gerekiyorsa bunu yalnız kendi test ortamınızda yapın, üretimdeki istemcide asla.

DNS ve diğer sızıntılar

Proxy ayarlı bir uygulama bile adları yerel DNS sunucusunda çözerse ziyaret ettiğiniz alan adları yerel ağda ve ISS’nizde görünür. SOCKS5 kullanırken adın proxy tarafında çözülmesini seçin (curl ve benzeri araçlarda socks5h://); bazı tarayıcıların SOCKS ayarında da DNS’i proxy üzerinden çözme seçeneği bulunur. HTTP proxy’de istemci adı zaten isteğin içinde proxy’ye iletir.

Tarayıcılarda WebRTC, yapılandırmaya bağlı olarak proxy dışındaki bir yoldan bağlantı adayları toplayabilir ve bu, sitelerin gerçek IP adresinizi görmesine yol açabilir. Proxy’yi kurduktan sonra çıkış adresinizi IP Sorgulama, proxy’nin kendisini Proxy Kontrol aracıyla doğrulayın. Konunun ayrıntısı DNS sızıntısı nedir yazısındadır.

Kayıtlar: kim ne tutuyor?

Proxy’yi işleten taraf, protokolün açık bıraktığı bilgileri (bağlantı zamanları, hedef adlar, trafik hacmi) teknik olarak kaydedebilir. Sağlayıcınızın hangi kayıtları ne kadar tuttuğunu gizlilik metninden okuyun; yazılı olmayan bir vaadi varsaymayın. Kendi tarafınızda da aynı özen geçerlidir: uygulama günlüklerinizde proxy kimlik bilgileri, oturum çerezleri ya da kişisel veriler açık durmasın, günlüklerin saklama süresini sınırlayın.

Sorumlu kullanım

Güvenlik yalnız sizi korumak değil, başkalarına zarar vermemektir. Proxy’yi hedef sitenin kullanım koşullarına ve mevzuata uygun işler için kullanın; istek hızınızı sınırlayın, kimlik bilgilerinizi başkalarıyla paylaşmayın ve proxy’nizin başkalarının erişimine açık kalmadığından emin olun. İlkeler güvenlik ve sorumlu kullanım sayfasında yer alır.

Kendi proxy sunucunuzu işletiyorsanız onu kimlik doğrulamasız ve herkese açık bırakmayın. Açık bir proxy kısa sürede başkalarının trafiğini taşımaya başlayabilir ve o trafik sizin adresinizden çıkar. Kimlik doğrulamayı zorunlu tutun, yalnız gereken portlara izin verin ve sunucunun hangi ağlardan erişilebildiğini güvenlik duvarıyla sınırlayın.

Özet: kontrol listesi

1. Kimlik bilgilerini URL’lere, betiklere ve depolara yazmayın; ortam değişkeni ya da izinleri kısıtlı bir dosya kullanın.
2. Her iş için ayrı kimlik bilgisi kullanın ve düzenli yenileyin; uygunsa IP beyaz listeye geçin.
3. Hedef sitelerde her zaman HTTPS kullanın; güvenilmeyen ağlarda proxy bağlantısının da korunduğundan emin olun.
4. Kaynağı belirsiz ücretsiz proxy kullanmayın, hiçbir proxy için kök sertifika yüklemeyin, sertifika uyarılarını geçmeyin.
5. SOCKS5’te adları proxy tarafında çözün ve çıkış adresinizi kurulumdan sonra doğrulayın.
6. Kendi günlüklerinizde gizli bilgileri maskeleyin ve proxy’yi kurallara uygun işlerde kullanın.