ICMP internals - Ping tracert

Σελ. 1 από 5

Αψογο αρθρο

Κι άλλο ένα τρομερό άρθρο του drhouse. Μπράβο σου.

Αρχικό μήνυμα από drhouse

Στην πραγματικότητα η παράμετρος TTL σχετίζεται και με hopping και με time.
Ξεκινάει με hooping.
Η TTL αλλάζει ρόλο την στιγμή που φθάνει το πρώτο fragmented packet.
Ας υποθέσουμε πως σε ένα client φθάνει το πρώτο fragmented packet και ότι αυτό έχει TTL = Ν, (από εδώ και στο εξής η τιμή Ν παίζει τον ρόλο των seconds). Το χρονικό διάστημα μέσα στο οποίο θα γίνει το reassembly των φραγμεντς είναι Ν seconds. Αν δεν έλθουν όλα τα fragment σε Ν seconds τότε το ICMP θα επιτρέψει το μήνυμα Fragment reassembly time exceeded.

Παρόλο που αυτό που αναφέρεις ορίζεται στο αρχικό specification του ip, στην πορεία έχει αλλάξει (δεν θυμάμαι το rfc αυτή τη στιγμή) και το reassembly timeout ορίζεται σαν σταθερή τιμή από το ίδιο το stack (ή από τον χρήστη) και δεν πρέπει να παίρνει την τιμή του TTL.
Λογικό, γιατί δεν υπάρχει λόγος να έχεις το ίδιο reassembly timeout σε δύο διαφορετικά links (με διαφορετικό latency) που τυγχάνει να έχουν το ίδιο αριθμό hops μεταξύ τους.

Ωραίο άρθρο

Αρχικό μήνυμα από karavagos

Παρόλο που αυτό που αναφέρεις ορίζεται στο αρχικό specification του ip, στην πορεία έχει αλλάξει (δεν θυμάμαι το rfc αυτή τη στιγμή) και το reassembly timeout ορίζεται σαν σταθερή τιμή από το ίδιο το stack (ή από τον χρήστη) και δεν πρέπει να παίρνει την τιμή του TTL.
Λογικό, γιατί δεν υπάρχει λόγος να έχεις το ίδιο reassembly timeout σε δύο διαφορετικά links (με διαφορετικό latency) που τυγχάνει να έχουν το ίδιο αριθμό hops μεταξύ τους.

Ωραίο άρθρο

Κατ' αρχήν ευχαριστώ για τα καλά σας λόγια.

Όπως τα λες θα πρέπει να είναι, γιατί αλλο είναι να γίνεται fragmentation reassembly με TTL=250
και άλλο με TTL=5 καθόλου δίκαιο.

Συγχαρητήρια και από μένα από το άρθρο (έστω και καθυστερημένα)
Θα ήθελα αν μπορείς να μου πεις ποιο είναι το πρόγραμμα που χρησιμοποιείς για την ανάλυση των πακέτων (αυτό που φαίνεται και στις εικόνες). Μου φαίνεται πολύ καλό...
Επίσης μου φαίνεται εξαιρετικά παράξενο, πως η περιβόητη επίθεση των root servers βασίστηκε μόνο σε συνδυασμούς TYPE/CODE τα οποία και αποτελούν τον πυρήνα του ICMP.
Δεν είμαι χακεράς ούτε σκοπεύω να γίνω, απλά μου κάνει εντύπωση πως ένα τόσο απλό στην δομή του πακέτο μπορεί να προκελάσει τόσο μεγάλης έκτασης πρόβλημα

Αρχικό μήνυμα από darist

Θα ήθελα αν μπορείς να μου πεις ποιο είναι το πρόγραμμα που χρησιμοποιείς για την ανάλυση των πακέτων (αυτό που φαίνεται και στις εικόνες). Μου φαίνεται πολύ καλό...

Όλα τα προγράμματα τύπου protocol analyzers κάνουν πάνω κάτω τα ίδια πράγματα.
Αυτό που είναι σημαντικό είναι η δομή των πρωτοκόλλων και όχι ο αναλυτής κατά την ταπεινή μου γνώμη.

Οι εικόνες είναι από το WireShark aka etheal.

Αρχικό μήνυμα από darist

Επίσης μου φαίνεται εξαιρετικά παράξενο, πως η περιβόητη επίθεση των root servers βασίστηκε μόνο σε συνδυασμούς TYPE/CODE τα οποία και αποτελούν τον πυρήνα του ICMP.

