internes lan durch vpn's schützen

worel

Well-Known Member
Hi!

Möchte ein Lan (wieder mal paranoid) schützen, und zwar vor arp-spoofing, sniffing, replay attacken etc.

Die meiner Meinung nach Beste Methode ist, von jedem Client aus eine VPN zu einem Tunnelpunkt aufzubauen, welcher mich dann zentral weiterleitet.
So wie es mit Windows XP auch funktioniert (hab ich schon ausprobiert, klappt ganz gut - halt nur windows) Das klappt aber nur nach dem Client - Server Prinzip und ich brauch Windows dafür.

Ein Switch welcher mir alle VPN Verbindungen von den Clients entgegennimmt und dann halt als "normaler" Switch agiert wär dich die Lösung? (wenn jemand nicht verbunden ist, hat man halt keinen Zugriff)
Ich möcht nämlich nicht zig einzelne VPN Querverbindungen erstellen müssen, da muss es ja was besseres geben.

Bisher hab ich nur von Cisco so ein Teil gesehen, und da bin ich mir nicht sicher ob der wirklich das macht was ich glaube.
 
oder ssl, oder pptp (ok, das nicht)

ja klar, auch die windows client-server sache geht per ipsec. nur wenn du meine frage nochmal liest bin ich auf der Suche wie man die Infrastruktur als ganzes tunneln kann.

Sowas wie ein verschlüsselter Layer über meinem Layer2.
 
ok, das wusste ich nicht! wieder was gelernt ;)

hast du da links die du empfehlen kannst für mich?

Und weil ich grad so in stimmung bin noch ne frage:
wenn ich dem switch beibringen will, dass port Y nur mit Port X und/oder mit Port Z kommunizieren darf, muss es ein routingable Switch sein? (gegenansicht: ein port soll nicht mit allen anderen kommunzieren dürfen so wie es ihm gefällt. VLan ist eine Möglichkeit, aber ich möchte nochmal INNERHALB des VLAN's steuern können wer mit wem darf und wer nicht.)
Und dass ich hunderte VLANS mache... das geht sicher einfacher?!
 
@Manga
weil VLAN's nicht dem Zweck der Verkehrsbegrenzung von einem Interface zum anderen dienen. Mit VLAN's kann man Interfaces komplett voneinander trennen und dann ist von einem VLAN zu einem anderen keine Kommunikation mehr möglich, von Hilfsmitteln wie Router, etc. mal abgesehen.

mfg
ZbZ
 
Was ist denn deiner (eurer) Meinung nach noch sinnvoll. Wenn ich am Switch (siehe Catalyst (Spitzen Link)) den Traffic untereinander unterbinde und dann noch zusätzlich alles verschlüssele? Ein ziemlicher Aufwand.

Durch die Switch Sache hab ich eigentlich schon Arp Spoofing, Netzwerk Sniffing und Replay Attacken ausgeschalten?!

Da müsst schon jemand physikalisch das Patchkabel hinter dem Rechner anzapfen.

Das heißt also: "normalen" traffic so gut wie geht per ssl oä. verschlüsseln (imap, pop3, logindaten etc.) und die Lösung mit dem trennen der Ports (Mac und gegenseitiger Zugriff) am Switch. Der restliche Payload dümpelt Klartext drüber, aber wie schon gesagt, wenn nicht einer irgendwo ne Weiche des Kabels drin hat, ist diese Lösung doch ganz nett?!
 
Hallo worel,

ich bin immer noch der Meinung das ganze mit IPsec zu lösen.
Du musst dich dann nur mit einem Thema befassen und nicht mit mehreren (VLAN, Port-Security, Tunnel, ...).

mfg
ZbZ
 
Verkehrsbegrenzung von einem Interface zum anderen

Warum sollte man das machen?

Der Verkehr fliesst dann doch eh nur zwichen zwei vertrauenswürdigen Rechnern,
und wenn der andere Rechner nicht vertrauenswürdig ist, blockt man halt per Firewall alle ports die man für nötig hält.
Diese Verbindung noch zu verschlüsseln dürfte kaum was bringen, höchstens gegen man-in-the-middle Attacken, und selbst dann ist fraglich, ob diese nicht doch erfolgreich wären.
 
@Manga

ein Switch unterscheidet im Regelfall nicht zwischen vertrauenswürdig und nicht vertrauenswürdig. Es ist richtig das in einer ge-switchten Umgebung die Daten nur zwischen zwei Rechnern ausgetauscht werden (sollten *gg*) aber dies wird anhand der MAC-Adressen geregelt.

http://de.wikipedia.org/wiki/Switch_(Computertechnik)

Firewall und Switch sollte man in diesem Kontext nicht in einen Topf werfen.

mfg
ZbZ
 
naja, der schmarrn ist, dass ich das Netz in mindestens 6 zonen unterteilen muss. (=VLan) Port Security ist ja nicht großartig schwer zum implementieren. Ne Mac auf den Port binden und fertig.

Ist der IPSec Transportmodus nichtwieder "nur" von Host-zu-Host? (wie ich schon beschrieben hab bräuchten wir ja vielleicht Host-zu-mehrerenHosts und umgekehrt, bzw. vielleicht Host-zuallenHosts und umgekehrt) Naja, das letzte würd aber dem Modell der Protected Ports wiedersprechen...


Also persönlich gefällt mir das Modell mit den Protected Ports sehr gut! Damit wärs ja praktisch so, als ob ich der einzige Client im Netz wär (mit Anbindung an die Firewall und Server...) Also nix mit sniffing, spoofing und replay hehe
 
Zuletzt bearbeitet:
@worel

Transportmodus hat was mit der Transportschicht zu tun.
http://de.wikipedia.org/wiki/Osi-modell
Das soll einfach nur heißen das die Applikationsprotokolle während des Transportes geschützt sind.


Wer da mit wem und wie unter welchen Vorraussetzungen reden darf wird in den IPsec-Richtlinien festgelegt.

mfg
ZbZ
 
Durch die Switch Sache hab ich eigentlich schon Arp Spoofing, Netzwerk Sniffing und Replay Attacken ausgeschalten?!

Nein.
Arp Spoofing kann ich auch in einem geswitchten Netz machen.
Du musst nur die Arp Tables des switches ueberschreiben.
und ueber 255.255.255.255 neu verbreiten (mal etwas vereinfacht)

Gg
 
Ich meinte mit Switch Sache dem z.B.: Cisco Catalyst + Port Protection (und als Beilage Port Security) - wie eben oben schon angeschnitten.

Dass der Switch alleine leider keinen Schutz gegen Arp Spoofing darstellt, is klar. Oder meintest du etwas anderes? Bisher ist mir nur bekannt, dass ich den Arp Cache von Clients "vergiften" kann, aber ich weiß nix von Arp Poisoning direkt gegen den Switch.

Hab nen netten Artikel gefunden:
http://www.3mfuture.com/articles_arp/arp_spoofing_heise_security.2005.pdf

Fazit: es wird verdammt schwer, 100% lässt sich nie was vermeiden! ;)
 
