büyük ölçekli ortamlar için iptables yönetim araçları


15

Çalıştığım ortam büyük ölçekli bir web barındırma işlemidir (yönetim altında yüzlerce sunucu, neredeyse herkese açık adresleme, vb.) Bu nedenle, ADSL bağlantılarını yönetmekten bahseden her şeyin iyi çalışması pek mümkün değildir. hem temel kural kümesini (şu anda iptables'da yaklaşık 12.000 giriş) hem de müşteriler için yönettiğimiz ana bilgisayar tabanlı kural kümelerini yönetmek için rahat olacak bir şey arıyor. Çekirdek yönlendirici kural setimiz günde birkaç kez değişir ve ana bilgisayar tabanlı kural kümeleri ayda 50 kez değişebilir (tüm sunucularda, bu nedenle ayda beş sunucu başına bir değişiklik olabilir).

Şu anda filtre genini kullanıyoruz (genel olarak toplar ve operasyon ölçeğimizde süper toplar) ve geçmişte diğer işlerde shorewall kullandım (filtrejenlere tercih edilir, ancak dışarıda bundan daha iyi bir şey ol).

Herhangi bir değiştirme sistemi için bulduğumuz "musts":

  • Oldukça hızlı bir şekilde bir kural kümesi oluşturmalıdır (kural setimizde çalışan bir filtre oluşturucu 15-20 dakika sürer; bu sadece çılgınca) - bu bir sonraki nokta ile ilgili:
  • Bir iptables-restore tarzı dosya oluşturmalı ve tek bir isabetle yüklemelisiniz, her kural eki için iptables çağırmamalı
  • Kural kümesi yeniden yüklenirken güvenlik duvarını uzun süre kaldırmamalıdır (yine bu yukarıdaki noktanın bir sonucudur)
  • IPv6'yı desteklemelidir (IPv6 uyumlu olmayan yeni bir şey dağıtmıyoruz)
  • DFSG içermemelidir
  • Düz metin yapılandırma dosyaları kullanmalıdır (her şeyi revizyon kontrolü ile çalıştırdığımızdan ve standart Unix metin işleme araçlarını kullanmak SOP'umuzdur)
  • Hem RedHat hem de Debian'ı desteklemelidir (tercih edilen, ancak en azından her iki dağıtımın standartlarına açıkça düşman olmamalıdır)
  • Sistemin "ana dilinin" parçası olmayan özellikleri desteklemek için isteğe bağlı iptables komutlarını çalıştırma özelliğini desteklemelidir

Tüm bu kriterleri karşılamayan hiçbir şey dikkate alınmayacaktır. Aşağıdakiler "güzellerimiz var":

  • Yapılandırma dosyası "fragmanlarını" desteklemelidir (yani, bir dizine bir yığın dosya bırakıp güvenlik duvarına "bu dizindeki her şeyi kural kümesine dahil et" diyebilirsiniz; yapılandırma yönetimini yaygın olarak kullanmak istiyoruz ve bu özelliği kullanmak istiyoruz. hizmete özel kuralları otomatik olarak sağlama)
  • Ham tabloları desteklemeli
  • Hem gelen paketler hem de REJECT kurallarında belirli ICMP'yi belirtmenize izin vermelidir
  • Birden fazla IP adresine çözümlenen ana bilgisayar adlarını zarif bir şekilde desteklemeli (bununla birkaç kez filtergen tarafından yakalandık; popodaki oldukça kraliyet ağrısı)
  • Aracın desteklediği daha isteğe bağlı / garip iptables özellikleri (yerel olarak veya mevcut veya kolayca yazılabilir eklentiler aracılığıyla) daha iyidir. Iptables'ın tuhaf özelliklerini arada sırada kullanıyoruz ve "sadece çalışanlar" ne kadar çoksa, herkes için o kadar iyi.

Isırırım-- gönderilerinizdeki "toplar" ve "süper toplar" terimleri ne? Sanırım kabarık kauçuk küreler hakkında konuşmuyorsunuz, ancak bağlam "iyi" veya "kötü" anlamına geliyorsa çıkarımda bulunamıyorum.
Evan Anderson

topları == kötü. Süper toplar == ekstra kötü.
womble

Bu kadar kuralla, en üstte kurulu ve ilgili bağlantıları kabul eden bir KABUL kuralına sahip olduğunuzdan emin olun. PC'lerde TCAM yoktur ve birçok kuralın performansı etkiler. Çok.
Thomas

@thomas: Evet, kural setine giren belirli miktarda optimizasyon var. Hangi güvenlik duvarı aracı seçilirse seçilsin optimizasyon hakkında "bilgi" sahibi olmak elbette bir avantaj olacaktır.
womble

Yanıtlar:


4

Belki de kural güdümlü bir yaklaşımdan “gerekli olan son durumu tanımla” yoluna geçmek istiyorsanız, fwbuilder'a bir göz atın.

Artıları:

  • birden fazla güvenlik duvarı desteklenir - temel + ana bilgisayar tabanlı kurallarınız - 1 nesne kümesinden
  • SQL-esque "bana ne istediğini söyle" yerine "nasıl yapılacağını söyle" yaklaşımı (NB orada herhangi bir SQL olduğunu söylemiyorum! Sadece açıklayıcı Vs prosedürel :-)
  • Bu bir GUI, ticari donanım f / w satıcılarının arayüzleri gibi, bu yüzden bazı görevleri çalışan / beceri yığınına itmek mümkün
  • denedim çoğu "garip 'kullanımını destekler
  • çeşitli f / w uygulamaları için kurallar oluşturabilir - BSD / cicso / iptables / etc
  • ön ucu kural derleyiciden ayırır, bu da beni hızın yazarlar için bir endişe kaynağı olduğu konusunda umutlandırır. Not: Bahsettiğiniz ölçeğin yakınında hiçbir şeyim yok
  • Dosya biçimi ikili değil
  • IPv6 yapar
  • Atomik ve hızlı yükleme için iptables-save stylee yapılandırması oluşturur

Eksileri:

  • Bu bir GUI
  • Mevcut kural setinizi taşımanın ağrısız olması pek olası değildir
  • GPL ve Debian'da, Windows + OSX istemcileri 30 günlük bir değerlendirmedir, çünkü hiç kimse bu işletim sistemi için henüz Ücretsiz bir sürümü derlememiştir; dolayısıyla devlerin ticari kolu bu ikililer üzerinde bir tekele sahip
  • Dosya biçimi teknik olarak XML'dir; NB bunun sizi ertelemesine izin vermeyin: Sağladıkları araçlara bir göz atın (örneğin, CLI aracılığıyla manipüle etmek için gui binary'yi kullanabilirsiniz), zaten var olan CLI XML araçlarını ve unutmayın - sizin ölçek - meta-veri + yapısının bazı benzerlikleri / bad / thing değil! Düzenlemeler arasında oldukça güzel farklar var, IIRC.

Bağlantı: http://www.fwbuilder.org


Hrm ... Bir bakayım. Bir GUI'nin varlığı (XML'den bahsetmiyorum) beni oldukça şiddetli bir şekilde seğirtiyor, ancak bazı ilginç fikirler ortaya atıyorsunuz (tüm altyapı için tek bir kural kümesi). OS X olayı sorun olmayacak.
womble

