SELinux ve AppArmor vs. grsecurity [kapalı]

14

Mümkün olduğunca güvenli bir sunucu kurmalıyım. Hangi güvenlik geliştirmesini kullanırsınız ve neden SELinux, AppArmor veya grsecurity? Bana bu üç için bazı ipuçları, ipuçları, artıları / eksileri verebilir misiniz?

BİLDİĞİM KADARIYLA:

  • SELinux: en güçlü fakat en karmaşık
  • AppArmor: SELinux'dan daha basit yapılandırma / yönetim
  • grsecurity: otomatik eğitim sayesinde basit yapılandırma, erişim kontrolünden daha fazla özellik
linux  security  hardening 
Ne tür bir hizmet sunmak için bir "sunucu"? Hangi ortamda, hangi ortamda? Bu bağlamda size "güvenli" olan şey nedir? Yararlı bir cevap vermek için çok daha fazla bilgi gerekli olacaktır. Örneğin, saf bir IP Gün Saati sunucusu çok güvenli olabilir - tüm ROM bellenimi, radyo girişi, otomatik şarj ile bağımsız pil gücü. Ama bu muhtemelen sizin için yararlı bir cevap değil. Peki ne tür bir hizmet? İnternet çapında, kurumsal çapta, güvenilir çalışma ekibi, özel noktadan noktaya ağ bağlantısı vb. Yüksek kullanılabilirlik ihtiyacı var mı? Güvenilirlik? Veri bütünlüğü? Giriş kontrolu? Ver
— mpez0

Yanıtlar:

7

Bu alanda çok araştırma yaptım. AppArmor'un MySQL için kural setlerinden bile faydalandım . AppArmor, süreç ayrışmasının en zayıf şeklidir. Sömürdüğüm özellik, tüm işlemlerin aynı dizinlerden bazılarına yazma ayrıcalıklarına sahip olmasıdır /tmp/. AppArmor ile ilgili güzel olan şey, kullanıcı / yönetici yoluna girmeden bazı istismarları bozmasıdır. Ancak AppArmor'un yakın zamanda düzeltilmeyecek bazı temel kusurları vardır.

SELinux çok güvenlidir, aynı zamanda çok sinir bozucudur. AppAmoror'ın aksine, meşru uygulamaların çoğu SELinux yeniden yapılandırılıncaya kadar çalışmaz. Çoğu zaman bu, yönetici SELinux'un yanlış yapılandırılmasına veya hepsini birlikte devre dışı bırakılmasına neden olur.

grsecurity çok büyük bir araç paketidir. En sevdiğim, grsecuirty'nin geliştirilmiş krokidir. Bu, SELinux'dan daha güvenlidir, ancak SELinux ve AppAprmor'un "sadece işe yaradığı" gibi bir hapishane hapishanesi kurmak biraz beceri ve zaman gerektirir.

4. sistem, Sanal Makine var. VM ortamlarında, bir saldırganın "patlamasına" izin verebilecek güvenlik açıkları bulunmuştur. Bununla birlikte, bir VM'nin, işlemler arasında daha az kaynak paylaştığınız bir VM'deki bir chroot'tan daha büyük bir ayrımı vardır. Bir VM için kullanılabilen kaynaklar sanaldır ve diğer VM'ler arasında çok az çakışma olabilir veya hiç olmayabilir. Bu aynı zamanda <buzzword>" bulut bilişim " ile de ilgilidir </buzzword>. Bir bulut ortamında, veritabanınız ve web uygulamanız arasında güvenlik için önemli olan çok temiz bir ayrım olabilir. 1 istismarın tüm buluta ve üzerinde çalışan tüm sanal makinelere sahip olması da mümkündür.

— Kale
kaynak
<buzzword>etiket yerine "kıçımı" yazabilirsiniz, herkes ne demek istediğinizi bilir;)
— Daniel Dinnyes
VM ile Xen, KVM veya LXC / Docker mı demek istediniz? Ayrıca, lütfen değerlendirmelerinize bakın.
— Daniel Dinnyes
1
@Daniel Dinnyes burada referans yok, hepsi bu hafifletme teknikleri ile korunan modern uygulamalara saldıran bir hacker olarak kişisel görüştür - büyük götürmek hiçbir şeyin mükemmel olmamasıdır.
— Rook
1
@Daniel Dinnyes Yanlış kullanım durumlarıyla ilgileniyorsanız, amaçlanan kullanım durumlarıyla başlayın. Bu teknolojileri kullanan dağıtımları yükleyin ve uygulamaları onlara dağıtın. Bu güvenlik sistemlerini dağıtma ve yapılandırma hakkında bilgi edinin ve ardından zayıf noktaları arayın.
— Rook
1
@Daniel Dinnyes yayınlanan CVE'lere ve özellikle her platform için herhangi bir kamu yararına bakar. Son zamanlarda gerçekten iyi bir SELinux baypası bulundu: exploit-db.com/exploits/40419
— Rook
1

Şahsen, SELinux'u kullanırım çünkü çoğunlukla kutudan çıkmış olan RHEL'in bazı lezzetlerini hedeflemeliyim. Red Hat'ta duyarlı bir dizi koruyucu ve SELinux'un yapılandırılmasıyla ilgili çok iyi belgeler var. Aşağıdaki yararlı bağlantılar.

— yılanlara ait
kaynak
evet ama yum ve selinux çok can sıkıcı.
— Kale
1
Yum'ın CLI'sini apt'den çok daha sezgisel buluyorum. SELinux, stok dışı uygulamalarla kendi yolunuza gitmeye çalıştığınızda can sıkıcıdır, ancak varsayılan olmayan işlevselliği etkinleştirmek için bazı sebool'ları açmanın ötesinde stoklarla ilgili hiçbir zaman sorun yaşamadım (örneğin, httpd php komut dosyalarının bağlanmasına izin verin) ) veritabanına
— ophidian
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.