Vraag Waarom is knoeien met de TTL van IP gevaarlijk?


Ik heb de iptables man-pagina gelezen (lichte leestijd) en ik kwam het 'TTL'-doel tegen, maar het waarschuwt:

Het instellen of verhogen van het TTL-veld kan potentieel zeer gevaarlijk zijn

en

Stel nooit de waarde in of verhoog deze op pakketten die uw lokale netwerk verlaten!

Ik kan zien hoe misschien het verlagen of instellen van de TTL lager ervoor kan zorgen dat pakketten worden verwijderd voordat ze de bestemming bereiken, maar welk effect kan toenemen?


50
2018-05-22 15:31


oorsprong




antwoorden:


De TTL wordt verlaagd als deze door een router gaat. Dit zorgt ervoor dat als het pakket in cirkels rondreist het uiteindelijk zal sterven.

Het TTL-veld van een IP v4-pakket is een 8-bits veld (255 decimaal). Dus het hoog instellen aan het begin is geen big deal, omdat het niet zo groot kan zijn in een goed gevormd pakket (hoewel, sommige dingen kunnen misvormde IP-pakketten accepteren).

Echter, als iets het verhoogt, en de stap van het verhogen is deel van de lus, het pakket kon in cirkels blijven doorgaan zonder ooit nul te bereiken. Na verloop van tijd (kan heel kort zijn of een geleidelijk lek), kunnen er pakketten worden opgebouwd in het systeem met die lus waardoor het te zwaar wordt.


66
2018-05-22 16:05





De TTL-pakketten houden de routering logisch, in principe. Als een pakket een zeer grote TTL zou hebben en om de een of andere reden in een rondgaande route zou worden vastgehouden, zou dit een hoop verkeer kunnen veroorzaken (een "pakketstorm" genoemd) en de normale werking verstoren. Te lage TTL zou leiden tot verlies van connectiviteit, omdat u het pakket zou verliezen voordat het de bestemming zou bereiken.


19
2018-05-22 15:39



Dit gaat meer over het aflopen van TTL, maar het gaat wel wat meer in detail over wat u zegt: cisco.com/web/about/security/intelligence/ttl-expiry.html - NickW


Er is een punt dat de antwoorden lijken te hebben gemist, maar dat puur academisch zou zijn (vanwege het aantal benodigde hops op het internet): als een pakket normaal zijn bestemming niet haalt vanwege een verlopen TTL, dan wordt het groter zou het pakket toestaan ​​zijn bestemming te bereiken, maar zou geen invloed hebben op pakketten die worden geretourneerd en ze zouden verlopen voordat ze uw netwerk bereiken.

UPDATE: Volgens deze pagina op Wikipedia:

In theorie wordt onder IPv4 de tijd tot leven gemeten in seconden, hoewel elke host die het datagram passeert, de TTL met ten minste één eenheid moet verminderen. In de praktijk wordt het TTL-veld met één verlaagd op elke sprong. Om deze praktijk te weerspiegelen, wordt het veld hernoemd als hoplimiet in IPv6.

UPDATE 2: Omdat iemand mijn bericht heeft geüpdatet en naar Wikipedia heeft verwezen, dacht ik dat het het beste zou zijn om naar de RFC zelf te verwijzen - http://www.ietf.org/rfc/rfc791.txt - Zoek gewoon naar TTL daarbinnen en het is best goed om het uit te leggen:

Dit veld geeft de maximale tijd weer dat het datagram in het internetsysteem mag blijven ... elke module die een datagram verwerkt, moet de TTL met ten minste één verlagen, zelfs als het datagram in minder dan een seconde wordt verwerkt

5
2018-05-22 17:17



Maar - als u pakketten die afkomstig zijn van uw netwerk heeft verhoogd naar de waarde die ze hadden gehad als ze afkomstig waren van uw router, dan zullen de retourpakketten uw router bereiken (en dan kunt u ze opwaarderen bij het doorsturen naar de client in de router). lokaal netwerk) - Random832
Ik hou van de nieuwe kijk op de aanpak en daar krijg ik mijn opinie voor. Oorspronkelijk was het echter de bedoeling dat TTL eenmaal per seconde het pakket in het netwerk en voor elke hop decrementeerde. Die historische definitie wordt tegenwoordig grotendeels genegeerd, maar het kan nooit worden aangenomen dat het pad tussen twee knooppunten symmetrisch is - of zelfs hetzelfde is van de ene pakketoverdracht naar de andere. - PP.
True. Je kunt soms heel rare resultaten krijgen met tracert als pakket x een andere route neemt dan pakket y! Ook bedankt voor de informatie over het bijhouden van de tijd, ik wist dat niet (hoewel als pakketten niet zijn voorzien van een tijdstempel die alleen kan worden verlaagd als een router eraan vasthoudt, toch?) - Matthew Steeples
@PP. Heeft u een referentie voor de bewering dat de TTL oorspronkelijk eenmaal per seconde moest worden verlaagd? Zonder precieze gesynchroniseerde klokken, die zeker niet gebruikelijk waren in de beginjaren van internet (laat staan ​​dat veel hosts alleen lokale tijd behandelden), zie ik niet hoe dat op betrouwbare wijze kan worden gedaan. - α CVn
@ MichaelKjörling Het is als zodanig gedefinieerd in RFC 791, dat IPv4 definieert. - Michael Hampton♦


Ik ken slechts één programma, dat een hogere TTL-waarde kan gebruiken, en dat is het traceroute. Zoals de naam al zegt, traceert het de route naar een bestemmingshost door de TTL-waarde te wijzigen. De standaard max hop is 20, maar je kunt die verhogen.


3
2018-05-22 15:52



(De meeste implementaties van) traceroute zijn ook afhankelijk van ICMP Tijd overschreden berichten om aan te geven of een pakket zijn bestemming heeft bereikt of niet. Even terzijde, Time Exceeded-berichten zijn een reden waarom het volledig blokkeren van ICMP een zeer slecht idee is. - α CVn


Elke router die een pakket verwerkt, verlaagt de TTL-waarde totdat het pakket de bestemming bereikt of TTL nul bereikt en sterft.

Zoals anderen hebben gezegd, kan het verhogen van TTL resulteren in pakketten die nooit doodgaan, als er een negatieve cyclus is. Over het algemeen, als een TTL-waarde niet groot genoeg is, moet de logica om een ​​grotere TTL uit te proberen waarschijnlijk worden afgehandeld door de end-to-end clients.

Als je zeker weet dat een router niet in een cyclus zit (boomachtige topologie), zou je in theorie de TTL-waarde veilig kunnen verhogen. Dat gezegd hebbende, zou meer opstoppingen dan standaard mogelijk congestie meer waarschijnlijk maken in het externe netwerk. Als u een lange keten van routers hebt tussen het interne en externe netwerk, kan, zolang er geen cyclus is, een hogere TTL-waarde helpen. Dat gezegd hebbende, zou het voor iemand vrij eenvoudig kunnen zijn om een ​​rand aan het netwerk toe te voegen en een cyclus te maken, dus beginnen met een grotere TTL-waarde waar het pakket in de eerste plaats is ontstaan, is veel veiliger.


0
2018-05-24 13:02