SYN Flood Attack Adalah: Cara Kerja, Ciri & Mengatasinya

Setiap kali seseorang membuka website Anda, komputernya tidak langsung meminta halaman. Ia lebih dulu berkenalan dengan server lewat tiga langkah bolak-balik, dan selama itu server menyisihkan satu slot di sebuah daftar tunggu yang jumlah barisnya terbatas.

Selama semua orang menyelesaikan perkenalannya, slot terus berputar dan daftar tidak pernah penuh. SYN flood attack adalah serangan yang mempermainkan tepat satu titik itu: penyerang memulai ribuan perkenalan, lalu tidak menyelesaikan satu pun. Slot tertahan, daftar tunggu penuh, dan pengunjung berikutnya tidak kebagian tempat.

SYN Flood Attack Adalah Serangan pada Antrean Koneksi

SYN flood attack adalah serangan penolakan layanan (denial of service, disingkat DoS) yang menghabiskan antrean koneksi setengah terbuka pada sebuah port. Caranya dengan mengirim banyak permintaan koneksi yang sengaja tidak diselesaikan. Nama lainnya SYN flooding atau TCP SYN flood, dan ketiganya merujuk mekanisme yang sama. Karena yang dipermainkan adalah protokol TCP, serangan ini tergolong serangan lapis transport, yaitu layer 4 pada model OSI.

Dua hal perlu diluruskan sejak awal karena sering tertukar. Pertama, sasarannya bukan lebar jalur data, melainkan sebuah pencacah di dalam sistem operasi server. Jalur internet Anda bisa jadi masih lapang ketika layanan sudah berhenti melayani.

Kedua, serangan ini tidak mengambil apa pun. Dari tiga hal yang dijaga dalam keamanan informasi — kerahasiaan, keutuhan, dan ketersediaan — SYN flood hanya menyerang ketersediaan (availability). Berkas dan database Anda utuh, hanya saja tidak ada yang bisa masuk.

Teknik ini juga bukan barang baru. Kelemahannya ditemukan Bill Cheswick dan Steve Bellovin sekitar 1994, lalu dipublikasikan luas pada 1996 bersama kode contohnya di majalah Phrack. Pada September 1996, serangan terhadap mail server sebuah penyedia internet membuat CERT menerbitkan peringatan resmi. Tiga puluh tahun kemudian cara yang sama masih dipakai.

Arti SYN dan Titik Rapuh Jabat Tangan TCP

SYN adalah singkatan dari synchronize (menyelaraskan), sebuah bit penanda di header TCP. Isinya satu pesan: "saya ingin membuka koneksi baru, dan nomor urut saya dimulai dari sini". Setiap koneksi TCP menuju port layanan Anda dimulai dengan bit tersebut.

Perkenalan lengkapnya disebut three-way handshake (jabat tangan tiga langkah):

1. SYN — klien mengirim permintaan koneksi berisi nomor urut awalnya.
2. SYN-ACK — server menyatakan siap sekaligus mengirim nomor urutnya sendiri. Di titik inilah ia menyisihkan satu slot dan menunggu.
3. ACK — klien mengonfirmasi. Koneksi resmi terbuka dan slot dilepaskan.

Selama menunggu langkah ketiga, koneksi berada dalam keadaan half-open (setengah terbuka). Sistem operasi menandainya dengan status SYN_RECV dan menyimpannya di sebuah daftar bernama backlog.

Penyerang cukup berhenti di langkah kedua. Ia mengirim SYN, menerima SYN-ACK, lalu diam. ACK yang ketiga tidak pernah datang. Server tidak bisa membedakan diam yang disengaja dari jaringan yang sedang buruk. Ia melakukan apa yang seharusnya: menunggu sambil mengirim ulang SYN-ACK sebelum menyerah.

Jabat tangan TCP normal selesai di ACK ketiga, sedangkan pada SYN flood ACK tidak dikirim dan slot tertahan 63 detik.

Pada Linux dengan setelan bawaan, penantian itu berlangsung 63 detik. Nilai tcp_synack_retries bawaannya 5, sehingga SYN-ACK dikirim ulang pada detik ke-1, 3, 7, 15, dan 31, lalu slot dibebaskan pada detik ke-63. Selama satu menit lebih itu, satu slot terkunci oleh satu paket.

Hitungan yang Membuat Serangan Ini Sangat Murah

