Re: TP nie lubi GIMPa czy co?

Witam wszystkich po urlopie bezpośrednio z siedliska wszelakiego zła.

Odpiszę ogólnie na kwestie, które mi się rzuciły w oczy - odpisywanie
na poszczególne wypowiedzi nie jest w google najbardziej ergonomiczną
czynnością.

1. Reklamacje, maile etc.

Mam już pewien przegląd pola. Łącznie przez ostatnie trzy tygodnie
maili na abuse jest około 100, wliczając w to wiele maili, które
służyły komuś do okazania emocji, a których autorzy mają ewidentny
problem z kulturą i ortografią. Reklamacji - o rząd wielkości mniej.
Na temat procesu reklamacyjnego nie będę się teraz wypowiadał - jest
tam parę innych kwestii (prawne etc.), na których inne osoby biorące w
nim udział znają się lepiej. Gdyby w korporacji wszystkim zajmowała
się jedna osoba...no wtedy korporacja nie byłaby korporacją ;).

Wszystkie maile - oprócz jednego bodajże - dotyczą gimp'a, IRCa i
esr.rootnode.net (pojedyncze przypadki). Oprócz interesującego
wniosku, że popularność własnoręcznie tworzonej grafiki rastrowej i
jej znaczenie dla sprawy polskiej jest swoistym odkryciem, podtrzymuję
to o czym pisałem wcześniej: jak widać nie za bardzo istnieją inne
przykłady istotne dla klientów TP. Próbkę mam już większą, proszę mi
tu kłamstwa nie zarzucać :>

Aktywność gimpa i rootnode wyrażona scoringiem spada (oznacza to, że
odstęp czasowy od ostatniego wysłanego za ich pośrednictwem rozkazu
się zwiększa), więc pewnie lada dzień nagłówki portali będą z
satysfakcją donosić, że TP odblokowała gimpa. Przy IRCu wpółpracujemy
z operatorami, otrzymali oni od nas informacje pomocne w poradzeniu
sobie z kontrolerami na ich serwerach. Ten problem też powinien
przestać Was niepokoić już niedługo. Chciałbym jednocześnie
podkreślić, że o ile pomiędzy słabiej kontrolowanymi pod względem
bezpieczeństwa serwerami zauważamy próby "przesunięcia" się
kontrolerów z jednego na drugi, istnieją polskie serwery IRC, które
nie były kontrolerami botnetów w momencie uruchomienia blackholingu i
aktualnie dalej nimi nie są. Ja znam 9 takich serwerów - tam
ewidentnie jakość administracji w zakresie bezpieczeństwa utrzymuje
się na stałym wysokim poziomie. Co popłaca.

2. O asertywności

Asertywność to jak wiadomo umiejętność mówienia "nie". Asertywność
jest wpisana w każdy projekt mający na celu ograniczenie działalności
botnetów, blackholing nie jest wyjątkiem. Dlatego odblokowanie serwera/
wpisanie go na whitelistę z definicji nie jest łatwe - nie ma tu
szczególnego znaczenia wytwarzane na TP "ciśnienie", bo spodziewaliśmy
się go uruchamiając projekt. Mamy ograniczone możliwości odróżnienia
"ciśnienia" wywieranego przez klientów z ich własnej inicjatywy od
"czarnego PR" generowanego lub inspirowanego przez osoby
zainteresowane kontrolą nad botnetami. Myślę, że uczciwym podejściem
jest założenie, że wszyscy są uczciwi - natomiast podejmowanie decyzji
na podstawie twardych faktów.

Wszyscy chyba rozumieją, że do odblokowania adresu nie powinien
wystarczać telefon lub mail, w takim przypadku cały pomysł nie miałby
sensu. Nie ma również znaczenia popularność serwisu i ilość powtórzeń
tego samego przykładu w mediach. Nie ma również znaczenia złożenie
deklaracji, że "problem po naszej stronie został rozwiązany". Ma
znaczenie to, czy został rozwiązany rzeczywiście - czy host wysyła
rozkazy jeszcze w trakcie rozmowy, czy nie jest aktywny np. od
tygodnia. Mamy przypadek hosta, który został zablokowany, bo parę
tygodni temu był kontrolerem, a ze względu na przyjętą w pierwszej
fazie restrykcyjną politykę jeszcze nie zdążył "wypaść" z listy - i w
takich przypadkach możemy to jak najbardziej uznać to za naszą
nadgorliwość i odblokować ruch. Ale patrząc na scoring, w porównaniu
do tego akurat hosta aktywność zablokowanych serwerów IRC, gimpa lub
rootnode była wyjściowo prawie stukrotnie większa. Teraz wynik jest
tylko 25 razy większy (proszę nie mylić scoringu z aktywnością w danej
chwili, on uwzględnia też zachowanie w czasie, czyli mówi o tym, ile
czasu upłynęło od ostatniego rozkazu).

3. Jak się uchronić przed kontrolerem botnetu

