Kaba kuvvet SSH saldırılarını engellemek için çeşitli yöntemlerin artıları / eksileri nelerdir?

Sisteminizde kaba kuvvet SSH saldırılarının başlatıldığı IP'leri kapatmak için bir dizi farklı paket var. Örneğin:

Bunların veya başkalarının artıları / eksileri nelerdir?

Şu anki çözümüm, logwatch'ın her gün oluşturduğu e-postayı almak ve korkunç IP adreslerini, daha sonra iptables'ı yeniden oluşturan bir komut dosyasına beslediğim bir metin dosyasına dökmek. Keskin, zaman alıcı ve manuel ve daha iyi bir yol istiyorum.

(Sorunu çözmek için "en iyi" yolun ne olduğunu sormadım, çünkü hiçbir şey yapmanın "en iyi" yolu yok.)

ssh security

— Andy Lester
kaynak

Yanıtlar:

DenyHosts kullanıyorum, bu yüzden en azından bunun için cevap verebilirim:

Artıları

Tamamen otomatik
Yapılandırılabilir (kara listeye alınmadan önce kaç başarısız deneme, mevcut olmayan kullanıcı adları, mevcut kullanıcı adları ve kök için özel bir giriş)
Size düzenli olarak yeni kara listeye alınan ana bilgisayarların bir listesi ile e-posta gönderebilir ve / veya her yeni ana bilgisayar kara listeye alındığında belirli bir programı çalıştırabilir
Bir süre sonra ana bilgisayarların kara listeden çıkarılmasını otomatik olarak destekler

Eksileri

Doğru kullandığınız sürece onarılamaz eksilerim yok:

Varsayılan yapılandırmasında yeni kara listeye alınan ana bilgisayarlara karşı sizi uyarmaz, bu nedenle birileri ağınıza yüzlerce farklı adresten saldırıyorsa, günlüklerinizi manuel olarak izliyorsanız hemen fark edemeyebilirsiniz, ancak ( artıları bölümü) size e-posta gönderebilir veya yeni ana bilgisayarlar eklendiğinde sizi uyarmak için bir yürütülebilir dosya çalıştırabilir
Varsayılan olarak, ana bilgisayarlarınızı diğerleriyle aynı şekilde kara listeye alacaktır, bu nedenle muhtemelen bunları eklemek istersiniz /etc/hosts.allow. Şifremi yazarken bir kez kendimi kilitledim ve işten biri bir şaka olarak root hesabımla giriş yapmaya çalıştı ve iş IP'mi kara listeye aldı ve neden birdenbire bağlanamadığımı anlamak birkaç günümü aldı artık işten ağıma

— Michael Mrozek
kaynak

Bir diğeri iptables (yani sadece ssh ile değil, herhangi bir hizmet ile çalışır) güvenen fail2ban olduğunu. Fail2ban ile şunları yapabilirsiniz:

Herhangi bir günlük dosyasının yolunu belirtin (apache, ssh, nginx, posta sunucusu, ...).
Saldırı modelleri için normal ifadeyi belirtin (örn. 6 saniyede nginx erişim günlüğünde aynı ip tarafından 10'dan fazla "404 hatası")
Belirli kalıpları yoksaymak için normal ifadeyi belirtin (çok faydalı!)
Yasak süresini belirtin
E-posta gönderin (veya başka bir uyarı gönderin ...)
Tamamen özelleştirilebilir (kendi uyarılarınızı ve filtrelerinizi yazabilirsiniz)

DenyHosts'un bir "dezavantajı", tcp sarmalayıcıları gerektirmesidir, bu nedenle yalnızca /etc/hosts.deny dosyasına bakan hizmetlerle çalışır. Ancak DenyHosts ile adil olmak gerekirse, sshd çoğu Linux dağıtımında TCP Sarmalayıcılarını kullanmak üzere derlenmiştir. Ayrıca DenyHosts'u fail2ban'dan (ancak daha az güçlü) daha kolay yapılandırmak için buluyorum.

Benzer bir SF sorusuna referans

— Barthelemy
kaynak

fail2ban, neyse ki, aynı zamanda pf ile çalışır - sadece iptables değil

— Good Person

Tarama tabanlı saldırılara karşı basit ve pratikte etkili bir koruma, standart bağlantı noktasını kullanmak değildir. 443 (https bağlantı noktası) sizi zayıf parolalarınızı kırmayacak farklı kaba kuvvet saldırılarına maruz bırakır ve muhtemelen varsayılan bağlantı noktasından daha fazla güvenlik duvarı üzerinden çalışır (22).

SSH kaba kuvvet saldırılarını önlemek için çoğu yöntem, kendi kendine DoS (ayy, yapılandırmayı berbat ettim!) İçin harika yollardır. Hata! , saldırgan benimle aynı alt ağda (dinamik IP aralığı, kolej ağı ...) bir makineyi devirdi / bozdu ve ben de yasaklanıyorum!).

Yalnızca birkaç yerden oturum açarsanız, kaynak IP adreslerini beyaz listeye ekleyebilirsiniz. Açıkçası hareket halindeyken dizüstü veya cep telefonunuzdan ssh istiyorsanız iyi değil.