Angka-angka di atas terdengar abstrak sampai dihitung. Dokumentasi kernel Linux menyebut satu entry SYN_RECV memakan sekitar 304 byte memori. Dari dua angka itu — 304 byte dan 63 detik — seluruh sifat serangan ini bisa diturunkan.

Mulai dari sisi memori. Antrean berisi 1.024 slot hanya memakan 304 KiB, dan antrean ekstrem berisi 65.536 slot pun hanya sekitar 19 MiB.

Kesimpulan yang mengikuti sering dilewatkan: SYN flood bukan serangan penghabis RAM. Yang habis adalah pencacah antreannya, bukan memorinya. Server dengan RAM 32 GB tetap berhenti melayani begitu batas backlog tersentuh.

Sekarang dari sisi penyerang. Karena setiap slot bertahan 63 detik, menjaga antrean 1.024 slot tetap penuh hanya membutuhkan sekitar 16 paket per detik. Sebuah paket SYN berukuran 40 sampai 60 byte. Dengan overhead Ethernet, laju itu setara sekitar 10 kbps, lebih kecil daripada koneksi dial-up tahun 1996.

Tiga ukuran antrean, beserta laju paket yang dibutuhkan untuk menahannya tetap penuh:

Inilah ketimpangan yang membuat teknik berumur tiga dekade masih berguna. Penyerang tidak perlu botnet, jalur besar, maupun celah keamanan. Ia hanya perlu tahu satu nomor port yang sedang terbuka.

Ketimpangan SYN flood: 16 paket per detik setara 10 kbps membekukan 1.024 slot antrean yang hanya memakai 304 KiB.

Sistem modern memang lebih longgar daripada masa RFC 4987 ditulis, ketika backlog bawaan masih berkisar belasan. Nilai somaxconn di Linux kini 4.096, naik dari 128 sebelum kernel 5.4 — kenaikan yang menggeser angka di kolom terakhir, bukan menghapus ketimpangannya.

Tiga Bentuk SYN Flood yang Ditemui di Lapangan

Ketimpangan biaya tadi dimanfaatkan dengan tiga cara, dan membedakannya menentukan pertahanan mana yang masuk akal.

1. Alamat sumber dipalsukan: penyerang mengisi kolom alamat pengirim dengan alamat IP acak milik orang lain. SYN-ACK dikirim ke alamat-alamat itu dan tidak pernah dibalas. Paling murah sekaligus paling sulit dilacak, karena jejak di log server bukan milik penyerang.
2. Dari satu sumber nyata: penyerang memakai alamatnya sendiri, tetapi memblokir balasan di sisinya supaya sistem operasinya tidak mengirim paket RST yang justru akan melepaskan slot. Jarang dipakai karena alamatnya langsung terbaca.
3. Terdistribusi lewat botnet: ribuan perangkat yang sudah dikuasai mengirim SYN dari alamatnya masing-masing. Inilah yang paling sulit disaring, karena setiap paketnya sah secara teknis dan berasal dari alamat yang benar-benar ada. Sumbernya biasanya router rumahan, kamera pengawas, dan perangkat internet of things yang tidak pernah diperbarui — sisi lain dari cara kerja sebuah botnet.

Bentuk ketiga inilah yang biasa disebut DDoS SYN flood attack, dan yang menempatkan teknik ini sebagai salah satu bentuk serangan DDoS. Satu fakta layak diketahui pembaca Indonesia. Dalam laporan Cloudflare paruh pertama 2026, Indonesia bertahan sebagai sumber serangan DDoS terbesar ketiga di dunia selama dua kuartal berturut-turut. Perangkat di sekitar kita lebih sering menjadi pelaku tak sadar daripada korban.

Cara Memastikan Server Anda Sedang Kena SYN Flood

Layanan yang lambat bisa disebabkan banyak hal. Sebelum menyetel apa pun, pastikan gejalanya memang cocok lewat empat pemeriksaan berikut.

Pertama, hitung jumlah koneksi yang tertahan di status SYN_RECV:

ss -H -n -t state syn-recv | wc -l

Pada server sehat angkanya nol sampai belasan. Angka yang menempel di ratusan atau ribuan dan tidak turun adalah tanda kuat. Opsi -H mematikan baris judul, supaya hitungannya tidak kelebihan satu.

