🚀 go-pugleaf

On Tue, 02 Nov 2010 21:02:42 +0100, Sławek Lipowski napisał:
> Witam,
>
> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy 
> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z 
> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>
> W kierunku naszych serwerów www, właśnie z AC-Xa, z różnych sieci 
> (potwierdzone przez NOC), wygląda na to, że także ze styku z PLIXem 
> (sądząc na podstawie MAC adresu), dociera sporo ruchu z takiej adresacji.
>
> Czy to jest norma?
>
> Pozdrawiam i z góry dzięki za poświęcony czas. :)

Tnij na wejściu. 

-- 
#begin 755 signature.exe
[tomek <at> sikornik <dot> net]                             vy 73! de SP9UOB
Proud to be 100 percent microsoft free.                            op. Tomek

W dniu 02.11.2010 21:04, Verox pisze:
> On Tue, 02 Nov 2010 21:02:42 +0100, Sławek Lipowski napisał:
>> Witam,
>>
>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>>
>> W kierunku naszych serwerów www, właśnie z AC-Xa, z różnych sieci
>> (potwierdzone przez NOC), wygląda na to, że także ze styku z PLIXem
>> (sądząc na podstawie MAC adresu), dociera sporo ruchu z takiej adresacji.
>>
>> Czy to jest norma?
>>
>> Pozdrawiam i z góry dzięki za poświęcony czas. :)
>
> Tnij na wejściu.
>

Jasne, tylko raz, że tego jest naprawdę sporo i generuje to jakieś tam 
obciążenie firewalli, dwa, że chciałbym potwierdzić, że nie ma to 
żadnego negatywnego wpływu na pozostały ruch.

Trochę sobie tego złapałem do analizy i z tego co na razie widzę, 
zdarzają się pakiety z ustawionymi flagami RST i ACK (seq=2 ack=1), ale 
generalnie są to pakiety z ustawionymi flagami FIN i ACK (seq=1 ack=1). 
Wygląda to więc jak próba zamknięcia połączenia TCP. Jeśli z jakiegoś 
powodu po stronie sieci użytkownika odwiedzającego nasze strony ruch ten 
nie jest NATowany na prawidłowy IP i jest przez nas porzucany, to 
połączenia TCP z naszymi serwerami www mogą nie być zamykane prawidłowo, 
co może generować pewne problemy...

-- 
Sławomir Lipowski
http://lipowski.org

W dniu 02.11.2010 21:57, Sławek Lipowski pisze:

> Jasne, tylko raz, że tego jest naprawdę sporo i generuje to jakieś tam
> obciążenie firewalli, dwa, że chciałbym potwierdzić, że nie ma to
> żadnego negatywnego wpływu na pozostały ruch.
> 
Jakich firewalli jeśli tniesz bogony w filtrach bgp (a przynajmniej się
powinno)?

Pozdrawiam
Daniel

W dniu 2010-11-02 22:04, Daniel pisze:
> W dniu 02.11.2010 21:57, Sławek Lipowski pisze:
> 
>> Jasne, tylko raz, że tego jest naprawdę sporo i generuje to jakieś tam
>> obciążenie firewalli, dwa, że chciałbym potwierdzić, że nie ma to
>> żadnego negatywnego wpływu na pozostały ruch.
>>
> Jakich firewalli jeśli tniesz bogony w filtrach bgp (a przynajmniej się
> powinno)?
> 
Raczej chodzi o to że pakiety przychodzą, a nie o to że "przychodzi" w BGP.

-- 
[WRC] Biały Scenic 2000 1,9 dTI
CB: Intek M-490 ML 145

+-=-=-=-=-=-=-=- Przemysław Gubernat -=-=-=-=-=-=-=-=-=-=-=-+
| _API Internet_ A. Stolarczyk i P. Gubernat Spółka Jawna   |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

On Tue, 02 Nov 2010 21:57:34 +0100, Sławek Lipowski napisał:
> W dniu 02.11.2010 21:04, Verox pisze:
>> On Tue, 02 Nov 2010 21:02:42 +0100, Sławek Lipowski napisał:
>>> Witam,
>>>
>>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>>>
>>> W kierunku naszych serwerów www, właśnie z AC-Xa, z różnych sieci
>>> (potwierdzone przez NOC), wygląda na to, że także ze styku z PLIXem
>>> (sądząc na podstawie MAC adresu), dociera sporo ruchu z takiej adresacji.
>>>
>>> Czy to jest norma?
>>>
>>> Pozdrawiam i z góry dzięki za poświęcony czas. :)
>>
>> Tnij na wejściu.
>>
>
> Jasne, tylko raz, że tego jest naprawdę sporo i generuje to jakieś tam 
> obciążenie firewalli, dwa, że chciałbym potwierdzić, że nie ma to 
> żadnego negatywnego wpływu na pozostały ruch.

Ale po co Ci firewall jak _powinieneś_ to wyciąć na filtrach od BGP? 


-- 
#begin 755 signature.exe
[tomek <at> sikornik <dot> net]                             vy 73! de SP9UOB
Proud to be 100 percent microsoft free.                            op. Tomek

On Tue, 02 Nov 2010 22:04:53 +0100, Daniel napisał:
> W dniu 02.11.2010 21:57, Sławek Lipowski pisze:
>
>> Jasne, tylko raz, że tego jest naprawdę sporo i generuje to jakieś tam
>> obciążenie firewalli, dwa, że chciałbym potwierdzić, że nie ma to
>> żadnego negatywnego wpływu na pozostały ruch.
>> 
> Jakich firewalli jeśli tniesz bogony w filtrach bgp (a przynajmniej się
> powinno)?

O właśnie. 


-- 
#begin 755 signature.exe
[tomek <at> sikornik <dot> net]                             vy 73! de SP9UOB
Proud to be 100 percent microsoft free.                            op. Tomek

