RootUsers

De meesten van ons zijn bekend met het eenvoudige op ICMP gebaseerde ‘ping’ commando dat ons in staat stelt om te testen op een basisreactie van een netwerk verbonden apparaat. Hoewel geweldig voor eenvoudige probleemoplossing, kunnen we niet bevestigen of de specifieke host aan de andere kant reageert op TCP-of UDP-poorten waar de meeste services waarschijnlijk worden geleverd.,

Ping is niet de be all and end all van netwerk problemen oplossen, als een firewall blokkeert inkomend ICMP verkeer dan zal een ping niet slagen die een valse perceptie kan produceren dat de host is down Omdat het niet reageert op de ping, maar andere diensten kunnen nog steeds reageren prima.

als alternatief, hoewel ping prima kan terugkomen met een antwoord, geeft het niet aan of een webserver reageert op poort 80 voor HTTP-verzoeken, kan de webserver mislukt zijn en niet langer reageren.

als ping ICMP-gebaseerd is, kunnen we dan een TCP-of UDP-poort gebruiken om te reageren?, Het antwoord is ja, laten we eens kijken.

Enter tcping

tcping is een dergelijke tool die kan worden gebruikt om te controleren of een TCP-poort reageert, er zijn een paar versies beschikbaar, maar ik gebruik deze: http://www.elifulkerson.com/projects/tcping.php

de handleiding staat op dezelfde pagina, in principe kunt u een commando uitvoeren zoals hieronder.

Hier gebruiken we tcping om poort 443 te controleren op google.com zoals te zien is, wordt de poort weergegeven als open en reageert, als de poort niet open is, wordt deze standaard weergegeven als geen antwoord na 2000ms.,

u kunt telnet ook gebruiken om TCP-connectiviteit met een poort te testen, maar het tcping-gereedschap biedt verdere functies zoals beschreven in de sectie Gebruik hier. Sommige van dergelijke functies omvatten de mogelijkheid om voortdurend uitvoeren van de test waardoor een manier om verkeer te genereren voor u om op te letten in live packet captures evenals de responstijd.

hoe zit het met UDP?

omdat UDP een verbindingsloos protocol is, is het bepalen of het reageert een beetje anders., Een TCP ‘ping’ werkt door het uitvoeren van een three way hand shake, de bron zal een SYN naar de bestemming sturen, de bestemming zal antwoorden met een SYN-ACK, en de bron zal dan een ACK sturen die de handshake voltooit en de verbinding tot stand brengt. Omdat UDP geen verbinding tot stand brengt, kunnen we hier niet alleen naar Zoeken om te bepalen of de poort reageert, maar moeten we in plaats daarvan specifieke gegevens verzenden en zien of we een reactie ontvangen.

NMAP is hiervoor een geweldig hulpmiddel, je kunt het downloaden en het gebruiken om een doeladres te scannen om te bepalen welke poorten geopend zijn.,

in dit voorbeeld vragen we of 8.8.8.8 reageert op UDP poort 53, omdat het DNS bedient zouden we verwachten dat het open is.

het Open / gefilterde resultaat wordt gebruikt wanneer nmap niet in staat is om te bepalen of de poort open of gefilterd is, de open poort heeft mogelijk geen antwoord gegeven. Het toont aan dat de service is geïdentificeerd als ‘domein’ als het is voor het dienen van DNS. Ik heb dit getest op een aantal andere DNS-servers op het Internet en sommige laten zien als open alleen te bevestigen dat ze reageren.

NMAP kan ook worden gebruikt om te controleren of een TCP-poort op dezelfde manier open is, verander gewoon-sU in-sT.,

waarom een poort mogelijk niet reageert

er zijn een paar eenvoudige redenen dat een poort mogelijk niet reageert op uw test.

• een firewall blokkeert het verkeer: er kan een firewall draaien tussen de bron en de bestemming die het verkeer filtert, afhankelijk van de regels, zelfs als u weet dat de bestemming op een bepaalde poort moet reageren.
• de bestemming luistert mogelijk niet op de poort: simpel gezegd, de bestemming waarmee u probeert te verbinden heeft mogelijk geen diensten die luisteren op de poort opgegeven, dus er zal geen antwoord zijn., Dit kan ook gebeuren als een service gestopt is, bijvoorbeeld als je Apache stopt, zal een webserver niet langer reageren op port 80 Verzoeken.
• Er is een ander netwerkprobleem tussen de bron en de bestemming van het verkeer: er kunnen een aantal netwerkverbindingsproblemen zijn tussen de bron en de bestemming, indien mogelijk controleer het netwerk, maar als het verkeer het Internet doorkruist, zult u beperkt zijn in wat u kunt controleren.,

u kunt de connectiviteit langs het pad van het verkeer controleren door een packet capture uit te voeren met iets als Wireshark of tcpdump, dit zal u laten zien waar het verkeer doorheen gaat en waar het wordt gestopt langs de route. U kunt het uitvoeren op de bron-en doelservers, evenals apparaten daartussen waar u toegang tot hebt, zoals firewalls of routers. Volg de doorstroming van het verkeer totdat u bepaalt waar het probleem is.,

samenvatting

tijdens het uitvoeren van een TCP ‘ping’ naar een bestemming kunt u bevestigen of het reageert zoals bedoeld, hoewel er een paar redenen zijn waarom de poort niet reageert zoals aangegeven. UDP kan worden gecontroleerd, maar het is een beetje moeilijker om zeker te zijn als je correct ontvangt een reactie, zodat de tests zijn niet altijd betrouwbaar, wat logisch is als UDP is niet een betrouwbaar protocol. Deze tests kunnen nuttig zijn bij het testen van de beveiliging door te bevestigen of poorten open of gesloten zijn.