Σκλέψου το ως εξής.

Το ICMP είναι ο επίσημος ταχυδρόμος, κάτι σαν τον ΕΡΜΗ και τους θεούς του Ολυμπου, στο TCP/IP Stack. Όταν ένας θεός ήθελε να στήλει ένα μήνυμα, το έδτελνε με τον ΕΡΜΗ.
Είναι ο μάγκας που εμπιστεύονται όλα τα μέρη (πρωτόκολλα) του TCP/IP Stack΄.

Λογικό λοιπόν είναι μιας και τον ΕΡΜΗ τον εμπιστεύονται όλοι να επιχειρηθεί κάποια στιγμή επίθεση με αυτόν.

Επέτρεψέ μου να αναφέρω πως αυτοί οι αναλυτές είναι καταπληκτικά εργαλεία και μπορεί να βοηθήσουν ένα τεχνικό σε πολλές περιπτώσεις, ακόμα και στην περίπτωση που ένας υπολογιστή δουλεύει αργά, εκκινεί αργά ...

Κάνοντας BaseLine analysis στα πακέτα που κυκλοφορούν μεσα στο τοπικό σου δίκτυο όταν όλα πάνε καλά μπορεί να σε βοηθήσει να βρείς προβλήματα όταν τα πράγματα στραβώσουν.

Αν κάνεις BaseLine analysis στην διαδικασία εκκίνησης / log on έχεις στοιχεία για να συγκρίνεις σε περίπτωση που ένα υπολογιστή δεν ξεκινάει γρήγορα, πολλές φορές η αιτία σε τέτοιες καταστάσεις είναι η πρόσβαση στο δίκτυο, θακυστερήσεις που ωφείλονται σε DHCP server ... με τον αναλυστή στο πλάι ΔΕΝ ΥΠΟΨΙΑΖΕΣΑΙ το πρόβλημα ΤΟ ΒΛΕΠΕΙΣ.

Στπέλνοντας τέτοια δεδομένα σε ένα κατασκευαστή λογισμικού, πάροχο μπορείς να βοηθήσεις με αποδείξεις στην λύση του όποιου προβλήματος.

Συγνωμη και πάλι για την μονολογία.

Thanks Dr. για τις πληροφορίες. Φαίνεται ότι το έχεις σπουδάσει το άθλημα...

Ο λόγος που αναρωτιέμαι για τις επιθέσεις τύπου ICMP είναι ότι τα πακέτα πέρα των τύπων/κωδικών, ip addresses, checksum και λοιπών βασικών πληροφοριών, δεν περιέχουν πραγματικά δεδομένα όπως των πακέτων των TCP και UDP datagrams. Διόρθωσέ με αν κάνω λάθος, αλλά και στα txt αρχεία που αναφέρεις στο άρθρο σου τα μόνα data που βρήκα στο ICMP datagram απλά αντιγράφονται κι επιστρέφονται όπου είναι απαραίτητο (πχ. ECHO request & reply). Σε άλλου τύπου επιθέσεις προσπαθείς να κρασάρεις ένα service (οτιδήποτε κι αν είναι αυτό) στέλνοντάς του δεδομένα που δεν ξέρει πως να τα χειριστεί. Δεν ξέρω αν με πιάνεις αλλά απ' αυτά που καταλαβαίνω (και πάλι λέω ότι μπορεί να κάνω λάθος) είναι πως ο Ερμής που αναφέρεις κουβαλάει άδεια μηνύματα. Πως άραγε γίνεται να δημιουργήσεις πρόβλημα χωρίς να στελνεις δεδομένα?

Σκεφτόμουν να κάνω αυτό ακριβώς που είπες (BaseLine analysis) γι' αυτό σε ρώτησα για το πρόγραμμα που χρησιμοποιείς. Δεν έχω κάποιο πρόβλημα, απλά από περιέργεια. Το μόνο που αναρωτιέμαι είναι αν το δίκτυο χρησιμοποιεί switch για να συνδέσει τους υπολογιστές εγώ με τον analyzer θα βλέπω μόνο ότι περνάει από τον υπολογιστή μου? Ή μπορώ να δω τι κινείται σε ολόκληρο το δίκτυο?

Thanks και πάλι...

Αρχικό μήνυμα από darist

