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.

niedziela, 25 października 2009

Netfilter jako prosty nIDS/nIPS

W świecie Otwartego Oprogramowania jest kilka aplikacji typu nIDS/nIPS, które dzielą się na dwie kategorie:
- Snort
- cała reszta

Snort - narzędzie przyciężkawe i toporne, słyszałem o takich u których działa, u mnie jednak odmawiał posłuszeństwa po kilkunastu dniach pożerania cykli CPU. Cała reszta to zwykle programy, wykrywające skanowanie portów, jak choćby Portsentry. Lubię proste rozwiązania, dlatego zamiast instalować kolejną aplikację, zacząłem dłubać przy Netfilterze. Za pomocą tego firewalla, możemy łatwo stworzyć niezbyt wyrafinowane, ale za to łatwe we wdrożeniu i bardzo wydajne narzędzie.

Podobnie jak w innych aplikacjach tego typu, wykrywa się próby połączeń na porty, którymi nikt nie powinien się interesować. Oczywiście w każdym wypadku lista może być inna. Kto próbuje się dostać na port powinien być z automatu blokowany, poza tym rozwiązanie musi być maksymalnie nieobsługowe, tzn. automatycznie czyścić "czarną listę". padło na wykorzystanie modułu recent, który zwykle jest stosowany do ochrony przed atakami słownikowymi na SSH.

Poniższy listing pozwala wykrywać skanowanie typu: Connect, SYN i UDP. Dwie pierwsze regułki zajmują się reakcją na wykryte skanowanie: pierwsza zapisuje do logów, druga blokuje IP-ka na 12 godzin. Kolejne to definicje portów:


iptables -A FORWARD -m recent --name skanery --update --seconds 43200 --hitcount 1 -j LOG --log-prefix "FW port-scan " -m limit --limit 2/hour
iptables -A FORWARD -m recent --name skanery --rcheck --seconds 43200 --hitcount 1 -j DROP

iptables -A FORWARD -p tcp -d 1.2.3.4 --dport 7 -m recent --name skanery --set
iptables -A FORWARD -p tcp -d 1.2.3.4 --dport 23 -m recent --name skanery --set
iptables -A FORWARD -p tcp -d 1.2.3.4 --dport 111 -m recent --name skanery --set
iptables -A FORWARD -p tcp -d 1.2.3.4 --dport 137 -m recent --name skanery --set
iptables -A FORWARD -p tcp -d 1.2.3.4 --dport 139 -m recent --name skanery --set


Skanowanie Null i Xmas traktujemy jak inne pakiety uszkodzone, jedną regułką:


iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP


Szkoda czasu na zastanawianie się, czy to skanowanie czy zwykłe śmieci.

środa, 9 września 2009

O tym jak zostałem dresem

Ludzie dzielą się na dwie zasadnicze kategorie: na tych, którzy nie założą dresu, jeśli nie uprawiają sportu i na tych troskliwych: "jakiś problem kurwa?". Nawet dziecko wie kim są "Dresy" i myślę, że wbrew wszelkim przesłankom, Oni też mają taką świadomość. Zastanawiałem się nie raz, skąd u Nich taki brak samokrytyki, bo jak wygląda dresik (nawet nowy, błyszczący), każdy widzi. Raczej nie chodzi o pieniądze, bo podrabiane dżinsy, nie będą specjalnie droższe od podrabianych dresów.

O tym, dlaczego dresy są tak popularne u nie-frajerów, dowiedziałem się ze trzy lata temu, w całkiem przypadkowy sposób. Mój serdeczny przyjaciel załatwił wejściówki, dla naszej paczki, na imprezę Kicz Party we wrocławskim klubie Alibi. To miała być zamknięta impreza, przeznaczona dla światka barmańskiego z tanimi alkoholami, na którą ludzie mieli przyjść poprzebierani tak kiczowato, jak tylko możliwe. Przed wyjściem zaczęły się przebieranki, mój kolega założył stalowe spodnie w kancik i sweterek w kratę, modny najdalej w latach siedemdziesiątych. Ja pożyczyłem od jego ojca dresik kreszowy model 89', a do tego bejzbolówka. Reszta brygady też była niezła, tombak na szyjach, woda kolońska Brutal, dziewczyny wygrzebały ze staroci jakieś kuriozalne kiecki i wrzuciły fest makijaż.

