Apache - Spory Load I % Cpu

[Gość normanos]

Hej.

 

Potrzebuje waszej pomocy. Już nie wiem co jest grane. Wczoraj od wieczora dedyk (PIV 3.0 2GB RAM) strasznie mi rzędzi, są spore loady (10-30), 50-100% obciążenie CPU przy zwykłym, normalnym ruchu, przy tych samych skryptach co zawsze, żadnych podejrzanych wzrostów.

Do tego normalne procesy w apache, wiele IP, nic nie wskazuje na ataki, system czysty, przeskanowany.

 

Jedynie co jest podejrzane to, że to się dzieje tak falami. Raz normalnie przy pełnym obciążeniu jest load 0.2-0.4 i nagle przy tej samej ilosci ludzi leci do 10-20. Szybko wskakuje na apachowy server-status, przeglądam procesy i jedyne co jest dziwne, że te wszystkie wysokie % CPU (po 5-20%) zajmuja nagle gify, jpgi i png. ot tak z nagła.

 

w logach nic niepokojącego, na hdd sporo miejsca i na cache i na logi. pamieci z 2GB sporo wolnego.

 

Macie jakies sugestie co jeszcze sprawdzić? Juz nie wiem co ten apache tak zwariował sobie ot tak. Nawet zresetowałem mój kochany 100 dniowy uptime chlip chlip, i na nic to

 

legenda do obrazka:

po 19:00 właśnie wczoraj cos szlag trafił, 100% cpu, zaczeło żreć swap. od tego momentu juz jest huśtawka. w nocy te oznaczone L to standardowe mielenie logów i pare rzeczy z crona.

 

 

update z logów

 

[Tue May 02 19:40:24 2006] [error] [client 127.0.0.1] File does not exist: /var/www/virtual/domena.pl/r57shell
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
sh: line 1: sysctl: command not found
find: /etc/ppp/peers: Permission denied
find: /etc/chatscripts: Permission denied
find: /etc/ssl/private: Permission denied
find: /etc/mysql/backup/mysql/vhcs2: Permission denied
find: /etc/mysql/backup/mysql/cacti: Permission denied
find: /etc/apf: Permission denied
find: /etc/apf.bk06012006-1136564236: Permission denied
find: /etc/apf.bk06012006-1136564499: Permission denied

itd. findem było przeszukanie z pół systemu póki tego wczoraj nie skilowałem.

Włam? przez jakis skrypt. przeszukuje logi apache, modsecurity ale nie widze nic dziwnego.

poza tym nawet jesli cos było wczoraj to dlaczego dzisiaj apache tak wariuje?!?

[patryk 451]

Jeśli user wrzucił skrypt r57shell (czyli dostęp do powłoki systemu z poziomu www, jak masz "luźno" skonfigurowany serwer idealne to wrzucenia exploitów) to lepiej zainstaluj chkrootkit i przeskanuj system...

[Gość normanos]

przeskanowany juz dawno. to byl jakis atak albo przez spreparowany jpg/gif na jakis skrypt php albo na phpmyadmin. szukam dalej.

 

w kazdym razie to bylo wczoraj, ale czemu dzisiaj apache tak rzezi a juz nic nie jest odpalane to nie wiem

[patryk 451]

Sprawdź w httpd.conf czy nie masz jakiś dziwnych dodanych modułow, zmian w konfiguracji, które mogłby wpływać na wydajność.

 

Zobacz też w dmesg czy system nie wyrzuca jakiś błędów dysku/DMA bo to może być także powodem degradacji wydajności.

[Gość normanos]

nie / nie

 

jedyne co jest dziwne, to ze cale to obciazenie wg. server-status z apache powoduja pliki graficzne ?!?

[shive 0]

Nie wiem czy takie dziwne... pliki graficzne to dobry sposób na przemycenie kodu wykonywalnego.

[hyhyhy 0]

