• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Frage zu Ports

LadyRavenous

in Schwarz
Teammitglied

Registriert
26 Dez. 2016
Beiträge
16.079
Ort
hello world
Lass hier mal Protokolle raus. Bestimmte Protokolle verwenden üblicherweise bestimmte Ports, weil es das Leben einfacher macht, aber Protokolle sind bei deiner Frage erst einmal egal.

Du willst als Zimmer 58322 eine Anfrage an 80 schicken, richtig? Die Zuordnung von 80 und 443 muss bekannt sein. Du kannst theoretisch zB 8082 auf 443 leiten, wenn die Zuordnung machst (ist aber eigentlich Unsinn).

Im Endeffekt sind Ports eine Adressierung, eine Zuordnung von*TCP- und*UDP-Verbindungen und -Datenpaketen zu*Server- und*Client-Programmen.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Die eigentliche Magie passiert ja zu dem :443 auf :80 - woher weiß Paket :443 das es an :80 bestimmt ist, macht das in dem Fall der Router?

Und was sagt das Paket von :443 ? - Es soll an eine Interne Adresse weitergeleitet werden? Mit IP 192.168........... ? ;)

Fragen :D

Wie funktioniert ein Router. :D
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Sind Ports also nicht nur Netzwerkprotokollen vorbehalten sondern auch intern Arbeitende Software/Deamons notwendig, also nicht auschliesslich TCP/UDP vorbehalten?
Nein, intern wird üblicherweise mit Sockets gearbeitet. Das zu erklären ist aber schwierig, zumal ich sowas nie theoretisch gelernt hab, sondern immer nur aus der Praxis raus verstehe. Da wär die @LadyRavenous eher die richtige Person, die hat das AFAIK studiert. Ich *kanns* halt ;)
Womit ich dir aber gleich noch nen Knoten aus dem Kopf nehmen kann, ist die Sache mit den Protokollen. TCP/IP ist ein Netzwerkprotokoll. Das ist dafür da, dass überhaupt kommuniziert werden kann. Und ja, dieses Protokoll kennt Ports. HTTP ist auch ein Protokoll, aber ein Protokoll der Anwendungsschicht, es setzt auf TCP/IP bzw. UDP auf. Man könnte sagen, TCP/IP und UDP sind sowas wie Festlegungen, wie miteinander geredet wird (Telefon, persönlich, schriftlich etc.), wohingegen HTTP/FTP/SSH etc. am Ehesten mit der Sprache vergleichbar sind - denn wenn der eine englisch und der andere französisch redet, bringt es ihnen nix, wenn sie sich gegenseitig akkustisch verstehen, nur weil sie das gleiche Medium nutzen.

Wie kann der Server wissen, welchen Port er in das Packet nehmen muss, wenn er random ist?
Du meinst den Antwortport? Den hat dein Computer dem Server ja gesagt, der steht nämlich als Absender im anfragenden Paket drin. Firefox hingegen weiß, dass er HTTP verwenden möchte (oder HTTPS), und das wurde fest auf Port 80 bzw. Port 443 festgelegt. Viel ausprobieren muss man da nicht. Das ist wie ein Anruf - du wusstest die Nummer, und dein Gegenüber bekommt die Deine am Display angezeigt, noch bevor er antwortet. Rufnummernunterdrückung gibts im Internet nicht ;) Nur ist deine Nummer halt nicht permanent (was der Server weiß, denn auch er kennt diese Festlegung für Ports über 49.000) - sie gilt für diesen einen Anruf, danach nicht mehr.

Die eigentliche Magie passiert ja zu dem :443 auf :80 - woher weiß Paket :443 das es an :80 bestimmt ist, macht das in dem Fall der Router?

Du frägst nix über Port 80 an. Der ist kein ausgehender Port. D. h. da geht natürlich Information auch raus, aber nur auf Anfrage von außen. Dein Port, mit dem du das NGB kontaktierst, ist 54693. Rufst du das als HTTP auf, landest du beim NGB an Port 80. Das ist eine Festlegung, genauso wie SSH standardmäßig 22 ist. Der NGB-Server sagt dir dann aber, dass an Port 80 nix ist, du sollst doch bitte Port 443 ansprechen (das ist ein Redirect) und beendet die Verbindung wieder. Antworten kann er dir, weil dein Router und dein Computer bereits dein erstes Paket durchgelassen haben, von innen, und diesen Weg, den es dort genommen hat, zementiert hat für alle Kommunikation, die vom Server zurückkommt. Die wird automatisch durch den gleichen Kanal zurückgeschickt. Und nein, das weiß nicht der Router, das steht im Paket drin.

Ein Router ersetzt nur den Absender durch sich selbst, legt einen eigenen Ausgangsport fest und mappt intern, dass der Traffic vom externen Port 49685 jetzt nach intern zum Rechner 192.168.0.123:54693 durchgeleitet werden soll, sofern er von dem Server kommt, der ursprünglich angesprochen wurde.
 

Hartman

gesperrt

Registriert
18 Feb. 2018
Beiträge
63
  • Thread Starter Thread Starter
  • #24
Ich nehme an, wir sprechen nicht von Proxy socks. Soweit bin ich noch nicht. Das wird wohl in den weiteren Kapiteln kommen.

TCP/IP sei das Protokoll, ist es nicht ein Vorstellungs Modell als ersatz zu dem OSI-Modell? Ich dachte nur TCP steht als Protokoll der Kommunikation? Du sagst http ist ein Protokoll der Anwendungsschicht. Ist es nicht ein Protokoll welches 3 Schichten Anspricht? Session (User Session also hier sollten die Ports sein?), application, presentation (gzip als compression)?

Den hat dein Computer dem Server ja gesagt, der steht nämlich als Absender im anfragenden Paket drin.

Achsooo gut, genau das war mir unklar.
Kann ich selber bestimmen, welchen Port ich dem Server zuweisen will?

