Verschillende bron poorten bij TCP gebruik

[Marlibica]

Ik ben nog steeds een beetje aan het puzzelen met m'n firewall. Kom er prima uit, ik snap alleen nog één ding niet. Ik heb dmv een syslog eens zitten kijken wat er nou precies allemaal gebeurt op m'n netwerk en het blijkt dat als bijv iemand gewoon aan het surfen is, de bestemmingspoort altijd netjes 80 is maar de bronpoort (waar het vandaan komt) telkens anders is, zoals hier:


Als ik dus poorten naar buiten toe wil blokken, moet ik hier dus op één of andere manier rekening mee houden. Zo wilde ik een FTP servertje open zetten, poort 20 en 21 naar binnen EN naar buiten toe open gezet. Blijkt dat ik ook een portrange ergens tussen 3450 en 3550 naar buiten open moet zetten om dit te laten werken. Er staat hierover e.e.a. in het grote poortmappingsverhaal maar daar staat het alleen uitgelegd voor FTP. Bij SMTP gebeurt hetzelfde en ook gewoon bij surfen dus, maar daar is het wat minder belangrijk.

Dit is alleen spannend als ik van buitenaf een connectie wil maken met een server. Probeer ik van buitenaf bv te FTP'en met een server, dan moet die server een portrange naar buiten toe open hebben staan. Als ik van binnenuit wil FTP'en met een server op het internet hoef ik alleen poort 20 en 21 te openen en daar gaan we.

Nou is dit niet onoverkomelijk, ik denk dat ik sowieso al de boel om ga draaien door alleen bepaalde poorten naar buiten toe te blokken. Ik wil alleen graag weten waarom dit is zodat ik er rekening mee kan houden. Ik heb al diverse Wiki artikelen gelezen over source ports, ge googled erover maar ik weet eigenlijk niet eens goed op welke kernwoorden ik zou moeten zoeken.


Wie weet hier meer over?

[DieterVDW]

Ten eerste, dat de bronpoort steeds verandert bij HTTP traffiek is normaal. Deze wordt vrij willekeurig gekozen uit de beschikbare poorten.

Ten tweede: FTP is een speciaal geval, daar heb je naast de TCP connectie die de controle doet ook TCP dataconnecties. Deze kunnen active zijn (de client verbindt zelf met de server) of passive (de client geeft een ip adres en poort op en de server verbindt hier dan mee) .
Als je in je server opgeeft dat alle data connecties passive moeten gebeuren, dan moet je daar geen poorten voor openzetten. Bemerk wel dat je je clients hiermee verplicht om bepaalde poorten open te zetten of te forwarden op hun firewall/router. En aangezien het grootste deel van de surfende wereld tegenwoordig wel achter een NAT-routertje zit, is dat niet bepaald handig.

[Marlibica]

Ah ok.

Maar, waarom is dat normaal? Er moet toch een reden voor zijn?

* Marlibica is wat nieuwsgierig

[Osiris]

DieterVDW schreef op woensdag 14 juni 2006 @ 14:16:
Ten tweede: FTP is een speciaal geval, daar heb je naast de TCP connectie die de controle doet ook TCP dataconnecties. Deze kunnen active zijn (de client verbindt zelf met de server) of passive (de client geeft een ip adres en poort op en de server verbindt hier dan mee) .
Als je in je server opgeeft dat alle data connecties passive moeten gebeuren, dan moet je daar geen poorten voor openzetten. Bemerk wel dat je je clients hiermee verplicht om bepaalde poorten open te zetten of te forwarden op hun firewall/router. En aangezien het grootste deel van de surfende wereld tegenwoordig wel achter een NAT-routertje zit, is dat niet bepaald handig.

Speciaal geval? Jazeker, maar je legt active en passive net verkeerd uit

Hier wordt 't wel OK uitgelegd

[Osiris]

Marlibica schreef op woensdag 14 juni 2006 @ 14:18:
Ah ok.

Maar, waarom is dat normaal? Er moet toch een reden voor zijn?

* Marlibica is wat nieuwsgierig

Dat wat normaal is? dat je client-side ook poorten nodig hebt?

Dat komt omdat TCP een 2-weg-verbinding is. Een verzender en een ontvanger als 't ware, maar ook meteen de andere kant op. En als je wilt dat de ontvanger ook nog wat terug kan sturen naar z'n verzender, dan zal die verzender óók een poort moeten hebben, net als de poort 80 van de ontvanger. En die poorten worden door je OS willekeurig aangewezen meestal

