Çok site barındırma - siteleri birbirlerinden korumak için önemli güvenlik açığı kaçırılıyor mu?

EDIT # 2 23 Temmuz 2015: Aşağıdaki kurulumda kaçırılan veya her şeyin kapsandığına inanmak için sebep verebilecek önemli bir güvenlik öğesini tanımlayan yeni bir cevap arıyorum.

EDIT # 3 29 Temmuz 2015: Özellikle güvenlik kısıtlamalarını atlatmak veya daha da kötüsü, ancak açık bir şeyi açık bırakmak için sömürülebilecek bir şeye izin vermek gibi olası bir yanlış konfigürasyon arıyorum.

Bu çok site / paylaşılan barındırma kurulumu ve paylaşılan bir Apache örneği kullanmak istiyoruz (yani bir kullanıcı hesabı altında çalışıyor), ancak hiçbir sitenin başka bir sitenin dosyalarına erişemediğinden emin olmak için PHP / CGI her web sitesinin kullanıcısı olarak çalışıyor ve hiçbir şeyin kaçırılmadığından emin olun (örneğin, sembolik saldırı önleme hakkında bilgimiz yoksa).

Şimdiye kadar sahip olduğum şey:

• PHP komut dosyalarının web sitesinin Linux kullanıcı hesabı ve grubu olarak çalıştığından ve hapsedildiğinden (CageFS kullanımı gibi) veya Linux dosya sistemi izinleri kullanılarak en azından uygun şekilde kısıtlandığından emin olun.
• CGI betiklerinin Apache kullanıcısı olarak çalıştırılamayacağından emin olmak için suexec kullanın.
• Sunucu tarafı desteğine ihtiyaç duyuyorsanız (shtml dosyalarında olduğu gibi), CGI'nin Options IncludesNOEXECbeklemediğinizde çalıştırılmasını önlemek için kullanın (ancak suexec kullanılıyorsa bu kadar endişe duymamalıdır).
• Bir bilgisayar korsanının Apache'yi başka bir web sitesinin dosyalarını düz metin olarak sunması ve DB şifreleri gibi açıklayıcı bilgileri ifşa etmesi için symlink saldırı korumasına sahip olun.
• Yalnızca bir bilgisayar korsanının yararlanamayacağı yönergelere izin vermek için AllowOverride/ yapılandırın AllowOverrideList. Yukarıdaki öğeler düzgün bir şekilde yapılırsa, bu daha az endişe verici olduğunu düşünüyorum.

Çok yavaş olmasaydı ve kök olarak çalışmadıysa MPM ITK ile giderdim, ancak özellikle paylaşılan bir Apache kullanmak istiyoruz, ancak güvenli bir şekilde yapıldığından emin olmak istiyoruz.

Http://httpd.apache.org/docs/2.4/misc/security_tips.html buldum , ancak bu konuda kapsamlı değildi.

Bilmeniz faydalı olursa, CloudLinux'u CageFS ve mod_lsapi ile kullanmayı planlıyoruz.

Yapacağınızdan veya bilmeniz gereken başka bir şey var mı?

EDIT 20 Temmuz 2015: İnsanlar genel olarak değerli olan bazı iyi alternatif çözümler sundular, ancak bu sorunun yalnızca paylaşılan bir Apache kurulumunun güvenliği ile ilgili olduğunu lütfen unutmayın. Özellikle yukarıda ele alınmayan ve bir sitenin başka bir sitenin dosyalarına erişmesine veya diğer sitelerin bir şekilde güvenliğini aşmasına neden olabilecek bir şey var mı?

Teşekkürler!

Şimdiye kadar sahip olduğunuz ürünlere tamamen katılıyorum.

Birkaç yıl önce böyle bir çok kullanıcılı kurulum çalıştırırdım ve temelde aynı ödünleşimi buldum: mod_php hızlı (kısmen her şey aynı işlem içinde çalıştığı için) ve suexec yavaş ama güvenli (çünkü her istek yeni bir çatal işlemi). Kullanıcı izolasyonu gerektiğinden suexec ile gittim.