Zuletzt bearbeitet:
So, folgende Lösung wird implementiert:

Jeder Client bekommt nen IPSec Client welcher sich bei Systemstart mit der Firewall verbindet (internes Interface). Die interessanten Server worauf zugegriffen wird stehen in der DMZ. Somit hab ich zwar keine Client zu Client Verbindung (drauf gesch...), aber eine sichere Client zu Server für jeden einzelnen.

Weiß eigentlich jemand wie dieses 802.1x funktioniert?
 
Hi,


Port Security ist schon mal ein Anfang:

Understanding How Port Security Works

You can use port security to block input to an Ethernet, Fast Ethernet, or Gigabit Ethernet port when the MAC address of the station attempting to access the port is different from any of the MAC addresses specified for that port. Alternatively, you can use port security to filter traffic destined to or received from a specific host based on the host MAC address.

Von Port Protection habe ich noch nie was gehört.

Was das 802.1x angeht, so benötigst Du noch einen Radius Server zur authentifizierung, und dann wird das Setup ziemlich umfangreich, denn sowas hat man dann ja auch redundant.

Was Deine Ipsec Lösung angeht, so halte ich das für ziemlichen Blödsinn. Du musst Dir erstmal klar werden was Du schützen willst.
IPsec ist auch nicht mal so eben implementiert. ( IPSEc ist übrigens auch L3 )

Auf Layer 2 kann es Dir immer passieren das jemand Deine cam table flooded, und dann die Packete als broadcast geschickt werden. Das ist ein beliebter Cisco exploit, allerdings habe ich das noch nicht gesehen. Kannst ja mal vormachen, die Anleitung kann ich Dir schicken.

Was hast Du denn für einen Switch ? Was für ne Software setzt Du ein ?
 
Hardware is noch nicht fix was genommen wird. Software ne Mixtur. (Win, Linux etc.)
Port Protection bei Cisco = Port Isolation bei HP (ähnlich Vlan, nur auf den Switch alleinig bezogen, nix mit Router; also welcher Port mit wem darf und mit wem nicht etc.)

802.1x vergess ich gleich wieder, ist mir zu stressig.
Port Security alleine kann halt auch trügerisch sein. Ist erst mal die richtige Mac gespooft und die Kiste angestöpselt, snifft es sich ganz ungeniert im internen Lan...
(deswegen Tunneling auf Layer3)

Bis jetzt bin ich noch immer nicht dahintergestiegen was die Möglichkeiten des Transportmodus bei IPSec sind (und wie man das implementiert)
 
Kurz gesagt:
Im Transportmodus wird nur die payload verschlüsselt, der IP Header bleibt erhalten.
Im Tunnelmodus wird das komplette Packet einpackt, ein neuer IP Header wird davorgeschrieben.... um genau zu sein ESP mit Trailer und ein neuer Ip Header.
Das ist der grundlegende Unterschied.
Damit kann man den Transport Modus mit den "originalen" IP Header einsetzen.

Mit Hardware/ Software meinte ich Deine Cisco Hardware.

Und Port Protection gibts bei Cisco immer noch nicht, jedenfalls nicht in diesem Terminus.


Ich bin ja echt mal gespannt was Du da implementierst.
 
Was ist mit Kerberos?
Ich kenne es zwar nicht gut, aber was ich davon gelesen habe,
sollte es diesen zweck erfüllen.

Aber ich bin nicht ein Fan von Cisco Hardware...


Gg
 
Zurück
Oben