O tym, że nie ma idealnych systemów chyba wie każdy. Mnie to mówiono na studiach, pisano o tym w książkach i w sieci.

“Integracja cały czas trwa, bo nie jest to projekt, który można by zwyczajnie zakończyć. Jest ona potrzebna, bowiem nie ma idealnych systemów, są tylko najlepsze rozwiązania dziedzinowe” – mówi Bożena Małczak-Koziarska. Te zaś trzeba ze sobą łączyć, co, jak przyznaje Bożena Małczak-Koziarska, nie zawsze jest łatwym zadaniem, ale nigdy nie jest tak, by jakiegoś systemu w ogóle nie dało się połączyć z pozostałymi.

Ot, mały cytat stąd, żeby nie być gołosłownym

Było też wiele wojen (słownych) między miłośnikami Windowsa i Linuxa jeśli chodzi o systemy operacyjne, a na GoldenLine.pl dyskutowano nad wyższości jednych nad innymi systemami cms. Zostańmy przy systemach CMS, by nie zagłębiać się nadto w inne typy/rodzaje/kategorie systemów.

Kilka lat temu (coś koło roku 2004 lub2005) jak pierwszy raz zetknąłem się z Mambo (a później Joomlą), nie miałem pojęcia, że ten CMS uprzyjemni mi życie i że stanę się jednym z maniaków tej Joomlowej społeczności, spędzającym wiele godzin na instalacji i testach nowych wersji systemu oraz rozszerzeń, czy modyfikacji dodatków.  Przez ten czas przybyło jakże ciekawych doświadczeń i ponad 1GB plików na dysku z kolejnymi wersjami i rozszerzeniami. A Czy ktoś włamał się na Twoją Joomlę? Kilka razy słyszałem to pytanie, a dwa razy miałem “przygodę” z włamaniem przez tureckich hakerów (Script kiddie):

• jedna ze stron, którą przejąłem w spadku była postawiona na bodajże Mambo 4.5.1 (początek grudnia 2006)

• druga na J! 1.5.0 ale po instalacji i wgraniu indywidualnie przygotowywanej templatki oddałem w cudze ręce, które nie zadbały o aktualizacje (początek grudnia 2008)

Poza własnymi doświadczeniami o włamaniach (i wadliwej Joomli) spotkałem się nie raz czy to na różnych blogach czy w Dzienniku Internautów (Shakowana strona joomla.org – zrzut by ‘krecik’). Pamiętajmy, że nie tylko na Joomlę można się włamać. Także WordPress jest podatny na włamania (vide: antyweb zhakierowany), a inne systemy także wymagają aktualizacji z powodu luk w zabezpieczeniach: Contenido, Drupal, Typo3. Głośna w 2008 roku była sprawa wycieku danych z PKO SA, za sprawą źle zabezpieczonego folderu na serwerze. Mnie kiedyś też udało się odkryć jedną podobne zaniedbanie w serwisie jednego klienta Agencji Interaktywnej. Tylko zamiast  wpisu na wykopie czy blogu (jak Kminek) wysłałem mail z informacją do pracownika Agencji (było warto, po jakimś czasie zaproponowano mi spotkanie w sprawie pracy). Praktyka pokazuje jak widać różne przypadki od włamań przez ludzkie zaniedbania i błędy.

Zainteresowanie nowym Joomla! ze strony krakerów jest zrozumiałe – popularny, najczęściej stosowany, łatwy w zarządzaniu, a przy tym jeszcze ubiega się o honory i najwyższe oceny w rankingach.
Doświadczenie z Joomla 1.0 pokazuje, że nawet wiele lat pracy nad systemem (początki sięgają wszak 2001 roku) nie chroni przed lukami w bezpieczeństwie. Jeszcze w ostatniej wersji 1.0.15 eliminowano różne usterki w tej mierze. Stabilną wersję Joomla 1.5 wydano w styczniu, mamy wrzesień – ukazało się kolejnych 6 poprawionych wydań. Coraz doskonalszych, ale przecież nie doskonałych!

Niefrasobliwość administratorów? Owszem, mamy z nią często do czynienia, ale też nie wszystko od nich zależy. Po pierwsze, ochrona serwisów to także zadanie administracji serwerów!

(źródło: Dziennik Internautów)

“Niefrasobliwość administratorów” to dobre określenie. Pamiętajmy, że na Joomli stronę postawić i skonfigurować jest łatwiej (niż np. Drupalu) a poza osobami “siedzącymi w temacie” biorą się za to osoby, które poczytali trochę w sieci (omijając zapewne wskazówki z pomocy Joomli i  10 najgłupszych tricków administratora Joomla) i wydaje im się, że jak strona działa można spocząć na laurach.

O sposobach na zabezpieczenie Joomli pisano już wiele razy, więc “Ameryki nie odkryję”.

Mogę jedynie wskazać te oczywiste, najważniejsze:

• register_globals is off
• safe_mode is off
• zmieniona login użytkownika (Super Administratora) ‘admin’ na jakiś inny
• zabezpieczony hasłem katalog ‘administrator’
• nie zapisywalny plik configuration.php
• dobrze ustawione uprawnienia dla katalogów i plików
• aktualizacje systemu, jeśli wyjdą nowe wersje
• robienie kopii plików (np. raz na tydzień w zależności jak często aktualizujemy nasz serwis) i zrzutów bazy (np. przy pomocy LazyBackup – i możemy spać spokojnie )

Do wykonania większości z powyższego wykazu z pomocą może nam przyjść Komponent GuardXT (wydany w styczniu 2009, więc całkiem świeżutki), dzięki któremu uda nam się ustawić powyższe.

GuardXT w akcji na jednej z moich stron

Po zainstalowaniu rozszerzenia, przy 20 pozycji z listy powinniśmy mieć zapalone zielone światło. Jeśli przy którymś z elementów świeci się nam czerwona “lampka”, możemy użyć konfiguratora, lub ręcznie wykonać właściwą operację: wgrać odpowiedni plik (np. .htaccess) albo zmienić kilka linijek w php.ini (a jeśli nie mamy do tego pliku dostępu: napisać “ładny mail”;P do administratora serwera).

Dopisek #1:

Dodatek testowałem na J! 1.5.9, na serwerze nazwa.pl, na którym czerwona “lampka” pali mi się przy “Initial run not yet executed”, niestety mimo prób przez ten etap nie mogę przejść, może ma ktoś jakiś pomysł, bo nie chce mi się już ślęczeć po nocy

Dopisek #2

W związku z paniką jaką sieją co niektórzy na forach, to do sposobów zabezpieczeń, przed hakerami, botami zamieniającymi pliki index.php możnaby jeszcze dopisać:

• blokowanie IP

W sumie sprawa prosta, bo albo instalujemy dodatek Ban IP Address i wpisujemy sami adresy IP do blokowania (takie listy znajdziemy np na exinfm.com, lub chongqed.org albo umieszczamy gotowy .htaccess w katalogu głównym z Joomlą. Można też posłużyć się skryptem, który będzie codziennie aktualizował plik z listą adresów IP.