W dniu 02.11.2010 22:04, Daniel pisze:
> W dniu 02.11.2010 21:57, Sławek Lipowski pisze:
>
>> Jasne, tylko raz, że tego jest naprawdę sporo i generuje to jakieś tam
>> obciążenie firewalli, dwa, że chciałbym potwierdzić, że nie ma to
>> żadnego negatywnego wpływu na pozostały ruch.
>>
> Jakich firewalli jeśli tniesz bogony w filtrach bgp (a przynajmniej się
> powinno)?
>
> Pozdrawiam
> Daniel

BGP nie ma tu nic do rzeczy. Mam styk w L2 z sieciami, które kierują do 
mnie pakiety IP z adresami żródłowymi jak w temacie. Jeśli chcieć, żeby 
mi to nie trafiło na farmę www, trzeba by to jednak upuścić na firewallu 
jakimś. ;)

Jednak aktualnie większym zmartwieniem jest dla mnie to, że w wyniku tej 
nieprawidłowości mogą nie być prawidłowo zamykane połączenia tcp do 
farmy www... :\

Jak by ktoś z uczestników AC-Xa w L2 mógł przeanalizować, czy obserwuje 
u siebie podobny ruch, byłbym wdzięczny.

-- 
Sławomir Lipowski
http://lipowski.org

W dniu 02.11.2010 22:19, Verox pisze:
> On Tue, 02 Nov 2010 21:57:34 +0100, Sławek Lipowski napisał:
>> W dniu 02.11.2010 21:04, Verox pisze:
>>> On Tue, 02 Nov 2010 21:02:42 +0100, Sławek Lipowski napisał:
>>>> Witam,
>>>>
>>>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>>>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>>>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>>>>
>>>> W kierunku naszych serwerów www, właśnie z AC-Xa, z różnych sieci
>>>> (potwierdzone przez NOC), wygląda na to, że także ze styku z PLIXem
>>>> (sądząc na podstawie MAC adresu), dociera sporo ruchu z takiej adresacji.
>>>>
>>>> Czy to jest norma?
>>>>
>>>> Pozdrawiam i z góry dzięki za poświęcony czas. :)
>>>
>>> Tnij na wejściu.
>>>
>>
>> Jasne, tylko raz, że tego jest naprawdę sporo i generuje to jakieś tam
>> obciążenie firewalli, dwa, że chciałbym potwierdzić, że nie ma to
>> żadnego negatywnego wpływu na pozostały ruch.
>
> Ale po co Ci firewall jak _powinieneś_ to wyciąć na filtrach od BGP?
>
>

RSy AC-Xa nie rozgłaszają mi takich tras, więc nie ma czego filtrować 
nawet. Szczerze, to nie za bardzo wiem, o co Ci chodzi. :) Przecież to, 
co dostaje z BGP i co trafia do mojej tablicy rutingu, a to, jaki adres 
IP mogą mieć pakiety trafiające na dany interfejs, to są niezależne 
rzeczy...

-- 
Sławomir Lipowski
http://lipowski.org

-- 
Sławomir Lipowski
http://lipowski.org

Dnia 02.11.2010 Sławek Lipowski <slawek@lipowski.org> napisał/a:

> Jednak aktualnie większym zmartwieniem jest dla mnie to, że w wyniku tej 
> nieprawidłowości mogą nie być prawidłowo zamykane połączenia tcp do 
> farmy www... :\

Samo zjawisko przeciekania pakietów z prywatnym IP źródłowym to nic nowego.
Kiedyś na pewnym rekursywnym serwerku DNS analizowałem ruch i było tego całkiem sporo. ;)
Oczywiście, nie ma sensu próbować przetwarzać żądania od kogoś, do kogo odpowiedź na pewno nigdy nie dotrze.


-- 
Paweł Małachowski

On 02-11-10 21:02, Sławek Lipowski wrote:
> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>
> W kierunku naszych serwerów www, właśnie z AC-Xa, z różnych sieci
> (potwierdzone przez NOC), wygląda na to, że także ze styku z PLIXem
> (sądząc na podstawie MAC adresu), dociera sporo ruchu z takiej adresacji.
>
> Czy to jest norma?

To jest norma. Internet jest pełen tego, niestety.

-- 
Grzegorz Janoszka

W dniu 02.11.2010 23:07, Grzegorz Janoszka pisze:
> On 02-11-10 21:02, Sławek Lipowski wrote:
>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>>
>> W kierunku naszych serwerów www, właśnie z AC-Xa, z różnych sieci
>> (potwierdzone przez NOC), wygląda na to, że także ze styku z PLIXem
>> (sądząc na podstawie MAC adresu), dociera sporo ruchu z takiej adresacji.
>>
>> Czy to jest norma?
>
> To jest norma. Internet jest pełen tego, niestety.
>

A to, że w prawie 100% są to wyłącznie pakiety z ustawionymi flagami FIN 
i ACK też jest normalne?

Jak to wygląda z Twojego doświadczenia?

-- 
Sławomir Lipowski

On 2010-11-02 23:16, Sławek Lipowski wrote:

> A to, że w prawie 100% są to wyłącznie pakiety z ustawionymi flagami FIN i
> ACK też jest normalne?
> Jak to wygląda z Twojego doświadczenia?

Mówiłem o tym na CONFidence kiedyś a potem na bodaj Cisco Expo -
daje się czasem nawet nawiązać sesję do serwerka stojącego z
taką adresacją, czasem coś ściągnąć, czasem dostaniesz nieproszony
ruch w Twoją stronę, po zgłoszeniu zwykle problem znika - czasem
"na zawsze", czasem "na chwilę". To zależy gdzie był błąd, czy
przecieka sieć operatora czy styku z Internetem i jak realizowana
jest separacja (MPLSem czy ręcznie).

Jeśli dostajesz tego faktycznie tyle że Ci się 'firewalle męczą'
to jest coś nie tak i sugerowałbym skontaktować się z dostawcą
(chyba że to bardzo zmęczone firewalle), jeśli znow chciałeś ściągać
ludzi do siebie na stronę to OK, ale już naprawdę starczy.

-- 
"Everything will be okay in the end.  |                 Łukasz Bromirski
  If it's not okay, it's not the end." |      http://lukasz.bromirski.net