Ο λόγος που αναρωτιέμαι για τις επιθέσεις τύπου ICMP είναι ότι τα πακέτα πέρα των τύπων/κωδικών, ip addresses, checksum και λοιπών βασικών πληροφοριών, δεν περιέχουν πραγματικά δεδομένα όπως των πακέτων των TCP και UDP datagrams. Διόρθωσέ με αν κάνω λάθος, αλλά και στα txt αρχεία που αναφέρεις στο άρθρο σου τα μόνα data που βρήκα στο ICMP datagram απλά αντιγράφονται κι επιστρέφονται όπου είναι απαραίτητο (πχ. ECHO request & reply). Σε άλλου τύπου επιθέσεις προσπαθείς να κρασάρεις ένα service (οτιδήποτε κι αν είναι αυτό) στέλνοντάς του δεδομένα που δεν ξέρει πως να τα χειριστεί. Δεν ξέρω αν με πιάνεις αλλά απ' αυτά που καταλαβαίνω (και πάλι λέω ότι μπορεί να κάνω λάθος) είναι πως ο Ερμής που αναφέρεις κουβαλάει άδεια μηνύματα. Πως άραγε γίνεται να δημιουργήσεις πρόβλημα χωρίς να στελνεις δεδομένα?

To ICMP πράματι δεν κουβαλάει πολλα "δεδομένα".
Επειδή όμως είναι αναγκαίο για το TCP/IP γι' αυτό και το χρησιμοποίησαν σε επίθεση τύπου DDoS Attack.

Για περισσότερες πληροφορίες ψάξε στον γογλη DDoS Attack Hit DNS Root Servers
και θα βρείς πολλές πληροφορίες.

Massive DDoS Attack Hit DNS Root Servers

Με το ICMP μπορείς να μάθεις πολλά για ένα υπολογιστή, να μάθεις π.χ τι υπηρεσίες UDP τρέχουν, να αναγνωρίσεις το λειτουργικό που έχει, ακόμα και τα routing tables μερικές φορές μπορείς να πειράξεις ...

Το μόνο που αναρωτιέμαι είναι αν το δίκτυο χρησιμοποιεί switch για να συνδέσει τους υπολογιστές εγώ με τον analyzer θα βλέπω μόνο ότι περνάει από τον υπολογιστή μου? Ή μπορώ να δω τι κινείται σε ολόκληρο το δίκτυο?

Οι αναλυτές αυτοί εργαζόντουσαν πολλοί καλά στα HUBed networks (ακούς τα πάντα).
Στα HUBed networks, έχουμε ένα ενοιαίο Broadcast Domain, έτσι όταν μιλάει ένας υπολογιστής μπορούν να τον ακούν όλοι. Στην πραγματικότητα όταν ένας υπολογιστής στέλνει ένα πακέτο αυτό φθάνει σε όλους τους υπολογιστες, όλοι το παραλαμβάνουν το ανοίγουν και βλέπουν αν έχει σταλεί σε αυτούς. Όπως καταλαβαίνεις αν μιλάμε για unicast packet, ολοι πλην ενός θα ασχοληθούν με αυτό και τέλος θα το απορίψουν (όλοι πλην ενός θα ασχοληθούν με αυτό), μόνο ένας θα το διαβάσει ολοκληρωτηκά.

Τα πράγματα δυσκόλεψαν λιγάκι με τα δίκτυα που χρησιμοποιούν switches και routers.
Οι συσκευές αυτές άλλωστες αυτός ήταν και ένας από τους σκοπούς τους φιλτράρουν την κυκλοφορία στο δίκτυο, οι routers κόβουν το broadcasting, έτσι θα πρεπει να είσαι προσεκτικότερος.

Σου προτείνω να βρείς (λιγάκι δύσκολα σήμερα) ένα hub και να βάζεις εκεί πάνω τον υπολογιστή που θέλεις να μελετήσεις με τον αναλύτή σου.

Σε μερικά switch μπορείς να κάνεις port spanning ή mirroring. Με την διαδικασία αυτή ρυθμίζεις το Switch να στέλνει τα πακέτα που φθάνουν σε μια πόρτα και στην πόρτα που έχεις τοποθετήσει τον αναλυτή σου. Υποπτεύομαι πως ο karavagos θα μπορούσε να μας πει περισσότερα.

Υ.Γ Αν οι admins το επιτρέπουν θα μπορούσαμε να ανοίξουμε καλή συζήτηση για διάφορα τέτοια εργαλεία, με σκοπό την μάθηση και προφύλαξή "μας".