Etwas verwirrend. Wenn ich denke etwas zu verstehen, kommt ein neues Protokoll oder wie auch immer dazu und dann wieder Fragen.. :D
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Ich nehme an, wir sprechen nicht von Proxy socks.
Nein, definitiv nicht. Da kann ich dir auch wenig bis nix drüber sagen, das hab ich selber nie genutzt. Ich lern nur, was ich brauchen kann ;)

TCP/IP sei das Protokoll, ist es nicht das Modell als ersatz zu dem OSI-Modell? Ich dachte nur TCP steht als Protokoll der Kommunikation? Du sagst http ist ein Protokoll der Anwendungsschicht. Ist es nicht ein Protokoll welches 3 Schichten Anspricht? Session (User Session also hier sollten die Ports sein?), application, presentation (gzip als compression)?
Du würfelst hier 25 Sachen durcheinander:

OSI-Modell: Das ist ein theoretisches Konstrukt, wie man sich Kommunikation vorstellen und Abhängigkeiten merken kann. Es unterscheidet grob 7 Schichten, wobei nicht für jede Betrachtung alle Schichten beachtet werden müssen, sondern nur alle jeweils drunter liegenden. Wenn Layer 1 nicht vorhanden ist, wird TCP/IP nicht laufen (weil dann der Stecker ausgesteckt ist, da tut sich ne Netzwerkkarte äußerst schwer, noch sinnvoll zu kommunizieren). Für die Nutzung von TCP/IP ist HTTP oder FTP aber völlig irrelevant.
HTTP ist ein Protokoll der Anwendungsschicht. Es benötigt zum Funktionieren natürlich alle drunter liegenden Schichten als Voraussetzung, aber ist deshalb nicht in allen Schichten vorhanden.
Bei HTTPS ist es komplizierter: Die Verschlüsselung, also das S, wird auf der darunter liegenden Schicht 6 implementiert, d. h. es wird ZUERST die Verschlüsselung aufgebaut, bevor man sich um den Datenaustausch über HTTP kümmert, der dann ja durch den verschlüsselten Tunnel geht.
Um dass die Verschlüsselung problemlos funktioniert, muss die Schicht 5 dafür sorgen, dass wir eine stehende Verbindung (der Socket) bekommen und dass ein kleiner Schluckauf etc. nicht dazu führt, dass diese Verbindung (Session/Sitzung) abreißt.
Um eine solche Sitzung aufzubauen, muss auf Schicht 4 erstmal überhaupt TCP/IP laufen, also IP-Adressen und Ports bereitgestellt werden, sonst kann man gar keine Pakete zwischen zwei weit entfernten Partnern austauschen.
Damit das möglich wird, mus auf Schicht 3 erstmal dafür gesorgt werden, dass überhaupt Pakete über eine Zwischenstelle geroutet werden können, sonst müssen wir nämlich im Shotgun-Verfahren jedes Paket an alle leiten, und das ist ziemlich ineffizient und stört die Kommunikation, insbesondere wenn das Internet miteinander reden will ;).
Damit zwei Netzwerkschnittstellen aber überhaupt miteinander kommunizieren können, benötigen sie eine gemeinsame Sprache, gemeinsame Bitrate und natürlich auch eine Adresse - hier wird nämlich noch im Shotgun-Verfahren einfach gesagt, dass das Paket für die Adresse 85:94:3D:E4:A2:B2 ist, und derjenige soll sich das bitte selber zwischen den ganzen anderen Paketen rausfischen. Der Rest der Teilnehmer, die das Paket erhalten, wirft es einfach weg - ist ja nicht für sie. (diese Schicht wird noch aufgeteilt in zwei Subschichten, aber das ignorieren wir einfach mal)
Ja, und jetzt haben wir zwar alles bis ins Kleinste geregelt, aber uns fehlt noch das Kabel. Das ist Schicht 1.

Kann ich selber bestimmen, welchen Port ich dem Server zuweisen will?
Als Serveradmin ja. Als Client, der was vom Server will, nicht. Du kannst ja nicht bestimmen, wo Tante Elfriede wohnt und dich dann bei der Nachbarin im 2. Stock beschweren, warum sie die Tür aufmacht und nicht Tante Elfriede. Aber Tante Elfriede kann bestimmen, wo sie wohnen möchte...

Grundsätzlich ist es aber nicht sinnvoll, einfach frei Schnauze irgendwelche Ports auszusuchen, denn man WILL ja als Server gefunden werden. Deshalb gibt es von der IANA eindeutig festgelegte Standardports, die weltweit eindeutig sind und die häufigsten Dienste beschreiben (bis hin zu deinem DOOM-Server). Die Liste wird natürlich immer mal wieder aktualisiert, es kommen gerade im Bereich zwischen 1024 und 10.000 immer wieder neue Dienste dazu, die eine eigene, eindeutige und für andere damit "verbotene" Portnummer haben wollen. Man muss sich da zwar nicht dran halten, aber es ist freundlich, wenn man das tut. Wenns blöd läuft, und zum Beispiel OpenVPN sich auf einmal aussucht, sie hätten gern Port 8080, weil der so toll klingt, und ein Admin will aber alle HTTP-Ausweichports von seinem Webserver nutzen und gleichzeitig einen VPN-Server betreiben, dann schlagen sich der Webserver und der OpenVPN-Server um den Port - wer zuerst kommt, bekommt den Port exklusiv, d. h. es ist dann nicht sicher, ob sich hinter dem Port 8080 gerade der Webserver oder der VPN-Server befindet. Das ärgert den Admin, und sowas vermeidet man.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
deine Ausgehenden Ports sind jenseits der 49.000 - das sind die Client-Portranges, also die Ports, die spontan bei Bedarf geöffnet werden

Kleine Ergänzung/Korrektur: Das sind "(Ephemeral) Dynamic and/or Private Ports (49152-65535)" laut IANA und nicht "Client Ports".

Sind Ports also nicht nur Netzwerkprotokollen vorbehalten sondern auch intern Arbeitende Software/Deamons notwendig, also nicht auschliesslich TCP/UDP vorbehalten?
Ein daemon kann sowohl auf einem Unix Socket als auch auf einem TCP/IP-Port lauschen.

