Smok Eustachy wrote:

> > jak mnie poinformowała dezinfolinia, zgłoszenie zostało przyposane do
> > konkretnej osoby dzisiaj o 6:40
> No do 14 dni otrzymacie potwierdzenie otrzymania, a do 30 dni odpowiedz.
> Ciekawym, co w niej będzie

to mnie szczerze najbardziej ciekawi, nie chodzi już o sam fakt
zapokojenia mojej niewiedzy (została wyczerpująco wyjaśniona na
polipie), ale o podejście korporacji do klienta

moim zdaniem powinna się pojawić oficjalna, wyczerpująca informacja
gdzieś w serwisie tp i w odpowiedzi na reklamacje powinien być odnośnik
do w/w, oczywiście nie w formie "więcej informacji na stronie tp.pl",
ale raczej w formie konkretnego odnośnika do szczegółowego opisu sprawy







--
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

On Tue, 6 Jan 2009 21:09:58 +0100, RoMan Mandziejewicz
<r...@p...pl> wrote:

> Szczerze wątpię właśnie w techniczną możliwość automagicznego
> wyłapywania zombies. Owszem, można określić, kto generuje duży ruch,
> ustalić jego IP i je przyblokować.

Sam ruch to za mało, trzeba wyłapywać anomalie. A im lepszy ma
być to algorytm, tym więcej danych statystycznych trzeba
zbierać. W przypadku TP to może boleć.

> Ale zdecydowana większość zombies
> to komputery na neostradzie - z dynamicznym IP. Zablokujesz go,
> przeloguje się i tyle z blokady. A powiązanie konkretnego IP z czasem
> połączenia i konkretnym klientem, to robota niemal ręczna.

To akurat jest proste: reguły na RAS-ie/DSLAM-ie związane z
loginem lub blokada na poziomie loginu.

r.
--
____________________________________________________
_____________
robert rędziak mailto:giekao-at-gmail-dot-com
zmien kreseczkę na kropeczkę: http://forum-subaru.pl
I hope they don't fart at Greenpeace. That's bad for Gaia.

do góry

On Tue, 6 Jan 2009 21:34:42 +0100, RoMan Mandziejewicz
<r...@p...pl> wrote:

> Żeby zablokować login, to trzeba go poznać. Czyli powiązać IP z
> loginem.

Ale to robi system uwierzytelniający (objerzyj sobie jak działa
np. RADIUS). I takie dane *muszą* być logowane, choćby z uwagi
na konieczność zachowania ich dla organów ścigania.

> Całość to i tak tylko moje gdybanie. Nie wiem nawet, czy operator ma
> jakąkolwiek możliwość _dokładnego_ obserwowania ruchu generowanego przez
> userów neo. Chodzi mi o dostęp do podglądu ruchu w wyższych warstwach.

Mieć, ma, tylko że może nie mieć mocy obliczeniowej na ich
przerobienie.

r.
--
____________________________________________________
_____________
robert rędziak mailto:giekao-at-gmail-dot-com
zmien kreseczkę na kropeczkę: http://forum-subaru.pl
I hope they don't fart at Greenpeace. That's bad for Gaia.

do góry

On Tue, 6 Jan 2009 20:38:56 +0000 (UTC), robert jakub
<r...@r...org.pl> wrote:

> ale takie blokowanie loginu wlasnie sie odbije na BL. kazdy zablokowany
> bedzie dzwonil i zglaszal awarie, a na slowa: prosze zabezpieczyc
> sobie komputer, zainstalowac antywirusa itp odpowie: "ale przeciez ja
> mam dobrze zabezpieczony komputer, syn sasiada tescia mi go robil.
> prosze natychmiast mnie odblokowac." i co ma zrobic TPSA/czy inny
> operator stosujacy ta technologie?

