Ticker

6/recent/ticker-posts

Subscribe

Haikalcctvid Channel
Haikalcctvid

Kasus Umum Serangan Jaringan

Seorang administrator jaringan tak hanya dituntut untuk membangun jaringan sesuai spesifikasi bisnis, melainkan juga membuatnya seaman mungkin bagi semua orang di dalam jaringan. 

Kasus Umum Serangan Jaringan

Tentu Anda sadar bahwa internet itu begitu luas, maka wajib hukumnya melindungi data-data dan segala aset yang ada di jaringan internal, baik pribadi maupun perusahaan. Kita perlu mengerahkan segenap kemampuan untuk melindunginya dari akses yang tidak diinginkan.

Akan tetapi, sebelum mampu mengamankan jaringan, kita perlu tahu terlebih dahulu apa saja jenis-jenis atau kasus umum serangan jaringan yang kerap menimpa suatu organisasi atau perusahaan agar ke depannya lihai dalam mengidentifikasi serangan dan lantas memproteksi jaringan secara efektif.

Serangan jaringan umumnya merupakan sebuah upaya untuk meraih akses ke suatu jaringan (acap kali jaringan internal perusahaan) dengan tujuan melancarkan aktivitas jahat, seperti mencuri data, melumpuhkan infrastruktur, dan lain-lain.

Simak beberapa contoh kasus umum terkait serangan jaringan berikut ini.


DNS Cache Poisoning

Mumpung masih hangat karena sebelumnya membahas Domain Name System, mari kita bahas serangan jaringan yang mampu menerpa DNS terlebih dahulu. Awal mula diciptakan, DNS dibentuk untuk menjadi protokol komunikasi yang terbuka dan publik, baik untuk pemerintah maupun lembaga pendidikan. Karena sifat terbukanya inilah yang menjadikannya rentan terhadap serangan siber, salah satunya adalah DNS Cache Poisoning.

Untuk mempermudah penjelasan yang akan disampaikan nanti, mari kita buat sebuah analogi. Bayangkan Anda adalah seorang mahasiswa baru yang tengah menjalani masa pengenalan lingkungan kampus di suatu universitas ternama.

Sayangnya, ada seorang senior yang luar biasa usil. Tanpa diketahui para maba (mahasiswa baru), senior tersebut mengubah semua nomor ruangan kelas yang ada di kampus. Alhasil, para mahasiswa baru yang notabene belum tahu tata letak kampus menghabiskan berhari-hari tersesat dan berulang kali masuk ke ruang kelas yang salah.

dos:701cdfb66f8c05522f7f002922cde2a820220318161535.png

Tak hanya itu, ternyata nomor ruang kelas yang salah itu pun dicatat oleh si senior ke dalam peta kampus. Wah! Ini membuat para mahasiswa baru terus menuju ke kelas yang salah. Kejadian ini akhirnya terselesaikan saat salah seorang staf kampus memperhatikan kejanggalan pada nomor ruang kelas, ia lantas memperbaiki nomor pada ruang kelas beserta peta kampus. Nah, DNS Cache Poisoning mirip seperti itu.

DNS Cache Poisoning merupakan tindak kejahatan siber yang beraksi dengan cara memasukkan informasi palsu ke dalam Recursive DNS Server cache. Dengan demikian, saat ada permintaan DNS dari client, Recursive DNS Server akan mengembalikan respons yang keliru dan pengguna pun akhirnya diarahkan ke situs web yang salah (yang sudah dikendalikan oleh si penjahat).

dos:be2d5d441d501e665cf4659d11fc1c5620220318161656.png

Apabila Anda masih bingung apa kaitannya dengan analogi sebelumnya, kami bantu jelaskan. Jadi, IP address ibarat “nomor ruang kelas” yang memungkinkan lalu lintas jaringan tiba di tempat yang tepat. Sementara itu, Recursive DNS Server adalah “peta kampus” yang menyimpan informasi nama domain dan IP address. Ketika si penjahat menyimpan informasi yang salah di sana, lalu lintas akan menuju ke tempat yang keliru sampai informasi yang tersimpan di cache diperbaiki.

Pertanyaan selanjutnya, bagaimana DNS Cache Poisoning bisa terjadi? Begini ilustrasinya. Sang penjahat menipu Recursive DNS Server cache dengan berkedok sebagai Authoritative Name Server. Jadi, pertama ia akan membuat request atau permintaan ke Recursive DNS Server, lalu memalsukan balasan saat si Recursive DNS Server melakukan proses DNS resolution (sebelum balasan resmi dari Authoritative Name Server tiba).

dos:074949f36fd5ed79caad53a8032c05d820220318161853.png

Terlebih lagi, ini terjadi karena proses DNS resolution menggunakan protokol UDP (bukan TCP) sehingga tak ada mekanisme “three-way handshake” (sudah kita pelajari di beberapa modul ke belakang) yang memverifikasi identitas perangkat.

