“Kemungkinan SYN flooding” di log meskipun koneksi SYN_RECV rendah

Baru-baru ini kami memiliki server apache yang merespons sangat lambat karena banjir SYN. Solusi untuk ini adalah mengaktifkan tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).

Saya memposting pertanyaan tentang ini di sini jika Anda ingin lebih banyak latar belakang.

Setelah mengaktifkan sinkronisasi kami mulai melihat pesan berikut di / var / log / pesan kira-kira setiap 60 detik:

[84440.731929] possible SYN flooding on port 80. Sending cookies.

Vinko Vrsalovic memberi tahu saya bahwa ini berarti backlog syn semakin penuh, jadi saya menaikkan tcp_max_syn_backlog menjadi 4096. Pada titik tertentu saya juga menurunkan tcp_synack_retries menjadi 3 (turun dari default 5) dengan menerbitkan sysctl -w net.ipv4.tcp_synack_retries=3. Setelah melakukan ini, frekuensinya sepertinya turun, dengan interval pesan bervariasi antara sekitar 60 dan 180 detik.

Selanjutnya saya menerbitkan sysctl -w net.ipv4.tcp_max_syn_backlog=65536, tetapi saya masih mendapatkan pesan di log.

Sepanjang semua ini saya telah menonton jumlah koneksi dalam keadaan SYN_RECV (dengan menjalankan watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), dan tidak pernah lebih tinggi dari sekitar 240, jauh lebih rendah dari ukuran backlog. Namun saya memiliki server Red Hat yang melayang di sekitar 512 (batas pada server ini adalah default 1024).

Apakah ada pengaturan tcp lain yang akan membatasi ukuran backlog atau saya menggonggong pohon yang salah? Haruskah jumlah koneksi SYN_RECV netstat -tunaberkorelasi dengan ukuran backlog?

Memperbarui

Yang terbaik yang bisa saya katakan adalah saya sedang berurusan dengan koneksi yang sah di sini, netstat -tuna|wc -lberkisar sekitar 5000. Saya telah meneliti ini hari ini dan menemukan posting ini dari karyawan last.fm, yang agak berguna.

Saya juga menemukan bahwa tcp_max_syn_backlog tidak berpengaruh ketika sinkronisasi diaktifkan (sesuai tautan ini )

Jadi sebagai langkah selanjutnya saya mengatur yang berikut ini di sysctl.conf:

net.ipv4.tcp_syn_retries = 3
        # default=5
net.ipv4.tcp_synack_retries = 3
        # default=5
net.ipv4.tcp_max_syn_backlog = 65536
        # default=1024
net.core.wmem_max = 8388608
        # default=124928
net.core.rmem_max = 8388608
        # default=131071
net.core.somaxconn = 512
        # default = 128
net.core.optmem_max = 81920
        # default = 20480

Saya kemudian mengatur tes waktu tanggapan saya, berlari sysctl -pdan menonaktifkan sinkronisasi oleh sysctl -w net.ipv4.tcp_syncookies=0.

Setelah melakukan ini, jumlah koneksi dalam keadaan SYN_RECV masih tetap sekitar 220-250, tetapi koneksi mulai tertunda lagi. Setelah saya perhatikan penundaan ini, saya mengaktifkan kembali sinkronisasi dan penundaan berhenti.

Saya percaya apa yang saya lihat masih merupakan perbaikan dari kondisi awal, namun beberapa permintaan masih tertunda yang jauh lebih buruk daripada mengaktifkan sinkronisasi. Jadi sepertinya saya terjebak dengan mereka diaktifkan sampai kita bisa mendapatkan lebih banyak server online untuk mengatasi beban. Bahkan kemudian, saya tidak yakin saya melihat alasan yang valid untuk menonaktifkannya lagi karena mereka hanya dikirim (tampaknya) ketika buffer server penuh.

Tetapi backlog syn tampaknya tidak penuh dengan hanya ~ 250 koneksi di negara SYN_RECV! Mungkinkah pesan flooding SYN adalah herring merah dan itu bukan syn_backlog yang terisi?

Jika ada yang punya opsi penyetelan lain yang belum saya coba, saya akan dengan senang hati mencobanya, tapi saya mulai bertanya-tanya apakah pengaturan syn_backlog tidak diterapkan dengan benar karena alasan tertentu.

Jadi, ini adalah pertanyaan yang rapi.

Awalnya, saya terkejut bahwa Anda melihat koneksi apa pun dalam status SYN_RECV dengan cookie SYN diaktifkan. Keindahan cookie SYN adalah Anda dapat berpartisipasi secara stateless dalam jabat tangan TCP 3-way sebagai server menggunakan kriptografi, jadi saya berharap server tidak mewakili koneksi setengah terbuka sama sekali karena itu akan menjadi kondisi yang sama seperti sedang disimpan.

Bahkan, intip sekilas sumbernya (tcp_ipv4.c) menunjukkan informasi menarik tentang bagaimana kernel mengimplementasikan cookie SYN. Pada dasarnya, meskipun dinyalakan, kernel berperilaku seperti biasanya sampai antrian koneksi yang tertunda penuh. Ini menjelaskan daftar koneksi Anda yang ada dalam status SYN_RECV.

Hanya ketika antrian koneksi tertunda penuh, DAN paket SYN lain (upaya koneksi) diterima, DAN sudah lebih dari satu menit sejak pesan peringatan terakhir, apakah kernel mengirim pesan peringatan yang telah Anda lihat ("mengirim cookie" ). Cookie SYN dikirim bahkan ketika pesan peringatan tidak; pesan peringatan hanya untuk memberi Anda kepala bahwa masalah belum hilang.

Dengan kata lain, jika Anda mematikan cookie SYN, pesan itu akan hilang. Itu hanya akan berhasil untuk Anda jika Anda tidak lagi menjadi SYN banjir.

Untuk mengatasi beberapa hal lain yang telah Anda lakukan:

• net.ipv4.tcp_synack_retries:
  • Meningkatkan ini tidak akan memiliki efek positif untuk koneksi masuk yang palsu, atau untuk yang menerima cookie SYN alih-alih keadaan sisi server (tidak ada retries untuk mereka juga).
  • Untuk koneksi spoofed yang masuk, meningkatkan ini meningkatkan jumlah paket yang Anda kirim ke alamat palsu, dan mungkin jumlah waktu bahwa alamat spoof tetap di tabel koneksi Anda (ini bisa menjadi efek negatif yang signifikan).
  • Di bawah beban normal / jumlah koneksi masuk, semakin tinggi ini, semakin besar kemungkinan Anda dengan cepat / berhasil menyelesaikan koneksi melalui tautan yang menjatuhkan paket. Ada pengembalian yang semakin berkurang untuk meningkatkan ini.
• net.ipv4.tcp_syn_retries: Mengubah ini tidak dapat memiliki efek pada koneksi masuk (hanya mempengaruhi koneksi keluar)

Variabel lain yang Anda sebutkan belum saya teliti, tetapi saya menduga jawaban untuk pertanyaan Anda cukup banyak di sini.

Jika Anda tidak dibanjiri SYN dan mesin responsif terhadap koneksi non-HTTP (mis. SSH) Saya pikir mungkin ada masalah jaringan, dan Anda harus meminta teknisi jaringan untuk membantu Anda melihatnya. Jika mesin ini umumnya tidak responsif bahkan ketika Anda sedang tidak dibanjiri SYN, itu terdengar seperti masalah beban yang serius jika itu mempengaruhi penciptaan koneksi TCP (level yang cukup rendah dan sumber daya tidak intensif)

Saya menghadapi masalah yang persis sama pada instalasi baru Ubuntu Oneiric 11.10 menjalankan server web (apache2) dengan situs web yang sarat muatan. Di Ubuntu Oneiric 11.10 sinkronisasi diaktifkan secara default.

Saya memiliki pesan-pesan kernel yang sama yang menyatakan kemungkinan serangan banjir SYN pada port server web:

kernel: [739408.882650] TCP: Kemungkinan SYN membanjiri port 80. Mengirim cookie.

