Kukla Güvenliği ve Ağ Topolojileri

Arka fon:

Sonunda 21. Yüzyıla katılmak ve Kukla'ya bakmak için biraz zaman ayırıyorum.

Bugünkü haliyle, tüm sunucu konfigürasyonlarını ofiste dahili olarak tutulan bir depoda kontrol ediyoruz. Bir güncelleme yapılması gerektiğinde, değişiklikler depolara geri kontrol edilir ve söz konusu makineye manuel olarak gönderilir. Bu genellikle uzak makineye SFTP yapmak ve ardından ilgili izinlerle dosyaları bir kabuktan yerine taşımak anlamına gelir.

Bu yüzden, Puppet'in sahip olduklarımız için basit ama şaşırtıcı bir uzantı olacağına ümit ediyorum.

Şimdi, şu anda makul bir şekilde güvence altına almamız gereken süreci düşünüyorum. İç ağımızın her zaman veri merkezlerimizdeki kamu ağlarından daha güvenli olacağı varsayımına dayanarak.

• İşlem her zaman bir yoldur. Değişiklikler güvenli bir ortamdan güvenli olmayan bir yere doğru ilerler ve asla tersi olmaz.

• Ana mağaza mümkün olan en güvenli yerdedir. Yapılandırmaları çalarak veya kötü amaçlı değişiklikler göndererek uzlaşma riski büyük ölçüde azaltılır.

Soru:

Kukla sunucu / müşteri modelini anladığım kadarıyla, müşterilerin güncellemeleri doğrudan sunucudan aşağı çekiyorlar. Trafik SSL sarılı olduğundan yakalanamaz veya karıştırılamaz. Ancak şu an yaptığımızdan farklı çünkü Kukla sunucusunun halka açık bir yerde barındırılması gerekiyor. Ya merkezi olarak ya da koruduğumuz her veri merkezi sitesi için bir tane.

Bu yüzden merak ediyorum:

• Basından çekişe değişim konusunda gereksiz yere paranoyak mı oluyorum?

• Tüm bu bilgileri merkezi bir ağda merkezi olarak saklama konusunda gereksiz yere paranoyak mı oluyorum?

• Diğerleri birden fazla ağı nasıl yönetiyor - her site için ayrı sunucu?

30.07.09. Güncellemesi:

Sanırım en büyük endişelerimden birinin tek bir makineye güvenmesi gerektiği. Kuklacı (lar) güvenlik duvarı ile korunacak, güvence altına alınacaktı ve bu şekilde. Ancak, dinleme hizmetleri olan herhangi bir kamu makinesinin belirli boyutta bir saldırı yüzeyi vardır.

Muhtemelen, usta kukla müşterilerinden herhangi biri üzerinde herhangi bir dosyayı güncelleme iznine sahipse, sonuçta bu uzlaşma sonuçta tüm istemcilerinin uzlaşmasına neden olacaktır. Konuşmak için "krallığa kral".

• Bu hipotez doğru mu?

• Hafifletilmesinin bir yolu var mı?

Bazen şifreleri modüllerimdeki değişkenlerde sakladığımdan, uygulamaları yapılandırmayı manuel olarak bitirmek zorunda kalmadan dağıtabilmek için kukla depomu düzgün bir şekilde genel bir sunucuya koyamayacağım anlamına geliyor. Bunu yapmak, kuklacıya saldırmanın tüm sunucularımızdaki tüm farklı uygulamalarımızın bazı uygulama veya db şifrelerini kazanmasına izin vereceği anlamına gelir.

Kukla yöneticim ofisimizdeki özel ağda ve sunucularda kukla daemonu çalıştırmıyorum. Dağıtmam gerektiğinde, ssh'ı özel ağdan sunuculara, bir tünel oluşturup uzaktan kuklacı çağırarak kullanıyorum.
İşin püf noktası, uzak tünel ve kukla istemcisini kukla yöneticisine bağlanacak şekilde ayarlamak değil, http bağlantısını kabul eden ve özel ağdaki kuklacı sunucusuna erişebilen bir proxy'ye ayarlamaktır . Aksi halde kukla, sertifikalarla host adı çatışması nedeniyle çekmeyi reddedecek

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

Benim için çalışıyor, yardımcı olacağını umuyor

Ofisimiz ve kolomuz olmak üzere iki sitemiz var. Her sitenin kendi kukla yöneticisi var. Aşağıdaki yapıya sahip bir svn deposu kurduk:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

Her sitenin altındaki modüller dizini, bir svn: externals dizini, tekrar üst seviye modüller dizinine geri döner. Bu, tamamen aynı modüller dizinini paylaştıkları anlamına gelir. Daha sonra yazdığımız sınıfların büyük çoğunluğunun modüller dizini altında olduğundan ve her iki site tarafından da kullanıldığından emin oluruz. Bu, bizi genel olarak düşünmeye zorlamak ve bir sınıfı belirli bir siteye bağlamak için zorlama avantajına sahiptir.

