Soru Bir web sitesinin yönetici bölümünü güvenceye almak için en iyi yöntemler nelerdir? [kapalı]


Kullanıcıların, özellikle kimlik doğrulama / erişim açısından web sitelerinin Yönetici bölümlerini güvenceye almak için en iyi uygulamayı nasıl değerlendirdiğini bilmek isterim.

Tabii ki SSL kullanmak ve tüm erişimi günlüğe kaydetmek gibi bariz şeyler var, ama insanların temel olarak bu temel adımların nereye yerleştirileceğini düşünün.

Örneğin:

  • Normal kullanıcılar için kullandığınız aynı kimlik doğrulama mekanizmasına mı güveniyorsunuz? Değilse ne?
  • Yönetici bölümünü aynı "uygulama alan adı" nda mı çalıştırıyorsunuz?
  • Yönetici bölümünün keşfedilmemesi için hangi adımları uyguladınız? (ya da tüm 'belirsizlik' şeyini reddediyor musunuz?)

Şimdiye kadar, yanıt verenlerden gelen öneriler şunlardır:

  • Kaba kuvvet saldırıları önlemek için her yönetici şifre kontrolüne yapay sunucu tarafı duraklatmak tanıtmak [Geliştirici Sanat]
  • Kullanıcılar için ayrı giriş sayfalarını ve aynı DB tablosunu kullanarak yönetici kullanın (XSRF'yi ve yönetici alanlarına oturum açma izni vermek için) [Hırsız Ustası]
  • Yönetici alanına web sunucusu yerel kimlik doğrulaması eklemeyi de düşünebilirsiniz (ör., .Htaccess aracılığıyla). [Hırsız Ustası]
  • Başarısız bir yönetici girişi girişimi sayısından sonra kullanıcıların IP'sini engellemeyi düşünün [Hırsız Ustası]
  • Başarısız yönetici giriş denemelerinden sonra captcha ekle [Hırsız Ustası]
  • Hem yöneticiler hem de kullanıcılar için eşit derecede güçlü mekanizmalar (yukarıdaki teknikleri kullanarak) sağlayın (ör. Yöneticilere özel davranmayın) [Lo'oris]
  • İkinci seviye kimlik doğrulamasını (ör. İstemci sertifikaları, akıllı kartlar, kart alanı vb.) Göz önünde bulundurun. [JoeGeeky]
  • Yalnızca güvenilir IP'lerden / Alanlardan erişime izin verin, mümkünse temel HTTP boru hattına (örn. HttpModules) bir denetim ekleyin. [JoeGeeky]
  • [ASP.NET] IPrincipal & Principal'ı kilitleyin (bunları değiştirilemez ve okunamaz hale getirin) [JoeGeeky]
  • Federasyon Hakları Yükselmesi - ör. Herhangi bir yöneticinin hakları yükseltildiğinde diğer yöneticilere e-posta gönder. [JoeGeeky]
  • Yöneticiler için ince taneli haklar düşünün - ör. Rol tabanlı haklar yerine, yönetici başına belirli eylemler için hak tanımlayın [JoeGeeky]
  • Yönetici oluşturmayı sınırlandır - ör. Yöneticiler başka yönetici hesapları değiştiremez veya oluşturamaz. Bunun için kilitli bir 'süpermin' istemcisi kullanın. [JoeGeeky]
  • İstemci Tarafı SSL Sertifikalarını veya RSA tipi anahtarlıklarını (elektronik belirteçler) düşünün [Daniel Papasian]
  • Kimlik Doğrulama için çerez kullanıyorsanız, yönetici ve normal sayfalar için ayrı çerezler kullanın. Yönetici bölümünü farklı bir alana yerleştirmek. [Daniel Papasian]
  • Pratikse, yönetici sitesini genel internet üzerinden özel bir alt ağda tutmayı düşünün. [John Hartsock]
  • Web sitesinin admin / normal kullanım bağlamları arasında taşınırken yeniden auth / session biletleri [Richard JP Le Guen]

77
2018-05-17 18:15


Menşei


Sadece bir düşünce ama. Muhtemelen yönetici bölümünün güvenliğini sağlamanın en iyi yolu, kamuya açık internete sahip değildir. Yönetici sitesini yalnızca özel bir alt ağda tutmayı tercih edebilirsiniz. - John Hartsock
Belirttiğiniz bu fikirlerden hangileri, yalnızca yöneticilere değil, tüm kullanıcılara başvurmak için iyi bir fikir olmaz mı? - Daniel Allen Langdon
WebLoginProject öğesini kontrol etmek isteyebilirsiniz. webloginproject.com XSS, SQL Injection, Session fixation ve CSRF zafiyetlerine karşı güvenli olacak şekilde tasarlanmış bir işbirlikçi giriş sistemidir. ASP ve PHP'de kaynak kodu var, çok dilli ve harika görünüyor. Bir çok geliştirici üzerinde delikler tespit etmek için çalışıyorlar, bu yüzden bu mümkün olabildiğince güvenli olabiliyor. - stagas
-1 gerçekten yanlış "güçlü şifre" dahil (aslında bir çok zayıf şifre yerine) - o0'.
@Lohoris - Bu soruyu neden reddettiğinizi anlamıyorum. Birisinin düşündürdüğüne dair fikrini özetledim mi? Belki de ilgili cevabı indirgemek daha yapıcı olacaktır. : / Bir problemin olduğunu tam olarak açıklayabilir misin? - UpTheCreek


Cevaplar:


Bunların hepsi iyi cevaplar ... Genelde idari bölümler için birkaç ek katman eklemek istiyorum. Bir tema üzerinde birkaç varyasyon kullanmamıza rağmen, genellikle aşağıdakilerden birini içerirler:

  • İkinci seviye kimlik doğrulaması: Bu, istemci sertifikalarını (Ör. X509 certs), akıllı kartları, cardspace vb. İçerebilir ...
  • Alan / IP kısıtlamaları: Bu durumda, yalnızca güvenilir / doğrulanabilir alanlardan gelen müşteriler; iç alt ağlar gibi; Yönetici alanına izin verilir. Uzak yöneticiler genellikle güvenilir VPN giriş noktalarından geçerler, böylece oturumları doğrulanabilir ve çoğu zaman RSA anahtarları ile korunur. ASP.NET kullanıyorsanız, HTTP Denetimleri ile HTTP Denetimlerinde bu kontrolleri kolaylıkla gerçekleştirebilirsiniz; bu, güvenlik kontrolleri yerine getirilmediyse uygulamanızın herhangi bir talebi almasını engeller.
  • IPrincipal & Principal tabanlı Yetkilendirme: Özel Prensipler oluşturmak ortak bir uygulamadır, ancak ortak bir hata onları değiştirilebilir ve / veya hakların sayılabilir kılmasıdır. Sadece bir yönetici konusu olmasa da, kullanıcıların daha yüksek haklara sahip olma ihtimalleri olduğu için daha önemlidir. Değişmez ve sayılmaz olduklarından emin olun. Ayrıca, Yetkilendirme için tüm değerlendirmelerin Müdür'e göre yapıldığından emin olun.
  • Federasyon Hakları Yükselmesi: Herhangi bir hesap birtakım haklar aldığında, tüm yöneticiler ve güvenlik görevlisi derhal e-posta ile bilgilendirilir. Bu, bir saldırganın hemen bildiğimiz hakları yükselttiğinden emin olur. Bu haklar genellikle ayrıcalıklı haklar, gizlilik korumalı bilgileri görme hakları ve / veya finansal bilgiler (ör. Kredi kartları) etrafında döner.
  • Hakları, Yöneticiler için bile, idareli olarak yayınlayın: Son olarak, ve bu bazı dükkanlar için biraz daha gelişmiş olabilir. Yetkilendirme hakları mümkün olduğunca gizli olmalı ve gerçek işlevsel davranışları sarmalıdır. Tipik Rol Tabanlı Güvenlik (RBS) yaklaşımları bir grup zihniyet. Güvenlik açısından bu en iyi model değildir. Yerine 'Gruplar' sevmek 'Kullanıcı yöneticisi', daha fazla parçalamayı deneyin (Ör. Kullanıcı Oluştur, Kullanıcıyı Yetkilendir, Yükselt / İptal et erişim hakları, vb ...). Bu, yönetim açısından biraz daha fazla yük olabilir, ancak bu size yalnızca daha büyük yönetici grubu tarafından gerçekten gerekli olan hakları atamak için esneklik sağlar. Erişim en azından tehlikeye düşerse, tüm haklara sahip olmayabilir. Bunu .NET ve Java tarafından desteklenen Kod Erişimi Güvenliği (CAS) izinlerinde sarmayı seviyorum, ancak bu yanıtın kapsamı dışındadır. Bir uygulamada ... bir uygulamada, yöneticiler diğer yönetici hesaplarını değiştiremez veya bir kullanıcıyı yönetici yapamaz. Bu sadece bir kaç kişinin erişebileceği kilitli bir istemci üzerinden yapılabilir.

14
2018-05-17 10:10





Web sitesi hem normal etkinlikler hem de yöneticiler için bir giriş gerektiriyorsa, ör. Bir forum, aynı kullanıcı veritabanını kullanan ayrı girişler kullanırdım. Bu, XSRF'nin ve oturum çalınmasının, saldırganın idari alanlara erişmesine izin vermemesini sağlar.

Ayrıca, yönetici bölümü ayrı bir alt dizinde ise, web sunucusunun kimlik doğrulaması (örneğin Apache'de .htaccess) ile güvenli bir şekilde bağlantı kurmak iyi bir fikir olabilir - o zaman birisinin hem parola hem de kullanıcı parolasına ihtiyacı vardır.

Yönetici yolunu göz ardı etmek neredeyse hiç güvenlik kazancı vermez - eğer birisi geçerli giriş verilerini biliyorsa, büyük olasılıkla yönetici aracının yolunu bulabilir. yol da).

3 başarısız girişten sonra kullanıcının IP'sini bloke etmek veya başarısız bir girişten sonra bir CAPTCHA gerektirmesi gibi bir kaba kuvvet koruması (sadece yasal kullanıcı için son derece rahatsız edici olan ilk giriş için değil) yararlı olabilir.


18
2018-05-17 11:15





  • Belirsizliği reddediyorum
  • Bir yerine iki kimlik doğrulama sistemi kullanmak overkill
  • Denemeler arasında yapay duraklama kullanıcılar için de yapılmalıdır
  • Başarısız girişimlerin IP'lerini engellemek, kullanıcılar için de yapılmalıdır
  • Güçlü şifreler de kullanıcılar tarafından kullanılmalıdır
  • Captcha'ları dikkate alırsanız, tahmin edin, bunları da kullanıcılar için kullanabilirsiniz.

Evet, yazdıktan sonra, bu cevabın "yönetici girişi için özel bir şey değil, herhangi bir giriş için kullanılması gereken tüm güvenlik özellikleri" olarak özetlenebileceğini anlıyorum.


7
2018-05-17 10:09



Cevap için teşekkürler. Şahsen ben katılmıyorum, örneğin: Bir kullanıcı 'ksd83,' | 4d # rrpp0% 27 & lq (go43 $ sd {3> 'gibi parolalar ile mutlu olur mu? Ve, geçerli kullanıcılar tarafından tetiklenen geçerli kullanıcılar IP blokları sıfırlama değil mi? unneccessary yönetici / müşteri hizmeti çalışması üretecek unutkanlık var mı? Şahsen farklı risk düzeylerinin farklı yaklaşımları haklı kıldığını düşünüyorum - UpTheCreek
Yönetici şifresi karmaşık olmalı, ancak aşırı karmaşık olmamalıdır, aksi halde yönetici bile hatırlamayacaktır ve bir yere yazacaktır (her güvenlik kuralına meydan okumayı zorlayacaksınız). Başarısız girişimde geçici olarak IP'leri engellemek oldukça standarttır, vbulletin yapar, phpbb IIRC yapar, kullanıcılar buna alıştırır. - o0'.
En iyi güvenlik uygulamaları için phpbb veya vbulletin'e bakmak istemiyorum.) - UpTheCreek
@UpTheCreek elbette, katılıyorum! Sadece bunu sorguluyordum "Unutulmayan yönetici / müşteri hizmeti çalışması üretecek unutkanlık yaparak geçerli kullanıcıların tetiklediği IP engellemelerini sıfırlamıyor" <- Bunun bir sorun olacağını düşünmüyorum çünkü kullanıcılar zaten böyle bir özellik için kullanılıyor. - o0'.
Ah görüyorum, doğru - UpTheCreek


Hem normal kullanıcı ayrıcalıklarına hem de yönetici ayrıcalıklarına sahip olan kullanıcılar için yalnızca tek bir oturum açma kullanırsanız, oturum düzeyini değiştirdiğinizde oturum tanımlayıcısını (bir çerezde veya GET parametresinde olsun ya da olmasın ...) yeniden oluşturun. ayrıcalık ... en azından.

Bu yüzden giriş yaparsam, normal kullanıcılardan oluşan bir şeyler yapın ve ardından bir yönetici sayfasını ziyaret edin, oturum kimliğimi yeniden oluşturun. Bir yönetici sayfasından / sayfalarından normal bir kullanıcı sayfasına geçersem kimliğimi yeniden oluşturun.


3
2018-05-25 18:10



Bunun ne anlama geldiğini açıklar mısınız lütfen? - Denis Pshenov
security.stackexchange.com/questions/1246/... - Richard JP Le Guen
Bunun senin düşündüğün kadar yardımcı olmayacağına inanıyorum. Çünkü saldırgan mevcut oturum kimliğinizi normal kullanıcı sayfasından alabilirse, yönetici sayfasına erişmek ve yeni bir oturum kimliği oluşturmak için bunu kullanabilir. Yanlışsam düzelt. - Denis Pshenov
Ancak saldırgan, yönetici sayfasına şifre olmadan erişemez. Kimlik doğrulamasından sonra ayrıcalık düzeyinde bir değişiklik yoktur. Oturum kimliğini yeniden oluşturma başarısızlığı, kimlik doğrulaması yapmak için güvenli bir şekilde oluşturulan bir oturumu yeniden kullanabilecekleri anlamına gelir. - Richard JP Le Guen
Şimdi anladım. Kullanıcının normal / yönetici içeriği arasında geçiş yaparken yeniden oturum açması gerekmediği bir senaryo açıkladığını düşünüyordum. - Denis Pshenov


İyi bir yönetici şifresi var.

Değil "123456" ancak bir dizi harf, rakam ve özel karakter uzunluğunda, 15-20 karakter. Sevmek "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Kaba kuvvet saldırısını önlemek için her şifre kontrolü için bir duraklama ekleyin.


1



Bir 'duraklama' ne olacağını biraz açıklayabilir misiniz? Biraz zaman öldürmek için Thread.Sleep (5000) gibi bir şey yapmaya mı atıfta bulunuyorsun? - earthling
bu aptalca: hatırlanması çok karmaşık bir şifre bir yere yazılacak (ya da kaydedilecek), bu yüzden GERÇEKTEN iyi bir şifreye izin verdiğinizden çok daha kötü bir şey (yani kopya yapıştırılmış olarak hatırladığınız için yazılacak bir şifre) ). - o0'.
Oh, keşke bu çılgınlığı taş devrine indirgeyebilirdim. yani aptal, yani Yanlış ... İnsanların bu gibi yanlış bilgi yaymaktan nefret ediyorum. - o0'.
@ Lo'oris: Tam olarak katılmamanız nedir?
Onu yukarıda yazdığım gibi ... yazdım mı? - o0'.


Dikkate alınması gereken başka şeyler şunlardır:

  1. Özellikle yönetici bilgisayarlarını yönetiyorsanız veya teknik olarak yetkin olduklarında göz önünde bulundurulması gereken bir seçenek, istemci kimlik doğrulaması için SSL sertifikalarına dayanan bir şey kullanmaktır. RSA keyfobs ve ek güvenlik için ne kullanılamaz.
  2. Çerezleri hiç kullanıyorsanız - belki de bir kimlik doğrulama / oturum belirteci için - muhtemelen çerezlerin yalnızca yönetici sayfalarına gönderilmesini sağlamak istersiniz. Bu, sitenize verilen riskleri azaltmaya yardımcı olur, ya cookie (katman) uzlaştırmak ya da XSS. Bu, yönetici kısmının farklı bir ana makine adına veya etki alanına sahip olmasının yanı sıra güvenli bayrağın çerezle ayarlanmasıyla kolayca yapılabilir.
  3. IP ile kısıtlama yapmak akıllıca olabilir ve internet üzerinden kullanıcılarınız varsa, yine de katılabildiği güvenilir bir VPN varsa bunu yapabilirsiniz.

1





Kullanırız Windows Authentication yönetici erişimi için. Bu, kimlik doğrulamayı genel son kullanıcılara uygulanandan ayrı tutarken yönetici alanlarını korumanın en pratik yoludur. Sistem yöneticisi Yönetici kullanıcı erişim bilgilerini yönetir ve etki alanı kullanıcı hesabındaki parola ilkelerini uygular.


1





Kesin yol, veritabanları, sunucular ve hepsi dahil olmak üzere iki farklı "çiftlik" e sahip olmak ve verileri bir çiftlikten diğerine taşımaktır. En modern, büyük ölçekli sistemler bu yaklaşımı kullanır (Vignette, SharePoint, vb.). Normalde "düzenleme aşaması" -> "önizleme aşaması" -> "teslim aşaması" farklı aşamalarına sahip olarak adlandırılır. Bu yöntem, içeriği işleme / kodla aynı şekilde yapılandırmanıza izin verir (dev-> qa-> prod).

Eğer daha az paranoyak iseniz, tek bir veritabanına sahip olabilirsiniz, ancak sadece yönetici bölümünüzü "düzenleme" sunucularında kullanabilirsiniz. Demek istediğim, sadece düzenleme sunucusuna yerleştirilmiş düzenleme komut dosyaları / dosyaları var.

Doğal olarak düzenleme aşaması sadece bir yerel intranette ve / veya bir VPN kullanarak mevcut olmalıdır.

Bu biraz fazla bir sıkıntı gibi görünebilir ve tüm kullanım durumları için en kolay çözüm olmayabilir, ancak bu kesinlikle bir şey yapmanın en sağlam yoludur.

"Güçlü yönetici şifrelerine sahip ol" gibi şeylerin güzel olduğunu, ancak yöneticinizin her türden akıllı atlatmaya açık olduğunu unutmayın.


-1



Bunun sadece veriyi işlemek yerine içeriği zorladığınız tamamen CMS / yayınlama koşullarında kullanışlı / pratik olacağını düşünüyorum. - UpTheCreek
Belki de, bunun işlem ve kullanıcı girdisi için yapıldığı durumları biliyordum (ve gördüm). Ayrı düzenleme sunucusuna sahip tek bir çiftlik için bu hiç de akıllıca değildir. Birden fazla çiftlikler için yaptığınız, siteden gelen girdinin bir sıraya (DB veya başka bir şekilde) gitmesi ve harici bir yordam kullanarak "düzenleme" sunucusuna / DB'ye işlenmesi ve kopyalanmasıdır. Bu, sisteminize girenlere daha fazla kontrol sağlar. Bununla birlikte, uygulamak karmaşıktır. - Nir Levy