Re: TP nie lubi GIMPa czy co?

Autor: ru <toruvinn_at_gmail.com>
Data: Sun 04 Jan 2009 - 21:29:50 MET
Message-ID: <ddabf787-b705-4321-901e-84b22dec8f07@35g2000pry.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-2

Bry!

On Jan 4, 8:13 pm, rafal.jaczyn...@gmail.com wrote:
(ciach)
> Witam rootnode.
Nie wiem, czy zrozumiałem aluzję (tzn. czy jakowaś była), ale na
wszelki wypadek śpieszę z wyjaśnieniem, iż ja z rootnode wspólnego nie
mam nic. ;-)

(ciach - o tym, jak pierwsza odpowiedź od TPCERT niewiele wniosła)
> To ja pojadę klasyką: bardzo mnie zraniłeś Shrek :(. No chyba, że
> więcej was te maile pisało, ale szczerze mówiąc nie podejrzewam.
Sztuk jeden mnie te maile pisało. Maili sztuk dwa. Odpowiedzi
otrzymałem sztuk jeden.

(ciach - o tym, jak nie dostałem odpowiedzi na odpowiedź na odpowiedź
otrzymaną od TPCERT)
> Hmmm, ja rzeczywiście dostałem takiego jednego maila, na którego
> jeszcze nie odpowiedziałem. Przyczyna jest taka, że tak nie do końca
> miejscami rozumiem, co autor miał na myśli, a miejscami też nawet przy
> najwyższym poświęceniu za dużo musiałbym tłumaczyć. Nie mam aż tak
> altruistycznej natury.
Hm, śmiem twierdzić, że nie o mnie chodzi, ale na wszelki wypadek -
adres, z którego pisałem różni się tylko domeną od tego, z którego
postuję na usenecie (z racji tego, iż tu postuję z gugli, bo tak mi
wygodnie).
Na wszelki podaję jeszcze: [TP CERT #2008121610039197]
Choć mail już trochę nieaktualny (bo powód mniej-więcej znam, chyba że
akurat w tym przypadku nie o botnety chodzi), byłbym wdzięczny za
jakieś namiary, tj. jakie hosty się z serwerem kontaktowały, porty,
daty, itp. - cokolwiek co spowodowało, iż uznano mnie za SIEWCĘ ZŁA
(R).
... ale to niekoniecznie na forum publicznym.

>> Byłbym naprawdę wdzięczny za jakieś informacje, co począć dalej (czy
>> też sprawę olać i korzystać już dożywotnio z dodatkowego IPka za
>> (bodajże) 4zł miesięcznie).
> Proste to jest jak konstrukcja cepa - jeżeli pod nowym adresem
> pozostalo ZŁO, zostanie on zablokowany. I nawet po zaprzestaniu zabawy
> będzie musiał odczekać pewien czas, aż według zastosowanej polityki
> zostanie automatycznie uznany za zagrożenie historyczne. Oryginalnie
> zablokowany adres podlega dokładnie tej samej procedurze - w tym
> tygodniu bodajże sprawdzałem, scoring obniżył mu się w porównaniu z
> poprzednim tygodniem, więc wygląda na to, że niedługo będzie
> dostępny.
Ależ ja od samego początku twierdzę, że ZŁA tam nie ma. Zdaję sobie
sprawę, że "twierdzić to ja sobie mogę", niemniej lista procesów
pracujących na hoście sugeruje, iż moje twierdzenie ma pewne poparcie
w praktyce. Do tego dochodzi jeszcze fakt, iż za czasów początkowych
prób usługi (czyli jakoś ~28 października ubiegłego roku) również
odpięto mi tego hosta, zatem znajduje się on w bazie już czas jakiś. I
tu - być może mylnie - podejrzewam, że albo wpis jest dodany "na
stałe" (o ile istnieje taka możliwość, a pewnie istnieje) jeszcze za
czasów mojego poprzednika (tj. gdy ktoś inny w OVH miał tego IPka/
serwer dedykowany).

Na wszelki wypadek zacząłem logować to, co mi wypluwa tcpdump,
zobaczymy co mi wyjdzie.

>> A teraz z troszeczkę innej beczki, gdyż od właściwie początku
>> informowania o wszelkich honeypotach (i podobnych) zbierających dane o
>> potencjalnych adresach do wycięcia chodzi mi to po głowie - czy nie
>> istnieje niebezpieczeństwo, iż powstanie nowy rodzaj ataku, tj.
>> spoofowanie "komunikatów kontrolnych botnetów" w taki sposób, by w
>> efekcie ofiara samego ataku została wycięta (bo uznana za kontroler)?
>> Szczerze mówiąc - nie wiem, po jakim gruncie stąpam (brak info o
>> BLach, firmach, więc mogę tylko sobie wyobrażać różne czarne
>> scenariusze), ale skoro odpowiednie dane gromadzone są przez automaty,
>> a automaty da się często oszukać, w efekcie tworzymy podstawy dla
>> paskudnego ataku, dzięki któremu łatwo (lub nieco trudniej - od
>> automatów zależy) możemy wysłać w routerowy kosmos "niewygodne" hosty.
> Ktoś już o tym pisał. No więc tak - hostom niewygodnym i dobrze
> zabezpieczonym zasadniczo nic nie grozi. Hostom niewygodnym i cienko
> zabezpieczonym grozi już teraz parę rzeczy skutkujących na przykład
> ich, jakby to powiedzieć, mniejszą dostępnością. Można w dodatku
> postawić tezę, że przejęty host jest sam w sobie zagrożeniem dla
> Internetu...więc skoro atakujący sam stara się za nas zrobić "incident
> containment" to nie jest to może wcale taki głupi pomysł ;). Jako DoS
> taki atak mógłby mieć sens o tyle, że mógłby być teoretycznie mniej
> zauważalny dla ofiary (nie jest dostępna i nawet o tym nie wie), ale
> jak widać na przykładzie naszej skromnej inicjatywy - jakoś, skubani,
> dowiadują się raczej wcześniej, niż później ;).

Hmm, nie do końca o to mi chodziło. Pytałem nie tyle o możliwość
"udawania kontrolera botnetu" z samego hosta (po jego przejęciu), bo
to jest dość oczywiste i proste (pod warunkiem, że hosta przejmiemy).
Problem łatwiej mi będzie wyjaśnić na przykładzie - załóżmy, że BLe (o
których nic nie wiadomo, więc zakładać sobie mogę ;-P) zbierają te
dane jednak analizując payload pakietów (czego TPSA nie robi, ale BLe
- kto wie?) TCP/IP. Większość pakietów przesyłanych do serwerów IRC
kontrolujących botnety będzie dość łatwo rozpoznawalna (:nick!
user@host PRIVMSG #mójwspaniałybotnet :.wywalcienoproszę <jakiś ip>
<jakieś inne parametry>). Jeśli BL widząc pakiet o podobnej treści
uznaje, iż pod adresem docelowym pakietu znajduje się IRCd
kontrolujący botnet... BINGO! Dalej to już tylko kwestia przesyłania
pakietów o odpowiedniej treści, udających "legalne" połączenie TCP/IP
z docelowym hostem (choć ten wcale nie musi nic wiedzieć o żadnym
połączeniu - ba, pewnie nawet nie ma nic otwartego na dst porcie).
Jeśli wymagane jest więcej takich połączeń (pakietów - symulujących
łączące się zombiaki), to jeżeli mamy jakiś botnet (albo odpowiednią
ilość kumpli, którzy mogą jeden pakiecik przesłać co jakiś czas) - nie
stanowi to problemu.
Wniosek - przy niewielkim nakładzie pracy (pakietów) to ISP wycina
hosta. I to - jak widać - na dość długi okres.

Pozdrawiam,

--
ru
Received on Sun Jan 4 21:30:08 2009

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sun 04 Jan 2009 - 21:40:02 MET