Achtung: Unix Sockets bitte nicht mit TCP Sockets verwechseln!

Wie kann der Server wissen, welchen Port er in das Packet nehmen muss, wenn er random ist?
Der Client (genauer: der Kernel/Netzwerkstack) entscheidet sich, welchen der dynamischen Ports er gerade vergeben will. Das Paket, das dann geschickt wird, enthält den anfragenden und den Ziel-Port. Um bei der hier im Thread etablierten Analogie zu bleiben: Der Ziel-Hostname ist der Adressatsadresse deiner Post, der Zielport ist die Zimmernummer und der Quellport ist deine eigene Zimmernummer.

Es kann doch sein, da dieser besetzt ist oder nimmt dieser dann einfach einen solange bis es klappt?
Der Netzwerkstack weiß zu jedem Zeitpunkt, welche Ports bereits belegt sind. Das kann sich innerhalb weniger Nanosekunden ändern.
 
Zuletzt bearbeitet:

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Ja, Hochfrequneztechnik ist Magie.

Die ganzen digital Pseudonatives(und ein paar ignorante alte Säcke) unterschätzen den Kram ganz gewaltig.

1hertz = 1 Intervall pro Sekunde
1Ghz = 1 Gigahertz
1 Gigahertz = 1000 Megahertz
1 Megahertz = 1000 Kilohertz
1 Kilohertz = 1000 Hertz

1Gigahertz = 1.000.000.000 Takte Pro Sekunde = 1.000.000 pro Millisekunde = 1.000 pro Nanosekunde

Viele CPU Instruktionen können in einem Takt abgehandelt werden.
Wie zum Beispiel die Addition von 2 Registern.

Peripheriezugriffe(Beispielsweise Anfragen an RAM oder Netzwerkkarte) dauern in der Regel "viel" länger also: unter Umständen dutzende Taktzyklen.

Da die Netzwerkchipsatz eines modernen PC's allerdings nach 70er Jahre Standard ein eigener Computer wäre wird das nochmal etwas relativiert. Was aber auch dazu führt das du an das Hardwarelevel nicht mehr praktikabel rankommst. Denn der Chipsatz sieht eine direktes durchleiten von irgendwas in den meisten Fällen wohl nicht mehr vor.

Die Darstellung ist sehr stark vereinfach, da all diese "Controller" wie erwähnt nach 70er Jahre standard komplett eigenständige Computer wären die in deinem Rechner miteienander kommunizieren kommen verschiedenartige Latenzen durch unterschiedliche Geschwindigkeiten dazu. Das war nur die Erklärung warum Nanosekunden problemlos haltbar sind.
 
Zuletzt bearbeitet:

Hartman

gesperrt

Registriert
18 Feb. 2018
Beiträge
63
  • Thread Starter Thread Starter
  • #28
Danke an alle und die Informationen. Ich brauche etwas Zeit und muss mich noch ein wenig einlesen um alle eure Informationen zu verarbeiten.

Das hier noch gefunden: https://www.youtube.com/watch?v=visrNiKIP3E


Ich schaue mir gerade das TCP-Packet an. Source Port und Destination Port. Wir haben ja vorher gesagt das der Source Port wird von meiner OS in das Packet geschrieben und zwar der, des clients, meiner bspw. Software.

Dabei ist dieser Port ja random vergeben, oder? Browser/Programme haben keinen fixen zugewiesenen Port?

Wenn ein Server also angesprochen wird, dann schickt er das Packet an meinen angegebenen Port. Heisst das auch, dass der Server theoretisch sich mit meinem Port verbinden koennte, wenn er offen sein muss? Ich habe das jetzt mal so verstanden, dass die Source Ports quasi nur innerhalb meines Betriebssystems addressiert sind und nicht Ports sind welche gegenseitige Netzwerkverbindungen erlauben?

Kennt jmd. eine gute methode, wie ich mit netcat rumspielen kann ohne mein eigenes Netzwerk potentiel zu vernichten? Gibts da evtl spezielle free VM/Virtualbox Labs?

Mir ist gerade aufgefallen das es von Port 24 praktisch kein Infos gibt?

Edit: Nachtrag; Kann man einen "Bit-Bucket" (abgelehnte oder verworfene Packete) wie auf einem Desktop Papierkorp einsehen?
 
Zuletzt bearbeitet:

eraser

Stinkstiefel

Registriert
21 Juli 2013
Beiträge
3.775
Im Grunde genommen ist das sogar relativ einfach zu erklären.

Dein Rechner öffnet bei einer ausgehenden Verbindung zB zu einem Webserver (Port 80) einen Port außerhalb der well-known Ports (>1024).

Wenn du zB eine Firewall stateless betreiben würdest, gibst du für den Datenverkehr Ein- und Ausgehend Quelle und Ziel an.

Eingehend: Quellport 443 | Destinationport > 1024
Ausgehend: Quellport > 1024 | Destinationport 443

Durch den Verbindungsaufbau zum Server weiß dieser von deinem eingehenden Port, der von deinem Client festgelegt wurde und du bekommst Antwort darauf. Funktioniert im Grunde ähnlich wie active FTP.
Der Client meldet sich per Port 21 beim FTP Server. Der Server "fragt" den Client, ob Port 1234 ok ist, Client sagt ja.. und der Datentransfer beginnt auf diesem Port.

Sinnhafter ist allerdings statefull, da hier die eingehenden Ports dynamisch geöffnet und geschlossen werden, passend zur ausgehenden Regel, welche fest definiert ist.
 
Zuletzt bearbeitet:

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
Die eigentliche Magie passiert ja zu dem :443 auf :80 - woher weiß Paket :443 das es an :80 bestimmt ist, macht das in dem Fall der Router?
Ich versuch mal die Kommunikation etwas vereinfacht zu erklären:

1. Du öffnest den Browser und tippst eine URL ein
Der Browser schickt ein HTTP-Paket an den Webserver (oder erst mal den Router dazwischen, aber das ist egal). Wichtiger Bestandteil im HTTP-Paket ist der Hostname. Das entspricht dem Vhost auf dem Webserver. Der Webserver kann dadurch unterscheiden, welche Seite aufgerufen wurde, auch wenn sich viele Seiten auf dem Webserver befinden und alle die gleiche IP haben.

2. HTTP-Anfrage auf dem Webserver
Der Server erhält das HTTP-Paket und prüft das jetzt mit seiner Konfiguration ab. Beim Apache sieht das normalerweise so aus:

https://wiki.apache.org/httpd/RedirectSSL
Code:
<VirtualHost *:80>
   ServerName mysite.example.com
   DocumentRoot /usr/local/apache2/htdocs
   Redirect /secure https://mysite.example.com/secure
</VirtualHost>

<VirtualHost _default_:443>
   ServerName mysite.example.com
   DocumentRoot /usr/local/apache2/htdocs
   SSLEngine On
# etc...
</VirtualHost>

In unserem Beispiel trudelt ein HTTP-Paket (=Port 80) ein. Also geht der Apache in seiner Config in die Section: VirtualHost *:80 rein und prüft, ob der Hostname aus dem HTTP-Header mit dem Servername übereinstimmt. Im Positivfall schickt er die Anfrage einfach an https://mysite.example.com/secure weiter.

3. HTTPS-Anfrage auf dem Webserver
Nach der Umleitung von HTTP an HTTPS sind wir wieder in derselben Config auf dem Webserver. Nur diesmal haben wir ein HTTPS-Paket auf Port 443. Die oberste Section wird also nicht "gematcht". Stattdessen prüft der Webserver die 2. Config und gibt das Dokument an den Client zurück.

Der Router ist in diesem Fall irrelevant.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Dabei ist dieser Port ja random vergeben, oder? Browser/Programme haben keinen fixen zugewiesenen Port?
Korrekt.

Wenn ein Server also angesprochen wird, dann schickt er das Packet an meinen angegebenen Port. Heisst das auch, dass der Server theoretisch sich mit meinem Port verbinden koennte, wenn er offen sein muss?
Ich glaube, du weißt nicht, was genau ein offener Port ist. Wenn der Port nicht geblockt ist und kein Programm dahinter lauscht, werden eingehende Pakete mit dem entsprechenden Zielport einfach nicht beantwortet.

Ich habe das jetzt mal so verstanden, dass die Source Ports quasi nur innerhalb meines Betriebssystems addressiert sind und nicht Ports sind welche gegenseitige Netzwerkverbindungen erlauben?
Du kannst ohne Probleme auch einen Dienst auf einem privaten Port lauschen lassen. Mit netcat geht das so:
Code:
nc -l 55555

Anzeigen kannst du dir den offenen Port dann mit

Code:
ss -lp | grep \"nc\"

Kennt jmd. eine gute methode, wie ich mit netcat rumspielen kann ohne mein eigenes Netzwerk potentiel zu vernichten?
Glaub' mir, du kannst prinzipiell recht wenig kaputt machen ;)

Gibts da evtl spezielle free VM/Virtualbox Labs?
Setz' dir doch einfach eine eigene VM auf. Ich empfehle Arch Linux, da lernst du einen Haufen über Linux. Versuch' dann mal, eine Netzwerkumgebung mit verschiedenen Services einzurichten. Auch Fedora in der Servervariante hat mir sehr viel über Netzwerkarchitektur beigebracht, insbesondere da die Firewall und SELinux standardmäßig sehr restriktiv eingestellt sind.

Mir ist gerade aufgefallen das es von Port 24 praktisch kein Infos gibt?
Wie genau meinst du das? Port 24 ist für "any private mail system" registriert.

Nachtrag; Kann man einen "Bit-Bucket" (abgelehnte oder verworfene Packete) wie auf einem Desktop Papierkorp einsehen?
Wie genau meinst du das? Deine Firewall kann dir in den Logs anzeigen, welche Pakete sie abgelehnt hat.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.823
Ort
Midgard
Geht so, zum Beispiel mit ARP-Paketen kann man schon alles so vermurksen das man unter Umständen alle Netzwerkgeräte neu initialisieren muss oder eine unbestimmte Zeit warten.
 

Hartman

gesperrt

Registriert
18 Feb. 2018
Beiträge
63
  • Thread Starter Thread Starter
  • #34
Wenn der Port nicht geblockt ist und kein Programm dahinter lauscht, werden eingehende Pakete mit dem entsprechenden Zielport einfach nicht beantwortet.

Ich habe -l (lauschen) mit "offen" verwechselt. Was ich damit sagen wollte ist, wenn ich mit einem zugewiesenen Port im Packet an den Server "lauschen" lasse, koennte dann der Gegensever diesen Port in irgend einer Weise missbrauchen durch reverse- oder binding-Shells? Kann eine Gegenpartei durch meinen zugewiesenen Port iwelche nachteilige informationen erhalten oder dies in irgend einer Form missbrauchen? Kann ich selber den Port mir zuweisen und wer weisst eigentlich TCP-Ports zu, Browser, Kernel?

Mit Bitbucket meinte ich, wo oder ob ich die abgewiesen Packete, die mir das Internet zusendet, nachschauen kann als log? Oder muss man Traffic-logs extra und seperat erstellen, wenn man nicht wireshark laufen hat 24/7?

Noch eine Frage: Ich nehme an, die Router vom ISP sind die Ports im "default" zustand schon geschlossen. Die Firewall des Routers also schon gesetzt als Werkseinstellung. Jetzt kann man ja noch eine Firewall auf 192.168.*.* dem PC im Netz haben. Wenn der Router bspw. einen Port offen hat, der auf meinem PC geschlossen ist, dann kommt das Packet zwar durch den Router in mein "Subnetz" rein, aber wird von meinem PC abgewiesen? Da gibt es keine Hierachische Struktur im Sinne, Router-Regel steht ueber der Host-Regel?