W dniu 03.11.2010 00:05, Łukasz Bromirski pisze:
 > Mówiłem o tym na CONFidence kiedyś a potem na bodaj Cisco Expo -
 > daje się czasem nawet nawiązać sesję do serwerka stojącego z
 > taką adresacją, czasem coś ściągnąć, czasem dostaniesz nieproszony
 > ruch w Twoją stronę, po zgłoszeniu zwykle problem znika - czasem
 > "na zawsze", czasem "na chwilę". To zależy gdzie był błąd, czy
 > przecieka sieć operatora czy styku z Internetem i jak realizowana
 > jest separacja (MPLSem czy ręcznie).

Będę próbować dążyć w tym kierunku, czyli spróbować zgłosić to do sieci, 
z których ten ruch pochodzi...

 > Jeśli dostajesz tego faktycznie tyle że Ci się 'firewalle męczą'
 > to jest coś nie tak i sugerowałbym skontaktować się z dostawcą

Zmęczenie firewalla możemy pominąć. Bardziej martwi mnie to, że to być 
może jest ruch, który powinien przychodzić z prawidłowymi IP i zamykać 
rzeczywiście nawiązywane połączenia. Jasne, że można przeprowadzić 
akademickie rozważanie, na ile to generuje problemy, a na ile nie, ale 
dziwi mnie w ogóle fakt występowania takiej anomalii.

 > (chyba że to bardzo zmęczone firewalle), jeśli znow chciałeś ściągać
 > ludzi do siebie na stronę to OK, ale już naprawdę starczy.
 >
 > --
 > "Everything will be okay in the end. | Łukasz Bromirski
 > If it's not okay, it's not the end." | http://lukasz.bromirski.net

Ale czym ściągnąć? Umieszczeniem adresu strony w podpisie? ;) Widzisz w 
tym coś złego? ;>

Generalnie napisałem tu tylko po to, żeby w miarę możliwości zorientować 
się, czy inni uczestnicy AC-Xa też otrzymują podobny ruch.

Pozdrawiam.

-- 
Sławomir Lipowski
http://lipowski.org

On 02-11-10 23:16, Sławek Lipowski wrote:
>>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>> To jest norma. Internet jest pełen tego, niestety.
> A to, że w prawie 100% są to wyłącznie pakiety z ustawionymi flagami FIN
> i ACK też jest normalne?

Są po prostu błędy w implementacji NAT/PAT. Większość ruterków domowych 
ma bardzo proste oprogramowanie i translacja adresów jest tam 
niedoskonała. Zdarza się, że niektóre pakiety wyciekają z oryginalnymi 
adresami źródłowymi. Pewnie wielu producentów korzysta z tego samego 
kodu, który natuje tylko pierwszy pakiet fin/ack, a wszystkie 
retransmisje przepuszcza.

-- 
Grzegorz Janoszka

On 03.11.2010 10:42, Grzegorz Janoszka wrote:
> On 02-11-10 23:16, Sławek Lipowski wrote:
>>>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>>>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>>>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>>> To jest norma. Internet jest pełen tego, niestety.
>> A to, że w prawie 100% są to wyłącznie pakiety z ustawionymi flagami FIN
>> i ACK też jest normalne?
> 
> Są po prostu błędy w implementacji NAT/PAT. Większość ruterków domowych
> ma bardzo proste oprogramowanie i translacja adresów jest tam
> niedoskonała. Zdarza się, że niektóre pakiety wyciekają z oryginalnymi
> adresami źródłowymi. Pewnie wielu producentów korzysta z tego samego
> kodu, który natuje tylko pierwszy pakiet fin/ack, a wszystkie
> retransmisje przepuszcza.
> 

Ale dlaczego przechodzi to przez brzegowe? Przecież tu nie ma routerków
domowych.

-- 
wer <",,)~~
http://szumofob.eu

W dniu 03.11.2010 10:42, Grzegorz Janoszka pisze:
> On 02-11-10 23:16, Sławek Lipowski wrote:
>>>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>>>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>>>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>>> To jest norma. Internet jest pełen tego, niestety.
>> A to, że w prawie 100% są to wyłącznie pakiety z ustawionymi flagami FIN
>> i ACK też jest normalne?
>
> Są po prostu błędy w implementacji NAT/PAT. Większość ruterków domowych
> ma bardzo proste oprogramowanie i translacja adresów jest tam
> niedoskonała. Zdarza się, że niektóre pakiety wyciekają z oryginalnymi
> adresami źródłowymi. Pewnie wielu producentów korzysta z tego samego
> kodu, który natuje tylko pierwszy pakiet fin/ack, a wszystkie
> retransmisje przepuszcza.
>

To jest ciekawy trop. Dzięki. Tylko że problem musiałby dotyczyć raczej 
urządzeń szkieletowych operatorów, a nie urządzeń domowych.

-- 
Sławek Lipowski
http://lipowski.org

3 Lis, 10:53, Sławek Lipowski <sla...@lipowski.org> napisał:

> To jest ciekawy trop. Dzięki. Tylko że problem musiałby dotyczyć raczej
> urządzeń szkieletowych operatorów, a nie urządzeń domowych.

Dlaczego tak uwazasz? Operator forwarduje pakiety na podstawie adresu
docelowego, a nie zrodlowego, w zasadzie adres zrodlowy moglby go w
ogole nie interesowac. Adres zrodlowy interesuje Ciebie - uzytkownika
koncowego.

Herlok Sz.