Terlepas dari celah kerentanan dalam proses DNS resolution, serangan DNS Cache Poisoning sejatinya tidaklah mudah. Karena Recursive DNS Server akan melakukan perjalanan ke Authoritative Name Server untuk mendapatkan informasi IP address dari suatu nama domain, si penjahat hanya memiliki waktu beberapa milidetik untuk mengirim balasan palsu sebelum balasan resmi dari Authoritative Name Server tiba.

Lantas, bagaimana dong solusinya? Telah lahir ke dunia sebuah protokol DNS yang lebih aman yang disebut DNSSEC. Protokol ini bertujuan untuk memecahkan beberapa masalah, termasuk DNS Cache Poisoning. Nanti kita akan bahas lebih detail.


Denial-of-Service dan Distributed Denial-of-Service

Serangan jaringan lain yang tak kalah mengerikannya ialah Denial-of-Service (DoS) dan Distributed Denial-of-Service (DDoS). Yuk, langsung saja kita bedah keduanya.

Denial-of-Service

Serangan ini begitu mematikan, bahkan mampu melumpuhkan infrastruktur (seperti server) Anda. Untuk mengenal bagaimana serangan Denial-of-Service bekerja, mari kita ibaratkan server sebagai seorang kasir kedai kopi.

Katakanlah Anda sebagai pemilik kedai kopi mempunyai layanan pemesanan melalui telepon. Cara kerjanya, seorang kasir akan menulis pesanan dan memberikannya kepada barista. Setelah minuman tersaji, pelanggan bisa mengambilnya langsung di kedai kopi.

Namun, ada orang iseng yang menelepon beberapa kali untuk memesan kopi, tetapi ia tak pernah mengambil minumannya. Karena terus-menerus menelepon tiada henti, ini membuat kasir tak bisa menerima panggilan dari pelanggan lain.

Nah, tindakan orang iseng tersebut mirip dengan serangan Denial-of-Service (DoS). DoS adalah upaya yang dilakukan secara sengaja untuk membuat website atau aplikasi menjadi tidak bekerja optimal bagi pengguna (berasal dari satu sumber).

dos:f554403b639237b59e3f53d3715a091220220318162233.png

Salah satu contoh dari serangan DoS adalah ketika seseorang membanjiri website dengan lalu lintas jaringan yang masif sehingga membuat server yang menampung website atau aplikasi tersebut kewalahan dan tak lagi mampu merespons permintaan pengguna.

Lantas, bagaimana cara mengatasi masalah ini? Pada kasus kedai kopi, solusi sederhananya adalah dengan memblokir nomor telepon tersebut. Jika dilihat dari sudut pandang jaringan, kita bisa memblokir permintaan yang berasal dari IP address si penyerang. Nanti kita bahas lebih lanjut soal ini pemblokiran ini.

Distributed Denial-of-Service

Untuk memahami serangan ini, mari kembali ke analogi kedai kopi. Kita memang telah memblokir nomor orang iseng tersebut. Namun, ternyata orang ini meminta bantuan teman-temannya. Mereka terus-menerus menghubungi kedai kopi dengan nomor telepon yang berbeda-beda. Tentu ini akan membuat pelanggan lain semakin kesulitan untuk menelepon kedai kopi Anda. Nah, bila itu terjadi, tandanya serangan DoS sudah berevolusi menjadi Distributed Denial-of-Service (DDoS). 

Berbeda dengan DoS yang hanya berasal dari satu sumber, serangan DDoS menggunakan banyak sumber untuk melakukan serangan. Tujuannya jelas untuk membuat suatu website atau aplikasi kewalahan sehingga server yang menampungnya tak mampu lagi beroperasi. Apabila sudah seperti ini, memblokir nomor telepon atau IP address satu per satu sudah tidak lagi menjadi solusi.

dos:87078ab288f8dd54434718344efd735e20220318162333.png

Serangan ini bisa berasal dari sekelompok orang atau bahkan individu. Cara kerjanya, penyerang menggunakan beberapa komputer yang terinfeksi (juga dikenal sebagai "bot") untuk mengirimkan lalu lintas jaringan yang masif ke target.

Oke, oke. Kini kita tahu bahwa serangan ini menakutkan bukan main. Jadi, bagaimana langkah preventifnya? Karena serangan ini berupaya untuk membanjiri server (yang menampung website atau aplikasi) dengan melakukan permintaan secara berulang-ulang, maka langkah preventif yang bisa dilakukan adalah melimitasi permintaan yang masuk ke server tersebut. Ini disebut juga sebagai request rate limit. Dengan begitu, setiap client hanya dapat melakukan sejumlah request saja selama kurun waktu tertentu. Kita akan pelajari soal ini nanti.


Man-in-the-Middle

Serangan terakhir yang akan kita bahas adalah Man-in-the-Middle alias MITM. Serangan ini sangat berbahaya dan bisa terjadi pada bentuk komunikasi apa pun, baik di internet, telepon seluler, maupun peralatan komunikasi tradisional seperti surat menyurat. Dari namanya, bisakah Anda menebak seperti apa teknis serangan ini?

