Web sitemdeki dosyalar / klasörler bir Linux web sunucusunda hangi izinlere sahip olmalıdır?


309

Bu bir Linux web sunucusundaki Dosya İzinleri hakkında Kanonik bir Soru .

Birkaç web sitesine ev sahipliği yapan Apache2 çalıştıran bir Linux web sunucum var. Her web sitesinin / var / www / dizininde kendine ait bir klasörü vardır.

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

/ Var / www / dizinine root aittir: root. Apache www-data olarak çalışıyor: www-data. Fabrikam web sitesi iki geliştirici, Alice ve Bob tarafından yönetilmektedir. Her iki Contoso web sitesi bir geliştirici, Eve tarafından korunmaktadır. Tüm web siteleri kullanıcıların resim yüklemesine izin verir. Bir web sitesinin tehlikeye atılması durumunda, etki mümkün olduğu kadar sınırlı olmalıdır.

Apache'nin içeriğe hizmet edebilmesi, web sitesinin saldırılara karşı güvenli olması ve geliştiricilerin hala değişiklik yapabilmesi için izinleri ayarlamanın en iyi yolunu bilmek istiyorum. Web sitelerinden biri şöyle yapılandırılmıştır:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

Bu dizin ve dosyalarda izinler nasıl ayarlanmalıdır? Bir web sitesinde asla 777 izin kullanmamanız gereken bir yerde okudum, ancak hangi sorunlara neden olabileceğini anlamıyorum. Yoğun dönemlerde, web sitesi bazı sayfaları otomatik olarak önbelleğe alır ve sonuçları önbellek klasöründe saklar. Web sitesi ziyaretçileri tarafından gönderilen içeriğin tümü, yüklenenler klasörüne kaydedilir.


6
Bu, web sitesi izinleriyle ilgili aldığımız tüm sorular için kanonik bir cevap olması amaçlanmıştır .
Nic

“Bir web sitesinde hiçbir zaman 777 izin kullanmamanız gereken bir yer okudum, ama anlamadım ...” - o zaman okuyucu buradaki cevapların esasını anlayabilecek veya en azından karşılaştırabilecek mi? Herhangi bir çözüm özel gereksinimlere dayanmalıdır - buradaki gereksinimler yeterince spesifik değil (tehdit modeli nedir)
symcbean

6
Apache hakkında sormak hoşuma gidiyor, ancak Microsoft'un genellikle örnek olarak kullandığı alanları kullanıyor.
gWaldo


Yanıtlar:


342

Hangi izinlerin kullanılacağına karar verirken, kullanıcılarınızın tam olarak kim olduğunu ve neye ihtiyaçları olduğunu bilmeniz gerekir. Bir web sunucusu iki tip kullanıcı ile etkileşime girer.

Kimliği doğrulanmış kullanıcılar sunucuda bir kullanıcı hesabına sahiptir ve belirli ayrıcalıklarla sağlanabilir. Bu genellikle sistem yöneticilerini, geliştiricilerini ve servis hesaplarını içerir. Genellikle SSH veya SFTP kullanarak sistemde değişiklikler yaparlar.

Anonim kullanıcılar web sitenize gelen ziyaretçilerdir. Dosyalara doğrudan erişim iznine sahip olmasalar da, bir web sayfası talep edebilirler ve web sunucusu kendi adına hareket eder. Anonim kullanıcıların erişimini, web sunucusu işleminin hangi izinlere sahip olduğuna dikkat ederek sınırlayabilirsiniz. Birçok Linux dağıtımında, Apache www-datakullanıcı olarak çalışır ancak farklı olabilir. Apache'nin sisteminizde hangi kullanıcıyı kullandığını görmek için ps aux | grep httpdveya ps aux | grep apachedüğmesini kullanın .


Linux izinleriyle ilgili notlar

Linux ve diğer POSIX uyumlu sistemler geleneksel unix izinlerini kullanır. Wikipedia'da Dosya Sistemi izinleri hakkında mükemmel bir makale var, bu yüzden burada her şeyi tekrarlamayacağım. Ama bilmen gereken birkaç şey var.

Execute bit
Interpreted scriptleri (örn. Ruby, PHP), çalıştırma izni olmadan gayet iyi çalışır. Yalnızca ikili dosyalar ve kabuk komut dosyaları yürütme bitine ihtiyaç duyar. Bir dizini geçmek (girmek) için, bu dizinde yürütme iznine sahip olmanız gerekir. Web sunucusu bir dizini listelemek veya içindeki herhangi bir dosyayı sunmak için bu izne ihtiyaç duyar.

Varsayılan yeni dosya izinleri
Bir dosya oluşturulduğunda, normalde onu oluşturanın grup kimliğini miras alır. Ancak bazen yeni dosyaların oluşturuldukları klasörün grup kimliğini miras almasını istersiniz, böylece SGID bitini üst klasörde etkinleştirirsiniz.

Varsayılan izin değerleri umask'ınıza bağlıdır. Umask, yeni oluşturulan dosyalardan izinleri çıkarır; bu nedenle, 022'nin ortak değeri, 755 ile oluşturulan dosyaların oluşturulmasına neden olur. Bir grupla işbirliği yaparken, oluşturduğunuz dosyaların grup üyeleri tarafından değiştirilebilmesi için umask'ınızı 002 olarak değiştirmek yararlı olur. Yüklenen dosyaların izinlerini özelleştirmek istiyorsanız, ya apache için umask değerini değiştirmeli ya da dosya yüklendikten sonra chmod çalıştırmalısınız.


777 ile sorun

Ne zaman chmod 777web sitesi, bunun için hiçbir güvenlik var. Sistemdeki herhangi bir kullanıcı web sitenizdeki herhangi bir dosyayı değiştirebilir veya silebilir. Ancak daha da ciddiyetle, web sunucusunun web sitenizi ziyaret edenler adına hareket ettiğini ve şimdi web sunucusunun yürüttüğü dosyaları değiştirebildiğini unutmayın. Web sitenizde herhangi bir programlama açıklığı varsa, web sitenizi tahrif etmek, kimlik avı saldırıları eklemek veya sunucunuzdaki bilgileri siz bilmeden çalmak için kullanılabilir.

Ayrıca, sunucunuz iyi bilinen bir bağlantı noktasında çalışıyorsa (bu, kök olmayan kullanıcıların dünyaca erişilebilen dinleme hizmetlerinin çoğalmasını engellemesi gerekir), bu, sunucunuzun kök tarafından başlatılması gerektiği anlamına gelir (her ne zaman akıllıca bir sunucu hemen düşecekse de liman bağlandıktan sonra daha az ayrıcalıklı bir hesaba). Başka bir deyişle, ana uygulamanın sürüm kontrolünün bir parçası olduğu bir web sunucusu çalıştırıyorsanız (örn. Bir CGI uygulaması), izinlerini (veya bu konuda, kullanıcı yeniden adlandırabileceğinden, içerdiği dizinin izinlerini) bırakarak 777 de çalıştırılabilir) sağlar herhangi bir kullanıcının çalışmasına herhangi bir kök olarak yürütülebilir.


Gereksinimleri tanımla

  • Geliştiricilerin web sitesine güncelleme yapabilmeleri için dosyalara okuma / yazma erişimi gerekir
  • Geliştiricilerin dizinlerde okuma / yazma / yürütme ihtiyacı vardır, böylece dolaşabilirler
  • Apache'nin dosyalara ve yorumlanmış komut dosyalarına okuma erişimi ihtiyacı var
  • Apache'nin erişilebilir dizinlere okuma / yürütme erişimi gerekiyor
  • Apache'nin yüklenen içerik için dizinlere okuma / yazma / yürütme erişimi gerekiyor

Tek bir kullanıcı tarafından tutulur

Sitenin korunmasından yalnızca bir kullanıcı sorumluysa, bunları web sitesi dizininde kullanıcı sahibi olarak ayarlayın ve kullanıcıya tam rwx izinleri verin. Apache'nin dosyalara hizmet edebilmesi için hala erişime ihtiyacı vardır, bu nedenle www-verilerini grup sahibi olarak ayarlayın ve gruba rx izinleri verin.

Sizin durumunuzda, kullanıcı adı olabilecek Havva, aşağıdakileri evekoruyan kullanıcıdır contoso.com:

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Apache tarafından yazılabilmesi gereken klasörleriniz varsa, grup sahibinin izin değerlerini yalnızca www-data'nın yazma erişimine izin verecek şekilde değiştirebilirsiniz.

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

Bu konfigürasyonun avantajı, sistemdeki diğer kullanıcıların gizlice dolaşması daha zor (ama imkansız değil *) çünkü sadece kullanıcı ve grup sahipleri web sitesi dizinine göz atabilir. Bu, yapılandırma dosyalarınızda gizli verileriniz varsa kullanışlıdır. Umask'ına dikkat et! Burada yeni bir dosya oluşturursanız, izin değerleri muhtemelen varsayılan olarak 755'tir umask 027. Yeni dosyaların varsayılan olarak 640 ( rw- r-- ---) olmasını sağlayabilirsiniz .


Bir grup kullanıcı tarafından korunur

Siteyi korumaktan birden fazla kullanıcı sorumluysa, izinleri atamak için kullanmak için bir grup oluşturmanız gerekir. Her web sitesi için ayrı bir grup oluşturmak ve bu web sitesinden sonra gruba isim vermek iyi bir uygulamadır.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

Önceki örnekte, grup sahibini Apache'ye ayrıcalıklar vermek için kullandık, ancak şimdi geliştiriciler grubu için kullanılıyor. Kullanıcı sahibi artık bizim için yararlı olmadığından, ayrıcalıkların sızdırılmamasını sağlamanın basit bir yoludur. Apache'nin hala erişime ihtiyacı var, bu yüzden dünyanın geri kalanına okuma erişimi sağlıyoruz.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Apache tarafından yazılabilir olması gereken klasörleriniz varsa, Apache'yi kullanıcı sahibi veya grup sahibi olarak yapabilirsiniz. Her iki durumda da ihtiyacı olan tüm erişime sahip olacak. Şahsen, geliştiricilerin hala yükleme klasörlerinin içeriğine göz atıp değiştirebilmesi için kullanıcı sahibi yapmayı tercih ediyorum.

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Bu ortak bir yaklaşım olmasına rağmen, bir dezavantajı var. Sistemdeki diğer her kullanıcı web sitenizde Apache ile aynı ayrıcalıklara sahip olduğundan, diğer kullanıcıların sitenize göz atması ve yapılandırma dosyalarınız gibi gizli veriler içerebilecek dosyaları okuması kolaydır.

Pastanı alabilir ve yiyebilirsin de

Bu daha sonra geliştirilebilir. Sahibin gruptan daha az ayrıcalığa sahip olması tamamen yasaldır, bu nedenle kullanıcı sahibini root olarak atamakla israf etmek yerine, Apache'yi web sitenizdeki dizinlerde ve dosyalarda kullanıcı sahibi yapabiliriz. Bu, tek bir koruyucu senaryoyu tersine çevirir, ancak eşit derecede iyi çalışır.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Apache tarafından yazılabilmesi gereken klasörleriniz varsa, kullanıcı sahibinin izin değerlerini yalnızca www-data'nın yazma erişimine izin verecek şekilde değiştirebilirsiniz.

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Bu çözümle ilgili dikkat edilmesi gereken noktalardan biri, yeni dosyaların kullanıcı sahibinin, www-data olarak ayarlanmak yerine içerik oluşturucuyla eşleşmesidir. Bu nedenle, oluşturduğunuz herhangi bir yeni dosya, siz onu yiyene kadar Apache tarafından okunamaz.


* Apache ayrıcalık ayrımı

Daha önce, hangi tür ayrıcalıklara sahip olursanız olun, diğer kullanıcıların web sitenizi gizlemelerinin mümkün olduğunu belirttim. Varsayılan olarak, tüm Apache işlemleri aynı www-data kullanıcısı olarak çalışır, böylece herhangi bir Apache işlemi aynı sunucuda yapılandırılmış diğer tüm web sitelerinden dosyaları okuyabilir ve hatta bazen değişiklikler yapabilir. Apache'nin bir betiği çalıştırmasını sağlayabilen herhangi bir kullanıcı, Apache'nin sahip olduğu erişime sahip olabilir.

Bu sorunla mücadele etmek için , Apache'de ayrıcalık ayrımı için çeşitli yaklaşımlar vardır . Ancak, her yaklaşım çeşitli performans ve güvenlik sakıncaları ile birlikte gelir. Kanımca, daha yüksek güvenlik gereksinimleri olan herhangi bir sitenin, VirtualHosts'u paylaşılan bir sunucuda kullanmak yerine özel bir sunucuda çalıştırılması gerekir.


Ek hususlar

Daha önce bahsetmedim, ancak geliştiricilerin doğrudan web sitesini düzenlemesi kötü bir uygulamadır. Daha büyük siteler için, web sunucusunu sürüm kontrol sisteminin içeriğinden güncelleyen bir tür yayınlama sisteminden daha iyisin. Tek bakımcı yaklaşımı muhtemelen idealdir, ancak bir kişi yerine otomatik yazılım kullanıyorsunuz.

Web sitenizin dağıtılması gerekmeyen yüklemelere izin veriyorsa, bu yüklemeler web kökünün dışında bir yerde saklanmalıdır. Aksi takdirde, kişilerin gizli olması amaçlanan dosyaları indirdiğini görebilirsiniz. Örneğin, öğrencilerin ödev göndermesine izin verirseniz, Apache tarafından sunulmayan bir dizine kaydedilmeleri gerekir. Bu ayrıca sır içeren yapılandırma dosyaları için iyi bir yaklaşımdır.

Daha karmaşık gereksinimleri olan bir web sitesi için Erişim Kontrol Listeleri'nin kullanımını incelemek isteyebilirsiniz . Bunlar ayrıcalıkların çok daha karmaşık kontrolünü sağlar.

Web sitenizin karmaşık gereksinimleri varsa, tüm izinleri ayarlayan bir komut dosyası yazmak isteyebilirsiniz. İyice test edin, sonra güvende tutun. Herhangi bir nedenden ötürü web sitenizi yeniden inşa etmek için ihtiyaç duyduğunuzda, altın değerinde altın değerinde olabilir.


10
"chmod -R 775 fabrikam.com". Çoğu web sitesinin içindeki çok az sayıda dosyanın çalıştırılabilir olması gerekir; örneğin web sunucusu okuyabildiği sürece php betiği 0640 olabilir. chmod -R a + X fabrikam.com sadece dizinler üzerindeki herkese çalıştırılabilir haklar verir.

7
Apache'nin apacheRed Hat kaynaklı sistemlerde kullanıcı olarak çalıştığını unutmayın .
Michael Hampton

Bu mükemmel, ancak anlamadığım bir şey vardı: Dosya üzerinde zaten bir grup sahipliği varsa, apache'yi bir dosya dizininin kullanıcısı / sahibi yapma stratejisinin amacını veya avantajını anlamıyorum.
idiotprogrammer,

Bu cevap kapsamlı olmakla birlikte, yalnızca DAC izinleriyle ilgilidir. MAC izinlerinin de dikkate alınması gerektiğini düşünüyorum.
Davud

1
Bu mükemmel bir yazı. İşte benim katkım: www-data'yı sahip olarak ve dev-fabrikam'ı grup olarak kullanmanın dezavantajı (Pasta'da yer alabilir ve onu da yiyebilirsiniz . Ayrıca, tek bir kullanıcı tarafından tutulan senaryo için de (tersi olarak) uygulanır . senaryo, Apache ne zaman bir klasör veya dosya oluştursa, kullanıcı erişemez ve bu yüzden dosyaların orijinal kullanıcıya geri çevrilmesi gerekir. Yanıtı% 100 emin olmadığım için güncellemedim. Başkalarının cevabını yamalamadan önce onaylamasını tercih ederim

14

Neden bu kadar çok insanın Apache'nin (ve / veya PHP'nin) neler yapabileceğini kontrol etmek için Linux haklarının “diğer” (o) bölümünü kullandığını (veya önerdiğini) merak ediyorum. Bu sağ kısmı "0" dan başka bir şeye ayarlayarak, tüm dünyaya dosya / dizin üzerinde bir şey yapma izni verirsiniz.

