Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Nut van Poortscan
18-11-2020, 10:27 door Anoniem, 35 reacties
Wat is het nut van het uitvoeren van een Poortscan?
Reacties (35)
Door Anoniem: Wat is het nut van het uitvoeren van een Poortscan?
Ga zelf je huiswerk maken.
18-11-2020, 11:56 door
User2048
Het koste mij drie tellen om dit te vinden: https://nl.wikipedia.org/wiki/Portscan.
18-11-2020, 12:41 door
MathFox
Een poortscan is een inventarisatiestap.
18-11-2020, 12:52 door
Bitje-scheef
Zie het als een flat waar je voorstaat en je kijkt waar de deuren en ramen openstaan.
Dit zijn mogelijke ingangen waar je naar binnen kunt, soms voor een bakkie koffie, soms voor een bakkie thee.
Dit zijn mogelijke ingangen waar je naar binnen kunt, soms voor een bakkie koffie, soms voor een bakkie thee.
Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
18-11-2020, 14:00 door
MathFox
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
syntax error reinterpretationEen poort is in veel gevallen simpel te openen van binnen naar buiten.
18-11-2020, 15:16 door
Killjoy
Door Bitje-scheef: Zie het als een flat waar je voorstaat en je kijkt waar de deuren en ramen openstaan.
Dit zijn mogelijke ingangen waar je naar binnen kunt, soms voor een bakkie koffie, soms voor een bakkie thee.
Dit zijn mogelijke ingangen waar je naar binnen kunt, soms voor een bakkie koffie, soms voor een bakkie thee.
Of soms voor "Oh buurman, wat doet u nu?" :D
Door MathFox:
Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
syntax error reinterpretationEen poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?
Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
Dat je weet dat je een ander beroep moet zoeken, verder "zien wat er toegankelijk is en open is op een systeem vanaf het buiten aanzicht, luisterende services etc".
18-11-2020, 15:45 door
MathFox
Door Anoniem:
Nee, er is een programma op de computer dat een poort opent.Door MathFox: Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
De beheerder van de computer (of firewall) zegt "Dit is geen speelterrein" tegen scriptkiddies.Door Anoniem:
Ja maar nooit van buiten naar binnen toch?
Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
https://www.google.com/search?q=nmap+filtered+ports Ben je aan het trollen of ben je gewoon lui? Autodidactiek is belangrijk als een hacker zijnde.Door MathFox:
Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
syntax error reinterpretationEen poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?
Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
18-11-2020, 16:11 door
Erik van Straten
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
Nee. Google: port knockingDoor Erik van Straten:
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
Nee. Google: port knockingErik, je antwoord is helaas onjuist.
Via een poort die dicht staat kom je niet naar binnen, er bestaan wel mechanismen om die poort van buitenaf te openen zodat je er wel door naar binnen kunt.
Door MathFox:
Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
syntax error reinterpretationEen poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja, en dat is gewoon geen vraag op het antwoord.
Door Anoniem:
Ja maar nooit van buiten naar binnen toch?
Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
Door MathFox:
Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
syntax error reinterpretationEen poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?
Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
Dat deze niet te benaderen is.
18-11-2020, 18:34 door
Erik van Straten
Door Anoniem:
Erik, je antwoord is helaas onjuist.
Via een poort die dicht staat kom je niet naar binnen, er bestaan wel mechanismen om die poort van buitenaf te openen zodat je er wel door naar binnen kunt.
Poorten, IP-adressen en zelfs MAC-adressen zijn virtueel, dingen die we zo zijn gaan noemen om complexe materie te vereenvoudigen. Dat er "verderop" in het door jou gebruikte OS functionaliteit zit die UDP, TCP, ARP, ...pakketjes "begrijpt", betekent niet dat je geen mogelijkheden zou hebben om buiten de begaande paden te gaan.Door Erik van Straten:
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
Nee. Google: port knockingErik, je antwoord is helaas onjuist.
Via een poort die dicht staat kom je niet naar binnen, er bestaan wel mechanismen om die poort van buitenaf te openen zodat je er wel door naar binnen kunt.
Op een moderne "netwerkkaart" zit een Ethernet- of optische connector waarop serieel signaaltjes binnenkomen die eerst in bits en daarna in bytes worden omgezet. Op basis van bytes op specifieke offsets vanaf de eerste ontvangen byte "herkennen" we dat het bijv. om een IP pakketje gaat, en zo ja, of daarin bijv. een "TCP" pakketje zit, en zo ja, voor welk "poortnummer" dat pakketje bedoeld is.
Met een firewall (logging daaruit) kun je zien dat specifieke pakketjes "binnenkomen op een gegeven poort". Niets belet je om software te maken die na één specifiek pakketje, of desgewenst een sequence, een poort open te zetten (bijv. door een firewall-regel toe te voegen waarmee toegang wordt verleend voor specifiek afzender IP-adres). Dat kan een andere "poort" zijn, of die "poort" zelf.
Voorbeeld: lang geleden heb ik een Atari ST gehad met een "Real time clock" module die je tussen één van de OS EPROM's en diens chipvoetje moest pluggen. Door een specifieke sequence van EPROM-adressen uit te lezen, kreeg de driver toegang tot de RTC chip (op dat moment moesten hardware-interrupts worden uitgezet om te voorkomen dat -op dat moment onbereikbare- OS routines aangeroepen zouden worden). Vergelijkbaar: de Commodore 64 had (heeft?) 64kB RAM en 2x 8KB ROM, maar kon slechts 64kB adresseren. Een (assembler/machinetaal) programmeur moest dus kiezen of hij de CPU beide ROM's wilde "laten zien" zoals gebruikelijk, of bijv. de "BASIC ROM" tijdelijk wilde uitschakelen, zodat de CPU het RAM-geheugen "onder" die ROM kon lezen en beschrijven.
Iets minder lang geleden heb ik speciale netwerksniffers geschreven die, werkend onder DOS, gebruik maakten van (toen voor DOS beschikbare) packet drivers (met een standaard API, en aan de andere kant ondersteuning voor een specifieke netwerkkaart). Uiteindelijk is een Ethernet netwerkpakketje niets anders dan een reeks bytes. Hoe die reeks wordt geïnterpreteerd, bepaalt de software daarachter. The sky is the limit.
Door Erik van Straten:
[knip]
The sky is the limit.
Door Anoniem:
Erik, je antwoord is helaas onjuist.
Via een poort die dicht staat kom je niet naar binnen, er bestaan wel mechanismen om die poort van buitenaf te openen zodat je er wel door naar binnen kunt.
Door Erik van Straten:
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
Nee. Google: port knockingErik, je antwoord is helaas onjuist.
Via een poort die dicht staat kom je niet naar binnen, er bestaan wel mechanismen om die poort van buitenaf te openen zodat je er wel door naar binnen kunt.
[knip]
The sky is the limit.
Ik acht je normaal best hoog maar dit is een teleurstellende reactie en puur als verdediging op je portnocking antwoord.
Het gaat over een poortscan en open/dichte poorten, als je dichte poorten zo makkelijk zou kunnen omzeilen dat zouden firewalls niet werken. Daar wil ik dan nog wel bewijs van zien dan.
Nogmaals, door een dichte poort kom je niet binnen.
Door Erik van Straten:
Op een moderne "netwerkkaart" zit een Ethernet- of optische connector waarop serieel signaaltjes binnenkomen die eerst in bits en daarna in bytes worden omgezet. Op basis van bytes op specifieke offsets vanaf de eerste ontvangen byte "herkennen" we dat het bijv. om een IP pakketje gaat, en zo ja, of daarin bijv. een "TCP" pakketje zit, en zo ja, voor welk "poortnummer" dat pakketje bedoeld is.
Met een firewall (logging daaruit) kun je zien dat specifieke pakketjes "binnenkomen op een gegeven poort". Niets belet je om software te maken die na één specifiek pakketje, of desgewenst een sequence, een poort open te zetten (bijv. door een firewall-regel toe te voegen waarmee toegang wordt verleend voor specifiek afzender IP-adres). Dat kan een andere "poort" zijn, of die "poort" zelf.
Voorbeeld: lang geleden heb ik een Atari ST gehad met een "Real time clock" module die je tussen één van de OS EPROM's en diens chipvoetje moest pluggen. Door een specifieke sequence van EPROM-adressen uit te lezen, kreeg de driver toegang tot de RTC chip (op dat moment moesten hardware-interrupts worden uitgezet om te voorkomen dat -op dat moment onbereikbare- OS routines aangeroepen zouden worden). Vergelijkbaar: de Commodore 64 had (heeft?) 64kB RAM en 2x 8KB ROM, maar kon slechts 64kB adresseren. Een (assembler/machinetaal) programmeur moest dus kiezen of hij de CPU beide ROM's wilde "laten zien" zoals gebruikelijk, of bijv. de "BASIC ROM" tijdelijk wilde uitschakelen, zodat de CPU het RAM-geheugen "onder" die ROM kon lezen en beschrijven.
Iets minder lang geleden heb ik speciale netwerksniffers geschreven die, werkend onder DOS, gebruik maakten van (toen voor DOS beschikbare) packet drivers (met een standaard API, en aan de andere kant ondersteuning voor een specifieke netwerkkaart). Uiteindelijk is een Ethernet netwerkpakketje niets anders dan een reeks bytes. Hoe die reeks wordt geïnterpreteerd, bepaalt de software daarachter. The sky is the limit.
Loool ik krijg antisec flashbacks van toen ze nog files van NASA servers af konden plukken omdat het simpelweg gewoon niet dicht stond. God wat zijn we eigenlijk als jonge hackers verwend met OWASPDoor Anoniem:
Erik, je antwoord is helaas onjuist.
Via een poort die dicht staat kom je niet naar binnen, er bestaan wel mechanismen om die poort van buitenaf te openen zodat je er wel door naar binnen kunt.
Poorten, IP-adressen en zelfs MAC-adressen zijn virtueel, dingen die we zo zijn gaan noemen om complexe materie te vereenvoudigen. Dat er "verderop" in het door jou gebruikte OS functionaliteit zit die UDP, TCP, ARP, ...pakketjes "begrijpt", betekent niet dat je geen mogelijkheden zou hebben om buiten de begaande paden te gaan.Door Erik van Straten:
Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?
Nee. Google: port knockingErik, je antwoord is helaas onjuist.
Via een poort die dicht staat kom je niet naar binnen, er bestaan wel mechanismen om die poort van buitenaf te openen zodat je er wel door naar binnen kunt.
Op een moderne "netwerkkaart" zit een Ethernet- of optische connector waarop serieel signaaltjes binnenkomen die eerst in bits en daarna in bytes worden omgezet. Op basis van bytes op specifieke offsets vanaf de eerste ontvangen byte "herkennen" we dat het bijv. om een IP pakketje gaat, en zo ja, of daarin bijv. een "TCP" pakketje zit, en zo ja, voor welk "poortnummer" dat pakketje bedoeld is.
Met een firewall (logging daaruit) kun je zien dat specifieke pakketjes "binnenkomen op een gegeven poort". Niets belet je om software te maken die na één specifiek pakketje, of desgewenst een sequence, een poort open te zetten (bijv. door een firewall-regel toe te voegen waarmee toegang wordt verleend voor specifiek afzender IP-adres). Dat kan een andere "poort" zijn, of die "poort" zelf.
Voorbeeld: lang geleden heb ik een Atari ST gehad met een "Real time clock" module die je tussen één van de OS EPROM's en diens chipvoetje moest pluggen. Door een specifieke sequence van EPROM-adressen uit te lezen, kreeg de driver toegang tot de RTC chip (op dat moment moesten hardware-interrupts worden uitgezet om te voorkomen dat -op dat moment onbereikbare- OS routines aangeroepen zouden worden). Vergelijkbaar: de Commodore 64 had (heeft?) 64kB RAM en 2x 8KB ROM, maar kon slechts 64kB adresseren. Een (assembler/machinetaal) programmeur moest dus kiezen of hij de CPU beide ROM's wilde "laten zien" zoals gebruikelijk, of bijv. de "BASIC ROM" tijdelijk wilde uitschakelen, zodat de CPU het RAM-geheugen "onder" die ROM kon lezen en beschrijven.
Iets minder lang geleden heb ik speciale netwerksniffers geschreven die, werkend onder DOS, gebruik maakten van (toen voor DOS beschikbare) packet drivers (met een standaard API, en aan de andere kant ondersteuning voor een specifieke netwerkkaart). Uiteindelijk is een Ethernet netwerkpakketje niets anders dan een reeks bytes. Hoe die reeks wordt geïnterpreteerd, bepaalt de software daarachter. The sky is the limit.
19-11-2020, 00:24 door
Erik van Straten
Door Anoniem: Het gaat over een poortscan en open/dichte poorten, als je dichte poorten zo makkelijk zou kunnen omzeilen dat zouden firewalls niet werken. Daar wil ik dan nog wel bewijs van zien dan.
Nogmaals, door een dichte poort kom je niet binnen.
Volgens mij begrijp je mij niet. Ik bedoel dat als een portscan "aantoont" dat een poort "dicht" zit, dit niet wil zeggen dat je die poort niet van buitenaf kunt "openen".Nogmaals, door een dichte poort kom je niet binnen.
Als de eigenaar van een device zelf software heeft geïnstalleerd die dat mogelijk maakt (wellicht omdat ie vreest binnenkort ontslagen te worden), of als er malware op die PC draait met zo'n backdoor, kun je die PC (met nmap of whatever) scannen tot je een ons weegt - zonder die backdoor te vinden.
Door Erik van Straten:
Als de eigenaar van een device zelf software heeft geïnstalleerd die dat mogelijk maakt (wellicht omdat ie vreest binnenkort ontslagen te worden), of als er malware op die PC draait met zo'n backdoor, kun je die PC (met nmap of whatever) scannen tot je een ons weegt - zonder die backdoor te vinden.
Door Anoniem: Het gaat over een poortscan en open/dichte poorten, als je dichte poorten zo makkelijk zou kunnen omzeilen dat zouden firewalls niet werken. Daar wil ik dan nog wel bewijs van zien dan.
Nogmaals, door een dichte poort kom je niet binnen.
Volgens mij begrijp je mij niet. Ik bedoel dat als een portscan "aantoont" dat een poort "dicht" zit, dit niet wil zeggen dat je die poort niet van buitenaf kunt "openen".Nogmaals, door een dichte poort kom je niet binnen.
Als de eigenaar van een device zelf software heeft geïnstalleerd die dat mogelijk maakt (wellicht omdat ie vreest binnenkort ontslagen te worden), of als er malware op die PC draait met zo'n backdoor, kun je die PC (met nmap of whatever) scannen tot je een ons weegt - zonder die backdoor te vinden.
Dit lijkt mij meer een verwarring wat bedoeld wordt met open/gesloten poort(/port).
In normaal taalgebruik spreekt men van een poort als er een applicatie reageert op het binnengekomen packet. Dit kan een native applicatie zijn of een service/daemon die een applicatie opstart en vervolgens verder het data verkeer verwerkt.
Als je met een nmap scant, dan kun je verkennen of op die poort data verkeer wordt gegenereerd. Dit kan zelfs in half-open connecties waardoor het lastig is om dit terug te vinden in loggegevens. Het kan zijn dat een firewall verkeer op deze poort niet doorlaat (drop statement), of filtered. Filtered wil zeggen dat de poort wel bestaat en actief is, maar dat de applicatie of firewall een close-connection statement genereert (bijvoorbeeld omdat een rule bestaat dat het alleen connecties accepteert van een bepaald domein).
Wat u (Erik) hierboven toevoegd is dat er backdoors bestaan die van buitenaf een applicatie opstarten middels een zgn. trigger, of dat er een applicatie van binnenuit wordt opgestart (bijvoorbeeld door een timer).
Er zijn tientallen manieren om een backdoor te verbergen. Denk aan bijvoorbeeld een malafide netstat i.c.m. een aangepast firewall script. Wat wel altijd zichtbaar is voor een sniffer op een systeem op hetzelfde netwerk is dat wanneer de backdoor actief is, er verkeer op het netwerk plaatsvindt. Daarom is het altijd belangrijk om het netwerk te monitoren op onbekend verkeer.
19-11-2020, 08:13 door
Erik van Straten
In aanvulling op mijn bijdrage van 00:24: wellicht is het "kortzichtig" van mij dat ik de vraag van de TS en Anoniem 13:28 vanuit defensief oogpunt interpreteerde.
Maar uiteindelijk heet deze site niet hacktic.nl, maar security.nl. En vormen het type backdoors dat ik bedoel, die ook in netwerkapparatuur (t/m netwerkkaarten/chips) kunnen zitten, een grote zorg van securityprofessionals - omdat ze lastig tot bijna onmogelijk te vinden zijn.
Maar uiteindelijk heet deze site niet hacktic.nl, maar security.nl. En vormen het type backdoors dat ik bedoel, die ook in netwerkapparatuur (t/m netwerkkaarten/chips) kunnen zitten, een grote zorg van securityprofessionals - omdat ze lastig tot bijna onmogelijk te vinden zijn.
Door Erik van Straten:
Als de eigenaar van een device zelf software heeft geïnstalleerd die dat mogelijk maakt (wellicht omdat ie vreest binnenkort ontslagen te worden), of als er malware op die PC draait met zo'n backdoor, kun je die PC (met nmap of whatever) scannen tot je een ons weegt - zonder die backdoor te vinden.
Door Anoniem: Het gaat over een poortscan en open/dichte poorten, als je dichte poorten zo makkelijk zou kunnen omzeilen dat zouden firewalls niet werken. Daar wil ik dan nog wel bewijs van zien dan.
Nogmaals, door een dichte poort kom je niet binnen.
Volgens mij begrijp je mij niet. Ik bedoel dat als een portscan "aantoont" dat een poort "dicht" zit, dit niet wil zeggen dat je die poort niet van buitenaf kunt "openen".Nogmaals, door een dichte poort kom je niet binnen.
Als de eigenaar van een device zelf software heeft geïnstalleerd die dat mogelijk maakt (wellicht omdat ie vreest binnenkort ontslagen te worden), of als er malware op die PC draait met zo'n backdoor, kun je die PC (met nmap of whatever) scannen tot je een ons weegt - zonder die backdoor te vinden.
Dus door een dichte poort kom je niet binnen, dat er mechanismen zijn om poorten van buitenaf te openen klopt, ik kan een mailtje naar mezelf sturen met een code en poortnummer erin en vervolgens gaat de poort open. Portknocking kan ook etc.
Het punt is dat je door een gesloten poort niet binnenkomt, je zult hemop wat voor manier dan ook moeten openen.
Door Erik van Straten: In aanvulling op mijn bijdrage van 00:24: wellicht is het "kortzichtig" van mij dat ik de vraag van de TS en Anoniem 13:28 vanuit defensief oogpunt interpreteerde.
Maar uiteindelijk heet deze site niet hacktic.nl, maar security.nl. En vormen het type backdoors dat ik bedoel, die ook in netwerkapparatuur (t/m netwerkkaarten/chips) kunnen zitten, een grote zorg van securityprofessionals - omdat ze lastig tot bijna onmogelijk te vinden zijn.
Maar uiteindelijk heet deze site niet hacktic.nl, maar security.nl. En vormen het type backdoors dat ik bedoel, die ook in netwerkapparatuur (t/m netwerkkaarten/chips) kunnen zitten, een grote zorg van securityprofessionals - omdat ze lastig tot bijna onmogelijk te vinden zijn.
Sportief !!
@Anoniem 13:33: dank!
Wat jij een geopende poort noemt is, vermoed ik (correcties welkom!), dat een "luisterend" proces het adres van een callback routine in een tabel van de TCP/IP stack heeft laten zetten, gekoppeld aan een specifiek poortnummer.
Daarmee weet de software achter die TCP/IP stack dat, als er een netwerkpakketje binnen is gekomen met daarin (op een specifieke offset in dat pakketje, nadat buitenste schillen ervan zijn afgepeld, zoals een mogelijke ethernet header) dat specifieke destination port nummer, dat de callback routine naar het luisterende proces moet worden aangeroepen - met als één van de parameters waarschijnlijk een pointer naar de juiste offset in het binnengekomen pakketje in RAM.
Dus ook als een poort dicht is, komen netwerkpakketjes wel eerst binnen, alleen worden ze (binnen het device) niet doorgestuurd naar een proces dat te kennen heeft gegeven dergelijke pakketjes te willen ontvangen. Van pakketjes die "niemand wil hebben" zeggen we dat ze worden "gedropt". D.w.z. dat de buffer (in het geheugen) met dat pakketje wordt vrijgegeven (waarbij zo'n buffer lang niet altijd wordt "gecleared" - maar dat is een ander verhaal).
De netwerkstack kan dan, naar keuze, bijv. een ICMP "port unreachable" pakketje terugsturen naar de kennelijke afzender van het ontvangen pakketje (waarbij al enige tijd bekend is dat je dat niet moet doen als het afzenderadres 255.255.255.255 is).
Gewetensvraag: stel een webserver luistert op poort 80. Stel ik configureer op die server een firewall die alle pakketjes bestemd voor poort 80 blokkeert indien het afzender-poortnummer oneven is (of bijv. het afzenderadres niet 10.11.12.13 is). Staat poort 80 op die server dan open of dicht? Of is het antwoord daarop "dat hangt ervan af"?
Nog zo'n vraag: stel op jouw smartphone luistert er niks op poort 2345. Jij surft naar security.nl waarbij jouw webbrowser toevallig poort 2345 als source port gebruikt. Staat de poort op jouw smartphone op dat moment dan open of niet?
Laatste vraag: voordat die websessie start doet jouw smartphone mogelijk een DNS request via UDP. Staat er dan een poort open voor een antwoord? En als dat antwoord even op zich laat wachten, hoe lang staat die poort dan open?
Door Anoniem: Het punt is dat je door een gesloten poort niet binnenkomt, je zult hemop wat voor manier dan ook moeten openen.
Mijn punt is dat het risico's met zich mee kan brengen door uitsluitend in abstracte "poorten" te denken.Wat jij een geopende poort noemt is, vermoed ik (correcties welkom!), dat een "luisterend" proces het adres van een callback routine in een tabel van de TCP/IP stack heeft laten zetten, gekoppeld aan een specifiek poortnummer.
Daarmee weet de software achter die TCP/IP stack dat, als er een netwerkpakketje binnen is gekomen met daarin (op een specifieke offset in dat pakketje, nadat buitenste schillen ervan zijn afgepeld, zoals een mogelijke ethernet header) dat specifieke destination port nummer, dat de callback routine naar het luisterende proces moet worden aangeroepen - met als één van de parameters waarschijnlijk een pointer naar de juiste offset in het binnengekomen pakketje in RAM.
Dus ook als een poort dicht is, komen netwerkpakketjes wel eerst binnen, alleen worden ze (binnen het device) niet doorgestuurd naar een proces dat te kennen heeft gegeven dergelijke pakketjes te willen ontvangen. Van pakketjes die "niemand wil hebben" zeggen we dat ze worden "gedropt". D.w.z. dat de buffer (in het geheugen) met dat pakketje wordt vrijgegeven (waarbij zo'n buffer lang niet altijd wordt "gecleared" - maar dat is een ander verhaal).
De netwerkstack kan dan, naar keuze, bijv. een ICMP "port unreachable" pakketje terugsturen naar de kennelijke afzender van het ontvangen pakketje (waarbij al enige tijd bekend is dat je dat niet moet doen als het afzenderadres 255.255.255.255 is).
Gewetensvraag: stel een webserver luistert op poort 80. Stel ik configureer op die server een firewall die alle pakketjes bestemd voor poort 80 blokkeert indien het afzender-poortnummer oneven is (of bijv. het afzenderadres niet 10.11.12.13 is). Staat poort 80 op die server dan open of dicht? Of is het antwoord daarop "dat hangt ervan af"?
Nog zo'n vraag: stel op jouw smartphone luistert er niks op poort 2345. Jij surft naar security.nl waarbij jouw webbrowser toevallig poort 2345 als source port gebruikt. Staat de poort op jouw smartphone op dat moment dan open of niet?
Laatste vraag: voordat die websessie start doet jouw smartphone mogelijk een DNS request via UDP. Staat er dan een poort open voor een antwoord? En als dat antwoord even op zich laat wachten, hoe lang staat die poort dan open?
Door Erik van Straten: @Anoniem 13:33: dank!
Geen dank ;-)
Door Anoniem: Het punt is dat je door een gesloten poort niet binnenkomt, je zult hemop wat voor manier dan ook moeten openen.
Mijn punt is dat het risico's met zich mee kan brengen door uitsluitend in abstracte "poorten" te denken.Wat jij een geopende poort noemt is, vermoed ik (correcties welkom!), dat een "luisterend" proces het adres van een callback routine in een tabel van de TCP/IP stack heeft laten zetten, gekoppeld aan een specifiek poortnummer.
En toegestaan door de firewall.
Daarmee weet de software achter die TCP/IP stack dat, als er een netwerkpakketje binnen is gekomen met daarin (op een specifieke offset in dat pakketje, nadat buitenste schillen ervan zijn afgepeld, zoals een mogelijke ethernet header) dat specifieke destination port nummer, dat de callback routine naar het luisterende proces moet worden aangeroepen - met als één van de parameters waarschijnlijk een pointer naar de juiste offset in het binnengekomen pakketje in RAM.
Dus ook als een poort dicht is, komen netwerkpakketjes wel eerst binnen, alleen worden ze (binnen het device) niet doorgestuurd naar een proces dat te kennen heeft gegeven dergelijke pakketjes te willen ontvangen. Van pakketjes die "niemand wil hebben" zeggen we dat ze worden "gedropt". D.w.z. dat de buffer (in het geheugen) met dat pakketje wordt vrijgegeven (waarbij zo'n buffer lang niet altijd wordt "gecleared" - maar dat is een ander verhaal).
Klopt dat het verkeer binnenkomt tot de firewall, anders zou een firewall nooit dropped of denied connections kunnen loggen.
De netwerkstack kan dan, naar keuze, bijv. een ICMP "port unreachable" pakketje terugsturen naar de kennelijke afzender van het ontvangen pakketje (waarbij al enige tijd bekend is dat je dat niet moet doen als het afzenderadres 255.255.255.255 is).
Gewetensvraag: stel een webserver luistert op poort 80. Stel ik configureer op die server een firewall die alle pakketjes bestemd voor poort 80 blokkeert indien het afzender-poortnummer oneven is (of bijv. het afzenderadres niet 10.11.12.13 is). Staat poort 80 op die server dan open of dicht? Of is het antwoord daarop "dat hangt ervan af"?
De poort staat dicht voor het betreffende verkeer wat aan de firewall rules voldoet en open voor het overige verkeer.
Nog zo'n vraag: stel op jouw smartphone luistert er niks op poort 2345. Jij surft naar security.nl waarbij jouw webbrowser toevallig poort 2345 als source port gebruikt. Staat de poort op jouw smartphone op dat moment dan open of niet?
Open maar alleen voor gerelateert verkeer, er kan geen nieuw proces van buitenaf geinitieerd worden wat door die poort 2345 naar binnen kan komen.
Laatste vraag: voordat die websessie start doet jouw smartphone mogelijk een DNS request via UDP. Staat er dan een poort open voor een antwoord? En als dat antwoord even op zich laat wachten, hoe lang staat die poort dan open?
Eigenlijk vergelijkbaar antwoord met hierboven.
Mij ging het in dit topic er om om de vraag van TS proberen te beantwoorden in simpele bewoordingen.
Als mijn auto niet start omdat de startmotor niet rond gegooid kan worden roep ik dat de accu leeg is.
Dat is totaal onjuist op meerdere[1] fronten maar toch begrijpt iedereen me.
[1]
De accu is gevuld met een vloeistof (accuzuur), loodcellen en nog wat zooi, dus niet leeg.
Qua capaciteit/lading ook onjuist omdat er nog steeds sprake is van een bepaalde capaciteit maar niet voldoende om de startmotor rond te gooien.
19-11-2020, 20:27 door
Erik van Straten
@Anoniem 19:17: OK! De enige vraag die ik nog heb is aan de TS: met welke kleur hoed op wil je die poortscan uitvoeren?
19-11-2020, 20:57 door
MathFox
@Anoniem 19:17: Het is niet moeilijk om met een gespoofd afzender adres op UDP nivo in een UDP sessie in te breken als je de poortnummers aan beide kanten kent. Werd gedaan in "DNS poisoning" aanvallen. https://nl.wikipedia.org/wiki/DNS-vergiftiging
Door Erik van Straten: @Anoniem 19:17: OK! De enige vraag die ik nog heb is aan de TS: met welke kleur hoed op wil je die poortscan uitvoeren?
Rood! ;) Met een blauwe baret! ;)Door MathFox: @Anoniem 19:17: Het is niet moeilijk om met een gespoofd afzender adres op UDP nivo in een UDP sessie in te breken als je de poortnummers aan beide kanten kent. Werd gedaan in "DNS poisoning" aanvallen. https://nl.wikipedia.org/wiki/DNS-vergiftiging
Door Erik van Straten: @Anoniem 19:17: OK! De enige vraag die ik nog heb is aan de TS: met welke kleur hoed op wil je die poortscan uitvoeren?
Rood! ;) Met een blauwe baret! ;)RHCA die gediend heeft voor de VN?
19-11-2020, 22:14 door
Erik van Straten
@Mathfox: tenzij ik erover heen gelezen heb, noch security.nl, noch tweakers.net heeft aandacht geschonken aan een nieuwe methode voor DNS Cache Poisoning, die "SAD DNS" gedoopt is. Deze aanval (op met name Linux DNS servers) weet de fixes te omzeilen die na de eerste ontdekking van dit soort aanvallen (Dan Kaninsky, 2008) in de meeste besturingssystemen zijn geïmplementeerd: https://www.saddns.net/.
Als ik nu de huidige door mij gebruikte DNS-server laat checken, begint het resultaat met:
Meer info (naast genoemde site zelf), bijv.
https://www.sidn.nl/nieuws-en-blogs/sad-dns-nieuwe-dns-cache-poisoning-aanval-ontdekt
https://blog.cloudflare.com/sad-dns-explained/
https://blog.nlnetlabs.nl/sad-dns-side-channel-attack-and-unbound/
Of het een gevolg is van deze aanval weet ik niet, maar vanmiddag meldde https://www.nu.nl/tech/6091536/onderdeel-site-van-joe-biden-met-turkse-teksten-beklad.html dat https://vote.joebiden.com/ gedefaced was (ik kon dat reproduceren). Volgens https://isc.sans.edu/tools/dnslookup.html waren de IPv4 adressen voor Nederland op dat moment:
Momenteel resolvt vote.joebiden.com in geen enkel land (voor zover gecheckt door sans.edu).
P.S. Ik hintte vorige week al op deze SAD DNS attack in https://www.security.nl/posting/677448/Is+een+digitale+handtekening+wel+altijd+rechtsgeldig%3F#posting677682 maar ofwel de redactie leest niet al mijn bijdragen :-) ofwel ze vonden deze kwetsbaarheid niet interessant genoeg :-(
Als ik nu de huidige door mij gebruikte DNS-server laat checken, begint het resultaat met:
Your DNS server IP is 194.109.133.199
Since it blocks outgoing ICMP packets, your DNS server is not vulnerable.
Maar ik heb ook DNS-servers voorbij zien komen die mogelijk wel kwetsbaar zijn.Since it blocks outgoing ICMP packets, your DNS server is not vulnerable.
Meer info (naast genoemde site zelf), bijv.
https://www.sidn.nl/nieuws-en-blogs/sad-dns-nieuwe-dns-cache-poisoning-aanval-ontdekt
https://blog.cloudflare.com/sad-dns-explained/
https://blog.nlnetlabs.nl/sad-dns-side-channel-attack-and-unbound/
Of het een gevolg is van deze aanval weet ik niet, maar vanmiddag meldde https://www.nu.nl/tech/6091536/onderdeel-site-van-joe-biden-met-turkse-teksten-beklad.html dat https://vote.joebiden.com/ gedefaced was (ik kon dat reproduceren). Volgens https://isc.sans.edu/tools/dnslookup.html waren de IPv4 adressen voor Nederland op dat moment:
Netherlands 13.32.240.102
Netherlands 13.32.240.101
Netherlands 13.32.240.34
Netherlands 13.32.240.121
Netherlands 13.32.240.101
Netherlands 13.32.240.34
Netherlands 13.32.240.121
P.S. Ik hintte vorige week al op deze SAD DNS attack in https://www.security.nl/posting/677448/Is+een+digitale+handtekening+wel+altijd+rechtsgeldig%3F#posting677682 maar ofwel de redactie leest niet al mijn bijdragen :-) ofwel ze vonden deze kwetsbaarheid niet interessant genoeg :-(
20-11-2020, 00:16 door
MathFox
Door Erik van Straten: @Mathfox: tenzij ik erover heen gelezen heb, noch security.nl, noch tweakers.net heeft aandacht geschonken aan een nieuwe methode voor DNS Cache Poisoning, die "SAD DNS" gedoopt is. Deze aanval (op met name Linux DNS servers) weet de fixes te omzeilen die na de eerste ontdekking van dit soort aanvallen (Dan Kaninsky, 2008) in de meeste besturingssystemen zijn geïmplementeerd: https://www.saddns.net/.
[...]
P.S. Ik hintte vorige week al op deze SAD DNS attack in https://www.security.nl/posting/677448/Is+een+digitale+handtekening+wel+altijd+rechtsgeldig%3F#posting677682 maar ofwel de redactie leest niet al mijn bijdragen :-) ofwel ze vonden deze kwetsbaarheid niet interessant genoeg :-(
Dank voor de link, ik heb de pdf gedownload en ga die verder doorlezen. Ziet er interessant uit.[...]
P.S. Ik hintte vorige week al op deze SAD DNS attack in https://www.security.nl/posting/677448/Is+een+digitale+handtekening+wel+altijd+rechtsgeldig%3F#posting677682 maar ofwel de redactie leest niet al mijn bijdragen :-) ofwel ze vonden deze kwetsbaarheid niet interessant genoeg :-(
De redactie moet keuzes maken in wat ze op de hoofdpagina zet. Voor deze aanval geldt dat de patch al uitgerold is.
Door MathFox:
Door Anoniem:
Nee, er is een programma op de computer dat een poort opent.Door MathFox: Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
De beheerder van de computer (of firewall) zegt "Dit is geen speelterrein" tegen scriptkiddies.Wat betekent filtered concreet?
Door Anoniem:
Wat betekent filtered concreet?
Door MathFox:
Door Anoniem:
Nee, er is een programma op de computer dat een poort opent.Door MathFox: Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
De beheerder van de computer (of firewall) zegt "Dit is geen speelterrein" tegen scriptkiddies.Wat betekent filtered concreet?
Filtered betekent dat het packet wel is ontvangen en er wordt door de interface gereageerd. Bijvoorbeeld, de TCP handshake wordt wel opgepakt (Syn/Ack), maar verder stopt de communicatie. Of dat de poort een reset connection message stuurt.
Door Anoniem:
Wat betekent filtered concreet?
Lees dan en kap met mensen pesten: https://www.google.com/search?q=nmap+filtered+portsDoor MathFox:
Door Anoniem:
Nee, er is een programma op de computer dat een poort opent.Door MathFox: Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
De beheerder van de computer (of firewall) zegt "Dit is geen speelterrein" tegen scriptkiddies.Wat betekent filtered concreet?
Wat betekent filtered concreet?
Onderstaande link geeft geen concreet antwoord zoals jij volgens mij bedoeld maar het geeft wel een voorbeeld over poort filtered.
https://pcmweb.nl/artikelen/security/firewall-poorten-scannen-hoe-en-waarom/
Door Anoniem:
Wat betekent filtered concreet?
Door MathFox:
Door Anoniem:
Nee, er is een programma op de computer dat een poort opent.Door MathFox: Een poort is in veel gevallen simpel te openen van binnen naar buiten.
Ja maar nooit van buiten naar binnen toch?Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?
De beheerder van de computer (of firewall) zegt "Dit is geen speelterrein" tegen scriptkiddies.Wat betekent filtered concreet?
leer te zoeken ?
https://nmap.org/book/man-port-scanning-basics.html
The six port states recognized by Nmap
open
An application is actively accepting TCP connections, UDP datagrams or SCTP associations on this port. Finding these is often the primary goal of port scanning. Security-minded people know that each open port is an avenue for attack. Attackers and pen-testers want to exploit the open ports, while administrators try to close or protect them with firewalls without thwarting legitimate users. Open ports are also interesting for non-security scans because they show services available for use on the network.
closed
A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then they would appear in the filtered state, discussed next.
filtered
Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically.
unfiltered
The unfiltered state means that a port is accessible, but Nmap is unable to determine whether it is open or closed. Only the ACK scan, which is used to map firewall rulesets, classifies ports into this state. Scanning unfiltered ports with other scan types such as Window scan, SYN scan, or FIN scan, may help resolve whether the port is open.
open|filtered
Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.
closed|filtered
This state is used when Nmap is unable to determine whether a port is closed or filtered. It is only used for the IP ID idle scan.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
