Polskie Forum Użytkowników Debiana

Serwer Ftp (np. Proftpd) ma taką opcję:
DefaultRoot ~
która robi to samo co DocumentRoot w apache.

Po za tym, można tworzyć sekcje <directory>, w których można ustawić użytkownikom prawa do zapisu i odczytu. Więc przy odpowiedniej konfiguracji, nie trzeba się martwić tym, że jeden odczyta, a drugi nie.

Po za tym, pliki konfiguracyjne można umieszczać poza public_html ale nadal w katalogu domowym użytkownika, wtedy odpada problem podglądania przez innych w shellu.

miszmaniac pisze:Serwer Ftp (np. Proftpd) ma taką opcję:
DefaultRoot ~
która robi to samo co DocumentRoot w apache.

To chyba nie jest dokładnie to samo.

DefaultRoot ~ uniemożliwia wyjście "userowi" ponad ten katalog.

Natomiast DocumentRoot w apache to jest wskazanie gdzie domena ma zacząć natomiast w żaden sposób nie ogranicza skryptów do sięgania w inne miejsca.

Oczywiście można różnie pokonfigurować php/apache i tak aby nie było dostępu do innych kont ale szczerze mówiąc na (bardzo) wielu serwerach nie jest to pozabezpieczane i dopiero po jakimś włamie administratorzy "sprzątają".

Oczywiście jest tak jak mówisz. Ja miałem na myśli zabezpieczenie ze strony wejścia przez ftp do niepożądanego katalogu.

Po za tym, nie wiem czy już o tym było czy nie, bo się wyłączyłem na chwilę z wątku

, ale w php.ini jest opcja safe_mode, to z jakiejś strony znalazłem:

Włączenie opcji safe_mode steruje dostępem do plików, udzielając go jedynie właścicielom. Uniemożliwia więc odczyt bądź modyfikację pliku innego właściciela niż autor wykonywanego skryptu. Inaczej mówiąc, wykonywany skrypt ma dostęp do innych plików, ale tylko tego samego właściciela.

Drugą ważną funkcją safe_mode jest ograniczenie możliwości uruchamiania poleceń systemowych z poziomu aplikacji PHP oraz ograniczenie dostępu do zmiennych środowiskowych. Opcji safe_mode nie da się jednak ustawić w pliku .htaccess, tak jak było to możliwe w wypadku register_globals.

Jeżeli chcemy wyłączyć dostęp tylko do wybranych funkcji, możemy użyć opcji disable_functions. W ten sposób zablokujemy np. wykonywanie poleceń systemowych. Postępując zgodnie z zasadą udostępniania tylko tych funkcji, które są potrzebne do działania skryptu, należałoby do pliku konfiguracyjnego dodać następującą instrukcję, w której zablokowane funkcje wymienione są po przecinku:

disable_functions shell_exec, mail, exec, system

Polecenia systemowe są domyślnie wyłączone w trybie safe_mode. Czasami jednak potrzebujemy jednego z poleceń systemowych, ale nie chcemy rezygnować z safe_mode. Rozwiązaniem jest utworzenie specjalnego katalogu poleceń dostępnych w safe_mode, skopiowanie do niego odpowiednich plików oraz dopisanie do php.ini następującego wiersza:

safe_mode_exec_dir=/bin/php

gdzie /bin/php jest przykładową ścieżką do tego katalogu.

Są też inne opcje takie jak np open_basedir. Ale to wszystko zależy od administratora czy je odpowiednio pokonfiguruje w debianie (bo chyab o tym jest to forum

) domyślnie te opcje są wyłączone (o ile dobrze pamiętam) i trzeba je samemu włączyć i odpowiednio poustawiać.

Wszystko zależy od wiedzy administratora i potrzeb do jakich serwer ma być używany.

jaSS pisze:Nie wiem czy nazwałbym to "spapraniem" ale jest to domyślna konfiguracja zazwyczaj.

Moim zdaniem pozostawiane dziurawych konfiguracji jest spapraniem. Co innego jak poprostu nie trzeba zmieniac bo np. jest tylko jedna strona, albo masz strone mamy i taty a co innego jak sie hostuje kilka i jeszcze bierze sie za to pieniadze.

