Server DNS Rekursif Publik yang Menghadapi - aturan iptables

Kami menjalankan server DNS rekursif publik di mesin Linux. Kami telah digunakan untuk serangan amplifikasi DNS. Apakah ada iptablesaturan yang direkomendasikan yang akan membantu mengurangi serangan ini?

Solusi yang jelas adalah hanya membatasi paket DNS keluar ke tingkat lalu lintas tertentu. Tapi saya berharap menemukan sesuatu yang sedikit lebih pintar sehingga serangan hanya memblokir lalu lintas ke alamat IP korban.

Saya telah mencari saran dan saran, tetapi semuanya tampaknya "tidak menjalankan server nama rekursif yang menghadap publik". Sayangnya, kita didukung dalam situasi di mana hal-hal yang tidak mudah diubah akan pecah jika kita tidak melakukannya, dan ini disebabkan oleh keputusan yang dibuat lebih dari satu dekade yang lalu sebelum serangan ini menjadi masalah.

Semuanya berbau skenario "bukan masalah saya" itu bukan kesalahan Anda dan harus / bisa 100% diselesaikan dengan mengambil tindakan yang tepat, terlepas dari seberapa "sulit" atau "sulit" itu, dan itu mengakhiri Anda buka server rekursif .

Fase keluar: beri tahu pelanggan bahwa server ini akan pergi pada tanggal X. Setelah waktu itu, mereka perlu menginstal patch (dengan asumsi Anda memilikinya) untuk menghentikannya dari menggunakan server DNS Anda. Ini dilakukan setiap saat. Admin, admin jaringan, helpdesk guys, programmer? Kami mendapatkannya ; akhir kehidupan ini terjadi setiap saat, karena prosedur operasi standar untuk vendor / penyedia layanan / mitra memberitahu kita untuk berhenti menggunakan sesuatu setelah tanggal X. Kami tidak selalu menyukainya, tetapi ini adalah fakta kehidupan di TI.

Anda mengatakan Anda tidak memiliki masalah ini pada perangkat saat ini, jadi saya berasumsi Anda telah menyelesaikan masalah ini dengan pembaruan firmware atau patch. Saya tahu Anda mengatakan Anda tidak dapat menyentuh perangkat, tetapi tentu saja mereka bisa? Maksudku, jika mereka membiarkan kotak-kotak ini pada dasarnya telepon rumah Anda, mereka tidak bisa benar-benar menjadi yang anal tentang siapa yang melakukan apa yang harus perangkat mereka; Anda bisa memiliki setup proxy terbalik untuk semua yang mereka tahu, jadi mengapa tidak minta mereka menginstal patch yang memperbaiki ini atau memberitahu mereka untuk menggunakan server DNS mereka sendiri . Tentunya perangkat Anda mendukung DHCP; Saya tidak bisa memikirkan perangkat jaringan (tidak peduli berapa lama / rapuh / aneh) yang tidak .

Jika Anda tidak dapat melakukan itu, hal berikutnya yang harus dilakukan adalah mengontrol siapa yang dapat mengakses server rekursif Anda: Anda mengatakan bahwa "sulit untuk mengatakan" siapa yang menggunakannya dan bagaimana, tetapi sekarang saatnya untuk mencari tahu secara pasti dan mulai menjatuhkan lalu lintas yang tidak sah

Ini adalah organisasi "semi-militer / pemerintah", bukan? Yah, mereka kemungkinan adalah bagian dari blokir sah yang mereka miliki; perangkat ini bukan router rumah di belakang IP dinamis. Temukan. Hubungi mereka, jelaskan masalahnya dan bagaimana Anda menghemat banyak uang dengan tidak memaksa firmware atau penggantian produk jika hanya mereka yang bisa mengkonfirmasi alamat netblock / IP yang akan digunakan perangkat untuk mengakses server DNS Anda.

