Nama : Siti Justianti Muhajriyah

NIM : 1929141008
Kelas : TEKNIK KOMPUTER A 2019
Keamanan TCP / IP
Model ancaman untuk keamanan jaringan:
• Musuh dapat mencegat / mengubah lalu lintas jaringan.
• Musuh dapat mengirim paket.
• Musuh memiliki kendali penuh atas mesin mereka sendiri.
• Musuh dapat berpartisipasi dalam protokol (biasanya).
Seringkali tidak layak untuk mencegah orang jahat keluar dari sistem yang besar.
• Menguping paket.
• Penting untuk diingat, tetapi dipahami dengan relatif baik.
• Setiap data yang dikirim melalui jaringan dapat diamati oleh musuh.
• Mengirim / spoofing paket.
• IP memungkinkan pengirim untuk membuat paket arbitrer.
• Secara khusus, pengirim dapat mengisi alamat sumber mana saja.
• Dapat berpura-pura bahwa sebuah paket datang dari alamat manapun.
• Apa yang dapat dilakukan musuh dengan ini?
Target mudah: memicu bug dalam beberapa implementasi.
• Penulis tidak begitu tertarik dengan masalah kelas ini.
• Sebaliknya, ingin melihat "masalah tingkat protokol".
• Apakah masalah tingkat protokol?
 Masalah yang melekat dalam desain.
 Penerapan yang benar akan mengalami masalah ini.
• Mengapa itu sangat penting?
 Dapat memperbaiki bug implementasi.
 Untuk memperbaiki bug tingkat protokol, mungkin perlu mengubah protokol!
 Mungkin tidak kompatibel dengan sistem yang ada.
 Seperti yang akan kita lihat, terkadang memungkinkan untuk menghasilkan perbaikan
yang kompatibel.
Bagaimana musuh mengetahui bahwa data tersebut berasal dari klien?
• Hanya klien yang seharusnya dapat menerima pesan kedua.
• Jadi, hanya klien yang harus mengetahui SN.
 • Pesan ketiga ditolak, kecuali pesan tersebut memiliki nilai SN yang benar.
Misalkan musuh A ingin mensimulasikan koneksi ke S dari C. (Asumsikan A tahu Alamat IP
C -‐ biasanya bukan masalah besar dalam praktiknya.)
Di mana musuh mendapatkan SN?
• Spesifikasi TCP menyarankan cara khusus untuk memilihnya.
• Secara khusus, kenaikan pada ~ laju konstan: ~ 250.000 per detik.
Mengapa begitu spesifik?
 Interaksi halus dengan koneksi yang digunakan kembali (nomor port src / dst).
 Ingin menghindari paket lama (dari koneksi masa lalu) mengganggu koneksi baru.
Jika musuh mengetahui nomor urut terbaru, bisa menebak nomor urut berikutnya.
 Impl benar-benar akan menabrak ISN setiap detik, membuatnya mudah ditebak.
Apa yang terjadi pada paket nyata yang dikirim S ke C (pkt kedua)?
• C akan menganggap paket tersebut dari koneksi lama, kirim RST sebagai
tanggapan.
• Bahkan jika RST itu dikirim, musuh dapat mencoba untuk balapan sebelum
RST tiba.
• Untungnya, ada bug aneh lainnya; akan membahasnya nanti
Tetapi mengapa serangan nomor urut berubah menjadi masalah keamanan?
1. Koneksi spoof ke aplikasi yang mengandalkan alamat IP.
• Misalnya, alat akses jarak jauh Berkeley: rlogin, rsh, rcp.
• Diizinkan masuk tanpa kata sandi, jika koneksi berasal dari sistem
"tepercaya".
Koneksi yang diperlukan untuk datang dari port sumber tepercaya (512-‐1023).
Mengapa persyaratan ini?
 Program rlogin / rsh / rcp tepercaya mengirim nama pengguna klien.
 Jika username sama dengan akun di server, tidak ada password dibutuhkan.
• Misalnya: "rsh athena.dialup.mit.edu ls".
• Membuat asumsi buruk tentang apa yang disediakan lapisan TCP.
 Diasumsikan koneksi TCP dari alamat IP berarti itu benar-benar berasal dari itu tuan
