<<< Date Index >>>     <<< Thread Index >>>

Re: [FYI] Core Internet technology vulnerable to hacking



Hi,

On Wed, Apr 21, 2004 at 10:10:17AM +1000, Peter Ross wrote:
> > Das spukt schon seit ein paar Wochen als "furchtbar wichtiges Problem,
> > aber man darf keine Details nennen" ueber alle Security-Mailing-Listen
> > - ist aber nur dann ein echtes Problem, wenn die betroffenen Netzwerke
> > auf grundlegende Dinge wie Anti-Spoofing-Filter ("keine Pakete mit
> > einer Source-IP aus meinem Netz duerfen von aussen kommen") vernach-
> > laessigen.
> 
> Macht man doch nicht;-) Mal im Ernst: Fuer mich als LAN-Admin mit relativ
> "dichten" Netzen (wenige WAN-Verbindungen) ist es recht einfach,
> Adressspoofing zu unterbinden, aber wie sieht das in der gaengigen
> Backbone-Praxis aus?

Es gibt Netzbetreiber, denen das alles egal ist ("der zahlt ja fuer seinen
Traffic").

Bei anderen Anbietern wird da relativ rigoros gefiltert.  Es gibt hier
drei Klassen von Leitungen:

 - Kundenleitungen - inzwischen relativ gut automatisierbar filterbar
    ("unicast reverse path filtering" - wenn die Source-IP von dem
    ankommenden Paket keine Adresse ist, die dort *hin* geroutet werden
    wuerde, wird das Paket verworfen.   Bei asymmetrischem Routing muss
    man aufpassen, bei single-homed-Kunden ist damit das Problem trivial
    geloest)

 - Backbone-Leitungen im eigenen Netz - hier wird i.A. nicht gefiltert

 - Upstream-Leitungen und Peering-Punkte - hier kann man relativ gut 
   die eigenen Netzbloecke schuetzen, also via Access-List auf Pakete
   filtern, die vorgeblich eine Source-IP aus dem eigenen Netzblock
   haetten.  Hier muss man hier und da mal eine Ausnahme definieren,
   aber das ist auch in den Griff zu bekommen.

   Problematisch sind hier Router mit mangelnder Filterperformance...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@xxxxxxxxxxxxxx
fax: +49-89-35655025                        gert@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

-- 
To unsubscribe, e-mail: debate-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: debate-help@xxxxxxxxxxxxxx