Artykuły dotyczące tematu: Apache

dodany: 25.07.2013 | tagi: , ,

Nowe wydanie Apache 2.4.6

0

Fundacja Apache poinformowała o nowym wydaniu swojego popularnego serwera HTTP, tym razem z gałęzi 2.4.

Wersja oznaczona 2.4.6 łata dwie luki bezpieczeństwa. Podobne poprawki zostały wprowadzone dwa tygodnie temu do 2.2.25 – nie do końca jasne jest, dlaczego z takim opóźnieniem zmiany trafiły do najnowszej gałęzi. Luka oznaczona CVE-2013-1896 umożliwiała wyłączenie serwera przez przekazanie odpowiednich danych do mod_dav, a dzięki naprawieniu CVE-2013-2249 każde ID sesji jest unikalne. Ponadto wprowadzono nowy moduł o nazwie mod_macro, ułatwiający zarządzanie konfiguracją.

Pełna lista zmian znajduje się na stronie projektu.

dodany: 23.07.2013 | tagi: , , ,

Apache porzuca rozwój stdcxx

0

Fundacja Apache poinformowała o zarzuceniu rozwoju własnej biblioteki standardowej C++.

Pierwsze wydanie ukazało się 8 lat temu, a ostatnie w połowie 2008 roku. W założeniach stdcxx miało implementować standard ISO/IEC 14882, nie zyskało jednak takiej popularności jak biblioteki dostarczane z gcc czy clang.

Więcej informacji można znaleźć na liście dyskusyjnej oraz stronie projektu.

dodany: 16.06.2013 | tagi: , , , ,

Luka DoS w fail2ban

0

W fail2ban, otwartoźródłowym programie służącym do zabezpieczania serwerów przed atakami brute-force, znaleziono lukę DoS.

Problem dotyczy wersji 0.8.9. Winne są filtry Apache (apache-auth.conf, apache-nohome.conf, apache-noscript.conf, apache-overflows.conf), w których używane jest niedokładne wyrażenie regularne.

Luka została załatana w wydaniu 0.8.10, zalecamy zatem jak najszybszą aktualizację.

dodany: 09.05.2013 | tagi: , , , ,

Malware Apache infekuje także nginx i lighttpd

0

Pod koniec kwietnia informowaliśmy o nowym backdoorze atakującym serwery Apache (zobacz newsa: Kolejny backdoor atakujący Apache). Charakteryzował się on tym, że zastępował plik wykonywalny serwera HTTP na maszynach z zainstalowanym cPanelem, tym samym unikając łatwego wykrycia za pomocą narzędzi menedżera pakietów.

Tym razem atakujący obrali za cel rzadziej używane serwery lighttpd i nginx. Poza tym sposób działania malware wygląda podobnie – wybrani odwiedzający trafiają na szkodliwe strony korzystające z zestawów exploitów takich jak Black Hole.

Jak informują badacze z ESET, odnaleziono rootkita na co najmniej 400 serwerach, a 100 tysięcy użytkowników antywirusa tej firmy zostało przekierowanych na takowe strony. Tak jak już pisaliśmy, szkodnik nie infekuje wszystkich odwiedzających – na jednym z zainfekowanych serwerów znaleziono czarną listę IP, wyłączającą prawie połowę adresów IPv4. Użytkownicy z ustawionym fińskim, japońskim, kazachstańskim rosyjskim, ukraińskim lub białoruskim językiem w przeglądarce także są „bezpieczni”.

Samo przekierowanie inaczej przebiega na przeglądarkach w systemie iOS. Internauci trafiający na stronę z pornograficznymi reklamami mają najwidoczniej w inny sposób przynieść zyski – typowy zestaw exploitów jest całkowicie bezużyteczny na większości mobilnych urządzeń.

Plik konfiguracyjny backdoora przechowywany jest bezpośrednio w pamięci – ESET opublikowało narzędzie, dzięki któremu można sprawdzić czy dana maszyna także stała się ofiarą malware. Nadal nie ustalono, w jaki sposób serwery są infekowane, ale badacze przypuszczają, że nie ma jednoznacznego czynnika. Początkowo obwiniano o to cPanel, lecz okazało się, że używany był na małej części zaatakowanych serwerów.


Więcej informacji można znaleźć na blogu ESET.

dodany: 09.05.2013 | tagi: , ,

Nowy backdoor zagraża serwerom WWW

0

Analitycy z firmy ESET wspólnie z ekspertami firmy Securi, zidentyfikowali zagrożenie, które atakuje najpopularniejszy i najczęściej wykorzystywany na świecie serwer stron internetowych Apache w wersji linuksowej. Z ponad 300 milionów witryn działających w oparciu o serwery Apache większość bazuje właśnie na Linuksie – to właśnie te serwisy znalazły się na celowniku Linux/Cdorked.A. Wizyta na stronie serwowanej przez zainfekowaną maszynę skutkuje przekierowaniem internauty do innego serwisu, zawierającego zestaw exploitów lub treści pornograficzne.

Eksperci z firmy ESET podkreślają, że Linux/Cdorked.A jest zaawansowanym zagrożeniem, które bardzo skutecznie maskuje swoją aktywność na zainfekowanym serwerze. Jedynym śladem działania Linux/Cdorked.A na danej maszynie jest zmodyfikowany plik „httpd”. Wszystkie inne informacje, odnoszące się do backdoora, w tym te dotyczące konfiguracji i kontroli nad zagrożeniem, przechowywane są w pamięci podręcznej serwera – przez co bardzo trudno jest wykryć i przeanalizować jego sposób działania. Analitycy zagrożeń z firmy ESET ustalili, że Linux/Cdorked.A. otrzymuje instrukcje działania za pośrednictwem HTTP. W celu minimalizacji prawdopodobieństwa wykrycia zagrożenia komunikacja ta jest specjalnie maskowana, a przekazywane instrukcje nie są rejestrowane w dzienniku zdarzeń serwera Apache.

Jeśli internauta trafi na stronę, która jest serwowana przez zainfekowanego Apache’a, zagrożenie przekieruje go do serwisu zawierającego zestaw exploitów o nazwie Blackhole. Zestaw ten automatycznie zidentyfikuje i wykorzysta luki wykryte na komputerze użytkownika, instalując na nim kolejne zagrożenia. W ten sposób maszyna może zostać dołączona do sieci zombie, a przejęty komputer może zostać później wykorzystany m.in. do realizacji ataku DDoS (Distributed Denial of Service). W takich atakach maszyny zombie wysyłają ogromną liczbę zapytań do serwerów firm i instytucji, powodując ich zablokowanie. Jeśli na stronę obsługiwaną przez zainfekowaną wersję Apache’a trafi użytkownik iPhone’a lub iPada, zagrożenie przekieruje go do witryny zawierającej treści pornograficzne.

Linux/Cdorked.A stanowi zagrożenie dla przedsiębiorstw, jeśli bowiem infekcja dotknie firmową stronę internetową, a administrator szybko nie zidentyfikuje problemu może dojść do sytuacji, w której serwis WWW zniknie z sieci. Stanie się tak wtedy, gdy zainfekowana strona zostanie zablokowana przez firmę hostingową, wyszukiwarkę internetową lub przeglądarkę WWW. Blokada będzie miała na celu ochronę nieświadomych internautów przed złośliwymi programami, a także zapobieżenie rozprzestrzenianiu się zagrożenia.

O potencjalnej skali działania Linux/Cdorked.A wypowiedział się Stephen Cobb, ekspert ds. bezpieczeństwa IT firmy ESET. Zwrócił on uwagę na statystyki serwisu Netcraft, z których wynika, że w lutym 2013 roku aż 348 milionów stron WWW działało w oparciu o serwer Apache. To ponad 55% wszystkich dostępnych w sieci stron WWW! Znaczna część tych serwerów działa w oparciu o system Linux, a to właśnie linuksową wersję Apache’a bierze na cel Linux/Cdorked.A. Laboratorium antywirusowe firmy ESET zidentyfikowało infekcje m.in. na 50 stronach ze 100.000 najpopularniejszych witryn wg serwisu Alexa.com

