Fragen zu verwendten Ports VR-NetWorld

Scorpion0815

Betreff:

Fragen zu verwendten Ports VR-NetWorld

· Gepostet: 13.02.2006 - 14:27 Uhr · #24294

Hallo,

ich habe hier mal eine Frage zu den Ports von VR-Networld.

Per Telefon von der Bank und auch hier im Forum nach Suche bekomme ich keine zufriedenstellenden Antworten bezüglich meines Problems:

Es heißt in allen Bereichen, bei einer Firewall müssten nur folgende Ports freigeschaltet werden:

TCP: 3000
TCP: 80
TCP: 443
TCP: 20
TCP: 21

So hier nun mein Problem:

Schalte ich nur diese Ports in der CISCO PIX frei, so kriege ich absolut keine Daten übermittelt.

Nach Einsatz eines Sniffers im LAN musste ich hier dann einen wechselnden Source-Port feststellen, der auf den Destination-Port 3000 bei hbci.gadeg.de ungelenkt wird.
Wäre dies nur ein Port könnte ich ja damit leben oder wenn mir jemand von euch hierzu eine Source-Port-Range mitteilen könnte.
Ich will und muss die Source-Ports bei mir im Unternehmen beschränken auf den einzelnen PC`s, was aber leider bei keiner bekannten Range ein bischen schwierig wird.

Vielleicht weiß ja hier einer genaueres zu.

Verwendete Version VR-Networld: 3.01
Betriebssystem: Windows XP Professional

Holger Fischer

Betreff:

Re: Fragen zu verwendten Ports VR-NetWorld

· Gepostet: 13.02.2006 - 15:33 Uhr · #24308

Hallo Scorpion,

die Portangaben sind richtig (Bei Verwendung des austerbenden InterCEPT/S würde noch 886 hinzukommen- die fällt beim RZ GAD aber weg)! Die Verbindung wird bei HBCI mit Diskette oder Chipkarte über Port 3000 hergestellt. Den Port 443 benötigst Du nur bei HBCI PIN/TAN.
Der FTP Port wird für das Update benötigt. Die Angabe mit dem Sniffer ist nicht relevant, da dies nichts mit der eigentlichen Kommunikation zu tun hat und mehr mit dem TCP/IP Protokoll zu tun hat.
Der Fehler dürfte in der verwendeten URL liegen.
hbci.gadeeg.de ist falsch. Die URL lautet hbci.gad.de.

Wenn Du nicht noch einen proxy einsetzt, sollte es damit funktionieren.

Scorpion0815

Betreff:

Re: Fragen zu verwendten Ports VR-NetWorld

· Gepostet: 13.02.2006 - 16:25 Uhr · #24315

Hallo Holger,

leider muss ich dir hier das gegenteil bestätigen.

Ich verwende keinen Proxy, nur die Firewall blockt den Verkehr und gib mir die Log-Auswertungen.

Die angegebene Adresse wird so zurückgegeben bei netstat auf der Workstation.

Erlaube ich der Workstation in der Firewall eine ausgehende Verbindung nur mit Port 3000, so bekomme ich keine Verbindung zum HBCI-Server und somit keine Daten über die Kontobewegungen.

Erst wenn ich alle Ports erlaube, lässt er hier eine Verbindung zu.

Problem an dieser ganzen Geschichte ist, das er auf der Workstation mit verschiedenen Ports arbeitet, die vom HBCI-Server auf Port 3000 (TCP) umgelenkt werden. Die Rückantwort erfolgt dann auf den Port des Clients auf meiner Seite.

Beispiel:

PCxx:1093 => HBCI:3000
HBCI:3000 => PCxx:1093

Da sich der Port des PC´s aber immer wieder ändert, kann ich hier so keine explizite Regel in der Firewall erstellen.

Einträge ala "ANY-Port" auf "HBCI:3000" will ich vermeiden. Um dies aber umsetzen zu können bräuchte ich dann für den PC eine Port-Range, und über die habe ich keine Angaben zur Verfügung.

Holger Fischer

Betreff:

Re: Fragen zu verwendten Ports VR-NetWorld

· Gepostet: 13.02.2006 - 16:50 Uhr · #24316

Hallo Scorpion,

da wir die gleiche Frage auch schon mal hatten, haben wir das damals mit der Entwicklung versucht zu klären. Hier mal ein Auszug daraus:

Zitat

Beim Einsatz eines Sniffers werden alle Kommunikationsvorgänge mitprotokoliert. Anwender eines Sniffers sollten jedoch auch mit den dort gelieferten Daten umgehen können. Hierzu ist weitergehendes Wissen des TCP/IP Stacks und des TCP-Handshakes notwendig.

Wir benötigen zum arbeiten mit VR-NetWorld die Möglichkeit
auf den Ports 3000 (HBCI), 443 (HBCI PIN/TAN ) sowie 21 (Online Update). Das Bedeutet jedoch nicht, dass wir diese Ports auch abhören. Die o.G. Ports müssen offen sein, damit unsere Software eine Kommunikationsverbindung zum entsprechenden Server herstellen kann. und wir Pakete auf diesem Port versenden können. Auf welchen Port der Server eine Antwort zurückschickt, wird durch den Server im TCP-Handshake festgelegt. Dies ist jedoch bereits innerhalb der TCP/UDP Sitzung gekapselt. Mit einem Sniffer kann man den Handshake beobachten.

z.B.:
Der Client sendet über Port 443 wie sich das für den Anruf eines SSL-Web-Servers gehört, denn der horcht schließlich (zumindest im Default-Fall) dort. Der Server seinerseits denkt nicht daran Port 443 zu nehmen - er sucht sich einen jenseits 1023 aus in diesem Fall z.B. 1303.
Bei der Portwahl ist er kaum eingeschränkt, es kann jeder freie Port zwischen 1024 und 65 535 sein. Informationen über den exakten Aufbau des TCP-Headers finden sich in RFC 793
(http://www.cis.ohio-state.edu/htbin/rfc/rfc793.html); dort ist TCP definiert.

Ports die ein Kunde bei seiner Firewall freigibt, sind i.A. Ports auf welche "von aussen" zugegriffen werden darf und welche dann an eine entsprechende Anwendung weitergeleitet werden können. Wir benötigen hier lediglich die Post, auf denen wir Daten empfangen wollen, also in unserem Fall 3000, 443, 21)

Ich bleibe also bei meiner Vermutung, dass die URL in der VRNWS falsch hinterlegt wurde. (u.a. auch, da ich hinter einem Linux Server arbeite und das ganze mit diesen Ports funktioniert)

Gruß

Holger

Scorpion0815

Betreff:

Re: Fragen zu verwendten Ports VR-NetWorld

· Gepostet: 14.02.2006 - 07:24 Uhr · #24342

Hallo Holger,

bei mir ist es definitiv so, das die Firewall die Kommunikation nicht durchlässt, wenn ich Ihr explizit sage, das Port 3000 "inside" nach Port 3000 "outside" zugelassen werden soll. Bis jetzt hat alles nur geklappt, wenn any Port "inside" nach Port 3000 "outside" zugelassen wurde.
Dank deiner Antwort aber kann ich jetzt die Regel ein bischen einschränken. ( siehe Zitat ).

PS: Ich hab hier nicht mit Linux in Bezug auf Internetsicherheit zu tun sondern mit CISCO :roll:

Firewall und vorgeschaltetem Paketfilter.

Zitat geschrieben von Holger Fischer

Bei der Portwahl ist er kaum eingeschränkt, es kann jeder freie Port zwischen 1024 und 65 535 sein.

Danke für die Hilfe.