it-swarm.asia

Web sitesi dosyalarımın / klasörlerimin Linux web sunucusunda hangi izinleri olmalıdır?

Bu bir Linux web sunucusundaki Dosya İzinleriyle ilgili Kurallı Sor .

Birkaç web sitesini barındıran Apache2 çalıştıran bir Linux web sunucum var. Her web sitesinin/var/www/dizininde kendi klasörü vardır.

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

/ Var/www/ana dizininin sahibi root: root dizinidir. Apache www-data: www-data olarak çalışıyor. Fabrikam web sitesi Alice ve Bob adlı iki geliştirici tarafından yönetiliyor. Her iki Contoso web sitesi de bir geliştirici, Eve. Tüm web siteleri, kullanıcıların resim yüklemesine izin verir. Bir web sitesinin güvenliği ihlal edilirse, etki mümkün olduğunca sınırlı olmalıdır.

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

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

Bu dizinler ve dosyalar üzerinde izinler nasıl ayarlanmalıdır? Bir web sitesinde asla 777 izinlerini kullanmamanız gereken bir yeri 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 tüm içerik yüklemeler klasörüne kaydedilir.

324
Nic

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

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

Anonim kullanıcılar web sitenizi ziyaret edenlerdir. Dosyalara doğrudan erişim izinleri olmamasına rağmen, bir web sayfası isteyebilirler ve web sunucusu kendi adlarına hareket eder. Web sunucusu işleminin hangi izinlere sahip olduğuna dikkat ederek anonim kullanıcıların erişimini sınırlandırabilirsiniz. Birçok Linux dağıtımında, Apache www-data Kullanıcısı olarak çalışır, ancak farklı olabilir. Apache'nin sisteminizde hangi kullanıcıyı kullandığını görmek için ps aux | grep httpd Veya ps aux | grep Apache Kullanın.


Linux izinleri hakkında notlar

Linux ve diğer POSIX uyumlu sistemler geleneksel unix izinlerini kullanır. Wikipedia hakkında Dosya sistemi izinleri hakkında mükemmel bir makale var, bu yüzden burada her şeyi tekrar etmeyeceğim. Ancak bilmeniz gereken birkaç şey var.

Yürütme biti
Yorumlanan komut dosyaları (ör. Ruby, PHP) yürütme izni olmadan gayet iyi çalışır. Yalnızca ikili dosyalar ve Shell betikleri yürütme bitine ihtiyaç duyar. Bir dizinde dolaşmak (girmek) için, o dizinde yürütme izninizin olması gerekir. Web sunucusu bu dizini listelemek veya içindeki dosyaları sunmak için bu izne ihtiyaç duyar.

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

Varsayılan izin değerleri umask'ınıza bağlıdır. Umask, yeni oluşturulan dosyalardan izinleri çıkarır, bu nedenle ortak 022 değeri 755 ile oluşturulan dosyalara neden olur. Bir grupla işbirliği yaparken, oluşturduğunuz dosyaların grup üyeleri tarafından değiştirilebilmesi için umask'nizi 002 olarak değiştirmeniz yararlı olur. Yüklenen dosyaların izinlerini özelleştirmek istiyorsanız, Apache için umask'i değiştirmeniz veya dosya yüklendikten sonra chmod'u çalıştırmanız gerekir.


777 ile ilgili sorun

Web sitenizi chmod 777 Yaptığınızda, hiçbir güvenliğiniz olmaz. Sistemdeki herhangi bir kullanıcı web sitenizdeki herhangi bir dosyayı değiştirebilir veya silebilir. Ancak daha ciddisi, web sunucusunun web sitenize gelen ziyaretçiler adına hareket ettiğini ve şimdi web sunucusunun yürüttüğü aynı dosyaları değiştirebildiğini unutmayın. Web sitenizde herhangi bir programlama güvenlik açığı varsa, bilmeden web sitenizi tahrif etmek, kimlik avı saldırıları eklemek veya sunucunuzdan bilgi çalmak için bunlardan yararlanılabilir.

Ayrıca, sunucunuz iyi bilinen bir bağlantı noktası (root olmayan kullanıcıların dünya çapında erişilebilir dinleme hizmetlerini üretmesini önlemek için) üzerinde çalışırsa, sunucunuzun root tarafından başlatılması gerektiği anlamına gelir ( bağlantı noktası bağlandıktan sonra herhangi bir aklı başında sunucu hemen daha az ayrıcalıklı bir hesaba düşecektir). Diğer bir deyişle, ana yürütülebilir dosyanın sürüm kontrolünün (ör. Bir CGI uygulaması) bir parçası olduğu bir web sunucusu çalıştırıyorsanız, kullanıcı adını yeniden adlandırabileceği için izinlerini (veya bu nedenle içeren dizinin izinlerini bırakarak) yürütülebilir) 777'de herhangi bir kullanıcının root olarak çalıştırılabilir çalıştırılmasına izin verir .


Gereksinimleri tanımlayın

  • Geliştiricilerin web sitesini güncelleyebilmeleri için dosyalara okuma/yazma erişimi gerekir
  • Geliştiricilerin dizinlere göz atma/yazma/yürütme gereksinimi vardır.
  • Apache'nin dosyalara ve yorumlanmış komut dosyalarına okuma erişimi gerekir
  • Apache'nin hizmet verilebilir 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 korunur

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

Sizin durumunuzda, kullanıcı adı eve olabilecek Havva, 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 yazma erişimine sahip olacak şekilde değiştirebilirsiniz.

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

Bu yapılandırmanın yararı, sistemdeki diğer kullanıcıların göz atması zorlaşır (ancak imkansız değildir *), çünkü yalnızca kullanıcı ve grup sahipleri web sitesi dizininize göz atabilir. Bu, yapılandırma dosyalarınızda gizli verileriniz varsa kullanışlıdır. Umask'ınıza dikkat edin! Burada yeni bir dosya oluşturursanız, izin değerleri büyük olasılıkla varsayılan olarak 755 olacaktır. umask 027 Çalıştırarak 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 üzere bir grup oluşturmanız gerekir. Her web sitesi için ayrı bir grup oluşturmak ve gruba bu web sitesinin adını 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ık 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, root olarak ayarlamak hiçbir ayrıcalığı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 veriyoruz.

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 klasörleriniz varsa Apache'yi kullanıcı sahibi veya grup sahibi yapabilirsiniz. Her iki durumda da, ihtiyaç duyduğu tüm erişime sahip olacaktır. Şahsen, geliştiricilerin yükleme klasörlerinin içeriğine göz atabilmesi ve 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 tüm kullanıcılar 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ızı alabilir ve yiyebilirsiniz

Bu daha da geliştirilebilir. Sahibinin gruptan daha az ayrıcalığa sahip olması son derece yasaldır, bu nedenle kullanıcı sahibini root'a atayarak israf etmek yerine, Apache'yi web sitenizdeki dizinlerde ve dosyalarda kullanıcı sahibi yapabiliriz. Bu, tek sürdürücü senaryosunun tersidir, 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ılabilir olması gereken klasörleriniz varsa, kullanıcı sahibinin izin değerlerini yalnızca www-data yazma erişimine sahip olacak ş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ümde dikkat edilmesi gereken bir şey, yeni dosyaların kullanıcı sahibinin www-data olarak ayarlanmak yerine yaratıcıyla eşleşmesidir. Bu nedenle, oluşturduğunuz yeni dosyalar siz onları seçene kadar Apache tarafından okunamaz.


* Apache ayrıcalık ayrımı

Daha önce, diğer kullanıcıların ne tür ayrıcalıklar kullandığınızdan bağımsız olarak web sitenizi araştırmasının mümkün olduğunu söylemiştim. 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ış tüm diğer web sitelerinden dosyaları okuyabilir ve hatta bazen değişiklik bile yapabilir. Apache'nin bir komut dosyası çalıştırmasını sağlayabilen herhangi bir kullanıcı, Apache'nin kendisiyle aynı erişimi elde edebilir.

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 dezavantajlarına sahiptir. Kanımca, yüksek güvenlik gereksinimleri olan herhangi bir site, VirtualHosts'u paylaşılan bir sunucuda kullanmak yerine özel bir sunucuda çalıştırılmalıdır.


Dikkat edilecek diğer noktalar

Daha önce bahsetmedim, ancak geliştiricilerin web sitesini doğrudan düzenlemeleri genellikle kötü bir uygulamadır. Daha büyük siteler için, web sunucusunu bir sürüm kontrol sisteminin içeriğinden güncelleyen bir çeşit yayın sistemine sahip olmanız çok daha iyidir. Tek sürdürücü yaklaşımı muhtemelen idealdir, ancak bir kişi yerine otomatik yazılımınız vardır.

Web siteniz sunulması gerekmeyen yüklemelere izin veriyorsa, bu yüklemelerin web kökünün dışında bir yerde saklanması gerekir. Aksi takdirde, insanların gizli olması amaçlanan dosyaları indirdiğini görebilirsiniz. Örneğin, öğrencilerin ödev göndermesine izin verirseniz, öğrencilerin Apache tarafından sunulmayan bir dizine kaydedilmesi gerekir. Bu, sır içeren yapılandırma dosyaları için de iyi bir yaklaşımdır.

Daha karmaşık gereksinimleri olan bir web sitesi için Erişim Kontrol Listeleri kullanımını incelemek isteyebilirsiniz. Bunlar ayrıcalıkların çok daha sofistike 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. Kendinizi herhangi bir nedenden dolayı web sitenizi yeniden oluşturmanız gerektiğinde bulursanız, altın ağırlığına değebilir.

347
Nic

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) kısmını neden kullandığını (veya önerdiğini) merak ediyorum. Bu doğru parçayı "0" dan başka bir şeye ayarlayarak, tüm dünyanın dosya/dizinde bir şeyler yapmasına izin vermeniz yeterlidir.

Benim yaklaşımım şöyledir:

  • İki ayrı kullanıcı oluşturuyorum. Biri tüm dosyaların sahibi olacak SSH/SFTP erişimi (gerekirse) ve diğeri PHP FastCGI kullanıcısı (web sitesinin çalışacağı kullanıcı) için). bob ve bob-www .
  • bob klasörlerde tam haklara ( rwx sahip olacak, rw - dosyalarda), böylece tüm web sitesini okuyabilir ve düzenleyebilir.
  • PHP FastCGI işlemi klasörlerde rx haklara ve r - "yazma" izninin de gerekli olduğu cache/ veya uploads/ gibi çok özel klasörler hariç dosyalar üzerindeki haklar. PHP FastCGI bu yetenek, bob-www ve bob-www otomatik olarak oluşturulan bob grubuna eklenecektir.
  • Artık tüm dizin ve dosyaların sahibinin ve grubunun bob bob olduğundan emin oluruz.
  • Bir şey eksik: FastCGI kullansak da Apache'nin statik içerik veya AllowOverrideNone dışında bir şeye ayarlanmışsa okumaya çalışacağı .htaccess dosyaları için okuma erişimine ihtiyacı var. Hakların o kısmını kullanmaktan kaçınmak için, www verilerini kullanıcıyı bob grubuna ekleyin.

Şimdi:

  • Geliştiricinin neler yapabileceğini kontrol etmek için hakların u kısmı ile oynayabiliriz (ancak bu aşağıdaki not).
  • Apache ve PHP neler yapabileceğini kontrol etmek için, hakların g kısmı ile oynayabiliriz.
  • o bölümü her zaman 0 olarak ayarlanır, böylece sunucudaki hiç kimse web sitesini okuyamaz veya düzenleyemez.
  • bob kullanıcı yeni dosyalar oluşturduğunda sorun yoktur, çünkü otomatik olarak ana grubuna ait olacaktır ( bob ).

Bu bir özettir, ancak bu durumda SSH'ye bob izin verilir. Herhangi bir kullanıcının web sitesini değiştirmesine izin verilmemesi gerekiyorsa (örneğin, müşteri web sitesini yalnızca bir CMS yönetici paneli aracılığıyla değiştirir ve Linux bilgisi yoksa), yine de iki kullanıcı oluşturun, ancak Shell olarak /bin/false Verin bob için giriş yapın ve girişini devre dışı bırakın.

    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 u (sahip) haklarını sınırlamanın çoğu zaman işe yaramaz ve güvensizdir, çünkü bir dosyanın sahibi chmod komutunu çalıştırabilir, hatta haklar 000'dır.

Bana yaklaşımımın bazı güvenlik sorunları olup olmadığını söyle, çünkü% 100 emin değilim, ama kullandığım şey bu.

Bu yapılandırmada bir sorun olduğunu düşünüyorum: PHP/Apache yeni bir dosya oluşturduğunda (örn. Upload), bob-www: bob , ve bob sadece okuyabilecektir. Belki dizinde setuid sorunu çözebilir.

14
Fox

Yukarıdaki mükemmel cevabın google rütbesi göz önüne alındığında, dikkat edilmesi gereken bir şey olduğunu düşünüyorum ve cevaptan sonra not bırakamıyorum.

Örneğe devam ederek, dizinte (veya dosyada) 570 izne sahip www-data'yı sahip olarak ve dev-fabrikam olarak grup olarak kullanmayı planlıyorsanız, Linux yoksayırsetuid, böylece tüm yeni dosyalar onları oluşturan kullanıcılara ait olur. Bu, yeni dizinler ve dosyalar oluşturduktan sonra aşağıdakine 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 çalışma izni alamadığım tek bir sorunum vardı. Görünüşte basit bir konu üzerinde artan bir oranda kıllar kaybediyordu ....

9
Paul

"Leo" adlı bir FTP kullanıcınız varsa, example.com web dizinine dosya yüklemeniz gerekir ve ayrıca "Apache" kullanıcınızın önbellek dizininde uploa dosyaları/oturumları/önbellek dosyaları oluşturabilmesi gerekir.

Bu komut leo'yı example.com'a Apache olarak sahip ve grup olarak atar, Apache kullanıcısı Apache grubunun bir parçasıdır, bu yüzden Apache grubunun izinlerini devralır

chown -R leo: Apache example.com

Doğru izni garanti eden ve güvenlik endişelerini de yerine getiren bir başka komut.

chmod -R 2774 example.com

Burada ilk sayı 2 dizin içindir ve oluşturulan her yeni dosyanın aynı grup ve sahip izinlerinde kalmasını sağlar. 77 sahip ve grup içindir, tam erişime sahip oldukları anlamına gelir. 4 diğerleri için sadece oluk okuyabilecekleri anlamına gelir.

aşağıdaki izin numaralarını anlamakta yardımcı olur

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
3
Krishan Gopal

Bu yapılandırma ile gidiyorum:

  1. root sahibine ve root grubuna bir küme, 0755 İzinlerini bir küme yükler.
  2. Tüm dosyalar root ve root grubuna, 0644 İzinlerine ayarlandı.
  3. Dizin ayarını root, grup www-data, İzinleri 1770 Olarak yükler. Yapışkan bit, grup sahibinin içindeki dizini ve dosyaları kaldırmasına veya yeniden adlandırmasına izin vermez.
  4. Inside, klasörlere www-data Sahip kullanıcı ve grup ve dosyaları yükleyen her 0700 Kullanıcı için www-data İzinleri içeren yeni bir dizin yükler.
  5. Apache yapılandırması:

Apache'nin .htaccess Dosyalarını okumaması ve Apache kullanıcısı uploads klasörünün içeriğini endeksleyememesi için uploads dizininde AllowOverride ve Index 'yi reddet.

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

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

6. php.ini Yapılandırması:

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ırmada, www-data Kullanıcı siteDir//tmp Ve /usr/share/phpmyadmin Dışındaki dizinlerin içine giremez. Ayrıca, aynı istekte yüklenecek maksimum dosya boyutunu, maksimum yazı boyutunu ve maksimum dosyaları kontrol edebilirsiniz.

3
Manolo

IMO'nun göz önünde bulundurması gerekenler:

  • dosyalarınızı okuyan bir işleme güveniyor musunuz? Örneğin. PHP?

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

'Test' kullanıcısı orada:

  • $HOMEDIR içindeki verileri
  • postası $MAIL
  • web için verileri /var/www/test

Şimdi düşünelim:

  • bir web uygulaması test kullanıcı (PHP-FPM) altında çalışır - dosyalarından herhangi birini silebilir!
  • bir web uygulaması test grubu (PHP-FPM) altında çalışır - dizinin grup için 'w' olduğu tüm dosyalarını silebilir ve grup için 'r' olan herhangi bir dosyayı değiştirebilir; ve yine de okuyabilir - örneğin ssh tuşlarınız!

Diyelim ki PHP buggy, ve bu open_basedir Güveniyor musunuz? chroot PHP süreç Ne yapmıyorsunuz, tüm dosya sistemlerinde taranmasını istiyor musunuz?

Web uygulama işleminiz, ör. PHP-FPM, sonra:

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

Böylece şunları yapabilirsiniz:

  • test kullanıcısı: test:test
  • test kullanıcısı ikincil bir gruptadır örn. test-www
  • bir web uygulaması (PHP-FPM) test-www:test-www altında çalışır
  • web uygulamasının dosyalarını okuyabileceğini istiyorsa test et: chmod u=rwX,g=rX,o= /var/www/test/public
  • web uygulamasının kendi web veri yoluna yazabilmesini istiyorsa test kullanıcısı: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (böylece uygulama şu şekilde yeni dosyalar oluşturur: test-www:test-www - setgid nedeniyle test-www grubuna sahip olacak dizinde!)

Bu nedenle, web uygulaması işlemi sahte olursa, sadece grup okuması olan belirli dosyaları okuyacak ve sadece upload dir'e yazabilecektir. Bu upload dizinini noexec,nodev,nosuidmount seçenekleriyle bir dosya sisteminde bulundurmanızı ve bu dizindeki yeni tuhaf dosyalar için sürekli izlemenizi ve ayrıca yeni işlemleri izlemenizi önemle tavsiye ederim. test-www uid altında.

Linux'ta izinleri daha iyi ayarlamak için ACL kullanılabilir. Web verilerini yüklemek için birden fazla insan olması gerekiyorsa, insan hesabını web veri dosyalarını yüklemek için kullanılan hesaptan ayırmak daha iyi olur. yeni hesap oluşturmak için örn. test-upload Ve test kullanıcısı, hangi kullanıcının orada ssh/sftp yapabileceğini kısıtlamak için ssh anahtarlarını yönetecekti. sshd_configExposeAuthInfo seçeneklerini bilir, böylece verileri yüklemek için hangi ssh anahtarının kullanıldığını günlüğe kaydedecek şekilde yapılandırılabilir.

Gerçekten çoğu webhosting hizmet ayrıcalık ayırma umurumda şüpheliyim, ne olsun herhangi bir bilgi olmadan 'güvenli' yazarken, yalan söyleyebilirim.

1
Jiri B