atsuki

No to chmurka w wykonaniu OVH, na razie tylko na stronach kimsufi: http://kimsufi.pl/cloud/

OVH mocno poszło w dol z tym kimsufi, a opłata instalacyjna... po 5 miesiącach się zwraca, huh, za swojego place 2x tyle...

Mea culpa, o to mi chodziło Można, można też dodać to co napisał na liście autor nginxa location ~ \..*/.*\.php$ { return 403; } jak i wiele innych rzeczy... sprawdzanie uploadowanego pliku czy jpeg to jpeg etc. Ale np. Przy wordpressie nie ma żadnego problemu z uploadem pliku i jego wykonaniu. @p Aha. Ale to nie zmienia jednego podstawowego faktu. ile skryptów - for, blogow, cms ma układ katalogów w taki opisany przez ciebie sposób? Ile osób korzystających z nginxa ma skonfigurowane php w inny sposób niż ten podatny? Sposób dodania obsługi php w ten sposób jest w każdym (?) how to w tym temacie... Więc dlatego jest to niebezpieczne...

Rzadko się zdarza.. poza tym, ciągle chodzi o jedną rzecz, zapis w configu nginxa w postacie location ~ \.php$ {} łapie wszystkie pliki php, nie zaleznie gdzie są. Więc nawet jak masz w /images/obrazek.jpg, a skrypty masz w /scripts/index.php dalej obrazek.jpg sie wykona jako php, bo nginx uzyje konfiguracji \.php$ wystarczy, ze nginx uzyje konfiguracji \.php$, skrypt perla sie wyswietli, nginx nie ponowi sprawdzenia, i nie zmieni konfiguracji na \.pl$

true - ale to nie zmienia postaci rzeczy, że informacja może się przydać a dodanie: location ~ \..*/.*\.php$ { return 403; } Nie zaszkodzi to tak samo jak z windowsem xp i używania go na koncie z prawem administratora... też proszenie się o problemy, a procent domowych pecetów z xp nie chodzi na administracyjnym koncie jest niewielki.

Oryginalny post: http://www.80sec.com...nx-securit.html po "ingliszu": http://www.webhostin...475#post6807475 a po naszemu, jest możliwość wykonania dowolnego kodu php (jak z innymi backendami?). możliwy model ataku: 1) prowadzimy hosting obrazków/plików, jest możliwość uploadu plików ogólnie; 2) ktoś wgrywa plik, plik to obrazek.jpg (nazwa czy rozszerzenie nie istotne) z kodem php; 3) dowolne wywołanie bezpośrednie pliku http://domain.tld/pl...cosdowlnego.php spowoduje wykonanie spreparowanego pliku; w zasadzie 99,99% konfiguracji jest podatnych, jak nie cale 100%, np taka: location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; include fastcgi_params; } która jest.. wszędzie, w każdym how to itp. Możliwe formy zabezpieczenia się? Polecam lekturę: http://forum.nginx.o...ead.php?2,88845 // się pośpieszyłem... może miły mod przenieść do działu traktującego o bezpieczeństwie? :>

Jeszcze może dodać rekordy AAAA oraz SRV, nie zaszkodzi

http://www.redhat.co...ps/meminfo.html A tak się głupio zapytam.. co ci ten commited przeszkadza? Sam napisałeś wcześniej, ze przez crony ci serwer nie wyrabia, więc zajmij się problemem, a nie szukaniem innych...

Poczytaj o wykorzystywaniu ramu w linuksie. .htaccess i optymalizacja ramu ?_?

jezeli chodzi tylko o konta ftp... nie lepiej skonfigurować proftpd z mysql (userzy via mysql) i do tego sa skrypty do administracji. Sporo jest tego na howtoforge...

Jak mnie pamięć nie myli.. alias działa w obrębie określonej lokalizacji root w server{}. Czyli gdzieś tam pod server_name dodaj root sciezka; Ale głowy nie dam sobie uciąć :/

Pamiętaj ze nginx działa z prawami usera www-data. A jeżeli odwołujesz się do jakichkolwiek plików innych niż *.php nginx serwuje sam treść, z pominięciem procesu PHP, więc .. masz odpowiedź? :>

hmm.. moze tak, dla przykładu: /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u user -g grupa -f "/usr/bin/php5-cgi -c /etc/php5/cgi/dowolne.ini" -C 1 -P /var/run/fastcgi-php.pid

hint - fastcgi poprzez spawn-fcgi bądź lepsze php-fpm, znajdziesz opisy na howtoforge.com

Zablokuj komende shell_exec, i wszystkie inne, ktore uznasz za stosowne. jak masz kilku userow tylko to np mozesz kazdemu dac oddzielny process php z wlasnym userem. Mozesz dokompilowac fpm do php... opcji jest sporo