Re: Problem: Dual Homed Gateway

Hallo

J Wunsch wrote:

> As Gerd Bitzer wrote:
>
> > > Wer routed auf einem Firewall aktiviert, gehört erschlagen.
>
> > Die Empfehlungen professioneller FW Berater geht dahin, auf FW's nur
> > statisches Routing einzusetzen.
>
> Wir gehören auch zu diesem Kreis :), und ja, ich würde dort sicher

Das freut mich, und das wollte ich auch keinesfalls in Abrede stellen :-)

>
> auch kein oder wenig dynamisches Routing machen wollen. GateD kann
> zuweilen vonnöten sein, wenn man einen RIP supplier benötigt, der aus
> irgendwelchen Gründen unbedingt auf dem Firewall laufen sollte. Auch
> kann er nützlich sein, wenn man seine Lernfähigkeit weit genug auf
> bekannte und als sinnvoll abgenickte Routes reduziert, wobei die via
> Routing-Protokollen gelernten Routes dann interne niedrig priorisierte
> reject-Routes überschreiben: fällt die dynamisch gelernte Route aus,
> so generiert der Firewall ein sauberes `Network unreachable' für das
> Ziel.
>
> routed ist in jedem Falle Humbug, der glaubt alles, was man ihm
> erzählt.

Habe von verschiedenen Seiten gehört, daß OSPF bei weitem RIP vorzuziehen ist.
Würde aber weder RIP noch OSPF durch die FW durchlassen, weder Inbound noch
Outbound, und wenn irgendwie möglich auf keinen Fall RIP, OSPF oder was auch
immer auf ner FW laufen lassen. Genausowenig sollte ne FW weder von Innen noch
von Außen irgendwie sichtbar sein, noch nicht mal per icmp, oder auch nicht auf
Broadcasts (z.B. xdmcp) reagieren.

>
>
> > > ab. Wenn Du alles in application-level proxies erledigen kannst,
> > > brauchst Du kein IP-Forwarding und bist eine Runde sicherer. Einige
> > > kommerzielle Produkte arbeiten grundsätzlich auf diese Weise
> > > (Checkpoint Firewall-1, AltaVista, Borderware). Mit FreeBSD (oder
> >
> > FW1 hat auch ein paar Application Level Proxy artige Dienste, dort Security
> > Server genannt.
> [...]
> > Netcat soll sich z.B. als universeller Proxy einsetzen lassen.Hab
> > ich aber noch nie probiert.
>
> FW-1 (und die anderen genannten) haben praktisch nur application-level
> proxies. Teilweise spezielle (wie die security server), teilweise
> halt allgemeine Teile à la netcat. IP-forwarding im Kernel gibt's
> dort nicht, es geht alles komplett über den Firewalldämon im Userland.
>

Das Stateful Inspection Filtering der FW1 seh ich (und z.B. Leute bei Integralis,
die FW1 schulen) eher als Packetfilter an, der aber z.B. auch bei connectionless
Protokollen (udp ..) Statusinformationen intern mitführt. Man kann bei FW1 z.B.
ziemlich einfach neue Protokollobjekte definieren, was im Fall von Application
Level Proxies weit diffiziler sein dürfte (sobald im Protokoll Besonderheiten
drin sind). Aber das Thema dürfte hier eher OT sein.

Gruß, G.Bitzer
Received on Wed 21 Oct 1998 - 07:27:25 CEST