eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.internet.poliptraceroute › Re: traceroute
  • Data: 2004-11-23 13:05:14
    Temat: Re: traceroute
    Od: Marek Moskal <m...@i...p-l> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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)

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: