Mengapa peretas menyerang server DNS dengan DoS?

Question

Saya bangun pagi ini ke server yang di-boot ulang. Server DNS berjalan lebih dari 100%. Setelah sedikit bekerja, saya mendapatkan fail2ban untuk memblokir semua permintaan tersebut.

Permintaan itu sendiri valid, hanya diulang ratusan kali per detik. Setelah blok tersebut mendapatkan banyak (ratusan) IP, saya dapat melihat bahwa saya memblokir 1 juta klik UDP setiap beberapa jam.

Apakah itu hanya serangan [D] DoS? (mungkin dianggap dinamis karena banyak komputer yang terlibat dan setelah ada yang diblokir cukup lama sepertinya itu menghentikan permintaan)

Kemungkinan lain yang dapat saya pikirkan adalah bahwa penyerang mencoba merusak server DNS dan mendapatkan akses ketika restart atau crash seluruh komputer dan mencoba koneksi ke layanan lain. (mis. jika Anda tidak tahu cara memasang firewall sebelum memulai layanan)

Sejak pengaturan ulang firewall terakhir saya, berikut adalah statistik saya:

Hit: 2.346.742
Jumlah IP: 473

Ini berjalan cepat. Beberapa ratus hit per detik. Namun, jumlah IP tidak bertambah banyak.

Answer 1

Dari komentar @ Schroeder, saya melakukan beberapa pencarian tambahan dan menemukan lebih banyak lagi tentang jenis serangan ini.

Saya Adalah Targetnya!

Pertama-tama, sepertinya saya adalah target penyerangan. Mengapa? Karena serangan Amplifikasi DNS berarti port sumber permintaan DNS diatur ke 53. Hal ini memungkinkan untuk memaksa DNS saya untuk mengirim tanggapan yang tidak diminta ke server lain (lihat grafik di bawah). Karena saya memiliki kurang dari 0,1% dari hit seperti itu menggunakan port itu, saya tidak benar-benar berpikir bahwa DNS saya digunakan untuk Amplifikasi, tetapi itu adalah targetnya.

Bagaimana serangan itu bekerja?

Penyerang menyiapkan komputer dengan perangkat lunak yang mengirimkan paket UDP ke beberapa server DNS acak yang meminta nama domain. Paket terlihat normal kecuali fakta bahwa penyerang menempatkan alamat IP komputer yang berbeda, bukan alamat IP-nya sebagai sumber. Hasilnya adalah DNS mengirimkan balasan ke komputer yang salah :

      10.0.0.1         10.0.0.2         10.0.0.3
+------------+   +------------+   +------------+
|            |   |            |   |            |
| Attacker   +-->| Some DNS   +-->| Me         |
|            |   |            |   |            |
+------------+   +--+---------+   +------------+
                    |      ^
                    v      |
                 +---------+--+   This step is not required, it happens if
                 |            |   your DNS is setup to accept recursive
                 | Master DNS |   requests (which is not a good idea)
                 |            |
                 +------------+
                       10.0.0.4

Dalam contoh di atas, permintaan penyerang harus memiliki 10.0.0.1 sebagai alamat asal UDP. Namun sebaliknya, penyerang mengubah alamat IP-nya dengan 10.0.0.3. Akibatnya, ketika DNS di 10.0.0.2 menerima paket UDP dan siap untuk mengirim balasan, ia mengirimkan data ke 10.0.0.3.

Master DNS dari domain akan digunakan jika DNS di 10.0.0.2 tidak tahu apa-apa tentang nama domain yang dipertanyakan.

CATATAN PENTING: Ini berlaku untuk semua layanan UDP. DNS mungkin yang terburuk dalam hal amplifikasi, tetapi NTP, misalnya, juga dapat ditargetkan.

Mengapa tidak memverifikasi Alamat Sumber saja?

Tidak mungkin dari 10.0.0.2 karena UDP tidak mengingat sumber sebenarnya dari paket tersebut.

Apa yang mungkin bagi ISP untuk memverifikasi bahwa semua paket yang keluar dari komputer tertentu memiliki alamat IP dari komputer tersebut. Beberapa memang, saya pikir, tapi kemungkinan besar tidak. Ini memiliki dampak kecepatan kecil ... yang tentu saja dengan amplifikasi DNS adalah untuk ditertawakan (amplifikasi DNS memiliki efek yang jauh lebih buruk di Internet daripada pemeriksaan kecil asal paket UDP).

Hal lain mungkin adalah bahwa pengguna mungkin masih dapat melakukan dengan menyambung ke Internet sedemikian rupa sehingga ia melewati verifikasi ISP. Saya tidak tahu apakah dan / atau bagaimana itu mungkin, tetapi saya tidak akan terkejut bahwa itu bisa dilakukan.

Sebenarnya hal ini sangat problematis karena asal mula serangan tersebut sulit dilacak dan tentunya itulah mengapa masih terjadi secara masal.

Mengapa itu DDoS?

Paket untuk meminta catatan DNS, yang terjadi di sini, sangat kecil, mungkin 300 byte. Jadi penyerang hanya perlu mengirim satu paket UDP kecil.

