Niekompetencja informatyków czai się wszędzie…

Oto wiadomość jaką dzisiaj dostałem na adres zapisany w bazie WHOIS:

From: „LiveNet.pl” <bok@livenet.pl>
To: [cenzura]
Subject: Wlamanie z waszej sieci !!!

Dzien dobry
Jestem wlascicielem firmy hostingowej livenet.pl. Pisze w sprawie jednego z
Państwa klientów, otóż uw klient wykazuje zdolności hakerskie włamując się na
serwery smtp i podszywając się pod właścicieli serwera wysyła spam co w świetle
dzisiejszego prawa jest przestępstwem. Ja w imieniu swoim oraz kilku innych
zaprzyjaźnionych firm z branży zaobserwowaliśmy to już od jakiegoś czasu. My
oraz nasi klienci dostajemy maile z załącznikami w których znajdują się wirusy.
Chcieli byśmy poznać dane tego człowieka. poniżej przesyłam wycinek z logów
serwera na który polowaliśmy jakiś czas. dla uproszczenia proszę mi podać dane
człowieka który o godzinie 12:16 korzystal z IP [cenzura] prosze o kontakt
telefoniczny [cenzura].

Poniżej tego tekstu nie było żadnych logów, ale nagłówki wiadomości. Już na
pierwszy rzut oka widać że to wirus, a pierwsze użycie Google wykazało że to
Bagle.H. Oczywiście postarałem się o zablokowanie dalszego rozsyłania wirusa z komputera
nieostrożnego klienta, jednak przesłane w skardze nagłówki nie ułatwiały mi tego jak powinny
– nazwa serwera podanego w nagłówków Received:
stuff.livenet.pl w ogóle nie istnieje. Przy okazji okazało się że ta
skarga przyszła do mnie jedynie z powodu przeoczenia przy konfiguracji mojego
serwera – taka nazwa w HELO nie powinno w ogóle być przyjęta. I więcej
przyjmowana nie będzie (oczywiście poza pocztą wysyłaną na konto
postmaster).

Wszystkie [cenzura] są oczywiście wstawione przeze mnie zamiast
informacji których nie chciałem publikować. Myślałem nad wycięciem także nazwy
firmy, ale niech zostanie – ku przestrodze potencjalnych klientów.

Czyżby libxml2 to był zły wybór?

Zaczynam wątpić w to że użycie libxml2 w PyXMPP to był naprawdę dobry
wybór. I to nie z tego powodu, że ta biblioteka, wraz z modułem pythonowym
jest dość trudno dostępna dla użytkownika końcowego. Chodzi raczej o podejście developerów
libxml2
. A może po prostu ja byłem głupi zakładając że interfejs SAX,
czyli strumieniowy, będzie mnie informował o zdarzeniach na bieżąco. Czyli że
np. informację o początku elementu dostaję zaraz po przeczytaniu całego taga
początkowego, a nie po rozpoczęciu kolejnego elementu. W każdym razie po
uaktualnieniu (zresztą podyktowanym względami bezpieczeństwa) libxml2 do
wersji 2.6.7 PyXMPP i wszystko co z niego korzysta (a więc CJC i JJIGW)
przestaje działać. I nie będzie działać, póki autorzy libxml2 nie cofną tego
feature’a, albo ja nie przygotuję obejścia (ręcznego wstępnego
parsowania strumienia XML przed przekazaniem go do parsera XML).

Routerek 3Coma nadal działa, ale zdążył nas zaskoczyć. Konfiguracja
firewalla, która miała zablokować dostęp po TCP i UDP do routera, zablokowała
cały ruch TCP i UDP przechodzący przez router. Okazało się że w ACLach w tym
routerze maski adresów IP mają odwrotne znaczenie niż gdzie indziej (chociaż
może w innych routerach jest tak samo) i adres z maską
255.255.255.255 oznacza dowolny adres, a jak chcę złapać
ten jeden konkretny, to muszę użyć maski 0.0.0.0. Dziwne,
ale teraz działa.

Postawiłem i wczoraj w końcu skonfigurowałem zgodnie z życzeniami
użytkowników serwerek Quake3 na firmowym serwerze games.bnet.pl. Gostki
przez dwa tygodnie za mną chodzili w tej sprawie. Podziwiam ich
cierpliwość. :-)

A’propos gier. Doszedłem to tego, czemu mi się komp przy OpenGL wywalał –
nie miałem modułu via-agp załadowanego, a obsługa DRI na Rage128
w trybie PCI najwyraźniej się sypie. A samo agpgart już nie
wystarcza. Obejrzałem sobie UFO: Alien
Invasion
– może z tego być niezła gierka.

Routerek i partactwa na WWW

Rano wyjęliśmy felerną kartę z routera, zainstalowalismy spowrotem
dystrybucyjny kernel, a ostatnią sieć maskaradowaną przez ten router
przepięliśmy do innego. W południe przyszedł routerek 3Coma. Udało się go
skonfigurować i nawet ładnie działa. Test polegający na ping-floodzie
przeszedł na 5+, innych na razie nie robiliśmy. Nieciekawie natomiast
wyglądał efekt nmapa zapuszczony na tym urządzeniu. Chyba 5 portów TCP
otwartych, w tym telnet, domyślnie bez hasła. Nie rozumiem co za idioci tak
domyślnie konfigurują takie urządzenia. Przecież mogłem zapomnieć sprawdzić.
Co gorsza okazało się że tych usług nie można wyłączyć. Na szczęście dało się
zablokować wbudowanym firewallem. Założyłem więc regułki blokujące wszystkie
połączenia TCP i UDP do maszynki i mam spokój. Na „dużym” routerze, gdy już
POLPAK działa i nie ma żadnej NATowanej sieci, mogłem wywalić moduł
ip_conntrack. Teraz powinien sobie i z kilkoma GB/s poradzić.
:-).

Najlepsze jest to, że dzisiaj, pierwszy raz od początku tygodnia, przez cały dzień nic nam
się nie powiesiło! :-) (odpukać!)

Żona poprosiła mnie o pomoc przy robieniu screenshotów stron WWW, co
zlecono jej w pracy. Pracuje ona w małej lokalnej firmie Linuksowej zajmującej
się głównie tworzeniem serwisów WWW. Te strony które mieliśmy strzelać
wyglądają całkiem nieźle, ale miejscami się rozjeżdżają. Z ciekawości
zapuściłem na nich walidatora W3C.
Masakra :-(. A łudziłem się że przynajmniej mała, linuksowa
firma, prowadzona przez rozsądnych i bardzo sympatycznych ludzi nie będzie
robić takich partactw…. No ale cóż, ja jestem idealista, a oni muszą
przede wszystkim zarobić
. Ale czy na pewno nie da się tego połączyć? Po
prostu wymagać od tych którym się robotę zleca, żeby wynik się walidował?
Konkretne wymaganie odnośnie jakości zleconej pracy, a nie wymagające od
wykonawcy wcale dużo więcej pracy, jedynie odrobinę kompetencji i wiedzy. No
i w wielu wypadkach pozwala uniknąć konieczności testowania strony we
wszystkich możliwych przeglądarkach.

Może hobbystycznie przerobię jedną stronę w zgodzie ze standardami…
ciekawe ile roboty zajmie to mnie. Przecież ja się tym normalnie nie zajmuję
no i nie wiem co autor miał na myśli.

Czy to się wreszcie skończy?

Paskudny ten tydzień. Na poniedziałku się nie skończyło. :-(

Powodem wolnego działania łącza po zmianie płyty w routerze okazały się
straty pakietów na jednej sieciówce. Dokładnie to był jeden z czterech portów na
czteroportowej karcie D-Link. We wtorek przełożyliśmy kabelek do interfejsu na
płycie głównej (VIA Rhine) i straty ustały. Było nawet lepiej niż na starej
płycie. Super… ale nie długo. Tego dnia też przyszła zamówiona karta
synchroniczna na PCI, ale instalację tego zostawiliśmy sobie na srodę. We
wtorek spatchowałem tylko dla nich kernel PLD. Po pracy okazało się że sieć na
tym VIA Rhine i pomaga tylko reset switchów, a żeby było śmieszniej po resecie
jednego z tych switchy musimy robić ifdown/ifup na serwerze do niego
podpiętym, bo dla odmiany tam sieć zawisa. W końcu jakoś działało dalej.

W środę już z samego rana poszliśmy na serwerownię podłączać nową kartę.
Trzeba było wyjąć serwer z szafy, zainstalować kartę, włożyć serwer spowrotem
(jego miejsce w szafie jest na wysokości około 2m) i wszystko popodłączać.
Klienci zapewne byli zachwyceni, bo trwało to ponad pół godziny a i na tym
przerwy się nie skończyły. Po podłączeniu i uruchomieniu zapatchowanego
kernela wszystko wyglądało dobrze… dopóki nie załadowałem sterownika do
karty. Próba zakończyła się twardym zwisem maszyny, nawet Magic-SysRq nie
pomógł. Po paru próbach z różnymi konfiguracjami postanowiliśmy zadzwonić do
producenta. Dostałem numer telefonu do gościa od tej karty a zarazem autora
sterowników. Niestety nie był w stanie powiedzieć nic konkretnego, jedynie
zasugerował zainstalowanie gołego kernela (no cóż ten z PLD jest rzeczywiście
przeładowany patchami). Cóż było robić. Odpaliłem router bez tego sterownika
(a więc dalej bez POLPAK-a), wróciłem do biura i zacząłem szykować kernel.
Instalację zostawiłem sobie na dzisiaj (czwartek).

Na tym środowe atrakcje się nie skończyły. Około 17-tej znowu siała sieć na
Rhine i trzeba było restartować switcha. Potem pojawiły się duże straty –
okazało się że tabela conntrack się przepełniła (wcześniej był kernel 2.2, a
więc nie było tego problemu). Poprawiłem ip_conntrack_max i było jakby lepiej.
Jednak wieczorem gdy chciałem sprawdzić jak daleko jest tej tabeli do
ponownego przepełnienia (wc -l /proc/net/ip_conntrack) znowu sieć zawisła. I
tym razem restart switchów nie pomógł. Po reboocie (zdalnym, serial-console
rulez) sieć w ogóle nie wstała. Tylko pojawił się komunikat o jakimś problemie
z routingiem przerwań i wynikającym z tego konfliktem. Próbowałem jakoś
skonfigurować routing z pominięciem tego routera (teoretycznie możliwe
rozwiązanie dla większości naszych klientów), ale nic z tego nie wyszło, więc
spróbowałem jeszcze jednego restartu. Tym razem sieć wstała, ale zauważyłem że
komunikat o problemie z przerwaniami też się przy starcie kernela pojawił.
Widać dupiata płyta główna.

Dzisiaj jak już dojechałem do pracy, co stało się 15 minut później niż
zwykle, bo autobus nie dojechał, zabraliśmy się znowu za ten nieszczęsny
router. Najpierw obejrzeliśmy jeszcze raz ten komunikat o przerwaniach i
spróbowaliśmy coś z tym zrobić w ustawieniach BIOS. Potem zainstalowałem nowy
kernel (ten własny, nie z PLD) i załadowałem sterowniki do karty. Załadowały
się, bez zwisu. Potem skonfigurowałem dostęp do POLPAKu – miodzio, znacznie
przyjemniejsza sprawa niż z tą nieszczęsną Sangomą. I zebra nie zdechła po
odpaleniu łącza i interfejs zachowuje się normalnie. Takiej właśnie karty mi
było trzeba… Nie nacieszyłem się jednak długo bo wszystko wisło. Na twardo.
Mieszaliśmy z ustawieniami przerwań itp., ale nigdy nie podziałało dłużej niż
godzinę. Znowu dzwoniłem do autora sterowników, ale nie miał lepszych pomysłów
niż te na które sami wpadliśmy – może to konflikt przerwań, spróbujcie bez
tej karty z którą współdzieli przerwanie
. Ale nie możemy wyciągnąć tej
karty, bo to czteroportówka, która sama zabiera wszystkie cztery przerwania
PCI. Przełączyliśmy jeden kabelek gdzie indziej, tak że przynajmniej jedno z
tych przerwań było nieużywane i mogło zostać tylko dla karty synchronicznej.
Jednak sytuacja bez zmian – nadal się wiesza. W końcu wywaliliśmy ten
sterownik i ponownie wyłączyliśmy POLPAK. Nie wyciągaliśmy karty, żeby nie
powodować kolejnej (tym razem dłuższej) przerwy w działaniu routera. Będąc na
serwerowni oczywiście pamiętaliśmy o wieszającej się VIA Rhine – przepięliśmy
z niej kabelek na 3Coma, który też tam był, może będzie lepiej.

Tej karty synchronicznej mamy już dosyć, jutro ją wyciągamy i spróbujemy
zwrócić. Dzisiaj zamówiłem dedykowany router 3Coma. Jakiś bardzo prosty z
portem V.35 i Ethernet – tak żeby tylko pośredniczył pomiędzy POLPAK-iem, a
naszym routerkiem. Jutro czeka mnie więc wyciąganie karty i instalacja
routera. Ale jak ten nowy router będzie nawalał, to najwyżej POLPAK nie będzie
działa, a na nasze główne łącze nie powinno to mieć problemu. Oby się te
problemy wreszcie skończyły!

A teraz coś bardziej optymistycznego. Wczoraj Krysia opanowała używanie
myszki. Odpaliłem jej TuxPainta (nie pierwszy raz), a ona sama stawiała
pingwinki w mniej-więcej przemyślanym miejscu. Jak tak dalej pójdzie, to zanim
skończy trzy latka (teraz ma niecałe dwa) to będzie chciała poznać hasło roota
:-).

Niezły początek miesiąca

Wszyscy rozpisują się o tym że miesiąc sie rozpoczął. Pewnie dlatego żeby
nie mieć pustej strony na swoich jogach. Ja też napiszę, szczególnie, że mam
na co się poużalać.

A więc przychodzę do pracy, ciesząc się że drugi admin już wrócił
z urlopu i będę miał mniej roboty. Jednak zaraz jak siadłem do kompa
okazało się, że ten nie dostał adresu IP. Biurowy serwerek/routerek
leży. Podpiąłem do niego monitor, klawiaturę, ale nawet zalogować się
nie da. Magic-SysRq ujawnił, że chodzi tam cała masa procesów
„crond” w stanie „D” („zombie”).
Dziwne, ale reboot pomógł.

Już gdy grzebałem w tym biurowym serwerku dzwonili klienci że im net
albo poczta nie działa. Oni nie są podłączeni przez nasz biurowy LAN,
więc już było wiadomo że na drugiej serwerowni (na TPSA) też coś leży.
Gdy w biurze sieć już działała okazało się, że nie ma wyjścia w świat,
a więc leży router brzegowy. On już szwankował od jakiegość czasu
i nawet nowa płyta do niego była (czekała na nową kartę V.35). Ale to
nie wszystko… okazało się że leży także router/serwer obsługujący
sieci osiedlowe.

Poszliśmy na TPSA. Okazało się że router brzegowy leży tak jak
podejrzewaliśmy, jednak reboot nie pomaga (ostatnio za którymś razem
pomagał). No cóż będzie trzeba płytę wymienić nie czekając na kartę
V.35 (stara karta była na ISA, więc do nowej płyty byśmy jej nie
wcisnęli). Serwer od osiedlówek natomiast wisiał podobnie jak ten
biurowy, tyle że tu dla odmiany była masa procesów „smbd”
w stanie „S”. Reboot pomógł.

W końcu udało się i odpalić router brzegowy. W tym celu trzeba było
znależć kartę grafiki która by do niego pasowała i w nim działała
(zwykłe AGP nie wchodziły w slot 1.5V, a jedna PCI po prostu nie
działa w tym kompie) i zorientować się że pamięc należy włożyć do
slotu 3 a nie jeden.

Teraz niby wszystko działa, ale część klientów oraz szef narzekają że
strony ładują się strasznie wolno, a my nie możemy znaleźć powodu…

ech… Mam nadzieję, że nie będzie cały marzec tak wyglądał…