IP und Ports Grundverständis

[Kraziator]

Hallo Leute,
ich wollte das mit den IPs und den Ports ein für alle mal richtig kapieren und mich nun extra hier angemeldet.
Hab nach ausführlicher Recherche für mich das ganze so vorgestellt: im Sendung mit der Maus-Stil

Spoiler

PC/Hochhaus hat
- IP-Adresse / Anschrift: 11.11.11.11
- hat 65535 Ports/Postfächer
- Port/Postfach 80 = Spezialfach für HTTP-Post, 21 für FTP-Post

Server/Firmengebäude hat
- IP-Adresse / Anschrift: 99.99.99.99
- hat 65535 Ports/Postfächer


PC-Programm/Bewohner im Hochhaus:
- lässt sich vom Betriebssystem/Hausverwalter Ports/Postfächer reservieren. z.B. Port/Postfach 50555
- bekommt OK, darf Port/Postfach nun öffnen, überprüfen, "belauschen"
- schreibt auf Fragebrief:
Absender: 11.11.11.11
Empfänger: 99.99.99.99, Port/Postfach 80
Rücksende-Port/Postfach 50555
- legt Fragebrief ins Postfach 80
- wartet/überprüft nun ständig Port/Postfach 50555 auf Eingang


Provider/Zustellfirma
- holt Fragebrief im Postfach 80 ab, bringt es zum Server/Firma, stellt Fragebrief ins Postfach 80 hinein


Server:
- schaut ständig im Postfach 80 nach, findet Fragebrief
- holt aus dem Lager die Homepage/Katalog und legt ihn ins Datenpaket
- schreibt auf Datenpaket:
Absender: 99.99.99.99
Empfänger: 11.11.11.11, Port/Postfach 50555
- legt Datenpaket ins Postfach 80


Provider/Zustellfirma
- holt Datenpaket im Postfach 80 ab, bringt es zum Hochhaus, stellt Paket ins Postfach 50555 hinein


PC-Programm/Bewohner im Hochhaus:
- findet neues Paket im Postfach 50555, kann sich Homepage/Katalog anschauen...
- schließt Port 50555 wieder

Nun meine ultimativen Fragen:
> ist der im Spoiler beschriebene Übertragungsweg korrekt?

> Können Ports gleichzeitig für das Versenden und Empfangen von Datenpaketen verwendet werden??

> Darf ein Programm seinen zugewiesenen Port nur zum Empfangen von Datenpaketen verwenden, oder auch zum Versenden?

> Nutzen alle Browser den Port 80 zum versenden?
Dürfen also soz. alle Bewohner ihre Anfragen ins Postfach 80 legen?
Warum darf es nur Postfach 80 sein und nicht... Port 40000 ?
Wenn mehrere Browser gleichzeitig laufen, schicken alle ihre Datenanfragen über Port 80 zum Server?
Warum kann der Browser z.B. eine Datenanfrage nicht über Port 40000 auf dem PC zum Server schicken?

> Nutzt ein Webserver den Port 80 sowohl zum horchen auf Anfragen, als auch zum Zurückversenden von Datenpaketen?

> Warum ist das Hochaus/PC/Server nicht unsicher, obwohl Port 80 ständig offen ist?

 

[Whiterose]

Können Ports gleichzeitig für das Versenden und Empfangen von Datenpaketen verwendet werden??

Ja dafür gibt es halt UDP/TCP

 

[conf_t]

Das mit dem Postfach ist etwas undeutlich. Ich ersetze das einfach mal durch ":"
Was beim einen die Nummer des Postausgangs ist, ist beim anderen immer die Nummer des Posteingangs.

Surfe ich (IP 1.1.1.1) einen HTTP-Server (IP 2.2.2.2) als User an heißt das

Anfrage: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Schicke mir deine Webseite
Antwort: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite, die du wolltest.

Im Datenpaket zum Server ist es so:
34567 ist der lokale Port des Clients der zufällig generiert wird. Nennt man im Fachjargon "Source-Port". Damit weiß der Server wohin (IP+Port). er die Antwort schicken muss.

Im Datenpaket zum mir vom Server
Ist der Port 80 der Ursprung und der Port 34567 der Zielport.


Die Kombination aus IPort nennt man Socket und genauer das wird von einem Programm "reserviert".

 

[PUNK2018]

1.) wenn wir davon ausgehen das sich es bei dem Hochhaus um einen PC handelt, ja, komplizierter wird es wenn das Hochhaus ein Router/Gateway ist und dahinter X Rechner sind...

2. + Teilweise 3.) du kannst mit Ports eig anstellen was du möchtest, ob Senden o. Empfangen o. beides, gehen tut alles ;-)

3.+4.) Es gibt für einige Dinge (Http) definierte Ports, schau dir mal "well-known" ports an: https://de.wikipedia.org/wiki/Liste_der_standardisierten_Ports
Ich denke das beantwortet dir die Frage sofort, so wie wir uns auf Rechtsverkehr geeinigt haben (zumindest in vielen Ländern) so hat man sich eben auch da geeinigt ;-)
Daher:
Für HTTP Anfragen nutzen alle browser Port 80 o. vllt noch 8080
Man hat sich auf Port 80 geinigt, daher geht i.d.r. kein anderer Port (zumindest Serverseitig), der Server hört nicht auf Port 40000

5.) Zurücksenden kann über beliebige Ports passieren, hauptsache das Paket kommt beim richtigen Port an, i.d.r. also Port 80 des Zielsystems