Şu anda düşünebileceğiniz üçüncü bir seçenek var: her kullanıcıya kendi php-fpm daemon'u verin. Bunun mümkün olup olmadığı kullanıcı sayısına bağlıdır, çünkü her birinin kullanıcı hesaplarını kullanarak en az bir php-fpm işlemi alması gerekir (arka plan programı istekleri ölçeklemek için prefork benzeri bir mekanizma kullanır, bu nedenle süreç sayısı ve bellek kullanımı sınırlayıcı faktörler olabilir). Bazı otomatik yapılandırma oluşturma işlemlerine de ihtiyacınız olacak, ancak bunun birkaç kabuk komut dosyasıyla yapılabilmesi gerekir.

Bu yöntemi geniş ortamlarda kullanmadım ancak IMHO, kullanıcıları hala süreç düzeyinde izole ederken iyi PHP web sitesi performansı sağlamak için iyi bir çözümdür.

Şimdiye kadar sahip olduğunuz her şey iyi düşünülmüş görünüyor. Bir sorun olarak görebildiğim tek şey, çoğu sömürünün bir şekilde kök erişimi elde etmeye çalışmasıdır. Bu nedenle, her site ve ilgili süreçleri ve komut dosyaları doğru bir şekilde hapse atılsa ve her şeyin kendi kullanıcısı ve izinleri olsa bile, köklü bir hacker daha az umursamazdı, sadece ayarladığınız her şeyi kaldırırlar.

Benim önerim, her siteye kendi OS hapishanesini vermek için bir çeşit VM yazılımı (VMware, VirtualBox, Qemu, vb.) Kullanmak olacaktır. Bu, sistem yöneticisi olarak güvenliği ihlal edilmiş tek bir site hakkında endişelenmenize izin vermez. Bir bilgisayar korsanı, bir sitenin VM'sinde php'yi (veya başka bir yazılımı) kullanarak kök kazanırsa, sanal makineyi duraklatıp daha sonra incelemek, düzeltmeler uygulamak veya kesintisiz bir duruma geri dönmek. Bu, site yöneticilerinin belirli site ortamlarına (başka bir siteyi kırabilir) belirli yazılım veya güvenlik ayarlarını uygulamasına da olanak tanır.

Bunun tek sınırlaması donanımınızdır, ancak iyi bir sunucu ve doğru çekirdek uzantılarıyla başa çıkmak kolaydır. Başarılı bir Linode bu tür kurulum çalıştırdım, hem Host hem de Konuk çok çok seyrek verildi. Eğer sen olduğunu varsayalım Komut satırı ile rahat, herhangi bir sorun olmamalıdır.

Bu tür kurulum, izlemeniz gereken saldırı vektörlerinin sayısını azaltır ve Host Machines güvenliğine odaklanmanıza ve sitedeki diğer her şeyi siteye göre ele almanıza olanak tanır.

Her sitenin kendi Apache arka plan programı altında çalışmasını ve Apache'yi hedeflemesini öneririm. Apache chroot ortamı / bin / sh erişimine sahip olmayacağından tüm sistem php işlevi başarısız olur. Bu, php'nin mail () işlevinin de çalışmadığı anlamına gelir, ancak e-posta uygulamanızdan posta göndermek için harici bir posta sağlayıcısı kullanıyorsanız, bu sizin için bir sorun olmamalıdır.

SELinux yardımcı olabilir mod_selinux. Burada hızlı bir şekilde nasıl yapılır:

PHP betiklerini sınırlamak için SELinux'u nasıl kullanabilirim?

Talimatlar biraz tarihli olduğundan, bunun RHEL 7.1'de çalışıp çalışmadığını kontrol ettim:

Ben kullandım Fedora 19 kullanıcısının versiyonunu ve RHEL 7.1 + Epel karşı taklidinin ile derlenmiş.

Temel epel config sahte kullanırsanız YMMV ile birlikte gelir:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

selinux-policyGüncel olduğundan emin olmak için önce hedef sisteminizi yükseltin .

Hedef kutuya kurun (veya önce yerel aynanıza koyun):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Şimdi, apache'deki her sanal ana makineye bir kategori atamalısınız. Bu, aşağıdaki örnekte olduğu gibi bir satır eklenerek yapılır selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Ardından, her ana bilgisayarın belge kökünde, belge köklerini httpd yapılandırmasında etiketlenenlerle aynı kategoriye yeniden etiketleyin.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Bir sistem yeniden etiketlemesi yaparsanız etiketlemenin onurlandırılmasını istiyorsanız, yerel politikayı da güncellemeniz daha iyi olur!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Şimdiden sağlanan birçok iyi teknik cevap var (lütfen buraya da bakınız: https://security.stackexchange.com/q/77/52572 ve LAMP Sunucusunun Güvenliğini Sağlama İpuçları ), ancak yine de burada belirtmek istiyorum güvenlik hakkında önemli bir nokta (yine başka bir bakış açısından): güvenlik bir süreçtir . Eminim bunu zaten düşünmüşsünüzdür, ancak yine de bazen (başka okuyucular için) bazen yeniden düşünmenin yararlı olabileceğini umuyorum.