rumah.
 Jika musuh dapat menebak SN, maka dapat mensimulasikan koneksi dari host
terpercaya.
 Keluarkan perintah apa pun menggunakan rsh.
 Bisa mengubah file .rhosts pengguna untuk mengizinkan login dari host penyerang.
 Kemudian hubungkan secara langsung tanpa harus mensimulasikan koneksi.
• Otentikasi berbasis host sepertinya rencana yang buruk.
 Terutama mengandalkan port "tepercaya" vs "tidak tepercaya" pada mesin.
 Masih digunakan sampai sekarang: mis., SMTP untuk surat keluar.
• Sebenarnya otentikasi rlogin bahkan lebih buruk: mereka diautentikasi dengan
nama host.
 Dari mana asal nama host? Reverse pencarian DNS.
 Misalnya, 18.26.4.9: temukan data PTR 9.4.26.18.in-‐addr.arpa.
 Pemilik domain tersebut dapat menyetel data PTR ke nama host mana pun!
 (Dapat membuat sedikit perbaikan: periksa apakah host memutuskan untuk alamat
yang sama.)
 Masalah serupa muncul di file log: nama host yang diselesaikan log (tidak tepercaya).

2. Serangan Denial of service: reset koneksi

• Setelah kita mengetahui SNc, dapat mengirimkan paket RST.
• Lebih buruk lagi: server akan menerima paket RST untuk nilai SNc apa pun di
dalam jendela.
• Dengan jendela besar (~ 32K = 2 ^ 15), hanya perlu 2 ^ 32/2 ^ 15 = 2 ^ 17
tebakan.
 Seberapa buruk koneksi disetel ulang?
• Salah satu target serangan tersebut adalah koneksi TCP antara router BGP.
• Menyebabkan router menganggap kegagalan link, dapat mempengaruhi lalu
lintas selama beberapa menit.
• Solusi:
 retas TTL (255).
 Otentikasi header MD5 (sangat khusus untuk link router -‐ ke - ‐
router).
3. Membajak koneksi yang ada.
• Senada, bisa juga menginjeksi data ke koneksi yang sudah ada.
 • Yang perlu diketahui musuh adalah SNc saat ini.
 Bagaimana cara mengatasi masalah ini?
• Baseline: jangan mengandalkan alamat IP untuk otentikasi.
 Gunakan enkripsi / otentikasi pada tingkat yang lebih tinggi.
 Kuliah selanjutnya: Kerberos.
 Tapi tetap, ingin memperbaiki situasi kita, untuk TCP.
• ISP dapat memfilter paket yang dikirim oleh pelanggan mereka.
 Sering dilakukan hari ini untuk pelanggan kecil, tetapi tidak konsisten.
 Tidak langsung bagi pelanggan dengan jaringan yang kompleks,
 multihoming…
Bagaimana cara menambal TCP?
• Tidak dapat memilih ISN dengan cara yang benar-benar acak, tanpa
melanggar spesifikasi TCP.
 Mungkin putus koneksi (port) jaminan penggunaan kembali.
• Penambahan acak?
 Harus mempertahankan laju kenaikan (~ 250k / detik).
 Bukan jumlah keacakan yang besar (katakanlah, 8 bit rendah per kenaikan).
• Selain: harus berhati-hati tentang bagaimana kita menghasilkan angka acak!
 PRNG Umum: generator kongruensial linier: R_k = A * R_ {k -‐ 1} + B mod N.
 Tidak aman: diberi satu nilai pseudo -‐ random, dapat menebak yang berikutnya!
 Banyak PRNG yang lebih aman secara kriptografis tersedia.
 ▪ Idealnya, gunakan PRNG bawaan kernel Anda (/ dev / random / dev / urandom)
 Ref: http://en.wikipedia.org/wiki/Fortuna_(PRNG) , atau aliran apa pun
 sandi seperti http://en.wikipedia.org/wiki/RC4
