Użytkownik <w...@c...3miasto.net> napisał w wiadomości
news:1101113819.711926@chylonia.3miasto.net...
>> taki pakiet tutaj się znaleźć nie powinien - ale skąd taka telia, mająca
>> dużo
>> klientów, ma wiedzieć, że któryś z ich klientów nie obsługuje takiej
>> sieci
>> jeżeli IP źródłowe jest routowalne? Znaczy wiedzieć to w teorii może i ma
>> jak,
>
> powinna obcinać przy źródle tzn. od klienta A puszczać tylko pakiety
> należące do A.

chyba ze klient ma np. zle skonfowane BGP i rozglasza 10/8 :)

--
mateo

do góry

Paweł Tyll <o...@o...pl> wrote:
>> A taka telia/tpsa nie powinna tego wycinac? Czy moze byłoby to zbyt
>> 'meczace' dla routerow?

Jeżeli ma klientów końcowych, to oczywiście. W tranzycie sensu nie ma.

> jeżeli IP źródłowe jest routowalne?

Używaj prywatne/publiczne zamiast nie/routowalne.

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)

do góry

Piotr KUCHARSKI napisal(a) [22 Nov 2004]:

>>> A taka telia/tpsa nie powinna tego wycinac? Czy moze byłoby to zbyt
>>> 'meczace' dla routerow?
> Jeżeli ma klientów końcowych, to oczywiście. W tranzycie sensu nie ma.

W pewnej mierze ma - nawet w przypadku tranzytu operator powinien MBSZ
wycinac na brzegu pakiety z niewlasciwymi adresami zrodlowymi, np. z sieci
prywatnych czy tez z wlasnej sieci operatora (!). Taka odrobina higieny.

PS: dla kompletnosci dyskusji - mechanizm do tego sluzacy na "duzych"
routerach nazywa sie "unicast Reverse Path Forwarding check" (uRPF) i jego
dwie podstawowe odmiany to tryb "strict" (dla laczy do klientow koncowych,
weryfikacja czy adres zrodlowy ma w tablicy routingu trase wskazujaca na
interfejs z ktorego taki pakiet przyszedl) albo "loose" (dla ruchu
tranzytowego lub pochodzacego od klientow typu multi-home, weryfikacja czy
trasa do adresu zrodlowego w ogole jest w tablicu routingu). Pozwala to
"wyczyscic" to, co sie wpuszcza do wlasnego szkieletu.

--
(moskit-at-irc.pl)

do góry

Marek Moskal wrote:
> Piotr KUCHARSKI napisal(a) [22 Nov 2004]:
>
>
>>>>A taka telia/tpsa nie powinna tego wycinac? Czy moze byłoby to zbyt
>>>>'meczace' dla routerow?
>>
>>Jeżeli ma klientów końcowych, to oczywiście. W tranzycie sensu nie ma.
>
>
> W pewnej mierze ma - nawet w przypadku tranzytu operator powinien MBSZ
> wycinac na brzegu pakiety z niewlasciwymi adresami zrodlowymi, np. z sieci
> prywatnych czy tez z wlasnej sieci operatora (!). Taka odrobina higieny.
>
> PS: dla kompletnosci dyskusji - mechanizm do tego sluzacy na "duzych"
> routerach nazywa sie "unicast Reverse Path Forwarding check" (uRPF) i jego
> dwie podstawowe odmiany to tryb "strict" (dla laczy do klientow koncowych,
> weryfikacja czy adres zrodlowy ma w tablicy routingu trase wskazujaca na
> interfejs z ktorego taki pakiet przyszedl) albo "loose" (dla ruchu
> tranzytowego lub pochodzacego od klientow typu multi-home, weryfikacja czy
> trasa do adresu zrodlowego w ogole jest w tablicu routingu). Pozwala to
> "wyczyscic" to, co sie wpuszcza do wlasnego szkieletu.

To wszystko pięknie Marku, ale w teorii. W praktyce zaraz wychodzą różne
"kwiatki". A to w tablicach BGP (nawet tych od najwiekszych światowych
operatorów) nie pojawia się komplet informacji o wszystkich używanych
sieciach, a to zdażają się nieprzewidziane, hmmm, trudności ze sprzętem.
Żeby daleko nie szukać: np. włączenie uRPF na karcie STM-16 na GSR
wyłącza obsługę NetFlow (niezbędny z kolei do wykrywania ataków DoS) :-(

do góry

Marek Moskal <m...@i...p-l> wrote:
>>>> A taka telia/tpsa nie powinna tego wycinac? Czy moze byłoby to zbyt
>>>> 'meczace' dla routerow?
>> Jeżeli ma klientów końcowych, to oczywiście. W tranzycie sensu nie ma.
> W pewnej mierze ma - nawet w przypadku tranzytu operator powinien MBSZ
> wycinac na brzegu pakiety z niewlasciwymi adresami zrodlowymi, np. z sieci
> prywatnych

I nie można by było dostać icmp z prywatnego linku /30 ;)

> czy tez z wlasnej sieci operatora (!). Taka odrobina higieny.

Jestem w stanie sobie wyobrazić taką awarię, że od operatora do tego
samego operatora idzie przez innego.

I naprawdę by wystarczyło filtrowanie klientów źródłowych od klientów
końcowych.

