Krzysztof Halasa wrote:

> Jesli TPSA dysponuje odpowiednimi statystykami (przeciez blokuje te IP
> wedlug algorytmu), to dlaczego nie moze zablokowac _zarazonych_
> maszyn, mozna im wyswietlac takze odpowiednia strone WWW z informacja,
> byloby to skuteczne z dowolnymi sposobami kontrolowania zombies, a
> dodatkowo byloby to zgodne z prawem oraz z umowami z klientami.

ale jakże zwiększyłoby ilość klientów neostrady odchodzących do
konkurencji, która takich komunikatów nie wyświetla, a to nie jest
zgodne z polityką sprzedaży &TP

uwierz mi, że niektórzy klienci nie potrafią sobie przemówić do rozsądku
w kwestii odwirusowania komputera,a w przypadku klientów neo robią się z
tego całkiem pokaźne ilości








--
http://net.czarne.net/ <- łącze w świat pilnie potrzebne !!!
Dach elektrowni w Czernobylu mial byc zbudowany z materialow
ognioodpornych ale tych nie bylo,a dach byc musial,wiec
zostal zbudowany z materialow palnych

do góry

In pl.internet.polip Krzysztof Halasa <k...@p...waw.pl> wrote:

> Nic podobnego. Miales tam od j.ch. szczescia, drugi raz bym sie na
> takie cos nie nastawial (swoja droga, pierwszy raz takze nie).

To jest dyskusja na osobny wątek, czemu się tak stało. Może jakieś
spotkanko? :)

> A co to znaczy "panowac nad maszyna"? Pamietasz jeszcze jak dziala
> IRC? To tak jak z DNSem. Botnet uzywa takze zapewne DNSu (chociaz nie
> musi, podobnie jak tym bardziej nie musi uzywac IRC), czy
> administrator dns*.tpnet.pl panuje nad swymi maszynami?

Jasne, że nie musi używać IRCa, może używać zupełnie czegoś innego.
W dużej części przypadków, jak już zresztą ktoś pisał w tym wątku, jest
tak, że używają tego ludzie, którzy korzystają z gotowych rozwiązań,
co najwyżej lekko je modyfikując. Bezpieczeństwo serwerów DNS, to historia
na osobny wątek. Administratorzy tychże, również nie siedzą bezczynnie,
a zagrożeń i problemów również jest sporo.

> Dopuszczam taka mozliwosc, ze ta lub inna maszyna jest pozbawiona
> opieki i ze dzieja sie na niej cuda, ale wedle mojej wiedzy do bycia
> uznanym za "kontroler botnetu" wystarczy - niech ktos zaprzeczy -
> normalna, prawidlowa praca serwera IRC (w rzeczywistosci kontrolerem
> botnetu jest ktos, kto nim steruje, nie serwer IRC, ktory tylko
> przesyla komunikaty miedzy uzytkownikami).

Odpowiedz w takim razie, dlaczego część serwerów IRC stale, notorycznie
służy za "kontrolery botnetu", natomiast innym serwerom się to nie zdarza?

> Tak czy owak, powyzsze nie ma wielkiego znaczenia, bo decydujaca
> sprawa jest _nieskutecznosc_ takiego blokowania. Tzn. ono moze troche
> poprawi sytuacje przez kilka tygodni, tak - zanim nowa wersja softu
> bedzie korzystac z szyfrowanego P2P. Pewnie czesc juz od dawna
> korzysta, wyeliminowane zostana gorsze botnety.

Nieskuteczność, to jest twój pogląd.
Jakie ma to znaczenie, że korzysta z szyfrowanego połączenia? Nawet w
przypadku sieci P2P, poimio że sam transfer danych odbywa się z peera do
peera, jest jakiś punkt centralny, zbiorczy, który po wycięciu spowoduje,
iż taka technologia nie będzie działać lub będzie działać w ograniczonej
formie.

