środa, 23 grudnia 2009

KMS - kocham w pupę

Xorg lub GDM (nie chce mi się dociekać co dokładnie) próbuje nas uraczyć KMS-em (Kernel mode-setting) - u mnie konkretnie dla sterownika radeon. Efekt jest tego taki, że przełączenie się na konsolę (Ctrl+Alt+Fx) i z powrotem powoduje, że nie da się więcej przełączyć na konsolę - zobaczymy jedynie czarny ekran.

Próba wyłączenia w bootloaderze: tzn.: radeon.modesetting=0 oraz nomodesetting wyłącza co prawda KMS, jednak X-y działają śmiertelnie wolno - jak nie urok to sraczka. Góglałem za tym, ale nie znalazłem nic rozsądnego. Bardzo mi się to podoba, jak ktoś siłowo wciska mi kompletnie zbędny bajer (KMS), i nie można znaleźć żadnych rozsądnych informacji ścierwo wyłączyć. I jak tu nie kochać zamkniętych sterowników?

piątek, 11 grudnia 2009

Jak namierzyć spamerski ścierwo na serwerze wuwuwu?

Infekcje serwisów internetowych, na hostingu dzielonym, to codzienność. W tej notce postanowiłem podzielić się doświadczeniem w namierzaniu i eliminowaniu tego badziewia, a jest ku temu powód, infekcje serwisów zwykle mają na celu wywoływanie ataków DoS lub wysyłania nieprzebranych ilości spamu.

Ofiara


W przypadku Apache z mod_php, namierzenie serwisu, który został skompromitowany może nie być łatwe, bo to piekielne robactwo próbuje się ukrywać. Wszystkie takie procesy działają z prawami serwera HTTP, co przy setkach serwisów nie ułatwia sprawy. Zainfekowany skrypt PHP często pobiera sobie skrypt perlowy(po HTTP), któremu nadaje losową nazwę, uruchamia go w danym katalogu (np.: ./ofenvrb.pl) i usuwa plik. Powoduje to pojawianie się procesów o losowych nazwach bez plików z kodem źródłowym.

Objawy


Zwykle takie robactwo nie jest w stanie przeciążyć rozsądnego serwera lub łącza, za to jest w stanie wyczerpać limit tablicy conntrack netfiltera na routerze(o czym dalej). Kilka procesów o losowych nazwach (o których wcześniej) będą wyraźnie widoczne w topie. Pomocny będzie także netstat:
# netstat -tlnp

który pokaże dużo nawiązanych połączeń TCP na port 25, a czasami nawet i 80. Ostatnio wyniuchałem ścierwo, które wysyła dużo żądań do jakichś programów CGI na zewnętrznych serwerach. Tu nam życie ułatwi ngrep:
# ngrep cgi-bin "port 80"

CGI jest już na tyle rzadko stosowane, że nie będzie nam zaciemniać wyników działania programu.

Na widelcu


Dla zasady sprawdzamy co zwróci nam lsof dla PID-u nieproszonego procesu:
# lsof -p PID

i tak jak można było się spodziewać nic się nie dowiedzieiliśmy. Próbujemy także macać pseudosystem plików /proc:
# cat /proc/PID/cmdline

jednak i to nie zawsze pomaga. Dobrym pomysłem jest użycie antywirusa, clamav wykrywa wiele rodzajów infekcji serwisów:
# clamscan -ri /foo/bar

Kiedy powyższe zawodzi pozostaje jeszcze jedna sztuczka, mało wyrafinowana ale całkiem skuteczna. Teraz my skorzystamy z podstępu: stworzymy wrapper na perla. Zmieniamy nazwę /usr/bin/perl np. na /usr/bin/perl_bin a jego miejsce wrzucamy taki oto skrypcik:

#!/bin/bash
echo -e "$PWD \nargs: $@ \n$(lsof -p $PPID)" \
| mail -s 'PERL' qwiat@foo.bar
/usr/bin/perl_bin $@


Skrypcik wyśle maila z kilkoma wartościami zmiennych środowiskowych i przy okazji to co zwróci lsof. Jeśli na serwerze bardzo intensywnie korzysta się z Perla, lepszym rozwiązaniem może być przekierowanie wyjścia do pliku. Teraz powinniśmy znaleźć zainfekowany serwis i odpowiednio się nim zająć.

Słowo na koniec


Teraz kilka słów o prewencji. Jak już wspomniałem doskonałym sposobem na wykrycie działającego robactwa jest pomiar rozmiaru tablicy conntrack (jeśli mamy linuksa na routerze). W tym celu użyjemy programu conntrack:
# conntrack -L | wc -l

Do stałego monitorowania (np. Nagios, Cacti) możemy użyć SNMP i obiektu tcp.tcpCurrEstab.0 zwracającego listę nawiązanych połączeń TCP. Niegłupim pomysłem też byłoby regularnie (z crona) odpalać antywirus.