dateiübertragung über internet

  • Allgemein

Es gibt 14 Antworten in diesem Thema. Der letzte Beitrag () ist von Manawyrm.

    dateiübertragung über internet

    hi leute,

    ich möchte ein kleines spiel programmieren, bei dem 2 Spieler online zusammen durch ein 2D weltraum fliegen.
    als grundlage wollte ich erstmal einen chat programmieren bei dem der client nur zugriff hat wenn der host "online" ist.

    soweit meine ideen, aber:

    über winsocket gibt es einige probleme:
    1. ip addresse (hat sich jetzt geklärt)
    2. weiterleitung über ports also vom rooter zu meinem pc.

    aber das wichtigste: mein vater möchte nicht so gerne ports öffnen, weil das sicherheitslücken in unserem rooter/firewall bringt (weiß da nicht besonders viel drüber)
    ist das wirklich so? wenn ja ist das "gefährlich" oder interessiert das kein wenn da 1 port offen ist?

    gibt es noch andere möglichkeiten als winsockets?
    (nur kostenlose)
    ich habe eine homepage (also so eine richtige) kann man darüber daten senden oder bringt das garnichts?

    ich bitte um antworten entweder auf meine fragen oder, einfach mal ganz allgemein erklären wie man sowas verwirklichen kann
    und natürlich auch alle möglichkeiten die ihr kennt daten zu übertragen.
    also es ist für mich beides ok:
    1. wenn mein pc dafür laufen muss, also ich eine host-anwendung gestartet haben muss
    2. oder eben das ich i-wie im internet nen server habe
    (wie gesagt kenn mich damit nicht aus, also einfach nur mal erklären was geht und was nicht)

    vielen dank schonmal im vorraus

    mfg HeadShotHarp

    HeadShotHarp schrieb:

    hi leute,

    ich möchte ein kleines spiel programmieren, bei dem 2 Spieler online zusammen durch ein 2D weltraum fliegen.
    als grundlage wollte ich erstmal einen chat programmieren bei dem der client nur zugriff hat wenn der host "online" ist.
    dassis genau das Funktionsprinzip von VersuchsChat


    aber das wichtigste: mein vater möchte nicht so gerne ports öffnen, weil das sicherheitslücken in unserem rooter/firewall bringt (weiß da nicht besonders viel drüber)
    ist das wirklich so? wenn ja ist das "gefährlich" oder interessiert das kein wenn da 1 port offen ist?
    würde mich auch interessieren.
    Habe Wikipedia gelesen aber nicht wirklich verstanden, was eine Firewall eiglich macht. Wenn iein Port eine Sicherheitslücke darstellt, wieso stellen die Ports für Browser und Email (und weitere Dienste) dann keine dar?
    Man muss zwischen dem Öffnen von eingehenden Ports und ausgehenden Ports unterscheiden.
    Wenn der Client über Port 80 rausgeht, um im Internet zu surfen, dann sorgt die Firewall dafür, dass nur direkte Antworten auf diese Anfragen an den Client durchgelassen werden.

    Einen eingehenden Port zu öffnen, bedeutet, dass alles was von aussen auf diesen Port kommt ungefiltert an einen bestimmten Rechner weitergeleitet wird.
    Deshalb muss dieser Rechner sicherstellen, dass das Programm, das diesen Port bedient, auch sicher ist.
    Nehmen wir an, es ist ein Webserver, der den Port 80 bedient.
    Beliebige Programme von aussen können also auf diesen Webserver direkt zugreifen.
    Hat dieser Webserver Sicherheitslücken, dann können die von dem sich verbindenden Programm ausgenutzt werden.

    Üblicherweise werden deshalb in Firmennetzwerken Webserver nicht direkt in ein internes Netz platziert, sondern in eine DMZ (demilitarisierte Zone), die durch eine weitere Firewall vom internen Netz getrennt ist.
    Damit kann es potentiellen Angreifern maximal gelingen, den Webserver anzugreifen, sie können diesen aber nicht als Sprungbrett ins interne Netz verwenden.

    Die Sicherheit des offenen Ports hängt von dem Programm ab, das diesen Port bedient.
    Bei einem selbstgeschriebenen Programm hast du zumindest selbst in der Hand, was du mit Angriffsversuchen machst.
    Am besten ist, wenn der dazugehörige Prozess keinerlei Rechte hat, dass er selbst im gehackten Zustand aus seiner eigenen Umgebung nicht rauskommt.

    Die Gefahr eines Angriffs auf einen Userport ist begrenzt.
    Aber es ist eine mögliche Sicherheitslücke, abhängig vom Programm, das dahinter hängt.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „petaod“ ()

    Ein TCPListener öffnet also wohl einen eingehenden port, während der TcpClient nur einen ausgehenden öffnet.
    Für einen einfachen Chat kannich kaum ein Risiko erkennen - ein Angreifer könnte maximal rumspammen, aber das kann jeder Benutzer.
    Kritischer könnte sein, wenn du ein chat-protokoll implementierst, mit dem man auch Dateien übertragen kann, oder gar ein Remoting-Protokoll.
    Aber ein Mannschaftsspiel - da wird doch vmtl. nur der Spielzustand synchronisiert werden, also der einzige mögliche Dateizugriff ühaupt wird etwa auf eine Datenbank gehen, und das auch nicht direkt, sondern das Spielprogramm macht das in Reaktion auf Dateneingang.

    Kommt auf dein Kommunikations-Protokoll an - also wenn du Befehle bastelst wie: "Empfange diese Datei und starte sie..." ... ;)
    vielen dank für die vielen aufschlussreichen antworten.

    ich habe vor, nur koordinaten zu senden,
    und zwar die, des raumschiffes, damit es beim anderen spieler angezwigt werden kann.

    also würde dann keine gefahr bestehen wenn ich das richtig verstanden habe.


    ich werde dein tutorial mal durchgehen und sehen ob es dann funktioniert.
    ich konnte meinen vater schonmal überreden, dass wir das mit den ports auf jeden fall mal ausprobieren werden.

    vielen dank nochmal an alle
    mfg HeadShotHarp
    Ja, es kommt halt immer drauf an, welche Anwendung hinter dem Port sitzt.

    Dabei ist aber noch zu beachten, dass es einige Ports gibt, die man nicht freigeben sollte.

    Dazu zählen :
    21 - FTP (nur wenn da wirklich nen FTP ist!)
    22 - SSH (nur wenn da wirklich nen SSH ist! [Linux usw.])
    23 - Telnet (nur wenn da wirklich nen Telnetserver ist [sollte man heutzutage aber eh nicht mehr nutzen.])
    53 - DNS
    80 - (nur wenn da wirklich nen Webserver ist!)
    137 - SMB
    138 - SMB
    139 - SMB
    3389 - RDP (Nur wenn da nen RDP Server ist! )
    3306 - MySQL (bitte NIE freigeben!!)

    Die Fettgedruckten bitte KEINESFALLES freigeben. Diese stellen ein Sicherheitsrisiko dar.
    Am besten für eigene Programme Ports über 20000 nutzen.
    Da ist das Risiko mit nem anderen Programm zu kollidieren auch schon viel geringer.
    Die Ports sind 16-bit also von 0 bis 65535.

    Gruß,
    Manawyrm

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Manawyrm“ ()

    Ich würde das ja auch über TCP machen dazu brauchst du dann nichtmahl ein winsoc das geht auch locker ohne.
    TCP reicht locker für die coordinaten. Schwieriger wird es dann allerdings, wenn du nicht nur coordinaten hast, sondern z.B. die Welt
    mit übertragen musst, dann musst du auf UDP zurückgreifen, da dort die versendbaren Datenmengen grösser sind und du die Daten
    bei TCP sehr oft splitten müsstest :)

    MFG S.S.
    hi leute,

    also ich habs jetzt hinbekommen.
    hab einen port freigegeben und kann daten übertragen... alles super bis auf eins:

    unser rooter loggt sich immer gegen 1 nachts aus und dann 1 minute später wieder ein.
    also beim provider und wir bekommen dann immer ne neue ip-addresse...
    wie kann ich dass denn jetzt lösen?

    mfg HeadShotHarp

    PS: danke für die portinformationen, aber ich wusste dass man ca die ersten 5000 nicht benutzen soll... steht in meinem vb buch xD
    ja sowas habe ich gesucht,
    gibt es das auch in kostenlos?

    da steht noch mahr also ne domain bekommt man und so...
    hab ich ja alles von 1und1.de will ja nur ne feste ip.
    kann man auch i-wie machen, dass sich mein rooter nichtmehr ein-und ausloggt?

    mfg HeadShotHarp
    gibt es das auch in kostenlos?

    Ist kostenlos.

    also ne domain bekommt man und so...

    Ja. name.dyndns.org/de/info/at/bz oder sowas

    hab ich ja alles von 1und1.de will ja nur ne feste ip.

    CName?

    rooter nichtmehr ein-und ausloggt?

    Der Provider zwingt dich nach 24 Stunden einen Reconnect zu machen.