Stel dat je 2 TCP-verbindingen zou maken naar dezelfde webserver op poort 80... Hoe gaat die webserver raden wat nou welke TCP-verbinding is om je website/plaatje/whatever terug te sturen als de client (jij dus) ook geen poort toegewezen kreeg per verbinding?
Spuit-11-edit

[ Voor 22% gewijzigd door Osiris op 14-06-2006 14:25 ]

[DieterVDW]

Stel dat HTTP traffiek een vaste bronpoort zou hebben, laten we even 81 pakken bvb.
Wel stel nu eens dat je aan het surfen bent en dat je 2 keer een pagina tegelijkertijd opent.
Je maakt dus 2 verbindingen naar een server op poort 80, beide vanaf poort 81 op je computer.
Als je nu een pakketje terugkrijgt van die server vanaf poort 80, bestemd voor poort 81 op je computer,
hoe kun je dan in godsnaam weten bij welke connectie dat pakketje hoort? Niet dus.

Een TCP connectie wordt geïdentificeerd door zijn bron ip en poort en doel ip en poort.
Als je dus 2 connecties legt naar hetzelfde ip en poort, dan is de enige manier om ze uit elkaar te houden om een andere doelpoort te gebruiken.

[CyBeR]

Marlibica schreef op woensdag 14 juni 2006 @ 14:18:
Ah ok.

Maar, waarom is dat normaal? Er moet toch een reden voor zijn?

* Marlibica is wat nieuwsgierig