und noch interessiert hat mich die Frage: Ein Port isch geschlossen, ist das dann defintiv? Also Es gibt wenn der Port geschlossen ist keinen Weg diesen fur Aussenstehende zu ;ffnen oder lauschen lassen? Ich stelle mir das gerade mit der Analogie vor, wenn ein Fenster geschlossen ist, dann kann doch ein Einbrecher die Fenster einschlagen. Aber dies gilt hier nicht?
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
wenn ich mit einem zugewiesenen Port im Packet an den Server "lauschen" lasse, koennte dann der Gegensever diesen Port in irgend einer Weise missbrauchen durch reverse- oder binding-Shells?
Nein. Wenn da kein Daemon dahinter läuft, ist da eigentlich nix zu machen. Die Pakete werden nicht direkt abgewiesen, aber verarbeitet halt eben auch nicht wirklich.

Kann eine Gegenpartei durch meinen zugewiesenen Port iwelche nachteilige informationen erhalten
Definiere nachteilige Informationen. Dass eine Gegenstelle vorhanden ist, weiß dein Gegenüber automatisch, wenn das Paket nicht vom vorgeschalteten Gerät als "Zielhost nicht erreichbar" zurückgewiesen wird. Offene Ports ohne dahinterliegende Dienste bringen eigentlich auch nix. Es sind immer die Dienste, die angreifbar sind.

Kann ich selber den Port mir zuweisen und wer weisst eigentlich TCP-Ports zu, Browser, Kernel?
Lauschende Ports (incoming) weist du selbst zu (oder der Daemon, der dahinter lauscht).
Abgehende Ports (outgoing) weist dein Netzwerkstack zu.

Mit Bitbucket meinte ich, wo oder ob ich die abgewiesen Packete, die mir das Internet zusendet, nachschauen kann als log?
Wenn deine Firewall Rejects oder Drops loggt, dann ja. Wenn nicht, dann nicht. Und den Inhalt (Traffic) wird die Firewall nicht mitloggen, das wäre nämlich potentiell ein Angriffsvektor (Denial-of-Service durch Vollschreiben der Festplatten mit Logdateien).

Ich nehme an, die Router vom ISP sind die Ports im "default" zustand schon geschlossen.
Die meisten, ja.

Da gibt es keine Hierachische Struktur im Sinne, Router-Regel steht ueber der Host-Regel?
Nein, im Netzwerk stirbt jeder Host für sich allein. D. h. jeder ist für seine eigene Sicherheit selbst verantwortlich, auch wenn der Router schon die meisten Angriffe aus dem Internet gar nicht erst ins Netzwerk lässt.

Also Es gibt wenn der Port geschlossen ist keinen Weg diesen fur Aussenstehende zu ;ffnen oder lauschen lassen?
Für Außenstehende: Nein. (Portknocking mal ausgenommen, aber da hast du als Host-Admin das ja so eingestellt, dass nach einer bestimmten Port-Anfrageabfolge ein dedizierter, von vornherein bekannter Port geöffnet wird.) Also nein, Port geschlossen heißt: keiner lauscht da auf was, niemand nimmt den Netzwerkverkehr entgegen, keiner interessiert sich für etwaige Pakete, was ankommt wird alles weggeschmissen.
 

Hartman

gesperrt

Registriert
18 Feb. 2018
Beiträge
63
  • Thread Starter Thread Starter
  • #36
Danke. Ich glaube ich hab die Grundbasis verstanden. Wenn ein Port lauscht, ist der dann auf die Antwort des vorher abgesendeten Packetes spezifiziert? Also, wie genau ist der Unterschied zwischen einem lauschenden Port und einem offenen Port zu verstehen. Ein lauschender Port nur bei erwartetender Antwort und ein offener port ist quasi: "hallo, kommt alle rein in unsere "service Bar" und wir geben euch einen aus (bei 80 also Website inhalte etc.)

Wenn deine Firewall Rejects oder Drops loggt, dann ja. Wenn nicht, dann nicht. Und den Inhalt (Traffic) wird die Firewall nicht mitloggen, das wäre nämlich potentiell ein Angriffsvektor (Denial-of-Service durch Vollschreiben der Festplatten mit Logdateien).

Ich nehem an, selbe Problematik wie beim dhcp-log das jmd. mit vielen MAC-Addr wechsel abschiesst.
 

sia

gesperrt

Registriert
26 März 2015
Beiträge
5.931
Ort
FFM (NSFW)
Kann ich selber den Port mir zuweisen und wer weisst eigentlich TCP-Ports zu, Browser, Kernel?
Ports für Dienste legst du in deren Konfiguration fest.

(Ephemeral) Dynamic Port Ranges kannst du auch ändern:

Linux

Linux allows you to view and change the ephemeral port range by simply using the file /proc/sys/net/ipv4/ip_local_port_range. For example, this shows the default configuration on a kernel 2.2 system:

[src=bash]$ cat /proc/sys/net/ipv4/ip_local_port_range
1024 4999[/src]

To change this to the preferred range, you could do (as superuser):

[src=bash]# echo "49152 65535" > /proc/sys/net/ipv4/ip_local_port_range[/src]

Note that you would need to do this each time the system boots, so be sure to add a line to a system startup script such as /etc/rc.local so your range is always used.

Also note that the Linux 2.4 kernel will default the range of 32768 through 61000 if adequate kernel memory is available, so changing the range may not be necessary on newer Linux systems.

Finally, also note that you may be able to use the sysctl interface to change the settings rather than using the /proc filesystem. The name of the sysctl parameter is "net.ipv4.ip_local_port_range". Edit the /etc/sysctl.conf file if you have it, or have a startup script run the sysctl command manually if you want to change this parameter using sysctl.

[…]

Microsoft Windows

As of Windows Vista and Windows Server 2008, Windows now uses a large range (49152-65535) by default, according to Microsoft Knowledgebase Article 929851. That same article also shows how you can change the range if desired, but the default range is now sufficient for most servers.