Bandingkan angka itu dengan koneksi yang benar-benar jadi lewat ss -H -n -t state established | wc -l. Pada trafik wajar jumlah koneksi mapan jauh melebihi yang setengah terbuka; saat diserang perbandingannya terbalik. Perintah netstat lama juga bisa dipakai, meski kini sudah digantikan ss.

Kedua, periksa penghitung kernel yang mencatat peristiwa ini:

netstat -s | grep -iE 'syncookies|listen'

Baris SyncookiesSent yang bertambah berarti antrean pernah penuh dan kernel memakai pertahanan cadangan, sedangkan ListenOverflows dan ListenDrops menunjukkan permintaan yang sudah dibuang. Jalankan dua kali berjeda sepuluh detik lalu bandingkan selisihnya; angka mutlaknya kurang berarti karena dihitung sejak server menyala.

Ketiga, lihat pesan kernel:

dmesg -T | grep -i 'syn flooding'

Pesannya berbentuk Possible SYN flooding on port 443. Sending cookies., atau berakhiran Dropping request. bila pertahanan cadangannya dimatikan.

Perlu diperhatikan: kernel hanya mencetak peringatan ini sekali untuk setiap socket yang mendengarkan. Tidak adanya pesan baru bukan bukti serangan sudah berhenti. Untuk memantau kondisi berjalan, gunakan penghitung pada pemeriksaan kedua, bukan isi log.

Keempat, rekam paketnya kalau tiga pemeriksaan tadi belum meyakinkan. Perintah berikut hanya menangkap paket pembuka koneksi, yaitu yang membawa bit SYN tanpa ACK:

tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' -c 200

Ganti eth0 dengan nama antarmuka jaringan Anda. Saat diserang, alamat sumber berganti hampir di setiap baris dan tidak satu pun disusul paket lanjutan. Simpan rekamannya ke berkas .pcap lewat opsi -w bila ingin diperiksa lebih teliti di Wireshark, memakai filter tampilan tcp.flags.syn == 1 && tcp.flags.ack == 0.

Kalau keempat pemeriksaan menunjuk arah yang sama, yang Anda hadapi memang SYN flood dan bukan lonjakan pengunjung.

SYN Cookies dan Apa yang Ditukar Dengannya

Pertahanan paling elegan terhadap serangan ini ditemukan Daniel J. Bernstein dan Eric Schenk pada September 1996, beberapa minggu setelah serangan yang memicu peringatan CERT. Namanya SYN cookies, dan gagasannya sederhana: kalau menyimpan status koneksi adalah sumber masalah, jangan menyimpannya sama sekali.

Server memampatkan status yang dibutuhkan ke dalam nomor urut pada SYN-ACK. Nomor itu disusun dari stempel waktu, ukuran segmen maksimum, dan hash kriptografis atas pasangan alamat dan port. Koneksinya lalu dilupakan sepenuhnya, tanpa satu slot pun terpakai. Ketika ACK ketiga datang, nomor yang dipantulkan klien cukup untuk menyusun ulang koneksinya. Kalau ACK tidak datang, tidak ada yang perlu dibersihkan.

Di sinilah letak kesalahpahaman yang paling sering muncul. Banyak panduan menempatkan "aktifkan SYN cookies" sebagai langkah pertama, padahal dokumentasi kernel Linux menyatakan tcp_syncookies bernilai 1 secara bawaan. Fitur itu sudah menyala di server Anda sejak hari pertama.

sysctl net.ipv4.tcp_syncookies

Yang perlu diperiksa bukan apakah ia menyala, melainkan apakah ia terpicu — dijawab penghitung SyncookiesSent pada bagian sebelumnya.

Sifat kedua yang jarang disebut adalah harganya. SYN cookies bukan kapasitas yang bisa dinaikkan, melainkan jaring pengaman yang menukar kelengkapan protokol dengan ketahanan. Dokumentasi kernel menyatakannya tanpa basa-basi: fitur ini melanggar protokol TCP secara serius, tidak mengizinkan pemakaian ekstensi TCP, dan dapat menurunkan kualitas layanan seperti SMTP relaying. Penutupnya yang paling penting — gejalanya tidak terlihat oleh Anda, melainkan oleh klien dan server relay yang menghubungi Anda.

