Bağlantı noktası 80'den geçen trafiği denetlemek için 2 ağ kartı ile kurulmuş bir linux kutum var. Bir kart internete çıkmak için kullanılır, diğeri ağ anahtarına bağlanır. Buradaki nokta, hata ayıklama amacıyla bu anahtara bağlanan aygıtlardaki tüm HTTP ve HTTPS trafiğini denetleyebilmektir.
İptables için aşağıdaki kuralları yazdım:
nat
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337
-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE
192.168.2.1:1337’de, Charles’ı kullanan şeffaf bir http proxy’im var.http://www.charlesproxy.com/) kayıt için.
Her şey port 80 için iyi, ancak port 1337'ye işaret eden 443 (SSL) portu için benzer kurallar eklediğimde, Charles üzerinden geçersiz mesajla ilgili bir hata alıyorum.
Daha önce Charles ile aynı bilgisayarda SSL proxy kullanıyorum (http://www.charlesproxy.com/documentation/proxying/ssl-proxying/), ancak bir sebepten dolayı şeffaf bir şekilde yapmakta başarısız oldu. Ben googled bazı kaynaklar mümkün olmadığını söylüyor - Birisi nedenini açıklayabilir eğer bir cevap olarak kabul etmeye istekli.
Bir not olarak, alt ağa bağlanan tüm istemciler de dahil olmak üzere, açıklanan kurulum için tam erişimim var - bu yüzden Charles tarafından imzalı imzayı kabul edebiliyorum. Çözüm, teoride, herhangi bir şeffaf vekil yapacağı için Charles'a özgü olmak zorunda değildir.
Teşekkürler!
Düzenleme: Onunla biraz oynadıktan sonra, belirli bir sunucu için çalışmayı başarabildim. Iptables'leri aşağıdakilere değiştirdiğimde (ve ters proxy için 1338'de charles'i açın):
nat
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338
-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE
Bir yanıt alabiliyorum, ancak hedef host yok. Ters proxy'de, 1338'deki her şeyin vurmak istediğim belirli bir ana bilgisayara gittiğini belirtirsem, el titremesini düzgün yapar ve iletişimi denetlemek için SSL proxy'lerini açabilirim.
Kurulum, idealden daha azdır çünkü 1338'den gelen her şeyin o ana makineye gittiğini varsaymak istemiyorum - hedef ana bilgisayarın neden kaldırıldığı konusunda bir fikrin var mı?
Tekrar teşekkürler
Gördüğünüz konular aynı Tek bir IP adresi / portunda birden fazla sertifikanın kullanımını engeller (Sunucu Adı Göstergesini kullanmadan).
Düz HTTP'de şeffaf proxy'niz, istemcinin hangi ana bilgisayara bağlanmak istediğini anlatabilir.
Host başlığı.
HTTPS MITM şeffaf proxy'si talebi aldığında, istemcinin hangi host adını talep ettiğini bilmez. (IP adresini bu kurallarla alabileceğinden bile emin değilim, bu da en azından genel durumda çalışmasa bile ters bir DNS araması kullanarak bir tahminde bulunmasına izin verebilir.)
- Beklenen ana bilgisayar adını elde etmek için MITM proxy'si
Host HTTP mesajında sadece başarılı bir tokalaşmanın ardından ortaya çıkan başlık.
- Başarılı bir el sıkışma elde etmek için MITM proxy'sinin beklenen hostname ile eşleşen bir sahte sertifika üretmesi gerekir.
Sonuç olarak, MITM proxy'si, el sıkışmadan önce hangi sertifikanın üretileceğini bilemez.
Bu saydam olmayan bir MITM proxy'si ile çalışabilir, çünkü en azından istediğiniz ana bilgisayar adını HTTP üzerinden alırsınız
CONNECT yöntem.
Bu konu hakkında sadece bazı temel bilgiler.
Bu eylemi başarılı bir şekilde çıkarabilen sadece birkaç cihaz var. Ancak, ortak halk için gerçekten uygun değildirler. Kendimi SSL Boşaltma ile Fortinet Fortigate kullanıyorum.
Temelde yaptığı şey; sunucuya yapılan SSL Bağlantısını keser ve bağlantıyı donanımdaki şifresini çözer, sonra nereye gitmek istediğinizi denetler ve bu bilgilere dayanarak bir güvenlik duvarı kararı alır.
Daha sonra, verileri almak ve orijinal isteği kullanıcı tarafından sağlanan bir CA kullanarak istemciye yeniden imzalamak için o ana makineye kendi bağlantısını kurar. Bunun sorunsuz bir şekilde çalışması için CA'nın istemcide güvenilen kök CA'da bulunması gerekir.
Bu tür kurulumlar, internet kullanımında şirket politikalarını uygulamak için kuruluşlarda kullanılmaktadır. Bir Active Directory kullandığınızdan, şirket CA'nızı istemcilere yüklemek kolaydır, bu büyük kuruluşlar için sorun oluşturmaz.
SSL trafiği şifrelendiği için bu, manuel proxy oluşturmadan SADECE yapabileceğiniz yoldur. Temelde bir MITM'dir, bu yüzden herhangi bir yasal meselenin ele alınması önemlidir.
Gördüğünüz diğer bir kaç soru daha var: şeffaf SSL vekil efsaneleri ve gerçekler. Ve Squid'in şeffaf bir SSL proxy'si haline gelmesini tam olarak nasıl yapılandıracağını açıklayan bu bağlantı var. Aradığın şey değil, ama en azından neyin yanlış gidebileceği hakkında bir fikir verebilir.
İptables kuralları iyi görünüyor, ama kullanmakta olduğunuz proxy yazılımını yapmakta olduğunuz şeyi yapabilmenin mümkün olup olmadığını bilmiyorum. Belgeler kesinlikle böyle olduğunu iddia ediyor.
Bruno'nun çözümüne eklemek için biraz araştırdım ve henüz biraz daha hızlı bir şekilde nasıl düzeltildiğimi paylaşmak istedim.
Bu iptables'leri ayarladıktan sonra, 1338 numaralı bağlantı noktasında bir ters proxy yerleştirebilir ve 1337 numaralı bağlantı noktasında localhost'a yönlendirebilirim. 1337 numaralı bağlantı noktası şeffaf bir http proxy'si olduğundan ve verilerin deşifresi çözüldüğü için, ana bilgisayar üstbilgisini alıp hedef haline getirecektir. konak.
Büyük dezavantajı esasen bir https bağlantısını http olarak dönüştürdüğümdür - bu her zaman her sunucuyla çalışmaz (bundan açığım olan güvenlik çukurundan bahsetmez).
Yazılımımın sınırları dahilinde çalışıyordum. Bruno'ya göre daha temiz bir çözümün 1338'den gelen tüm trafiğin deşifre edilmesi gerektiğini varsaymak olduğuna inanıyorum. Şifre çözme işleminden sonra, hedef ana bilgisayarı inceleyin ve ardından isteği SSL kullanarak proxy'ye gönderin.