Merkezi güvenlik duvarını ağ topolojisine sığdırmaya çalışmak


11

Ağımızı aşırı taşıma sürecindeyim, geri dönmeye devam ettiğim sorun: hala merkezi bir güvenlik duvarına sahipken, katman 3'ü çekirdeğe getirmeye çalışmak.

Burada karşılaştığım ana sorun, baktığım "mini çekirdek" anahtarların her zaman düşük donanım içi ACL sınırlarına sahip olması, mevcut boyutumuzda bile hızlı bir şekilde vurabildiğimiz. Şu anda çekirdek için bir çift EX4300-32F satın almak üzereyim, ama diğer modellere ve Juniper ve Brocade'in ICX serisinden diğer seçeneklere baktım. Hepsi aynı düşük ACL sınırlarına sahip gibi görünüyor.

Çekirdek anahtarların kablo hızı yönlendirmesini sürdürmesi gerektiğinden, bu çok mantıklıdır, bu nedenle ACL işlemiyle çok fazla fedakarlık yapmak istemeyin. Böylece tüm güvenlik duvarlarımı çekirdek anahtarlarında kendim yapamıyorum.

Bununla birlikte, çoğunlukla tam olarak yönetilen sunucular yapıyoruz ve merkezi (durum bilgisi olan) bir güvenlik duvarına sahip olmak, müşterilerin birbirleriyle doğrudan konuşmasını sağlayamadığımız için bu yönetime çok yardımcı oluyor. Mümkünse böyle tutmak isterim, ancak çoğu ISS ağı bu tür bir şey yapmayacakmış gibi hissediyorum, bu nedenle çoğu durumda çekirdeği yönlendirmeyi yapmak doğrudan doğru olur.