Been there, done that. Pracowałem w kablówce, w której mieliśmy
taki system. Większość, gdy się dowiedziała (byli powiadamiani
telefonicznie i mailowo) była raczej wystraszona. Było paru
takich, którzy oczywiście się rzucali ze oni mają
superbezpieczny komputer, etc. Odblokowywało się ich i
powiadamiało się ich, że jeśli objawy wystąpią ponownie w ciągu
danego czasu, to blokada zostanie przywrócona i często była.
Rekordziści łapali się po kilka-kilkanaście razy na miesiąc, ale
większość z nich w końcu dawała za wygraną i robiła z komputerem
porządek. Paru zapewne odeszło, ale szacuję to na pojedyncze
sztuki w skali dziesiątek tysięcy klientów.

r.
--
____________________________________________________
_____________
robert rędziak mailto:giekao-at-gmail-dot-com
zmien kreseczkę na kropeczkę: http://forum-subaru.pl
I hope they don't fart at Greenpeace. That's bad for Gaia.

do góry

Dnia Tue, 06 Jan 2009 21:05:18 +0000, Robert Rędziak napisał(a):
/.../
> Been there, done that. Pracowałem w kablówce, w której mieliśmy taki
> system. Większość, gdy się dowiedziała (byli powiadamiani telefonicznie
> i mailowo) była raczej wystraszona. Było paru takich, którzy oczywiście
> się rzucali ze oni mają superbezpieczny komputer, etc. Odblokowywało
> się ich i powiadamiało się ich, że jeśli objawy wystąpią ponownie w
> ciągu danego czasu, to blokada zostanie przywrócona i często była.

Gorzej, jak coś się pomisza i poblokuje se "bo tak". W skali TP moze to
oznaczać, że np 100000 Neostrad "się zablokowało" i armagedon.

> Rekordziści łapali się po kilka-kilkanaście razy na miesiąc, ale
> większość z nich w końcu dawała za wygraną i robiła z komputerem
> porządek. Paru zapewne odeszło, ale szacuję to na pojedyncze sztuki w
> skali dziesiątek tysięcy klientów.
>
No i na drzewo ich.

do góry

Dnia Tue, 06 Jan 2009 21:34:42 +0100, RoMan Mandziejewicz napisał(a):
/..../
>
> Żeby zablokować login, to trzeba go poznać. Czyli powiązać IP z loginem.
> Znając obyczaje w TPSA, to właśnie może stanowić największy problem - bo
> "procedura zapewnienia jakości usług nie zezwala na dostęp do danych
> pracownikom technicznym" na przykład.
>
Przecież to będzie robił automat.
Tj robiłby. Tak jak teraz blokuje się Neo, jak ktoś nie płaci za nie.

> Całość to i tak tylko moje gdybanie. Nie wiem nawet, czy operator ma
> jakąkolwiek możliwość _dokładnego_ obserwowania ruchu generowanego przez
> userów neo. Chodzi mi o dostęp do podglądu ruchu w wyższych warstwach.
Już raczej by był problem z analizą tego.

do góry

RoMan Mandziejewicz <r...@p...pl> writes:

> Szczerze wątpię właśnie w techniczną możliwość automagicznego
> wyłapywania zombies. Owszem, można określić, kto generuje duży ruch,
> ustalić jego IP i je przyblokować. Ale zdecydowana większość zombies
> to komputery na neostradzie - z dynamicznym IP. Zablokujesz go,
> przeloguje się i tyle z blokady. A powiązanie konkretnego IP z czasem
> połączenia i konkretnym klientem, to robota niemal ręczna.

To musialoby byc robione na radiusie czy czego tam uzywaja. Powiazanie
konkretnego IP z klientem nie wymagaloby czasu polaczenia, przeciez
nie chodzi o dane historyczne. Wystarczyloby sprawdzic, czy w ciagu
ostatniego np. kwadransa ten klient byl caly czas zalogowany (IOW czy
jest zalogowany przynajmniej od kwadransa), jesli skrypt nie moze tego
wyciagnac to jest to conajmniej dziwne.

