Yaklaşık 1 milyon IP adresini kara listeye almak için IPtables veya null yolunu kullan?

Bir müşterinin 1 milyondan az IP adresini (alt ağ yok) bir kara listeye koyması gereken bir durumla karşılaştım ve ağ performansı bir endişe kaynağı. IPTables kurallarının rotalardan daha az performans etkisine sahip olacağını varsaysam da, bu sadece bir varsayım.

IP adreslerini veya uzun IP adres listelerini kara listeye almak için null yönlendirme yapmak için herhangi bir sağlam kanıtı veya başka bir gerekçesi var mı? Bu durumda her şey otomatik, kullanım kolaylığı gerçekten bir sorun değil.

EDIT 26-Kasım-11

Bazı test ve geliştirmelerden sonra, bu seçeneklerden hiçbirinin işe yaramadığı anlaşılıyor. Hem rota aramalarının hem de iptables'ın kurallar arasında doğrusal aramalar yaptığı ve bu kadar fazla kuralı işlemesi çok uzun sürdüğü anlaşılıyor. Modern donanımda, 1M öğelerini iptables kara listesine koymak, sunucuyu saniyede yaklaşık 2 düzine pakete düşürüyor. Yani IPTable'lar ve boş yollar açık.

ipsetJimmy Hedman'ın önerdiği gibi, bir sette 65536'dan fazla adresi izlemenize izin vermemesi haricinde, harika olurdu, bu yüzden birisi hakkında hiçbir fikri olmadığı sürece kullanmaya bile çalışamıyorum.

Görünüşe göre bu kadar çok IP'yi engellemenin tek çözümü, uygulama katmanında dizine alınmış bir arama yapmak. Öyle değil mi?

Daha fazla bilgi:

Bu örnekte kullanım durumu, "bilinen suçluların" bir IP adresi listesinin bir web sunucusundaki statik içeriğe erişmesini engelliyor. FWIW, Apache'leri kullanarak engelleme yapmak Deny fromda aynı derecede yavaş (eğer değilse) doğrusal bir tarama yapıyor.

FYI: Son çalışma çözümü, kara listeye karşı arama yapmak için apache'nin mod_rewrite'ını bir berkeley DB haritası ile birlikte kullanmaktı. Berkeley DB'lerin endekslenmiş yapısı, listenin O (log N) performansı ile ölçeklenmesini sağladı.

iptables kullanmayı ve arama sayısını azaltmak için çok seviyeli bir ağaç oluşturmayı deneyin.

iptables -N rules_0_0_0_0_2
iptables -N rules_64_0_0_0_2
iptables -N rules_128_0_0_0_2
iptables -N rules_192_0_0_0_2
iptables -N rules_0_0_0_0_4
iptables -N rules_16_0_0_0_4

iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/2 -j rules_0_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 64.0.0.0/2 -j rules_64_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 128.0.0.0/4 -j rules_128_0_0_0_2
iptables -A INPUT -p tcp --dport 80 -s 192.0.0.0/4 -j rules_192_0_0_0_2

iptables -A rules_0_0_0_0_2 -s 0.0.0.0/4 -j rules_0_0_0_0_4
iptables -A rules_0_0_0_0_2 -s 16.0.0.0/4 -j rules_16_0_0_0_4

ve benzeri - iç içe geçme düzeyleri ekleme; Açıkçası, kuralları oluşturmak için otomatik bir yol gerekecektir ve yalnızca bir ya da daha fazla suçluya sahip olduğunuz ağlar için zincirlere sahip olmalısınız - bu sayede oldukça fazla yapılması gereken arama sayısını azaltabilirsiniz ve bence aslında işe yarıyor.

Bu tam olarak ne ipsetiçindir.

Web sitesinden http://ipset.netfilter.org/ :

Eğer istersen

• Birden fazla IP adresini veya port numaralarını saklayın ve bir dokunuşta iptables ile koleksiyonla eşleştirin;
• iptables kurallarını performans cezası olmadan IP adreslerine veya portlara karşı dinamik olarak güncellemek;
• Tek bir iptables kuralıyla karmaşık IP adresini ve port temelli kuralları tanımlayın ve IP kümelerinin hızından yararlanın

o zaman ipset sizin için uygun bir araç olabilir.

Netfilter çekirdek ekibi üyesi Jozsef Kadlecsik (REJECT hedefini de yazan kişi) tarafından yazılmıştır, bu yüzden aklıma gelen en iyi seçenek budur.

Son çekirdeğe bile dahil edilmiştir.

