PLD przechodzi na pakiety DEB

Niezwykła nowina: PLD-Linux rezygnuje z pakietów RPM na rzecz pakietów DEB. W końcu dystrybucja dojrzała do tego by wybrać rozwiązanie wygodniejsze i bardziej intuicyjne dla szarego użytkownika. Poldek wylatuje z dystrybucji na dobre, jego miejsce zajmie apt-get.

równouprawnienie kobiet

W Dzień Kobiet każdego roku powraca ożywiona dyskusja o pozycji kobiety w społeczeństwie i równouprawnieniu (a konkretnie jego braku). Moje drogie Panie, z okazji waszego święta pragnę, zakomunikować Wam, że aktualny stan utrzymuje się tylko dlatego że poza gadaniem nie robicie nic by sobie pomóc.

Zacznijmy od początku, wielkim krokiem do równouprawnienia była Pierwsza Wojna Światowa. W społeczeństwach o silnie uszczuplonych zasobach mężczyzn kobiety po prostu musiały zacząć wykonywać męskie zawody. Od tamtego czasu równouprawnienie rosło, jednak nie uzyskało satysfkacjonującego poziomu.

Jest jednak sposób by temu zaradzić. Zacznijmy od tego, że kobiety stanowią 52% procent społeczeństwa, zatem w krajach demokratycznych sa w stanie w wyborach wybrać na każde stanowisko Państwowe kobiety lub mężczyzn przychylnych kobietom. Tak wybrani politycy będą mogli przeforsować każde prawo, ze zmianą konstytucji włącznie. Kobiety mogły by prawnie zdyskryminować mężczyzn i wprowadzić najdziwaczniejsze ustawy jakie przyszły by im do głowy.

Zatem moje drogie, nie na Manifę, ale do urn!

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.