Güvenlik konusunda, kukla yöneticimizi (ve ağımızın geri kalanını) güvenlik duvarımızın arkasında barındırıyoruz, bu yüzden konfigürasyonu merkezi olarak saklama konusunda endişeli değiliz. Kuklacı yalnızca güvendiği ana bilgisayarlara config gönderir. Açıkçası o sunucuyu güvende tutman gerekiyor.

Paranoya'nın ne kadar gerekli olduğu konusunda karar veremem, bu büyük ölçüde çevrenize bağlı. Ancak, mevcut yapılandırmanızın iki ana noktasının hala geçerli olabileceğini güvenle söyleyebilirim. Kukla yöneticinizin bulunduğu her yerde güvenli bir ortamdan (ofisinizdeki depo) daha az güvenli bir ortama geçişinizin değişmesini sağlayabilirsiniz. İşlemi SFTP'ing'ten bir grup sunucuya değiştirir ve manuel olarak dosyaları SFTP'ing'e yerleştirmek için kukla yöneticinize yerleştirirsiniz ve Kukla'ın dosyaları dağıtmasına ve bunları doğru yere koymasına izin vermiş olursunuz. Ana mağazanız hala depoda ve riskleriniz azaltıldı.

İtme veya çekme işleminin diğer modelden daha güvenli olduğuna inanmıyorum. Kukla, iki yollu bir güven söz konusu olduğundan emin olmak için hem istemcinin hem de sunucunun kimliğini doğrulamanın yanı sıra, yapılandırmaları güvenli bir şekilde yerine getirmek için de harika bir iş çıkarmaktadır.

Çoklu ağlara gelince, her bir merkezdeki uydu kuklacıların bulunduğu merkezi bir "ana" kuklacı ile merkezi anaya müşteri olarak davranıyoruz.

Bir tasarım yaklaşımı, her bir sistem sitesinde yerel bir kuklacı bulundurmak ve kuklacılara değişiklikleri zorlamak için bir dağıtım aracı kullanmaktır. (Git'i git kancalarıyla kullanmak da işe yarayabilir).

Bu, kukla ağ trafiğinin yalnızca dahili olacağı için bir kamu ağındaki dinleme servisleri hakkındaki endişenizi koruyacaktır.

Ayrıca, bildirimleri her sunucuya iletmek ve kukla istemcisinin bildirimleri ayrıştırması ve ilgili yapılandırmaları uygulaması da mümkündür.

"Dış" demenize rağmen, keyfi olarak insanların kukla yöneticinize bağlanması gerektiğinden şüpheliyim. karışıma her zaman bir VPN atabilirsiniz. bir arkadaşım bir keresinde bana "bağlantı güvenliyse protokolün güvenliği hakkında endişelenmeniz gerekiyor mu?" diye sordu. bu tutuma katılmamakla birlikte, ekstra bir katman asla acıtmaz ve kesinlikle kişisel paranoyamda harikalar yaratır. Ayrıca, tünel tünelleri için eğlenceli.

Cfengine'in yazarı ve bir üniversite profesörü olan Mark Burgess (bu kuklanın mirasına borçlu olduğu görülüyor) itme ve çekme konusunda çok şey yazdı. Çekmenin doğası gereği daha güvenli olduğunu iddia ediyor. Cfengine web sitesine bakarsanız, yalnızca 17 yılda 1 ağ güvenliği olayı olmuşlardır. Burgess, çekme tasarımı nedeniyle olduğunu iddia ediyor. Tek bir uzlaşma noktasının kaçınılmaz olduğunu düşünüyorum. Bu noktaya saldırı yolları hakkında daha fazla endişe duyarım.

İsterseniz merkezi bir usta olmadan kukla çalıştırabilirsiniz. Gördüğüm bir yöntem git deposunu kullanmak ve yalnızca bir etiketi önceden ayarlanmış bir gpg anahtar listesinden biri tarafından imzalanmışsa, yalnızca bir güncellemeyi birleştiren ve dağıtan komut dosyalarına sahip olmaktır. İnsanlar nasıl saklanmış konfigürasyonlar elde edebileceğini bile araştırdılar (örneğin, başka bir sunucuda işlenen bir kaynaktan merkezi bir sunucuda nagios izlemesi kurmak için kullanılır).

Yani merkezi git sunucusu tehlikeye girerse, diğer sunucular ondan daha fazla güncelleme uygulamaz. Gpg anahtarları, tuşları iptal etme yöntemiyle birlikte sys admin dizüstü bilgisayarlarında ya da bir şeyde olacaktır.

Http://current.workingdirectory.net/posts/2011/puppet-without-masters/ adresinde daha fazla bilgi alabilirsiniz.