Mudahnya, kita bisa menganggap serangan MITM sama seperti menguping atau menyadap suatu komunikasi. Serangan ini dilakukan dengan menjadi orang yang berada di tengah komunikasi antara dua pihak. Penyerang bisa mengetahui pesan apa yang dikirim dan diterima oleh pihak yang menjadi target.

Namun, MITM bisa lebih berbahaya daripada sekadar menyadap. Menyadap merupakan bentuk serangan pasif karena penyerang hanya bisa memantau transaksi data yang lewat. Sementara itu, MITM tak hanya memantau, melainkan juga dapat mencegat dan mengubah pesan yang dikirim atau pesan yang diterima. Dengan demikian, serangan MITM dapat disebut sebagai serangan aktif.

Gambar di bawah ini merupakan contoh skenario yang bisa dilakukan penyerang dengan serangan MITM.

dos:34564a503b48fc06a5ecd6b60f43414420220318162726.jpeg

Dari gambar tersebut Anda bisa melihat betapa berbahayanya MITM ini. Budi alias penyerang bisa leluasa memata-matai (spying), mencegat (intercepting), hingga memalsukan (fabricating) dirinya menjadi Alisa dan Bobi. Pertanyaannya, mengapa ini bisa terjadi? Bagaimana caranya Budi bisa berada di dalam proses komunikasi antara Alisa dan Bobi?

Simak baik-baik. MITM paling banyak terjadi karena korban dan penyerang berada di dalam jaringan yang sama. Biasanya disebabkan oleh korban yang tidak hati-hati ketika menggunakan WiFi hotspot publik. Ketika sudah berada di jaringan yang sama, penyerang dapat secara mudah menyadap komunikasi korban dengan server melalui teknik IP spoofing atau ARP spoofing.

Setelah korban berhasil tersadap, penyerang dapat membaca seluruh aktivitas transaksi HTTP request dan response. Penyerang bisa mencuri cookie, session, access token, hingga kredensial yang hendak korban gunakan ketika login. Bahkan, akan jauh lebih parah lagi bila si penyerang sudah melakukan intercepting dan fabricating (meski untuk sampai tahap ini perlu implementasi yang rumit).

Lantas, bagaimana langkah preventif terhadap serangan MITM?

Pertanyaan yang bagus. Dalam serangan MITM, penyerang sangat mengandalkan jaringan yang digunakan korban. Jadi, langkah preventifnya adalah kita perlu berhati-hati ketika menggunakan jaringan publik. 

Langkah preventif terhadap serangan ini tak hanya dapat dilakukan oleh Anda sebagai administrator jaringan atau pengembang aplikasi, melainkan juga berlaku untuk pengguna secara umum. Berikut uraiannya.

  • Jangan gunakan Wi-Fi publik yang tidak terproteksi
    Tak jarang kita menemukkan beberapa Wi-Fi publik yang dapat diakses tanpa ada proteksi password sama sekali. Jangan pernah menggunakan Wi-Fi tersebut sebab Anda takkan pernah tahu siapa pemilik Wi-Fi sebenarnya. Mungkin saja, sebenarnya penyerang sedang memasang jebakan agar korban masuk ke dalam jaringan yang sama dengan dia.

  • Jangan pernah melakukan transaksi penting menggunakan Wi-Fi publik
    Meskipun Wi-Fi telah terproteksi dengan password, tetapi jangan pernah melakukan transaksi penting menggunakan Wi-Fi publik, apalagi aktivitas perbankan. Jika Anda ingin bertransaksi, gunakan selalu koneksi pribadi seperti jaringan seluler agar terhindar dari penyerangan MITM.

  • Mengganti password Wi-Fi secara berkala
    Jika Anda pemilik kafe dengan akses Wi-Fi publik, Anda tidak akan mengetahui apakah si penyerang berada di tengah-tengah keramaian pelanggan atau tidak. Begitu pula dengan password Wi-Fi yang digunakan, Anda tidak akan tahu apakah penyerang telah berhasil masuk ke Wi-Fi dan melakukan aksi MITM. Jadi, usahakan senantiasa mengganti password Wi-Fi secara berkala, ya.

  • Mengaktifkan Multi-Factor Authentication
    Jika aplikasi yang Anda gunakan memiliki fitur Multi-Factor Authentication (MFA), pastikan fitur tersebut selalu aktif. Sebab bila penyerang berhasil memiliki kredensial Anda, ia tetap harus menghadapi proteksi dari MFA.

Langkah preventif terhadap serangan MITM juga dapat diterapkan pada sisi aplikasi, yakni selalu menggunakan protokol yang aman seperti HTTPS. Protokol HTTPS merupakan protokol gabungan antara HTTP dengan TLS atau SSL. 

Transaksi data yang menggunakan protokol ini dilakukan secara aman karena terdapat proses enkripsi (mengubah data menjadi bentuk yang tak terbaca) pada data yang ditransaksikan. Dengan begitu, penyerang tidak akan bisa membaca data pada transaksi HTTPS sebab datanya telah terenkripsi.

dos:50b58b437b68be9aa317fcfef7afa0d020220321095447.png

Post a Comment

0 Comments