2 Checkpoints & 1 Tunnel

Hallo Leute.

Ich poste das 'mal hier, da es eigentlich in kein anderes Subforum passt.

Folgende Situation:

Wir haben 2 Standorte, einen in Kiel und einen in der Schweiz (Selzach). Beide Sites sind jeweils durch eine Checkpoint-1 gesichert, und die Standorte sind über das I-Net, über einen VPN-Tunnel miteinander verbunden.

Die IP- Adressen sind im Klass-A (10.*.*.*) Bereich angesiedelt, gehen also zudem auch noch über NAT. Nun, man müsste jetzt normalerweise denken, dass alles in Ordnung ist, doch scheinbar sind auf der Kieler FW Regeln erstellt worden, die gewissen Verkehr aus unserem Bereich blocken. Das möchten wir aber nicht, da wir verschiede Probleme damit haben.

Aus meiner Erfahrung, und auch aus den MS MOC-Unterlagen, weiss ich aber, dass es völlig sinnlos ist, zwei Standorte, welche über VPN verbunden sind, innerhalb der Verbindung weiter durch FW regeln einzuschränken.

Da die Typen in Kiel entweder:

a) Völlig inkompetent sind

b) Einfach keine lust haben

c) Angst vor irgendwelchen (imaginären) Sicherheitslücken

d) Von Allem etwas

...haben, möchte ich gerne eine Dokumentation, oder Link, oder sonst was, welches meine Aussage untermauert, damit die Typen richtig informiert werden.

Am liebsten wäre mir etwas von Checkpoint, denn in Kiel scheinen sie mir nicht gerade die MS Kenner und Könner zu sein, was sich wohl im Vertrauen zum Produkt wiederspiegelt.

Kann mir da irgendwer helfen? Ein Bier an irgendeinem Treffen wäre da garantiert. ;)

Grüsse

Velius

es ist durchaus sinnvoll innerhalb von von oder standleitungs verbindungen eigene fw regeln zu verwenden. die meisten "einbrüche" kommen von innen, des weiteren ist es eine der wenigen möglichkeiten diverse würmer an der verbreitung zu hindern.

Ich würde mal sagen es kommt drauf an, wie die beiden Standorte zueinander stehen.

Sind es eine einzige Firma, dann halte ich FW Regeln für schwachsinnig. Da arbeitet man gegeneinander. Und wenn man FW Regeln einsetzt, sollten die beiden EDV Abteilungen dann aber Hand in Hand arbeiten, damit der tägliche Ablauf nicht gefährdet ist.

Also: FW Regel vorhanden - Grund angeben, wieso sie weg muss - FW Regel wegkonfigurieren.

Wenn Ihr aber Kunde von Kiel seid, oder Kiel Kunde von Euch, dann sieht das anders aus. Dann verstehe ich die Bedenken. Ich würde dann auch nicht einfach eine Regel öffnen, nur weil eine dahergelaufene Firma meint, es wäre bequem für sie.

Danke GerhardG, aber nicht wenn dabei das halbe AD nicht läuft!

Leider habe ich den von mir im Tipp & Links geposteten Beitrag, über AD & FW den zuständigen Herren geschickt, aber.....

Original geschrieben von Velius

 

Da die Typen in Kiel entweder:

 

a) Völlig inkompetent sind

b) Einfach keine lust haben

c) Angst vor irgendwelchen (imaginären) Sicherheitslücken

d) Von Allem etwas

 

 

...haben, .....

Ausserdem, die Leitung ist durch ein VPN gesichert, also ist von aussen schonmal Feierabend. Und tut mir leid, aber Würmer und der gleichen killt man im internen Netz (Standorte über VPN verbinden zähle ich mit dazu!) mit Antivirenlösungen, ok, aber nicht mir Portregeln auf einer FW, im internen Netz!

Gibt es auch Vorschläge die dafür wären, alles andere kann ich nicht gerbauchen, so gut die Hilfe auch gemeint ist.

Grüsse

Velius

@Wildi

Es ist eine Active Directory Domain (Subdomain im Forest), und auch eine Firma....leider werden die beiden Sites individuell administriert. Zum Glück konnte ich das Admin Passwort erhalten, sonst würde hier schon das Feuer toben!!

P.S.:

Original geschrieben von Wildi

Also: FW Regel vorhanden - Grund angeben, wieso sie weg muss - FW Regel wegkonfigurieren.

....habe ich auch schon versucht, bin da leider brutal auf Titan gestossen, und mein Schädel ist für gewöhnlich sehr hart. Ein Generalschlüssel(-Dokument) wäre die beste Lösung, wenn's sowas gibt.

Original geschrieben von Velius

Danke GerhardG, aber nicht wenn dabei das halbe AD nicht läuft!