For older Windows operating systems (Windows XP and older), Windows uses the traditional BSD range of 1024 through 4999 for its ephemeral port range. Unfortunately it appears that you can only set the upper bound of the ephemeral port range. Here is information excerpted from Microsoft Knowledgebase Article 196271:

  • Start Registry Editor (Regedt32.exe).
  • Locate the following key in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  • On the Edit menu, click Add Value, and then add the following registry value: Value Name: MaxUserPort Data Type: REG_DWORD Value: 65534 <for example>, Valid Range: 5000-65534 (decimal) Default: 0x1388 (5000 decimal)
  • Description: This parameter controls the maximum port number used when an application requests any available user port from the system. Normally, ephemeral (that is, short-lived) ports are allocated between the values of 1024 and 5000 inclusive.
  • Quit Registry Editor.

Note: There is another relevant KB article (812873) which claims to allow you to set an exclusion range, which could mean that you could exclude ports 1024-9999 (for example) to have the ephemeral port range be 10000-65534. However, we have not been able to get this to work (as of October 2004).

Mit Bitbucket meinte ich, wo oder ob ich die abgewiesen Packete, die mir das Internet zusendet, nachschauen kann als log? Oder muss man Traffic-logs extra und seperat erstellen, wenn man nicht wireshark laufen hat 24/7?
Muss ja nicht wireshark sein, du kannst auch tcpdump (entgegen des Namens kann es auch andere Protokolle als TCP aufzeichnen) verwenden.

Ich nehme an, die Router vom ISP sind die Ports im "default" zustand schon geschlossen. Die Firewall des Routers also schon gesetzt als Werkseinstellung.
Jein, DNAT.

Jetzt kann man ja noch eine Firewall auf 192.168.*.* dem PC im Netz haben. Wenn der Router bspw. einen Port offen hat, der auf meinem PC geschlossen ist, dann kommt das Packet zwar durch den Router in mein "Subnetz" rein, aber wird von meinem PC abgewiesen?
Korrekt.

Da gibt es keine Hierachische Struktur im Sinne, Router-Regel steht ueber der Host-Regel?
Warum sollte das so sein?

Es gibt wenn der Port geschlossen ist keinen Weg diesen fur Aussenstehende zu ;ffnen oder lauschen lassen?

Nur über Exploits, die über andere Dienste auf das System kommen, also quasi "von innen heraus". Tatsächlich kann ich mich nicht daran erinnern, dass ein Netzwerkstack mal das Öffnen von irgendwelchen Ports von außen erlaubt hätte; allerdings wäre das ohne lauschenden Dienst wohl auch total unnötig.

Ich stelle mir das gerade mit der Analogie vor, wenn ein Fenster geschlossen ist, dann kann doch ein Einbrecher die Fenster einschlagen. Aber dies gilt hier nicht?
Wenn kein Fenster da ist, müsste der Einbrecher erst einmal eins einbauen ;)

Die Ephemeral Ports sind nicht für eingehende Verbindungen vorgesehen. Aus der iptables-Firewall-manpage:

[…] state is a comma separated list of the connection states to match. Possible states are
INVALID meaning that the packet is associated with no known connection,
ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions,
NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions, and
RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Also, wie genau ist der Unterschied zwischen einem lauschenden Port und einem offenen Port zu verstehen.
Offen und Lauschen sind keine Kategorien. Offen und Geschlossen sind welche. Server-Port (also für einen Serverdienst dedizierter Port) oder ephemeral Port sind Kategorien.

Ein Server-Port ist ein Port, der nach dem Motto verfährt: Kommt alle Rein, hier gibts Freibier, Koks und Nutten.

Ein Ephemeral Port ist ein Port, der nur schriftlich geladene Gäste mit Eintrittskarte reinlässt.

Ich nehem an, selbe Problematik wie beim dhcp-log das jmd. mit vielen MAC-Addr wechsel abschiesst.
Jajein, eher so ein Fall von "ich schick dir riesige Pakete, und das stundenlang an der Kapazitätsgrenze deiner Leitung - wenn du den ganzen Zufalls-Inhalt speicherst, hast du einfach eine Logdatei, die ein paar Terabyte groß ist, bis kein Platz mehr für irgendwas auf der Festplatte ist. Der Server schmiert dann zwar nicht ab, aber machen kannst du damit auch nix mehr (Logins werden nicht mehr protokolliert, Speicherfehler nicht mehr, sonstige Systemevents etc.).
 

Hartman

gesperrt

Registriert
18 Feb. 2018
Beiträge
63
  • Thread Starter Thread Starter
  • #39
Definiere nachteilige Informationen

Aus IT Forensic- oder Security Pentester Sicht? Damit wollte ich nur wissen, ob diese Informationen die ich an eine (scheinbar) unbekannte Gegenpartei sende ein Risiko fur mich darstellen kann. Zbsp. ob man anhand des Portes der in das Packet geschrieben wird, sich Informationen extrahieren lassen uber die OS, Services etc des Absenders. Ob sich, auch wenn die Ports random sind, durch Algorithmen oder anhand der Art der Vergabe/Zuweisung herausgefunden werden kann welche OS etc. man nutzt.

Ich denke mal an Banner-Grabbing. Wenn ich mit nc den service-header des Server ansehen kann (ob die richtig oder nicht richtig sind ist mal jetzt egal) kann das dann die Gegenpartei auch bspw. welche Arch ich habe?

Ich denke da bspw. an cookies und bspw. Browser-Agents. Laufen die zusammen mit dem http auf den Port 80,8080,443?


Ich glaube ich weiss was du meinst. Da lese ich mich ein, wenn ich die Grundlagen sicherer kann. Will mich da jetzt "noch" nicht verwirren lassen durch zu viele neue Infos.

Warum sollte das so sein?
Ich dachte da an Hubs und Switches.

Wenn kein Fenster da ist, müsste der Einbrecher erst einmal eins einbauen
Damit ich das richtig verstehe: Port geschlossen = Fort knox

Wenn wir hier surfen, dann kommen wir ja auf die Website durch 443 oder 80 rein. Wenn ich aber etwas Poste, dann "lade" ich ja etwas bei eurem Provider-Server rauf. Also im prinzip eine .txt Datei. Passiert das auch mit/auf Port 80, 443 oder braucht es dann Port 21?