Referans olarak, işte ideal olarak yapmak istediğim topoloji (ancak FW'yi nereye sığacağından emin değilim).

ağ

Mevcut Çözüm

Şu anda, bir çubukta yönlendirici yapılandırmamız var. Bu, NAT, durum bilgisi olan güvenlik duvarı ve VLAN yönlendirmesini tek bir noktada yapmamızı sağlar. Çok basit.

L2'yi ağımızın "üst" üne (sınır yönlendiricileri) kadar genişleterek (kabaca) aynı çözümle devam edebilirim. Ama sonra çekirdeğin bana sunabileceği kablo hızı yönlendirmesinin tüm avantajlarını kaybediyorum.

IIRC çekirdek anahtarları 464 Gbps yönlendirme yapabilirken, sınır yönlendiricilerim şanslıysam 10 veya 20 Gbps sunabilir. Bu teknik olarak şu anda bir sorun değil, daha çok bir büyüme meselesi. Sanki şu anda çekirdek yönlendirme kapasitesinden yararlanmak için mimariyi tasarlamazsak, daha büyük olduğumuz ve bu kapasiteden yararlanmamız gerektiğinde her şeyi yeniden yapmak acı verici olacaktır. İlk seferinde doğru yapmayı tercih ederim.

Olası çözümler

Erişilecek Katman 3

Belki de L3'ü erişim anahtarlarına genişletebileceğimi ve böylece güvenlik duvarı kurallarını daha sonra erişim anahtarı ACL'lerinin donanım sınırlarına uyacak daha küçük bölümlere ayırabileceğimi düşündüm. Fakat:

  • Bildiğim kadarıyla bunlar durumsal ACL'ler olmayacaktı
  • Erişim için L3, bana göre, çok daha esnek görünmüyor. Sunucu dolapları veya diğer dolaplara VM geçişleri daha acı verici olacaktır.
  • Her rafın üstünde bir güvenlik duvarı yöneteceksem (sadece altı tanesi), muhtemelen yine de otomasyon istiyorum. Bu noktada, güvenlik duvarlarının ana bilgisayar düzeyinde yönetimini otomatikleştirmek için bir sıçrama değildir. Böylece tüm sorunu önlemek.

Erişim / çekirdek arasındaki her yukarı bağlantıda köprülü / şeffaf güvenlik duvarları

Bunun birden fazla güvenlik duvarı kutusu içermesi ve gerekli donanımı önemli ölçüde artırması gerekir. Ve güvenlik duvarları olarak düz eski Linux kutularını kullanarak daha büyük çekirdek yönlendiriciler satın almaktan daha pahalı olabilir.

Dev çekirdek yönlendiriciler

İhtiyacım olan güvenlik duvarını yapabilen ve çok daha büyük bir yönlendirme kapasitesine sahip daha büyük bir cihaz satın alabilir miyim. Ama gerçekten bunun için bütçem yok ve eğer bir cihazı tasarlanmadığı bir şey yapmaya çalışıyorsam, muhtemelen çok daha yüksek özelliklere gitmem gerekecek. başka türlü yapamayacağım.

Merkezi güvenlik duvarı yok

Çemberlerden atladığım için, belki de bu çabaya değmez. Her zaman sahip olmak güzel bir şeydi ve bazen "donanım" güvenlik duvarı isteyen müşteriler için bir satış noktasıydı.

Ancak "tüm" ağınız için merkezi bir güvenlik duvarına sahip olmanın mümkün olmadığı anlaşılıyor. Öyleyse, daha büyük ISP'lerin yüzlerce hatta binlerce ana bilgisayarı olduğunda, özel sunucuları olan müşterilere ne kadar daha büyük donanım güvenlik duvarı çözümleri sunabileceğini merak ediyorum?

Herkes bu sorunu çözmenin bir yolunu düşünebilir mi? Ya tamamen özlediğim bir şey mi, yoksa yukarıdaki fikirlerden birinde bir varyasyon mu?

GÜNCELLEME 2014-06-16:

@ Ron'un önerisine dayanarak, karşılaştığım sorunu ve sorunu çözmenin iyi bir yolunu açıklayan bu makalede tökezledim.

Başka öneriler olmadığı sürece, bunun bir ürün önerisi türü problem olduğunu söyleyebilirim, bu yüzden bunun sonu olduğunu düşünüyorum.

http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/


Ağda VRF-lite veya MPLS mi kullanıyorsunuz? Çekirdek anahtarlar hangi marka?
Daniel Dib

@DanielDib Henüz VRF veya MPLS kullanmıyorum, ancak bu site ile başka bir site arasında dağıtmayı planlıyorum. Marka henüz kesin değil (hala satın alma listesini bulmaya çalışıyor) ... Ama şu anda çoğunlukla Juniper EX4300-32F veya Brocade ICX 6610-48-PE'ye
bakılıyor

1
Kapatmak için oy verdim; Bunun nedeni, sorduğunuz sorunun, hangi satıcının seçeceği / model seçeceği ve bütçe kısıtlamaları vb. Gibi çözümünüz için çok özel ayrıntılara, bunun müşterileriniz için ürün teklifinizi nasıl değiştireceğidir ... Burada uygun olmayan her şey , bunlar iş kararlarıdır. Her topolojinin uzmanlarının ve aleyhtarlarının ne olduğunu sorabilirsiniz, ancak kimse sizin için en iyi olanı size söyleyemez.
jwbensley

1
Durumunuzdaki iki peni; Cisco ASAs gibi bağlamları destekleyen veya sadece sanal güvenlik duvarlarına sahip olan güvenlik duvarlarını düşündünüz mü? Her müşteri için varsayılan ağ geçidi olarak müşteri VLAN'ına bıraktığınız ve kenar yönlendiricilerinize doğru halka açık bir VLAN'a daldığınız iki arabirime sahip güvenlik duvarlarını döndürebileceğiniz bazı VM ana bilgisayarlarına sahip olun. Sadece bir düşünce (Sanal güvenlik duvarlarını tercih ederim).
jwbensley

2
Cisco ASA 1000V veya Catbird (catbird.com) gibi sanallaştırılmış güvenlik duvarlarına ciddi şekilde bakarım. Bu şekilde her vserver'a bir güvenlik duvarı yerleştirebilirsiniz. Erişim listelerinizi ana yönlendiricinizden uzak tutun.
Ron Trunk

Yanıtlar:


5

İki seçenekten birini seçerdim:

Kiracı başına bireysel Sanal Güvenlik Duvarları

Artıları:

  • Yatay olarak ölçeklenebilir
  • Spin-up ve aşağı spin
  • Gelecekteki topoloji / tasarım değişikliklerine göreceli olarak bağışıklık
  • Eksiksiz müşteri ayrımı / izolasyonu

Eksileri:

  • Standart bir şablonu zorlamadığınız sürece, artık yönetmek için n ayrı güvenlik duvarınız var
  • Artık izlenecek n ayrı güvenlik duvarınız var
  • Artık yama yapmak için n ayrı güvenlik duvarınız var

Kiracı başına yönlendirme örneği / bağlam içeren büyük güvenlik duvarı şasisi / kümesi

Çekirdeğinizin yanına sarkan büyük bir merkezi güvenlik duvarı (küme) dağıtın ve trafiği tekrar tekrar yönlendirmek için dahili ve harici bir yönlendirme örneği kullanın (örneğin: Dahili örnekte varsayılan ağ geçidi güvenlik duvarı, varsayılan ağ geçidi açık güvenlik duvarı çekirdekteki harici yönetim ortamınızdır ve harici yönetim ortamı için varsayılan değer sınırlarınızdır.)

Artıları:

  • Yönetmek ve yapılandırmak için tek kutu
  • İzlemek için tek kutu
  • Yama için tek kutu
  • Müşteri ayrımı

Eksileri:

  • Birinci gün maliyeti daha yüksek olacak
  • Ölçeklendirme yok
  • Yapılandırmaya bağlı olarak, müşteriler arası trafik sınır yönlendiricilerinizde yönlendirmeye başlayabilir

0

Hangi çekirdek anahtarları kullanıyorsunuz? Politikalar genellikle dağıtım katmanında yapılır, eğer daraltılmış bir Core tasarımı ile gidiyorsanız, çekirdek ihtiyaçlarınızı karşılayabilmelidir. Ayrıca, devlet denetimini mi yoksa sadece acls'ı mı seviyorsunuz? Takip etmeniz gereken herhangi bir uyumluluğunuz varsa, acls yeterli olmayabilir.

Şahsen, bir güvenlik duvarı ile giderdim, belki de kümelenebilir bir tane ararım, böylece her birini kümeleyebilir ve kaynak ateşi güvenlik duvarı gibi merkezi olarak yönetilen kural tabanını koruyabilirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.