6.) Weil wir u.U. nicht alles über Port 80 übertragen können, wir haben uns ja auf die Sprache bzw. das Protkoll geinigt, nämlich HTTP, wenn nun eine FTP anfrage über Port 80 kommt, dann läuft diese ins leere und wird imho ignoriert.

 

[Kraziator]

Ja dafür gibt es halt UDP/TCP

ja aber wenn z.B. Firefox den Port 50555 vom OS bekommt und dort nun auf Antwortpakete lauscht, warum nutzt er diesen nicht gleich zum Versenden von Anfragen? warum muss er Port 80 nutzen?

Das mit dem Postfach ist etwas undeutlich. Du solltest in dem Ablauf zwischen "Posteingang" und "Postausgang" unterscheiden.

genau das ist meine Frage: hat ein Port eine Eingangstür und Ausgangstür.
Können also dadurch Pakete soz. rein oder auch raus....?

 

[Merle]

"Dafür" gibt es kein UDP lol. Die Webserver laufen auf Port 80 und die Browser übersetzen HTTP://www.google.de zu google.de:80 und der DNS Server macht daraus (IP fiktiv) 99.99.99.99:80. Da fragt dein Browser an. Die Anfrage geht vom ersten freien, unpriviligierten Port deiner IP aus, also z.B. 88.88.88.88:1025(-65000irgendwas). Der Webserver kennt deinen Port und richtet seine Antworten dort hin. Der Webserver kann natürlich vielen Usern, die auf Port 80 ankommen, Daten liefern, sperrt aber meist den Port für diese Anwendung. Ich wüsste von keiner Doppelbelegung von Ports. Bei Routern kann man auch nicht 2 Mal den selben öffnen. Obiges Beispiel aus #2 mal ausgeschlossen, kP ob das geht.

 

[Whiterose]

Da es standardisierten Ports sind

 

[Kraziator]

Surfe ich (IP 1.1.1.1) einen HTTP-Server (IP 2.2.2.2) als User an heißt das

Anfrage: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Schicke mir deine Webseite
Antwort: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite, die du wolltest.

ah super Erklärung, jetzt hab ich das schon besser verstanden.
Eine Anwendung reserviert sich also immer ein Socket = IPort

D.h. wenn ich 2.2.2.2:80 in den Browser eintippe, geht diese Anfrage "ausgehend" auch durch den Port 80 meines eigenen PC zum Port 80 des Servers.?
Sprich: Zielport des Servers definiert gleichzeitig den zu nutzenden Ausgangsport?

Wenn ich 2.2.2.2:50000 eintippe, geht die Anfrage durch den Port 50000 des PCs und der Port 50000 vom Server wird angesprochen, aber niemand antwortet weil keiner dort auf Anfragen wartet?

Ist es denn möglich, dass ein Programm eine Anfrage über seinen eigenen Port, z.B. 40000 um den Server 2.2.2.2:80 zu kontaktieren?

komplizierter wird es wenn das Hochhaus ein Router/Gateway ist und dahinter X Rechner sind...

ich hab das jetzt so verstanden:
wenn jetzt mehrere Clients im LAN hinter einem Router hängen:
kann es sein, dass wenn mehrere surfen, die Browser zufällig den selben "Empfangsport" (= Sourceport??) wählen.
Der Router merkt sich dann einfach welcher Client mit welcher IP welchen Port gewählt hat und vergibt einen neuen Port.
Beim Server kommt dann der neugewählte Port durch den Router an. Zurückkommende Pakete ordnet der Router wieder dem ürsprünglichen Socket (?) wieder zu
Das ganze nennt man NAT? ist das jetzt richtig verstanden worden von mir?

5.) Zurücksenden kann über beliebige Ports passieren, hauptsache das Paket kommt beim richtigen Port an, i.d.r. also Port 80 des Zielsystems

das verstehe ich jetzt aber wieder nicht.
Der Server schickt Daten doch immer zurück zum Source-Port, der zuvor vom Programm reserviert wurde, wo das Programm dort auch auf Pakete wartet.
Warum sollte der Server die Pakete zum Port 80 des Zielsysstems schicken?

Dadurch stellt sich auch die Frage:
Welches Programm lauscht auf meinem PC eigentlich am Port 80?
wenn garkeins, warum kann dieser nicht als Source-Port dienen? obwohl Ports doch Senden und Empfangen können?

Warum sucht sich also z.B. Firefox einen Source-Port bei 50xxx aus und nutzt nicht den Port 80 zum "empfangen"

Die Anfrage geht vom ersten freien, unpriviligierten Port deiner IP aus, also z.B. 88.88.88.88:1025(-65000irgendwas). Der Webserver kennt deinen Port und richtet seine Antworten dort hin.

kannst du mir das genauer erklären?:

ich (IP 1.1.1.1) , HTTP-Server (IP 2.2.2.2)
Anfrage: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Schicke mir deine Webseite
durch welchen Port auf meinem PC geht diese Anfrage? durch Port 80 oder Port 34567?

 

[thebackfisch]

Bringt bitte Ports und IP-Adressen nicht durcheinander. Die Portangabe hat absolut nichts mit der IP-Adresse zu tun, schaue dir einmal das OSI-Modell an:
https://de.wikipedia.org/wiki/OSI-Modell
IP-Adressen sind auf Schicht 3 implementiert, Ports sind etwas von TCP/UDP (Schicht 4). Einem Router ist es normalerweise völlig egal, was für Ports im Spiel sind, er wertet nur den IP-Header aus, lässt also alles darüber unangetestet. NAT ist da eine Ausnahme, er mapt so zu sagen einen Port auf eine IP-Adresse, aber das ist aus Sicht des OSI-Modells ganz böses Zeug

Ein Datenpaket kommt auch immer an, wenn es nur eine IP-Adresse hat. Die Portangabe sagt dem Betriebssystem nur, welchem Dienst es dem Paket zuordnen soll. Mal zur Vernschaulichung: Ein ping-Befehl kommt völlig ohne Port aus, da ICMP (das Protokoll, das hinter dem ping-Befehl steckt) auf Schicht 3 implementiert ist und dort endet. Folgich gibt es keine höheren Schichten und somit auch keine Prots.

Ein Webserver setzt eben auf TCP als Schicht 4 und hat damit auch Ports. So können z.B. zwei Webserver auf demselben System laufen. Manche Ports sind für bestimmte Anwendungen reserviert, sie müssen also nicht expliziet angegeben werden. Dass man Ports in der Adresszeile des Webbrowsers mit Doppelpunkt an die Adresse dranhängt, wurde halt mal so definiert, hat aber eben nichts mit der IP-Adresse zu tun. mit SSH funktioniert diese Schreibweise z.B. nicht.

 

[conf_t]

Deine Vorstellung, dass eine Paket durch einen Port raus geht ist schlicht nicht richtig.
Was Zielsystem ist, kommt immer auf den Standpunkt an. Vom Server aus ist das Zielsystem der Client und vom Client aus gesehen der Server. Daher muss man immer schauen, von wo nach wo das eine Paket läuft.

Wenn wir bei dem Beispiel bleiben:
Anfrage: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Schicke mir deine Webseite
Antwort: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite, die du wolltest.

Heißt das, dass die Anfrage einfach so, ohne "durch einen Port" raus geht. Heißt zwar "Port" hat aber nur bedingt was mit einer Tür zu tun.
Es ist eher so, dass die Source-IP der Absender ist und der Port das Aktenzeichen oder so was.

Also wenn ein Datenpaket den PC verlässt, bekommt es quasi vom Betriebssystem einen Stempel aufgedrückt mit Absender und Aktenzeichen - fertig. Es geht nicht durch irgendwas durch.

Dienste auf Server haben einen definierten Port, um sie anzusprechen, damit man auch definitiv den richtigen Dienst erwischt. Es gibt empfohlene Einstellungen (Well Known Ports), aber man kann auch einen Webserver "sagen", dass er auf Port 8888 Anfragen erwarten soll statt auf 80. Also im Regelfall lautet das Aktenzeichen für öffentliche Webserver "80".

Wenn du zeitgleich zwei verschiedene Webserver anfragst sähe es so z.B. aus:

Anfrage: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Schicke mir deine Webseite
Anfrage: IP 1.1.1.1:54321 an IP 1.2.3.4:80 -> Schicke mir deine Webseite
Antwort: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite_Teil1, die du wolltest.
Antwort: IP 1.2.3.4:80 an IP 1.1.1.1:54321 -> Hier die Webseite, die du wolltest.

Welche Ports vom Client genutzt werden (hier 1.1.1.1) wählt das Betriebssystem aus. Am Ende ist immer wichtig, dass die Kombination aus Quell-IP+Port und Ziel-IP+Port zusammen eindeutig, und zu dem Zeitpunkt einmalig ist, das nennt man Session. (PAT und NAT lassen wir mal außen vor).

Diese Zuordnung ist sehr wichtig, weil ein Datenpaket maximal üblicherweise 1500 bytes Nutzdaten enthält. Um z.B. eine kleine Webseite, mit 15kbytes zu übertragen, bräuchte man rund 10 Pakete (habe mal den binären Umrechnungsfaktor ausgelassen und bin Dezimal geblieben, macht für das Verständnis keinen Unterschied).

Dasheißt es gehen 10 Pakete nach der Anfrage vom Client an den Server zurück zum Client. Bei TCP sähe das vereinfacht so aus (und TCP ist bei HTTP Standard):

Client: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Hallo, machen wir eine Session auf den Ports 34567 und 80?
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> können wir tun
Client: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Super, dann lege ich mal los
Client: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Ich will HTTP mir dir sprechen, ok?
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Na klar ist das ok.
Client: IP 1.1.1.1:34567 an IP 2.2.2.2:80 -> Schicke mir deine Webseite
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite_Teil1, die du wolltest.
Client: IP 1.1.1.1:54321 an IP 1.2.3.4:80 -> Habe Webseite_Teil1 erhalten
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite_Teil2, die du wolltest.
Client: IP 1.1.1.1:54321 an IP 1.2.3.4:80 -> Habe Webseite_Teil2 erhalten
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite_Teil3, die du wolltest.
.....
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite_Teil9, die du wolltest.
Client: IP 1.1.1.1:54321 an IP 1.2.3.4:80 -> Habe Webseite_Teil9 erhalten
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Hier die Webseite_Teil10, die du wolltest.
Client: IP 1.1.1.1:54321 an IP 1.2.3.4:80 -> Habe Webseite_Teil10 erhalten
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Ok, dann sind wir fertig
Client: IP 1.1.1.1:54321 an IP 1.2.3.4:80 -> Ja, dann sind wir fertig, tschüss
Server: IP 2.2.2.2:80 an IP 1.1.1.1:34567 -> Ok

Danach wird die Zuordnung des POrts am Client 34567 wieder aufgehoben. Und könnte für eine neue Session zu einem anderen Server benutzt werden, oder auch nicht.

So jetzt muss man sich vorstellen, dass ein Webserver tausende solcher Sessions gleichzeitig bedient, da werden eben die Source-ports der Clients und deren IP einfach benötigt, um die Eindeutigkeit herzustellen.

 

[Kraziator]

Bringt bitte Ports und IP-Adressen nicht durcheinander.

hier muss ich aber nachfragen, an welcher Stelle genau, ich die beiden durcheinander gebracht habe?
magst du mir die Stelle zeigen? nur für mein eigenes Verständnis.

Mit Hilfe der IP kann Computer A mit Computer B im Netzwerk kommunizieren / Daten austauschen.
Auf den beiden Computern laufe aber viele Programme, Dienste etc.
ComputerA/DienstX will mit ComputerB/DienstY kommunizieren. Damit Datenpakete vom Absender zum richtigen Empfänger ankommt, muss noch der Port angegeben werden. Er ist quasi ein Kommunikationskanal.

Ich bitte um Nachsicht, dass ich kein Fachmensch bin und bei Erklärungen bitte nicht zuviel mit Fachjargons um sich geworfen wird.
Ich bin zwar wie ich finde recht computerversiert, aber der Wiki-Artikel zum OSI-Modell ist für mich leider reinstes Fachkauderwelsch.
Ich wünschte ich könnte ihn ohne Hilfe verstehen, aber hätte ich ihn verstanden, hätte ich den Thread hier vermutlich garnicht gestellt.

...

erstmal vielen vielen Dank für deine Mühe, mir alles so ausführlich zu erklären

...dass die Anfrage einfach so, ohne "durch einen Port" raus geht.

bedeutet das dann auch, dass Ports nur dazu da sind, damit Dienste dort ihre (für sie bestimmten) Datenpakete abholen können.
Um quasi eine Verwechslung bei der "Lieferung" der Daten auszuschließen?

Wenn Anfragen "einfach so" rausgehen, dann werden Ports für ausgehende Verbindungen/Anfragen also garnicht gebraucht.
Dementsprechend haben Ports also garkeinen "Ausgang" sondern nur einen "Eingang"?
Wären also nur zum "Empfangen" da?

Meine Firewall-Software fragt mich, wenn ein Programm ins Internet gehen will.
Ich dachte bisher immer, dass die Firewall einfach alle Ports auf dem Rechner auf "ausgehende" Verbindungen überwacht.
Sobald ein Programm Datenpakete über den Port "schleusen" will, würde mir die Firewall dies melden...
So scheint es aber nicht zu sein.

Wenn Anfragen aber nun "einfach so" rausgehen, wie merkt die Firewall das dann?

 

[thebackfisch]

Also ich finde den Wikipedia-Artikel recht verständlich

Im Grunde ist es doch ganz einfach: Ports sind Adressen des TCP-Protopkolls auf Schicht 4, genau so wie die IP eine Adresse des IP-Protokolls auch Schicht 3 ist und MAC-Adressen Adressen des Ethernet-Protokolls auf Schicht 2. Ports dienen also dazu einen TCP-Dienst auf dem System zu identifizieren. Es gibt immer Empfänger- und Ziel-Port.

 

[conf_t]

Also bei dir dreht man sich im Kreis und ich habe echt das Gefühl du willst es nicht verstehen und hälst an deiner Vorstellung fest. Geh zu jemanden, der es dir das persönlich erklären kann. Über ein Forum taugt es scheinbar nicht. Ich geb's auf.

 

[Kraziator]

Also bei dir dreht man sich im Kreis und ich habe echt das Gefühl du willst es nicht verstehen und hälst an deiner Vorstellung fest. Geh zu jemanden, der es dir das persönlich erklären kann. Über ein Forum taugt es scheinbar nicht. Ich geb's auf.

ok, ich habe mir deine Antworten jetzt immer wieder mehrmals durch gelesen und mich vom Gedanken verabschiedet, Ports seien Andockstellen / Türen / Tore.
Ich hatte vorher bei Google eine Seite gefunden, auf der Ports mit Andockstellen am Hafen verglichen wurde, wo Waren ab- und aufgeladen werden. Daher die falsche Vorstellung.
Ich bitte um Verzeihung

Ports sind also nichts weiter als Zahlen/ "Aktenzeichen" die im Header eines Datenpakets vermerkt sind.
OK. Verstanden.

Also wenn ein Datenpaket den PC verlässt, bekommt es quasi vom Betriebssystem einen Stempel aufgedrückt mit Absender und Aktenzeichen - fertig. Es geht nicht durch irgendwas durch.

OK. Das ist auch endlich verstanden und auch logisch.
Jetzt wird mir einiges viel klarer

Auf dem Server muss also Port 80 geöffnet sein, klar, damit er Anfragepakete mit Portangabe "80" erkennt.
Da ich keinen Webserver betreibe, mein PC ergo kein Webserver ist, muss bei mir z.B. Port 80 auch garnicht offen sein...
Somit ist die Behauptung die man überall im Netz so liest, Port 80 müsse offen sein, damit man surfen kann: schlichtweg Unsinn..?

Und somit wären Begriffe wie "Port öffnen, schließen, sperren" eigentlich falsch.
Da ein Port garnicht existiert, sondern nichts weiter als eine Zahl ist, kann er auch garnicht geschlossen oder geöffnet werden.

Port öffnen hieße lediglich, dass Datenpakete mit übereinstimmender Portangabe im Header nicht ignoriert, sondern weitergeleitet werden zum Dienst, der sich zuvor diesen Port / Aktenzeichen beantragt hat?
Datenpakete mit Portangaben die unbekannt, ergo geschlossen sind, werden einfach "weggeschmissen"...?