Responsnya, bagaimanapun, mungkin beberapa kilobyte data. Secara khusus, ada domain yang digunakan dalam serangan ini:

peacecorps.gov

dan domain tersebut mengembalikan lebih dari 3 KB data! (Ini mendefinisikan banyak bidang 'TXT' yang digunakan dalam serangan amplifikasi itu.) Inilah mengapa ini disebut Serangan Amplifikasi.

Akibatnya, permintaan dari Penyerang diubah menjadi respons sekitar 10x lebih besar dan komputer yang diserang (10.0.0.3) dibanjiri dengan sejumlah besar paket UDP yang agak besar.

Di sini saya menunjukkan entri yang dihasilkan dalam iptables. Angka pertama menunjukkan jumlah klik ke komputer DNS saya setelah sekitar 40 menit (jadi lebih dari 10.000 klik dalam satu menit ...):

pkts     bytes target     prot opt in     out     source               destination         
61637  4376227 DROP       udp  --  eno1   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0a7065616365636f72707303676f76|" ALGO name bm TO 65535

Perhatikan juga bagaimana string sepenuhnya diubah menjadi bilangan heksadesimal.

Bukankah permintaan HTTP lebih buruk lagi ?!

HTTP 0.9 / 1.0 / 1.1 / 2 menggunakan TCP yang merupakan protokol dua arah dan tidak ada amplifikasi yang dapat dihasilkan dengan TCP. yaitu TCP rusak jika Anda tidak terhubung dengan benar dengan jabat tangan penuh.

HTTP / 3, bagaimanapun, memperkenalkan protokol QUIC yaitu HTTP melalui paket UDP. Sejauh ini saya belum mendengar masalah besar dengan QUIC, tetapi protokolnya telah banyak berubah dalam 6-7 tahun terakhir dan belum diterapkan secara luas. Berikut adalah artikel tentang fakta bahwa QUIC telah membangun fitur-fitur untuk mencegah serangan amplifikasi, jadi ada harapan bahwa hal itu telah diatasi.

Beberapa orang berbicara tentang menggunakan HTTP untuk menanyakan nama domain. (DoH - Domain melalui HTTP). Mudah-mudahan itu tidak akan diimplementasikan menggunakan QUIC ...

Bagaimana cara Memperbaiki Masalahnya?

Amplifikasi terjadi karena DNS Anda diatur untuk menerima permintaan nama domain yang tidak Anda kendalikan (yaitu domain yang bukan Anda pemiliknya).

BIND memiliki opsi yang memungkinkannya melakukan amplifikasi, yang disebut rekursi dalam bahasa DNS. Fitur ini sekarang dinonaktifkan secara default, tetapi Anda mungkin telah mengaktifkannya (karena kesalahan?).

Ini pengaturan yang salah :

allow-recursion { any; };

Yang Anda inginkan adalah menggunakan pengaturan yang benar :

trusted-servers { 192.0.2.4; }  // list all your trusted servers

allow-recursion { trusted-servers; };

Ini akan membuat server Anda secara otomatis menolak semua permintaan semacam itu. Jadi jika Anda tidak peacecorps.govdan Anda menerima permintaan seperti itu, BIND hanya akan berhenti di situ dan menulis catatan di log DNS Anda tentang permintaan yang ditolak.

Bisakah saya memblokir IP dari permintaan tersebut?

Iya. Saya mulai dengan melakukan itu karena server saya berjalan dengan baik lebih dari 100% dalam waktu CPU. Namun, mungkin tidak bijaksana untuk melakukannya. Dari gambar di atas, Anda dapat melihat bahwa server DNS Anda berada di antara penyerang dan korban. Jika Anda memblokir alamat IP sumber, bukan IP penyerang yang Anda blokir, melainkan IP korban. Ini berarti Anda sebenarnya mencegah korban melihat nama domain Anda dan melakukan permintaan yang sah. Mungkin bukan itu yang Anda inginkan!

Pada awalnya, saya membuat pesan log dari firewall saya. Jika saya mendeteksi 5 atau lebih permintaan ke port 53 (UDP) dari alamat IP yang sama dalam waktu singkat (5 detik), maka saya akan memblokir alamat IP tersebut. Untuk melakukannya, saya menggunakan fail2ban.

Pertama, saya memiliki filter yang mendeteksi tautan dengan UDP dan port 53 sebagai tujuan:

# Filter: /etc/fail2ban/filter.d/named-fast-requests.conf
[Definition]
failregex = \sIN=[a-z0-9]+ .* SRC=<HOST> .* PROTO=UDP .* DPT=53\s

Kedua, saya memiliki jail yang memberikan parameter lain:

# Jail: /etc/fail2ban/jail.d/named-fast-requests.conf
[named-fast-requests]
enabled  = true
filter   = named-fast-requests
action   = named-action[scheme=all,period=year,reason=named fast requests]
logpath  = /var/log/iptables/iptables.log
maxretry = 5
findtime = 5
bantime  = 1036800

Poin utama di sini adalah maxretrydan findtimeyang disetel 5 kali dalam 5 detik atau kurang. Jika itu terjadi, saya memblokir <HOST>.

