SYN flood: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
k r2.7.2) (bot Menambah: tr:SYN saldırısı |
Fitur saranan suntingan: 3 pranala ditambahkan. |
||
| (15 revisi perantara oleh 10 pengguna tidak ditampilkan) | |||
Baris 1:
[[Image:Tcp normal.svg|thumb|Koneksi normal antara pengguna ([[Alice and Bob|Alice]]) dan server. Jabat tangan tiga arah dilakukan dengan benar.]]
[[Image:Tcp synflood.png|thumb|SYN Flood. Penyerang ([[Alice and Bob|Mallory]]) mengirimkan beberapa paket tetapi tidak mengirim "ACK" kembali ke server. Karena itu, koneksi setengah terbuka dan menghabiskan sumber daya server. Alice, pengguna yang sah, mencoba untuk terhubung tetapi server menolak untuk membuka koneksi yang mengakibatkan penolakan layanan.]]
Sebuah '''SYN flood''' adalah bentuk [[Serangan DoS|serangan penolakan layanan]] di mana penyerang dengan cepat memulai koneksi ke server tanpa menyelesaikan koneksi. Server harus menghabiskan sumber daya menunggu koneksi yang setengah terbuka, yang dapat menghabiskan sumber daya yang cukup untuk membuat sistem tidak responsif terhadap lalu lintas yang sah.<ref>{{cite web |title=CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks |url=https://resources.sei.cmu.edu/asset_files/WhitePaper/1996_019_001_496172.pdf#page=123 |website=Carnegie Mellon University Software Engineering Institute |archive-url=https://web.archive.org/web/20001214111600/https://www.cert.org/advisories/CA-1996-21.html |archive-date=2000-12-14 |access-date=18 September 2019 |url-status=live}}</ref><ref>[https://partners.nytimes.com/library/cyber/week/0914panix.html New York's Panix Service Is Crippled by Hacker Attack], New York Times, September 14, 1996</ref>
[[Paket jaringan|Paket]] yang dikirimkan penyerang adalah paket <code>[[Paket protokol internet#Pembentukan koneksi|SYN]]</code>, bagian dari [[Protokol Kendali Transmisi#Pembentukan koneksi|jabat tangan tiga arah]] [[TCP]] yang digunakan untuk membuat sambungan.<ref>{{cite web |title=What is a DDoS Attack? |url=https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/ |website=Cloudflare.com |publisher=Cloudflare |accessdate=4 May 2020}}</ref>
== Detail teknis ==
Ketika klien mencoba untuk memulai koneksi TCP ke server, klien dan server bertukar serangkaian pesan yang biasanya berjalan seperti ini:
# Klien meminta koneksi dengan mengirimkan pesan <code>SYN</code> (''synchronize'') ke server.
# Server ''menerima'' permintaan ini dengan mengirim kembali <code>SYN-ACK</code> ke klien.
# Klien menanggapi dengan <code>ACK</code>, dan sambungan dibuat.
Ini disebut [[Protokol Kendali Transmisi#Pembentukan koneksi|jabat tangan tiga arah TCP]], dan merupakan fondasi untuk setiap koneksi yang dibuat menggunakan protokol TCP.
Sebuah serangan SYN flood bekerja dengan tidak menanggapi server dengan kode <code>ACK</code> yang diharapkan. Klien jahat bisa saja tidak mengirim <code>ACK</code> yang diharapkan, atau dengan spoofing [[alamat IP]] sumber di <code>SYN</code>, menyebabkan server mengirim <code>SYN-ACK</code> ke alamat IP yang dipalsukan – yang tidak akan mengirim <code>ACK</code> karena itu "tahu" bahwa ia tidak pernah mengirim <code>SYN</code>.
Server akan menunggu pemberitahuan untuk beberapa waktu, karena kemacetan jaringan sederhana juga bisa menjadi penyebab <code>ACK</code> hilang. Namun, dalam sebuah serangan, ''[[TCP setengah terbuka|koneksi setengah terbuka]]'' yang dibuat oleh klien jahat mengikat sumber daya di server dan pada akhirnya dapat melebihi sumber daya yang tersedia di server. Pada titik itu, server tidak dapat terhubung ke klien mana pun, baik yang sah atau tidak. Ini secara efektif menolak layanan kepada klien yang sah. Beberapa sistem juga dapat mengalami kegagalan fungsi atau crash ketika fungsi [[sistem operasi]] lain kekurangan sumber daya dengan cara ini.
== Penanggulangan ==
Ada beberapa cara yang dapat dilakukan untuk mencegah dan mengurangi efek dari <nowiki>''</nowiki>SYN Flooding<nowiki>''</nowiki>, yakni sebagai berikut:▼
▲Ada beberapa cara yang dapat dilakukan untuk mencegah dan mengurangi efek dari ''SYN Flooding'', yakni sebagai berikut:
* Meningkatkan ukuran buffer koneksi TCP untuk meningkatkan jumlah percobaan pembuatan koneksi yang dapat dilakukan secara simultan. Hal ini memang menjadi solusi sementara, karena penyerang juga mungkin meningkatkan ukuran paket SYN yang ia kirimkan untuk memenuhi buffer tersebut.
* Mengurangi nilai waktu kapan sebuah percobaan pembuatan koneksi TCP menjadi "timed-out". Hal ini juga menjadi solusi sementara, apalagi jika jaringan di mana sistem berada sangat sibuk atau lambat.
* Mengimplementasikan [[
* Memantau ''[[firewall]]'' dan mengonfigurasikannya untuk memblokir serangan ''SYN flood'' ketika hal tersebut terjadi. Pendekatan ini merupakan pendekatan yang sering dilakukan oleh banyak organisasi, apalagi jika ditambah dengan [[Intrusion Prevention System|''Intrusion Prevention System'' (IPS)]], meski hal ini membutuhkan kejelian dari seorang [[administrator jaringan]] untuk memantau catatan (''log'') dari IPS dan ''firewall'' yang ia atur. Bahkan, dengan kedua perangkat tersebut, klien-klien yang valid dapat ditolaknya karena konfigurasi yang tidak benar.
Ada sejumlah tindakan pencegahan terkenal yang terdaftar di RFC 4987 termasuk:
# Penyaringan
# Meningkatkan backlog
# Mengurangi timer SYN-RECEIVED
# Mendaur ulang [[TCP setengah terbuka]] terlama
# Cache SYN
# [[SYN cookies]]
# Pendekatan Hybrid
# Tembok api dan proxy
== Lihat pula ==<!-- HARAP HORMATI ORDER ALFABETIS -->
* [[Denial-of-service attack|Serangan Denial-of-service]]
* [[Serangan Fraggle]]
* [[Internet Control Message Protocol]]
* [[Spoofing alamat IP]]
* [[Serangan Smurf|Serangan smurf]]
== Referensi ==
<references />
== Pranala luar ==
* [http://www.cert.org/advisories/CA-1996-21.html Penasihat CERT resmi tentang Serangan SYN]
[[Kategori:Serangan penolakan layanan]]
▲[[cs:SYN flood]]
▲[[el:SYN flood]]
| |||