Οι αναλυτές αυτοί εργαζόντουσαν πολλοί καλά στα HUBed networks (ακούς τα πάντα).
Στα HUBed networks, έχουμε ένα ενοιαίο Broadcast Domain, έτσι όταν μιλάει ένας υπολογιστής μπορούν να τον ακούν όλοι.

Collision domain θες να πεις φαντάζομαι

Σε μερικά switch μπορείς να κάνεις port spanning ή mirroring. Με την διαδικασία αυτή ρυθμίζεις το Switch να στέλνει τα πακέτα που φθάνουν σε μια πόρτα και στην πόρτα που έχεις τοποθετήσει τον αναλυτή σου. Υποπτεύομαι πως ο karavagos θα μπορούσε να μας πει περισσότερα.

Ο απλός τρόπος είναι να βάλεις την κάρτα δικτύου σου σε promiscuous mode, στο οποιο όταν λαμβάνει πακέτα για τα οποια δεν είναι αυτή ο προορισμός, δεν τα κάνει drop αμέσως. Ανάλογα το μέγεθος και την τοπολογία του δικτύου, υπάρχει περίπτωση να μπορείς να δεις ένα αρκετά συμπαθητικό ποσοστό της κίνησης έτσι.

Με port mirroring (λες στο switch οτιδήποτε frames λαμβάνει στο/α X ports, τα τα κάνει forward και στο/α Y) μπορείς να έχεις αρκετά μεγαλύτερη ακρίβεια, εφόσον το bandwidth επαρκεί για κάτι τέτοιο.

Επίσης, υπάρχει και η δυνατότητα να έχεις ένα μηχάνημα (με 2+ κάρτες δικτύου) ανάμεσα στα σημεία που επιθυμείς να παρακολουθήσεις και να κάνεις in-line sniffing από αυτό.

Off Topic

Βασικά, σε switch ότι και να κάνεις (π.χ. promiscuous), θα λαμβάνεις από default μόνο τα L2/L3 broadcast (αν και μπορείς να κάνεις διάφορα κόλπα μέσω arp spoofing). Αν καταφέρεις να κάνεις το switch να μεταφράζει "όλα" τα unknown unicast σε L2 broadcast (π.χ. μηδενίζοντας το aging των mac-addresses ή περιορίζοντας το πλήθος τους στην πόρτα προορισμού), τότε μπορείς να έχεις σχεδόν όλη την πληροφορία (όπως και όλες οι πόρτες του ίδιου broadcast domain). Διαφορετικά χρειάζεται το "κατ'ορολογία Cisco" SPAN (Switched Port Analyzer) ή κάτι αντίστοιχο, προκειμένου να λάβεις ακριβές αντίγραφο της κίνησης.

Btw, σε δίκτυο με hub, broadcast & collision domain ταυτίζονται.

Αρχικό μήνυμα από Someonefromhell

Collision domain θες να πεις φαντάζομαι

Στα HUBed networks ενιαίο Collision domain & broadcast domain.
Κάνει προυτς το ένα PC και το ακούνε όλα.

Συγγνωμη που ξεθαβω το θεμα, εχω καποιες ερωτησεις-αποριες σχετικα με το παρακατω. Ζητείται η βοήθειά του Δοκτορα η οποιουδήποτε αλλου που γνωρίζει..

ICMP 9 και 10
Σε μερικές περιπτώσεις, ένα client pc δεν του αρέσει η IP που του δίνει ένας router, σε αυτή την περίπτωση μπορεί να κάνει triggering με ένα πακέτο την διαδικασία ICMP-> router solicitation. Σε αυτή την περίπτωση αν στο δίκτυο έχει ρυθμιστεί κατάλληλα κάποιο κουτί για να απαντήσει, αυτό θα απαντήσει με ICMP->Router advertisement.

RFC 1256, page 3.

The ICMP router discovery messages are called "Router Advertisements" and "Router Solicitations". Each router periodically multicasts a Router Advertisement from each of its multicast interfaces, announcing the IP address(es) of that interface. Hosts discover the addresses of their neighboring routers simply by listening for advertisements. When a host attached to a multicast link starts up, it may multicast a Router Solicitation to ask for immediate advertisements, rather than waiting for the next periodic ones to arrive; if and only if no advertisements are forthcoming, the host may retransmit the solicitation a small number of times, but then must desist from sending any more solicitations.

