Haruskah saya menilai paket batas dengan iptables?


8

Saya menggunakan iptables di Server Ubuntu. Ini adalah server web pada VPS.
Saya ingin tahu apakah saya harus menilai paket batas. Jika demikian, apa yang harus saya nilai-batas? Dan haruskah saya melakukannya secara global atau per alamat IP?

Referensi yang
saya lihat orang menyarankan ini:

# Limit packet traffic on a TCP or UDP port:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

# Limit established/related packet traffic:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

Di atas, batas tingkat global tampaknya tidak terlalu berguna, setidaknya untuk kasus yang dapat saya bayangkan. Apakah ada kasus di mana saya harus menilai-batas secara global?
Saya percaya bahwa batas tingkat per IP biasanya lebih baik:

# Add the IP to the list:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --set --name RATELIMITED
# Drop if exceeded limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --update --seconds $sec --hitcount $hc --rttl --name RATELIMITED -j DROP
# Accept if inside limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -j ACCEPT

Pertanyaan tambahan: IP jarak jauh mungkin palsu. Bagaimana cara membatasi mereka dengan benar?
Menambahkan pertanyaan lain untuk ini:
/server/340258/how-to-rate-limit-spoofed-ips-with-iptables

Tujuan
saya mencoba mengurangi risiko beberapa serangan D / DoS dan penyalahgunaan umum.

Terkait
Bagaimana cara saya menilai batas koneksi SSH dengan iptables?

PS : Saya baru saja membuka pertanyaan terkait hanya untuk ICMP dan itu termasuk pembatasan tingkat untuk protokol ini: iptables | Jenis ICMP: yang mana (berpotensi) berbahaya?

Jawaban:


6

Batas tingkat bukanlah pencegahan melainkan undangan untuk DoS - terutama dalam rasa yang disajikan di atas di mana paket akan turun jika tingkat tertentu dari paket yang tidak diautentikasi tanpa informasi negara telah terlampaui. Karena semua orang dapat memalsukan paket (termasuk alamat IP sumber) pada keadaan koneksi ini tanpa usaha yang lebih besar, vektor serangan DoS baru yang meningkatkan fasilitas batas tarif Anda akan muncul.

Batas tarif umumnya hanya masuk akal jika Anda memilikinya

  1. baik batas keras atau koneksi lunak yang dapat diprediksi dalam konfigurasi Anda
  2. atur batas tarif untuk lalu lintas umum di bawah batas ini agar dapat mengatur koneksi untuk lalu lintas prioritas atau administrasi terlepas dari bebannya

Meskipun 1. sering kali cukup sulit untuk dipastikan mengganggu, 2. jelas hanya akan berfungsi jika Anda dapat membedakan lalu lintas "prioritas atau administratif" dari yang lain saat pengaturan sambungan - mis. Jika datang melalui antarmuka jaringan yang berbeda.

Dalam kasus lain, itu lebih baik mengurangi ketahanan sistem Anda daripada menambahnya.


Hai syneticon-dj. Saya memahami dan setuju bahwa firewall yang salah konfigurasi adalah alat lain untuk serangan DoS. Terimakasih atas peringatannya!
ML--

Pembatasan laju per-ip atau per-ip-port juga masuk akal ketika mempertahankan dari lalu lintas yang sah yang terlalu masif untuk server seseorang tetapi pencetusnya tidak cenderung mengeksploitasi masalah yang Anda sebutkan, katakanlah, perilaku kasar dari Bingbot atau Bot Facebook.
Ján Lalinský

3

Masalah dengan -m batas adalah keterbatasan semua paket TCP apa pun sumber alamat IP. Jadi, jika Anda memiliki batasan rendah untuk paket syn seperti

-A INPUT -p tcp  --syn -m limit --limit 30/s --limit-burst 30 -j ACCEPT
-A INPUT -p tcp --syn -j DROP

hanya satu klien dengan baris perintah hping yang dapat menurunkan server Anda dengan mengirimkan paket tcp sebanyak dengan flag SYN karena aturan batas akan cocok dan akan menjatuhkan banyak paket apa pun sumber alamat IP. batas tidak membuat perbedaan antara lalu lintas yang baik dan lalu lintas yang buruk. Ini akan menurunkan lalu lintas masuk yang baik juga.

Hping bisa berupa:

hping thetargetedhostip -p 80 -S -c 1000 -i u20000

Lebih baik menggunakan hashlimit untuk membatasi koneksi tcp masuk per alamat IP . Aturan berikut hanya akan cocok jika 30 paket per detik akan diterima mengurangi jumlah paket resmi per IP menjadi 15 paket per detik.

-A INPUT -p tcp --syn -m hashlimit --hashlimit 15/s --hashlimit-burst 30 --hashlimit-mode srcip --hashlimit-srcmask 32 --hashlimit-name synattack -j ACCEPT 
-A INPUT -p tcp --syn -j DROP

Pada kenyataannya, saya yakin bahwa banyak server yang diturunkan hari ini tidak diambil karena kehabisan sumber daya selama serangan tetapi karena modul batas menjatuhkan semua lalu lintas yang masuk.


1

Saya biasanya membatasi aturan pembatasan tingkat ke server yang saya harapkan:

  • jumlah lalu lintas yang diharapkan rendah
  • layanan otentikasi

Misalnya, halaman login panel kontrol hosting, POP3, IMAP, SSH, dll. Saya biasanya membiarkan layanan HTTP terbuka lebar dan hanya memblokir jika ada masalah.

Anda tidak ingin menjatuhkan traffic web yang bagus. Tautan pada slashdot dapat mengirimkan Anda banyak lalu lintas dan dengan aturan global, Anda mungkin tidak menyadari adanya masalah.

Berkenaan dengan IP spoofed, mereka tidak dapat diblokir menggunakan metode ini dan biasanya tidak menjadi perhatian karena aturan ini terutama berfokus pada membatasi koneksi TCP yang sudah ada. Dengan IP spoof, koneksi TCP tidak pernah dapat dibangun.


Hai jeffatrackaid, terima kasih atas jawaban Anda! Saya juga cenderung menilai-batas (secara global) jenis layanan ini (SSH dll). Mengenai lalu lintas HTTP, itu sebabnya saya tidak bermaksud menerapkan batas global. Dalam pertanyaan ini saya berharap untuk melihat apakah ada kasus ketika batas per IP bisa menarik. Mengenai IP palsu (saya membuka pertanyaan terpisah tentang itu) meskipun koneksi tidak dapat dibangun, ada kemungkinan DoS dengan menggunakan banjir SYN. Saya tetap tertarik mendengar bagaimana ini bisa dikurangi.
ML--
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.