Bunu kendim test etmedim, ancak sorun tanımınızı duyduğumda anında " pf" (OpenBSD'den itibaren) diye düşündüm .

pfSadece aradığınız şey olabilir adres tabloları kavramı vardır .

Yaptığım çok lanetli araştırmalara göre , bunun daha iyi ölçeklendirme potansiyeline sahip görünüyor ipset. Göre Runtime Seçenekleri PF SSS bölüm ayar yapmadan kutunun, dışarı, pf destekler, varsayılan olarak tüm tablolar arasında 200.000 girişlerinin toplam 1.000 tablolar olmak üzere toplam. (Sistem <100 MB fiziksel belleğe sahipse 100,000). Bu, en azından herhangi bir faydalı düzeyde çalışıp çalışmadığını görmek için bunu denemeyi düşünmeye değer olduğuna inanmamı sağlıyor.

Tabii ki, sunucularınızı Linux üzerinde çalıştırdığınızı farz ediyorum, bu nedenle bazı işletim sistemlerini pf ile çalıştıran ayrı bir güvenlik duvarı kutusu (OpenBSD veya FreeBSD gibi) olması gerekir. Ayrıca, herhangi bir durumsal paket filtrelemeyi ortadan kaldırarak verimi artırabilirsiniz.

FIB_HASH yerine FIB_TRIE kullanarak araştırma yaptınız mı?

FIB_TRIE, ön ek sayılarınız için çok daha iyi ölçeklendirilmelidir. (/ 32'ler boş yollar hala öneklerdir, sadece çok özeldir)

Kullanmak için kendi çekirdeğinizi derlemeniz gerekebilir, ancak yardımcı olabilir.

FIB_TRIE Notları

Posterity için: ipsetdocs göre bir setin varsayılan boyutu 65536'dır, bu seçeneklerle değiştirilebilir.

maxelem Bu parametre tüm karma tipi setlerinin create komutu için geçerlidir. Sette saklanabilecek azami eleman sayısını belirler, varsayılan 65536. Örnek:ipset create test hash:ip maxelem 2048.

Bunu buraya henüz yorum yapamadığım için koydum.

Gelecekte bu sorunla karşılaşan herkes için bazı faydalı notlar:

Her şeyden önce, ihtiyacınız olmayan hiçbir trafiği analiz etmeyin. Örneğin, TCP trafiğini engelliyorsanız, yalnızca SYN paketlerini filtreleyin, böylece bağlantıya yalnızca bir kez filtre uygulayın. İsterseniz kullanabilirsiniz -m state, ancak bağlantı izlemenin performansın bir sorun olması durumunda önlemek isteyebileceğiniz kendi ek yükü vardır.

İkincisi, bir milyon kuralı iptables içine koymak uzun zaman alıyor: birkaç dakika. Bu kadar fazla varlığı izlemeniz gerekirse, muhtemelen netfliter'dan uzak tutmalısınız. Kuralların büyüklüğü fark yaratır.

Üçüncüsü, amaç doğrusal taramalardan kaçınmaktır; Fakat ne yazık ki, hem iptables hem de iproute2 doğal olarak doğrusaldır. Kurallarınızı ikili ağaç stiline bölerek çok sayıda zincire ayırabilirsiniz, bu da danışmanız gereken kural sayısını sınırlar ancak yine de iptables bu sorun için uygun değildir. İşe yarayacak , ancak değerli kaynakların kaybı.

Dördüncü ve en önemlisi, iş yükünüzü kullanıcı alanına zorlamak kötü bir fikir değil. Bu, kendi sıkı kodunuzu yazmanıza veya problem setinize göre ayarlanmış hazır bir çözüm kullanmanıza olanak sağlar. Bu soruna kendi çözümüm, belirtildiği gibi, apache'nin mod_rewrite sistemi ile tetiklenen BDB aramalarını kullanmaktı. Bu, oturum başına yalnızca bir aramayı tetikleme ve yalnızca geçerli bir istek gönderildikten sonra ek fayda sağlamıştır. Bu durumda, performans son derece hızlıydı ve engelleme listesinin maliyeti neredeyse yok denecek kadar azdı.

-j QUEUEHedefi ile birlikte kullanarak iptables ile benzer kullanıcı alanı işlemlerini yapabilirsiniz libnetfilter_queue. Bu araç, güçlü, basit ve kötü belgelenmiş. Herhangi bir resmi belgenin parçası olmayan, web üzerinde dağılmış çok sayıda ilginç materyal bulunduğundan, bulabildiğiniz kadar kaynaktan okumaya devam etmenizi öneririm.