Katılıyorum, bir GUI bana aslında WTF yaptı, ancak CLI tarafından gördüklerimden memnun kaldım. Zaten kurulumunuz ne kadar dinamik? Günde 10 veya yılda 10 değişiklik olur mu? Burada detay vermek için yararlı bir faktör olabilir. Ayrıca, XML dosya biçiminin güzel bir işlevi, XML uyumlu araçları kullanarak, tek tanım nesnelerini kullanarak tüm yapılandırmayı tek bir dosyada kullanabilmeniz, ancak tek tek sunucunun yapılandırmalarını ve değişiklik kümelerini belgelemek için düğüme özgü bir değişiklik günlüğü üretebilmeniz olabilir. . Sadece bir düşünce ...
Jonathan Matthews

@Jonathan: Haklısın, kural setinin dinamikliğini bilmek önemlidir. Soruyu düzenledim; Çekirdek kural kümesi için günde en fazla birkaç iş günüdür.
womble

3

kendin yaz. ciddi olarak - bu ölçekte makul.

kullanmak ipset ve / veya iptable tablolar / subtables bol. mümkün olduğunda yalnızca bazı alt tabloları / bazı ipset gruplarını yeniden yükleyin - bu yeniden yapılandırmayı hızlandıracaktır.

muhtemelen zaten yapıyorsunuz, ancak yine de bahsetmeye değer - yönlendiricideki yükü ve yeni bağlantılar kurmak için gereken ortalama arama sayısını azaltmak için iç içe tabloları kullanın. Açıkçası -İLERİ -m durumu --stat KURULDU, İLGİLİ en üst kuralınız.