Δεν μπορω να καταλάβω σε τι διαφέρει το Router Advertisement απο ενα ARP request η απο ενα Reverse ARP (εκτος οτι το ΑRP ειναι Link Layer και το ICMP Internet Layer).

Γιατι πχ στο δικτυο μου δεν εχω δει ΠΟΤΕ ενα Router Advertisement οταν κανω reboot το router;

ευχαριστω

Κατ’ αρχήν αγαπητέ φιλαράκο, συγνώμη για την καθυστέρηση της απάντησής μου, δυστυχώς ο ελεύθερος χρόνος μου αυτή την περίοδο είναι αρκετά περιορισμένος, και μπαίνω αμέσως στο ψητό.

Για να καταλάβεις την διαφορά ανάμεσα στο ARP και στο ICMP θα πρέπει να έχεις καλύτερη γνώση του TCP/IP stack και πως αυτό δουλεύει.

Το πρωτόκολλο ARP είναι λίγο παράξενο και μοναδικό υπό την εξής έννοια.
Αυτό που το κάνει μοναδικό είναι ότι ΔΕΝ εμπεριέχει IP header δηλαδή δεν εμπεριέχει Source IP Address, Destination IP Address, και γι αυτό τον λόγο δεν μπορεί να μιλήσει (πλήν μιας περίπτωσης αλλά ας μην επεκταθούμε σε αυτή) σε υπολογιστές που βρίσκονται εκτός τοπικού δικτύου.

Σε γενικές γραμμές όταν ένας υπολογιστής θέλει να θέσει ένα ερώτημα σε όλους (Broadcasting) ή μια ομάδα (Multicasting) υπολογιστών που βρίσκονται μέσα στο ίδιο τοπικό δίκτυο κάνει χρήση του ARP.

Πρόσεξε με το ARPING ένας υπολογιστή θέτει ένα ερώτημα σε πολλούς (broadcast, multicast) που βρίσκονται στο ίδιο δίκτυο (ΜΗΝ ΞΕΧΝΑΣ δεν έχει IP Header, δεν είναι δρομολογήσιμο). Το ICMP φέρει IP header είναι δρομολογήσιμο, που σημαίνει ότι μπορεί να μεταφέρει ένα μήνυμα από “ΜΑΚΡΥΑ”. Ξεκινάμε επικοινωνία με ένα υπολογιστή που βρίσκεται στο διαδίκτυο, αν κάπου εκεί μέσα στο σύννεφο κάτι πάει στραβά με ARPING δεν μπορεί να επιστρέψει ενώ με το ICMP μπορεί.


To πρωτόκολλο ICMP βρίσκεται στο IP OSI layer και υπάρχει ιδιαίτερος λόγος που βρίσκεται εκεί. Εγώ το ICMP το φαντάζομαι σαν τον ταχυδρόμο ΕΡΜΗ, και μεταφέρει μηνύματα σφαλμάτων κατά κανόνα για το UDP, Destination unreachable port unreachable, host unreachable …

Ένας server που δεν υποστηρίζει μια υπηρεσία (σε tcp port) απαντάει με RST.
Ενώ ένας server που δεν υποστηρίζει μια υπηρεσία (σε udp port) απαντάει με ICMP destination unreachable port unreachable.

Το TCP έχει δικούς του εσωτερικούς μηχανισμούς για να ανακάμψει από διάφορα σφάλματα όπως sequence / acknowledge numbers, duplicate acks, retransmissions, error notification (window full, window zero), out of order packets …
Ας υποθέσουμε ότι ένας υπολογιστή (PC_A) θέλει να στείλει δεδομένα σε ένα άλλο (PC_B) μέσω TCP.

Πρόσεξε τι γίνεται σε μερικές περιπτώσεις.