Benim yaklaşımım şöyle:

  • İki ayrı kullanıcı oluşturdum. Biri tüm dosyalara sahip olacak SSH / SFTP erişimi (gerekirse) ve bir tane de PHP FastCGI kullanıcısı için (web sitesi olarak çalışacak kullanıcı). Bu kullanıcıları sırasıyla bob ve bob-www olarak adlandıralım .
  • bob tüm haklara sahip olacaktır ( klasörlerdeki rwx , rw- dosyalar), böylece tüm web sitesini okuyabilir ve düzenleyebilir.
  • PHP FastCGI işlem ihtiyacı rx klasörler ve üzerindeki haklarını r-- çok özel gibi klasörler haricinde dosyalar üzerinde hakları cache/veya uploads/"yazma" izni de gereklidir. PHP Fastcgi bu yeteneğini kazandırmak, o kadar çalışacak bob-www ve bob-www otomatik olarak oluşturulur eklenecektir bob grubunda.
  • Artık tüm dizinlerin ve dosyaların sahibinin ve grubunun bob olduğundan emin olduk .
  • Bir şeyler eksik: FastCGI kullanıyor olsak bile, Apache'nin statik içerik için okumaya ihtiyacı var, ya da AllowOverridebaşka bir şeye ayarlanmışsa okumayı deneyeceği .htaccess dosyaları None. Kullanmaktan kaçınmak için o hakların bir kısmını, ben eklemek www-data kullanıcıya bob grubunda.

Şimdi:

  • Geliştiricinin neler yapabileceğini kontrol etmek için , hakların u bölümünde oynayabiliriz (ancak bu not).
  • Apache ve PHP'nin neler yapabileceğini kontrol etmek için hakların g bölümünü oynayabiliriz .
  • O sunucuda kimse okumak veya web sitesini düzenleyebilirsiniz böylece yanım hep, 0 olarak ayarlanır.
  • Bob kullanıcısı yeni dosyalar oluşturduğunda sorun yok çünkü otomatik olarak ana grubuna ( bob ) ait olacak.

Bu bir özet, ancak bu durumda bob SSH'ye izin verilir. Web sitesini değiştirmesine izin verilen herhangi bir kullanıcının olmaması gerekiyorsa (örneğin, müşteri web sitesini yalnızca bir CMS yönetici paneli aracılığıyla değiştirir ve Linux bilgisine sahip değildir), yine de iki kullanıcı oluşturun, ancak bob/bin/false için kabuk olarak verin ve girişini devre dışı bırak.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Not: insanlar sınırlayıcı unutma eğiliminde u bir dosyanın sahibi çalıştırabilir, çünkü (sahibi) haklarını olan yararsız ve güvensiz çoğu zaman chmodkomut bile hakları 000 olan.

Yaklaşımımda bazı güvenlik sorunları olup olmadığını söyle, çünkü% 100 emin değilim, ancak kullanıyorum.

Bu konfigürasyonun bir sorunu olduğunu düşünüyorum: PHP / Apache yeni bir dosya oluşturduğunda (örn. Upload), bob-www: bob'ye ait olacak ve bob onu okuyabilir. Belki dizinde setuid sorunu çözebilir.


Linux görmezden geliyor setuid. Yeni dosyalar her zaman yaratıcıya aittir.
Paul,

Bir şey anlamıyorum Bu, tek kullanıcı olduğu için web sitesinde daha fazla geliştirici eşzamanlı olarak çalışırken, durumu dahil ediyor gibi görünmüyor bob. Bununla nasıl başa çıkıyorsun? Örneğin. ssh aracılığıyla her iki kullanıcı da bob olarak giriş yapar. bob (1) şifreyi hatırlayamadığını ve başka bir şifreye değiştirdiğini ancak hala güvende olduğunu hissediyor. bob (2) bir dahaki sefere giriş yapmaya çalışır ve yapamaz.
n611x007

2
@naxa Herhangi bir marjinal iyi sistem asla geliştiricilerin hiçbirini doğrudan web sitesinde değiştirmemelidir. İdeal olarak, web sitesi, “bob” kullanıcı hesabının her (kararlı) sürümü otomatik olarak çekip dağıtması için sürüm kontrolü altındadır. Bu nedenle, geliştiriciler geliştirme dışına çıkar ve dağıtım sunucusuna gönderildikten sonra değişiklikler dağıtılır. 'bob', uzaktan oturum açmayı içermeyen, çok sınırlı ağ iznine sahip olması gereken bir sistem kullanıcısıdır; iptables aslında böyle şeyler için UID ile filtre uygulamanıza izin verir.
Parthian Shot,