• Namun, nilai SN untuk pasangan src / dst yang berbeda tidak pernah
berinteraksi!
• Jadi, bisa memilih ISN menggunakan offset acak untuk setiap pasangan src /
dst.
 Trik bagus: ISN = ISN_oldstyle + F (srcip, srcport, dstip, dstport, rahasia)
 F adalah beberapa fungsi pseudo -‐ random; kira-kira, pikirkan SHA1.
 Tidak memerlukan status tambahan untuk melacak ISN per koneksi.
 Apakah serangan nomor urut masih relevan?
 • Sebagian besar sistem operasi menerapkan solusi ISN per koneksi di atas.
 Ref: Linux secure_tcp_sequence_number di net / core / secure_seq.c
• Tapi protokol lain mengalami masalah yang hampir identik - ‐- ‐ misalnya,
DNS.
 DNS berjalan melalui UDP, tidak ada nomor seq, hanya port, dan port dst tetap (53).
 Jika musuh mengetahui klien membuat kueri, dapat memalsukan respons.
 Hanya perlu menebak port src, seringkali bisa diprediksi.
 Masalah mendapatkan popularitas di tahun 2008, meskipun dipahami dengan baik
oleh djb sebelum.
 Solusi: dengan hati-hati manfaatkan semua kemungkinan keacakan!
 Kueri DNS berisi ID kueri 16-bit, dan dapat mengacak ~ 16 bit
 port src.
 Solusi: terapkan DNSSEC (catatan DNS yang ditandatangani, termasuk yang hilang
 catatan).
 Satu masalah: distribusi kunci (siapa yang diizinkan untuk menandatangani setiap
domain?)
 Masalah lain: pencacahan nama (untuk menandatangani jawaban "tidak ada nama
seperti itu").
 Sebagian dimitigasi oleh NSEC3: http://tools.ietf.org/html/rfc5155
 Penerapan lambat, tidak banyak insentif untuk meningkatkan, biaya tidak sepele.
 Biaya termasuk kinerja dan administrasi (kunci / sertifikat pengelolaan). Banjir SYN.
• Perhatikan bahwa server harus menyimpan beberapa status ketika menerima
paket SYN.
 Disebut koneksi setengah terbuka: dibalas dengan SYN -‐ ACK, menunggu ACK.
• Bagaimana jika menerima pesan SYN dari banyak sumber?
 Banyak implementasi mencoba mempertahankan status untuk semua koneksi
setengah terbuka.
 Tapi akhirnya kehabisan memori, harus menolak koneksi!
• Masalah yang menjengkelkan: kita bahkan tidak tahu untuk siapa kita menjaga
keadaan!
 Musuh dapat memiliki satu host, dan menghasilkan SYN dari banyak IP src.
 • Serangan Denial -‐ of -‐ service: asimetri besar antara sumber daya klien +
server.
 Klien memalsukan satu paket (kurang dari 1 milidetik).
 Server membuang memori sampai waktu koneksi habis (menit).
 Pertahanan untuk SYN flooding: cookie SYN.
• Ide: membuat server stateless, sampai menerima paket ketiga (ACK).
• Mengapa ini rumit?
 Perlu memastikan bahwa musuh tidak dapat membuat koneksi dari alamat src apa
pun.
 Sebelumnya, ini dilakukan dengan menyimpan ISN, dan mengharapkannya di ACK.
• Gunakan sedikit kriptografi untuk mencapai tujuan yang sama.
• Menyandikan status sisi server menjadi nomor urut.
 ISN = MAC_k (src / dst addr + port, stempel waktu) || cap waktu
 Stempel waktu berbutir kasar (mis., menit).
 Server menyimpan kunci rahasia k, tidak dibagikan dengan orang lain.

• Server menghitung urutan seperti di atas saat mengirim respons SYN -‐ ACK.
• Server dapat memverifikasi status utuh dengan memverifikasi hash (MAC)
pada urutan ACK.
 Tidak terlalu ideal: perlu memikirkan serangan replay dalam timestamp.
• Masalah lain: jika paket ketiga hilang, tidak ada yang mengirim ulang.
 Mungkin bukan masalah besar jika terjadi serangan DoS.
 Hanya masalah untuk protokol di mana server berbicara lebih dulu.
 Vektor serangan DoS lainnya: amplifikasi bandwidth.
• Mengirim paket permintaan gema (ping) ICMP ke alamat siaran jaringan.
 Misalnya, 18.26.7.255.
 Dulu Anda akan mendapatkan balasan gema ICMP dari semua mesin di
 jaringan.
 Bagaimana jika Anda memalsukan paket dari alamat korban? Korban mendapat
semua balasan.
 Temukan subnet dengan 100 mesin di jaringan cepat: 100x amplifikasi!
• Bisakah kita memperbaikinya?
 Router sekarang memblokir "siaran langsung" (paket dikirim ke siaran
 alamat).
• Varian modern: amplifikasi DNS.
 DNS juga merupakan layanan respons permintaan.
 Dengan kueri kecil, server mungkin mengirim kembali respons yang besar.
 Dengan DNSSEC, tanggapan mengandung banyak tanda tangan, jadi mereka bahkan
lebih besar!
 Karena DNS berjalan melalui UDP, alamat sumber sama sekali tidak diverifikasi.
 Ref: http : //blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-
 menyerang
• Bisakah kita memperbaiki serangan DNS?
 Sebenarnya cukup sulit! Server nama root harus menjawab pertanyaan dari
 siapa saja.
• Bagaimana jika kita memiliki kesempatan untuk mendesain ulang DNS dari
awal?
 Satu kemungkinan rencana: query harus sebesar respon (membutuhkan padding).
 Teknik umum: memaksa klien untuk mengeluarkan setidaknya banyak pekerjaan.
 Kontrol kemacetan TCP.
• Penerima bisa mendapatkan pengirim untuk mempercepat, dengan ACK
segmen yang tidak diterima. Atau
 mengirim lebih banyak ACK (misalnya, mengirim ACK untuk setiap byte alih-alih
setiap paket).
 Protokol perutean: peserta yang terlalu percaya.
• ARP: dalam satu jaringan Ethernet.
 Untuk mengirim paket IP, membutuhkan alamat MAC Ethernet dari router / hop
berikutnya.
 Address Resolution Protocol (ARP): menyiarkan permintaan untuk MAC target.
 Siapapun dapat mendengarkan siaran, mengirim balasan; tidak ada otentikasi.

 Musuh dapat menyamar sebagai router, mencegat paket, bahkan saat diaktifkan
bersih.
 Solusi potensial: lakukan sakelar yang bertanggung jawab atas ARP.
• ▪ Tidak digunakan secara luas: akan membutuhkan pengelolaan alamat MAC /
IP hati-hati.
• DHCP: sekali lagi, dalam satu jaringan Ethernet.
 Klien meminta alamat IP dengan mengirimkan permintaan siaran.
 Server merespons, tidak ada otentikasi (beberapa spesifikasi ada tetapi tidak secara
luas bekas).
• Jika Anda baru saja terhubung ke jaringan, mungkin tidak tahu apa yang
diharapkan.
 Banyak bidang: alamat IP, alamat router, server DNS, daftar domain DNS, ..
 Musuh dapat meniru server DHCP ke klien baru di jaringan.
• Dapat memilih server DNS, domain DNS, router, dll.
 Juga, serangan DoS pada server: meminta banyak sewa, dari banyak alamat MAC.
 Solusi: buat sakelar yang bertanggung jawab atas DHCP (forward reqs to real server).
• Tidak diterapkan secara luas: akan membutuhkan konfigurasi sakelar yang
hati-hati. Bahkan lebih rumit pada jaringan nirkabel. BGP: Internet - ‐ wide
(mirip dengan serangan RIP yang dijelaskan di kertas).
 Semua router peserta BGP dapat mengumumkan rute ke sebuah prefiks.
 Bagaimana jika musuh memiliki router? Dapat mengumumkan awalan atau rute apa
pun.
 Apakah masalah ini masih relevan?
• Pelaku spam sering memanfaatkan ini: mengumumkan alamat yang tidak
digunakan, dan kirim spam.
• Menyiasati daftar hitam pengirim spam tingkat IP: pilih hampir
• IP apa saja!
 Bagaimana cara memperbaikinya?
• SBGP: penandatanganan kriptografi pengumuman rute.
• Harus mengetahui siapa yang diizinkan untuk mengumumkan setiap prefiks IP
tertentu.
• Mewajibkan seseorang untuk mendistribusikan kunci / sertifikat untuk setiap
IP awalan.
• Masalah bootstrap rumit; beberapa overhead kinerja terlalu Mendapatkan daya
tarik tetapi masih belum digunakan secara luas.
 • Banyak masalah lain juga.
• Pesan ICMP seperti redirect: tidak ada otentikasi, pada dasarnya tidak
digunakan sekarang.
• Mengekspos terlalu banyak informasi (netstat, SNMP, finger): sebagian besar
tetap.
• identd ("Layanan Otentikasi"): desain yang buruk, tidak ada otentikasi yang
sebenarnya.
• Email: masalah nyata tetapi belum ada solusi praktis.
 Otentikasi vs otorisasi.
 Misalnya, PGP tidak akan menyelesaikan masalah spam.
• Kata sandi dalam protokol: HANYA mendukung kata sandi tidak terlalu
bagus.
• Protokol transfer data FTP.
 Server menghubungkan kembali ke klien untuk mengirim file ke klien.
 Klien memberi tahu server alamat IP dan nomor port apa yang akan digunakan.
 Dapat digunakan untuk pemindaian port dari IP server.
 Dapat digunakan untuk mengirim lalu lintas apa pun (tertanam dalam file) dari IP
server.
 ▪ Misalnya, masalah otentikasi kembali ke IP: rlogin, spam, dll.
 Bagaimana musuh mengetahui perangkat lunak / protokol apa yang Anda jalankan?
• Probing:
 Periksa apakah sistem mendengarkan pada port yang terkenal.
 Protokol / sistem sering mengirimkan pesan spanduk awal.
• nmap dapat menebak OS dengan mengukur berbagai detail impl-spesifik.
 Ref: http://nmap.org/book/man-os-detection.html
• Gunakan DNS untuk mencari nama host untuk alamat IP; mungkin memberi
petunjuk.
• Menebak: asumsikan sistem rentan, coba eksploitasi bug.
 Bagaimana musuh mengetahui alamat IP sistem yang akan diserang?
• traceroute untuk menemukan router di sepanjang jalan, untuk serangan BGP.
• Bisa juga hanya memindai seluruh Internet: hanya 2 ^ 32 alamat.
 Tautan jaringan 1 Gbps (100 MB / dtk), paket minimum 64 byte ~ 1,5 juta paket per
detik., 2 ^ 32 = 4B paket dalam ~ 2500 detik, atau 45 menit.
 Mengapa hal-hal begitu tidak aman di tingkat TCP / IP?
• Secara historis, desainer tidak terlalu mengkhawatirkan keamanan.
 Bahkan Bellovin berkata: "Internet pada tahun 1989 adalah tempat yang jauh lebih
ramah".
 Internet Asli memiliki sejumlah kecil pengguna yang relatif dapat dipercaya.
 Persyaratan desain berubah seiring waktu.
• Argumen ujung ke ujung sedang beraksi.
 Bagaimanapun juga harus memberikan keamanan di tingkat aplikasi.
 Hal-hal yang "cukup baik" di tingkat pengangkutan untuk membiarkan aplikasi
bekerja.
• Beberapa perbaikan memang ditambahkan, tetapi hanya untuk masalah
terburuk / solusi yang lebih mudah.
 Bagaimana cara meningkatkan keamanan?
• Perbaikan yang kompatibel dengan protokol untuk implementasi TCP.
• Firewall.
 Perbaikan sebagian, tetapi banyak digunakan.
 Masalah: musuh mungkin berada dalam jaringan firewall.
 Masalah: sulit untuk menentukan apakah paket "jahat" atau tidak.
 Masalah: bahkan untuk bidang yang ada (src / dst), sulit untuk diautentikasi.
 Desain TCP / IP tidak cocok untuk teknik pemfilteran seperti firewall.
 Misalnya, fragmentasi paket IP: port TCP dalam satu paket, muatan di paket lain.
• Menerapkan keamanan di atas TCP / IP: SSL / TLS, Kerberos, SSH, dll.