Anda akan ingin memperbarui tindakan dengan hal Anda sendiri. Saya menggunakan iplockalat saya sendiri di sini. Perintah yang saya gunakan dalam aksi:

actionban = /usr/sbin/iplock -s named -b <ip>

Secara default, fail2ban menggunakan iptablessecara langsung. Telusuri tindakan mereka untuk melihat bagaimana hal itu dilakukan.

Jangan Menjadi Sumber Amplifikasi

Anda harus memblokir permintaan yang port UDP sumbernya kurang dari 1024. Ini tidak valid. Jika Anda menawarkan server, port 53 akan menjadi port tujuan, bukan sumber.

iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 0:1023 -j DROP

PERINGATAN: ganti posisi (123) dengan nomor yang benar!

Aturan ini mengatakan bahwa untuk setiap paket UDP yang masuk eth0, yang memiliki port sumber antara 0 dan 1023, jatuhkan paket tersebut. Ini mencegah seseorang menggunakan server DNS Anda untuk amplifikasi. Namun, itu tidak melindungi server Anda sendiri dari amplifikasi dari orang lain. Perhatikan bahwa meskipun dengan allow-recursionpenyiapan yang tepat , Anda tidak akan mencegah serangan amplifikasi jika penyerang memilih dengan benar salah satu nama domain Anda untuk serangan tersebut.

Catatan: jika Anda menentukan server nama yang berbeda untuk menyelesaikan nama domain di komputer Anda, Anda mungkin ingin membuka koneksi tersebut sebelum memblokir semuanya dari port 0 hingga 1023. Ini akan menjadi seperti ini:

iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 53 -s 8.8.8.8 \
                    -d <your-static-ip> -j ACCEPT

Ini adalah data yang dikembalikan dari nameserver 8.8.8.8, yang mungkin ingin Anda terima. Tampaknya penyedia Anda atau beberapa server nama resmi lainnya tidak akan menjadi sumber langsung serangan UDP. Jika Anda tidak memiliki alamat IP statis, Anda tidak perlu menyertakan -dopsi.

Namun, mungkin jauh lebih baik menggunakan ESTABLISHEDfitur yang sekarang tersedia untuk pesan UDP (sudah cukup lama sekarang, tapi saya ingat saat itu tidak tersedia ...):

iptables -I INPUT 123 -i eth0 -p udp -m state \
      --state ESTABLISHED,RELATED -m udp -d <your-static-ip> -j ACCEPT

Ini berarti Anda akan secara otomatis menerima jawaban dari penyedia server nama domain Anda karena firewall akan tahu Anda mengirim permintaan dan Anda ingin menerima balasan. Aturan ini harus muncul sebelum DROPaturan di atas.

Jatuhkan Permintaan yang Tidak Diinginkan Lebih Awal

Jelas, meminta BIND menerima semua permintaan peacecorps.govitu bukanlah sesuatu yang diinginkan siapa pun. Anda sebenarnya dapat memblokirnya langsung di firewall Anda. Ini berfungsi karena paket UDP tidak dienkripsi sehingga nama domain terlihat.

Berikut adalah aturan yang dapat digunakan untuk memblokir permintaan nama domain tersebut:

sudo iptables -I INPUT 123 -i eno1 -p udp -m udp --dport 53 \
           -m string --hex-string "|0A|peacecorps|03|gov|" --algo bm -j DROP

Jelas, jika DNS Anda memiliki domain atau sub-domain termasuk "peacecorps.gov" maka tidak boleh menggunakan iptablesaturan itu. Bagi kebanyakan dari kita, meskipun itu jarang terjadi.

The --hex-stringpilihan memungkinkan Anda untuk menentukan string. Cara mendefinisikannya dalam paket UDP menggunakan bentuk P-string (ukuran + data). Karena "peacecorps" memiliki panjang 10 karakter, kami menempatkan 0x0A tepat di depannya. Sekali lagi, "gov" adalah tiga huruf jadi kami menggunakan 0x03. Jika kita menggunakan string "peacecorps.gov", itu tidak akan berfungsi karena titik tidak akan cocok dengan byte 0x03. Namun, ukuran pertama adalah opsional (meskipun Anda akan mencocokkan apa pun yang terlihat sama seperti "bestpeacecorps").

Memiliki aturan seperti itu akan menghemat banyak sekali lalu lintas yang benar-benar tidak diinginkan bagi layanan nama domain Anda.

Update: Meskipun serangan itu berhenti sekitar dua minggu setelah saya posting pertanyaan saya, "peacecorps.gov" masalah masih terjadi sekitar 10 kali sehari.

Sumber: https://defragged.org/2020/05/20/tips-and-tricks-blocking-dns-requests-via-iptables/

Debugging You DNS

In order to see what query your DNS server receives and replies to, you can run the following commands in your console:

sudo rndc querylog

Now look at the logs, usually here:

less /var/log/named.log

Look at the bottom (hit G in less) and you should start seeing queries from remote IPs. The logs include the domain name being checked. It's very practical, especially if you missed entering some of your own domain names in your secondary or tertiary DNS.