Ini dilakukan sepanjang waktu: Saya memiliki beberapa pelanggan yang membatasi akses extranet atau pendengar HL7 ke mitra layanan kesehatan dengan cara ini; itu tidak sulituntuk meminta mereka mengisi formulir dan memberikan IP dan / atau netblock, saya seharusnya mengharapkan lalu lintas dari: jika mereka ingin akses ke ekstranet, mereka harus memberi saya IP atau subnet. Dan ini jarang menjadi target yang bergerak sehingga tidak seperti Anda akan dibanjiri dengan ratusan permintaan perubahan IP setiap hari: jaringan rumah sakit kampus besar yang memiliki blokir sendiri dengan ratusan subnet dan ribuan dan ribuan host IP secara rutin memberi saya beberapa alamat IP atau subnet yang seharusnya saya harapkan; lagi, ini bukan pengguna laptop yang berkeliaran di sekitar kampus sepanjang waktu, jadi mengapa saya berharap melihat paket sumber UDP dari alamat IP yang selalu berubah? Jelas saya membuat asumsi saya di sini, tapi saya berani bertaruh itu tidak sebanyak yang Anda pikirkan untuk perangkat <100-an. Ya, itu akan menjadi ACL yang panjang, dan ya,

Jika karena alasan tertentu saluran komunikasi tidak terbuka (atau seseorang terlalu takut atau tidak dapat diganggu untuk menghubungi pemilik perangkat lawas ini dan melakukan ini dengan benar), Anda perlu menetapkan garis dasar penggunaan / aktivitas normal sehingga Anda dapat memformulasikan beberapa strategi lain yang akan membantu (tetapi tidak mencegah) partisipasi Anda dalam serangan amplifikasi DNS.

Lama berjalan tcpdumpharus bekerja penyaringan pada UDP 53 yang masuk dan masuk log pada aplikasi server DNS. Saya juga ingin mulai mengumpulkan sumber alamat IP / netblocks / informasi geoIP (apakah semua klien Anda di AS? Blokir yang lain) karena, seperti yang Anda katakan, Anda tidak menambahkan perangkat baru, Anda hanya memberikan warisan layanan untuk instalasi yang ada.

Ini juga akan membantu Anda memahami jenis rekaman apa yang diminta, dan untuk domain apa, oleh siapa, dan seberapa sering : agar amplifikasi DNS berfungsi sebagaimana dimaksud, penyerang harus dapat meminta jenis rekaman besar (1) ke domain yang berfungsi (2).

1. "tipe rekaman besar": apakah perangkat Anda bahkan membutuhkan catatan TXT atau SOA untuk dapat diselesaikan oleh server DNS rekursif Anda? Anda mungkin dapat menentukan jenis rekaman mana yang valid di server DNS Anda; Saya percaya ini mungkin dengan BIND dan mungkin Windows DNS, tetapi Anda harus melakukan penggalian. Jika server DNS Anda merespon dengan SERVFAILapapun TXT atau SOA catatan, dan setidaknya bahwa respon urutan besarnya (atau dua) lebih kecil dari muatan yang dimaksudkan. Jelas Anda masih "bagian dari masalah" karena korban palsu masih akan mendapatkan SERVFAILtanggapan dari server Anda, tetapi setidaknya Anda tidak memalu mereka dan mungkin server DNS Anda "dihapuskan" dari daftar yang dipanen. bot menggunakan dari waktu ke waktu untuk tidak "bekerja sama".

2. "domain yang berfungsi": Anda mungkin dapat membuat daftar putih hanya domain yang valid. Saya melakukan ini pada pengaturan pusat data saya yang keras di mana server hanya membutuhkan Pembaruan Windows, Symantec, dll untuk berfungsi. Namun, Anda hanya mengurangi kerusakan yang Anda sebabkan pada saat ini: korban masih akan dibombardir dengan NXDOMAINatau SERVFAILtanggapan dari server Anda karena server Anda masih akan menanggapi IP sumber yang dipalsukan. Sekali lagi, skrip Bot mungkin juga secara otomatis memperbarui daftar server terbuka berdasarkan hasil, sehingga ini bisa membuat server Anda dihapus.

