Güncelleme Şubat 2024: Bu makalenin içeriğinin çoğu şimdi yazdığım bu geğirme eklentisiyle elde edilebilir: https://github.com/honoki/burp-digiitalocean-droplet-openvpn-bir spin verdiğinizden emin olun!
Güvenlik testleri yaparken, genellikle tüm trafiğinizi bir VPN üzerinden göndermeniz istenir. Tüm yerel trafiğinizi aynı VPN üzerinden göndermek istemiyorsanız, kullanımı kolay bir kurulum yapılandırma bazen bir ağrı olabilir. Bu yazı, VPN’yi kendi makinenizde çalıştırmak zorunda kalmadan, tüm trafiğini uzak bir VPN aracılığıyla göndermek için geğirme paketini yapılandırmanın olası bir yolunu özetlemektedir.
Bu kılavuzda, aşağıdaki araçları kullanan bir kurulumu açıklayacağım. Bununla birlikte, bunların çoğunun aynı hedeflere ulaşmak için benzer araçlarla değiştirilebileceğini unutmayın.
- Geğirme süiti
- Macun
- OpenVPN Sanal Özel Sunucuda Çalışıyor (VPS)
- Jumphost olarak ikinci bir VPS (statik bir IP’niz varsa gerekli değildir)
- Tarayıcı uzantısı chrome veya firefox’ta switchy omega
Neden?
Güvenlik testlerinizi yürütmek için bir VPN yapılandırmanın iyi bir fikir olabilmesinin birkaç nedeni vardır:
- Kamuya açık olmayan varlıkların test edilmesi, örneğin dahili bir ağda bulunur; Bu genellikle iç altyapı testleri veya UAT ortamlarına karşı testler yaparken geçerlidir;
- Kamu varlıklarının beyaz liste bir ortamdan test edilmesi, örneğin, genellikle bir WAF’ın arkasına gizlenmiş web uygulamaları, internet tarafından erişilebilen, ancak yalnızca bir dizi beyaz listeye alınmış ağ, vb.
- Programa katılmak için VPN’lerinin bir koşul olarak kullanılmasını gerektiren hata ödül programları.
Bu ihtiyacı karşılamak için, yerel test makinenize bir OpenVPN istemcisi yüklemeye ve devam etmeye meyilli olabilirsiniz. Bu kesinlikle işe yarasa da, test faaliyetlerimi diğer ağ etkinliğinden ayırmanın sadece gizlilik bilincine sahip bir karar olmadığını, aynı zamanda VPN bant genişliğini mümkün olduğunca serbest bırakmaya da yardımcı olduğunu buldum, çünkü artık artık gereksiz trafikle işgal edilmiyor.
Kurulum
Mimari olarak, tarif edeceğim çözüm şuna benziyor:
VPN Tüneli
VPN tüneli elbette bu kurulumun çekirdeğidir ve (seçilen) trafiğinizi bir hedefin ortamındaki varlıklara veya internete erişilebilir varlıklara doğru tünel yapmanıza izin verecektir, ancak kökenli Hedefin ağı. Başka bir deyişle, test ettiğiniz web uygulamaları, kendinizden ziyade Target X’in IP adres aralığından geldiğinizi görecektir.
Jump host
Ev veya ofis ağınızda statik bir IP’niz varsa veya bu geçici bir kurulum olarak tasarlanmışsa (yani geçerli IP’niz yapacak), bunu atlayabilirsiniz.
Aksi takdirde, bu atlama ana bilgisayar VPN bağlantılı EC2 örneğinize doğru bir köprü görevi görür. En önemlisi, VPS’nin statik IP’si, VPN üzerinden gönderilmekten kaçınmak için trafiği bu atlama ana bilgisayarı yapılandırmamıza izin verecektir.
Bu atlama ana bilgisayarında, EC2 örneğinin özel anahtarına (varsa) eriştiğinizden emin olun ve aşağıdaki komutu kullanarak bir çorap proxy ayarlayın:
ssh -i ~/ssh-private-key.pem -D 2222 [email protected]
Bu, atlama ana bilgisayarındaki 2222 numaralı bağlantı noktasından vekili tüm trafiği, AWS EC2 örneği aracılığıyla orijinal hedefe doğru yönlendirecek bir SSH tüneli oluşturacaktır (yani VPN etkinleştirildiğinde VPN aracılığıyla).
AWS EC2 Örneği
Ucuz olduğu için, VPN ile bağlantıyı kurmak için AWS EC2’de bir T2.Micro örneği seçtim. Ben Debian hayranıyım, bu yüzden bir Ubuntu 18.04 görüntüsü attım. Çalıştığında ve çalıştırıldıktan sonra, aşağıdaki yapılandırılmış olana ihtiyacınız olacaktır:
- OpenVPN’yi yükleyin;
- Bağlamak istediğiniz VPN’nin yapılandırmasını içeren OVPN dosyasını yükleyin;
- Trafiği olağan ağ geçidi (kaynak) yoluyla yönlendirerek atlama ana bilgisayarınızı (veya ev/ofis ipini) VPN’den beyaz liste;
- Gerekirse herhangi bir yerel DNS sunucusunu beyaz liste;
# install OpenVPN client
sudo apt install openvpn
# find out and write down your local gateway's IP address
netstat -anr
# find out and write down your local DNS servers' IP addresses
# (I needed this to allow DNS resolution in AWS EC2 when the VPN is running)
systemd-resolve --status
# Make sure both IPs you wrote down are not redirected through the VPN:
sudo route add -host gw
sudo route add -host gw
# Start the VPN!
sudo openvpn --config ./openvpn-config.ovpn --daemon Yerel Yapılandırma
Bunu işe almak için son adımlar:
- Jump ana bilgisayarınızdaki SOCKS proxy’sine yerel bağlantı noktası yönlendirmesini ayarlayın;
- Burp paketini, yönlendirilen yerel bağlantı noktasını çorap proxy olarak kullanacak şekilde yapılandırın;
- VPN üzerinden yalnızca seçilen siteleri göndermek için ProxySwitch tarayıcı uzantısını kullanın.
Windows’ta, Putty’yi kullanarak, yerel bağlantı noktası 31337’yi 2222 bağlantı noktasındaki atlama ana bilgisayarınıza iletmek için aşağıdaki yapılandırmayı kullanabilirsiniz:
Burp süitinde, kullanıcı seçeneklerine veya proje seçeneklerine gidin ve Socks Proxy’yi 31337 numaralı bağlantı noktasındaki yerel evinize işaret edecek şekilde yapılandırın:
Son olarak, Seçilen Siteler için Switchy Omega’nızı gübre proxy’nize yönlendirin:
Testlerinizi başlatmadan önce, proxy etkinken IFConfig.co veya ipchicken.com gibi bir siteye göz atarken görüntülenen genel IP’nizin değerini doğrulamanızı öneririm.
Artıları / Eksileri
Açıklanan kurulumun bahsetmeye değer birkaç (dis) avantajı vardır:
Profesyonel
- VPN bant genişliğini sadece test etme faaliyetlerine ayırın, bu da bazen titrek bir VPN üzerinden bağlantı hızınızı önemli ölçüde artırabilir;
- “Arka plan” ağ trafiğinizi VPN trafiğinden ayırın, kişisel cihazınızdan test ederken gizliliğinizin risk altında olmamasını sağlayın;
- AWS EC2 örneği, faturanızın bir gecede büyümeye devam etmemesini sağlayarak testler arasında kapatılabilir;
- Atlama ana bilgisayarındaki aynı çorap vekiline işaret ederek tek bir VPN bağlantısından bağlanmak için birden fazla aygıtı yapılandırabilirsiniz.
Eksileri
- Kurulum, OpenVPN istemcinizi yerel makinenize çalıştırmaktan biraz daha kıvrımlıdır;
- AWS EC2 örneğinde başarısız bir VPN bağlantısı olması durumunda, fark etmeden VPN-ED ortamının dışında testler yürütüyor olabilirsiniz;
- Alan başına proxy ayarlarını yapılandırırken, diğer etki alanlarına çarpan web uygulama trafiği proxy olmaz ve muhtemelen beklenmedik sonuçlara yol açar.
Bu konudaki düşüncelerinizi duymak isterim! Benzer bir yaklaşım kullandınız mı? Bu kurulumu geliştirmek veya basitleştirmek için önerileriniz var mı? Aşağıdaki yorumlarda bana bildirin.