Om twee redenen:
• Een poort valt maar een keer te gebruiken. Je kunt niet twee verbindingen tegelijk opzetten vanaf dezelfde poort.
• Veiligheid. Als het source port steeds hetzelfde is, is het opeens een stuk makkelijker om packets te spoofen. Ik kan dan packets sturen waarvan het lijkt alsof ze bij jou vandaan komen. (In de praktijk is er iets meer nodig, maar 't is een hindernis).

[ Voor 3% gewijzigd door CyBeR op 14-06-2006 14:26 ]

[CodeCaster]

Netjes uitgelegd DieterVDW Nog even twee aanvullingen, ten eerste geldt het voor alle TCP (en UDP) verkeer, niet alleen voor HTTP.

Verder is dit dus ook hoe NA(p)T werkt, de router onthoudt bij welke interne uitgaande poort een verbinding hoort, zodat de router weet naar welke PC 'ie het antwoord van de externe computer moet sturen

Rijst bij mij wel weer de vraag wat er gebeurt als je met 60.000 computers achter één router zit, dan kun je er donder op zeggen dat pakketjes naar de verkeerde PC teruggestuurd worden

---

Oh, en nog even ontopic

Je moet dus destination-poorten blokkeren, die zijn wel altijd hetzelfde (21 voor FTP, 80 voor HTTP, enz )

[ Voor 37% gewijzigd door CodeCaster op 14-06-2006 14:28 ]

[Osiris]

CodeCaster schreef op woensdag 14 juni 2006 @ 14:26:
Rijst bij mij wel weer de vraag wat er gebeurt als je met 60.000 computers achter één router zit, dan kun je er donder op zeggen dat pakketjes naar de verkeerde PC teruggestuurd worden

Zit je NAT-table gewoon binnen de kortste keren vol en kunnen $veel PC's niet meer op internet?

[CyBeR]

CodeCaster schreef op woensdag 14 juni 2006 @ 14:26:
Rijst bij mij wel weer de vraag wat er gebeurt als je met 60.000 computers achter één router zit, dan kun je er donder op zeggen dat pakketjes naar de verkeerde PC teruggestuurd worden

Als die ook alle 60000 tegelijk druk verbindingen aan het opzetten zijn ben je wel fucked ja. Maar NAT is daarom ook broken by design

[DieterVDW]

CyBeR schreef op woensdag 14 juni 2006 @ 14:25:
[...]
• Een poort valt maar een keer te gebruiken. Je kunt niet twee verbindingen tegelijk opzetten vanaf dezelfde poort.

O nee? En wat doet een server dan wel? Massa's verbindingen vanaf dezelfde poort ...
Je zou in theorie ook perfect kunnen al je HTTP verbindingen bvb bronpoort 80 geven en vandaaruit connecties leggen naar verschillende servers. De computer kan dan nog perfect aan het bronadres van de verschillende pakketjes uitmaken bij welke connectie deze horen.
Je krijgt maar problemen als je 2 connecties legt vanaf hetzelfde bronip en poort naar hetzelfde doel ip en poort.

[CodeCaster]

Osiris schreef op woensdag 14 juni 2006 @ 14:28:
[...]

Zit je NAT-table gewoon binnen de kortste keren vol en kunnen $veel PC's niet meer op internet?

Ik had het over een router, niet over een SpeedTouch Zo'n Cisco bak heeft standaard 32 MB geheugen, die krijg jij niet vol met NAT tabelletjes hoor

offtopic:
"$veel"... reminds me of something... oh ja, ik was aan het PHP-en

DieterVDW schreef op woensdag 14 juni 2006 @ 14:30:
[...]


O nee? En wat doet een server dan wel? Massa's verbindingen vanaf dezelfde poort ...
Je zou in theorie ook perfect kunnen al je HTTP verbindingen bvb bronpoort 80 geven en vandaaruit connecties leggen naar verschillende servers. De computer kan dan nog perfect aan het bronadres van de verschillende pakketjes uitmaken bij welke connectie deze horen.
Je krijgt maar problemen als je 2 connecties legt vanaf hetzelfde bronip en poort naar hetzelfde doel ip en poort.

Een webserver accepteert dan misschien wel 10.000 verbindingen tegelijk op poort 80, de verbinding wordt echter direct geporteerd naar een vrije socket, waara de source poort van het antwoord-pakketje gewoon weer random tussen 3000 en 64000 ligt

[ Voor 50% gewijzigd door CodeCaster op 14-06-2006 14:32 ]

[Marlibica]

* Marlibica snapt het \0/

Thnx!

[CyBeR]

DieterVDW schreef op woensdag 14 juni 2006 @ 14:30:
[...]


O nee? En wat doet een server dan wel? Massa's verbindingen vanaf dezelfde poort ...
Je zou in theorie ook perfect kunnen al je HTTP verbindingen bvb bronpoort 80 geven en vandaaruit connecties leggen naar verschillende servers. De computer kan dan nog perfect aan het bronadres van de verschillende pakketjes uitmaken bij welke connectie deze horen.

Nee, dat is naar dezelfde poort. Listening sockets werken anders in dat opzicht.

Je krijgt maar problemen als je 2 connecties legt vanaf hetzelfde bronip en poort naar hetzelfde doel ip en poort.

En wat gebeurt er vaak terwijl je aan het web browsen bent?

[DieterVDW]

CyBeR schreef op woensdag 14 juni 2006 @ 14:32:
En wat gebeurt er vaak terwijl je aan het web browsen bent?

Daarom dat het dan ook is zoals het is .

CodeCaster schreef op woensdag 14 juni 2006 @ 14:30:
Een webserver accepteert dan misschien wel 10.000 verbindingen tegelijk op poort 80, de verbinding wordt echter direct geporteerd naar een vrije socket, waara de source poort van het antwoord-pakketje gewoon weer random tussen 3000 en 64000 ligt

Als ik mijn HTTP traffiek snif, dan wordt er altijd gecommuniceerd met poort 80 op de server hoor...
De server houdt de verbindingen uit elkaar dmv de client socketadressen.
De verbinding wordt niet overgezet naar een andere poort.
Want dan zou de traffiek die ik terugkrijg van een HTTP server niet vanaf poort 80 komen hé.
Dat bedoel je toch?

[CyBeR]

CodeCaster heeft gelijk in dat dat je onmiddelijk naar een ander socket wordt overgezet, maar het source port blijft wel gelijk aan de poort waarnaar jij verbinding had gemaakt. Die verbinding bestaat immers nog. Maar de andere kant op kan dit niet. Je kunt niet meerdere verbindingen aanmaken met een enkele socket, en je kunt geen twee sockets met dezelfde poort maken.

[DieterVDW]

CyBeR schreef op woensdag 14 juni 2006 @ 14:58:
CodeCaster heeft gelijk in dat dat je onmiddelijk naar een ander socket wordt overgezet...

Hangt er beetje vanaf hoe je een socket definiëert I guess...
De officiële definitie is dat een socket een ip adres - poort combinatie is.
Alle pakketjes die een server dus ontvangt van zijn clients komen dus wel degelijk in dezelfde socket terecht.

Jullie bekijken een socket allicht als iets wat hoort bij een TCP connectie, wat eigenlijk niet klopt.
Inderdaad elke nieuwe connectie krijgt onmiddellijk een eigen datastructuur en buffers en zo toegewezen, naar dit is géén socket.
Maar de verwarring is begrijpelijk, als je bvb even aan denkt aan de Java API waar een ServerSocket nieuwe Socket objecten genereert bij een inkomende connectie.
De implementatie echter niet verwarren met het concept!

Er nog even de RFC op nageslagen:

To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network
and host addresses from the internet communication layer, this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.

[ Voor 36% gewijzigd door DieterVDW op 14-06-2006 15:29 ]

[JackBol]

socket != port

een port is een adres en een socket is een buffertje.

[CyBeR]

DieterVDW schreef op woensdag 14 juni 2006 @ 15:19:
[...]


Hangt er beetje vanaf hoe je een socket definiëert I guess...
De officiële definitie is dat een socket een ip adres - poort combinatie is.

Helemaal niet. Sockets kunnen net zo goed lokaal zijn (UNIX sockets in 't filesystem op unix dozen) of via een compleet ander netwerk werken dan een IP-netwerk.

Jullie bekijken een socket allicht als iets wat hoort bij een TCP connectie, wat eigenlijk niet klopt.

Ook niet, dus.

[DieterVDW]

Het gaat hier over TCP/IP verkeer hé, en ik gebruik de definitie van een socket uit de RFC.
Behoorlijk authoritair zou ik dus zeggen.
Als je over het concept 'socket' praat bij TCP/IP, dan heb je het over een ip-port combinatie.

Maar ja 'socket' wordt voor zoveel gebruikt (idd unix sockets en zo) dat er inderdaad wel een leuke discussie te voeren valt over wat een socket nu juist behelst.
"Een socket is een buffertje" is dan een andere visie, zij het erg implementatie specifiek ...

Nou ja niet veel zin om hier over te discussiëren denk ik, we hebben allemaal gelijk uiteindelijk .

[Wim-Bart]

Overigens is 60.000 NAT connecties door een NA(p)T router geen enkel probleem, mits er maar genoeg geheugen in zit. Een router is niks meer dan een doorgeefluikje met administratie. Een NAT router heeft simpel gezien gewoon een tabel die er als volgt uit ziet:

Inside IP

Inside Port

Outside IP

Outside Port

Voor IPv4 is er per regel 4 octets + word + 4 octets + word
In theorie zou je dus 0xFFFFFFFD x 0xFFFD regels in je tabel nodig hebben om het internet (IPv4) te NATten wat neerkomt op 281462091612169 regels = 3377545099346028 bytes = 3145584 GiByte, en alleen voor TCP dus x2 voor TCP+UDP en dan nog andere proto's zoals ICMP.

60.000 UDP+TCP connecties is dus niks, buffer van 704KiByte is hiervoor voldoende.

Een NAT router werkt gewoon heel simpel:

PC met ip 192.168.0.1:32000 zet verbinding op met 64.60.20.10:80
NAT router maakt regeltje aan met deze gegevens
Er komt een pakketje terug op de router
Router zoekt regeltje in zijn tabel en stuurt pakketje door

Natuurlijk heb je ook andere varianten dit op de router een socket aanmaken die de connectie onderhoud. Dan heb je echter een probleem en zit je theoretisch gebonden aan 0xFFFD connecties. Het is maar hoe de router NAT implementeerd.

[CodeCaster]

Ja, maar in het van het externe netwerk terugkomende pakketje staat níet het interne IP, dus weet de router enkel de poort.

En wanneer er zóveel PC's tegelijk massaal aan het verzenden slaan, zal er dan nooit een poort dubbel gebruikt worden? Dat vroeg ik me dus af

[JackBol]

wim-bart schreef op donderdag 15 juni 2006 @ 02:21:
Overigens is 60.000 NAT connecties door een NA(p)T router geen enkel probleem, mits er maar genoeg geheugen in zit.

het geheugen is niet het probleem... dat is maar een implementatie-specifiek detail. Het probleem is dat je hoge poorten op raken. 65536 - 1024 = 64512 max aantal concurrent connections...

[CyBeR]

Nah, als je 't source IP-adres meeneemt in die vergelijking kom je aan een stuk meer. Er is in principe geen reden waarom een NAT router niet kan zeggen 'Oh, dit packet met dst poort 1234 van IP-adres 1.2.3.4 moet naar 4.3.2.1, en dit andere packet met dst poort 1234 van IP-adres 5.6.7.8 moet naar 5.4.3.2'

Blijft allemaal knap kut natuurlijk. Zo'n enorme schaarste aan IP-adressen is er nou ook weer niet. (Alles na 239.0.0.0/8 is nog gewoon vrij, maar 'gereserveerd'.) En als dat er wel was: perfecte reden om IPv6 eens globaal in te gaan voeren.

[JackBol]

CyBeR schreef op donderdag 15 juni 2006 @ 13:46:
(Alles na 239.0.0.0/8 is nog gewoon vrij, maar 'gereserveerd'.)

die adressen gaan nooit meer gebruikt worden. Simpelweg omdat je ALLE tcp/ip stacks in de wereld dan zou moeten upgraden... als je daar mee bezig bent, kun je net zo goed meteen over stappen op v6.