Örneğin, sorunuzda temel olarak teknik önlemlere odaklanıyorsunuz: "bu soru yalnızca paylaşılan bir Apache kurulumunun güvenliği ile ilgilidir. Özellikle, paylaşılan çalıştırırken atmanız gereken ancak yukarıdaki listede bulunmayan güvenlik adımları var mı? Apache ve PHP. "

Hemen hemen tüm cevaplar burada ve bahsettiğim diğer 2 soru da tamamen teknik gibi görünüyor (güncel kalmak için tavsiye hariç). Benim açımdan, bu bazı okuyucuları yanıltıcı bir izlenim bırakabilir, eğer sunucunuzu bir kez en iyi uygulamaya göre yapılandırırsanız, sonsuza kadar güvende kalırsınız. Bu yüzden lütfen cevaplarda özlediğim noktaları unutmayın:

1. Her şeyden önce, güvenliğin ISO 27001 ( http://www.isaca.org/) dahil olmak üzere birçok standart tarafından önerildiği gibi , bir süreç ve özellikle de "Planla-Yap-Kontrol Et-Yasla" döngüsü hakkında olduğunu unutmayın. Dergi / arşivler / 2011 / Cilt-4 / Sayfalar / Uygulama-ve-Uygulama-ISO27001.aspx ). Temel olarak, bu, güvenlik önlemlerinizi düzenli olarak gözden geçirmeniz, güncellemeniz ve test etmeniz gerektiği anlamına gelir .

2. Sisteminizi düzenli olarak güncelleyin. Bu, sıfır günlük güvenlik açıklarını kullanan hedefli saldırılara karşı yardımcı olmaz, ancak neredeyse tüm otomatik saldırılara karşı yardımcı olacaktır.

3. Sisteminizi izleyin. Cevaplarda bu noktayı gerçekten özlüyorum. Benim bakış açımdan, sisteminizdeki bazı problemler hakkında mümkün olduğunca erken bilgilendirilmeniz son derece önemlidir.

   İstatistikler bunun hakkında şöyle diyor: "Sızmadan keşfe kadar geçen ortalama süre 173.5 gündür" ( http://www.triumfant.com/detection.html ), "Tespit edilmeden 205 medyan gün sayısı" ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-trends-2015.pdf ). Ve umarım bu sayılar hepimizin sahip olmak istediği şey değildir.

   Sadece hizmetin durumunu (Nagios gibi) izlemek için değil, aynı zamanda saldırı tespit sistemleri (OSSEC, Snort) ve SIEM sistemleri (OSSIM, Splunk) için de birçok çözüm (ücretsiz dahil) vardır. Çok karmaşık hale gelirse, en azından 'fail2ban' gibi bir şeyi etkinleştirebilir ve / veya günlüklerinizi ayrı syslog sunucusuna yönlendirebilir ve önemli olaylar hakkında e-posta bildirimleri alabilirsiniz .

   Yine, buradaki en önemli nokta hangi izleme sistemini seçtiğiniz değil, en önemlisi "Planla-Yap-Kontrol Et-Yasla" döngüsüne göre düzenli olarak izlemeniz ve düzenli olarak revize etmenizdir .

4. Güvenlik açıklarının farkında olun. İzleme ile aynı. Apache için bazı kritik güvenlik açıkları veya kurulumunuz için önemli olan başka bir hizmet keşfedildiğinde bildirilecek bazı güvenlik açığı listesine abone olun. Amaç, bir sonraki planlanan güncellemenizden önce görünen en önemli şeyler hakkında bilgilendirilmektir.

5. Bir olay durumunda ne yapacağınızı planlayın (ve bunu "Planla-Yap-Kontrol Et-Yasa" döngüsüne göre düzenli olarak güncelleyin ve revize edin). Güvenli yapılandırma hakkında soru sorarsanız, sisteminizin güvenliği sizin için önemli hale gelir. Ancak, tüm güvenlik önlemlerine rağmen sistemin saldırıya uğraması durumunda ne yapmalısınız? Yine, burada sadece "OS'yi yeniden yükle" gibi teknik önlemleri kastetmiyorum: Kazaları ilgili yasaya göre nereye bildirmelisiniz? Sunucunuzu hemen kapatmanıza / bağlantısını kesmenize izin var mı (şirketiniz için maliyeti nedir)? Sorumlu ana kişi tatilde / hasta ise kiminle temasa geçilmelidir?

6. Yedekleme, arşivleme ve / veya değiştirme / çoğaltma sunucunuz olsun. Güvenlik aynı zamanda hizmetinizin kullanılabilirliği anlamına da gelir. Yedeklemenizi / arşivinizi / çoğaltmanızı düzenli olarak kontrol edin ve geri yükleme prosedürlerini düzenli olarak test edin.

7. Penetrasyon testi? (yine, "Planla-Yap-Kontrol Et-Yasla" döngüsüne bakın :) Çok fazla geliyorsa, en azından web hizmetlerinizi kötü amaçlı yazılım ve güvenlik sorunları için tarayan bazı ücretsiz çevrimiçi araçları deneyebilirsiniz.

Kullanım çantanız liman işçisi konteynırları için idealdir.

Her kapsayıcı, her Apache kapsayıcı grubuna ek güvenlik olarak atanan benzersiz kullanıcı kimlikleriyle bir müşteri veya istemciyi temsil edebilir. Anahtar, apache yığınınızı başlatmadan önce kapsayıcı başlangıcında kök ayrıcalıklarını bırakmak olacaktır. Her müşteri, her biri kendi özel kar tanesi çekirdeğine ve diğer ek yüke ihtiyaç duyan düzinelerce sanal makineye sahip olmak zorunda kalmadan kendi DB hizmetlerini kendi benzersiz şifreleriyle alır. Sonuçta, liman işçisinin kalbinde kroot var. Düzgün bir şekilde yönetildiğinde, bunu her gün tipik bir sanal kümeye devrederim.

Zaten burada çok iyi öneriler. Yine de tartışmada kaçırılan şeyler var.

Web sayfalarının sunulmasının bir parçası olarak çalıştırılanlar dışındaki süreçlere dikkat edin. örneğin, bu işlerin kullanıcı tarafından tanımlanıp tanımlanmadığına bakılmaksızın, güvenilir olmayan verilere dokunan tüm cron işlerinizin uygun kullanıcı ve uygun hapiste çalıştığından emin olun.

Benim tecrübelerime göre, günlük analizi gibi şeyler, barındırma hizmeti tarafından sağlandığında, neredeyse hiç olmadığı kadar kök olarak çalıştırılır ve günlük analiz yazılımı istediğimiz kadar güvenlik denetimi verilmez. Bunu iyi yapmak biraz zor ve kuruluma bağlıdır. Bir yandan, root'un sahip olduğu (yani ana süreç) apache işleminizin kullanıcının tehlikeye atabileceği herhangi bir dizine yazmasını istemezsiniz. Bu muhtemelen hapse doğrudan yazmamak anlamına gelir. Öte yandan, bu dosyaları analiz için hapishanedeki süreçler için kullanılabilir hale getirmeniz gerekir ve bunun mümkün olduğunca gerçek zamanlıya yakın olmasını istersiniz. Hapishanelerinize günlükleri olan bir dosya sisteminin salt okunur bir bağına erişebiliyorsanız, bu iyi olmalıdır.

PHP uygulamaları genellikle kendi statik dosyalarını sunmaz ve paylaşılan bir apache süreciniz varsa, apache işleminizin ana bilgisayar ortamındaki hapishaneden bir şeyler okuduğunu tahmin ediyorum? Eğer öyleyse, bu çeşitli endişeler doğurur.

.htaccessdosyalar, izin verdiğiniz şeylere çok dikkat etmeniz gereken açık bir dosyadır. Çoğu önemli php uygulamaları değilse, planlı düzeninizi bozmadan muhtemelen izin veremeyeceğiniz .htaccess dosya düzenlemelerine çok bağımlıdır.

Apache'nin statik dosyanın ne olduğuna nasıl karar verdiği daha az açıktır. Örneğin, bir *.php.gifveya *.php.endosyayla ne işe yarar? Bu mekanizma veya başka bir statik dosya ne olduğu konusunda ayrımcılığı kandırırsa, apache'nin hapishanenin dışından php çalıştırması mümkün mü? Dinamik içeriği yürütmek için herhangi bir modülle yapılandırılmamış statik içerik için ayrı bir hafif web sunucusu ayarladım ve statik sunucuya hangi isteklerin gönderileceğini ve hangisinin dinamik olana karar vereceğine karar veren bir yük dengeleyicim var.

Stefan'ın Docker önerisi ile ilgili olarak, konteynerin dışında duran ve dinamik içerik için her bir konteynırdaki php artalanlarla konuşan tek bir web sunucusuna sahip olmak ve aynı zamanda bir docker konteynerinde oturan ikinci bir web sunucusuna sahip olmak mümkündür ve her birinin içeriği için kullandığı hacimleri paylaşır ve böylece önceki paragraftaki ile aynı olan statik içeriği sunabilir. Docker'ı çeşitli hapishane tipi yaklaşımlar arasında takdir ediyorum, ancak bu veya diğer hapishane tipi yaklaşımlarla, üzerinde çalışacağınız başka konular olacak. Dosya yükleme nasıl çalışır? Her bir konteynere dosya aktarma cinleri koyar mısınız? PAAS tarzı git tabanlı bir yaklaşım benimsiyor musunuz? Kapsayıcı içinde oluşturulan günlükleri nasıl erişilebilir hale getirirsiniz, ve onları yuvarlar mısın? Cron işlerini nasıl yönetiyor ve yönetiyorsunuz? Kullanıcılara herhangi bir kabuk erişimi verecek misiniz ve eğer öyleyse, bu konteyner içindeki başka bir arka plan programı mı? vesaire vesaire.

Görmediğim ilk şey süreç yönetimidir, bu nedenle bir süreç başka bir CPU veya RAM sürecini aç bırakamaz (veya bu konuda G / Ç, ancak dosya sisteminiz bunu önlemek için tasarlanmış olabilir). PHP örneklerinize "kapsayıcılar" yaklaşımının en büyük avantajlarından biri, hepsini tek bir "OS" görüntüsünde çalıştırmaya çalışmak ve kaynak kullanımını bu şekilde daha iyi kısıtlayabilmenizdir. Bunun sizin tasarımınız olmadığını biliyorum, ama bu dikkate alınması gereken bir şey.

Her neyse, PHP'nin Apache'nin arkasında çalışan ve temelde proxy olarak çalışan kullanım durumuna geri dönelim. suexec yok değil apache kullanıcı olarak çalışan bir şey önlemek - sağladığı yeteneği başka bir kullanıcı olarak çalıştırmak için. Bu yüzden bir endişe, her şeyin düzgün bir şekilde yapıldığından emin olmak olacak - bunun için doküman sayfası potansiyel tehlikeyi söylüyor: https://httpd.apache.org/docs/2.2/suexec.html . Yani, bilirsin, tuz tanesi ve bunun gibi.

Güvenlik açısından onlar farklı veya farklı bir kütüphaneye karşı derlenmektedir, özellikle (sarf cagefs) ile işe kullanıcı ikili bir kısıtlı bir set olması yararlı olabilir (örneğin istenmeyen özellikleri yoktur bir) ancak tehlike şu anda güncellemeler için bilinen bir dağıtımı izlememeniz, PHP kurulumlarınız için farklı bir dağıtım (kafesler) izlemenizdir (en azından kullanıcı alanı araçlarıyla ilgili olarak). Her ne kadar muhtemelen cloudlinux ile belirli bir dağılımı takip ettiğiniz için, bu kendi başına ilginç bir risk değil, artımlı bir risktir.

AllowOverride'ı istediğiniz yerde bırakabilirim. Derinlemesine savunmanın ardındaki temel fikir, tüm yığınınızı korumak için tek bir katmana güvenmemektir. Her zaman bir şeyin yanlış gidebileceğini varsayın. Bu olduğunda hafifletin. Sitelerinizin önünde yalnızca bir çit olsa bile, hafifletene kadar tekrarlayın.

Günlük yönetimi anahtar olacaktır. İzole edilmiş dosya sistemlerinde çalışan birden fazla hizmetle, bir sorun olduğunda ilişkilendirilecek etkinlikleri entegre etmek, bunu en başından ayarlamadıysanız küçük bir acı olabilir.

Bu benim beyin dökümü. Umarım orada çok faydalı bir şey vardır. :)