Alasannya ada pada ruang yang tersedia. Nomor urut hanya 32 bit, sebagian sudah habis untuk stempel waktu dan hash. RFC 4987 mencatat ukuran segmen maksimum umumnya dipadatkan ke dua bit, sehingga hanya empat nilai bisa diwakili. Ekstensi seperti window scaling dan selective acknowledgement tidak kebagian ruang, dan pada koneksi jarak jauh berkecepatan tinggi hilangnya keduanya terasa sebagai transfer yang lebih lambat. Karena itu SYN cookies dirancang menyala hanya saat antrean benar-benar penuh.

Menyetel Pertahanan Tambahan di Server Linux

Cara mengatasi SYN flood dari sisi server terbagi dalam empat langkah berikut, diurutkan dari yang paling aman ke yang paling berdampak. Seluruhnya menuntut akses root, jadi hanya tersedia bagi pengguna VPS atau dedicated server.

Pertahanan SYN flood: SYNPROXY dan CSF bekerja di firewall, tcp_max_syn_backlog dan tcp_synack_retries di kernel.

Langkah #1: Perlebar antrean koneksi

Dua nilai bekerja berpasangan: tcp_max_syn_backlog mengatur jumlah koneksi setengah terbuka yang diingat, somaxconn membatasi antrean koneksi jadi yang menunggu diambil aplikasi. Menaikkan salah satu saja tidak banyak menolong.

sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=8192

Angka 8.192 memadai untuk web server bertrafik menengah, dan biayanya mudah dihitung: 8.192 dikali 304 byte, sekitar 2,4 MiB. Nilai bawaannya menyesuaikan besar memori mesin, jadi periksa dulu sebelum menaikkan.

Langkah #2: Persingkat masa tunggu

Menurunkan tcp_synack_retries dari 5 ke 2 memperpendek penantian dari 63 detik menjadi 7 detik. Slot berputar sembilan kali lebih cepat, sehingga antrean yang sama menampung lebih banyak koneksi asli.

sysctl -w net.ipv4.tcp_synack_retries=2

Harganya nyata. Klien di jaringan seluler yang buruk kadang butuh lebih dari 7 detik untuk membalas, dan koneksi mereka akan gagal lalu harus diulang. Jangan turunkan sampai 1, dan pantau kegagalan koneksi setelahnya.

Langkah #3: Simpan perubahannya

Perubahan lewat sysctl -w hilang saat server dinyalakan ulang, jadi tulis ke berkas konfigurasi:

cat >> /etc/sysctl.d/99-synflood.conf <<'EOF'
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_synack_retries = 2
EOF
sysctl --system

Langkah #4: Pindahkan jabat tangan ke firewall

Cara terakhir memindahkan beban ke firewall di depan aplikasi. Untuk beban yang jauh lebih besar, iptables punya target SYNPROXY. Seluruh jabat tangan dipindahkan ke firewall, sehingga aplikasi baru melihat koneksi setelah ACK ketiga terbukti datang. Red Hat mencatat peningkatan sekitar sepuluh kali lipat dibanding tanpa perlindungan.

iptables -t raw -I PREROUTING -p tcp --syn --dport 443 -j CT --notrack
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate INVALID,UNTRACKED \
  -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

SYNPROXY bersandar pada SYN cookies dan stempel waktu TCP, jadi keduanya harus aktif, dan net.netfilter.nf_conntrack_tcp_loose perlu bernilai 0 agar ACK penutup tidak dianggap koneksi baru. Uji di luar jam sibuk, karena aturan yang salah urutan bisa memutus seluruh trafik ke port tersebut.

Pengguna cPanel atau WHM punya jalur lebih ringkas lewat CSF Firewall. Setelan SYNFLOOD di /etc/csf/csf.conf bawaannya 0 alias mati, dengan SYNFLOOD_RATE di 100/s dan SYNFLOOD_BURST di 150. Dokumentasi CSF menganjurkan menyalakannya hanya ketika Anda memang sedang diserang, karena setelan itu memperlambat semua koneksi baru dari alamat mana pun begitu terpicu.

Kalau gerbang jaringan Anda memakai MikroTik, padanannya ada di menu /ip settings. Ada satu perbedaan penting dari Linux di sini: dokumentasi RouterOS mencatat tcp-syncookies bernilai no secara bawaan, jadi pada perangkat ini menyalakannya benar-benar mengubah sesuatu.

/ip settings set tcp-syncookies=yes

