masala ćaj dla leniwych

Oryginalny przepis na napój Masala Ćaj, pozwala uwarzyć smaczny napój, jest jednak złożony, stosunkowo czasochłony i do mycia mamy uświniony garnek i sitko. Tu jednak z pomoca przyszło mi lenistwo (które razem ze strachem są najsilniejszymi bodźcami wynalazczości) i tak oto powstał Masala Ćaj dla leniuchów:

1. parzymy mocną herbatę
2. dodajemy 'Przyprawę do grzanego piwa i wina"
3. dolewamy trochę mleka
4. dosypujemy nieco cukru do smaku (uwaga przyprawa do grzańca ma sporo cukru)

Wychodzi nam zatem bawarka o korzennym aromacie, mimo to sympatyczna odmiana.

ChrInst 1.0

Oddaję w Wasze ręce najnowszą, okrągłą wersje ChrInsta: 1.0. W tej wersji najciekawszą zmianą jest zastąpienie GRUB-a przez GRUB2. Nowy bootloader nie wymaga paskudnego obejścia, jakim jest gałąź /boot, która była do tej pory konieczna jesli używalimy LVM-u lub ext4 na rootfsie.

Jeśli pozwolimy instalatorowi samemu podzielić dysk opcja ("new" layout) zarówno rootfs jak i /home będą używały systemu plików ext4. Przy okazji dwa słowa o tym jak ChrInst zakłada systemy plików w trybie automagicznym. Zacznijmy od tego, że zakłada LVM, ChrInst przeznacza 80% całego miejsca na VG dla LV. Dzieki temu jeśli zajdzie taka potrzeba, możemy pozostałe 20% przydzielić dla któregoś systemu plików lub swapu. Takiej podejście wynika z faktu, że niemal wszystkie systemy plików mkożna powiększać, ale pomniejszać już nie każdy.

Tryb automatycznego podziału dysku jest adresowany pod desktop i wygląda on następująco:

• rootfs: 5GB + 1/40 wielkości dysku/macierzy


• swap: 1GB + wielkośc RAM-u


• /home: reszta (z 80%VG)

zatem podział dysku 500GB przy 2GB RAM-u będzie wyglądał w przybliżeniu tak:

• rootfs: 15GB


• swap: 3GB


• /home: 382GB

do tego pozostaje ~100GB wolnego dla przyszłych zastosowań.

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?

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.

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.

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.

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.