Eksperci z firmy ESET radzą wszystkim administratorom, którzy opiekują się stronami WWW działającymi na linuksowych serwerach Apache, aby sprawdzili czy ich maszyny nie padły ofiarą Linux/Cdorked.A. W tym celu można posłużyć się bezpłatnym narzędziem, jakie przygotowali analitycy firmy ESET. Narzędzie dostępne jest na blogu firmy ESET: http://www.welivesecurity.com/wp-content/uploads/2013/04/dump_cdorked_config.c

Źródło: ESET

dodany: 30.04.2013 | tagi: , ,

Kolejny backdoor atakujący Apache

0

Daniel Cid z Sucuri poinformował o odkryciu kolejnego backdoora atakującego Apache, popularny serwer HTTP. Jak wyjaśnia, przez ostatnie miesiące Sucuri było zajęte śledzeniem Darkleecha. Podczas tego czasu zaczęto zauważać zmiany w wektorze ataku. Na serwerach z cPanelem, zamiast dodać własny moduł albo modyfikować konfigurację Apache, atakujący zastępowali plik wykonywalny serwera o nazwie httpd własnym, oczywiście złośliwym.

Tym razem sprawdzenie integralności plików za pomocą menedżera pakietów może nie wystarczyć, jako że cPanel instaluje serwer Apache w innym miejscu. Pewnym sposobem jest sprawdzenie daty utworzenia pliku. Ponadto jeśli za pomocą grepa znajdziecie frazę open_tty w /usr/local/apache, najprawdopodobniej serwer jest zarażony, gdyż oryginalny plik nie zawiera takiego łańcucha. Przed zastąpieniem złośliwego pliku właściwym, należy wykonać polecenie chattr -ai /usr/local/apache/bin/httpd, w innym przypadku system poinformuje o braku odpowiednich uprawnień.

Więcej informacji o skutkach infekcji można znaleźć na blogu Sucuri oraz ESET.

dodany: 12.04.2013 | tagi: , , ,

Luka w mod-security dla Apache i nginx

1

Ukazało się nowe wydanie mod_security dla serwerów WWW Apache i nginx, modułu zabezpieczającego aplikacje sieciowe przed włamaniami, atakami XSS i podobnymi zagrożeniami przez filtrowanie żądań dochodzących do serwera. Wersja 2.7.3 naprawia lukę w parserze XML. Timyr Yunusov i Alexey Osipov z Positive Technologies odkryli, że odpowiednio stworzony plik XML mógł atakującemu dać dostęp do lokalnych plików oraz możliwość nadmiernego wykorzystania CPU lub pamięci. Luka otrzymała sygnaturę CVE-2013-1915.

W liście zmian można znaleźć również dodatkowy przełącznik, SecXmlExternalEntity, kontrolujący czy biblioteka libxml2 będzie ładować zewnętrzne encje podczas przetwarzania plików. Domyślnie jest on wyłączony.

Yunosov i Osipov nie opublikowali jeszcze własnego opisu luki.

dodany: 08.04.2013 | tagi: , ,

Darkleech infekuje serwery Apache

0

Przez co najmniej 9 ostatnich miesięcy, malware Darkleech wstrzyknął niewidoczne dla użytkowników ramki prowadzące do szkodliwych stron w tysiące stron internetowych. W tym celu malware wykorzystuje moduł do Apache, jednego z najbardziej popularnych serwerów WWW. Nie wykryto jednak wektora ataku prowadzącego do zainfekowania serwerów. Co więcej Darkleech uważnie wybiera ofiary, tworząc czarną listę użytkowników, do których nie trafią szkodliwe ramki. Zainfekowane serwery pochodzą z 48 krajów, ale większość z nich znajduje się w Stanach Zjednoczonych, Wielkiej Brytanii i Niemczech.

