Bir web sitesinin yönetici bölümünün güvenliğini sağlamak için en iyi uygulamalar nelerdir? [kapalı]

İnsanların, özellikle kimlik doğrulama / erişim açısından, web sitelerinin Yönetici bölümlerinin güvenliğini sağlamak için en iyi uygulama olarak ne düşündüklerini bilmek istiyorum.

Elbette SSL kullanmak ve tüm erişimi kaydetmek gibi bariz şeyler var, ancak insanların bu temel adımların üzerinde barın nerede ayarlanacağını düşündüklerini merak ediyorum.

Ö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 etki alanında" mı çalıştırıyorsunuz?
• Yönetici bölümünü keşfedilmemiş hale getirmek için hangi adımları atıyorsunuz? (yoksa tüm 'belirsizlik' şeyini mi reddediyorsunuz)

Şimdiye kadar, yanıtlayanlardan gelen öneriler şunları içerir:

• Kaba kuvvet saldırılarını önlemek için her yönetici şifresi kontrolüne yapay bir sunucu tarafı duraklaması ekleyin [Geliştirici Sanatı]
• Aynı DB tablosunu kullanan kullanıcılar ve yönetici için ayrı oturum açma sayfaları kullanın (XSRF'yi ve oturum çalmayı yönetici alanlarına erişim sağlamayı durdurmak için) [Thief Master]
• Yönetici alanına web sunucusu yerel kimlik doğrulaması eklemeyi de düşünün (örn. .Htaccess aracılığıyla) [Thief Master]
• Bir dizi başarısız yönetici oturum açma denemesinden sonra kullanıcıların IP'sini engellemeyi düşünün [Thief Master]
• Başarısız yönetici giriş denemelerinden sonra captcha ekleyin [Thief Master]
• Kullanıcılar ve yöneticiler için eşit derecede güçlü mekanizmalar (yukarıdaki teknikleri kullanarak) sağlayın (ör. Yöneticileri özel olarak tedavi etmeyin) [Lo'oris]
• İkinci düzey kimlik doğrulamayı düşünün (örneğin, istemci sertifikaları, akıllı kartlar, kart alanı vb.) [JoeGeeky]
• Yalnızca güvenilir IP'lerden / Etki Alanlarından erişime izin verin, mümkünse temel HTTP ardışık düzenine (örneğin, HttpModules aracılığıyla) kontrol ekleyin. [JoeGeeky]
• [ASP.NET] IPrincipal & Principal'ı kilitleyin (onları değişmez ve numaralandırılamaz hale getirin) [JoeGeeky]
• Federasyon Hakları Yükseltme - örneğin, herhangi bir yöneticinin hakları yükseltildiğinde diğer yöneticilere e-posta gönderin. [JoeGeeky]
• Yöneticiler için ayrıntılı hakları göz önünde bulundurun - örneğin, role dayalı haklar yerine, yönetici başına belirli eylemler için hakları tanımlayın [JoeGeeky]
• Yönetici oluşturulmasını kısıtlayın - örneğin, Yöneticiler diğer yönetici hesaplarını değiştiremez veya oluşturamaz. Bunun için kilitlenmiş bir 'süper yönetici' istemcisi kullanın. [JoeGeeky]
• İstemci Tarafı SSL Sertifikalarını veya RSA tipi anahtarlıkları (elektronik belirteçler) düşünün [Daniel Papasian]
• Kimlik Doğrulama için tanımlama bilgileri kullanıyorsanız, yönetici ve normal sayfalar için ayrı tanımlama bilgileri kullanın, örneğin yönetici bölümünü farklı bir etki alanına yerleştirerek. [Daniel Papasian]
• Mümkünse, yönetici sitesini özel bir alt ağda, genel internet dışında tutmayı düşünün. [John Hartsock]
• Web sitesinin yönetici / normal kullanım bağlamları arasında geçiş yaparken yetkilendirme / oturum biletlerini yeniden yayınlama [Richard JP Le Guen]

Bunların hepsi iyi cevaplar ... Genelde yönetim bölümlerim için birkaç ek katman eklemeyi seviyorum. Bir tema üzerinde birkaç varyasyon kullansam da, bunlar genellikle aşağıdakilerden birini içerir:

• İkinci seviye kimlik doğrulama : Bu, istemci sertifikalarını (Ör. X509 sertifikaları), akıllı kartları, kart alanını vb. İçerebilir.
• Etki alanı / IP kısıtlamaları : Bu durumda, yalnızca güvenilir / doğrulanabilir etki alanlarından gelen istemciler; dahili alt ağlar gibi; yönetici alanına girmesine izin verilir. Uzak yöneticiler genellikle güvenilir VPN giriş noktalarından geçer, böylece oturumları doğrulanabilir ve genellikle RSA anahtarlarıyla da korunur. ASP.NET kullanıyorsanız, bu kontrolleri HTTP Ardışık Düzeni'nde HTTP Modülleri aracılığıyla kolayca gerçekleştirebilirsiniz; bu, uygulamanızın güvenlik kontrolleri yerine getirilmediği takdirde herhangi bir istek almasını engeller.
• Kilitli Fikri Mülkiyet ve İlkelere Dayalı Yetkilendirme : Özel İlkeler oluşturmak yaygın bir uygulamadır, ancak yaygın bir hata onları değiştirilebilir ve / veya haklar sayılabilir hale getirmektedir. Bu sadece bir yönetici sorunu olmasa da, daha önemlidir çünkü burada kullanıcıların yüksek haklara sahip olma olasılığı yüksektir. Değişmez ve sayılamaz olduklarından emin olun. Ek olarak, Yetkilendirmeye yönelik tüm değerlendirmelerin Müdüre göre yapıldığından emin olun.
• Federasyon Hakları Yükseltme : Herhangi bir hesap belirli sayıda hak aldığında, tüm yöneticiler ve güvenlik görevlisi hemen e-posta yoluyla bilgilendirilir. Bu, bir saldırganın bildiğimiz hakları hemen yükseltmesini sağlar. Bu haklar genellikle ayrıcalıklı haklar, gizlilik korumalı bilgileri görme hakları ve / veya finansal bilgiler (örneğin, kredi kartları) etrafında döner.
• Yöneticilere bile az miktarda hak verin : Son olarak, bu bazı mağazalar için biraz daha gelişmiş olabilir. Yetkilendirme hakları olabildiğince gizli olmalı ve gerçek işlevsel davranışları çevrelemelidir. Tipik Rol Tabanlı Güvenlik (RBS) yaklaşımları bir Grup zihniyetine sahip olma eğilimindedir . Güvenlik açısından bakıldığında, bu en iyi model değildir. ' Kullanıcı Yöneticisi ' gibi ' Gruplar ' yerine, onu daha fazla ayırmayı deneyin ( Ör. Kullanıcı Oluştur, Kullanıcıyı Yetkilendir, Erişim haklarını Yükselt / İptal Et, vb.)). Bunun 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 ihtiyaç duyulan hakları atama esnekliği sağlar. Erişim tehlikeye atılırsa en azından tüm hakları alamayabilirler. Bunu .NET ve Java tarafından desteklenen Kod Erişim Güvenliği (CAS) izinlerine dahil etmeyi seviyorum, ancak bu yanıtın kapsamı dışındadır. Bir şey daha var ... bir uygulamada yöneticiler diğer yönetici hesaplarını değiştirmeyi yönetemez veya bir kullanıcıyı yönetici yapamaz. Bu, yalnızca birkaç kişinin erişebileceği kilitli bir istemci aracılığıyla yapılabilir.

Web sitesi hem normal etkinlikler hem de yöneticiler için bir oturum açma gerektiriyorsa, örneğin bir forum, aynı kullanıcı veritabanını kullanan ayrı oturumlar kullanırdım. Bu, XSRF'nin ve oturum çalmanın saldırganın yönetim alanlarına erişmesine izin vermemesini sağlar.

Ek olarak, yönetici bölümü ayrı bir alt dizindeyse, bunu web sunucusunun kimlik doğrulamasıyla (örneğin Apache'de .htaccess) güvence altına almak iyi bir fikir olabilir - o zaman birinin hem bu parolaya hem de kullanıcı parolasına ihtiyacı vardır.

Yönetici yolunu gizlemek neredeyse hiçbir güvenlik kazancı sağlamaz - eğer birisi geçerli oturum açma verilerini biliyorsa, ya kimlik avı yaptığından ya da sizi kilitlediğinden ya da sosyal mühendislik yoluyla aldığından yönetici aracının yolunu da bulabilir (muhtemelen yol da).

3 başarısız oturum açtıktan sonra kullanıcının IP'sini bloke etmek veya başarısız bir oturum açtıktan sonra bir CAPTCHA gerektirmek (yasal kullanıcılar için son derece can sıkıcı olduğu için ilk oturum açma için değil) gibi kaba kuvvet koruması da yararlı olabilir.

• Belirsizliği reddediyorum
• Bir yerine iki kimlik doğrulama sistemi kullanmak aşırıdır
• Denemeler arasındaki yapay duraklama kullanıcılar için de yapılmalıdır
• Başarısız girişimlerin IP'lerinin engellenmesi kullanıcılar için de yapılmalıdır
• Kullanıcılar tarafından da güçlü parolalar kullanılmalıdır
• Captcha'ları kabul ediyorsanız, tahmin edin ne oldu, onları kullanıcılar için de kullanabilirsiniz.

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

Hem normal kullanıcı ayrıcalıklarına hem de yönetici ayrıcalıklarına sahip kullanıcılar için yalnızca tek bir giriş kullanırsanız, oturum tanımlayıcısını (bir çerezde veya bir GET parametresinde veya her neyse ...) seviyesinde bir değişiklik olduğunda yeniden oluşturun. ayrıcalık ... en azından.

Dolayısıyla, giriş yaparsam, bir dizi normal kullanıcı işi yaparsam ve ardından bir yönetici sayfasını ziyaret edersem, oturum kimliğimi yeniden oluşturun. Daha sonra bir yönetici sayfasından / sayfalarından normal bir kullanıcı sayfasına gidersem, kimliğimi yeniden oluşturun.

İyi bir yönetici şifreniz olsun.

Değil "123456"ama yeterince uzun harfler, rakamlar ve özel karakterler dizisi, 15-20 karakter, derler. Beğen "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Kaba kuvvet saldırısını önlemek için her parola denetimi için bir duraklama ekleyin.

İşte dikkate alınması gereken diğer bazı şeyler:

1. Göz önünde bulundurulması gereken bir seçenek, özellikle yöneticinin bilgisayarlarını yönetiyorsanız veya bunlar teknik olarak yetkin ise, istemci kimlik doğrulaması için SSL sertifikalarına dayalı bir şey kullanmaktır. RSA anahtarlıklar ve başka şeyler de ek güvenlik için kullanılabilir.
2. Çerezleri (belki bir kimlik doğrulama / oturum belirteci için) kullanıyorsanız, muhtemelen çerezlerin yalnızca yönetici sayfalarına gönderilmesini sağlamak istersiniz. Bu, 1/2 katman uzlaşması veya XSS yoluyla çerezleri çalarak sitenize getirilen riskleri azaltmaya yardımcı olur. Bu, yönetici kısmının farklı bir ana bilgisayar adında veya etki alanında olması ve ayrıca çerez ile güvenli bayrak ayarlanmasıyla kolayca yapılabilir.
3. IP ile kısıtlama da akıllıca olabilir ve internette kullanıcılarınız varsa, katılabilecekleri güvenilir bir VPN varsa bunu yine de yapabilirsiniz.

Windows AuthenticationYönetici erişimi için kullanıyoruz . Bu, kimlik doğrulamasını genel son kullanıcılar için geçerli olandan ayrı tutarken yönetici alanlarını korumanın en pratik yoludur. Sistem yöneticisi, Yönetici kullanıcı erişim kimlik bilgilerini yönetir ve etki alanı kullanıcı hesabında parola ilkelerini uygular.

Kesin yol, veritabanları, sunucular ve tümü dahil olmak üzere iki farklı "çiftliğe" sahip olmak ve verileri bir çiftlikten diğerine taşımaktır. Çoğu modern, büyük ölçekli sistem bu yaklaşımı kullanır (Vignette, SharePoint, vb.). Normalde "düzenleme aşaması" -> "önizleme aşaması" -> "teslim aşaması" farklı aşamalara sahip olarak adlandırılır. Bu yöntem, içeriği / yapılandırmayı kodu ele aldığınız şekilde (dev-> qa-> prod) işlemenizi sağlar.

Daha az paranoyak iseniz, tek bir veritabanınız olabilir, ancak yönetici bölümünüzün "düzenleme" sunucularında kullanılabilir olması gerekir. Demek istediğim, sadece düzenleme sunucusuna yerleştirilmiş düzenleme betikleri / dosyaları var.

Doğal olarak, düzenleme aşaması yalnızca yerel bir intranette ve / veya bir VPN kullanılarak yapılmalıdır.

Bu biraz abartılı görünebilir ve tüm kullanım durumları için en kolay çözüm olmayabilir, ancak kesinlikle işleri yapmanın en sağlam yoludur.

"Güçlü yönetici şifrelerine sahip olmak" gibi şeylerin iyi olduğunu unutmayın, ancak yine de yöneticinizi her türden akıllı eylemlere açık bırakın.

Ne tür verileri korumak istediğinize (yasal gereklilikler ve benzeri) bağlıdır.

• Pek çok öneri kimlik doğrulamayla ilgilidir .. Bence oturum açma olarak OpenId / Facebook kimlik doğrulamasını kullanmayı düşünmelisiniz. (Büyük olasılıkla kimlik doğrulama güvenliği için sizden daha fazla kaynak harcayacaklar)

• Veritabanındaki değerleri güncellemenin yanı sıra değişiklikleri kaydedin. Bu şekilde, X kullanıcısının veya X ile Y tarihleri ​​arasındaki değişiklikleri geri alabilirsiniz.

Hiç kimsenin yönetici şifresinin depolanmasından / doğrulanmasından bahsettiğini fark etmedim. Lütfen lütfen PW'yi düz metin olarak ve tercihen tersine çevrilebilecek bir şey olarak saklamayın - tuzlu bir MD5 karması gibi bir şey kullanın, böylece en azından birisi saklanan "şifreyi" alırsa, sahip olmayacaktır sizin tuz düzeninize sahip olmadıkları sürece, çok faydalı herhangi bir şey.

Yöneticinin bileceği bir parola alanı ve bir güvenlik sorusu ekleyin, örneğin ilk kız arkadaşınızın adı neydi veya yönetici panelini her görüntülediğinizde soruları rastgele sıralayın.

Belki de yönetim bölümünü her zaman büyük bir dizine koyabilirsiniz, örn.

http://domain.com/sub/sub/sub/sub/sub/index.php

Ama bu pek iyi değil hah.

Ana sayfaya aşağıdaki gibi bir sorgu dizesi ekleyebilirsiniz:

http://domain.com/index.php?display=true

Olduğunda, kullanıcı adı ve şifre alanı görünecektir.