Yalnızca IPv6 bağlantılarını dinleyen bir ssh arka plan programına sahip olmak, sizi birkaç yıl boyunca taramalardan korumalıdır. Ancak birçok güvenlik duvarı IPv6'yı makul bir şekilde taşımanıza izin vermez.

Bahsetmediğiniz başka bir yöntem de port çalmadır . Kendi kendine DoS sorunları (yanlış yapılandırma dışında) sorunu yaşamaz, ancak güvenlik duvarlarını iyi geçmez ve bağlantı kurulmasına birkaç saniye gecikme ekleyebilir.

İyi şifreleriniz varsa veya şifre doğrulaması olmadan yaşayabiliyorsanız, şifre doğrulamayı devre dışı bırakın. (Anahtarlar ve bir kerelik parolalar çoğu kullanım durumu için yeterlidir: istemci makineye bir ssh anahtarı depolayacak kadar güvenmiyorsanız, aynı zamanda bir keylogger'a sahip olmadığına da güvenmezsiniz). O zaman kaba kuvvet saldırıları size biraz CPU ve bant genişliğine mal olacak, ancak sizi bir saldırıya maruz bırakmayacaktır (anahtarlarınızdan hiçbirinin Debian düşük entropi OpenSSL'den gelmediğini kontrol ettiğiniz sürece ).

Sonuç olarak, bağlantı noktasını değiştirmenin pozunuzu önemli ölçüde azaltmadığını unutmayın. Daha az tarama elde edersiniz , ancak kesebileceğiniz tek şey, eski güvenlik açıklarından ve zayıf parolalardan yararlanmaya çalışan düşük asılı meyvedir. Daemon'unuzu güncel tuttuğunuz ve makul parolalar veya makul deneme hızı sınırları uyguladığınız sürece, bağlantı noktasını değiştirmek bir güvenlik önleminden daha fazla sorumluluk taşır.

— Gilles 'SO- şeytan olmayı bırak'
kaynak

Kendinizi yasaklamamanız için bazı uygulamalar gerektiğini kabul ediyorum ;-) Varsayılan bağlantı noktalarını değiştirmek ve bir parolaya güvenmemek, ancak parola korumalı bir anahtara da iyi bir tavsiye. Ancak ssh ve web sunucumun saatte binlerce isteği reddetmesi gerekirken bot ağlarının neden erişim günlük dosyalarımı doldurmasına izin vermem gerektiğini bilmiyorum. Fail2ban ile, erişim günlüğüm temiz ve sunucu uygulamalarım bu trafiği hiç görmüyor (ilk X hatalı istekleri hariç :-)).

— Barthelemy

Standart olmayan bir bağlantı noktası kullanmak çok fazla koruma sağlamaz. Standart olmayan bir bağlantı noktasında SSH taraması, bağlantı noktası 22'deki SSH taramasından sadece birkaç dakika daha sürer (Kırıcının bir tarama yaptığını ve taramanın bir IDS tarafından engellenmediğini varsayarsak. Ancak bir IDS'niz varsa, bağlantı noktası gizleme muhtemelen gereksizdir. ). Eğer bir kraker olsaydım ve SSH'yi standart olmayan bir bağlantı noktasında bulduysam, daha da ilgilenirim çünkü yöneticinin bu hizmetin gizlenecek kadar değerli olduğunu düşündüğünü ve belirsizliğe göre güvenliğe güvendiğini biliyorum.

— Stefan Lasiewski

@Stefan: Saldırıların çoğu belirli bir sunucuya karşı değil, belirli bir hizmete karşıdır. Bunun için, birçok adresteki tek bir bağlantı noktasını taramak her adresteki birçok bağlantı noktasından daha etkilidir. Ve aslında sizi hedefleyen bir saldırgan varsa, daha iyi bilirsiniz, bu yüzden güçlü veya yasaklanmış şifrelerin ve saldırıların günlüğe kaydedilmesini istersiniz.

— Gilles 'SO- kötü olmayı kes

@Stefan Standart dışı bağlantı noktalarını, gerçekte bir güvenlik önlemi olarak (yani, birisinin sunucumun kontrolünü ele geçirmesini engelleme) değil, sıkıntıya karşı etkili bir çözüm (kaba kuvvet taramaları) olarak görüyorum.

— Barthelemy

@sudowned Farklı bir bağlantı noktası belirtmek zor bir durum. Sadece bir satır .ssh/config. Güvenlik duvarı size izin vermiyorsa kilitleme bir sorundur ve en kolay çözüm port 22'ye bağlı kalmak ve aynı zamanda 443'ü dinlemek olacaktır. . Bir SSH arka plan programının parola kimlik doğrulamasını desteklememesinin neden imkansız olduğunu düşündüğünüzü bilmiyorum: Bu sadece sshd_configen yaygın uygulama olan OpenSSH'ye bir satır eklemek meselesidir .

— Gilles 'SO- şeytan olmayı bırak'