Re: Kluge oder doofe Idee: Zweistufige Firewall mit VPN

Juergen P. Meier wrote:
Nein, selbst die
Quelladresse ist kein zuverlaessiges Kriterium, da Adressfaelschung
moeglich und praktikabel ist.
Noch mal, ich glaub ich kapier das nicht richtig: Kann denn ein Paket, daß eine *private* Adresse im Header trägt so "weit" kommen. Ich bin wahrscheinlich einfach nur total naiv... Das kommt davon, wenn man zu lange auf der guten Seite der "Macht" steht. :-)

Zudem musst du zwingend Pruefen, ob dein Linksys-Router zuverlaessig
verhindert, dass Pakete zwischen dem VPN-Tunnel und dem
Internet-Uplink geroutet werden.
Ähm... Du meinst, damit ein Paket vom Internet-Uplink nicht in den Tunnel gerät? Ebenfalls -vv, bitte.

Andernfalls koennten dir die
VPN-Admins deiner Gescheaftspartner dahin treten, wo es weh tut.
Oh, zumindest *ein* Problem, daß wir nicht haben. Ich bin "die VPN ADMINS unserer Geschäftspartner". :-)

Ja. Oder - wenn der Angreifer mehr Detailkenntnisse ueber Anwendungen
und Netztopologie hat - Datenmodifikationsangriffe, oder wenn dein
Router zwischen Internet und VPN Routet (und Nattet) direkt die
eigentlich durch das VPN geschuetzten Kundensysteme angreift.
D.h., wenn ich das mir mal an einem praktischen Beispiel vor Augen führe (bitte korrigier mich, wenn ich daneben liege): Jemand müßte wissen, daß mein VPN-Router eine Verbinung ins private Netz meines Kunden darstellt, dann ein Paket auf die Reise zu meinem Router schicken, und ihm die Routinginformation mitgeben (*hüstel* ich und routing... geht sowas überhaupt oder verzapfe ich grade End-Schwachsinn?), die VPN-Strecke zu unserem Kunden für einen Angriff auf dessen Netz zu verwenden?


Falls sich dir die Moeglichkeit bietet, wuerde ich den VPN-Router mit
alleine dieser Funktion in eine (kollabierte) DMZ der Firewall packen
---[Internet]----(DSL-Modem)---(Linux mit PPPoE und Firewall)---[LAN]
|
(Linksys VPN-Router)

Ja, an sowas habe ich auch schon gedacht. Bei ein paar Kunden lasse ich die Firewalls auch noch PPPoE übernehmen. Allerdings hat sich das als nicht ganz so handlich herausgestellt, da einige Services beim Wechsel der externen Adresse (die wie bei ADSL üblich sich nun mal alle 24h ändert), darunter auch iptables, aber auch der Squid die Arbeit verweigern. OK... das haben wir mit einem Skript, das bei Adresswechsel die entsprechenden Dienste neu startet, gut in den Griff bekommen. Aber schöner wär's, wenn ein vorgeschalteter Router dies übernehmen würde.

Nun gut, wat nicht geht, geht nicht. Also kommt der Linksys in 'ne DMZ und die Firewall kümmert sich ums DSL, nur mal für den Moment angenommen.

Auf dem Linux-Rechner kannst du dann mittels "Advanced Routing (so
heist das bei Linux in der Dokumenetation)" oder allgemein Policy
Routing in Verbindung mit iptables die VPN-TunnelinhaltsDatenstroeme
vom Rest getrennt behandeln und Filtern, und verhindern, dass Pakete
aus einem VPN-tunnel ins Internet gelangen.
Ah, jetzt ja... Mit Advanced Routing beträte ich allerdings (für mich) völliges Neuland. Und da Chefe will, daß das ganze am besten schon gestern über die Bühne gegangen ist... Lieber wäre es mir, ich könnte bei native iptables bleiben.