“Neden bu kadar çok insanın“ öteki ”(o) bölümünü kullandığını (veya önerdiğini) merak ediyorum - o zaman belki de bunu cevaptan çok bir soru olarak göndermeliydin. Destek, geliştirme, yönetici hesapları, farklı erişim ihtiyacı iken kasten ayrıcalık düzeyi en düşük olan (Sistemin en fazla maruz kalan parçası olarak) sunucusu işletmek görülmemiş şey değildir
symcbean

@ParthianShot bunu üçüncü taraflara zorlayamazsınız (site sizin tarafınızdan tutulmadığında ancak klasör sunucunuzda olduğunda). Bazen ne yapacaklarını bildikleri tek şey ftp kullanmaktır.
Peregring-lk,

9

Yukarıdaki mükemmel cevapta Google rütbesine bakıldığında, dikkat edilmesi gereken bir şey olduğunu düşünüyorum ve cevaptan sonra not bırakamıyorum.

Örneğe devam edersek, www-data'yı sahib olarak ve dev-fabrikam'ı dizinde (veya dosyada) 570 izne sahip bir grup olarak kullanmayı planlıyorsanız, Linux'un görmezden geldiğine dikkat etmek önemlidir setuid; onları yaratan kullanıcı. Bu, yeni dizinler ve dosyalar oluşturduktan sonra şuna benzer bir şey kullanmanız gerektiği anlamına gelir:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

Rackspace OpenStack için Ubuntu 12.04'te, sorunu sihirli bir şekilde düzelten sunucuyu yeniden başlatana kadar 570'ın çalışmasına izin alamadığım garip bir sorun yaşadım. Bu görünüşte basit olan mesele üzerinde artan oranda saç dökülmesi oldu ...


Bu googled olsun lütfen. Eğer lighttpd altında / var / www sahipliğini (veya başka bir web tarayıcısı) değiştirmek istiyorsanız Raspbian (aka ahududu pi üzerinde, yeniden başlattığınız GEREKİR
gbronner

@gbronner Bu, çözüm bulmak için zor bir mesele ise, bunu bir soru olarak göndermeyi ve soruya bir cevap vermeyi düşünebilirsiniz. Bununla birlikte, muhtemelen farklı bir soru-cevap sitesi için daha uygundur. Tahminimce Unix ve Linux bunu yapmak için iyi bir yer olabilir.
Paul

1
Ayrıca raspberrypi.stackexchange.com; ÖD sitelerinin bilgiyi biraz parçaladığı görülüyor.
gbronner

@gbronner lol. Bunu bilmiyordum! U&L'deki Raspbian etiketinde 120 soru gibi bir şey var.
Paul

3

Bu yapılandırma ile gidiyorum:

  1. Biri, sahibi rootve grubuna yüklenenler dışındaki tüm dizinler root, izinleri 0755.
  2. Tüm dosyalar sahibi rootve gruba ayarlanmış root, izinleri 0644.
  3. Ayarlanan dizine sahibine root, grubuna www-data, izinlerine yükler 1770. Yapışkan bit, grup sahibinin dizini ve içindeki dosyaları kaldırmasına veya yeniden adlandırmasına izin vermez.
  4. İçeride klasöre www-datasahip kullanıcı ve gruba sahip yeni bir dizin ve dosya yükleyen 0700her www-datakullanıcı için izinler .
  5. Apache yapılandırması:

Reddetti AllowOverrideve Indexupload dizininde, böylece Apache .htaccessdosyaları okumaz ve Apache kullanıcısı upload klasörü içeriğini indeksleyemez:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.iniyapılandırma:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Bu yapılandırma ile www-datakullanıcı siteDir/ /tmpve dışındaki dizinlerin içine giremez /usr/share/phpmyadmin. Ayrıca, aynı dosyaya yüklenecek maksimum dosya boyutunu, maksimum posta boyutunu ve yüklenecek maksimum dosyaları da kontrol edebilirsiniz.


3

"Leo" adında bir FTP kullanıcınız varsa, example.com web dizinine dosya yüklemeniz gerekir ve ayrıca "apache" kullanıcınızdan önbellek dizininde uploa-files / sessions / cache dosyaları oluşturabilmeniz gerekir;

Bu komut leo'yı example.com'a apache olarak sahip ve grup olarak atar, apache kullanıcısı apache grubunun bir parçası olduğundan apache grubunun izinlerini devralır.

chown -R leo: apache example.com

Doğru izni sağlayan ve güvenlikle ilgili endişeleri de yerine getiren başka bir komut.

chmod -R 2774 example.com

Burada ilk sayı 2, dizin içindir ve oluşturulan her yeni dosyanın aynı grupta kalmasını ve sahiplik izni olmasını sağlar. 77 sahibi ve grup için tam erişime sahip oldukları anlamına gelir. 4 diğerleri içindir, sadece yalak okuyabiliyorlar.

izin numaralarını anlamak için aşağıdakiler yararlı olacaktır:

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

1

IMO bir hesaba katmak zorunda:

  • dosyalarınızı okuyan bir sürece güveniyor musunuz? Örneğin. PHP?

Kullanıcı 'test' altında çeşitli verilerin bulunduğu bir sunucunuz olduğunu varsayalım.

'Test' kullanıcısı orada:

  • onun verileri $HOMEDIR
  • onun postası $MAIL
  • web’deki verileri /var/www/test

Şimdi düşünelim:

  • Bir web uygulaması testkullanıcı altında çalışır (PHP-FPM) - dosyalarından herhangi birini silebilir!
  • Bir web uygulaması testgrup altında çalışır (PHP-FPM) - grup için dizinin 'w' olduğu tüm dosyaları silebilir ve grup için 'r' olan herhangi bir dosyayı değiştirebilir; ve hala onları okuyabilirdi - örneğin ssh anahtarlarınız!

Diyelim ki PHP buggy ve bu, güveniyor open_basedirmusunuz? Eğer Do chrootPHP süreci? Siz değilsiniz, tüm dosya sistemlerinde gezinmesini istiyor musunuz?

Web uygulaması süreciniz, örneğin. PHP-FPM, sonra:

  • üzerinden belirli bir yolla sınırlandırılmak chroot
  • veri sahibinin birincil kullanıcısı veya birincil grup izni altında çalışmamalı

Böylece şunları yapabilirsiniz:

  • test kullanıcısı: test:test
  • Test kullanıcısı ikincil bir gruptur, örn. test-www
  • bir web uygulaması (PHP-FPM) altında çalışıyor test-www:test-www
  • Web uygulamasının kendi dosyalarını okuyabilmesini isterse kullanıcı testlerini yapar: chmod u=rwX,g=rX,o= /var/www/test/public
  • web uygulamasının web veri yoluna yazabilmesini istiyorsa test kullanıcısı: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (böylece uygulama yeni dosyalar oluşturacak: test-www:test-www- dizinde setgid nedeniyle test-www grubuna sahip olacak!)

Böylece, eğer web uygulaması süreci sahte olursa, sadece grubun okuması gereken dosyaları okur ve uploadsadece dir'e yazabilir . Bu uploaddir seçeneğine sahip bir dosya sistemine sahip noexec,nodev,nosuid mountolmanızı ve bu dizindeki yeni bizzare dosyaları için sürekli izlemeyi ve ayrıca test-wwwkullanıcı kimliği altındaki yeni süreçleri izlemenizi şiddetle tavsiye ederim .

Linux'ta, izinleri daha iyi ayarlamak için ACL kullanılabilir. Birden fazla insanın web verilerini yüklemesi gerekiyorsa, insan hesabını web verilerini yüklemek için kullanılan hesaptan ayırmak daha iyi olacaktır. yeni hesap oluşturmak için örn. test-uploadve test kullanıcısı, hangi kişinin orada ssh / sftp yapabileceğini sınırlamak için ssh anahtarlarını yönetir. seçenekleri sshd_configbilir, ExposeAuthInfoböylece verileri yüklemek için hangi ssh anahtarının kullanıldığını günlüğe kaydedebilir.

Web barındırma hizmetlerinin çoğunun ayrıcalıklara önem verdiğinden şüpheliyim, ne elde edeceğinize dair hiçbir bilgi olmadan 'güvenli' yazdıklarında, yalan söylediklerini söyleyebilirim.


php-fpm izin chrootve user, groupbir havuz için ayarlanmalıdır. ama ben php_admin_value[open_basedir]seçeneğe güvenmezdim . Ayrıca bakınız, bu kullanıcı başına ayrı bir PHP FPM usta olması daha iyidir okumak ma.ttias.be/a-better-way-to-run-php-fpm bir cin Çoğu Linux ve * BSD dağıtımlar yormayan örneklemek için.
Jiri B
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.