Leider habe ich den von mir im Tipp & Links geposteten Beitrag, über AD & FW den zuständigen Herren geschickt, aber.....

wenn es probleme gibt, dann müssen für bestimmte hosts eben ausnahmen oder entsprechende regelungen erstellt werden.

Original geschrieben von Velius

Ausserdem, die Leitung ist durch ein VPN gesichert, also ist von aussen schonmal Feierabend. Und tut mir leid, aber Würmer und der gleichen killt man im internen Netz (Standorte über VPN verbinden zähle ich mit dazu!) mit Antivirenlösungen, ok, aber nicht mir Portregeln auf einer FW, im internen Netz?

wenn ich den normalen pc's den port 135 übers vpn dicht mache, hab ich einen guten schutz gegen weitere blaster würmer. was hilft mir ne antivirus lösung wenn diese relativ einfach deaktiviert werden kann? ich würde mich nicht darauf verlassen das die av hersteller immer rechtzeitig neue signaturen bereitstellen.

da ist eine kleine firewall regel ne kostenlose und sehr wirksame lösung.

Original geschrieben von Velius

Gibt es auch Vorschläge die dafür wären, alles andere kann ich nicht gerbauchen, so gut die Hilfe auch gemeint ist.

Grüsse

Velius

wenn euer ad nicht sauber funktioniert => gib den ball den kollegen weiter. entweder bauen diese eine saubere regel die den nötigen verkehr ermöglicht, oder sie löschen die internen regeln wieder.

wir haben mehr oder weniger die selben probleme wie du (nur mit relativ vielen standorten). wenn die kollegen von ihrer lösung überzeugt sind, finden sie auch eine entsprechende doku die ihren weg untermauert.

Dann mach ich mal ein Szenario wie ich mich verhalten würde ;)

MA: Ich bräuchte diese und jene Zugriffe in Kiel

Admin (Schweiz): Ich kümmer mich drum

Admin (Schweiz) ruft Admin (Kiel) an

Admin (Schweiz): FW Regel ändern!!!!

Admin (Kiel): Mach ich nicht. Weil...

... wenn das 'weil' begründet ist, dem MA sagen: Geht ncht weil so und so

... wenn das 'weil' unbegründet ist dem Chef mitteilen. (Antwort des Chefs abwarten und handeln oder nicht handeln)

So einfach. Ich würde mir da nicht das Leben schwer machen lassen.

Lass es, aber du argumentierst mit mir, ich möchte aber gerne Hilfe haben? Ist das zuviel verlangt?

Dein 1. Zitat:

Ist hier beschrieben, wie's geht

http://www.mcseboard.de/showthread.php?s=&threadid=40058

Aber die Kollegen raffen's nicht, Punkt.

2. Zitat:

Blaster kommt gar nicht erst in's Netz. Wenn die Firewall gegen dass I-Net richtig konfiguriert ist, und wenn ein Notebook den Virus einschleust, dann hast du eh schon 'ne Infektion (falls Signaturen und patsches nicht da sind).

3. Zitat:

Diese Aussage ist völlig für den Eimer, denn sie ist nicht produktiv.

Ausserdem, was willst du damit sagen, "nur mit relativ vielen standorten" und "wir haben mehr oder weniger die selben probleme". Wir gaben auch noch mehr Standoprte als die zwei, und und du hats null Ahnung davon, ob du wirklich die selben Probleme hast. Wahrst denn du schon mal hier? Ich war's jedenfalls nicht bei dir, deswegen lass ich auch solche überflüssigen Bemerkunen sein!

Original geschrieben von Velius

Ist hier beschrieben, wie's geht

http://www.mcseboard.de/showthread....;threadid=40058

 

Aber die Kollegen raffen's nicht, Punkt.

dann würde ich wie wildi schon gepostet hat einfach dem chef sagen das du so keinen sauberen ad betrieb garantieren kannst.

Original geschrieben von Velius

 

Blaster kommt gar nicht erst in's Netz. Wenn die Firewall gegen dass I-Net richtig konfiguriert ist, und wenn ein Notebook den Virus einschleust, dann hast du eh schon 'ne Infektion (falls Signaturen und patsches nicht da sind).

ein standort ist womöglich verseucht, aber eine weitere ausbreitung auf andere standorte wird (mit glück) durch die port regelungen verhindert.

Original geschrieben von Velius

 

Diese Aussage ist völlig für den Eimer, denn sie ist nicht produktiv.

Ausserdem, was willst du damit sagen, "nur mit relativ vielen standorten" und "wir haben mehr oder weniger die selben probleme". Wir gaben auch noch mehr Standoprte als die zwei, und und du hats null Ahnung davon, ob du wirklich die selben Probleme hast. Wahrst denn du schon mal hier? Ich war's jedenfalls nicht bei dir, deswegen lass ich auch solche überflüssigen Bemerkunen sein!