>> Błąd, zarażony komuter komunikuję się z zarażonym (lud podstawionym)
>> serwerem, będący botnetem
>
> Skad ten wniosek?
> Widziales kiedys takiego bota (prawdziwego)? On korzysta z normalnego
> serwera (serwerow) IRC, nie uzywa niczego "podstawionego" ani
> zarazonego. Rownie dobrze moglby uzywac np. NNTP.

Mógłby. W zasadzie nie wnikam, czy to jest serwer IRC, NEWS, czy inne
GG. Jest kontrolerem botnetu i tyle. Jeżeli administrator tegoż sobie
nie radzi z zarządzaniem, to może pewne kwestie powinien sobie przemyśleć.

>> To jest wiariant idealny, wzorcowy, jednakże podejrzewam, że mało
>> możliwy do zaimplementowania adhoc.
>
> Jak to "adhoc"? Przeciez to nie jest awaria, ktora trzeba zalatwic
> w ciagu godziny. Dlaczego zamiast spedzac czas na planowaniu
> nieskutecznych z zalozenia "rozwiazan" nie poswieca go troche by
> zaplanowac jakies rozwiazanie sensowne?

Nieskuteczne to wciąż, tylko Twój pogląd. Oczywiście zgadzam się, że
w przypadku porządnie zaplanowanej usługi pewne rzeczy jest zrobić łatwiej
i skuteczniej, jednakże nadal uważam, że to co zostało zrobione w TP, to
duży krok naprzód, biorąc pod uwagę korporacyjne realia.

--
ŁT

do góry

Krzysztof Halasa wrote:

> Zauwaz ze nikt nie broni dac stalych IP neostradom. Szczerze mowiac,
> to by takze rozwiazalo (naprawde skutecznie) wiele problemow przez nie
> powodowanych, ktorych obecnie rozwiazac sie nie da.

część klientów neo, korzystających z w/w właśnie ze względu na
dynamiczne IP odeszłaby do konkurencji











--
http://net.czarne.net/ <- łącze w świat pilnie potrzebne !!!
Dach elektrowni w Czernobylu mial byc zbudowany z materialow
ognioodpornych ale tych nie bylo,a dach byc musial,wiec
zostal zbudowany z materialow palnych

do góry

In pl.internet.polip Piotr KUCHARSKI <c...@s...waw.pl> wrote:

> Ekhm. Co znaczy "nie panuje"? Usługa działa? Działa. Klienci korzystają?
> Korzystają. Wygląda, że jednak panuje.

Serwer, który jest open-relayem dla poczty również działa, a klienci
również z niego korzystają...


> Aaa, że niby chodzi o to, że według jakichś kryteriów niektórych klientów
> nie powinniśmy obsługiwać? Nie ma sprawy, daj kryteria nadające się do
> automatycznego usuwania i jeśli są sensowne, to je wdrożę.

Porządnie przeporwadzona autoryzacja klientów z użyciem wszelkich dostępnych
mechanizmów? W przypadku innych usług jakoś się da.

> To nie jest tak, że nie prowadzimy takich działań ochronnych. Prowadzimy.
> Byliśmy pionierami wręcz. Ileż to było zgłoszeń "serwer IRC mnie atakuje",
> bo skanował na okoliczność open proxy. Wszystko ewoluuje w kierunku coraz
> trudniejszego automatycznego rozpoznawania.

Widzisz, w przypadku smtp, wcześniej również nie było wymogów, aby
dokonywać autoryzacji, używania certyfikatów itp. Niestety czasy uległy
zmianie, tak więc trzeba było wynaleźć rozwiązania, aby owy, w zasadzie
goły protokół uzbroić w mechanizmy obronne. Być może w przyadku samego
IRCa, również trzeba by pomyśleć nad takimi sposobami, aby uniemożliwić
lub przynajmniej utrudnić korzystania automatom z tej usługi.