Α) Το PC-A στέλνει δεδομένα στο PC-B τα οποία όμως χάνονται κάπου ενδιάμεσα διότι υπάρχει congestion σε κάποιο router. Οι εφαρμογές δεν γνωρίζουν τίποτα σχετικά με τα σφάλματα αυτά. Σε επίπεδο όμως TCP αυτά αναγνωρίζονται και το PC-B με τον μηχανισμό sequence / Ack απαντάει στο PC-A “πήρα το πακέτο με αρίθμηση Ν, και περιμένω να μου στείλεις το πακέτο με αρίθμηση Ν+χ”. Αυτή η συζήτηση γίνεται σε επίπεδο TCP.
B) Καθώς το PC_B παραλαμβάνει τα δεδομένα που του στέλνει το PC_A, ας υποθέσουμε πως δεν αδειάζει το TCP receive buffer, μιας και το PC_A ασχολείται με CPU intensive apps. Σε επίπεδο TCP, το PC_A στέλνει ένα μήνυμα στο PC_B λέγοντάς του πως “Το buffer μου είναι γεμάτο, σε παρακαλώ μην στέλνεις δεδομένα παρά μόνο αν σε ενημερώσω”. Το PC_B σταματάει την αποστολή δεδομένων. Tώρα αν το PC_A καθυστερήσει το άδειασμα του δικού του TCP receive window, το PC_B θα στείλει μερικά μηνύματα στο PC_A ρωτώντας το κατά καιρούς ενώ συγχρόνων θα προσπαθήσει με την μέθοδο των Keep Alive Msg να διατηρήσει την σύνδεση. Μόλις το PC_A αδειάσει το TCP Receive Window, θα στείλει ένα μήνυμα στο PC_B λέγοντάς του ότι τώρα μπορεί να δεχθεί δεδομένα και τότε το PC_B θα συνεχίσει την αποστολή δεδομένων. Όλη αυτή η διαδικασία γίνεται σε επίπεδο TCP, οι εφαρμογές δεν καταλαβαίνουν τίποτα απ’ όλα αυτά τα προβλήματα.


Το UDP στερείται όλων αυτών των μηχανισμών ανάκαμψης.
Και πως φτάνουν τα δεδομένα στον προορισμός τους, χωρίς μηχανισμούς ανάκαμψης από τέτοιου είδους προβλήματα ;

Τον ρόλο αυτό, τον παίζει η ΕΦΑΡΜΟΓΗ που χρησιμοποιεί το UDP. Με την χρήση UDP όλοι οι μηχανισμοί ανάκαμψης γίνονται από την ΕΦΑΡΜΟΓΗ.

Redirections

Συνημμένο Αρχείο 60500

ΠΡΟΣΟΧΗ Τα redirections είναι καλά ΜΟΝΟ όταν προέρχονται από routers, διαφορετικά κάποιος επιχειρεί να σου κάνει route poisoning.

Router Solicitation – Router Advertisement

Γιατι πχ στο δικτυο μου δεν εχω δει ΠΟΤΕ ενα Router Advertisement οταν κανω reboot το router;

Συνημμένο Αρχείο 60501

Μέλη όπως ο Karavagos ίσως θα μπορούσαν να σε καλύψουν περισσότερο.

drhouse πραγματικά δεν έχω λόγια να σ ευχαριστήσω που μπηκες στον κοπο να γράψεις ολο αυτό..Κατάλαβα πολυ καλά τι εννοείς.

Μιας και μιλησαμε για ARP, κατι αλλο περίεργο που εκανα capture στο δίκτυό μου (εδω και κάμποσο καιρο) ειναι το παρακάτω.

Συνημμένο Αρχείο 60502

βλεπουμε ενα ΑRP request απo το Cisco στο Quantaco, να ρωταει ποιος εχει την 192.168.1.102.

Το Quantaco απαντάει κανονικότατα.

ΟΜΩΣ το Cisco ξερει ηδη ποιος εχει την παραπανω ΙΡ καθως δεν κανει broadcast αλλα την στελνει κατευθειαν στον παραληπτη!

Αν κοιταξουμε πιο προσεκτικα, θα δουμε οτι στο Εxpand του Ethernet Frame, το Destination ειναι γνωστο.

Αντιθετα στο Εxpand του ΑRP το Destination ειναι αγνωστο.

Εχει να κανει με το γεγονος οτι το Quantaco εχει direct link με το Ciscο? και αν ειναι ετσι, γιατι του κανει ΑRP request? αφου ξερει απ πριν τον παραληπτη..

Και παλι ευχαριστω πολυ!

Αρχικό μήνυμα από George_GPS

Δεν μπορω να καταλάβω σε τι διαφέρει το Router Advertisement απο ενα ARP request η απο ενα Reverse ARP (εκτος οτι το ΑRP ειναι Link Layer και το ICMP Internet Layer).

