Linux sunucularının güvenliğini sağlama: iptables vs fail2ban


10

Linux sunucusu güvenliği, özellikle de kaba kuvvet saldırıları ve fail2ban'ı özel iptables'a karşı kullanma konusunda topluluğun beynini seçmek istiyorum .

Orada birkaç benzer soru var, ancak hiçbiri konuyu memnuniyetime hitap etmiyor. Kısacası, internete maruz kalan linux sunucularını (olağan hizmetleri, ssh, web, mail) kaba kuvvet saldırılarından korumak için en iyi çözümü belirlemeye çalışıyorum.

Sunucu güvenliği üzerinde iyi bir tanıtıcı var, yani root veya parola girişlerine izin vermeyerek, varsayılan bağlantı noktasını değiştirerek, yazılımın güncel olmasını sağlayarak, günlük dosyalarını kontrol ederek, yalnızca belirli ana makinelerin sunucuya erişmesine ve güvenlikten yararlanmasına izin vererek ssh'yi kilitliyorum genel güvenlik uyumluluğu için Lynis ( https://cisofy.com/lynis/ ) gibi denetim araçları , bu nedenle girdi ve tavsiye her zaman memnuniyetle karşılansa da , bu soru mutlaka bununla ilgili değildir .

Sorum şu ki hangi çözümü kullanmalıyım (fail2ban veya iptables) ve bunu nasıl yapılandırmalıyım, ya da kaba kuvvet saldırılarına karşı korumak için her ikisinin bir kombinasyonunu kullanmalıyım?