Batas Pertahanan yang Perlu Anda Pahami

Empat batas berikut menentukan sejauh mana penyetelan di atas menolong.

Pertama, tidak semua orang memegang tuas ini. Pengguna shared hosting tidak punya akses sysctl maupun iptables; keputusannya ada di tangan penyedia, dan itu memang bagian dari yang Anda bayar. Kalau Anda perlu mengaturnya sendiri, jenis layanannya yang harus berubah.

Kedua, pembatasan laju menghasilkan salah tangkap. Ribuan pelanggan satu operator seluler bisa keluar lewat segelintir alamat yang sama. Batas 100/s yang terdengar longgar pun bisa menjatuhkan pengunjung asli di jam ramai. Setiap angka pembatasan adalah taruhan antara menahan penyerang dan menolak pembeli.

Ketiga, penyetelan kernel tidak menolong melawan serangan volumetrik. Kalau bandwidth server dijenuhkan puluhan gigabit per detik, paketnya sudah hilang di jaringan hulu sebelum kernel sempat menghitungnya. Pada skala itu yang dibutuhkan adalah penyaringan di hulu, biasanya lewat CDN atau layanan penyaringan penyedia.

Keempat, SYN flood bukan lagi ancaman terbesar. Dalam laporan Cloudflare kuartal ketiga 2025, SYN flood menempati urutan ketiga vektor serangan lapis jaringan, di bawah UDP flood dan DNS flood. Menyempurnakan pertahanan SYN sambil mengabaikan lapis lain adalah pekerjaan yang tidak seimbang.

Pertanyaan yang Sering Diajukan

Apa itu flooding attack?

Flooding attack adalah serangan yang membanjiri sasaran dengan permintaan sampai kapasitasnya habis. Yang membedakan jenisnya adalah sumber daya yang dihabiskan: SYN flood menghabiskan antrean koneksi, UDP flood menghabiskan jalur data, HTTP flood menghabiskan kemampuan aplikasi memproses permintaan.

Apa arti SYN dalam jaringan?

SYN berasal dari kata synchronize, bit penanda di header TCP yang menyatakan permintaan membuka koneksi baru sekaligus mengumumkan nomor urut awal pengirim. Ia adalah paket pertama dari tiga langkah jabat tangan TCP.

Elemen keamanan mana yang dilanggar SYN flood attack?

Ketersediaan atau availability, satu dari tiga elemen triad CIA. Kerahasiaan dan keutuhan data tidak tersentuh, karena penyerang tidak pernah masuk ke sistem maupun mengubah isinya.

Langkah jabat tangan mana yang tidak pernah diselesaikan?

Langkah ketiga, yaitu paket ACK dari klien. Server sudah mengirim SYN-ACK lalu menunggu konfirmasi yang tidak pernah tiba, sehingga koneksi tertahan di status SYN_RECV.

Apakah SYN cookies perlu saya nyalakan sendiri?

Pada Linux modern tidak perlu, karena net.ipv4.tcp_syncookies sudah bernilai 1 secara bawaan. Yang layak diperiksa adalah seberapa sering ia terpicu, lewat penghitung SyncookiesSent pada keluaran netstat -s.

Kenapa pengguna shared hosting tidak bisa menyetel apa pun?

Antrean koneksi dimiliki oleh satu sistem operasi yang dipakai bersama semua akun di server itu, bukan oleh akun Anda. Karena satu nilai berlaku untuk semua penghuni, penyetelannya dipegang penyedia hosting.

Kesimpulan

SYN flood attack adalah serangan yang menyasar antrean koneksi, bukan lebar jalur data dan bukan isi data Anda. Kekuatannya berasal dari ketimpangan biaya yang bisa dihitung: sekitar 10 kbps dari sisi penyerang sudah cukup untuk membekukan antrean seribu slot selama satu menit lebih.

Kabar baiknya, pertahanan utamanya sudah menyala di server Linux Anda sejak awal. Urutan kerja yang masuk akal karena itu bukan menyalakan SYN cookies, melainkan memastikan ia terpicu lewat penghitung kernel. Setelah itu perlebar antrean secukupnya, persingkat masa tunggu, lalu pindahkan jabat tangan ke firewall bila bebannya menuntut. Untuk serangan berskala besar, penyaringan di hulu tetap tidak tergantikan.

Semoga artikel ini membantu.