Το IRDP (το οποίο χρησιμοποιεί τα ICMP μηνύματα που αναφέρεις) βοηθάει στην εύρεση IP gateways/routers σε τοπικά δίκτυα (κάτι σαν το DHCP), ενώ το ARP μεταφράζει την L3 διεύθυνση σε L2 (το συνηθισμένο είναι από IP σε MAC) σε τοπικά δίκτυα.

Η λογική ακολουθία σε μια αρχική επικοινωνία μεταξύ ενός host και ενός router θα ήταν η έναρξη επικοινωνίας μέσω IRDP να προκαλέσει την αποστολή ARP πακέτων προκειμένου να βρεθούν οι mac διευθύνσεις των εμπλεκόμενων μηχανημάτων και μετά να σταλούν τα παραπάνω ICMP πακέτα. Λόγω όμως της εμπλοκής του multicast (όπου γίνεται κατευθείαν αντιστοίχηση IP=>MAC) στο IRDP, το ARP δεν χρειάζεται/χρησιμοποιείται στη συγκεκριμένη περίπτωση.

Αρχικό μήνυμα από George_GPS

Γιατι πχ στο δικτυο μου δεν εχω δει ΠΟΤΕ ενα Router Advertisement οταν κανω reboot το router;

ευχαριστω

Δεν ξέρω για τα υπόλοιπα routers, αλλά στα Cisco το IRDP είναι απενεργοποιημένο από default, οπότε αν ισχύει κάτι αντίστοιχο και στο δικό σου, ίσως για αυτό να μην βλέπεις τα σχετικά πακέτα.

Γενικά όμως τα συγκεκριμένα ICMP μηνύματα έχουν χρησιμότητα μόνο στο ICMPv6. Στο ICMPv4 υπάρχουν πολλές τρύπες αλλά και καλύτεροι/ασφαλέστεροι τρόποι να επιτύχεις ότι και το IRDP.

Off Topic

Αρχικό μήνυμα από George_GPS

Μιας και μιλησαμε για ARP, κατι αλλο περίεργο που εκανα capture στο δίκτυό μου (εδω και κάμποσο καιρο) ειναι το παρακάτω.

Συνημμένο Αρχείο 60502

βλεπουμε ενα ΑRP request απo το Cisco στο Quantaco, να ρωταει ποιος εχει την 192.168.1.102.

Το Quantaco απαντάει κανονικότατα.

ΟΜΩΣ το Cisco ξερει ηδη ποιος εχει την παραπανω ΙΡ καθως δεν κανει broadcast αλλα την στελνει κατευθειαν στον παραληπτη!

Αν κοιταξουμε πιο προσεκτικα, θα δουμε οτι στο Εxpand του Ethernet Frame, το Destination ειναι γνωστο.

Αντιθετα στο Εxpand του ΑRP το Destination ειναι αγνωστο.

Εχει να κανει με το γεγονος οτι το Quantaco εχει direct link με το Ciscο? και αν ειναι ετσι, γιατι του κανει ΑRP request? αφου ξερει απ πριν τον παραληπτη..

Και παλι ευχαριστω πολυ!

Είτε γίνεται update του arp cache (το πιο πιθανό, αν γίνεται ανά τακτά χρονικά διαστήματα, μπορείς να αλλάξεις το "arp timeout" του interface για επιβεβαίωση), είτε το unicast ARP request χρησιμοποιείται από το DHCP για έλεγχο λειτουργίας του host.

Αρχικό μήνυμα από George_GPS

drhouse πραγματικά δεν έχω λόγια να σ ευχαριστήσω που μπηκες στον κοπο να γράψεις ολο αυτό..Κατάλαβα πολυ καλά τι εννοείς.

Μιας και μιλησαμε για ARP, κατι αλλο περίεργο που εκανα capture στο δίκτυό μου (εδω και κάμποσο καιρο) ειναι το παρακάτω.

Συνημμένο Αρχείο 60502

βλεπουμε ενα ΑRP request απo το Cisco στο Quantaco, να ρωταει ποιος εχει την 192.168.1.102.

Το Quantaco απαντάει κανονικότατα.

ΟΜΩΣ το Cisco ξερει ηδη ποιος εχει την παραπανω ΙΡ καθως δεν κανει broadcast αλλα την στελνει κατευθειαν στον παραληπτη!

Αν κοιταξουμε πιο προσεκτικα, θα δουμε οτι στο Εxpand του Ethernet Frame, το Destination ειναι γνωστο.

Αντιθετα στο Εxpand του ΑRP το Destination ειναι αγνωστο.

Εχει να κανει με το γεγονος οτι το Quantaco εχει direct link με το Ciscο? και αν ειναι ετσι, γιατι του κανει ΑRP request? αφου ξερει απ πριν τον παραληπτη..

Και παλι ευχαριστω πολυ!

Ρίξε μια ματιά στον όρο "Gratuitous ARP". εκεί πάει το μυαλό μου, περισσότερα μόνο αν δώ λεπτομέρειες από το capture.

Αρχικό μήνυμα από drhouse

Ρίξε μια ματιά στον όρο "Gratuitous ARP". εκεί πάει το μυαλό μου, περισσότερα μόνο αν δώ λεπτομέρειες από το capture.

K εγω αυτο σκέφτηκα αρχικα..

Όμως δεν ειναι Gratuitous ARP, το λεει και στο frame που εχει γίνει expand..

Gratuitous ARP = False, σύμφωνα με το Wireshark...

Ασε που ετσι κ αλλιώς το Source και το Destination (edit: IP) Address ειναι διαφορετικά..Σε ενα Gratuitous ARP request αυτά τα δυο πρέπει (και είναι) πάντα ίδια.

o φιλος karavagos ίσως να εχει δίκιο..

Αρχικό μήνυμα από George_GPS

K εγω αυτο σκέφτηκα αρχικα..

Όμως δεν ειναι Gratuitous ARP, το λεει και στο frame που εχει γίνει expand..

Gratuitous ARP = False, σύμφωνα με το Wireshark...

Ασε που ετσι κ αλλιώς το Source και το Destination Address ειναι διαφορετικά..Σε ενα Gratuitous ARP request αυτά τα δυο πρέπει (και είναι) πάντα ίδια.

o φιλος karavagos ίσως να εχει δίκιο..

Το πιό πιθανό είναι να έχει δίκιο ο karavagos .

Επειδή ψάχνεσαι σου έκανα την αναφορά για το Gratuitous ARP.

Ένα Gratuitous ARP έχει σαν destination address ffffff …. (broadcast).
Θέτει το ερώτημα σε όλους όσους βρίσκονται στο τοπικό δίκτυο.

Επίσης έχε υπ' όψιν σου ότι μερικές φορές μια IP συσκευή αν και έχει IP, δεν την χρησιμοποίει, επικοινωνεί δε με κάνοντας χρήση των MAC addr.

Βεβαιώσου ότι πράγματι βλέπεις arp query και το αντίστοιχη ΤΟΥ arp response.

Καλά θα ήταν να ανέβαζες capture file.

Αρχικό μήνυμα από drhouse

Το πιό πιθανό είναι να έχει δίκιο ο karavagos .

Επειδή ψάχνεσαι σου έκανα την αναφορά για το Gratuitous ARP.

Ένα Gratuitous ARP έχει σαν destination address ffffff …. (broadcast).
Θέτει το ερώτημα σε όλους όσους βρίσκονται στο τοπικό δίκτυο.

Επίσης έχε υπ' όψιν σου ότι μερικές φορές μια IP συσκευή αν και έχει IP, δεν την χρησιμοποίει, επικοινωνεί δε με κάνοντας χρήση των MAC addr.

Βεβαιώσου ότι πράγματι βλέπεις arp query και το αντίστοιχη ΤΟΥ arp response.

Καλά θα ήταν να ανέβαζες capture file.

Ευχαριστώ, ισως το διατύπωσα λαθος, ήθελα να πω οτι στο Gratuitous ARP οτι η Sender IP είναι ιδια με την Τarget IP, δεν εννοούσα MAC.

Eνα παράδειγμα GARP:

Συνημμένο Αρχείο 60531

Σε ενα Gratuitous ARP request, δεν πρέπει να υπάρξει πότε Gratuitous ARP reply. Αν συμβεί κατι τέτοιο εχουμε μια ΙP η οποια χρησιμοποιείται και απο αλλο σύστημα. Σ αυτήν την περίπτωση μας ενημερώνει σχεδον πάντα το OS μας με κατάλληλο μηνυμα.

ΥΓ: Με την πρωτη ευκαιρία θα ανεβάσω και το ολοκληρωμένο .pcap, αυτη τη στιγμή το ειχα μονο σε PrtScn. Μόλις το βρω θα το ανεβάσω (γίνεται ενας ψιλοχαμος στο PC)