iptebles -i <dev> die
VPN-Pakete (die vom Linksys router kommen) zuverlaessig anhand des
Interfaces, wo sie reinkommen erkennen kannst, unabhaengig von ihrer
IP Adresse.
Hört sich gut an. Fast wie in der guten_alten_Zeit(tm), als es noch ipsec-Interfaces gab (man, wat war das alles noch schön einfach damals).

Du musst die SAs deiner VPN-Partner kennen und auf dem
Linux-Rechner diese Netze an den Linksys Router routen, damit dieser
deine Pakete aus dem LAN auch in die VPN-tunnel einpacken kann.
Die Security Associations? Ähm... reicht es nicht, wenn ich einfach die Zielnetze meiner Kunden über den Linksys route? Ich administriere die Netze der Kunden, kann also definitiv ausschließen, daß es da zu Duplikaten kommt. Oder meinst Du mit SA in diesem Fall nur die Netzadressen? Innerhalb von IPSEC meint SA doch m.E. die Kombination aus Key bzw. Shared Secret und Adresse, oder?

Sinnvollerweise sollte mindestens das iptables-Regelwerk in der
FORWARD Chain der filter-Tabelle jeglichen nicht-IPSEC Traffic zwischen
DMZ-Interface und Internet-Interface verbieten.
OK, das kapiere sogar ich.

So, jetzt zum NAT-Detail - du hast wohl nur eine oeffentliche IP:
Richtig. Eine öffentliche, *dynamische* IP.

Fall 1) der Linksys und deine VPN-Partner unterstuetzen NAT-Traversal,
das ist der einfachste Fall:
Von NAT-T habe ich schon mal gehört... *hüstel* In der Doku zu meinem Router finde ich nix über dessen Befähigung zu NAT-T. Allerdings scheint es mit *meiner* Befähigung zu NAT-T auch nicht allzu weit her zu sein.

Ich lese bei http://en.wikipedia.org/wiki/NAT-T:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NAT-T (NAT-Traversal in the IKE) is a mechanism in IPsec for UDP encapsulation of the ESP packets in order to better go through firewalls. The negotiation during the Internet key exchange (IKE) phase is defined in RFC 3947 and the UDP encapsulation itself is defined in RFC 3948.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ähm... ja. Also in welches UDP-Protokoll wird ESP nun eingepackt? Und wer packt da was ein? Wenn ich es richtig Ich muß ganz ehrlich eingestehen, daß ich mit...

http://www.rfc-archive.org/getrfc.php?rfc=3948

....doch ein wenig überfordert bin. Nein, nein, bitte, das soll keine Aufforderung sein, mit NAT-T im Detail darzulegen. Spar Dir den Schweiß. :-) Aber wenn Du vielleicht eine Quelle für etwas verständlichere Literatur zu dem Thema in Deiner Linksammlung hättest?

In der PREROUTING-Chain der nat-Tabelle packst du eine NAT-Regel fuer
die UDP oder TCP Pakete, in denen die IPSEC Pakete verpackt sind und
DNATest das auf die jetzt private IP des Linksys (Analog in
POSTROUTING eine SNAT fuer ausgehende Verbindungen).
Verstanden.

Fall 2) der Linksys braucht dann nachwievor die Offizielle IP,
Die offizielle IP braucht die Firewall nach außen.

> bei DynIP musst du die IP bei jeder Aenderung auch
am Linksys manuell aendern und die NAT-Regel anpassen),
Das finde ich doch einen *ähm* eher speziellen Vorschlag. OK... ich könnte mir mit einigem Auffwand ein Skript stricken, daß die externe IP der FW ausliest, und das diese IP dann per "Fernsteuerung" in die HTML-Formulare des Linksys "einträgt". Nicht, daß ich sowas schon mal gemacht hätte... Aber alle 24h die Adresse manuell einzutragen, auch am WE und wenn ich im Urlaub bin? Naja...