On 03-11-10 10:49, bofh@nano.pl wrote:
> On 03.11.2010 10:42, Grzegorz Janoszka wrote:
>> On 02-11-10 23:16, Sławek Lipowski wrote:
>>>>> Mam pytanie do uczestników AC-Xa, którzy mają do niego dostęp w L2. Czy
>>>>> obserwujecie docieranie do waszych sieci ruchu z adresami źródłowymi z
>>>>> podsieci 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16?
>>>> To jest norma. Internet jest pełen tego, niestety.
>>> A to, że w prawie 100% są to wyłącznie pakiety z ustawionymi flagami FIN
>>> i ACK też jest normalne?
>>
>> Są po prostu błędy w implementacji NAT/PAT. Większość ruterków domowych
>> ma bardzo proste oprogramowanie i translacja adresów jest tam
>> niedoskonała. Zdarza się, że niektóre pakiety wyciekają z oryginalnymi
>> adresami źródłowymi. Pewnie wielu producentów korzysta z tego samego
>> kodu, który natuje tylko pierwszy pakiet fin/ack, a wszystkie
>> retransmisje przepuszcza.
>
> Ale dlaczego przechodzi to przez brzegowe? Przecież tu nie ma routerków
> domowych.

A dlaczego ma nie przechodzić przez rutery operatorów? Pakiet z adresem 
źródłowym 192.168 jest takim samym pakietem jak wszystkie inne.

Jest tzw. dobrą praktyką filtrować to, co przychodzi od klientów, żeby 
nie przepuszczać żadnych zespoofowanych (takie staropolskie słowo) 
adresów, ale kto w PL to robi? Ostatni raz z firmami typu Netia, 
Crowley, GTS/Energis, TKTelekom itp miałem do czynienia jakieś 3 lata 
temu i nikt wtedy nie filtrował. Wątpię, czy od tamtego czasu zmieniło 
się wiele. Ktoś może przetestować?

-- 
Grzegorz Janoszka

>
> BGP nie ma tu nic do rzeczy. Mam styk w L2 z sieciami, które kierują do 
> mnie pakiety IP z adresami żródłowymi jak w temacie. Jeśli chcieć, żeby mi 
> to nie trafiło na farmę www, trzeba by to jednak upuścić na firewallu 
> jakimś. ;)

Hmm... Ale przecież ta Twoja farma serwerów ma po drodze do tych IXów 
router. Nie wystawiasz przecież farmy wprost w L2 do IXów, tylko via router. 
I na nim odfiltrujesz śmieci.


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

> RSy AC-Xa nie rozgłaszają mi takich tras, więc nie ma czego filtrować 
> nawet. Szczerze, to nie za bardzo wiem, o co Ci chodzi. :) Przecież to, co 
> dostaje z BGP i co trafia do mojej tablicy rutingu, a to, jaki adres IP 
> mogą mieć pakiety trafiające na dany interfejs, to są niezależne rzeczy...

Jaki masz problem w ubiciu na routerze pakietów z src priv IP?


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

W PLIX starym się wycinać wszystko co lata na numeracji prywatnej,
nawet męczyliśmy klientów żeby u siebie sprawdzali czemu coś takiego
dostajemy. Taki ruch obserwowaliśmy u 60-70% uczestników. Tak naprawdę
walka z wiatrakami ;-))

W dniu 03.11.2010 11:13, Zboj pisze:
>>
>> BGP nie ma tu nic do rzeczy. Mam styk w L2 z sieciami, które kierują do
>> mnie pakiety IP z adresami żródłowymi jak w temacie. Jeśli chcieć, żeby mi
>> to nie trafiło na farmę www, trzeba by to jednak upuścić na firewallu
>> jakimś. ;)
>
> Hmm... Ale przecież ta Twoja farma serwerów ma po drodze do tych IXów
> router. Nie wystawiasz przecież farmy wprost w L2 do IXów, tylko via router.
> I na nim odfiltrujesz śmieci.
>
>

Jasne, pomijając co jest między IXami o farmą, techniczne odfiltrowanie 
tego ruchu nie jest problemem. Po prostu marzy mi się idealny świat, w 
którym pakiety te będą docierać z prawidłowymi adresami źródłowymi i 
połączenia TCP do farmy www będą zamykane prawidłowo. Odfiltrowanie tego 
ruchu przez kogokolwiek takiego efektu bynajmniej nie da.

Zakładam w tym momencie, że pakiety te są wysyłane w celu zamykania 
rzeczywiście nawiązanych wcześniej połączeń TCP, tylko z jakiegoś powodu 
nie są natowane na prawidłowy IP.

-- 
Sławek Lipowski

W dniu 03.11.2010 11:15, Zboj pisze:
>> RSy AC-Xa nie rozgłaszają mi takich tras, więc nie ma czego filtrować
>> nawet. Szczerze, to nie za bardzo wiem, o co Ci chodzi. :) Przecież to, co
>> dostaje z BGP i co trafia do mojej tablicy rutingu, a to, jaki adres IP
>> mogą mieć pakiety trafiające na dany interfejs, to są niezależne rzeczy...
>
> Jaki masz problem w ubiciu na routerze pakietów z src priv IP?
>
>

Nie mam żadnego problemu. Chciałbym wyeliminować przyczynę ich 
generowania i uniknąć konsekwencji.

-- 
Sławek Lipowski

W dniu 03.11.2010 11:08, Grzegorz Janoszka pisze:
> (...)
>
> A dlaczego ma nie przechodzić przez rutery operatorów? Pakiet z adresem
> źródłowym 192.168 jest takim samym pakietem jak wszystkie inne.
>
> Jest tzw. dobrą praktyką filtrować to, co przychodzi od klientów, żeby
> nie przepuszczać żadnych zespoofowanych (takie staropolskie słowo)
> adresów, ale kto w PL to robi? Ostatni raz z firmami typu Netia,
> Crowley, GTS/Energis, TKTelekom itp miałem do czynienia jakieś 3 lata
> temu i nikt wtedy nie filtrował. Wątpię, czy od tamtego czasu zmieniło
> się wiele. Ktoś może przetestować?
>

No to pytanie, czy nie powinno to się zmienić. Zakładałem jednak, że 
firmy ISP nie pozwalają klientowi końcowemu wysyłać ruchu z dowolnego 
IP. Jeśli tak nie jest, to to jest bardzo cenna informacja.

-- 
Sławek Lipowski

W dniu 03.11.2010 11:22, nastach pisze:
> W PLIX starym się wycinać wszystko co lata na numeracji prywatnej,
> nawet męczyliśmy klientów żeby u siebie sprawdzali czemu coś takiego
> dostajemy. Taki ruch obserwowaliśmy u 60-70% uczestników. Tak naprawdę
> walka z wiatrakami ;-))
>

Kiepska informacja. Dziwi też fakt niechęci ludzi do prostowania takich 
rzeczy.

-- 
Sławomir Lipowski

>
> Nie mam żadnego problemu. Chciałbym wyeliminować przyczynę ich generowania 
> i uniknąć konsekwencji.

Nie wyeliminujesz. Jak już tu padło - privIP to prawidłowe IP i co do zasady 
pakiet z takim src IP poleci w sieć zarówno intencjonalnie, jak i poprzez 
błędy w NAT/PAT. Z uwagi na ich przeznaczenie - powinno się je ciąć. Jaka 
jest praktyka - padło już w tej dyskusji. Nie ma sensu postulowanie o 
idealny świat. Realia są ziemskie.

Wracając do meritum. Jak chcesz uniknąć konsekencji - musisz je ciąć. Jak 
nie chcesz ciąć - zmagasz się z konsekwencjami. Nie ma tu żadnej filozofii.

Pozdrawiam,


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

W dniu 03.11.2010 10:59, Airen pisze:
> 3 Lis, 10:53, Sławek Lipowski<sla...@lipowski.org>  napisał:
>
>> To jest ciekawy trop. Dzięki. Tylko że problem musiałby dotyczyć raczej
>> urządzeń szkieletowych operatorów, a nie urządzeń domowych.
>
> Dlaczego tak uwazasz? Operator forwarduje pakiety na podstawie adresu
> docelowego, a nie zrodlowego, w zasadzie adres zrodlowy moglby go w
> ogole nie interesowac. Adres zrodlowy interesuje Ciebie - uzytkownika
> koncowego.
>
> Herlok Sz.
>

No tak, ale odfiltrowanie ruchu z nieprawidłowym adresem źródłowym, 
który przychodzi od klienta końcowego nie jest chyba głupim pomysłem 
chociażby w kontekście uniemożliwienia takiemu klientowi wykonania DoSa 
poprzez wygenerowanie ruchu z losowym IP. Tak że czy na pewno ISP nie 
powinien sprawdzać adresu źródłowego pakietów pochodzących od klienta 
końcowego?

-- 
Sławek Lipowski

W dniu 03.11.2010 12:54, Zboj pisze:
>>
>> Nie mam żadnego problemu. Chciałbym wyeliminować przyczynę ich generowania
>> i uniknąć konsekwencji.
>
> Nie wyeliminujesz. Jak już tu padło - privIP to prawidłowe IP i co do zasady
> pakiet z takim src IP poleci w sieć zarówno intencjonalnie, jak i poprzez
> błędy w NAT/PAT. Z uwagi na ich przeznaczenie - powinno się je ciąć. Jaka
> jest praktyka - padło już w tej dyskusji. Nie ma sensu postulowanie o
> idealny świat. Realia są ziemskie.
>
> Wracając do meritum. Jak chcesz uniknąć konsekencji - musisz je ciąć. Jak
> nie chcesz ciąć - zmagasz się z konsekwencjami. Nie ma tu żadnej filozofii.
>
> Pozdrawiam,
>
>

Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie 
dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie 
wyeliminuje tej konsekwencji.

-- 
Sławek Lipowski

On 03-11-10 12:46, Sławek Lipowski wrote:
> Nie mam żadnego problemu. Chciałbym wyeliminować przyczynę ich
> generowania i uniknąć konsekwencji.

To idź i napraw wszystkie sieci na świecie. Popraw też embedded code w 
milionach ruterków soho. Może będzie prościej, jak zupgradujesz 
wszystkich do IPv6, nie uważasz? Przy okazji zadbaj też o to, żeby nie 
było głodu, wojen, a drób żeby siedział w kurniku/kaczniku i nie wtrącał 
się do polityki. Postrasz rosołem.

BtW - jakie są konsekwencje tego, że dostajesz pakiety fin/ack z 
prywatnych adresów?

-- 
Grzegorz Janoszka

>
> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie 
> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie 
> wyeliminuje tej konsekwencji.

Ale wytnie ruch z priv IP w całości. O tyle możesz mieć mniej. Reszta i tak 
będzie musiała expirować, jak to się dzieje dotychczas. Zyskujesz więc 
trochę, ale nie rozwiążesz problemu, bo to wymaga pracy u źródła. BTW - jak 
w sieciach będą cięte privIP skutecznie, to i tak będą wisiały u Ciebie 
sesje z braku FIN+ACK, które opisujesz. Dla algorytmu rozważań nie ma 
znaczenia, czy cięcie privIP nastapi u Ciebie, czy np.w  PLIXie.

Masz lepszy pomysł - posłucham z ciekawością.


-- 
---
Zboj (Piotr Marciniak)
   zboj \at/ mnc.pl 

On 03-11-10 13:01, Sławek Lipowski wrote:
> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
> wyeliminuje tej konsekwencji.

Jesteś pewien, że nie dociera? IMHO te nienatowane, co widzisz, to 
retransmisje.

-- 
Grzegorz Janoszka

On 03.11.2010 13:06, Grzegorz Janoszka wrote:
> On 03-11-10 12:46, Sławek Lipowski wrote:
>> Nie mam żadnego problemu. Chciałbym wyeliminować przyczynę ich
>> generowania i uniknąć konsekwencji.
> 
> To idź i napraw wszystkie sieci na świecie. Popraw też embedded code w
> milionach ruterków soho. Może będzie prościej, jak zupgradujesz
> wszystkich do IPv6, nie uważasz? Przy okazji zadbaj też o to, żeby nie
> było głodu, wojen, a drób żeby siedział w kurniku/kaczniku i nie wtrącał
> się do polityki. Postrasz rosołem.
> 
> BtW - jakie są konsekwencje tego, że dostajesz pakiety fin/ack z
> prywatnych adresów?
> 

Jeśli dostaje z prywatnych to tym bardziej z tej sieci mogą wyjść
spoofowane adresy, co już groźniejsze, szczególnie przy UDP.

-- 
wer <",,)~~
http://szumofob.eu

Dnia 03.11.2010 Grzegorz Janoszka <Grzegorz@nie-lubie-spamu.Janoszka.pl> napisał/a:
> adresów, ale kto w PL to robi? Ostatni raz z firmami typu Netia, 
> Crowley, GTS/Energis, TKTelekom itp miałem do czynienia jakieś 3 lata 
> temu i nikt wtedy nie filtrował. Wątpię, czy od tamtego czasu zmieniło 
> się wiele. Ktoś może przetestować?
netia jakies "3 lata temu" filtrowala.

Przynajmniej mnie, w Poznaniu ;)

-- 
Andrzej 'The Undefined' Dopierała
HomePage: http://andrzej.dopierala.name/
Reprezentuję siebie i wyrażam tylko moje zdanie!

W dniu 03.11.2010 13:10, Zboj pisze:
>>
>> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
>> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
>> wyeliminuje tej konsekwencji.
>
> Ale wytnie ruch z priv IP w całości.

Z priv IP dostaję tylko FIN+ACK.

> O tyle możesz mieć mniej. Reszta i tak
> będzie musiała expirować, jak to się dzieje dotychczas. Zyskujesz więc
> trochę, ale nie rozwiążesz problemu, bo to wymaga pracy u źródła. BTW - jak
> w sieciach będą cięte privIP skutecznie, to i tak będą wisiały u Ciebie
> sesje z braku FIN+ACK, które opisujesz. Dla algorytmu rozważań nie ma
> znaczenia, czy cięcie privIP nastapi u Ciebie, czy np.w  PLIXie.

O tym już pisaliśmy, nie chodzi o to, żeby TYLKO wyciąć ten ruch 
(nigdzie nie stwierdziłem, że uważam, że go nie należy ciąć), ale też 
wyeliminować jego źródło i ewentualne konsekwencje tych nieprawidłowości.

> Masz lepszy pomysł - posłucham z ciekawością.

Poza odfiltrowaniem ruchu, ustalenie, kto go generuje i kontakt z danymi 
sieciami.

-- 
Sławek Lipowski

W dniu 03.11.2010 13:18, Grzegorz Janoszka pisze:
> On 03-11-10 13:01, Sławek Lipowski wrote:
>> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
>> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
>> wyeliminuje tej konsekwencji.
>
> Jesteś pewien, że nie dociera? IMHO te nienatowane, co widzisz, to
> retransmisje.
>

Postaram się potwierdzić w wolnej chwili i dam znać.

-- 
Sławek Lipowski

3 Lis, 12:58, Sławek Lipowski <sla...@lipowski.org> napisał:

> No tak, ale odfiltrowanie ruchu z nieprawidłowym adresem źródłowym,
> który przychodzi od klienta końcowego nie jest chyba głupim pomysłem
> chociażby w kontekście uniemożliwienia takiemu klientowi wykonania DoSa
> poprzez wygenerowanie ruchu z losowym IP.

Jaka jest różnica w skuteczności ataku z wykorzystaniem losowego
adresu z puli prywatnych, a losowego adresu z puli publicznych?

> Tak że czy na pewno ISP nie
> powinien sprawdzać adresu źródłowego pakietów pochodzących od klienta
> końcowego?

Jako dobra praktyka byłoby to wskazane, ale nie możesz tego wymagać od
swojego operatora. W końcu jego zadaniem jest kierowanie ruchu jaki do
Ciebie próbują inni przesłać.

Herlok Sz.

W dniu 03.11.2010 20:45, Airen pisze:
> 3 Lis, 12:58, Sławek Lipowski<sla...@lipowski.org>  napisał:
>
>> No tak, ale odfiltrowanie ruchu z nieprawidłowym adresem źródłowym,
>> który przychodzi od klienta końcowego nie jest chyba głupim pomysłem
>> chociażby w kontekście uniemożliwienia takiemu klientowi wykonania DoSa
>> poprzez wygenerowanie ruchu z losowym IP.
>
> Jaka jest różnica w skuteczności ataku z wykorzystaniem losowego
> adresu z puli prywatnych, a losowego adresu z puli publicznych?

Miałem na myśli łącze dostarczane przeciętnemu Kowalskiemu, więc 
nieprawidłowy adres źródłowy w tym wypadku = każdy inny niż np. jeden mu 
przyznany.

>> Tak że czy na pewno ISP nie
>> powinien sprawdzać adresu źródłowego pakietów pochodzących od klienta
>> końcowego?
>
> Jako dobra praktyka byłoby to wskazane, ale nie możesz tego wymagać od
> swojego operatora. W końcu jego zadaniem jest kierowanie ruchu jaki do
> Ciebie próbują inni przesłać.
>
> Herlok Sz.

IMHO ISP dostarczając łącze klientowi końcowemu nie powinni przechodzić 
do porządku dziennego nad możliwością puszczenia przez ich klientów 
końcowych pakietów z dowolnym adresem źródłowym.

-- 
Sławek Lipowski

> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
> wyeliminuje tej konsekwencji.

nie, konsekwencja dla mnie jest to ze musze sprawdzic pol miliona pakietow
na sekunde zeby odfiltrowac te z niechcianych adresow. Bez sensu. Jak do
tego dodam cala mase rzeczy ktore chcialbym filtrowac na routerze brzegowym
to juz wychodzi pewne obciazenie. Tak jak pisalem bez sensu. Jak ktos ma
problem ze zlym zamykaniem sesji TCP to pisz do tego kto ma ten problem i
niech sobie radzi wlasnie ten ktos




Icek

> > To idź i napraw wszystkie sieci na świecie. Popraw też embedded code w
> > milionach ruterków soho. Może będzie prościej, jak zupgradujesz
> > wszystkich do IPv6, nie uważasz? Przy okazji zadbaj też o to, żeby nie
> > było głodu, wojen, a drób żeby siedział w kurniku/kaczniku i nie wtrącał
> > się do polityki. Postrasz rosołem.
> >
> > BtW - jakie są konsekwencje tego, że dostajesz pakiety fin/ack z
> > prywatnych adresów?
> >
>
> Jeśli dostaje z prywatnych to tym bardziej z tej sieci mogą wyjść
> spoofowane adresy, co już groźniejsze, szczególnie przy UDP.

a spoofowane z innych adresow nie moga wyjsc ?????




Icek

Dnia 04.11.2010 Icek <icek@do.pl> napisał/a:
>> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
>> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
>> wyeliminuje tej konsekwencji.
>
> nie, konsekwencja dla mnie jest to ze musze sprawdzic pol miliona pakietow
> na sekunde zeby odfiltrowac te z niechcianych adresow. 
masz 500kpps "niechcianego" ruchu? napewno nie jest to atak dos? Albo nawet ddos?

U mnie na interfejsie do plixa - owszem - widze troszke pakietow z adresami
"prywatnymi", ale - glownie wychodzace. Czesc z urzadzen w sieciach ktore nie
potrzebuja internetu, a musza byc widoczne w sieci(a nie chcialo mi sie ich
wycinac na firewallu), czesc zapewne z jakis routerkow ktore robia nata, ale
cos im umknie... itepe. Wiem - powinno to byc odfiltrowane, ale dla ruchu kilku
pps nie chcialo mi sie jeszcze usiasc i posprawdzac wszystkiego ;)

-- 
Andrzej 'The Undefined' Dopierała
HomePage: http://andrzej.dopierala.name/
Reprezentuję siebie i wyrażam tylko moje zdanie!

>> Masz lepszy pomysł - posłucham z ciekawością.
> 
> Poza odfiltrowaniem ruchu, ustalenie, kto go generuje i kontakt z danymi 
> sieciami.

no to do dzieła, naprawa globalnego Internetu czeka ;)

Marcin

>> Masz lepszy pomysł - posłucham z ciekawością.
> 
> Poza odfiltrowaniem ruchu, ustalenie, kto go generuje i kontakt z danymi 
> sieciami.

no to do dzieła, naprawa globalnego Internetu czeka ;)

Marcin

W dniu 03.11.2010 14:39, Sławek Lipowski pisze:
> W dniu 03.11.2010 13:18, Grzegorz Janoszka pisze:
>> On 03-11-10 13:01, Sławek Lipowski wrote:
>>> Ale konsekwencją jest niezamykanie połączeń TCP w prawidłowy sposób. Nie
>>> dociera FIN+ACK od klienta z prawidłowego IP. Cięcie pakietów nie
>>> wyeliminuje tej konsekwencji.
>>
>> Jesteś pewien, że nie dociera? IMHO te nienatowane, co widzisz, to
>> retransmisje.
>>
>
> Postaram się potwierdzić w wolnej chwili i dam znać.
>

Udało mi się powiązać część ruchu z FIN+ACK z src IP z klas prywatnych z 
połączeniami TCP, które nie zostały zamknięte przez zdalny host. 
Jednakże to gównie poszlaki. Pasuje TTL i id pakietów IP układają się 
wiarygodnie. Część takiego ruchu nie udało mi się z niczym powiązać. 
Może niepotrzebnie łączę te fakty, aczkolwiek to, że te pakiety mają 
praktycznie zawsze ustawioną flagę FIN sprawia, że bardzo mocno wydaje 
mi się, że nie jest to jakoś bardzo ogólny problem, tylko dość 
szczególny przypadek.

Być może faktycznie głównie są to retransmisje, które nie łapią się już 
w NAT. Jeśli by tak było, to nie ma dramatu (oczywiście to też nie 
powinno mieć miejsca), przy czym dalej uważam, że to strona generująca 
takie pakiety powinna zadbać o ich odfiltrowanie. Inaczej to trochę tak, 
jak by zamiast ścigać złodziei samochodów nakazać wszystkim instalację 
super zabezpieczeń antykradzieżowych w autach. Zabezpieczenia i tak 
można i pewnie powinno się montować, ale to nie znaczy bynajmniej, że 
nie trzeba chociażby próbować łapać złodziei. :)

-- 
Sławek Lipowski

W dniu 04.11.2010 22:52, Marcin Kuczera pisze:
>
>>> Masz lepszy pomysł - posłucham z ciekawością.
>>
>> Poza odfiltrowaniem ruchu, ustalenie, kto go generuje i kontakt z
>> danymi sieciami.
>
> no to do dzieła, naprawa globalnego Internetu czeka ;)
>
> Marcin

Ogólne przesłanie bijące z tego wątku jest mało pocieszające. Wygląda na 
to, że większość z ludzi zajmujących się sieciami przywykła do 
nieprawidłowości i jest przekonana, że nic się z tym nie da zrobić. W 
AC-Xie nie są to tylko pakiety z src IP z klasy prywatnej, z wypowiedzi 
jednej z osób wynika, że w PLIX jest podobnie.

NOC ATMANa niestety nie widzi w zgłoszonym przypadku powodu do 
jakiejkolwiek interwencji z ich strony, a bez ich pomocy ciężko coś 
wskórać i np. ustalić, kto tak naprawdę ten ruch generuje (jest niby 
adres MAC, który można przypisać do IP z puli stykowej, ale nie ma 
gwarancji, że adres MAC nie jest fałszywy). Temat pozostaje więc chyba 
pozostawić samemu sobie.

-- 
Sławek Lipowski

Ja uważam, że może mieć miejsce nie wiem czy dobrze myślę i czy akurat jest
to o co chodzi w temacie... Ogółem stare. Odpal sobie serwer irc +
http://packetstormsecurity.org/irc/kaiten.c  i TSUNAMI <target> <secs>  :)

Jesteś najwyraźniej ofiarą takiego botnetu. Wystarczy jedna maszyna a syfu
potrafi nawalić ostro. Tylko dlaczego bogon ip puszcza...