W przypadku centralnie sterowanych botnetów (a o takich mówimy w
przypadku blackholingu) występują z punktu widzenia kontrolującego
ogólnie trzy możliwości: wykorzystanie do kontroli botnetu legalnie
działającej i dostępnej również dla normalnych użytkowników usługi
(dotyczy zasadniczo IRC) na serwerze dedykowanym do tego celu lub
dostarczającym też inne usługi, uruchomienie usługi dedykowanej do
kontroli nad botnetem na własnym serwerze, na którym działa też inna,
"oficjalna" usługa (wtedy do kontroli można użyć czegokolwiek - irc,
http w szczególności) lub uruchomienie dedykowanej usługi na czyimś
serwerze, który został specjalnie w tym celu przejęty (wtedy też
niekoniecznie może to byc ircd).

Dla ilustracji i przy zachowaniu prawa do błędu: wydaje mi się, że
polskie IRC, rootnode i gimp należą do pierwszej kategorii. Wszędzie
tam jest uruchomiony serwer irc, czego administratorzy się nie
wypierają (no w przypadku ircnetu byłoby trudno ;), nie są to więc
raczej dwie pozostałe możliwości. No można pogdybać w przypadku
rootnode - nie znam szczegółowo zasad hostowania w Ecatelu, poziomu
wirtualizacji środowisk, praw dostępu, jakie mają osoby z rootnode
etc. - teoretycznie w przypadku korzystania z hostingowni o historii
wskazującej na "elastyczną politykę" mogło dojść do sytuacji, w której
rootnode np. nie miało pełnej kontroli nad tym co się dzieje. Ale to
gdybanie. W każdym razie zauważcie, że na przykład w drugim i trzecim
przypadku możliwa jest sytuacja, że blokujemy adres, i jeden zaczyna
narzekać, że nie może sobie do www sięgnąć, inny narzeka, że mu padło
radio...a na brak dostępu do irca nie narzeka nikt.

Jak się więc zabezpieczyć? Będąc operatorem IRCa trzeba robić ni mniej
ni więcej tylko to, o czym już pisał na przykład Karpio. Nie jest to
rocket science, są osoby, którym się udaje tematu dopilnować. Będąc
właścicielem jakiegokolwiek serwera trzeba po prostu nim
administrować, rozumiejąc administrację tak, jak była ona rozumiana
drzewiej - nie jako "kręcenie korbą" po krótkim przyuczeniu, ale
odpowiedzialność za serwer ze szczególnym uwzględnieniem jego
bezpieczeństwa. Wtedy powinno być dobrze.

A ponieważ nie żyjemy w idealnym świecie, i tak ja w każdym zawodzie,
tak wśród ogólnie pojętych informatyków podaż osób, które mają duży
talent i wiedzę jest znacząco mniejsza, niż popyt na nich - czasem
taki ISP musi zaadresować problem wymykający się spod kontroli. Z
reguły znacząco lepiej to wychodzi, kiedy ISP sam z siebie wykaże się
inicjatywą...bo kiedy zostanie do tego zmuszony przez regulatorów,
prawo, rządy lub właścicieli rozwiązania mają tendencję być o wiele
bardziej dyskusyjne.

4. Skuteczność BGP blackholingu - czyli o populacji botnetów
centralnie sterowanych vs. peer-to-peer

Każdy, kto czyta tę listę i jest w stanie podać z mocą twierdzenia
właściwą odpowiedź na powyższe pytanie traci tu czas i pieniądze, bo
jest (po "jasnej" stronie mocy) jednym z nielicznych ludzi na świecie,
którzy taką wiedzę posiadają. "Mądrość ludowa", głosząca, że skoro p2p
jest teoretycznie lepsze, to na pewno jest bardziej popularne, na
szczęście nie działa. O wynikach badań nad fast fluxem już
wspominałem, dodam jeszcze, że patrzę sobie na wyniki projektu
honeypotowego w chińskiej sieci (z 2007 roku), i widzę, że średnia
długość "życia" serwera C&C wynosiła 54 dni...straasznie wolny ten
fast flux ;). Z tego samego projektu - liczba zaobserwowanych botnetów
IRC przez rok czasu wyniosła ni mniej, ni więcej, tylko 3290...z kolei
trochę przydużo, jak na wymierającą technologię.

Prawda jest taka, że trzeba odróżnić botnety tworzone na dedykowanym
malware stworzonym przez ich twórców, ze względu na wiedzę tychże
stosujące najskuteczniejsze techniki, od botnetów tworzonych z
wykorzystaniem gotowych, dosyć powszechnie dostępnych narzędzi. Jest
parę marek samochodów lepszych od np. forda, ale to fordów jeździ
więcej. Są takie diesle, co wygrywają Le Mans, ale większość tych, co
jeździ nie ma w sobie tej "winning technology" ;). Dobra, zaryzykuję -
jest pewnie parę programów graficznych lepszych od Gimpa, ale to Gimp
jak widzę bije je popularnością na głowę :D

Pozdrawiam,
RJ
Received on Mon Jan 5 16:50:05 2009