Door Anoniem: Wat is het nut van het uitvoeren van een Poortscan?

Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?

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.

Door MathFox: syntax error reinterpretation
Een poort is in veel gevallen simpel te openen van binnen naar buiten.

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 Anoniem:
Ja maar nooit van buiten naar binnen toch?
Dus als een poortscan aangeeft dat alle poorten filtered zijn, wat houdt dat in?

Door Anoniem: Dus als een poort dicht is betekent het dat je er niet via die voort naar binnen kunt?

Door Erik van Straten: Nee. Google: port knocking

Door MathFox: syntax error reinterpretation
Een poort is in veel gevallen simpel te openen van binnen naar buiten.

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 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:
[knip]
The sky is the limit.

Door Erik van Straten: 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.

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 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.

Door Erik van Straten: 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".

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: 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".

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: 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.

Door Anoniem: 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: @Anoniem 13:33: dank!

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 19:17: OK! De enige vraag die ik nog heb is aan de TS: met welke kleur hoed op wil je die poortscan uitvoeren?

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

Rood! ;) Met een blauwe baret! ;)

Your DNS server IP is 194.109.133.199
Since it blocks outgoing ICMP packets, your DNS server is not vulnerable.

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 :-(

Door MathFox: Nee, er is een programma op de computer dat een poort opent.
De beheerder van de computer (of firewall) zegt "Dit is geen speelterrein" tegen scriptkiddies.

Door Anoniem:
Wat betekent filtered concreet?

Door Anoniem:
Wat betekent filtered concreet?

Wat betekent filtered concreet?

Door Anoniem:
Wat betekent filtered concreet?

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.