zusaetzlich
hast du jedoch auch Private IP zwischen Linksys und Linux-Rechner.
Ein Transfer-Netz sozusagend.

Auf dem Linksys brauchst du eine default route an die Private IP des
Linux-Rechners.
Auch verstanden, klar.

Auf dem Linux-Rechner musst du jetzt Tricksen, damit er IPSEC Pakete,
die eigentlich an ihn selbst addressiert sind, unveraendert an den
Linksys Router schiebt.
Warum tricksen? Reicht dafür nicht einfaches DNAT? "Mag" das IPSEC des Linksys die Pakete nicht mehr annehmen, wenn das DNAT der Firewall die Header-Informationen manipuliert hat?

iptables -t nat -I PREROUTING -i eth0 -p 50,51 -j DNAT 172.16.1.2
iptables -t nat -I POSTROUTING -o eth2 -p 50,51 -d 172.16.1.2 \
-j DNAT $oeffentliche-adresse
Laß mich zusammenfassen bzw. vereinfachen: Du schickst das Paket erst per Prerouting an die private Adresse des Routers, und wenn das Routing schon terminiert ist, manipulierst Du den Header der Pakete so, daß als Ziel doch wieder die offizielle Adresse darinsteht? Rafiniert. Sowas macht mir aber nun *wirklich* 'nen Knoten ins Hirn. :-)

HTH,
*Ufff* Ja. Ich glaube, ich muß mir noch mal 'ne Firewallschulung reinziehen. Bin wohl gedanklich noch bei den wundervollen ipsec-Interfaces hängengeblieben. Ich sollte an dieser Stelle wohl geflissentlich verschweigen, daß ich noch bis letztes Jahr Schulungen zu ipsec gegeben habe (allerdings immer nur über Kernel 2.4.x...)? ;-)

Hm... vielleicht bleib ich doch bei OpenVPN...

Danke und viele Grüße,

A.
PS: Gibt's ein gutes Buch/eine gute Seite um die Methoden der Black-Heads kennenzulernen? Mir schwant, meine Firewallregeln könnten *noch* solider gestrickt sein, wenn ich genauer wüßte, wovor ich mich schützen muß. Wie IP-Spoofing funktioniert will mir z.B. - s.o. - einfach nicht in den Kopp.

--
dawin GmbH - Andreas Stallmann - Consultant
http://www.dawin.de
.

Relevant Pages

  • Re: Kluge oder doofe Idee: Zweistufige Firewall mit VPN
    ... Source-Adressen der Pakete, also Adressen aus dem lokalen Netz des ... Router zwischen Internet und VPN Routet direkt die ... Auf dem Linux-Rechner kannst du dann mittels "Advanced Routing (so ... VPN-Pakete (die vom Linksys router kommen) zuverlaessig anhand des ...
    (de.comp.security.firewall)
  • Re: OE Outbox fails after SP2 wireless cable
    ... And, in short order, 'windows update' downloaded and installed SP2. ... with the Linksys gateway, and I also checked a box on a list somewhere to ... I'm only using the Linksys hardware firewall, ... the existing installation? ...
    (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
  • Re: Linksys router as Firewall
    ... >> The BEFSR41 router does that. ... >The Linksys does not isolate internal from external, ... >(unless you do MAC filtering or port filtering). ... >> Virus scanning and spam filtering is not a function of a firewall. ...
    (comp.security.firewalls)
  • Re: Zyxel router for Inspiron 1505?
    ... supercede the default firewall settings. ... names and include technical support (the others ... Someone suggested a Zyxel Extreme-MIMO X550 router. ... Linksys or D-Link. ...
    (alt.sys.pc-clone.dell)
  • Re: uplink newbie question
    ... And those that do, do not firewall ... If your laptop, connected to the Linksys, needs to access the ... >> LAN on the Netgear, it's creating outgoing traffic thru the Linksys, which is ...
    (microsoft.public.windowsxp.network_web)