A wracajac do tematu, nie do konca rozumiem w czym problem?
Tak jak ja to widze:
1) Jest dwoch uzytkownikow i obaj maja strone w ~/public_html
2) Obaj maja dostep do shella i nie powinni miec dostepu do swoich katalogow
3) Jak user nie ma dostepu do katalogu nadrzednego to nie ma do podrzednych, wiec odpowiedni dostep do ~ jest wystarczajacy. Apache powinien sie dobrac i tak.
4) Z tego co kojarze, to ~/public_html rzadzi sie troszke innymi prawami (zwlaszcza dostepu) niz inne katalogi do ktorych apache ma dostep.
5) Jesli 3 nie dziala to: nadac chmoda 750 na ~/public_html a admin wczesniej ustawil chgrp www-data i bit sticky (albo setgid - nigdy nie pamietam) na tenze katalog.
6) dostep z zewnatrz przez http://www.domena.com/config.php zrobi PARSOWANIE pliku php i o ile tam sa tylko deklaracje zmiennych (host, user, pass do bazy danch) nie zostanie nic wyswietlone. Co innego jak ktos robi konfiguracje w pliku txt albo ini i go parsuje recznie czy tam automatycznie, wtedy tylko htaccess pomoze.
7) Nie mam pojecia po co numeruje linijki

Stawi pisze:jaSS napisał/a:
Nie wiem czy nazwałbym to "spapraniem" ale jest to domyślna konfiguracja zazwyczaj.

Moim zdaniem pozostawiane dziurawych konfiguracji jest spapraniem. Co innego jak poprostu nie trzeba zmieniac bo np. jest tylko jedna strona, albo masz strone mamy i taty a co innego jak sie hostuje kilka i jeszcze bierze sie za to pieniadze.

Dlatego napisałem w ostatnim poście że wszystko zależy od celów do jakich serwer ma być używany.

A nie jedna firma "hostingowa" typu krzak nie stawia serwerów po to żeby były sprawną częścią internetu tylko po to żeby zgarnąć kasę i się zwinąć zanim ktokolwiek coś wydłubie i zrobi awanturę.

No ale to już jest bicie piany nie na temat

Fajnie byłoby jakby wszystkie serwery były odpowiednio zabezpieczone a ludzie grzeczni, mili i np ustępowali starszym miejsca w tramwaju

ale rzeczywistość niestety jest inna.

Więc z mojej strony EOT, no chyba że ktoś zada jakieś konkretne pytanei co do konfiguracji czy czegoś podobnego.

wg mnie najlepiej walnac sobie base64encode a potem decode w innej czesci aplikacji ktora np laczy. Przed lamerem tak sie zabezpieczysz.

base64_encode() zwraca dane zakodowane za pomocą algorytmu base64. Ten sposób kodowania został zaprojektowany, aby móc bezpiecznie przesyłać dane binarne, poprzez warstwy transportujące nie zaprojektowane do obsługi 8 bitowego przesyłania informacji, np. treść emaili.

Na lamera jest dobre md5 a nie base64_encode gdyż dane nią zakodowane można zdekodować przy pomocy innej wbudowanej w PHP funkcji base64_decode.

SHA1

jang pisze:Na lamera jest dobre md5 a nie base64_encode gdyż dane nią zakodowane można zdekodować przy pomocy innej wbudowanej w PHP funkcji base64_decode.

Jedyny problem w tym ze md5 jest hashem a nie kodowaniem, czyli jest jednostronne - z md5 nie zrobisz tego co bylo wczesniej. Nie nadaje sie to do przechowywania hasel bo nie ma jak go potem odzyskac zeby uzyc

Wogole to ktos czytal te metody o ktorych ja mowilem i to testowal? Na moj gust dzialaja w 99% a sa najlatwiejsze i najmniej upierdliwe w realizacji.

[quote="Stawi"]Jedyny problem w tym ze md5 jest hashem a nie kodowaniem, czyli jest jednostronne - z md5 nie zrobisz tego co bylo wczesniej. Nie nadaje sie to do przechowywania hasel bo nie ma jak go potem odzyskac zeby uzyc ]Jeśli chodzi o pytanie które zadał zakładający ten temat to wystarczy to co napisałeś w poprzednim poście, natomiast moja odpowiedź bardziej się tyczy mlyczka który w pliku (chmod 777) przechowuje hasło nie do bazy a do logowania się do panelu administracyjnego

Kod: Zaznacz cały

if ( SHA1($haslo_z_formularza) == $haslo_z_pliku )
{
    echo "Witam admina";
}
else
{
    echo "Na drzewo"
}

tak więc nie jest mu potrzebne odzyskiwanie tylko po prostu musi je pamiętać.

Pozdrawiam

Polskie Forum Użytkowników Debiana

widoczne has