-
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)
Następne wpisy z tego wątku
- 23.11.04 13:18 Marek Moskal
Najnowsze wątki z tej grupy
- Jest tutaj kto? Halo, Darius Expert?
- Czy to konieczne? ATMAN - 30.06.2019 - Wyłączenie news.atman.pl
- pl.internet.polip - is DEAD?
- ovh
- INEA
- Prośba o traceroute z Vectry
- BGP - wszyscy wkładają głowę w piasek.
- http://pl
- Re: Czemu jest wylaczany serwer w3cache.icm.edu.pl ?
- Taaaka integracaj na rynku, a tu nikt, nic..
- Alternatywna sieć dla internetu kiedyś w Polsce
- ooerator gsm + stały ip z revdns
- Dostęp do ip nostrady
- narzędzia do weryfikacji poprawności bazy WHOIS
- T-mobile bawi się w MITM....
Najnowsze wątki
- 2024-05-26 O co chodzi?
- 2024-05-26 PJ autobus-tramwaj
- 2024-05-26 Renault Trafic i lampka z czerwonym STOP
- 2024-05-26 cena pięciocyfrowa
- 2024-05-26 Re: Jak dobra KE "okrada" złą Rosję "dla Ukrainy"
- 2024-05-25 supercap
- 2024-05-25 Sulzbach => Technischer Rollouter (d/m/w) <=
- 2024-05-25 Warszawa => Senior Account Manager <=
- 2024-05-25 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-25 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-25 Warszawa => Interactive/Experience Designer <=
- 2024-05-25 Warszawa => Key Account Manager <=
- 2024-05-25 Warszawa => SAP WM Consultant / Execution <=
- 2024-05-25 Warszawa => Key Account Manager <=
- 2024-05-25 Re: znów ten wrocław