Auch Aussagen wie "Paket kommt beim richtigen Port an" müsste auch falsch sein.
Datenpakete müssen / werden nicht zum richtigen Port gebracht, weil garkein Port existiert.
Es muss heißen: Pakete müssen zum richtigen Dienst/Programm geleitet werden, das den auf dem Paket vermerkten Port zugewiesen bekommen hat.

Habe ich jetzt alles richtig verstanden?

Falls ja, bedanke ich mich wirklich herzlich bei dir für deine Geduld
Danke schön

 

[conf_t]

Auf dem Server muss also Port 80 geöffnet sein, klar, damit er Anfragepakete mit Portangabe "80" erkennt.
Da ich keinen Webserver betreibe, mein PC ergo kein Webserver ist, muss bei mir z.B. Port 80 auch garnicht offen sein...
Somit ist die Behauptung die man überall im Netz so liest, Port 80 müsse offen sein, damit man surfen kann: schlichtweg Unsinn..?

Nein, du mischst schon wieder alle. Das Paket beinhaltet natürlich auch eine Empfänger IP und den Port, der dort erreicht werden soll.
Der heimische Router lässt das zu. Aber jeder Bestandteil des Paketsheaders kann durch eine Firewall ausgelesen und blockiert werden. Denn man kann da sagen, die Quell-IP darf garnicht das lokale Subnetz verlassen, oder der Port80 darf in keinem Paket als Zielport angegeben sein.

Aber um das zu verstehen musst du den TCP-3-Way-Handshake kapieren, das habe ich oben kurz angedeutet. Weil "ausgehend"/"eingehend" bei Firewalls nicht auf das einzelne Paket sich bezieht, sondern darauf wer das erste Paket im 3-Way-Handshake gesendet hat. Ein TCP-Header hat Platz für mehrere Angaben wie IP des Senders, Empfängers, Sendeport und Port beim Empfänger uvm. Das wertet eine Firewall aus.
Fragt der Client den Server an, initiert er den 3-Way-Handshake. Im lokalen Netz ist die Kommunikation daher ausgehend und die ist i.d.R. unbeschränkt. Würde auf dem Client ein Webserver laufen und ein anderer PC würde den dortigen Webserver anfragen, wäre die Verbindung aus dem zuerst genannten Clients, der jetzt einen Webserver hat, eingehend. Eingehende Verbindungen aus dem Internet werden durch die Routerfirewall erst mal geblockt, da für den normalen Enduser nicht nötig ist, eingehende Verbindungen zuzulassen, da 99,9% der Anwendungsfälle für den normalen Verbraucher ausgehend sind. Wenn du einen Webserver zu Hause betreibst, dann musst du den Port 80 "öffnen"/"freigeben". Bei Unternehmensnetzen, ist das auch oft anders. Da werden auch ausgehend viele Ports gesperrt, damit die Mitarbeiter oder Trojaner nicht ungewollte Kommunikationen beginnnen oder Programme ausführen. So kann man z.B. effizient Bittorrent unterbinden oder früher ed2k-Sharing. Halt alles Sachen, die ein hohe Risiko für ein Unternehmen bedeuten.

Und somit wären Begriffe wie "Port öffnen, schließen, sperren" eigentlich falsch.
Da ein Port garnicht existiert, sondern nichts weiter als eine Zahl ist, kann er auch garnicht geschlossen oder geöffnet werden.

Auf der einen Seite ja, auf der anderen Seite nein. Ein "geschlossener" Port ist wie du jetzt schreibst auch nicht wirklick geschlossen, ein Paket auf einen unbenutzten Port landet einfach im Datennirvana und wird verworfen. Man kann eben Firewalls sagen: "Hey, wenn du ein Paket mit de Zielport 80 eingehend siehst, werf es doch bitte weg". Da Machen alle Heimrouter so, per Standardeinstellung. Diese Regel kann man auch erweitern, bei besserem Firewalls und mehrer Eigenschaften eines Paketes kombinieren.

Port öffnen hieße lediglich, dass Datenpakete mit übereinstimmender Portangabe im Header nicht ignoriert, sondern weitergeleitet werden zum Dienst, der sich zuvor diesen Port / Aktenzeichen beantragt hat?
Datenpakete mit Portangaben die unbekannt, ergo geschlossen sind, werden einfach "weggeschmissen"...?

Jo

Auch Aussagen wie "Paket kommt beim richtigen Port an" müsste auch falsch sein.

Das hat sich halt so in der Sprache eingebürgert

Datenpakete müssen / werden nicht zum richtigen Port gebracht, weil garkein Port existiert.

Problematisch formuliert.

Es muss heißen: Pakete müssen zum richtigen Dienst/Programm geleitet werden, das den auf dem Paket vermerkten Port zugewiesen bekommen hat.

Ja, liest sich erst mal ganz gut.

 

[Kraziator]

Hallo Nicht ich
also ich habe in den letzten zwei Tagen durch das Durchlesen deiner Beiträge mehr über IP/Ports gelernt als die letzten 10 Jahre
Vielen Dank dafür. Ich freue mich total.
Jetzt machen meine ganzen Einstellungen am Router auf einmal total Sinn und ich verstehe sogar was ich eingestellt hatte

Nichtsdestotrotz bleiben noch ein paar Restfragen übrig. Magst du mir das noch erklären?

Ich unterscheide jetzt auch endlich zwischen Serverport und Clientport.
> Serverport: immer für ALLE Anfragen offen, nimmt unangeforderte Datenpakete an
> Clientport: nur für den Server geöffnet, der zuvor kontaktiert wurde, nimmt nur zuvor angeforderte Antwort-Datenpakete des Servers an.
Quelle: https://wiki.ubuntuusers.de/Offene_Ports

Aber wann ist ein Port ein "Serverport", wann ein "Clientport" ?
Ein Browser beantragt beim OS für sich ein Clientport, auf dem es Pakete vom zuvor kontaktierten Server erhält. OK.
Aber ein HTTP-Dienst (oder sogar ein Schadprogramm z.B.) "benötigt" doch einen Serverport, an dem es "unangefordert" Pakete geschickt bekommt?
Übernimmt vielleicht das OS die Aufgabe zu erkennen, ob ein Traffic/Datenpaket vorher angefordert oder unangefordert ankommt?

Desweiteren habe ich mir einige Erklärungen aus dem Internet zusammengesucht und kommentiert.
Kannst du die Stellen nachkommentieren, die falsch bzw. von mir falsch verstanden wurden?

Spoiler

Ein Port ist offen, wenn ein Programm an einem Port nach Paketen lauscht, die an ihn geschickt wurden, ohne dass das Programm diese Pakete vorher angefordert hat.

Quelle: http://archive.kanotix.com/index.php?module=pnWikka&tag=PortListe
Was ist mit den (Client-)Ports, die mein Browser geöffnet hat für den Empfang der Serverdaten?
Gelten diese auch als offen?

Wie der Darstellung zu entnehmen ist, nutzen Internetbrowser, zum Beispiel der Internet Explorer, bei seiner Arbeit den Port 80.
E-Mail-Programme, darunter Outlook Express, verwenden zwei Ports: für das Versenden von Post den Port 25, für den Empfang Port 110.

Ich bin der Meinung, dass hier Serverport und Clientport durcheinandergebracht wurde.
Ein Browser "verwendet" nicht den Port 80, Mailprogramme "verwenden" auch nicht die Port 110 bzw. 25.
Der Browser schickt Datenpakete zum Server mit dem "Vermerk", dass sie zum Port 80 des Servers geliefert werden soll.
Ein Mailprogramm schickt Datenpakete zum Mailserver mit dem Vermerk, dass sie zum Port 110 bzw. 25 des Mailservers geliefert werden soll.
Port 80, 110, 25 sind also die Serverports und vom Serverbetreiber so eingestellt sind, weil es allgemein so standardisiert ist.
Wenn der Betreiber lustig ist, kann er auch andere Ports einstellen, so dass nur Leute, die diesen Port kennen die Server kontaktieren können...
Somit haben diese "offenen Ports" erstmal garnichts mit dem eigenen Rechner zu tun.
"Verwenden", tun die Browser / Mailprogramme nur ihre Clientports.

Wenn Sie das Filesharingprogramm eMule aufgespielt haben, öffnet es die für seine Arbeit erforderlichen Ports 4662 und 4672.

Das sind wiederum CLIENT-Ports. Diese werden auf dem eigenen Rechner geöffnet.
Sie nehmen aber auch NUR Datenpakete von dem Server an, die das Filesharingprogramm zuvor vom selbigen angefordert hat an.

Wenn Ihr Computer nicht geschützt ist, so kann jedes auf Ihrem Computer installierte Programm den entsprechenden Port öffnen.

Stimmt. Jedes Programm kann beim OS sich einen Port reservieren lassen und erhält dann Pakete, die für diesen Port bestimmt sind.
Aber auch nur Pakete von dem Server, den der Dienst/Das Programm zuvor kontaktiert hat.

Ebenso kann jedes Programm von außen an jeden Port Ihres Computers angeschlossen werden.

Wie soll das denn gehen?

So kann Ihnen durch eine der vielen Möglichkeiten ein Trojanisches Pferd untergeschoben werden (Beispiel: I-Worm.MyDoom),
das auf Ihrem Computer einen Port öffnet (Beispiel: 3127),
über den unbemerkt Ihre gesamten wichtigen Informationen herausgezogen werden können.

Ich kann mir so ein Pferd doch nur über Mailanhänge, USB-Stick, Ausführen einer "*Pferd*.exe" auf mein System holen.
Erst dann kann das Pferd den Port auf meinem Rechner öffnen.
Diesen Port braucht es aber doch eigentlich garnicht um irgendwelche Daten zu "senden".
Das kann es doch auch so....?
Der geöffnete Port wäre doch nur dazu da, um Daten von seinem "Herrn" zubekommen, bzw. sich selbst zu updaten oder?

Über die Firewall sind normalerweise nur die Ports, also Pforten geöffnet, die auch tatsächlich benötigt werden.
Habe ich keine Firewall, so sind auch unbenutzte Ports geöffnet, über die sich der Virus Zugang verschafft.

Was ist denn damit gemeint?
Das widerspricht komplett mein Verständnis.
Wie soll sich bitte ein Virus über ein Port Zugang verschafft? wie soll das gehen?
Quelle: http://www.aboutip.de/stat/ports.php

 

[conf_t]

Aber wann ist ein Port ein "Serverport", wann ein "Clientport" ?

Grundsätzlich kann jeder Port ein Server- oder Clientport sein. Man hat halt mal die ersten 100 Port fest definiert, dass die für Server verwendet werden, ist aber eine reine Definitionssache und man kann auch davon abweichen.

Bei z.B. dem am häufigsten verwendeten Transportprotokoll TCP hat du am Anfang den bereits erwähnten 3-Way-Handshake. Der lokale Port des Initiators ist immer der Clientport, egal welche Nummer er hat und der Zielport im ersten Paket des Handshakes ist immer der Serverport, ebenfalls egal, welche Nummer er hat.