Konu ile ilgili ilginç bir yanıt var ( Denyhosts vs fail2ban vs iptables- kaba kuvvet oturum açmalarını önlemenin en iyi yolu? ). Kişisel olarak benim için en ilginç cevap ( https://serverfault.com/a/128964 ) ve günlük dosyalarını ayrıştırmak için kullanıcı modu araçlarını kullanan fail2ban'ın aksine iptables yönlendirmesinin çekirdekte gerçekleştiğiydi . Fail2ban elbette iptables kullanır, ancak yine de bir eylem gerçekleştirene kadar günlük dosyalarını ayrıştırmak ve bir desen eşleştirmek zorundadır.

IPtables'dan bir süre IP isteklerini bırakmak için iptables ve hız sınırlayıcı ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ) kullanmak mantıklı mı? hangi protokole bağlanmaya çalıştığından bağımsız olarak belirli bir dönemde çok fazla bağlantı denemesi yapar? Eğer öyleyse, oradaki paketler için drop vs ret kullanma hakkında bazı ilginç düşünceler var ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), bununla ilgili herhangi bir düşünce var mı?

Fail2ban , varsayılan yapılandırmada ele alınamayan hizmetler için özel ' kurallar ' yazabilme şeklinde özel yapılandırmaya izin verir . Kurulumu ve kurulumu kolaydır ve güçlüdür, ancak elde etmeye çalıştığım tek şey bir x tutarı üzerinden herhangi bir hizmet / protokolde 2 başarısız erişim denemesi yaparsa bir IP'yi sunucudan ' engellemek ' ise aşırıya kaçabilir mi? zaman?

Buradaki amaç günlük günlük izleme raporlarını açmak ve sunucuya başarısız bağlantı girişimlerinin sayfaları arasında gezinmek zorunda değilsiniz.

Zaman ayırdığınız için teşekkürler.


Yanıtlar:


21

fail2ban veya iptables kullanmalı mıyım?

Bir güvenlik duvarı çözümüne ek olarak fail2ban'ı , isteğe bağlı olarak varolan güvenlik duvarı kurallarını, aksi takdirde kamu hizmetlerinde istenmeyen eylemler gerçekleştiren sistemlerin belirli ip adreslerini engelleme kurallarıyla genişletmek için kullanırsınız . Birbirleriyle uyumlu çalışırlar.

Basitleştirilmiş: bir güvenlik duvarı yalnızca ağ bağlantılarını ve paketleri görür ve buradaki kalıpları bir anlam ifade edebilir, ancak istenen ve geçerli istekleri kötü amaçlı, hatalı biçimlendirilmiş ve istenmeyen isteklerden ayırt etmek için uygulama düzeyinde bilgi sahibi değildir. Örneğin, güvenlik duvarınız bir grup HTTP API isteği ile Wordpress yönetici sayfanızda kaba kuvvet parolası tahmininin neden olduğu bir dizi yanlış giriş denemesi arasındaki farkı söyleyemez, güvenlik duvarına her ikisi de yalnızca 80 veya 443 numaralı bağlantı noktasına TCP bağlantılarıdır.

Fail2ban, dolaylı da olsa, güvenlik duvarınıza uygulama düzeyinde içgörü sağlamak için genel ve genişletilebilir bir yaklaşımdır.
Sıklıkla uygulamalar, kötü niyetli, hatalı biçimlendirilmiş ve istenmeyen istekleri kaydeder ve kaydeder, ancak daha nadiren daha fazla kötüye kullanımı önleme yeteneğine sahip olurlar. Her ne kadar biraz ayrıştırılmış olsa da, Fail2ban o günlüğe kaydedilen kötü amaçlı olaylara göre hareket edebilir ve hasarı sınırlayabilir ve daha fazla kötüye kullanımı önleyebilir, genellikle güvenlik duvarınızı dinamik olarak daha fazla erişimi reddedecek şekilde yeniden yapılandırarak. Başka bir deyişle, Fail2ban mevcut uygulamalarınızı değiştirmeden kötüye kullanımdan kurtulmanın yollarını sunar.

Güvenlik duvarlarına uygulama düzeyinde öngörüler sağlamak için farklı bir yöntem, izinsiz giriş algılama / önleme sistemi olacaktır .


Örneğin, bir web sunucusu ortak bir kamu hizmetidir ve güvenlik duvarınızda 80 ve 443 numaralı TCP bağlantı noktaları genel olarak internete açıktır.
Genellikle, birden çok geçerli kullanıcının bir NAT ağ geçidinin veya bir web proxy'sinin arkasında olduklarında tek bir kaynağı olabileceğinden, HTTP / HTTPS bağlantı noktalarında herhangi bir hız sınırlaması yoktur.

Web sunucunuza yönelik istenmeyen ve / veya kötü amaçlı eylemler algıladığınızda, böyle bir suçlunun engellenmesini otomatikleştirmek için fail2ban kullanırsınız (ya tamamen engelleyin veya yalnızca 80 ve 443 numaralı bağlantı noktalarına erişimlerini kilitleyin).

Öte yandan SSH erişimi bir kamu hizmeti değildir, ancak güvenlik duvarınızdaki SSH erişimini yalnızca beyaz listedeki IP adresi aralıklarıyla sınırlandıracak bir konumda değilseniz, gelen bağlantıları hız sınırlaması kaba davranışı yavaşlatmanın bir yoludur kuvvet saldırıları. Ancak güvenlik duvarınız, kullanıcı bob'u 5 kez başarılı bir şekilde oturum açtığını ve hala bir bot tarafından root olarak oturum açmayı denemediği için 5 kez başarılı bir şekilde ayırt edemediğini gösteriyor.


Aradığım fikir bu, benim için çok mantıklı, zaman ayırdığınız için teşekkürler.
kingmilo

2
Derin paket denetimi gerçekleştirebilen uygulama güvenlik duvarları (uygulama ağ geçitleri olarak da bilinir) olsa da.
gardenhead

@ gardenhead kabul etti ve +1; iptablesOP tarafından belirtilen nedeniyle öncelikle çekirdek içine Linux packetfilter yapı odaklanmıştı. Benim görüşüme göre uygulama güvenlik duvarları paketleri uygulama protokolü farkında oldukça incelemek değil ve tüm isteği incelemek gerekir. Web'de daha sonra
apache'nin

@HBruijn Haklısın - Paket terimini yanlış kullandım. Uygulama ağ geçitlerinin nasıl oluşturulduğunun ayrıntılarını bilmiyorum, ancak inceleme + iletmeden önce eksiksiz bir uygulama katmanı mesajı oluşturmak için yeterli paket almak için beklediklerini hayal ediyorum.
gardenhead

1
Protip: diğer hizmetler için fail2ban kullansanız bile ssh için son iptables modülünü kullanın. Kuralların düzgün bir şekilde temizlenmediği ilginç hata modları olabilir ve bundan etkilenen girişlere sahip olmak gerçekten sinir bozucu olabilir (ve ayrıca sorunun hata ayıklanmasını zorlaştırabilir). Son zamanlarda , gerçek kuralların değişmesi gerekmez, bu yüzden geri erişim şansınız yüksektir.
Simon Richter

8

fail2ban veya iptables kullanmalı mıyım?

Bu biraz "emniyet kemeri mi, araba mı kullanmalıyım?" Diye sormaya benzer.

Öncelikle, fail2ban'ın gerçekten sadece metin dosyalarındaki yinelenen girdileri otomatik olarak algılamak ve belirli bir eşiği karşıladığında bazı komutları yürütmek için bir araç olduğunu unutmayın .

Genellikle, bir politikayı ihlal eden yinelenen günlük girişleriyle kanıtlandığı gibi bazı politikaları ihlal eden ana bilgisayarları engellemek için kullanırız, ancak bunun için kullanabileceğiniz tek şey bu değildir.

Sen edebilirsiniz eklemek için fail2ban kullanmak (ve kaldır) talep üzerine kuralları iptables. Ayrıca iptables kurallarını elle ekleyebilir ve kaldırabilir ya da yanıt olarak tamamen farklı bir şey yapmak için fail2ban kullanabilirsiniz. Her şey onu nasıl yapılandırdığınızla ilgili.

Fail2ban çalıştırıp çalıştırmadığınıza bakılmaksızın genel güvenlik duvarınız olmalıdır. Bu tür bir güvenlik duvarı, örneğin, asla meşru olmayacağını bildiğiniz trafiği (gelen veya giden) engellemek olacaktır. Örneğin, bu veritabanı sunucusunun gerçekten tüm Internet'ten bağlantı noktası 25'te gelen bağlantılarla uğraşması gerekiyor mu?

Bunun da ötesinde, fail2ban'ın ihlal eden IP'leri bir süreliğine keserek politika ihlallerine yanıt vermesi, sunucunuzu kendi başına güvence altına almak için fazla bir şey yapmaz (iyi bir istismarın sadece bir kez güvenlik duvarınızdan geçmesi gerekir), ancak sistem günlükleri dahil ancak bunlarla sınırlı olmamak üzere sisteminizdeki gürültü seviyesini azaltın. Bunu yapmanın basit yolu, çekirdeği paketleri bir süreliğine bırakacak şekilde yapılandırmak için fail2ban iptables'ı çalıştırmaktır. Çevre güvenlik duvarınızı yalnızca ana bilgisayar güvenlik duvarı yerine yeniden yapılandırabiliyorsanız, o zaman çok daha iyidir.

Başka bir deyişle, ilk etapta kolayca ayrılabildikleri ölçüde, her ikisini de istersiniz.

Eğer elde etmeye çalıştığım tek şey balta miktarı üzerinde herhangi bir hizmet / protokol üzerinde 2 başarısız erişim denemesi yaparsanız sunucudan bir IP 'engellemek' için bir overkill olabilir mi?

Bu fail2ban tam olarak çözmek için tasarlanmış kullanım durumudur. Bir aleti kullanım amacı için kullanmak neredeyse hiçbir zaman aşırıya kaçmaz.

Buradaki amaç günlük günlük izleme raporlarını açmak ve sunucuya başarısız bağlantı girişimlerinin sayfaları arasında gezinmek zorunda değilsiniz.

Sorunuzla doğrudan ilgili olmayan bir yana: Günlükleri incelenmek üzere filtrelediğinizde, belirli bir giriş hakkında ne yapacağınızı düşünün. Bir giriş hakkında yapacağınız tek şey "meh" demek ve devam etmekse, muhtemelen filtrelemek istersiniz. Gerekli olması halinde gözden geçirilmek üzere tüm günlükleri kaydettiğinizden emin olun, ancak normal izleme iş akışınıza yalnızca , göründüğünde bir şeyler yapacağınız şeyleri aktarın . Fail2ban'ı birkaç başarısız bağlantı denemesinden sonra bir ana bilgisayarı engelleyecek şekilde ayarlarsanız, bunları manuel olarak incelemeniz gerekmeyebilir ve bunları izleme bildirimlerinizden bırakabilirsiniz. Meşru bir kullanıcı erişim kaybından şikayet ederse, tüm günlükleri çıkarın ve bir göz atın.


Kapsamlı geri bildirimi takdir ediyorum, sanırım ikisini tamamen ayrı işlevlere sahip olarak düşünmedim.
kingmilo

4

Aynı soruyu yıllar önce çözdüm. Performans ve kolay kurulum nedeniyle yeni modüller ile iptables kullanmaya karar verdim. Ana bilgisayarlarda çok sayıda sanal kapsayıcı korumak zorunda kaldım. Kurallarınızla birlikte herhangi bir DOS vektörünü açmamayı unutmayın. Kurallardaki ağ listelerini veya ip listelerini eşleştirmek için ipset'i de kullanın. Beyaz listeler için kullanıyorum. Bir listedeki bir ülkenin tüm ağları ince ayar için mükemmeldir. Ve aynı kurala sahip başka bir hizmeti sadece eşleşecek bir bağlantı noktası daha ekleyerek korumak çok kolaydır. Bu yüzden fail2ban ile değiştirmek istemiyorum ama belki başka ihtiyaçları olan biri fail2ban ile mutlu olacaktır.

İşte bazı örnek:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

Günlük iletilerinizin çıktıları fail2ban ile birleştirilebilir. INPUT kuralları için de kullanabilirsiniz.

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.