Pada saat yang sama, saya cukup yakin, bahwa tidak ada serangan yang terjadi. Saya menerima pesan ini pada interval 5 menit. Ini tampak seperti mengintip beban, karena penyerang akan menjaga beban tinggi sepanjang waktu, ketika mencoba untuk membuat server berhenti merespons permintaan.

Menyetel net.ipv4.tcp_max_syn_backlogparameter tidak menyebabkan peningkatan apa pun - pesan berlanjut pada tingkat yang sama. fakta bahwa jumlah koneksi SYN_RECV selalu sangat rendah (dalam kasus saya di bawah 250) adalah indikator, bahwa harus ada beberapa parameter lain, yang bertanggung jawab atas pesan ini.

Saya telah menemukan pesan bug ini https://bugzilla.redhat.com/show_bug.cgi?id=734991 di situs topi merah yang menyatakan bahwa pesan kernel dapat disebabkan oleh bug (atau kesalahan konfigurasi) di sisi aplikasi . Tentu saja pesan log sangat menyesatkan! Karena ini bukan parameter kernel yang bertanggung jawab dalam kasus itu, tetapi parameter aplikasi Anda, sebelum diteruskan ke kernel.

Jadi kita juga harus melihat parameter konfigurasi aplikasi server web kita. Ambil dokumen apache dan buka http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog

Nilai default ListenBacklogparameter adalah 511. (Ini sesuai dengan jumlah koneksi, yang telah Anda amati di server Red Hat Anda. Server Anda yang lain mungkin memiliki angka yang lebih rendah dikonfigurasi.)

Apache memiliki parameter konfigurasi sendiri untuk antrian backlog untuk koneksi yang masuk. jika Anda memiliki banyak koneksi masuk, dan setiap saat (seperti hal acak) mereka tiba bersama pada waktu yang hampir bersamaan, sehingga server web tidak dapat melayani mereka dengan cukup cepat dengan cara yang sesuai, jaminan simpanan Anda akan penuh dengan 511 koneksi dan kernel akan menjalankan pesan di atas yang menyatakan kemungkinan serangan banjir SYN.

Untuk mengatasi ini, saya menambahkan baris berikut ke /etc/apache2/ports.confatau salah satu file .conf lainnya, yang akan dimuat oleh apache ( /etc/apache2/apache2.confharus juga ok):

ListenBackLog 5000

Anda juga harus mengatur nilai net.ipv4.tcp_max_syn_backlogyang masuk akal. dalam pemahaman saya, maksimal kernel akan membatasi nilai, bahwa Anda akan dapat mengkonfigurasi dalam konfigurasi apache. jadi jalankan:

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

Setelah menyetel konfigurasi, jangan lupa untuk me-restart apache Anda:

sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )

Dalam kasus saya, perubahan konfigurasi ini segera menghentikan peringatan kernel. Saya dapat mereproduksi pesan dengan menetapkan nilai ListenBackLog yang rendah di konfigurasi apache.

Setelah beberapa pengujian dengan kernel 3.4.9 jumlah koneksi SYN_RECV di netstat tergantung pada

• /proc/sys/net/core/somaxconn dibulatkan ke kekuatan 2 berikutnya (mis. 128 -> 256)
• 75% /proc/sys/net/ipv4/tcp_max_syn_backlogjika /proc/sys/net/ipv4/tcp_syncookiesdiatur ke 0atau 100% jika /proc/sys/net/ipv4/tcp_syncookiesdiatur ke1
• ListenBackLog dalam konfigurasi apache dibulatkan ke kekuatan 2 berikutnya (mis. 128 -> 256)

minimum setiap parameter ini digunakan. Setelah mengubah somaxconn atau apache ListenBackLog harus dihidupkan ulang.

Dan setelah meningkatkan apache tcp_max_syn_backlog juga harus dimulai ulang.

Tanpa tcp_syncookies, apache memblokir, mengapa dalam hal ini hanya 75% dari tcp_max_syn_backlog adalah batas yang aneh. dan meningkatkan parameter ini meningkatkan koneksi SYN_RECV ke 100% dari nilai lama tanpa memulai ulang apache.