> PS: dla kompletnosci dyskusji - mechanizm do tego sluzacy na "duzych"
> routerach nazywa sie "unicast Reverse Path Forwarding check" (uRPF) i jego
> dwie podstawowe odmiany to tryb "strict" (dla laczy do klientow koncowych,
> weryfikacja czy adres zrodlowy ma w tablicy routingu trase wskazujaca na
> interfejs z ktorego taki pakiet przyszedl)

I uRPF strict będzie szybszy niż ACL? Czy tylko wygodniejszy w konfiguracji?

> albo "loose" (dla ruchu
> tranzytowego lub pochodzacego od klientow typu multi-home, weryfikacja czy
> trasa do adresu zrodlowego w ogole jest w tablicu routingu).

He he, zrobili w końcu; pamiętam, jak wprowadzili uRPF i popsuli multihoming.

> Pozwala to "wyczyscic" to, co sie wpuszcza do wlasnego szkieletu.

Pod warunkiem, że nikt śmieci nie ogłasza -- czyli marne zabezpieczenie. ;p
Ile to już razy widziałem ogłaszane rfc1918.

p.

--
Beware of he who would deny you access to information, for in his
heart he dreams himself your master. -- Commissioner Pravin Lal
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów ;)

do góry

Piotr KUCHARSKI napisal(a) [23 Nov 2004]:

>> W pewnej mierze ma - nawet w przypadku tranzytu operator powinien
>> MBSZ wycinac na brzegu pakiety z niewlasciwymi adresami zrodlowymi,
>> np. z sieci prywatnych
> I nie można by było dostać icmp z prywatnego linku /30 ;)

Przeciez nikt rozsadny nie ponumeruje laczy w szkielecie prywatnymi
adresami ;> Bo psuje to zalecenia RFC, bo psuje PMTU, bo czasami dziwne
kwiatki wychodza jak klient cos spsuje u siebie...

Jest projekt przeznaczenia zakresu adresow na adresy "operatorskie"
(trzecia klasa obok publicznych i prywatnych), ktore bylyby zarezerwowane
dla laczy szkieletowych, mozna by je bylo spokojnie wyfiltrowac na
wszystkich wejsciach/wyjsciach do innych sieci (peering i klienci) i mozna
by je bylo powtarzac w kazdym szkielecie.

Co do filtrowania... sa duzi operatorzy ktorzy robia znacznie bardziej
restrykcyjne filtrowanie, np. nie wpuszczaja do swojej sieci zadnych
pakietow z adresami docelowymi bedacymi /30 na laczu do klienta. Klientow
trzeba bylo co prawda oduczyc od pingowania adresow IP laczy routerow
(pinguje sie ewentualnie loopbacki) ale wszystko dziala i eliminuje spora
czesc atakow.

Itd, itd...

>> czy tez z wlasnej sieci operatora (!). Taka odrobina higieny.
> Jestem w stanie sobie wyobrazić taką awarię, że od operatora do tego
> samego operatora idzie przez innego.

Co innego gdy ktos swiadomie przeanalizowal siec, wie kiedy taka awaria
moze sie przydazyc, czy w tym przypadku chcialby routing "naokolo" i
swiadomie nie korzysta z takiego filtrowania, a co innego jezeli sie w
ogole nad tym nie zastanowil.

Kwestia tranzytu wlasnego ruchu przez innego operatora poprzez rozdzielone
awaria kawalki sieci to takze np. sprawa uzgodnien peeringowych.

> I naprawdę by wystarczyło filtrowanie klientów źródłowych od klientów
> końcowych.

To zdecydowanie pierwszy krok. Internet juz nie jest tak bezpiecznym
miejscem jak kiedys byl...

> I uRPF strict będzie szybszy niż ACL? Czy tylko wygodniejszy w
> konfiguracji?

Wygodniejszy w konfiguracji jest na pewno, dziala automatycznie (przy
ewentualnyh przeadresowaniu nie trzeba grzebac w ACLach), duzo mniejsza
mozliwosc pomylki przy zmianach w ACLu. Szybkosc zalezy od urzadzenia i
implementacji, bo uRPF oznacza wykonanie dodatkowego lookupu w tablicy
routingu (czy raczej w tablicy forwardingu), co moze byc szybsze od ACLa,
ale nie musi.

>> Pozwala to "wyczyscic" to, co sie wpuszcza do wlasnego szkieletu.
> Pod warunkiem, że nikt śmieci nie ogłasza -- czyli marne
> zabezpieczenie. ;p Ile to już razy widziałem ogłaszane rfc1918.

A zalozyc filtry na trasy otrzymywane z BGP to nie uaska? ;)
Zaden pojedynczy mechanizm nie pozwoli ci zabezpieczyc sieci, ale im
wiecej punktow uszczelnisz, tym lepiej.

--
(moskit-at-irc.pl)

do góry

Mariusz Krukowski napisal(a) [23 Nov 2004]:

>> PS: dla kompletnosci dyskusji - mechanizm do tego sluzacy na
>> "duzych" routerach nazywa sie "unicast Reverse Path Forwarding
>> check" (uRPF)
> To wszystko pięknie Marku, ale w teorii.

Najpierw trzeba przynajmniej znac teorie i probowac ja zastosowac. Ty ja
znasz i probojesz stosowac i znasz konkretne ograniczenia (sprzetowe jak w
przypadku starszych kart do GSRa czy operacyjne jak przyklad z BGP). W
wielu przypadkach chodzi jednak o uswiadomienie ludzi ze cos takiego mozna
i powinno sie (w miare mozliwosci) robic.

--
(moskit-at-irc.pl)

do góry