Re: traceroute

Autor: Marek Moskal <moskit_at_irc.p-l>
Data: Tue 23 Nov 2004 - 14:05:14 MET
Message-ID: <Xns95AA8F4D2703Amoskit@171.69.11.157>
Content-Type: text/plain; charset=iso-8859-2

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)
Received on Tue Nov 23 14:10:26 2004

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Tue 23 Nov 2004 - 14:40:04 MET