Cisco postanowiło przyjrzeć się sprawie i w trakcie 6 tygodni w lutym i marcu zaobserwowało 2 tysiące zainfekowanych serwerów. Zakładając, że każdy z nich hostuje 10 stron, co najmniej 20 tysięcy stron internetowych zostało zarażone w tym czasie.

Wstrzykiwane przez Darkleech ramki prowadzą do stron wykorzystujących zestaw exploitów Blackhole, gdzie systemy nieświadomych internautów są zarażane. W skład Blackhole wchodzi wiele luk, w tym w Javie, Flashu, Adobe Readerze i wielu innych. Wiele z tych exploitów działa tylko na nieaktualnych wersjach wcześniej wymienionego oprogramowania.

Same ataki nie byłyby w żaden sposób wyjątkowe, gdyby nie fakt, że iFrames tworzone przez Darkleech generowane są dynamicznie przez moduł Apache. Infekcja jest trudna do wykrycia, bo malware nie ingeruje w kod strony. Co więcej, nie wszyscy użytkownicy są atakowani – na czarnej liście znajdują się zaatakowani internauci, tak samo jak ci przychodzący z wyników wyszukiwania. Blokowani są również pracownicy firm branży security i administratorzy hostingów.

Atakujący korzystający z Darkleecha podmieniają także usługę sshd na zarażonych serwerach, zapewniając sobie zdalny dostęp.

Pełny raport znajduje się na blogu Cisco i Ars Technice.

dodany: 11.03.2013 | tagi: , , ,

Złośliwy moduł Blackhole w CentOS i Apache?

3

Ostatnimi czasy dużą popularność zdobywa Blackhole exploit kit. Badacze z Sophos uważnie obserwują i analizują jego rozwój. Z bardzo prostej przyczyny – narzędzie to używane jest głównie przez cyberprzestępców w celu zainfekowania malwarem.

Jednym z nowszych ataków jest zmodyfikowanie normalnej strony w ten sposób, aby przekierować ruch użytkownika na szkodliwą stronę z eksploitem. W tym celu wykorzystywane są specjalnie spreparowane biblioteki Javascript:

al_js.jpg-w=640

Analogicznie strony są wstrzykiwane za pomocą skryptu online:

al_inline.jpg-w=640

Atak wykrywany jest jako Mal/Iframe-AL. Analizując dane dostępne z Alexy, większość serwerów roznoszących ten rodzaj malware, działa pod kontrolą CentOS-a i Apache. Odpowiedzialny za to może być szkodliwy moduł do tego ostatniego – nie byłoby to pierwsze wykorzystanie tego pomysłu. Administratorzy powinni uważnie przejrzeć pliki konfiguracyjne swoich serwerów pod kątem takich niechcianych zmian.

dodany: 05.12.2012 | tagi: , ,

Pierwsze kroki z własnym serwerem – część 2.

8

Jednym z podstawowych zastosowań serwera (czy to dedykowanego, czy wirtualnego), jest dostarczenie usługi serwera www. Najczęściej jest to kod HTML, kod PHP i baza danych MySQL, które w połączeniu tworzą naszą stronę w sieci. Oczywiście nie zawsze wykorzystuje się taki zestaw, ale niewątpliwie jest on najpopularniejszy. Najpopularniejszym zaś serwerem www wykorzystywanym obecnie na świecie, jest Apache.

Linux, Apache, MySQL i PHP to zestaw, który potocznie nazywany jest stosem LAMP. Jeśli zaufamy statystyce, to decydując się na własny serwer, Wasze potrzeby opisać można właśnie tymi czterema literami. Dlatego też w kolejnych częściach tego artykułu będziemy rozważać zabezpieczenia dotyczące tego stosu.

Na początek zajmiemy się najprostszymi metodami zabezpieczenia serwera Apache. Nie będziemy zagłębiać się w zaawansowane metody zabezpieczeń i studium przypadków.

Podstawową zasadą bezpieczeństwa w tej części jest: „Jeśli nie podasz pewnych informacji na tacy, to napastnik będzie miał utrudnione zadanie”. Jest to dość oczywiste, a jednak niezwykle istotne. Większość systemów serwerowych z rodziny Linux (i nie tylko), domyślnie podaje pewne informacje na tacy. Są to informacje takie jak: rodzina systemu operacyjnego i jego dystrybucja, wersja serwera apache oraz wersja PHP zainstalowanego na serwerze. Wszystkie trzy informacje wymienione powyżej, pozwalają na użycie exploitów dla określonej wersji oprogramowania zainstalowanego na serwerze (jeśli taki exploit istnieje). Exploit to (w uproszczeniu) algorytm, który pozwala wykorzystać niezałataną lukę bezpieczeństwa do skutecznego ataku na aplikację lub cały system.

Jeżeli napastnik nie będzie wiedział jakich wersji oprogramowania używamy, to trudniej będzie mu określić jakiego exploita ma użyć i czy w ogóle posiada takiego, który może nam zaszkodzić. Każda nieudana próba ataku na nasz serwer jest zaś sygnałem, który możemy odebrać analizując logi (co powinniśmy czynić).

Tak więc musimy ukryć następujące informacje:

  1. System operacyjny serwera
  2. Wersja serwera www
  3. Wersja PHP

Poniżej przykład odpowiedzi serwera, który nie ukrywa tych informacji:

Zanim zabierzemy się do zacierania tych informacji, upewnijmy się, że zainstalowane na naszym serwerze Apache oraz PHP są aktualne. Nieaktualne oprogramowanie naraża nas na podatności, które mogły zostać załatane w kolejnych wydaniach.

Zajmijmy się zatem zatajeniem informacji o naszym serwerze. Najczęściej można odczytać tego typu informacje, kiedy wywołamy stronę błędu (np. 404 lub 403):

W nagłówkach wygląda to podobnie:

Rozwiązaniem jest dodanie dwóch dyrektyw do konfiguracji serwera Apache.

  1. Logujemy się przez SSH do naszego serwera
  2. Za pomocą ulubionego edytora edytujemy plik konfiguracyjny Apache’a (najczęściej apache2.conf lub httpd.conf; w dystrybucjach Debian i Ubuntu będzie to plik /etc/apache2/apache2.conf)
  3. Na końcu pliku dodajemy dwie dyrektywy:

Po wprowadzeniu zmian należy ponownie uruchomić serwer Apache:

Pierwsza z dyrektyw wyłącza wyświetlanie sygnatury serwera na stronach (np. błędów 404 lub 403). Dzięki temu w przypadku wywołania błędu, odpowiedź serwera wygląda tak:

Druga z dyrektyw, to ukrycie informacji w nagłówkach http, które wysyłane są przez serwer. Tak zwany token serwera może przyjąć sześć form:

ServerTokens Prod wyświetla Server: Apache
ServerTokens Major wyświetla Server: Apache/2
ServerTokens Minor wyświetla Server: Apache/2.2
ServerTokens Min wyświetla Server: Apache/2.2.22
ServerTokens OS wyświetla Server: Apache/2.2.22(Ubuntu)
ServerTokens Full wyświetla Server: Apache/2.2.22 (Ubuntu) PHP/5.3.5

Często, jeśli nie zdefiniuje się dyrektywy ServerTokens w ogóle, to wyświetlana jest wersja Full, co jest pełnym zestawem informacji dla atakującego. My wybraliśmy dyrektywę ServerTokens Prod, dzięki temu w nagłówkach znajdzie się jedynie informacja, iż stronę serwuje Apache:

Zabezpieczywszy się przed uzyskaniem informacji na temat serwera www, należałoby poczynić podobny krok w stosunku do PHP. Sposób jest równie prosty:

  1. Za pomocą ulubionego edytora edytujemy plik konfiguracyjny PHP (php.ini; w dystrybucjach Debian i Ubuntu będzie to plik /etc/php5/apache2/php.ini)
  2. Wyszukujemy dyrektywę expose_php i zmieniamy jej wartość na Off

W kolejnych częściach artykułu zajmiemy się najprostszymi metodami zabezpieczenia serwera baz danych MySQL.