"Kendi yaz" masanın dışında değil, ama ilk etapta filtergen var - şimdi eski bir çalışan tarafından yazılmıştır. Mümkünse başka bir güvenlik duvarı yönetim aracı daha üretmemeyi tercih ederiz.
womble

IPSET büyük kural setleri için yıldırım hızındadır. "birden fazla IP adresini veya port numarasını saklayın ve bir swoop'ta iptables tarafından koleksiyonla eşleşin; iptables kurallarını performans cezası olmadan IP adreslerine veya bağlantı noktalarına dinamik olarak güncelleyin; tek bir iptables kuralıyla karmaşık IP adresi ve port tabanlı kural kümelerini ifade edin ve hızdan yararlanın IP setleri "Ben shorewall ile kullanın. Shorewall'un sizin ölçeğinizde nasıl performans göstereceği hakkında hiçbir fikrim yok.
Mart'ta artifex

2

kutsal toplar (temayı canlı tutuyor!) adam ... 12.000 temel kural?

Setleri sadece CVS'ye bırakmak gibi tüm kolay seçenekleri düşündüğünüzü varsayıyorum? Kukla mı CFengine mi?

Dürüst olmak gerekirse, verdiğiniz genel bakıştan, ağ tasarımınızı yeniden değerlendirmenizi önemle tavsiye ederim. Muhtemelen biraz fazla basitim, ama sadece 12k iptables kurallarını gerektirecek bir tasarımı kavrayamıyorum. Bu, güvenlik duvarı kurallarını yönetmenin daha iyi bir yolundan ziyade SLB tipi bir çözümden daha fazla fayda sağlayacak bir şey gibi görünüyor.

Yan notta, "cevap" eklemek yerine yorum nasıl eklenir?


Yorum yapmak için minimum miktarda itibara ihtiyacınız var. Bunu yaptığınızda bir bağlantı görünecektir.
jay_dubya

Muhtemelen iptables kurallarımızda belirli bir miktar fazlalık vardır, ancak bu büyük ölçüde bir filtre jenerinin işlevi olabildiğince verimli olmayabilir. Bununla birlikte, bir / 19 IP alanımız ve müşteri başına VLAN'larımız ve oldukça kısıtlayıcı bir "varsayılan politikamız" var (bağlantı noktalarını müşteriler tarafından istendiği gibi açmak için IP başına özel durumlar gerektirir). Kesinlikle bu kurallardan birkaçından kurtulamayacağız. Oh, ve evet, zaten Kukla kullanıyoruz ve operasyon ölçeğimizde elle kurallar yazmaya başlamak üzereyiz.
womble

Kesinlikle kendimden daha büyük bir IP alanı tutuyorsunuz, ancak yine de bir çok kuralı bir şekilde haklı çıkarmak zor buluyorum. Bunları, chokepoints'teki düşme kuralı kurulumlarını kullanabileceğiniz bir ağaç yapısına bölmeyi düşündünüz mü? yani, alt ağ X sadece web tüm sunucular, alt ağ Y tüm web + smtp sunucuları? Aslında onları alt ağa bağlamak zorunda kalmazsınız, sadece mantıksal olarak katmanlı bir güvenlik duvarının arkasında gruplandırın ... bu noktada sadece gürültü ekliyorsam özür dilerim ... Bunun için yeterince sofistike olmayabilirim. Güvenlik duvarı kural
setlerimi beğeniyorum

Biz gerçekten böyle şeyleri “kademelendirme” konumunda değiliz; biz büyük ölçüde adanmış bir sunucu barındırma sağlayıcısıyız, bu nedenle müşterilerimizin makinelerle günlük olarak ne yapmaya karar verdikleri değişebilir, bu da dahili bir hizmet için özel bir altyapı yapıyor olmamızdan çok daha fazla dans gerektirebilir.
womble

0

12000 kural? deli misin? Bu miktarda filtrelemenin devam etmesiyle ilgili performans sorunlarınız yok mu? Neden 12.000 kurala ihtiyaç duyacağınızı göremiyorum? Ayarladığınız kuralların politikayı gerçekten uyguladığını nasıl doğrularsınız?

Politika nedir?

Politikanızı nasıl test ediyorsunuz?

12.000 kural muhtemelen kitaptaki her güvenlik kuralını ihlal eder.


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.