> Nie ma sprawy, wdrożyliśmy tego samego RBL-a, co efnet. Nic to, że oni
> wpuszczają cały świat, więc muszą być dużo bardziej restrykcyjni, a my
> tylko Polskę, więc nie musimy, a nawet nie chcemy. Nic to, że TPSA
> korzysta z zupełnie innej listy adresów IP do blokowania, która nie jest
> dostępna publicznie, więc ten RBL i tak by nam nie pomógł. Nic to, że nikt
> nie zgłosił nam kontrolerów botów do zablokowania.

Zgadzam się, fakt wycięcia lub inne wątpliwe kwestie powinny być przekazane
do administratora tegoż.

> Znaczy proszę mnie źle nie zrozumieć, jestem jak najbardziej za ubijaniem
> robactwa. Ale też proszę nie rzucać sobie na wiatr, że nie panujemy nad
> usługą, bo nie usuwamy klientów, którzy spełniają nieznane name kryteria.

Chyba nikt niczego tutaj takiego nie napisał. Przynajmniej nie ja.


--
ŁT

do góry

Andrzej Karpinski <k...@j...zechcesz.to.znajdziesz> writes:

>> Mam wrazenie ze MichalJ pokazal tu jakis wykres niedawno? To dowod, ze
>> "rozwiazanie" nie bylo skuteczne juz nawet w chwili jego wprowadzenia.
>
> Mi z wykresu wynika, ze peeki spadly o rzad wielkosci. Ale oczywiscie
> to kwestia tego jak sobie chcemy zinterpretowac dane ktore mamy ;)

Na moim wykresie główny spadek nastąpił 11 listopada.

Poźniejsze spadki - jeśli w ogóle są - to dużo mniejsze. Ale każdy
liczy po swojemu.

Kiedy TP włączyło tę swoją czarną dziurę?

MJ
PS. Prosiłem, żeby mojego wykresu za "główny dowód w sprawie" nie
uważać... 8-)

do góry

Lukasz Trabinski <l...@t...nospam.net> wrote:
>> Ekhm. Co znaczy "nie panuje"? Usługa działa? Działa. Klienci korzystają?
>> Korzystają. Wygląda, że jednak panuje.
> Serwer, który jest open-relayem dla poczty również działa, a klienci
> również z niego korzystają...

I co, blokujesz ruch do open-relayów, czy od?

Poza tym porównanie nie do końca trafne.

>> Aaa, że niby chodzi o to, że według jakichś kryteriów niektórych klientów
>> nie powinniśmy obsługiwać? Nie ma sprawy, daj kryteria nadające się do
>> automatycznego usuwania i jeśli są sensowne, to je wdrożę.
> Porządnie przeporwadzona autoryzacja klientów z użyciem wszelkich dostępnych
> mechanizmów? W przypadku innych usług jakoś się da.

Uwierzytelnianie? Znaczy konta dla każdego? Znaczy nie. Trudno, będziemy
w takim razie blokowani, pewnie w końcu wymrzemy, trudno. Taka filozofia
istnienia IRCnetu, brak rejestracji nicków, kanałów, użytkowników. Nie,
że takie rejestracje istnieją w innych sieciach, z którymi ponoć nie ma
problemów, więc nie wygląda to jakoś na warunek konieczny.

>> To nie jest tak, że nie prowadzimy takich działań ochronnych. Prowadzimy.
>> Byliśmy pionierami wręcz. Ileż to było zgłoszeń "serwer IRC mnie atakuje",
>> bo skanował na okoliczność open proxy. Wszystko ewoluuje w kierunku coraz
>> trudniejszego automatycznego rozpoznawania.
> Widzisz, w przypadku smtp, wcześniej również nie było wymogów, aby
> dokonywać autoryzacji, używania certyfikatów itp. Niestety czasy uległy
> zmianie, tak więc trzeba było wynaleźć rozwiązania, aby owy, w zasadzie
> goły protokół uzbroić w mechanizmy obronne. Być może w przyadku samego
> IRCa, również trzeba by pomyśleć nad takimi sposobami, aby uniemożliwić
> lub przynajmniej utrudnić korzystania automatom z tej usługi.

