En iyi Dağıtılmış Kaba Kuvvet önlemi nedir?

İlk olarak, küçük bir arka plan: CodeIgniter için bir auth + auth sistemi uyguladığım bir sır değil ve şimdiye kadar kazanıyorum (tabiri caizse). Ama oldukça önemsiz bir meydan okumayla karşılaştım (çoğu yetkilendirme kütüphanesinin tamamen özlediği, ancak düzgün bir şekilde idare etmede ısrar ediyorum): büyük ölçekli, dağıtılmış, değişken kullanıcı adı kaba kuvvet saldırılarıyla akıllıca nasıl başa çıkacağım .

Bütün olağan hileleri biliyorum:

1. IP / ana bilgisayar başına başarısız deneme sayısını sınırlama ve suçluların erişimini reddetme (örn. Fail2Ban) - botnet'ler daha akıllı büyüdüğü için artık çalışmaz
2. Yukarıdakileri bilinen 'kötü' IP'lerin / ana bilgisayarların (örn. DenyHosts) bir kara listesiyle birleştirmek - bu da giderek artan bir şekilde 1. sıraya düşmeyen botnetlere dayanıyor
3. Geleneksel kimlik doğrulamasıyla birleştirilmiş IP / ana bilgisayar beyaz listeleri (ne yazık ki dinamik IP kullanıcıları ve çoğu web sitesinde yüksek karmaşa ile işe yaramaz)
4. N dakika / saat içinde başarısız denemelerin sayısı için bir site sınırı sınırı ayarlamak ve bundan sonraki tüm giriş denemelerini birkaç dakika / saat boyunca kısmak (askıya almak) (DoS'a saldıran sorun botnet çocuk oyuncağı haline gelir)
5. Giriş / şifre seçeneği YOK olan tüm kullanıcılar için zorunlu dijital imzalar (ortak anahtar sertifikaları) veya RSA donanım belirteçleri (şüphesiz çok sağlam bir çözüm, ancak yalnızca kapalı, özel hizmetler için pratik)
6. Zorlanmış ultra güçlü şifre şemaları (örneğin, sembollerle 25 saçma karakter - yine sıradan kullanıcılar için çok pratik değildir)
7. Ve son olarak, CAPTCHA'lar (çoğu durumda işe yarayabilir, ancak kullanıcılar için can sıkıcıdır ve kararlı, becerikli bir saldırgana karşı neredeyse işe yaramaz )

Şimdi, bunlar sadece teorik olarak uygulanabilir fikirler. Orada bol (önemsiz DoS saldırılarına örneğin) tamamen açık siteyi darbe çöp fikirlerin. İstediğim daha iyi bir şey. Ve daha iyisi, yani:

• DoS ve kaba kuvvet saldırılarına karşı güvenli (+) olmalı ve biraz sinsi bir botun radar altında çalışmaya devam etmesine izin verebilecek yeni güvenlik açıkları getirmemelidir.

• Otomatikleştirilmesi gerekiyor. Bir insan operatörünün her girişi doğrulaması veya şüpheli etkinliği izlemesi gerekiyorsa, gerçek dünya senaryosunda çalışmayacaktır.

• Yaygın web kullanımı için uygun olmalıdır (ör. Programcı olmayanlar tarafından gerçekleştirilebilen yüksek karmaşa, yüksek hacimli ve açık kayıt)

• Kullanıcı deneyimini, sıradan kullanıcıların rahatsız olacağı veya sinirleneceği (ve potansiyel olarak siteyi terk edeceği) noktaya engelleyemez.

• Gerçekten güvenli yavru kedi olmadıkça, yavru kedi içeremez.

(+) 'Güvenli' demekle, en azından paranoyak bir kullanıcının şifresini gizli tutma becerisi kadar güvenli

Öyleyse - hadi duyalım! Bunu nasıl yapardın ? Bahsetmediğim en iyi uygulamayı biliyor musun (oh lütfen söylediğini söyle)? Kendime ait bir fikrim olduğunu itiraf ediyorum (3 ve 4'ten gelen fikirleri birleştirerek), ama gerçek uzmanların kendimi utandırmadan önce konuşmasına izin vereceğim ;-)

Tamam, yeterince durma; işte şu ana kadar bulduğum şey

(üzgünüm, uzun mesaj önde. Cesur ol arkadaşım, yolculuk buna değecek)

Orijinal postadan yöntem 3 ve 4'ü bir tür 'bulanık' veya dinamik beyaz listeye birleştirin ve sonra - ve işte burada - beyaz listeye alınmamış IP'leri engellememek, sadece cehenneme ve arkaya sıkıştırmak .

Bu önlemin yalnızca bu çok spesifik saldırı türünü önlemeye yönelik olduğunu unutmayın. Uygulamada, elbette, otantikliğe yönelik diğer en iyi uygulamalar yaklaşımlarıyla birlikte çalışır: sabit kullanıcı adı azaltma, IP başına azaltma, kod tarafından zorlanan güçlü şifre politikası, kontrolsüz çerez girişi, onları kaydetmeden önce tüm şifre eşdeğerlerini hash etme, asla güvenlik soruları vb. kullanma

Saldırı senaryosu ile ilgili varsayımlar

Bir saldırgan değişken kullanıcı adlarını hedefliyorsa, kullanıcı adımız kısıtlamamız tetiklenmez. Saldırgan bir botnet kullanıyorsa veya geniş bir IP aralığına erişiyorsa, IP azaltma güçsüzdür. Saldırgan, kullanıcı listemizi önceden kazıdıysa (genellikle açık kayıt web hizmetlerinde mümkündür), 'kullanıcı bulunamadı' hatalarının sayısına dayalı olarak devam eden bir saldırı tespit edemeyiz. Kısıtlı bir sistem çapında (tüm kullanıcı adları, tüm IP'ler) daraltmayı zorlarsak, bu tür saldırılar tüm sitemizi saldırı süresi ve azaltma süresi boyunca DoS yapar.

Bu yüzden başka bir şey yapmalıyız.

Karşı önlemin ilk kısmı: Beyaz liste

Oldukça emin olabileceğimiz şey, saldırganın binlerce kullanıcının (+) IP adreslerini tespit edememesi ve dinamik olarak aldatmamasıdır. Bu da beyaz listeyi uygulanabilir kılar . Başka bir deyişle: her kullanıcı için, kullanıcının daha önce (son zamanlarda) oturum açtığı (karma) IP'lerin bir listesini saklarız.

Böylece, beyaz liste şemamız kilitli bir 'ön kapı' olarak işlev görecektir; burada kullanıcının giriş yapmak için tanınmış 'iyi' IP'lerinden birine bağlanması gerekir. Bu 'ön kapıya' kaba kuvvet saldırısı neredeyse imkansız olurdu (+).

(+) saldırgan sunucuya, tüm kullanıcılarımızın kutularına veya bağlantının kendisine 'sahip' değilse ve bu durumlarda artık bir 'kimlik doğrulama' sorunumuz yoksa, gerçek bir franchise boyutunda çekme -plug FUBAR durumu

Karşı önlemin ikinci kısmı: Tanınmayan IP'lerin sistem genelinde kısılması

Kullanıcıların bilgisayarları sık sık değiştirdiği ve / veya dinamik IP adreslerinden bağlandığı bir açık kayıt web hizmetinde beyaz listenin çalışması için, tanınmayan IP'lerden bağlanan kullanıcılar için bir 'kedi kapısını' açık tutmamız gerekir. İşin püf noktası, kapıyı botnetlerin sıkışıp kalması ve meşru kullanıcıların mümkün olduğunca az rahatsız olması için tasarlamak .

Şemamda, bu, onaylanmamış IP'ler tarafından, örneğin 3 saatlik bir süre boyunca (hizmet türüne bağlı olarak daha kısa veya daha uzun bir süre kullanmak daha akıllıca olabilir) çok kısıtlayıcı bir maksimum başarısız giriş denemesi sayısı ayarlanarak elde edilir ve bu kısıtlamayı küresel hale getirmek , yani. tüm kullanıcı hesapları için.

Yavaş (denemeler arasında 1-2 dakika) kaba kuvvet bile bu yöntem kullanılarak hızlı ve etkili bir şekilde tespit edilir ve engellenir. Tabii ki, gerçekten yavaş bir kaba kuvvet hala fark edilmeden kalabilir, ancak çok yavaş hızlar kaba kuvvet saldırısının amacını yener.

Bu azaltma mekanizması ile başarmayı umduğum, maksimum sınıra ulaşıldığında, 'kedi kapısı' çarpmalarının bir süre kapalı kalması, ancak ön kapımızın normal yollarla bağlanan meşru kullanıcılara açık kalmasıdır:

• Ya tanınan IP'lerinden birinden bağlanarak
• Veya kalıcı bir giriş çerezi kullanarak (her yerden)

Saldırı sırasında etkilenecek tek meşru kullanıcı - yani. kısıtlama etkinleştirildiğinde - bilinmeyen bir yerden veya dinamik bir IP ile giriş yapan kalıcı giriş çerezleri olmayan kullanıcılar olurdu. Bu kullanıcılar azaltma bitene kadar giriş yapamazlar (saldırganın azaltmaya rağmen botnetini çalışır tutması durumunda bu biraz zaman alabilir).

Bu küçük kullanıcı alt kümesinin, aksi halde kapalı kedi kapısından sıkılmasına izin vermek için, botlar hala çarpıyor olsa bile, bir CAPTCHA ile 'yedek' giriş formu kullanacağım. Böylece, "Üzgünüz, ancak şu anda bu IP adresinden giriş yapamıyorsunuz" mesajını görüntülediğinizde, " güvenli yedekleme girişi - YALNIZCA HUMANS ( botlar: yalan söyleme ) " yazan bir bağlantı ekleyin . Şaka bir yana, bu bağlantıyı tıkladıklarında, onlara site genelinde azaltmayı atlayan bir reCAPTCHA kimlik doğrulamalı giriş formu verin. Bu şekilde, eğer insan ise VE doğru giriş + şifresini biliyorlarsa (ve CAPTCHA'ları okuyabilirlerse), bilinmeyen bir ana bilgisayardan bağlanıp otomatik oturum açma çerezini kullanmasalar bile asla reddedilmezler.

Oh, ve sadece açıklığa kavuşturmak için: CAPTCHA'ların genel olarak kötü olduğunu düşündüğüm için, 'yedekleme' giriş seçeneği sadece azaltma etkinken görünecektir .

Bunun gibi sürekli bir saldırının hala bir tür DoS saldırısı teşkil edeceğini inkar etmek mümkün değildir, ancak açıklanan sistem yerinde olduğunda, yalnızca küçük bir kullanıcı alt kümesi olduğundan, yani "beni hatırla" kurabiyesi VE bir saldırı olurken giriş yapıyor VE her zamanki IP'lerinden giriş yapmıyor VE CAPTCHA'ları okuyamıyor. Bot saldırısı sırasında sadece bu kriterlerin TÜMÜNE hayır diyebilenler, özellikle botlar ve gerçekten şanssız engelli insanlar geri çevrilecek.

DÜZENLEME: Aslında, CAPTCHA meydan okumalı kullanıcıların bile bir 'kilitlenme' sırasında geçmesine izin vermenin bir yolunu düşündüm: Yedek CAPTCHA girişinin yerine veya ek olarak, kullanıcıya tek kullanımlık bir seçenek sunma , e-postasına gönderilen ve daha sonra daralmayı atlamak için kullanabileceği kullanıcıya özel kilitleme kodu. Bu kesinlikle 'rahatsızlık' eşiğimi aşıyor, ancak sadece küçük bir kullanıcı alt kümesi için son çare olarak kullanıldığından ve hesabınızdan kilitlenmeyi hala devirdiğinden, kabul edilebilir.

(Ayrıca, saldırının burada açıkladığım kötü dağıtılmış sürümden daha az karmaşık olması durumunda bunların hiçbirinin gerçekleşmeyeceğini unutmayın . Saldırı sadece birkaç IP'den geliyorsa veya sadece birkaç kullanıcı adına isabet ediyorsa, çok daha önce engellenecektir ve site genelinde sonuçları olmadan )

Bu, sağlam olduğuna ve kaçırdığım çok daha basit bir çözüm olmadığına ikna olduktan sonra, kimlik doğrulaması kütüphanemde uygulayacağım karşı önlem. Gerçek şu ki, güvenlikte yanlış şeyler yapmanın pek çok ince yolu var ve yanlış varsayımlar yapmanın veya umutsuzca kusurlu mantık yapmanın üstünde değilim. Bu nedenle, lütfen, herhangi bir geri bildirim, eleştiri ve iyileştirme, incelik vb. Çok takdir edilmektedir.

Birkaç basit adım:

Bazı yaygın kullanıcı adlarını kara listeye alın ve bunları bal küpü olarak kullanın. Yönetici, misafir vb. Kimsenin bu adlara sahip hesaplar oluşturmasına izin vermeyin, bu nedenle birisi onları giriş yapmaya çalışırsa, yapmaması gereken bir şey yaptığını bilir.

Sitede gerçek güce sahip olan herkesin güvenli bir parolaya sahip olduğundan emin olun. Yöneticilerin / moderatörlerin harf, sayı ve sembol karışımı ile daha uzun şifreleri olmasını isteyin. Bir açıklama ile normal kullanıcılardan önemsiz derecede basit şifreleri reddedin.

Yapabileceğiniz en basit şeylerden biri, birileri hesaplarına giriş yapmaya çalıştığında insanlara söylemek ve onlara olmasa olayı bildirmeleri için bir bağlantı vermek. "Birisi hesabınıza 4: 20'de Çarşamba falan giriş yapmaya çalıştı. Bu siz değilseniz, burayı tıklayın." Saldırılarla ilgili bazı istatistikleri tutmanıza izin verir. Sahte erişimde ani bir artış olduğunu görürseniz, izleme ve güvenlik önlemlerini artırabilirsiniz.

Kaba kuvvet saldırılarının MO'sunu doğru bir şekilde anlarsam, bir veya daha fazla kullanıcı adı sürekli olarak denenir.

Henüz burada gördüğümü düşünmediğim iki öneri var:

• Her zaman standart uygulamanın her kullanıcı için her yanlış girişten sonra kısa bir gecikme (bir saniye ya da daha fazla) olması gerektiğini düşündüm. Bu kaba kuvveti etkiliyor ama bir saniyelik gecikmenin sözlük saldırısını ne kadar süre uzak tutacağını bilmiyorum. (10.000 kelimelik sözlük == 10.000 saniye == yaklaşık 3 saat. Hmm. Yeterince iyi değil.)
• site genelinde yavaşlama yerine, neden kullanıcı adı kısma olmasın. Gaz kelebeği her yanlış girişimde giderek daha sert hale geliyor (bir sınıra kadar, sanırım gerçek kullanıcı hala giriş yapabilir)

Düzenleme : Bir kullanıcı adı gaz kelebeği hakkındaki yorumlara yanıt olarak: Bu, saldırının kaynağına bakılmaksızın kullanıcı adına özel bir gaz kelebeği.

Kullanıcı adı kısıtlanırsa, koordineli bir kullanıcı adı saldırısı (çoklu IP, IP başına tek tahmin, aynı kullanıcı adı) bile yakalanır. Saldırganlar zaman aşımı sırasında başka bir kullanıcı / geçiş denemekte özgür olsalar da bireysel kullanıcı adları gazla korunur.

Saldırganların bakış açısından, zaman aşımı sırasında 100 şifreyi ilk kez tahmin edebilir ve hesap başına bir yanlış şifreyi hızlı bir şekilde keşfedebilirsiniz. Aynı süre boyunca yalnızca 50 saniyelik tahminler yapabilirsiniz.

Bir kullanıcı hesabı açısından bakıldığında, tahminler birden fazla kaynaktan geliyor olsa bile, şifreyi kırmak için aynı ortalama tahmin sayısını almaya devam eder.

Saldırganlar için, en iyi ihtimalle, 1 hesabı olduğu gibi 100 hesabı kırmakla aynı çaba gösterilecektir, ancak site çapında temelde kısıtlama yapmadığınızdan, kelebeği oldukça hızlı bir şekilde artırabilirsiniz.

Ek ayrıntılandırmalar:

• birden fazla hesabı tahmin eden IP'leri algılama - 408 İstek Zaman Aşımı
• aynı hesabı tahmin eden IP'leri tespit eder - 408 Çok sayıda (100 diyelim) tahminden sonra Zaman Aşımı İste.

Yukarıdakileri de iyileştirebilen UI fikirleri (bu bağlamda uygun olmayabilir):

• Eğer şifre ayarını kontrol ediyorsanız, kullanıcıya şifrelerinin ne kadar güçlü olduğunu göstermek onları daha iyi bir şifre seçmeye teşvik eder.
• giriş sayfasını kontrol ediyorsanız , tek bir kullanıcı adının az sayıda (10 diyelim) tahmininden sonra bir CAPTCHA sunun.

Üç kimlik doğrulama faktörü vardır:

1. Kullanıcı bir şey biliyor (yani bir şifre)
2. Bir kullanıcı sahiptir şey (yani bir anahtarlık)
3. Kullanıcı bir şeydir (yani retina taraması)

Genellikle, web siteleri yalnızca 1 numaralı politikayı uygular. Çoğu banka bile sadece 1. politikayı uygular. Bunun yerine iki faktörlü kimlik doğrulamaya "başka bir şey bilir" yaklaşımına güvenirler. (IE: Bir kullanıcı şifresini ve annesinin kızlık soyadını biliyor.) Eğer yapabiliyorsanız, ikinci bir kimlik doğrulama faktörü eklemenin bir yolu çok zor değildir.

Yaklaşık 256 rasgele karakter üretebiliyorsanız, bunu 16 × 16 tablosunda yapılandırabilir ve daha sonra kullanıcıdan örneğin A-14 hücresi tablosundaki değeri vermesini isteyebilirsiniz. Bir kullanıcı kaydolduğunda veya parolasını değiştirdiğinde, tabloyu verin ve yazdırmasını ve kaydetmesini isteyin.

Bu yaklaşımın zorluğu, bir kullanıcı şifresini unuttuğunda, olacağı gibi, sadece "bu soruyu cevapla ve yeni bir şifre gir" standardını sunamazsınız, çünkü bu da kaba kuvvete karşı savunmasızdır. Ayrıca, e-postaları da tehlikeye atılabileceğinden sıfırlayamaz ve onlara yeni bir e-posta gönderemezsiniz. (Bkz: Makeuseof.com ve çalınan alanları.)

Başka bir fikir (yavru kediler içerir), BOA SiteKey (adın ticari marka inanıyorum) dediğimiz şeydir. Kısaca, kullanıcının kayıt olurken bir resim yüklemesini sağlayın ve giriş yapmaya çalıştıklarında, 8 veya 15 (veya daha fazla) rasgele görüntüyü seçmelerini isteyin. Yani, bir kullanıcı yavru kedisinin bir resmini yüklerse, teorik olarak sadece hangi resmin tüm diğer yavru kedilerden (veya çiçeklerden ya da her neyse) tam olarak olduğunu bilir. Bu yaklaşımın sahip olduğu tek gerçek saldırganlık ortadaki adam saldırısıdır.

Bir fikir daha (yavru kedi yok), kullanıcıların sisteme eriştiği IP'leri izlemek ve sahip oldukları bir adresten giriş yaptıklarında ek kimlik doğrulama (captcha, bir kedicik seç, bu tablodan bir anahtar seç) daha önce değil. Ayrıca, GMail'e benzer şekilde, kullanıcının son oturum açtığı yeri görüntülemesine izin verin.

Düzenleme, Yeni Fikir:

Giriş denemelerini doğrulamanın başka bir yolu, kullanıcının giriş sayfanızdan gelip gelmediğini kontrol etmektir. Yönlendiricileri kontrol edemezsiniz, çünkü kolayca taklit edilebilirler. İhtiyacınız olan şey, kullanıcı giriş sayfasını görüntülediğinde _SESSION var'da bir anahtar ayarlamak ve ardından giriş bilgilerini gönderirken anahtarın var olup olmadığını kontrol etmektir. Bot giriş sayfasından gönderilmezse giriş yapamaz. Bunu, bir çerez ayarlamak için kullanarak veya forma yüklendikten sonra forma bazı bilgiler ekleyerek javascript'i sürece dahil ederek de kolaylaştırabilirsiniz. Veya formu iki farklı alt bölüme bölebilirsiniz (yani kullanıcı kullanıcı adını girer, gönderir, ardından yeni bir sayfada şifresini girip tekrar gönderir.)

Bu durumda anahtar en önemli husustur. Bunları oluşturmanın yaygın bir yöntemi, kullanıcı verilerinin, IP'lerinin ve gönderildiği zamanın bir kombinasyonudur.

Daha önce PHP'de kullanıcı giriş denemelerini nasıl kısabilirim konusunda çok benzer bir soruya cevap vermiştim . Birçoğunuzun gerçek kodu görmek için bilgilendirici ve yararlı bulacağına inandığım için burada önerilen çözümü tekrarlayacağım. Günümüzde CAPTCHA busters'larında kullanılan giderek daha doğru algoritmalar nedeniyle CAPTCHA kullanımının en iyi çözüm olmayabileceğini lütfen unutmayın:

Kısıtlamayı tek bir IP veya kullanıcı adına zincirleyerek DoS saldırılarını önleyemezsiniz. Cehennem, bu yöntemi kullanarak hızlı giriş girişimlerini gerçekten engelleyemezsiniz.

Neden? Çünkü saldırı, azaltma girişimlerinizi atlamak için birden fazla IP'ye ve kullanıcı hesabına yayılabilir.

İdeal olarak, sitedeki tüm başarısız giriş denemelerini izlemeniz ve bunları bir zaman damgasıyla ilişkilendirmeniz gerektiğini fark ettim:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Belirli bir sürede toplam başarısız oturum açma sayısına göre belirli gecikmelere karar verin . Bunu, failed_loginstablonuzdan alınan istatistiki verilere dayandırmalısınız, çünkü kullanıcı sayısına ve kaçının şifresini hatırlayabildiğine (ve yazabileceğine) bağlı olarak zamanla değişecektir .

10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Belirli bir süre boyunca başarısız oturum açma sayısını bulmak için her başarısız oturum açma girişiminde tabloyu sorgulayın, 15 dakika deyin:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Belirli bir zaman dilimi içindeki deneme sayısı sınırınızı aşarsa, ya da kısıtlamayı zorlayın ya da belirli bir süre zarfında başarısız deneme sayısı eşik değerinden daha az olana kadar tüm kullanıcıları bir captcha (reCaptcha) kullanmaya zorlayın.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

ReCaptcha'yı belirli bir eşikte kullanmak, birden fazla cepheden bir saldırının en aza indirilmesini ve normal site kullanıcılarının meşru başarısız oturum açma girişimleri için önemli bir gecikme yaşamamasını sağlayacaktır. Önleme konusunda garanti veremem, çünkü CAPTCHA'ların yakalanabileceği zaten genişletildi. Alternatif çözümler, belki de "Bu hayvanı adlandır" ın bir varyantı olarak iyi çalışabilen bir çeşidi vardır.

Bu sorunun maliyet-fayda analizini yapıp yapmadığınızı sormak zorundayım; Kendinizi bir dizi şifreyi tahmin etmek için yeterli web varlığına sahip bir saldırgandan korumaya çalıştığınız anlaşılıyor, IP başına belki 3-5 istek gönderiyor (IP azaltmayı reddettiğinizden). Bu tür saldırıların maliyeti (kabaca) ne kadardır? Korumak istediğiniz hesapların değerinden daha mı pahalı? Kaç tane devasa botnet sahip olduğunuzu istiyor?

Cevap hayır olabilir - ama eğer öyleyse, umarım bir çeşit güvenlik uzmanından yardım alırsınız; programlama becerisi (ve StackOverflow skoru) güvenlik teknik bilgisi ile güçlü bir korelasyon göstermez.

Jens'in şemasını sözde durum geçiş şeması / rulebase olarak özetlemek için:

1. kullanıcı + şifre -> giriş
2. kullanıcı +! şifresi -> reddedildi
3. kullanıcı + bilinen_IP (kullanıcı) -> ön kapı, // never throttle
4. kullanıcı + unknown_IP (kullanıcı) -> catflap
5. (#denied> n) catflaps aracılığıyla (site) -> gaz kelebeği catflaps (site) // slow the bots
6. catflap + gaz kelebeği + şifre + captcha -> giriş // humans still welcome
7. catflap + gaz + şifre +! captcha -> reddedildi // a correct guess from a bot

Gözlemler:

• Asla ön kapağı kısmayın. Elbonian eyalet polisi bilgisayarınızın evinizde olmasına rağmen sizi sorgulayamıyor. Kaba kuvvet, bilgisayarınızdan uygulanabilir bir yaklaşımdır.
• "Parolanızı mı unuttunuz?" bağlantısını tıklarsanız, e-posta hesabınız saldırı yüzeyinin bir parçası olur.

Bu gözlemler, karşı koymaya çalıştığınız kişilere farklı bir saldırı türünü kapsar.

Görünüşe göre yavaş dağıtılmış kaba kuvvete karşı savunmaya çalışıyorsunuz . Bu konuda yapabileceğiniz kadar değil. PKI kullanıyoruz ve şifre girişi yok. Bu yardımcı olur, ancak müşterileriniz arada bir iş istasyonları şansı veriyorsa, bu çok geçerli değildir.

Feragatname: İki faktörlü bir şirkette çalışıyorum, ancak buraya takmak için burada değilim. İşte bazı gözlemler.

Çerezler XSS ve tarayıcı vulnsları ile çalınabilir. Kullanıcılar genellikle tarayıcıları değiştirir veya çerezlerini temizler.

Kaynak IP adresleri aynı anda dinamik olarak değişken ve taklit edilebilir.

Captcha yararlıdır, ancak belirli bir insanın kimliğini doğrulamaz.

Birden çok yöntem başarılı bir şekilde birleştirilebilir, ancak iyi tat kesinlikle sıra ile.

Parola karmaşıklığı iyidir, parola tabanlı her şey kritik olarak yeterli entropiye sahip parolalara bağlıdır. IMHO, güvenli bir fiziksel yere yazılan güçlü bir parola, bellekteki zayıf bir paroladan daha iyidir. İnsanlar, üç farklı web sitesi için şifre olarak kullanıldıklarında, kağıt belgelerin güvenliğini köpeklerinin adındaki etkili entropiyi nasıl anlayacaklarını çok daha iyi değerlendirebilirler. Kullanıcılara bir kerelik kullanım kodlarıyla dolu büyük veya küçük bir sayfa yazdırma olanağı vermeyi düşünün.

“Lise maskotunuz neydi” gibi güvenlik soruları çoğunlukla “bildiğiniz bir şeyin” başka bir berbat biçimidir, çoğu kamuya açık bir şekilde kolayca tahmin edilebilir veya açıktır.

Belirttiğiniz gibi, başarısız giriş denemelerini kısmak kaba kuvvet saldırılarını önleme ile DoSing hesabını kolaylaştırma arasında bir değiş tokuştur. Agresif kilitleme politikaları şifre entropisine güven eksikliğini yansıtabilir.

Şahsen ben zaten bir web sitesinde şifre sona erdirme zorunluluğunu görmüyorum. Saldırgan şifrenizi bir kez alır, daha sonra değiştirebilir ve bu politikaya olabildiğince kolay bir şekilde uyabilir. Belki de bir avantajı, saldırgan hesap şifresini değiştirirse kullanıcının daha erken fark edebilmesidir. Daha da iyisi, kullanıcının saldırgan erişim elde etmeden önce bir şekilde bilgilendirilmesi olabilir. "Son girişten bu yana başarısız olan N denemesi" gibi mesajlar bu açıdan yararlıdır.

En iyi güvenlik, birincisine göre bant dışı ikinci bir kimlik doğrulama faktöründen gelir. Söylediğiniz gibi, "sahip olduğunuz bir şey" deki donanım belirteçleri harika, ancak çoğunun (hepsi değil) dağıtımlarıyla ilişkili gerçek yönetici ek yükü var. Web siteleri için iyi bir biyometrik "olduğunuz bir şey" çözümleri bilmiyorum. Bazı iki faktörlü çözümler openid sağlayıcılarıyla çalışır, bazılarında PHP / Perl / Python SDK'ları bulunur.

En yüksek tavsiyem, kullanıcıları hesaplarına kötü giriş denemeleri hakkında bilgilendirdiğinizden emin olmanızdır - Kullanıcılar, birilerinin gerçekte hesaplarına girmeye çalıştığına dair kanıt sunulduğunda, şifrelerinin gücünü çok daha ciddiye alacaktır. .

Aslında kardeşimin myspace hesabına hacklenen birini yakaladım çünkü onun için kurduğum gmail hesabına girmeye çalıştılar ve gelen kutuma giden 'şifremi e-posta ile sıfırla' özelliğini kullandılar.

1. Normal şifrelerini girmeden önce bir kerelik bir şifre talep etmeye ne dersiniz? Bu, birisinin ana şifreyi tahmin etmek için birçok fırsat bulmadan saldırdığını çok açık hale getirir mi?

2. Bir saldırı sırasında küresel bir sayım / giriş hatası oranını koruyun - bu bir saldırı göstergesidir - bir saldırı sırasında giriş hatalarıyla ilgili daha katı olun, örneğin IP'leri daha hızlı yasaklayın.

Mükemmel bir cevap olduğuna inanmıyorum ama bir saldırı algılanırsa robotları karıştırmaya çalışarak ona yaklaşmaya meyilli olurum.

Aklımın üstünde:

Alternatif bir giriş ekranına geçin. Gerçekten görünen birden fazla kullanıcı adı ve şifre boşluğu var, ancak bunlardan sadece biri doğru yerde. Alan adları Rastgele -a oturum anahtarı, sunucu daha sonra alanları nelerdir öğrenebilirsiniz giriş ekranı ile birlikte gönderilir. Başarılı veya başarısız olur, böylece bir tekrar saldırısı deneyemezsiniz - şifreyi reddederseniz yeni bir oturum kimliği alırlar.

Yanlış alandaki verilerle gönderilen herhangi bir formun bir robottan olduğu varsayılır - oturum açma başarısız olur, noktalanır ve bu IP kısıtlanır. Rastgele alan adlarının hiçbir zaman yasal alan adlarıyla eşleşmediğinden emin olun, böylece parolaları hatırlayan bir şey kullanan biri yanlış yönlendirilmez.

Daha sonra, farklı bir captcha'ya ne dersiniz: Bir insan için sorun yaratmayacak bir dizi sorunuz var. Ancak, rastgele DEĞİLDİR . Saldırı başladığında herkese 1. soru verilir. Bir saat sonra 1. soru atılır, bir daha asla kullanılmaz ve herkes 2. soru alır.

Saldırgan, soruların tek kullanımlık doğası nedeniyle robotuna koymak için veritabanını indiremez. Herhangi bir şey yapabilmek için bir saat içinde botnet'ine yeni talimatlar göndermesi gerekiyor.

Birkaç kişi CAPTCHA'yı geri dönüşlü bir insan mekanizması olarak içerdiğinden, CAPTCHA'nın etkinliği hakkında daha eski bir StackOverflow sorusu ve iş parçacığı ekliyorum.

ReCaptcha kırılmış / hacklenmiş / OCR olmuş / yenilmiş / kırılmış mı?

CAPTCHA kullanmak, azaltma ve diğer önerilerinizdeki gelişmeleri sınırlamaz, ancak CAPTCHA'yı yedek olarak içeren cevapların sayısının güvenliği kırmak isteyen insanlar için mevcut olan insan tabanlı yöntemleri göz önünde bulundurması gerektiğini düşünüyorum.

Ayrıca, bir kullanıcı şifresinin gücüne göre daraltabilirsiniz.

Bir kullanıcı şifresini kaydettiğinde veya değiştirdiğinde şifresi için bir güç derecesi hesaplarsınız, örneğin 1 ile 10 arasında.

"Şifre" gibi bir şey 1 puan alırken, "c6eqapRepe7et * Awr @ ch" 9 veya 10 puan alabilir ve puan ne kadar yüksek olursa, kısma o kadar uzun sürer.

Bu soruyu sorduğumda genellikle duyduğum ilk cevap bağlantı noktalarını değiştirmek, ancak bunu unutmak ve IPv4'ü devre dışı bırakmak. Yalnızca IPv6 ağlarından istemcilere izin verirseniz, artık basit ağ taraması için dua etmezsiniz ve saldırganlar DNS aramalarına başvuracaktır. Apache (AAAA) / Sendmail (MX-> AAAA) / herkese verdiğiniz şey (AAAA) ile aynı adreste çalışmayın. Bölgenizin xferd olmadığından emin olun, bölgenizin herhangi biri tarafından indirilmesine izin vermeyi bekleyin mi?

Botlar sunucunuzu yeni ana makine adları bulursa, ana makine adlarınıza biraz anlamsızca ekleyin ve adresinizi değiştirin. Eski adları bırakın ve hatta bot ağının zaman aşımına uğraması için bal küpü adları ayarlayın.

** Ters (PTR) kayıtlarınızı test edin (ip6.arpa altında). IE Tipik olarak ip6.arpa bir adreste ~ 32 "." S olurdu ama son birkaç eksik ile denemek VS diğerleri olmayan kayıtları olan ağ blokları kaçabilir. Bunu daha ileri götürürseniz, adres alanının büyük bölümlerini atlamak mümkün olur.

En kötü durumda, kullanıcıların bir IPv6 tüneli kurması gerekecek, bir DMZ'ye VPN yapmak kadar ileri gitmeleri gerekmiyor ... Biri bunun neden ilk seçenek olmadığını merak ediyor.

Ayrıca Kerberos iyidir, ancak IMHO LDAP darbeler (NISPlus ile teknik olarak yanlış olan nedir? Sun, kullanıcıların LDAP istediğine karar verdiğini okudum ve bu nedenle NIS + 'ı düşürdüler). Kerberos, LDAP veya NIS olmadan iyi çalışır, kullanıcıları ana bilgisayar temelinde bir ana bilgisayar üzerinde yönetmeniz yeterlidir. Kerberos kullanımı, otomatik olmasa bile size kolay bir PKI sağlar.

Biraz geç burada ama zor bir durum olduğunu varsayarak, saldırgan çok sayıda rastgele IP, rastgele kullanıcı adı ve en popüler 10.000'in bir listesinden seçilen rastgele bir şifre kullanıyor.

Yapabileceğiniz bir şey, özellikle sistem saldırı altında görünüyorsa, sistemde çok sayıda yanlış şifre denemesi olduğu ve özellikle parolanın düşük entropi olması durumunda, örneğin ebeveynlerinizin isimleri gibi ikincil bir soru sormaktır, örneğin . Bir saldırgan 'şifre1' şifresini deneyen bir milyon hesaba çarparsa, çok fazla kazanma şansları yüksektir, ancak isimleri doğru alma şansları başarıları önemli ölçüde azaltacaktır.