Mengapa merusak TTL IP berbahaya?


51

Saya telah membaca halaman iptables (light bedtime reading) dan saya menemukan target 'TTL', tetapi ia memperingatkan:

Pengaturan atau penambahan bidang TTL berpotensi sangat berbahaya

dan

Jangan pernah menetapkan atau menambah nilai pada paket yang meninggalkan jaringan lokal Anda!

Saya dapat melihat bagaimana mungkin pengurangan atau pengaturan TTL yang lebih rendah dapat menyebabkan paket dijatuhkan sebelum mencapai tujuan, tetapi apa efek peningkatan yang dapat terjadi?

Jawaban:


67

TTL akan dikurangi ketika melewati router. Ini memastikan bahwa jika paket tersebut berputar-putar, akhirnya akan mati.

Bidang TTL dari paket IP v4 adalah bidang 8-bit (255 desimal). Jadi pengaturannya tinggi pada awalnya itu bukan masalah besar karena sebenarnya tidak bisa sebesar itu dalam paket yang terbentuk dengan baik (Meskipun, beberapa hal mungkin menerima paket IP yang salah).

Namun, jika sesuatu menambahnya, dan langkah penambahan adalah bagian dari loop , paket bisa terus berputar tanpa mencapai nol. Seiring waktu (bisa jadi sangat singkat, atau kebocoran bertahap), paket bisa menumpuk di sistem yang mengandung loop sehingga menyebabkan kelebihan beban.


20

TTL pada paket membuat routing tetap waras, pada dasarnya. Jika suatu paket memiliki TTL yang sangat besar dan terjebak dalam rute melingkar karena suatu alasan, itu dapat menyebabkan satu ton lalu lintas (disebut "paket badai") dan mengganggu operasi normal. TTL yang terlalu rendah akan mengakibatkan hilangnya konektivitas karena Anda akan kehilangan paket sebelum mencapai tujuan.


Ini lebih lanjut tentang kedaluwarsa TTL, tetapi sedikit lebih detail tentang apa yang Anda katakan: cisco.com/web/about/security/intelligence/ttl-expiry.html
NickW

5

Ada satu hal yang kelihatannya tidak terjawab oleh jawabannya tetapi murni bersifat akademis (karena berapa banyak hop yang diperlukan di internet): jika suatu paket biasanya gagal mencapai tujuannya karena TTL yang kedaluwarsa, maka tambahkan saja akan memungkinkan paket untuk mencapai tujuan itu tetapi tidak akan mempengaruhi paket yang dikembalikan dan mereka akan kedaluwarsa sebelum mencapai jaringan Anda.

UPDATE: Menurut halaman ini di Wikipedia :

Secara teori, di bawah IPv4, waktu untuk hidup diukur dalam detik, meskipun setiap host yang melewati datagram harus mengurangi TTL oleh setidaknya satu unit. Dalam praktiknya, bidang TTL dikurangi dengan satu pada setiap hop. Untuk mencerminkan praktik ini, bidang ini diubah nama batas hop di IPv6.

UPDATE 2: Ketika seseorang memperbarui posting saya dan mereferensikan Wikipedia, saya pikir mungkin yang terbaik untuk merujuk RFC itu sendiri - http://www.ietf.org/rfc/rfc791.txt - Cukup cari TTL di sana dan itu cukup pekerjaan yang baik untuk menjelaskannya:

Bidang ini menunjukkan waktu maksimum datagram dibiarkan tetap di sistem internet ... setiap modul yang memproses datagram harus mengurangi TTL setidaknya satu bahkan jika itu memproses datagram dalam waktu kurang dari satu detik

2
Namun - jika Anda menambahkan paket yang berasal dari jaringan Anda ke nilai yang akan mereka miliki jika mereka berasal dari router Anda, maka paket yang dikembalikan akan mencapai router Anda (dan kemudian Anda dapat menambahkannya ketika mengirimnya ke klien di jaringan lokal)
Random832

Saya suka pandangan novel tentang pendekatan dan Anda mendapatkan upvote saya untuk itu. Namun TTL awalnya dimaksudkan untuk dikurangi satu kali untuk setiap detik paket yang dihabiskan dalam jaringan dan juga untuk setiap hop. Definisi historis itu sebagian besar diabaikan saat ini - namun tidak dapat diasumsikan bahwa jalur antara dua node simetris - atau bahkan sama dari satu paket transmisi ke paket lainnya.
PP.

Benar. Anda bisa mendapatkan beberapa hasil yang sangat aneh menggunakan tracert kadang-kadang jika paket x mengambil rute yang berbeda dari paket y! Juga terima kasih atas informasi tentang waktu pelacakannya juga, saya tidak tahu itu (walaupun jika paket tidak diberi cap waktu yang hanya dapat dikurangi jika router memegangnya, kan?)
Matthew Steeples

@PP. Apakah Anda memiliki referensi untuk klaim bahwa TTL semula seharusnya dikurangi satu kali per detik? Tanpa jam disinkronkan presisi tinggi, yang tentu saja tidak biasa di awal-awal Internet (apalagi bahwa banyak host hanya menangani waktu lokal), saya tidak melihat bagaimana itu bisa dilakukan dengan andal.
CVn

3
@ MichaelKjörling Didefinisikan seperti itu dalam RFC 791, yang mendefinisikan IPv4.
Michael Hampton

3

Saya tahu hanya satu program, yang bisa menggunakan nilai TTL yang lebih tinggi, dan itu traceroute. Seperti namanya, ini melacak rute ke host tujuan dengan memodifikasi nilai TTL. Max standar hop adalah 20, tetapi Anda dapat meningkatkannya.


2
(Sebagian besar implementasi) traceroute juga mengandalkan pesan ICMP Time Exceeded untuk mengetahui apakah suatu paket telah mencapai tujuannya atau belum. Selain itu, pesan Time Exceeded adalah salah satu alasan mengapa pemblokiran langsung ICMP adalah ide yang sangat buruk.
CVn

0

Setiap router yang menangani paket menurunkan nilai TTL, hingga paket mencapai tujuannya, atau TTL mencapai nol, dan mati.

Seperti yang dikatakan orang lain, peningkatan TTL dapat menghasilkan paket yang tidak pernah mati, jika ada siklus negatif. Secara umum, jika nilai TTL tidak cukup besar, logika untuk mencoba TTL yang lebih besar mungkin harus ditangani oleh klien end-to-end.

Jika Anda yakin bahwa router tidak dalam siklus (topologi seperti pohon), Anda secara teori dapat meningkatkan nilai TTL dengan aman. Karena itu, memungkinkan lebih banyak hop daripada standar dapat membuat kemacetan lebih mungkin di jaringan eksternal. Jika Anda memiliki rantai panjang router antara jaringan internal dan eksternal, selama tidak ada siklus, nilai TTL yang lebih besar mungkin membantu. Karena itu, bisa sangat mudah bagi seseorang untuk menambahkan keunggulan pada jaringan dan membuat siklus, jadi dimulai dengan nilai TTL yang lebih besar di mana paket yang berasal dari tempat pertama jauh lebih aman.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.