Übernimmt vielleicht das OS die Aufgabe zu erkennen, ob ein Traffic/Datenpaket vorher angefordert oder unangefordert ankommt?

Ja das ist erstmal Aufgabe des Betriebssystems. Man kann diese Aufgabe in Firewalls auslagern (siehe vorherige Posts).

Was ist mit den (Client-)Ports, die mein Browser geöffnet hat für den Empfang der Serverdaten?
Gelten diese auch als offen?

Technisch ist er dann offen. Nimmt aber nur Pakete von einer bestimmten IP+Portkombination, ein Spoofing ist theoretisch möglich, wird aber durch Sicherheistmechanismen im Browser versucht zu unterbinden. Da das Betriebssystem unter diesem Port auf nichts anderes als auf die IP+Portkombination antwortet, sehen Portscanner keinen Offenen Port, da keine Reaktion erfolgt.

Ich bin der Meinung, dass hier Serverport und Clientport durcheinandergebracht wurde.
Ein Browser "verwendet" nicht den Port 80, Mailprogramme "verwenden" auch nicht die Port 110 bzw. 25.
Der Browser schickt Datenpakete zum Server mit dem "Vermerk", dass sie zum Port 80 des Servers geliefert werden soll.
Ein Mailprogramm schickt Datenpakete zum Mailserver mit dem Vermerk, dass sie zum Port 110 bzw. 25 des Mailservers geliefert werden soll.
Port 80, 110, 25 sind also die Serverports und vom Serverbetreiber so eingestellt sind, weil es allgemein so standardisiert ist.
Wenn der Betreiber lustig ist, kann er auch andere Ports einstellen, so dass nur Leute, die diesen Port kennen die Server kontaktieren können...
Somit haben diese "offenen Ports" erstmal garnichts mit dem eigenen Rechner zu tun.
"Verwenden", tun die Browser / Mailprogramme nur ihre Clientports.

Kommt jetzt auf die Interpretation von "Verwenden" an, denn wie du schreibst, schreiben die Clientprogramme in das Paket, dass es zum Server Port xyz soll. Klar verarbeiten tun die nur die Daten auf ihrem eigenen lokalen, meist für den User unsichtbaren Port. Deshalb kann der Betreiber des Servers, wie du gesagt hast einfach die Portsändern und das Clientprogramm guckt doof, weil es die Pakete zum nicht benutzten Standardport sendet.

Das sind wiederum CLIENT-Ports. Diese werden auf dem eigenen Rechner geöffnet.
Sie nehmen aber auch NUR Datenpakete von dem Server an, die das Filesharingprogramm zuvor vom selbigen angefordert hat an.

Emule ist das etwas schwieriger. Dieses Programm ist Client und Server gleichzeitig, sonst würde das Peer-to-Peer Prinzip nicht funktionieren. Deshalb sind auch einige Tricks nötig emule User zu finden, die gegen Urheberrecht verstoßen. Daher muss man bei Emule die besagten Ports als Serverports betrachten. Der Clientteil von Emule benutzt wieder für den Anwender unsichtbare Ports.

Stimmt. Jedes Programm kann beim OS sich einen Port reservieren lassen und erhält dann Pakete, die für diesen Port bestimmt sind.
Aber auch nur Pakete von dem Server, den der Dienst/Das Programm zuvor kontaktiert hat.

Für Clientports zutreffend und in der Praxis bei z.B. Bot-Netzen relevant, aber z.B. ein Trojaner installiert dir einen Webserver (und zufällig wird der Port im Router weitergeleitet, weil du z.B. P'n'P im Router aktiviert hast und der Trojaner den Router dann umprogrammiert hatte), dann kann dein PC als Server fungieren.

Ebenso kann jedes Programm von außen an jeden Port Ihres Computers angeschlossen werden.

Ich weiß auch nicht wie der Satz gemeint sein soll

Ich kann mir so ein Pferd doch nur über Mailanhänge, USB-Stick, Ausführen einer "*Pferd*.exe" auf mein System holen.
Erst dann kann das Pferd den Port auf meinem Rechner öffnen.
Diesen Port braucht es aber doch eigentlich garnicht um irgendwelche Daten zu "senden".
Das kann es doch auch so....?
Der geöffnete Port wäre doch nur dazu da, um Daten von seinem "Herrn" zubekommen, bzw. sich selbst zu updaten oder?

Das habe ich ja oben schon gestriffen, das Thema. Im Prinzip hast du es richtig erkannt. Es gibt aber viele Möglichkeiten einen Trojaner auf den PC zu laden. Dazu reicht schon ein sogenannte Drive-By-Download beim Aufufen einer (unseriösen) Webseite, oder über einer Werbebanner, ein Java-Script uvm. Man muss dazu nicht zwingend selbst etwas aktiv getan haben. Deshalb benutzen erfahrene Leute keinen Internet Explorer, sonderen einen Browser bei dem man No-Skript und Werbeblocker als Plugins installieren kann (d.h. Chrome oder Firefox).

Über die Firewall sind normalerweise nur die Ports, also Pforten geöffnet, die auch tatsächlich benötigt werden.
Habe ich keine Firewall, so sind auch unbenutzte Ports geöffnet, über die sich der Virus Zugang verschafft.