Nie przeczytałeś mojego posta uważnie. Utrudniamy. Ale niekoniecznie
w dokładnie taki sam sposób, w jaki robią to firmy, od których TPSA
bierze dane do blackholingu. Zresztą nie wiadomo, w jaki. Na szczęście
wspominają coś o dzieleniu się taką listą IP, jak będziemy ją mieć, to
będziemy ją z crona aplikować.

>> Znaczy proszę mnie źle nie zrozumieć, jestem jak najbardziej za ubijaniem
>> robactwa. Ale też proszę nie rzucać sobie na wiatr, że nie panujemy nad
>> usługą, bo nie usuwamy klientów, którzy spełniają nieznane nam kryteria.
> Chyba nikt niczego tutaj takiego nie napisał. Przynajmniej nie ja.

Napisałeś w wątku o nieusuwaniu c&c, że nie panujemy nad usługą. To jest
właśnie nieusuwanie klientów, którzy spełniają nieznane nam kryteria.

Nie przeczę, wślizgiwanie się w botnety i łączenie się razem z nimi
i śledzenie, kto się skąd łaczy, nie jest złą metodą. Ale za tym powinno
pójść zgłoszenie usunięcia dostępu dla danych adresów, a nie ciche
usunięcie dostępu do usługi, bez dania szansy na reakcję. I proszę mi tu
nie wyjeżdżać, że byliśmy w jakimś skoringu na wysokiej pozycji przez X dni.
Co z tego, że byliśmy, jak o tym nie wiedzieliśmy?

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal

do góry

Przed chwilą zadzwoniła do mnie błękitna linia, w sprawie reklamacji
dotyczącej tego, że nie działa gimp.org i powiadomiła, że w związku
z tym TP udziela nam bonifikaty na abonament 50% na czas niedziałania
gimp.org. Dotyczy łącza DSL.

a.

do góry

Wemif napisał(a):

> Przed chwilą zadzwoniła do mnie błękitna linia, w sprawie reklamacji
> dotyczącej tego, że nie działa gimp.org i powiadomiła, że w związku
> z tym TP udziela nam bonifikaty na abonament 50% na czas niedziałania
> gimp.org. Dotyczy łącza DSL.

Jezeli ta informacja szybko sie rezejdzie to zachwile BL zostanie
zdosowana reklamacjami ;P

j.

--
Orle pióra, kaczy chód,
i Cesarza zwalą z nóg.
http://ussburaque.org

do góry

januszek napisał(a):
> Wemif napisał(a):
>
>> Przed chwilą zadzwoniła do mnie błękitna linia, w sprawie reklamacji
>> dotyczącej tego, że nie działa gimp.org i powiadomiła, że w związku
>> z tym TP udziela nam bonifikaty na abonament 50% na czas niedziałania
>> gimp.org. Dotyczy łącza DSL.
>
> Jezeli ta informacja szybko sie rezejdzie to zachwile BL zostanie
> zdosowana reklamacjami ;P
>
To jest tak, jak się wprowadza coś bez przemyślenia. Poza tym coś takiego to
przyznanie się, że to
jest ICH wina, że nie ma dostępu do tej strony.

wer

do góry

On 07.01.2009, Piotr KUCHARSKI <c...@s...waw.pl> wroted:

> Uwierzytelnianie? Znaczy konta dla każdego? Znaczy nie. Trudno, będziemy
> w takim razie blokowani, pewnie w końcu wymrzemy, trudno. Taka filozofia
> istnienia IRCnetu, brak rejestracji nicków, kanałów, użytkowników.

Na freenode.net jak najbardziej nicki są rejestrowane i chronione hasłami,
a bez rejestracji część funkcji nie jest dostępna.

GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Nocturnal Infiltration and Accurate Killing

do góry