Oświeciło mnie jak tylko wysiedliśmy z samochodów, najpierw podeszliśmy do budki z zapiekankami, żeby się nieco posilić. Postanowiłem nieco wczuć się w rolę i zacząłem trenować tradycyjny chód dresa: pewny siebie, nieco przygarbiony, czapka na oczy, łokcie szerzej niż tego wymaga wygoda. Mijaliśmy sporo osób, ale ani razu, nie musiałem nikomu ustępować miejsca na chodniku, nikt nie utrzymał kontaktu wzrokowego dłużej niż sekundę, ani chłopaki, ani dziewczyny. Jako, że okolice Alibi to mekka studencka, to wieczorem najczęściej kręcą się młodzi ludzie. Wygląd reszty mojej wesołej brygady nie łagodził sprawy, za każdym razem wzrok na bok. Byłem niewidoczny! Pod budką z szybkim żarciem, ktoś kolejki o coś mnie spytał, ale wzrok miał tak przepraszający za zawracanie dupy, że aż mi się głupio zrobiło. Podobnie było później w knajpie, może za dobrze grałem?

Generalnie wcale nie byłem zachwycony reakcją ludzi, bo to oznaczało, że z daleka widać, że jestem dresem i nie miałem pojęcia co będzie, jak spotkam prawdziwych. Jakoś nie wyobrażałem sobie, że potraktują mnie jak brata-w-trzech-paskach, a było się czego obawiać. Tamtego dnia odbywał się we Wrocku jakieś mecz piłkarski i przez miasto jechały autobusy pełne rozśpiewanych kibiców. Z tym "śpiewaniem" to mnie nieco poniosło, użyłem go z braku lepszego, równie litościwego eufemizmu. Obawiałem się, że mogę się spotkać z nimi oko w oko i z jakiegoś powodu mogli by uznać, że jestem kibicem przeciwnej drużyny. Miałem równe 50% szans na przeżycie i wcale nie pomagał fakt że nie miałem pojęcia kto z kim grał.

Krótko: dres wzbudza strach i nieufność. Im może się wydawać, że to respekt, ale się mylą. Respekt można czuć do kogoś, kto jest przewidywalny, jak ktoś jest niestabilny niczym nitrogliceryna w Ikarusie, to można czuć jedynie strach. Strach taki, jaki się czuje widząc uciekiniera z domu wariatów* z nożem w zębach.

* Mam nadzieję, że moje komiksowe porównanie nikogo nie obrazi.

sobota, 15 sierpnia 2009

Logi na linksowym desktopie

Tradycyjny model zarządzania logami w uniksie to połączenie trzech aplikacji:
- syslog
- logrotate
- cron

Powyższe trio dobrze się sprawdza na maszynach produkcyjnych, działających 24/7. Logrotate dostarcza cronowi zadanie do katalogu daily, które wykonywane jest codziennie, tuż po północy. Problem zaczyna się na desktopie, gdy komputer jest wyłączany przed wykonaniem zadań w daily. Logi puchną, przechowując bardzo stare i często zbędne informacje. Można kombinować z anacronem, ja jednak postanowiłem sprawdzić co do zaoferowania ma tu syslog-ng, gdyż w PLD jest to domyślny demon logów.

Założyłem, że nie potrzebuję trzymać dzienników dłużej niż tydzień, oraz nie będę potrzebował ich kompresować. W pliku /etc/syslog-ng/syslog-ng.conf odszukujemy definicje plików (file) w destination np.:

destination d_messages { file("/var/log/messages"); };

Dodajemy do nazwy pliku makro $WEEKDAY, doklejające trzyliterowy przyrostek, odpowiadający aktualnemu dniu tygodnia. Ponadto dodajemy opcję overwrite_if_older(86400), gwarantującą że demon nie nadpisze danego pliku wcześniej niż za 24 godziny (86400 sekund):

destination d_messages { file("/var/log/messages.$WEEKDAY" overwrite_if_older(86400)); };

na koniec restartujemy demona. To rozwiąże problem tylko z aplikacjami korzystającymi z sysloga, dlatego musimy przekonfigurować każdą aplikację z osobna. Przykładowo sudo w PLD pisze zarówno do sysloga, jak i do własnego pliku, załatwiamy to jedną linijką w pliku /etc/sudoers:

Defaults !logfile

Nie musimy się za to przejmować logami pliku /var/log/dmesg*, czy programów X.org, GDM, gdyż same troszczą się o swoje dzienniki.

sobota, 18 lipca 2009

cnetworkmanager w PLD

Na desktopach, od których wymagałem większej pewności działania, np. tym w pracy, do łączenia się z WiFi używałem tradycyjnej metody za pomocą rc-skryptów. Nie chciałbym odciąć się od sieci w razie, jak nie będzę mógł podnieść X-ów po aktualizacji. Na szczęście niedawno w PLD pojawił się cnetworkmanager - konsolowy klient NetworkManagera.

Migracja
Instalujemy NetworkManagera z pluginem (dla GNOME):
$ poldek -i NetworkManager NetworkManager-applet
pakiet cnetworkmanager jest dostępny w gałęzi testowej (th-test):
$ poldek -n th-test -i cnetworkmanager

Wyłączamy obsługę interejsu wlan, przez ustawienie ONBOOT=no w pliku /etc/sysconfig/interfaces/ifcfg-wlan0 i restartujemy sieć:
# service network restart
uruchamiamy NetworkManagera:
# service NetworkManager start

Logujemy się na nowo do GNOME. Teraz w razie problemów mamy pod ręką tekstowego klienta, który jest o niebo łatwiejszy w obsłudze, niż dzierganie w rc-skryptach i wpa_supplicancie.

Obsługa
Obsługa klienta tekstowego jest bardzo prosta, listę sieci wyświetlimy za pomocą:
$ cnetworkmanager -n
cnetworkmanager 0.8.4 - Command Line Interface for NetworkManager
Wifi Networks:
51: cycki (52Mb WPA)
37: HotSpot (21Mb)


połączenie z siecią:
cnetworkmanager -C cycki --wpa-pass=blabla

Jako wisienkę na torcie dodam, że jako klient NetworkManagera nie wymaga praw roota.

sobota, 4 lipca 2009

Niech żyją ignoranci

Zawsze byłem zwolennikiem poważnego traktowania zagadnień bezpieczeństwa. Jeśli tylko nadarzała się okazja starałem się dawać wskazówki rodzinie i znajomym, by lepiej chronili swoje zasoby. Za ignorantów uważałem tych którzy choć trochę dbali o bezpieczeństwo, w końcu Internet jest wypchany artykułami dotyczącymi bezpieczeństwa, skierowanych zarówno dla profesjonalistów jak i dla laików.

Zmieniłem zdanie wczoraj, otóż mój ISP w miejscu zamieszkania zaprzestał świadczyć swoje usługi, co zaowocowało brakiem zarówno sieci jaki i kablówki - toż to dramat w piątkowy wieczór, zwłaszcza jeśli właśnie zaczyna się mój urlop. Tu z pomocą przyszli mi sąsiedzi, szybki rzut okiem na listę dostępnych sieci w NetworkManagerze i znalazły się trzy niezabezpieczone sieci. Szczęście się do mnie uśmiechnęło i jedna z nich zadziałała. Wydajność nie zachwycała, jednak filmiki z youtube działały względnie dobrze.

Wasze zdrowie ignoranci!

środa, 24 czerwca 2009

Tam gdzie Babilon upadł

Hej Antyglobalisto! Hej wrogu Babilonu!

Nie macie już dosyć walki, w której miast Babilon upaść, zdaje się być jeszcze silniejszy? Politycy jeszcze mocniej ryjami chwycili koryto? Nie pojawiają się bankierzy, którzy odczuli by choć trochę kryzys?

Mam dla Was świetną nowinę! Nie musicie już walczyć z Babilonem, by przestać żyć w jego cieniu. Jest takie miejsce gdzie upadł, a jego zgliszcza już dawno wystygły. Jest miejsce na ziemi gdzie nie ma władzy centralnej, sądów, ani nawet regularnej policji (sic!). Nie ma korporacji, a w Bank Światowy dawno zapomniał o istnieniu tego kraju. Nie płaci się podatków, składek zdrowotnych, akcyz, sam decydujesz co robisz z własnymi pieniędzmi. Nikt nie zainteresuje się też Waszym poletkiem zioła. To ciepły kraj, ze słońcem przez wiele dni w roku, długą granicą morską i bogactwem natury. Kominy fabryk nie będą wam zasłaniać malowniczych widoków, a za zarobione w Babilonie pieniądze, możesz kupić kawałek ziemi i żyć całkiem wygodnie.

Czego więcej Wam potrzeba? Potrzeba Wam jedynie niezawodnej broni samopowtarzalnej. Ten kraj to Somalia, zatem najlepszym wyborem będzie słynny AK-47, nie będzie problemów z amunicją a i brak zakładu rusznikarskiego nie sprawi kłopotu. Pewnym problemem mogą być zatargi lokalnych watażków, jeśli jednak nie staniecie na linii ognia, to krzywda Ci się raczej nie stanie. Poza tym nie obiecywałem, że dożyjecie sędziwej starości.

Podoba Wam się? Oddajcie zatem worek ciężkich nakrętek do skupu metali nieszlachetnych, spalcie koszulki z wizerunkiem El Comandante i w drogę!