Ja, was dort stand war Quatsch. Ohne Firewall hat ein designierte Eindringlich auf ungepatchte oder veraltete Dienste, die nicht für ihn bestimmt sind zu zugreifen. Hänge ich meinen PC ins Internet, direkt ohne Firewall und so, dann kann man versuchen den PC über diverse Dienste zu hacken, angefangen mit der Dateifreigabe. Viele Dienste, die nicht für das Internet bestimmt sind, sind auch nicht, sagen wir mal, "gehärtet", oder es wird lässiger mit Sicherheitslücke umgegangen.

 

[The Ripper]

Ja das ist erstmal Aufgabe des Betriebssystems. Man kann diese Aufgabe in Firewalls auslagern (siehe vorherige Posts).

Ich dachte, wenn ein Port offen ist geht da auch wirklich alles rein? Ich mein, wenn per UDP Pakete verschickt werden, ist es doch kaum kontrollierbar, ob das Paket erwünscht/angefordert ist?

Ich bin der Meinung, dass hier Serverport und Clientport durcheinandergebracht wurde.
Ein Browser "verwendet" nicht den Port 80, Mailprogramme "verwenden" auch nicht die Port 110 bzw. 25.
Der Browser schickt Datenpakete zum Server mit dem "Vermerk", dass sie zum Port 80 des Servers geliefert werden soll.
Ein Mailprogramm schickt Datenpakete zum Mailserver mit dem Vermerk, dass sie zum Port 110 bzw. 25 des Mailservers geliefert werden soll.
Port 80, 110, 25 sind also die Serverports und vom Serverbetreiber so eingestellt sind, weil es allgemein so standardisiert ist.
Wenn der Betreiber lustig ist, kann er auch andere Ports einstellen, so dass nur Leute, die diesen Port kennen die Server kontaktieren können...
Somit haben diese "offenen Ports" erstmal garnichts mit dem eigenen Rechner zu tun.
"Verwenden", tun die Browser / Mailprogramme nur ihre Clientports.

Wo ziehst du den Unterschied verwenden/vermerken her?
Eigentlich werden alle Ports nur vermerkt ( eigentlich kann man das gar nicht so sagen, sie werden natürlich auch verwendet :O, wäre ja sonst sinnlos) und zwar in dem jeweiligen Protokoll-Headern, hier z.b. zu sehen am TCP- Header:
https://de.wikipedia.org/wiki/Transmission_Control_Protocol#/media/File:TCP_Header.svg

Man hat halt mal die ersten 100 Port fest definiert, dass die für Server verwendet werden, ist aber eine reine Definitionssache und man kann auch davon abweichen.

Korrektur:
Die Ports 1-1023 wurden "standardisiert" und zwar offiziell von der IANA.

 

[conf_t]

Ich dachte, wenn ein Port offen ist geht da auch wirklich alles rein? Ich mein, wenn per UDP Pakete verschickt werden, ist es doch kaum kontrollierbar, ob das Paket erwünscht/angefordert ist?

Auch UDP benutzt Ports und IPs, daher lässt sich sehrwohl feststellen, ob der UDP-Stream vom Client ausgelöst wurde oder nicht. Das trifft nur auf Serverports zu, weil die Dienste dahinter neue Anfragen von "außen" aktzeptieren. Clientports tun das nicht, bzw. du müsstes den bestehenden Stream "kapern", dazu brauchst gleich Ports, gleiche IPs und ggf. gleich Sequenz-Nummern und ACKs, damit es nicht auffällt. Um den Inhalt zu scannen bräuchte man eine Packetinspection. Es geht um das Zuordnen von "erwünschten/angefragten" UDP/TCP-Sessions anhand der Pors. Und zu ziehst meine Passage komplett aus dem Kontext. Wenn du schon so spitzfindig sein willst, ist alleine schon das Wort "alles" falsch, wie soll man denn dann die Sessions aueinanderhalten? Hört sich an als wäre das ein Schwarzes Loch .
Zum Spaß, mach mal an einem Standard Windows PC, ohne extra Software ein Telnet auf Port TCP 22. Oh Wunder es wird nicht gehen, auch im LAN nicht, wo die Windows-Firewall das nicht blocken würde, es fehlt einfach der Dienst auf Port 22 *Klopf,Klopf*


Korrektur:
Die Ports 1-1023 wurden "standardisiert" und zwar offiziell von der IANA.[/QUOTE]
Meine Tastatur schlckt manche Zeichen einfach weg. Das sollte 1000 heißen, ist zwar nicht 1023, aber für den Fall hier recht irrelevant.

 

[The Ripper]

UDP-Stream? not really

Es geht um das Zuordnen von "erwünschten/angefragten" UDP/TCP-Sessions anhand der Pors. Und zu ziehst meine Passage komplett aus dem Kontext. Wenn du schon so spitzfindig sein willst, ist alleine schon das Wort "alles" falsch, wie soll man denn dann die Sessions aueinanderhalten? Hört sich an als wäre das ein Schwarzes Loch .

Angenommen ich bin der Client und kommuniziere grad über 2.2.2.2.2:777 mit einem Server an 1.1.1.1:81, Protokoll UDP. Irgend ein beliebiger anderer z.b. 3.3.3.3:100 sendet nun an 2.2.2.2:777 ein gültiges UDP-Paket. Wie soll nun das Betriebssystem/Firewall erkennen, dass das Paket nicht erwünscht ist?

Zum Spaß, mach mal an einem Standard Windows PC, ohne extra Software ein Telnet auf Port TCP 22. Oh Wunder es wird nicht gehen, auch im LAN nicht, wo die Windows-Firewall das nicht blocken würde, es fehlt einfach der Dienst auf Port 22 *Klopf,Klopf*

ja, in der Tat, sowieso klar, wenn das Socket nicht registriert wurde.