Zrob sobie mod_secure i dodaj pare SecFilter`ow, by zabezpieczyć się przed podobnymi akcjami... zmien haslo, zrob apfa i inne cuda tej firmy, poprostu - zabezpiecz server Pozdr.

 

 

 

edit:

a może to nowy bug w vhcsie albo i stary :>

[patryk 451]

Obejrzyj dokładnie co jest w kodzie tych obrazków. : ).

[hyhyhy 0]

Software: VHCS

 

Link: http://www.vhcs.net

 

Attack method: Cross Site Scripting

 

advisory:http://www.aria-security.net/hm/vhcs.txt

 

 

Summary:

 

vhcs is a powerfull Hosting Managment

 

 

Proof of Concept:

 

Admin Require

 

 

[target]/admin/server_day_stats.php?year=2006&month=05&day=2[xss]

 

[target]/admin/server_day_stats.php?year=2006&month=05[xss]&day=2

 

[target]/admin/server_day_stats.php?year=2006[xss]&month=05&day=2

 

Solution

 

contact me: Advisory@Aria-Security.net

 

o prosze, a to akurat ze wczoraj ;-) Pozdr.

[Gość normanos]

oj panowie panowie... wprawdzie admin ze mnie żaden (z konieczności a nie z zamiłowania) ale nie bierzcie mnie (znowu?) za idiotę. coś takiego jak mod_security i wpisy to PODSTAWA przy stawianiu serwera a nie po kilku miesiącach działania.

 

@shive: tak, to dobry sposób ale w aplikacjach a nie w zwykłych obrazkach.

 

@rusel: security działa z masą rulesów juz od 3 miesięcy , APF, BFD i inne rzeczy działaja od kilku miesięcy, serwer zabezpieczony przynajmniej wg. podstawowych rzeczy

 

@patryk: w kodzie obrazków? to zwykłe obrazki typu logoserwisu.jpg wykresik.gif baner.gif normalne, ZWYKŁE pliki. wstrzykiwac kod to można tam gdzie on jest obrabiany, uploadowany etc. a nie do plików które są tylko wyświetlanie i nie mają z tym nic wspólnego. Dodatkowa obserwacja: to rózne, losowe obrazki z całego serwera, wszystkich kont. Ot po prostu teraz jakby wiecej % CPU mu zajmowało pokazanie obrazków. Albo tylko tak pokazuje w server-info

 

@rusel: możesz podac urla do tej dziury? okej, znalazłem

http://secunia.com/advisories/19940/

to nie to. w logach nie ma w ogóle szukania vhcsa.

 

---------------------------------

małe posumowanie: nawet jeżeli był jakiś włam, czy tez raczej imho próba włamu to NIE TŁUMACZY to tego, że serwer w tej chwili dostał zadyszki i ciagle jest wysoki load i % CPU.

 

- brak dziwnych odpalonych plików

- brak jakiejkolwiek aktywności na kontach (trzech) userów

- apache nie mieli żadnych podejrzanych plików

- ruch w normie (wolne, mniejszy nawet)

- rózne ip, różne sajty, wygląda wszystko, ż ejest w normie

-----------

skonczyły mi sie pomysły

 

Cały dzień oglądam topa i procesy apache i jedyne co moge powiedzieć to to, że to co wcześniej apache robił z srednim obciażeniem CPU 0.1-0.8, czasami 1-2% CPU to teraz robi po 2-3% a często 10-20 ;(

[shive 0]

@shive: tak, to dobry sposób ale w aplikacjach a nie w zwykłych obrazkach.

 

W zwykłych obrazkach też Ale prawdopodobieństwo tak wyszukanego ataku jest chyba niewielkie..

[p 3]

Nie wiem czemu nikt nie zwrocil na to uwagi, ale na tych wykresach caly czas zajetosc procka przez system / procesy uzytkownikow jest taka sama. Jedyne co skacze (i to ostro) to WAIT I/O, co w skrocie oznacza, ze dysk sie nie wyrabia (albo ktos leci find'em jak to bylo w tym przypadku). Tlumaczylo by to nawet dlaczego te 'skoki' sa takie dlugie (30-60min), bo w przypadku awari dysku wygladaloby to inaczej (a przynajmniej powinno). Niepokoi mnie za to fakt, ze pomimo tego, ze skillowales ten proces obciazenie nadal tak skacze (bo skacze, prawda?).

[patryk 451]

Średnio 12% iowait w przypadku dysków IDE to normalny wynik - natualne jest także, że kiedy jest więcej odwołan bo Apacza/bazy iowait rośnie bo dysk ma więcej zadań w kolejce. I może to właśnie odwołania do bazy są tym problemem, albo zdalne wywoływanie dziwnych komend przez r57shell (poszukaj czy nie siedzi jeszcze gdzieś na serwerze i skoro masz mod_security zablokuj go..).

 

Nie jest także żadnym problemem wstrzyknięcie kodu w obrazek/txtka/cokolwiek, ale to już temat na inny post .

[Gość normanos]

@p: dokładnie, gratuluje wnikliwej analizy. To co działo się wczoraj to była próba włamu przez r57shell http://www.google.pl/search?q=r57shell

może mi ktoś powiedzieć jaki skrypt, które miejsce jest atakowane przez ten skrypt? http://rst.void.ru/download/r57shell.txt bo niemogłem dojść. Wygooglałem, że to chyba phpMyAdmin ale u mnie nie wystepuje "lużno" dostępny przez www bez hasła.

 

w tej chwili uspokoiło się ale wykres CPU jest wyższy o 10% niż zwykle i jest mocno "powrany" podczas gdy wcześniej stanowił przyjemną falę Do tego wcześniej load też był wmiare ustabilizowany poniżej 0.6-0.8 a teraz dosyć często jest rwany do 1-2. W tej chwili niby nic sie nie dzieje ale i trafik maluteńki, wolne jest

 

[patryk 451]

Pozwole sobie zacytować:

 

Opens a back door via HTTP access. It allows the remote attacker to perform any of the following actions:

 

* Execute shell commands on /bin/bash

* Change file permissions

* Delete files and directories

* Upload files

* Edit files

* Find files

* Show system information

* Dump SQL database

 

Safe_mode/blokada shell_exec itp powinny przeszkodzić kolejnym próbom. Sprawdź crontaba czy nic nie biega sobie w tle, przestudiuj wszystkie uruchomione procesy...

[Gość normanos]

safe_mode to zubożenie php a teo chciałbym uniknąć.

blokada shell_exec? możesz napisac więcej bo w manualu nic nie znalazłem.

 

http://us3.php.net/manual/pl/features.safe-mode.php

jezeli dobrze skumałem to zamiast safe_mode można polegac na open_basedir a to właśnie mam ustawione w apache'u (tylko mozna otwierać w obrębie domeny).

[patryk 451]

Odszukaj linijkę disable_functions w php.ini i dodaj tam przynajmniej shell_exec i exec (po przecinku).

[Gość normanos]

dzięki patryk, shell i exec przyblokowany w php.

[p 3]

Uu... Jak caly czas shell_exec byl wlaczony to kiepsko. Wydawalo mi sie, ze mowiles, ze wszystkie podstawowe rzeczy sa zrobione?

 

A co do obecnego zachowania CPU... Zresetuj maszyne, moze to tylko efekt powlamaniowy? Ostatnio po stress-tescie jedna maszyna jedyne co potrafila zrobic do czasu restartu to 'kernel panic' / 'segmentation fault'. I nie, nie mam zamiaru wdawac sie w dyskusje na temat 'fajnego' uptime

[patryk 451]

True. Rebooty działają cuda : ). Całkiem możliwe, że jeśli kernel jest mocno defaultowy to teraz Twój sprzęt cały czas jedzie na swapie, chociaż nie musi - a po reboocie wszystko mu się przeczyści.

[Gość normanos]

jechał na swapie, reboot, dalej to samo ;(

[patryk 451]

Jesteś pewien, że to Apache? Co pokazuje top?

[Gość normanos]

22582 www-data  15   0 30744  15m  20m S  9.0  0.7   0:02.29 apache2
22587 www-data  15   0 33112  17m  20m S  8.2  0.9   0:00.55 apache2
22446 www-data  15   0 31592  15m  20m S  6.0  0.8   0:00.52 apache2
21815 www-data  16   0 32716  17m  20m S  3.7  0.8   0:02.55 apache2
22690 www-data  15   0 27408  11m  20m S  0.7  0.6   0:00.09 apache2
22581 www-data  15   0 31512  15m  20m S  0.3  0.8   0:00.49 apache2
22588 www-data  16   0 27636  11m  20m S  0.3  0.6   0:00.18 apache2
22686 www-data  16   0 27372  11m  20m S  0.3  0.6   0:00.09 apache2
22698 www-data  15   0 27704  11m  20m S  0.3  0.6   0:00.13 apache2
22699 www-data  15   0 27184  10m  20m S  0.3  0.5   0:00.20 apache2

[patryk 451]

No to pozostaje 'lsof pid' i zobacz co tam tez ten Apacz otwiera, jeśli się upierasz, że to on .

[Gość normanos]

no, panowie, czytajcie bo będzie ciekawie i zabawnie

 

podsumowanie:

był włam. najprawdopodobniej poprzez ściągnięcie skryptu r57shell przez dziurę w jakimś skrypcie toplisty w php. chyba w miejscu, w którym toplista pobiera/sprawdza banner. tak tylko obstawiam bo to było w logach mod_security a wiadomo, że loguje się to co jest zatrzymane a nie co przepuszczone a akurat mase takich wywołań było zatrzymanych.

 

niebardzo wiem jak poprzez ten skrypt z jednego konta dostał się na wszystkie inne i nagral tam plik index.htm z infem, żeby sie zglosic do "hakerów"

 

i tu prośba do was: Co jeszcze zrobić aby po wrzuceniu jakiegokolwiek zlosliwego skryptu nie dalo sie nic więcej zrobic poza danym kontem? niby mam te base_dir i php z jednego konta nie zrobi nic na drugim ale widac tym razem zostało to jakos ominiete. przyblokowac jeszcze jakąś funkcje w php? w apache?

 

-----------

a teraz ta bardziej zabawna rzecz. otóż skarzyłem się na wysoki load/% CPU nieproporcjonalny do trafiku i osiągów sprzed włamu. Miałem racje, że nic nie ma w tle, że to apache/php nagle generuje takie obiciążenie.. bo... he he... uwaga.... podczas ataku wysypał się eAccelerator (zniknął katalog w /tmp?!?) i ja potem go wyłączyłem bo jeszcze nie widziałem gdzie jets problem. Wczoraj uruchomiłem eAcceleratora ponownie i...

jak ręka odjął CPU spadło z 40-50% do 10-15% ! (11% avg) !!! load wrócił z 1-2 na 0.3-0.8 (0.6 avg).

 

Te różnice są spore!!!

 

Powyższy tekst dedykuje Patrykowi, który kiedyś na forum pisał, że nie widzi specjalnych róznic w dzialaniu z accel. i bez