Nein, im Netzwerk stirbt jeder Host für sich allein. D. h. jeder ist für seine eigene Sicherheit selbst verantwortlich, auch wenn der Router schon die meisten Angriffe aus dem Internet gar nicht erst ins Netzwerk lässt.

Der Switch ist ja eigentich in der Data Link Schicht und kommt vor dem Router (oder sind die in Standart Heimnetze im Router integriert?), falls ich mir das richtig gemerkt habe. Wird dann nicht der Switch das Packete zu erst ablehen oder nur auf seine technische Eignung gepru;ft?

[Edit]Etwas anderes: Wenn ich ein Packet sende, dann muss dieser ja "hops" nehmen. Dh. doch das mein Packet durch den ISP von mir und durch den vom receiver gehen muss. Da muss doch der ISP auch Ports offen haben oder wie muss ich mir das vorstellen?
Ich merke gerade, das diese Frage etwas dumm ist. Da mir alles noch ganz neu ist habe ich mich im Detail verstrickt. Wenn ich ansurfe dann haben die dazwischen liegenden nodes nur Physical-, Data Link- und Network-Layer bereit gestellt. Der Transportlayer ist gar nicht vorhanden, also muss da auch kein Port vorhanden sein... :P
Da kann man sich schon verhardern in dem ganzen Komplex...[/Edit]

Gibt es eigentlich iwo einen Dienst, oder ein Programm womit man ein simples Packet an jmd. schicken kann und sieht, wie es auf der Welt anhand einer Weltkarte gewandert ist ("hopped")? Das finde ich ganz spannend, wenn man das sehen kann.

Ist diese Eintrittskarte in der Checksum des Packets geschrieben, wo wird das validiert?


Wenn ich IPs auf meinem PC sperre (White oder Blacklist) bspw. wegen eines SYN-Floods oder allg. wegen eines Traffic-DDos bringt es nicht viel wenn ich diese lokal sperre, die muss man auf dem Router sperren? Kann man eigentlich DDos'en, wenn ein Heimnetz alle Ports gesperrt hat, da gibts ja theoretisch nichts das ich anbiete das jmd. fremdes angehen kann? Wie ich das verstehe, wenn ich im Heimnetz alle Ports zu habe und jmd mir x^n SYN Anfragen schickt, dann muss doch im Packet trotzdem ein Port enthalten sein? Da dieser bei mir geschlossen ist, wird der Router ein RST senden und somit die ganze Zeit, keine Zeit fur mich haben (DDos-Ziel?). Was passiert aber, wenn der Port offen ist, wie unterscheidet sich das genau? Ich hoffe man versteht, was ich meine...
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Aus IT Forensic- oder Security Pentester Sicht? Damit wollte ich nur wissen, ob diese Informationen die ich an eine (scheinbar) unbekannte Gegenpartei sende ein Risiko fur mich darstellen kann.
Potentiell: Ja. Es kommt halt auf die Intentionen des Gegenüber an. Einem Feind *irgendeine* Information zukommen zu lassen (auch Existenz ist eine Information), ist potentiell gefährlich. Die Frage, die du dir an dieser Stelle stellen musst ist: Wie hoch sind die Mittel, die mein potentieller Feind einzusetzen bereit ist, um meine Verteidigung zu durchbrechen, und was erhofft er sich als Gewinn? Ist dieser Kosten-Nutzen-Faktor stark kostenintensiv und wenig nützlich, wird dein Feind dich nicht angreifen.

In deinem Fall: Nein, nicht gefährlich.

Zbsp. ob man anhand des Portes der in das Packet geschrieben wird, sich Informationen extrahieren lassen uber die OS, Services etc des Absenders.
Outgoing Ports: Nein, außerhalb deines direkten Netzwerks eher nicht.
Incoming Ports: Sehr stark. Windows wird beinahe immer RDP, SMB oder NetBIOS offen haben und auch derartige Pakete ins lokale Netz verschicken. Bei Linux ist SSH ein Kandidat. Außerdem sind die meisten Firewalls unter Windows DROP-Walls, d. h. man sieht als Angreifer/Scanner ein schwarzes Loch. Bei Linux ist REJECT normal, d. h. da kommt immer ein Nein zurück.

Ich denke mal an Banner-Grabbing.
Ja, da steht meist ziemlich viel drin, meist sollte das aber keine sicherheitsrelevante Info sein, sofern dein System up to date ist. Der Angreifer sieht halt gleich, was nicht funktionieren wird (weil Sicherheitslücke bereits gepatcht, aber das hätte er beim versuchten Exploit eh gesehen.

Ich denke da bspw. an cookies und bspw. Browser-Agents. Laufen die zusammen mit dem http auf den Port 80,8080,443?
Alle Kommunikation mit dem Browser läuft auf 80/443/8080. Cookies werden nur nie zum Server verschickt ;)

Ich dachte da an Hubs und Switches.
Hubs und Switches ermöglichen nur Kommunikation und deren Steuerung, Sicherheit wird da noch lange nicht implementiert. Das ist erst mit Routern der Fall (und mit managed switches, aber da kommen wir grad wieder auf komplexen Untergrund).

Damit ich das richtig verstehe: Port geschlossen = Fort knox
Ja.

Also im prinzip eine .txt Datei. Passiert das auch mit/auf Port 80, 443 oder braucht es dann Port 21?
Nein, du lädst einen Datenstream, keine Datei. Der wird vom Apache2 (Webserver, Port 443) und den PHP-Seiten in die Datenbank gejagt. FTP hat damit nix zu tun (und der Port ist auch nicht offen, wenn du mal schauen möchtest).