To jedna z opcji, oczywiscie.

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.

> Myślę, że nawet, gdyby to przeszło, to uzywany sprzęt nie daje
> możliwości automagicznego przekierowania wszelkich żądań na stronę z
> raportem - "Jesteś ZOMBIE i dopóki nie wyleczysz swojego komputera
> masz szlaban na te gołe baby z RedTube, zboczeńcu!".

A jak jest zrobiona r...@n...pl?
Tak czy owak, to sie da osiagnac wieloma sposobami, nawet jesli nie da
sie przekierowac wszystkich TCP:80. A czy sie nie da, to ja nie wiem.
--
Krzysztof Halasa

do góry

Robert Rędziak <r...@g...wkurw.org> writes:

> Sam ruch to za mało, trzeba wyłapywać anomalie. A im lepszy ma
> być to algorytm, tym więcej danych statystycznych trzeba
> zbierać. W przypadku TP to może boleć.

No ale oni przeciez w tej chwili takze to musza robic. Moze minimalnie
inaczej, ale musza.
--
Krzysztof Halasa

do góry

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

> Wiem wiem, Ty zawsze patrzysz na rozne rzeczy inaczej. Tu na szczescie
> nie ma niebezpieczenstwa "near miss" z kostucha.

Miałem trochę szczęścia na tych prawie 7 tys. metrów ;)

> Ale blackholing jakichs serwerow np. IRC niczego tu nie zmieni.
> Rozumiesz to? To nie jest skuteczne rozwiazanie, chociaz TPSA moze sie
> nim pobawic jak nowa zabawka (kosztem np. klientow).

No i tutaj się różnimy. To nie ma znacznia, czy to jest IRC serwer czy
inna maszyna. Jest kontrolerem botnetu, a jej administrator prawdopodobnie
nie panuje nad nią, czemy więc ma nie być wycięta?


> Natomiast tu mamy do czynienia z dzialaniem _z_zalozenia_
> a) nieskutecznym (na dluzsza mete), b) wycinajacym normalna
> komunikacje normalnego (niezarazonego) usera z normalnymi
> (niezarazonymi itp) serwerami.

Błąd, zarażony komuter komunikuję się z zarażonym (lud podstawionym)
serwerem, będący botnetem


> Rozumiesz? TPSA wprowadza takie rozwiazanie _wiedzac_, ze ono nie moze
> byc skuteczne. Jaki to ma sens?

To _Ty_ uważasz, że jest nieskuteczne. Ja uważam, że jest bardzo skuteczne,
a jednoczesne proste w rozwiązaniu i mało kosztowne.

> 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.

To jest wiariant idealny, wzorcowy, jednakże podejrzewam, że mało
możliwy do zaimplementowania adhoc.

--
ŁT

do góry

Lukasz Trabinski <l...@t...nospam.net> writes:

>> Wiem wiem, Ty zawsze patrzysz na rozne rzeczy inaczej. Tu na szczescie
>> nie ma niebezpieczenstwa "near miss" z kostucha.
>
> Miałem trochę szczęścia na tych prawie 7 tys. metrów ;)

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

> No i tutaj się różnimy. To nie ma znacznia, czy to jest IRC serwer czy
> inna maszyna. Jest kontrolerem botnetu, a jej administrator prawdopodobnie
> nie panuje nad nią, czemy więc ma nie być wycięta?

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?

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).


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.

> 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.

> To _Ty_ uważasz, że jest nieskuteczne. Ja uważam, że jest bardzo skuteczne,
> a jednoczesne proste w rozwiązaniu i mało kosztowne.

Mam wrazenie ze MichalJ pokazal tu jakis wykres niedawno? To dowod, ze
"rozwiazanie" nie bylo skuteczne juz nawet w chwili jego wprowadzenia.

Proste i tanie, w to nie watpie nawet przez chwile.

> 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?
--
Krzysztof Halasa

do góry