Saya juga menggunakan beberapa bentuk pembatasan tingkat, seperti yang disarankan orang lain, baik di tingkat aplikasi (yaitu ukuran pesan, permintaan per batasan klien) atau tingkat firewall (lihat jawaban lain), tetapi sekali lagi, Anda akan harus melakukan beberapa analisis untuk memastikan Anda tidak membunuh lalu lintas yang sah.

Sistem Deteksi Intrusi yang telah disetel dan / atau dilatih (sekali lagi, perlu garis dasar di sini) harus dapat mendeteksi lalu lintas yang abnormal dari waktu ke waktu berdasarkan sumber atau volume juga, tetapi kemungkinan akan memerlukan penjagaan / penyetelan / pemantauan berkala untuk mencegah kesalahan positif dan / atau lihat apakah itu benar-benar mencegah serangan.

Pada akhirnya, Anda harus bertanya-tanya apakah semua upaya ini sepadan atau apakah Anda harus bersikeras bahwa hal yang benar telah dilakukan dan itu menghilangkan masalah sejak awal.

Itu tergantung pada jenis tingkat pembatasan yang ingin Anda lakukan.

Pembatasan nilai dengan iptablessebenarnya lebih dimaksudkan untuk membatasi paket yang masuk, karena paket hingga batas akan cocok dengan filter dan menerapkan target yang ditentukan (mis., ACCEPT). Anda mungkin akan memiliki target berikutnya untuk DROPpaket - paket yang tidak cocok dengan filter. Dan meskipun iptablesmemiliki QUEUEtarget, ia hanya meneruskan paket ke ruang pengguna di mana Anda harus menyediakan aplikasi antrian Anda sendiri. Anda juga dapat menilai batas paket keluar, tetapi sedikit orang yang benar-benar ingin mulai membuang lalu lintas keluar.

iptables batas nilai menurun:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

Menggunakan hashlimitdaripada limitakan memberi Anda batasan tarif per IP tujuan. Yaitu, lima paket ke 8.8.8.8 yang mencapai batas akan mencegah paket dikirim ke 8.8.4.4 sementara dengan hashlimitjika 8.8.8.8 dimaksimalkan Anda masih dapat mencapai 8.8.4.4, yang terdengar lebih seperti yang Anda inginkan.

Jika Anda tidak ingin paket yang melewati batas dijatuhkan maka yang Anda inginkan adalah paket tc. tcakan mengatur aliran untuk mendapatkan aliran stabil yang bagus daripada banyak lalu lintas bursty. Pada paket sisi yang masuk dikirim ke aplikasi lebih lambat tetapi semua akan tiba dalam urutan. Pada paket keluar akan meninggalkan aplikasi Anda secepat mungkin tetapi ditempatkan pada kabel dalam aliran yang konsisten.

Saya belum tcbanyak menggunakan , tapi ini adalah contoh ICMP pembatas tingkat yang mungkin bisa Anda adaptasi dengan mudah untuk DNS.

Berikut adalah satu hal yang dapat Anda lakukan untuk memitigasi respons potensial terhadap permintaan palsu, tetapi dibutuhkan beberapa upaya:

Pertama, lihat log Anda dari saluran keamanan dan temukan alamat IP yang menjadi palsu.

Kemudian jalankan tcpdump menggunakan IP sumber itu (10.11.12.13) seperti ini:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

Anda akan mendapatkan sesuatu seperti ini:

18: 37: 25.969485 IP (tos 0x0, ttl 52, id 46403, offset 0, flag [tidak ada], proto: UDP (17), panjang: 45) 10.11.12.13.51169> 01.02.03.04.domain: 4215+ ANY ? . (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w ..
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

Sekarang bagian yang menyenangkan! Buka rfc1035 di http://tools.ietf.org/html/rfc1035 dan buka bagian 4.1.1.

Saatnya menerjemahkan hasil tcpdump dan mencari pola yang bisa kita gunakan untuk membuat filter level paket.

ID header dimulai pada 0x1C, jadi kami punya beberapa flag pada 0x1E, QDCOUNT di 0x20, ANCOUNT di 0x22, NSCOUNT di 0x24 dan ARCOUNT di 0x26.

Itu meninggalkan pertanyaan aktual pada 0x28, yang dalam hal ini adalah null (ROOT) untuk NAME, 0xFF untuk QTYPE = ANY, dan 0x01 untuk QCLASS = IN.

Singkatnya, saya menemukan bahwa menambahkan aturan iptables berikut memblokir lebih dari 95% kueri palsu yang meminta rekaman APAPUN DALAM ROOT:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

Jarak tempuh Anda mungkin beragam ... harap ini membantu.

Menggunakan tcdan antrian disiplin di linux untuk port keluar 53 UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

Akan mengatur Anda dengan discterbatas hingga 10mbit untuk paket apa pun dengan tanda firewall '1'. Tanda-tanda firewall hanya internal untuk firewall, dan jangan memodifikasi paket. Hanya penanganan paket dengan disiplin antrian. Inilah cara yang Anda gunakan iptablesuntuk membuat tanda firewall:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

Ubah keinginan Anda untuk mengecualikan subnet dan / atau tujuan yang tepercaya. The -o eth0membatasi pembentukan untuk paket outbound saja. Semoga ini membantu.

Saya akan mencoba untuk membuat daftar semua klien yang bergantung pada penyelesai rekursif eksternal Anda. Mulailah dengan satu atau dua hari jejak paket pada kotak DNS. Dari sana, mulailah membuat aturan iptables untuk memungkinkan lalu lintas yang Anda kenali dan otorisasi. Standarnya pada akhirnya akan menurunkan lalu lintas ke 53 / tcp dan 53 / udp. Jika itu merusak sesuatu, sesuaikan aturan Anda.

tergantung pada 'posisi' jaringan Anda [memiliki beberapa umpan bgp atau berada di 'ujung' internet - sebagai jaringan rintisan] Anda dapat mencoba sesuatu seperti uRPF untuk mencegah spoofing alamat sumber.

lainnya sumber info.

Apakah perangkat ini masih di bawah kontrak dukungan? Jika demikian, hubungi pelanggan Anda. Biarkan mereka tahu bahwa internet telah berevolusi sedikit dalam dekade terakhir dan untuk terus memberikan resolusi nama untuk perangkat ini, Anda perlu mengetahui IP SRC untuk mendapatkan permintaan dari. Tetapkan tanggal ~ 6 bulan di masa depan di mana Anda tidak lagi dapat melayani klien yang tidak dikenal, dan patuhi itu. Ini sangat umum di industri. Jika perangkat ini tidak lagi di bawah kontrak dukungan ... terdengar seperti keputusan bisnis. Berapa lama perusahaan Anda bermaksud mengeluarkan sumber daya untuk produk kuno yang tidak lagi menghasilkan pendapatan?

Ini kedengarannya seperti perangkat khusus, apakah mereka begitu khusus sehingga Anda dapat memperkirakan domain mana yang tepat untuk mengharapkan permintaan yang sah? bind mendukung tampilan, membuat tampilan publik yang hanya melakukan rekursi untuk domain tersebut.

Gunakan ini sebagai kesempatan belajar, jika Anda belum melakukannya, berhentilah mengeluarkan produk di mana Anda tidak memiliki kemampuan untuk memperbaiki bug. Itulah ini, bug. Salah satu yang pasti akan EOL perangkat ini sebelum waktunya, cepat atau lambat.

Dari nanog di suatu tempat, ini:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

Ini tidak ideal. Mungkin lebih baik untuk membiarkan paket lebih sedikit per detik, dan memiliki ledakan yang lebih tinggi.

Ini adalah solusi yang saya gunakan beberapa kali untuk melawan serangan DDOS, itu tidak sempurna tetapi membantu saya. Solusinya terdiri dari skrip yang dipanggil setiap N menit (seperti 1,2,3 dst. Menit) oleh cron dan memblokir IP yang membuat sejumlah koneksi lebih besar dari yang diberikan dalam skrip:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp