Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
teraz wlascicielem katalogu /var/www jest przykladowy user przykladowyuser1, ktorego dodalem do grupy www-data, i moze on wrzucac serwisy www
jak mozna zrobic w lenny, zeby apache (dziala teraz jako user www-data i grupa www-data) dzialal rowniez jako user przykaldowyuser1, tzn byl w stanie zapisywac do katalogu /var/www (i jego podkatalogow)?
Offline
Najwygodniej zainteresuj się czymś takim co się nazywa suPHP tylko do tego proponuję własnoręczną kompilację Apache+PHP+suPHP. Na Debianie średnio mi się udało to skonfigurować poprawnie. Poza tym przy ręcznej kompilacji w/w softu możesz ustawić użytkownika/grupę per vhost.
Offline
winnetou napisał(-a):
Najwygodniej zainteresuj się czymś takim co się nazywa suPHP tylko do tego proponuję własnoręczną kompilację Apache+PHP+suPHP. Na Debianie średnio mi się udało to skonfigurować poprawnie. Poza tym przy ręcznej kompilacji w/w softu możesz ustawić użytkownika/grupę per vhost.
nie chce sie bawic w reczne kompilacje.
do serwera via ftp i tak de facto ma dostep personel - po wprowadzeniu przez nich zmian wrzucaja zmienione pliki serwisow lub inne rzeczy na serwer via ftp i chodzi o to, zeby nie trzeba bylo logowac sie na konsole i zmieniac prawa/uzytkownikow do tego, co zrobia.
a czasem zrobia cos, co wymaga, zeby serwer mogl zapisywac sobie w jakims tam katalogu (np. pliki cache czy inne takie)
Offline
Najlepiej to zainteresuj się modułem userdir(public_html w ~/) i włącz obsługę php5(php5.conf, będziesz musiał coś zakomentować - czytaj komentarze w pliku) dla użytkownika.
Wszystko to zrobisz w /etc/apache2/mods-available i /etc/apache2/mods-enabled.
Drugi katalog informuje nas jaki moduł jest(czyt. powinien być) obecnie włączony. Tworząc(usuwając) symlinki z /etc/apache2/mods-available do /etc/apache2/mods-enabled możesz włączać(wyłączać) kolejne moduły.
Offline
cyb napisał(-a):
do serwera via ftp i tak de facto ma dostep personel - po wprowadzeniu przez nich zmian wrzucaja zmienione pliki serwisow lub inne rzeczy na serwer via ftp i chodzi o to, zeby nie trzeba bylo logowac sie na konsole i zmieniac prawa/uzytkownikow do tego, co zrobia.
a czasem zrobia cos, co wymaga, zeby serwer mogl zapisywac sobie w jakims tam katalogu (np. pliki cache czy inne takie)
Hm... masz serwer FTP który nie pozwala na zmianę uprawnień? Który to?
Offline
ethanak napisał(-a):
Hm... masz serwer FTP który nie pozwala na zmianę uprawnień? Który to?
uprawnienia moze zmieniac, ale chyba nie zmieni wlasciciela plikow.
chodzi o to, zeby wszystko bylo proste, latwe i przyjemne i zeby nie bylo pomieszania, ze czesc plikow jest uzytkownika ftpowego, a czesc serwera www i ftpowiec nie moze ich np. skasowac.
poza tym o zmianie praw trzeba pamietac - a w ferworze walki jak wiadomo zapomina sie o szczegolach :)
dlatego zrobic od razu cos lepiej, zeby pozniej bylo latwiej i nie trzeba bylo pamietac o szczegolach :)
Offline
No to tylko suexec/suphp. Nie wiem jak na debianie, ale na centosie działa. Jedyny problem to taki że php działa jako cgi - ale to jest do przeżycia.
Offline
tak z ciekawosci, zmiana w /etc/apache2/envvars
linii:
export APACHE_RUN_USER=www-data
na:
export APACHE_RUN_USER=userek1
powoduje ze procesy zaczynaja chodzic jako userek1.
ale czy taka podmiana jest bezpieczna z punktu widzenia bezpieczenstwa?
Offline
cyb napisał(-a):
tak z ciekawosci, zmiana w /etc/apache2/envvars
linii:
export APACHE_RUN_USER=www-data
na:
export APACHE_RUN_USER=userek1
powoduje ze procesy zaczynaja chodzic jako userek1.
ale czy taka podmiana jest bezpieczna z punktu widzenia bezpieczenstwa?
Apache ma wtedy uprawnienia użytkownika którego został uruchomiony - więc jak użytkownik może zrobić np:
rm -rf /home
to i Apache to może zrobić. Bezepieczeństwo w takim wypadku zależy m.in od uprawnień jakie ma dany użytkownik w systemie, aczkolwiek nie tylko. Bezpieczeństwo to temat rzeka ;)
Offline
winnetou napisał(-a):
więc jak użytkownik może zrobić np:
Kod:
rm -rf /hometo i Apache to może zrobić. Bezepieczeństwo w takim wypadku zależy m.in od uprawnień jakie ma dany użytkownik w systemie, aczkolwiek nie tylko.
nie pomyslalem o najoczywistszym - pierwsza mysl: "jak dorwie haslo usera to i tak moze nabroic", ale druga juz byla
"ale jesli dobierze sie do apache od d4 strony, to nie znajac hasla moze wszystko rozwalic".
dzieki za zwrocenie uwagi :)
Ostatnio edytowany przez cyb (2010-07-29 20:12:41)
Offline
jak mozna zrobic w lenny, zeby apache (dziala teraz jako user www-data i grupa www-data) dzialal rowniez jako user przykaldowyuser1, tzn byl w stanie zapisywac do katalogu /var/www (i jego podkatalogow)?
bzdura.
Zwykły użytkownik -aby się zalogować, potrzebuje aktywnej powłoki shell (domyślnie bash, czasem zsh lub inna).
Taka powłoka pozwala na uruchamianie skryptów i jest potencjalnie niebezpieczna.
Natomiast apache działa na prawach użytkownika systemowego z domyślnie ustawioną powłoką /bin/false - która uniemożliwia użycie powłoki i znacząco obniża ryzyko działania exploita lub innego groźnego kodu.
A jak powloka fallse - to za malo, to zawsze sa jeszcze jaile/chrooty, apparmor/tomoyo/selinux/grsecurity, mod-security i mod-evasive, i suhosin do php.
Natomiast strona i skrypty php - elementy wykonywalne (skrypty), oraz foldery -uprawnienia 755, pliki - które nie wymagają atrybutu wykonania - 644.
Ważne -żeby właścicielem plików nie był apache lub grupa www-data, ale użyszkodnik.
Wtedy apache pokazuje - serwuje pliki, ale z poziomu usera systemowego www-data (apache) nie można zmienić ani jednego bita w plikach strony www.
A strony użytkowników najlepiej chodzą na hostach wirtualnych - pod adresem http://użyszkodnik.domena.com/
Można tez prościej: podlinkować folder /home/użyszkodnik/publiczny do /var/www/użyszkodnik, i mamy stronę użyszkodnika pod adresem http://domena.com/użyszkodnik/
To by było na tyle
;)
Ostatnio edytowany przez Jacekalex (2010-07-29 20:45:02)
Online
Jak znam życie problem dotyczy php działającego jako moduł. Jeśli tak proponuję rozważyć użycie fastcgi.
Offline
Jacekalex napisał(-a):
Zwykły użytkownik -aby się zalogować, potrzebuje aktywnej powłoki shell (domyślnie bash, czasem zsh lub inna).
Taka powłoka pozwala na uruchamianie skryptów i jest potencjalnie niebezpieczna.
Natomiast apache działa na prawach użytkownika systemowego z domyślnie ustawioną powłoką /bin/false - która uniemożliwia użycie powłoki i znacząco obniża ryzyko działania exploita lub innego groźnego kodu.
Bzdura...
http://pl2.php.net/manual/en/function.popen.php
http://pl2.php.net/manual/en/function.exec.php
Jaki problem odpalić /bin/bash plik.sh?
Offline
@Jacekalex
Jak już Mino zauważył - bzdura. Wcale nie potrzebujesz powłoki żeby odpalić z poziomu PHP jakikolwiek skrypt. Przede wszystkim w php.ini należy zablokować funkcje typu exec(), shell_exec() czy system(). Nawet jak odpalisz apacza z użytkownikiem nobody:nogroup wgrywając PHP_Shell jesteś w stanie w systemie sporo nabroić ;] Do blacklistowanych opcji dodałbym jeszcze fopen, furlopen i kilka innych. Ponadto jak chcesz się zabezpieczyć np przed rozsyłaniem spamu to zablokował bym mail().
Z ciekawostek hasło roota w 3 poleceniach
Na szczęście w Debianie od Lennego nie działa ;)
Także proponuję poczytać na temat "niebezpiecznych funckji PHP oraz na temat zabezpieczeń ogólnie - grsec oraz suPHP/suEXEC to podstawa jeśli na poważnie podchodzisz do bezpieczeństwa serwera WWW i systemu w ogólności
Offline
milyges napisał(-a):
Jacekalex napisał(-a):
Zwykły użytkownik -aby się zalogować, potrzebuje aktywnej powłoki shell (domyślnie bash, czasem zsh lub inna).
Taka powłoka pozwala na uruchamianie skryptów i jest potencjalnie niebezpieczna.
Natomiast apache działa na prawach użytkownika systemowego z domyślnie ustawioną powłoką /bin/false - która uniemożliwia użycie powłoki i znacząco obniża ryzyko działania exploita lub innego groźnego kodu.Bzdura...
http://pl2.php.net/manual/en/function.popen.php
http://pl2.php.net/manual/en/function.exec.php
Jaki problem odpalić /bin/bash plik.sh?
Pisałem o Apachu, nie o php - konfiguracja php i wyłączenie potencjalnie niebezpiecznych funkcji,
to elementarz zabezpieczenia serwera, lecz pytanie było o apacha z działającego z uprawnieniami użytkownika.
A o ile się nie mylę, php nie jest integralną częścią Apacha.
To by było na tyle
Online
Natomiast apache działa na prawach użytkownika systemowego z domyślnie ustawioną powłoką /bin/false - która uniemożliwia użycie powłoki i znacząco obniża ryzyko działania exploita lub innego groźnego kodu.
Bzdura
U mnie Apache domyślnie instalowany w debian lenny 5.0.6 ma powlokę /bin/sh
Mam pytanie.
Czy jak dodam usera systemowego do grupy www-data, katalog domowy ustawię na user.www-data (czyli właścicielem jest user a grupa www-data) oczywiście zmienie domyślnego publica z /var/www na /home/user to czy jest to złoty środek do pogodzenia ftp z serwowaniem stron www w tym samym katalogu?
Offline
O ile twój Apache dziala w internecie to radziłbym dać mu powłokę /bin/false i gruntownie zabezpieczyć wykonanie skryptów php i innych - działających po stronie serwera: perl, cgi, python, ruby.
Do tego pliki na serwerze - właściciel inny niż www-data, wyświetla i wykonuje skrytpy.
Pliki uprawnienia 644, skrypty i foldery 755, foldery cache i tmp (np joomli) uprawnienia 777.
Wtedy trochę podziała, aż ktoś go potraktuje atakiem slowloris, wtedy docenisz rewerse proxy.
http://forums.gentoo.org/viewtopic-t-834620-view-pr … e5b99b53b5ab3
Pozdrawiam
Ostatnio edytowany przez Jacekalex (2010-10-12 22:55:53)
Online
ja jednak będę się upierał przy suphp :P Wtedyt prawa na $HOME dla apacza wystarczą np 700 lub 711 co jeszcze bardziej ograniczy dostęp do np listowania katalogów (bez prawa read nie możliwe jest np wykonianie polecenia "ls"). Oczywiście poza zabezpieczeniem apacza pasuje zajać się php/ruby i innymi co mają działać na serwerku.
Offline
A ja nie rozumiem jednego w tym wątku:
Autor wątku - Cyb, ani jednym słowem nie wspomniał o php.
Natomiast milyges wyskoczył ze skryptami php, ty go poparłeś.
To, że do php warto wziąść np safe-mode, suhosin, i wyłączyć wszystkie nieużywane funkcje,
typu system i podobne, a do tego załadować apacha do chroota, albo przynajmniej ustawić mod-security (ma opcję chrootowania apacha) - to dla mnie jasne jak słońce.
Ale to, że apache nie zawsze służy do do php, ale czasem też jako serwer plików - sam miałem taki cyrk, jak pracowałem w reklamie - reklama na PC (Windows) - redakcja - iMaci, sieć wspólna - maci nie obvsługują samby, Windows nie widzi sieci appletalk - dupa blada. Corel na Windzie w redakcji, skład na macu w redakcji. Dupa blada - informatyk z centrali - musicie sobie jakoś radzić.
Sam instalowałem na na windows millenium serwer www i ftp - żeby normalnie przeciągać pliki na maca.
Bo jak ktoś przyniósł reklamę w corelu, i trzeba ją było przerobić na EPS, to potem - trzeba ją było wrzucić do grafików. (jak przyszedłem do roboty - taki plik puszczali mailem (czas dostarczenia - około 2 dni :))) - bo nagrywarki w reklamie nie było, a pendrivy w 2002 roku, to była przyszłość).
A była to reklama całkiem sporego dziennika.
W firmach często na apachu się umieszcza np firmowe spisy telefonów, regulaminy, ogłoszenia, a nawet jadłospisy.
I to w plikach html lub pdf - wytarganych z worda lub accesa.
I IMHO - o to właśnie pytał autor wątku.
jakby chodziło o php - to by napisał o php, prawda?
Ostatnio edytowany przez Jacekalex (2010-10-13 01:21:32)
Online
Suhosin jest domyślnie ładowany w lenny 5.0.6.
Ruby nie jest zainstalowany. Serwer tylko serwuje php
Dziwi mnie jeszcze jedna rzecz. Jeżeli debian stabilny jest dopracowywany pod względem stabilności i bezpieczeństwa bardzo skrupulatnie to po licho userowi www-data nadaje mu sie z automatu powłokę /bin/sh. Czy może mi ktoś ten problem wyjaśnić.
Przeszukałem plik php.ini i dla modułu i dla cli-php nie znajduję funkcji system(), exec (). Czy może mnie ktoś z szanownych forumowiczów nakierować?
Offline