Pozdrawiam,
Dulin


W dniu 6 listopada 2010 12:39 użytkownik Sławek Lipowski <
slawek@lipowski.org> napisał:

> W dniu 04.11.2010 22:52, Marcin Kuczera pisze:
> >
> >>> Masz lepszy pomysł - posłucham z ciekawością.
> >>
> >> Poza odfiltrowaniem ruchu, ustalenie, kto go generuje i kontakt z
> >> danymi sieciami.
> >
> > no to do dzieła, naprawa globalnego Internetu czeka ;)
> >
> > Marcin
>
> Ogólne przesłanie bijące z tego wątku jest mało pocieszające. Wygląda na
> to, że większość z ludzi zajmujących się sieciami przywykła do
> nieprawidłowości i jest przekonana, że nic się z tym nie da zrobić. W
> AC-Xie nie są to tylko pakiety z src IP z klasy prywatnej, z wypowiedzi
> jednej z osób wynika, że w PLIX jest podobnie.
>
> NOC ATMANa niestety nie widzi w zgłoszonym przypadku powodu do
> jakiejkolwiek interwencji z ich strony, a bez ich pomocy ciężko coś
> wskórać i np. ustalić, kto tak naprawdę ten ruch generuje (jest niby
> adres MAC, który można przypisać do IP z puli stykowej, ale nie ma
> gwarancji, że adres MAC nie jest fałszywy). Temat pozostaje więc chyba
> pozostawić samemu sobie.
>
> --
> Sławek Lipowski
> _______________________________________________
> POLIP mailing list
> POLIP@man.lodz.pl
> https://lists.man.lodz.pl/mailman/listinfo/polip
>

Sławek Lipowski wrote:
> W dniu 04.11.2010 22:52, Marcin Kuczera pisze:
>>
>>>> Masz lepszy pomysł - posłucham z ciekawością.
>>>
>>> Poza odfiltrowaniem ruchu, ustalenie, kto go generuje i kontakt z
>>> danymi sieciami.
>>
>> no to do dzieła, naprawa globalnego Internetu czeka ;)
>>
>> Marcin
> 
> Ogólne przesłanie bijące z tego wątku jest mało pocieszające. Wygląda na 
> to, że większość z ludzi zajmujących się sieciami przywykła do 
> nieprawidłowości i jest przekonana, że nic się z tym nie da zrobić. W 
> AC-Xie nie są to tylko pakiety z src IP z klasy prywatnej, z wypowiedzi 
> jednej z osób wynika, że w PLIX jest podobnie.


no i co z tego ?
To jest problem firm obsługujących farmy serwerów i innych dla których 
to ma znaczenie, ale dla telekomów to nie ma żadnego znaczenia tak więc 
nie ma uzasadnienia ponoszenia kosztów związanych z rozwiązywaniem 
takich spraw.

Marcin

6 Lis, 04:39, Sławek Lipowski <sla...@lipowski.org> napisał:

> NOC ATMANa niestety nie widzi w zgłoszonym przypadku powodu do
> jakiejkolwiek interwencji z ich strony, a bez ich pomocy ciężko coś
> wskórać...

Być może mają ważniejsze rzeczy do roboty od naprawiania całego
internetu.
Skoro nie udało Ci się z tym ruchem, sugeruję zacząć szerzyć pokój na
świecie. To na pewno ma sens :)

Herlok Sz.

> > nie, konsekwencja dla mnie jest to ze musze sprawdzic pol miliona
pakietow
> > na sekunde zeby odfiltrowac te z niechcianych adresow.
> masz 500kpps "niechcianego" ruchu? napewno nie jest to atak dos? Albo
nawet ddos?

nie, mam tyle chcianego. Ale żeby wyłapać z chcianego ten niechciany to
muszę każdy sprawdzić nie ?


> U mnie na interfejsie do plixa - owszem - widze troszke pakietow z
adresami
> "prywatnymi", ale - glownie wychodzace. Czesc z urzadzen w sieciach ktore
nie
> potrzebuja internetu, a musza byc widoczne w sieci(a nie chcialo mi sie
ich
> wycinac na firewallu), czesc zapewne z jakis routerkow ktore robia nata,
ale
> cos im umknie... itepe. Wiem - powinno to byc odfiltrowane, ale dla ruchu
kilku
> pps nie chcialo mi sie jeszcze usiasc i posprawdzac wszystkiego ;)

no mi tak samo. Bez sensu zajmowac sie problemem, ktory nie jest problemem a
jeżeliby zastosować jakieś rozwiązanie to ono generowałoby większy problem
niż ten obecnie istniejący


Icek

W dniu 06.11.2010 15:11, Airen pisze:
> (...)  sugeruję zacząć szerzyć pokój na
> świecie. To na pewno ma sens :)
>
> Herlok Sz.
>
>

Chyba jednak nie warto. Trafię najprawdopodobniej głównie na samych 
konserwatywnych pesymistów, którzy na wstępie powiedzą, że to się nie 
uda i nie ma sensu nawet kiwnąć palcem, żeby chociażby w minimalnym 
stopniu spróbować coś z tym zrobić. Będą motywować to tym, że nie widzą 
w tym nic nadzwyczajnego, a poza tym to nie ich problem, a to, że na 
świecie nie ma pokoju to jest normalka i nic nowego...

-- 
Sławek Lipowski

W dniu 2010-11-07 00:57, Sławek Lipowski pisze:
> Chyba jednak nie warto. Trafię najprawdopodobniej głównie na samych
> konserwatywnych pesymistów, którzy na wstępie powiedzą, że to się nie
> uda i nie ma sensu nawet kiwnąć palcem, żeby chociażby w minimalnym
> stopniu spróbować coś z tym zrobić. Będą motywować to tym, że nie widzą
> w tym nic nadzwyczajnego, a poza tym to nie ich problem, a to, że na
> świecie nie ma pokoju to jest normalka i nic nowego...

Zgadza się. Nie można im przetłumaczyć, że lepiej jest wrogiem dobrze.

-- 
start