Der Switch ist ja eigentich in der Data Link Schicht und kommt vor dem Router (oder sind die in Standart Heimnetze im Router integriert?)
Achtung, du verwechselst da was. Das OSI-Schichtenmodell hat nichts mit Priorität oder "vorher/nachher" zu tun, sondern ist ein Bedingungsmodell. Wenn kein Kabel da ist, dann kann ein Router auch nichts routen. Ein Router braucht also die Schichten 1 und 2, um überhaupt seiner Arbeit nachgehen zu können, kann aber logischerweise selbst beide darunterliegenden Schichten auch. Eine Netzwerkkarte zum Beispiel kann in Verbindung mit dem dahinter liegenden OS alles, von Kabel bis Anwendungsschicht, inklusive Routing, Data Link etc. Geh mal ein bisschen weg von dem Modell, in der Praxis hilft dir das selten weiter.

Ein Switch schiebt Pakete nur an den richtigen Adressaten, aber dazu muss der direkt an ihm hängen. Stell dir das vor wie ein Vorarbeiter, der die Arbeit für 8 Leute verteilt und immer wieder Antworten von diesen Leuten für jeweils andere Leute bekommt. Der nimmt das Brieflein entgegen, schaut nach, für wen es genau ist und schiebt das in genau dieses Fach. Ein Hub würde es Kopieren und einfach in jedes Fach werfen. Sanityprüfung macht keiner davon.

Da muss doch der ISP auch Ports offen haben oder wie muss ich mir das vorstellen?
Nicht wirklich. Das meiste dürfte auf Ebene 3 (Routing) stattfinden, abgesehen vom Anschauen, wohin das Paket genau soll. Ausnahme: Shared connections. Da wird dann mit NAT gearbeitet, das braucht Ports, um Zuordnungen zu ermöglichen. Da wäre aber glaub thom eher der richtige Ansprechpartner...

Gibt es eigentlich iwo einen Dienst, oder ein Programm womit man ein simples Packet an jmd. schicken kann und sieht, wie es auf der Welt anhand einer Weltkarte gewandert ist ("hopped")?
Obs das auch graphisch gibt, weiß ich nicht (wahrscheinlich schon), aber es gibt es auf jeden Fall fürs Terminal: traceroute.

Ist diese Eintrittskarte in der Checksum des Packets geschrieben, wo wird das validiert?
Die Eintrittskarte ist der Absender - der Port wartet ja auf ein Paket von a.b.c.d:443 - kommt da eines an, ist es eingeladen. Kommt eins von w.x.y.z:48 an, wurde das nie angefragt und wird verworfen (das ist glaub mit Firewalling am Besten erklärbar, weil da die Statuus der Pakete (NEW, ESTABLISHED, RELATED, INVALID) ne Rolle spielen. Das ist aber nicht ohne, merks dir einfach für den Anfang mal so, dass es einfach nicht geht, bis du ne solide Vorstellung hast, wie das mit Ports, IPs und Routing genau läuft.

Wenn ich IPs auf meinem PC sperre (White oder Blacklist) bspw. wegen eines SYN-Floods oder allg. wegen eines Traffic-DDos bringt es nicht viel wenn ich diese lokal sperre, die muss man auf dem Router sperren?
Wenn du einen SYN-Flood auf deinen PC bekommst, dann ist der entweder lokal oder du hast deinem Router dummerweise ne Wildcard-Weiterleitung auf deinen Rechner eingerichtet (Portforwarding) - eine eher doofe Idee. SYN-Floods sind normalerweise nur für Webserver interessant, weil SYN immer ein Paket des Status NEW ist, d. h. das allererste Paket, das zwischen zwei Kommunikationspartnern zum Aufbau einer Verbindung geschickt wird. Schon das zweite Paket ist ein SYN-ACK und damit RELATED.

SYN-Floods funktionieren, weil der Server für jeden SYN (also für jede Verbindung) einen Prozess ausforkt, und es gibt ein Maximum an Forks, die der Master gleichzeitig unterhalten darf. Ist das erreicht, kann kein weiterer SYN mehr angenommen werden, und der Dienst ist nicht mehr erreichbar. Der Angreifer schickt dabei en masse SYNs, erhält auch die SYN-ACKs vom Server, beantwortet die aber nie mit einem ACK, um die Verbindung tatsächlich aufzubauen. Er will ja gar keine Daten, er will nur den Dienst stören. Der Server bekommt also nie mehr eine Antwort, und nach einer definierten Zeit gibt er auf und killt den Fork, ohne dass jemals eine Verbindung zustande gekommen wäre. Damit ist wieder Platz für neue Verbindungs-Aufbauten mit einem neuen SYN.

Wie gesagt, nicht dein Problem, und weit entfernt von jedem Problem, das du in den nächsten 6 Monaten haben wirst. Niemand DoSt ein Heimnetzwerk, das macht einfach keinen Sinn, und funktionieren tut es auch nicht (weil der Router von außen keine SYNs akzeptiert, wenn du kein Portforwarding eingerichtet hast).

Ich geb dir mal nen kleinen Tipp, bevor wir uns hier weiter verzetteln: Du liest fleißig, das ist toll und macht mir auch Spaß. Das Problem dabei ist nur, dass du deinem Gehirn keine Zeit lässt, das angelesene Wissen tatsächlich zu verstehen - du stopfst grad nur und kommst entsprechend oft durcheinander. Manchmal ist weniger mehr. Lass mal Angriffsszenarien, Firewalling etc. erstmal außen vor, und bleib grad mal vielleicht bei TCP/IP fürs erste. Dann lernst du, wie eine Verbindung auf- und abgebaut wird, was Statuus sind, wie die Erwartungshaltung der Gesprächspartner über das nächste Paket ist etc. und vor Allem: Wo das auf welchen OSI-Schichten eine Rolle spielt. Wenn du das wirklich im Schlaf kannst und die Bedingungen dafür und Konsequenzen daraus verstehst, kannst du dich um Angriffswege schlau machen und auch mal mit telnet ne Verbindung zum Beispiel zu nem Mailserver aufbauen. Langsam anfangen, langsam steigern. Nicht alles auf einmal. Wir sind auch nicht als Meister vom Himmel gefallen, wir alle nicht.
 
Zuletzt bearbeitet:
Oben