ich hab die selben überzeugungs probleme mit anderen kollegen/standorten, mehr wollte ich nicht sagen :rolleyes:

Ich muss mich an dieser Stelle bei dir auch ein wenig für den Ton entschuldigen, war vielleicht etwas vergriffen. :)

Aber trotzdem, der Port 135 wird von AD rein nur vom RPC (Endpoint Mapper!) benötigt, auch wenn du alle NetBIOS aktivitäten in der Domäne abschaltest.

Das kann nicht gehen, auch wenn man damit eine mögliche Virenverbreitung bekämpfen will!

....heute kam dann das Unerwartete. Die FW Regeln wurden scheinbar gelockert, aber was noch viel krasser ist, die drei Domänen Master-Rollen wurden auf einen der DC's an unserem Standort übertragen.

Der Infrastruktur Master war zwar nicht nötig, denn alle DC's im Forest sind GC's.....

Scheint so, als wär ich einigen Leuten gehörig auf den Nerven rumgetrampelt.

Wenn das bei einigen Boardmembers auch der Fall war, dann entschuldige ich mich hier nochmals dafür.

Original geschrieben von GerhardG

 

wenn ich den normalen PCs den Port 135 übers vpn dicht mache, hab ich einen guten schutz gegen weitere blaster würmer. was hilft mir ne antivirus lösung wenn diese relativ einfach deaktiviert werden kann? ich würde mich nicht darauf verlassen das die av hersteller immer rechtzeitig neue signaturen bereitstellen.

da ist eine kleine firewall regel ne kostenlose und sehr wirksame lösung.

 

Kleiner Nachtrag, für alle Diejenigen, die auch eine Checkpoint NG Apllication Intelligence am laufen haben:

 

Attack ID: CPAI-2003-11

Last Update: 07-December-2003

References: CAN-2003-0352 CAN-2003-0605 CAN-2003-0715 CA-2003-20 CA-2003-23

Attack Description:

There are several known and widely exploited vulnerabilities through the use of DCOM over MS-RPC. By default, FireWall-1 blocks DCOM over MS-RPC.

 

SmartDefense Protection:

This protection will allow specific MS-RPC interfaces, such as DCOM interface, if they are allowed in the rule base. You can use the DCE-RPC services to create them and apply the protections in this page.

 

SmartDefense unconditionally blocks the "Blaster" worm and its variants, while allowing legitimate DCOM traffic.

 

Die NG verhindert alleine, ohne den restlichen RPC verkehr zu behindern, die Verbreitung des Balster Viruses, ist also von daher auch kein Grund, zusätzliche Regeln zu implementieren.:)

Grüsse

Velius

Hi Velius,

bin durch. Ich kenne die Problematik der AD-Replikation durch eine FW, wir machen es selbst :D.

Das ist aber eher "politisch" angesiedelt. Mit den Dokus von MS funktioniert das wunderbar, nur musste man die erst einmal finden.

Gibt ja nicht gerne jeder zu, dass seine x.500 - Struktur für die Replikation die Ports 1-65535 benötigt :D, oder ?!

Gruß Data

Geb dir Recht, aber MS hat auch ein Dokument, wo wann man die RPC Ports fixieren lassen kann....

http://support.microsoft.com/default.aspx?scid=kb;de;224196

Ausserdem verwenden wir wie gesagt eine Checkpoint, und die hat bereits eine vordefinierte Regel-Gruppe, welche allen DCE-RPC spezifischen Verkehr zulässt, also alles was etwa so aussieht:

GUID

 

GUIDs identify objects such as interfaces, manager entry-point vectors (EPVs), and class objects. A GUID is a 128-bit value consisting of one group of 8 hexadecimal digits, followed by three groups of 4 hexadecimal digits each, followed by one group of 12 hexadecimal digits. The following example shows the groupings of hexadecimal digits in a GUID.

 

6B29FC40-CA47-1067-B31D-00DD010662DA

Na ja, entzwischen weiss ich einiges mehr über die NG-R55, von daher kann ich solche Sachen nun besser vermitteln.

Man sollte sich aber dennoch mit den Profukten, die man betreut auskenne, sonst muss man sich halt solche Sprüche

Gibt ja nicht gerne jeder zu, dass seine x.500 - Struktur für die Replikation die Ports 1-65535 benötigt , oder ?!

gefallen lassen. :p ;)

Gruss

Velius

Korrekt. :)

Wir nutzen Cisco, sieht also bei uns etwas anders aus. Wir nutzen die RPC-Port-Fixierung die Du gepostet hast. Macht am wenigsten Streß.

Naja, wollen mal sehen mit was MS in der Zukunft noch so aufwartet.

Gruß Data.