Cara Mengatur ModSecurity dengan Nginx di Debian/Ubuntu

Tutorial ini akan menunjukkan cara memasang dan menggunakan ModSecurity dengan Nginx di server Debian/Ubuntu. ModSecurity adalah firewall aplikasi web open source yang paling terkenal (WAF), memberikan perlindungan komprehensif untuk aplikasi web Anda (seperti WordPress, Nextcloud, Ghost dll) terhadap berbagai macam serangan Layer 7 (HTTP), seperti injeksi SQL, skrip lintas situs, dan penyertaan file lokal.

Catatan :Tutorial ini berfungsi pada semua versi Debian dan Ubuntu saat ini, termasuk Debian 10, Ubuntu 18.04, Ubuntu 20.04 dan Ubuntu 20.10.

Aplikasi web pada dasarnya tidak aman. Jika Anda adalah admin WordPress, Anda mungkin akan mendengar berita tentang peretas yang mengeksploitasi kerentanan di plugin dan tema WordPress sesekali. Sangat penting bagi Anda untuk menerapkan WAF di server web Anda, terutama bila Anda memiliki aplikasi lama yang tidak menerima pembaruan. ModSecurity awalnya dibuat oleh Ivan Ristić pada tahun 2002, saat ini dikelola oleh Trustwave SpiderLabs. Ini adalah WAF yang paling banyak digunakan di dunia, digunakan oleh lebih dari satu juta situs web. cPanel, panel kontrol hosting yang paling banyak digunakan, menyertakan ModSecurity sebagai WAF-nya.

Anda mungkin pernah mendengar firewall berbasis host lain seperti iptables, UFW, dan Firewalld, dll. Perbedaannya adalah mereka bekerja pada lapisan 3 dan 4 model OSI dan mengambil tindakan berdasarkan alamat IP dan nomor port. ModSecurity, atau firewall aplikasi web secara umum, dikhususkan untuk fokus pada lalu lintas HTTP (lapisan 7 dari model OSI) dan mengambil tindakan berdasarkan konten permintaan dan respons HTTP.

ModSecurity 3

ModSecurity awalnya dirancang untuk server web Apache. Itu bisa bekerja dengan Nginx sebelum versi 3.0 tetapi mengalami kinerja yang buruk. ModSecurity 3.0 (alias libmodsecurity ) dirilis pada tahun 2017. Ini adalah rilis tonggak sejarah, terutama untuk pengguna Nginx, karena ini adalah versi pertama yang bekerja secara native dengan Nginx. Peringatan ModSecurity 3 adalah bahwa ModSecurity 3 belum memiliki semua fitur seperti pada versi sebelumnya (2.9), meskipun setiap rilis baru akan menambahkan beberapa fitur yang hilang.

Langkah 1:Instal Nginx Versi Terbaru di Debian/Ubuntu

ModSecurity terintegrasi dengan Nginx sebagai modul dinamis, yang memungkinkan Anda untuk mengkompilasi kode sumber dari masing-masing modul tanpa mengkompilasi Nginx itu sendiri.

Biner Nginx perlu dikompilasi dengan --with-compat argumen, yang akan membuat modul dinamis kompatibel dengan biner dengan biner Nginx Anda yang ada. Namun, tidak semua biner Nginx yang dikirimkan dari repositori default Debian/Ubuntu dikompilasi dengan --with-compat argumen. Untuk mempermudah, kita dapat menginstal Nginx versi terbaru dari ondrej/nginx-mainline PPA, yang dikelola oleh pengembang Debian.

Catatan :Repositori nginx.org juga menyediakan versi terbaru dari Nginx. Namun, ondrej/nginx-mainline PPA menyediakan modul dinamis ekstra yang mungkin berguna bagi Anda, seperti modul Brotli.

Ubuntu

Jika Anda menggunakan Ubuntu 16.04, 18.04, 20.04, atau 20.10, jalankan perintah berikut untuk menginstal Nginx versi terbaru.

sudo add-apt-repository ppa:ondrej/nginx-mainline -ysudo apt updatesudo apt install nginx-core nginx-common nginx nginx-full

Selama proses instalasi, ini mungkin memberitahu Anda bahwa distributor paket telah mengirimkan versi terbaru dari file konfigurasi utama. Disarankan untuk menekan n untuk menjaga versi Anda saat ini. Anda selalu dapat memeriksa perbedaannya nanti.

Secara default, hanya repositori biner yang diaktifkan. Kita juga perlu mengaktifkan repositori kode sumber untuk mengunduh kode sumber Nginx. Edit file repositori jalur utama Nginx.

sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

Temukan baris yang dimulai dengan # deb-src .

# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ fokus utama

Hapus # karakter untuk mengaktifkan repositori kode sumber ini.

deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ fokus utama

Simpan dan tutup file. Kemudian perbarui indeks repositori.

sudo apt update

Debian

Jika Anda menggunakan Debian 10 atau Debian 11, jalankan perintah berikut untuk menginstal Nginx versi terbaru.

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -xsudo apt update sudo apt install nginx-core nginx-common nginx nginx-full

Selama proses instalasi, ini mungkin memberitahu Anda bahwa distributor paket telah mengirimkan versi terbaru dari file konfigurasi utama. Disarankan untuk menekan n untuk menyimpan versi Anda saat ini. Anda selalu dapat memeriksa perbedaannya nanti.

Secara default, hanya repositori biner yang diaktifkan. Kita juga perlu mengaktifkan repositori kode sumber untuk mengunduh kode sumber Nginx. Edit file repositori jalur utama Nginx.

sudo nano /etc/apt/sources.list.d/nginx-mainline.list

Anda harus menemukan satu baris yang mengaktifkan repositori biner Nginx. Tambahkan baris berikut untuk mengaktifkan repositori kode sumber Nginx di Debian 10.

deb-src https://packages.sury.org/nginx-mainline/ buster main

Jika Anda menggunakan Debian 11, tambahkan baris berikut sebagai gantinya.

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

Simpan dan tutup file. Kemudian perbarui indeks repositori.

sudo apt update

Memeriksa Argumen Konfigurasi Nginx

Sekarang periksa argumen konfigurasi Nginx dengan perintah berikut:

sudo nginx -V

Semua binari Nginx di PPA dikompilasi dengan --with-compat argumen.

Langkah 2:Unduh Paket Sumber Nginx

Meskipun kita tidak perlu mengkompilasi Nginx sendiri, kita memerlukan paket kode sumber Nginx untuk mengkompilasi modul dinamis ModSecurity. Jalankan perintah berikut untuk membuat nginx direktori di bawah /usr/local/src/ untuk menyimpan paket kode sumber Nginx. Ganti username dengan nama pengguna asli Anda.

sudo chown username:username /usr/local/src/ -R mkdir -p /usr/local/src/nginx

cd ke direktori sumber Nginx.

cd /usr/local/src/nginx/

Unduh paket sumber Nginx dengan perintah di bawah ini:

sudo apt install dpkg-devapt source nginx

Jika Anda melihat pesan peringatan berikut, Anda dapat mengabaikannya dengan aman.

W:Unduhan dilakukan tanpa kotak pasir sebagai root karena file 'nginx_1.19.5.orig.tar.gz' tidak dapat diakses oleh pengguna '_apt'. - pkgAcquire::Run (13:Izin ditolak)

Lihat file kode sumber yang diunduh.

ls

Contoh keluaran:

nginx-1.19.5nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.debian.tar.xznginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.dscnginx_1.19.5 .orig.tar.gz

Pastikan versi kode sumber sama dengan versi biner Nginx Anda (sudo nginx -v ).

Langkah 3:Instal libmodsecurity3

keamanan libmod adalah perpustakaan ModSecurity yang benar-benar melakukan pemfilteran HTTP untuk aplikasi web Anda. Pada Debian 10 dan Ubuntu 20.04, 20.10, Anda dapat menginstalnya dengan sudo apt install libmodsecurity3 , tapi saya sarankan Anda mengompilasinya dari sumbernya.

Untuk mengompilasi libmodsecurity , pertama-tama klon kode sumber dari Github.

sudo apt install gitgit clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/cd /usr/local/src/ ModSecurity/

Instal dependensi build.

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyaj pra> 

 Instal submodul yang diperlukan.
 
git submodule initgit submodule update
 

 Konfigurasikan lingkungan build.
 
./build.sh ./configure
 

 Jika Anda melihat kesalahan berikut, Anda dapat mengabaikannya.
 
fatal:Tidak ada nama yang ditemukan, tidak dapat menggambarkan apa pun.
 

 Kompilasi kode sumber dengan perintah berikut. Secara default, make hanya akan menggunakan satu inti CPU. Saya memiliki 4 inti CPU di server saya, jadi saya menentukan 4 pekerjaan (-j4 ) untuk make untuk mempercepat proses kompilasi. Ubah 4 ke jumlah inti CPU Anda sendiri.
 
make -j4
 

 Setelah make perintah selesai tanpa kesalahan, instal biner.
 
sudo make install
 

 Ini akan dipasang di bawah /usr/local/modsecurity/ direktori.
 
Memecahkan Masalah Galat Kompilasi
 
kesalahan #1
 

 Jika Anda melihat kesalahan berikut saat menjalankan make perintah, mungkin karena server Anda kehabisan RAM.
 
g++:kesalahan kompiler internal:Terbunuh (program cc1plus)
 

 Baris berikut di /var/log/syslog file menunjukkan server kehabisan memori, jadi pertimbangkan untuk meningkatkan spesifikasi server.
 

 
 

 Atau, Anda dapat membuat ruang swap untuk menyelesaikan masalah kehabisan memori. Namun, itu harus digunakan hanya sebagai tindakan sementara. Menggunakan ruang swap pada server SSD dapat merusak kinerja sistem.
 
kesalahan #2
 

 Jika Anda melihat kesalahan berikut saat mengkompilasi ModSecurity,
 
utils/geo_lookup.cc:Dalam fungsi anggota 'bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function&)>) const':utils/geo_lookup.cc:124:32:error:konversi tidak valid dari 'const MMDB_s*' ke 'MMDB_s*' [-fpermissive]r =MMDB_lookup_string(&mmdb, target.c_str( ), &gai_error, &mmdb_error);
 

 Mungkin karena Anda menginstal libmaxminddb-dev versi lama . Anda dapat menghapus paket ini.
 
sudo apt remove libmaxminddb-dev
 

 Dan instal libgeoip-dev , yang merupakan alternatif dari libmaxminddb-dev .
 
sudo apt install libgeoip-dev
 

 Kemudian kompilasi ulang ModSecurity.
 
make clean./configuremake -j4
 

 Instal biner.
 
sudo make install
 
Langkah 4:Unduh dan Kompilasi Kode Sumber Konektor Nginx ModSecurity v3
 

 Konektor Nginx ModSecurity tautan libmodsecurity ke server web Nginx. Kloning repositori ModSecurity v3 Nginx Connector Git.
 
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
 

 Pastikan Anda berada di direktori sumber Nginx.
 
cd /usr/local/src/nginx/nginx-1.19.5/
 

 Instal dependensi build untuk Nginx.
 
sudo apt build-dep nginxsudo apt install uuid-dev
 

 Selanjutnya, konfigurasikan lingkungan dengan perintah berikut. Kami tidak akan mengkompilasi Nginx itu sendiri, tetapi mengkompilasi Konektor Nginx ModSecurity modul saja. --with-compat flag akan membuat modul kompatibel dengan biner dengan biner Nginx Anda yang sudah ada.
 
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
 

 Bangun Konektor Nginx ModSecurity modul.
 
membuat modul
 

 Modul akan disimpan sebagai objs/ngx_http_modsecurity_module.so . Salin ke /usr/share/nginx/modules/ direktori.
 
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
 
Langkah 5:Muat Modul Konektor Nginx ModSecurity v3
 

 Edit file konfigurasi Nginx utama.
 
sudo nano /etc/nginx/nginx.conf
 

 Tambahkan baris berikut di awal file.
 
load_module modules/ngx_http_modsecurity_module.so;
 

 Juga, tambahkan dua baris berikut di http {...} bagian, jadi ModSecurity akan diaktifkan untuk semua host virtual Nginx.
 
modsecurity aktif;modsecurity_rules_file /etc/nginx/modsec/main.conf;
 

 
 

 Simpan dan tutup file. Selanjutnya, buat /etc/nginx/modsec/ direktori untuk menyimpan konfigurasi ModSecurity
 
sudo mkdir /etc/nginx/modsec/
 

 Kemudian salin file konfigurasi ModSecurity.
 
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
 

 Edit filenya.
 
sudo nano /etc/nginx/modsec/modsecurity.conf
 

 Temukan baris berikut.
 
Hanya Deteksi Mesin SecRule
 

 Konfigurasi ini memberi tahu ModSecurity untuk mencatat transaksi HTTP, tetapi tidak mengambil tindakan saat serangan terdeteksi. Ubah ke berikut, sehingga ModSecurity akan mendeteksi dan memblokir serangan web.
 
SecRuleEngine Aktif
 

 Kemudian temukan baris berikut (baris 224), yang memberi tahu ModSecurity informasi apa yang harus disertakan dalam log audit.
 
SecAuditLogParts ABIJDEFHZ
 

 Namun, pengaturan defaultnya salah. Anda akan tahu alasannya nanti saat saya menjelaskan cara memahami log ModSecurity. Pengaturan harus diubah menjadi berikut.
 
SecAuditLogParts ABCEFHJKZ
 

 Jika Anda memiliki situs web pengkodean, Anda mungkin ingin menonaktifkan pemeriksaan badan tanggapan, jika tidak, Anda mungkin mendapatkan 403 kesalahan terlarang hanya dengan memuat halaman web dengan banyak konten kode.
 
SecResponseBodyAccess Nonaktif
 

 Simpan dan tutup file. Selanjutnya, buat /etc/nginx/modsec/main.conf berkas.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Tambahkan baris berikut untuk menyertakan /etc/nginx/modsec/modsecurity.conf berkas.
 
Sertakan /etc/nginx/modsec/modsecurity.conf
 

 Simpan dan tutup file. Kita juga perlu menyalin file pemetaan Unicode.
 
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/
 

 Kemudian uji konfigurasi Nginx.
 
sudo nginx -t
 

 Jika pengujian berhasil, mulai ulang Nginx.
 
sudo systemctl restart nginx
 
Langkah 6:Aktifkan Kumpulan Aturan Inti OWASP
 

 Untuk membuat ModSecurity melindungi aplikasi web Anda, Anda perlu menentukan aturan untuk mendeteksi aktor jahat dan memblokirnya. Untuk pemula, adalah ide yang baik untuk menginstal set aturan yang ada, sehingga Anda dapat memulai dengan cepat dan kemudian mempelajari seluk beluknya. Ada beberapa set aturan gratis untuk ModSecurity. Set Aturan Inti OWASP (CRS) adalah kumpulan aturan standar yang digunakan dengan ModSecurity.
 
 
Ini adalah kumpulan aturan gratis, dikelola komunitas, dan paling banyak digunakan yang menyediakan konfigurasi default yang dijual untuk ModSecurity.
 
Berisi aturan untuk membantu menghentikan vektor serangan umum, termasuk injeksi SQL (SQLi), skrip lintas situs (XSS), dan banyak lainnya.
 
Dapat diintegrasikan dengan Project Honeypot.
 
Ini juga berisi aturan untuk mendeteksi bot dan pemindai.
 
Telah disetel melalui paparan luas untuk memiliki sangat sedikit kesalahan positif.
 
 

 Unduh CRS OWASP terbaru dari GitHub.
 
wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz
 

 Ekstrak filenya.
 
tar xvf v3.3.0.tar.gz
 

 Pindahkan direktori ke /etc/nginx/modsec/ .
 
sudo mv coreruleset-3.3.0/ /etc/nginx/modsec/
 

 Ganti nama crs-setup.conf.example berkas.
 
sudo mv /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Kemudian edit file konfigurasi utama.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Tambahkan dua baris berikut, yang akan membuat Nginx menyertakan file konfigurasi CRS dan aturan individual.
 
Sertakan /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf Sertakan /etc/nginx/modsec/coreruleset-3.3.0/rules/*.conf
 

 
 

 Simpan dan tutup file. Kemudian uji konfigurasi Nginx.
 
sudo nginx -t
 

 Jika pengujian berhasil, mulai ulang Nginx.
 
sudo systemctl restart nginx
 
Langkah 7:Pelajari Cara Kerja OWASP CRS
 

 Mari kita lihat file konfigurasi CRS, yang memberi Anda dokumentasi yang baik tentang cara kerja CRS.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Anda dapat melihat bahwa OWASP CRS dapat berjalan dalam dua mode:
 
 
mode mandiri . Ini adalah mode tradisional yang digunakan dalam CRS v2.x. Jika permintaan HTTP cocok dengan aturan, ModSecurity akan segera memblokir permintaan HTTP dan berhenti mengevaluasi aturan yang tersisa.
 
mode penilaian anomali . Ini adalah mode default yang digunakan dalam CRS v3.x. ModSecurity akan memeriksa permintaan HTTP terhadap semua aturan, dan menambahkan skor ke setiap aturan yang cocok. Jika ambang batas tercapai, maka permintaan HTTP dianggap sebagai serangan dan akan diblokir. Skor default untuk permintaan masuk adalah 5 dan untuk respons keluar adalah 4.
 
 

 
 

 Saat berlari dalam mode penilaian anomali, ada 4 level paranoia.
 
 
Paranoia level 1 (default)
 
Paranoia tingkat 2
 
Paranoia tingkat 3
 
Paranoia tingkat 4
 
 

 Dengan setiap peningkatan level paranoia, CRS memungkinkan aturan tambahan yang memberi Anda tingkat keamanan yang lebih tinggi. Namun, tingkat paranoia yang lebih tinggi juga meningkatkan kemungkinan memblokir beberapa lalu lintas yang sah karena alarm palsu.
 

 
 

 Ini adalah dua konsep dasar yang perlu Anda pahami sebelum menggunakan CRS. Sekarang kita bisa menutup file. Aturan CRS individu disimpan di /etc/nginx/modsec/coreruleset-3.3.0/rules/ direktori. Setiap aturan yang cocok akan meningkatkan skor anomali.
 
Langkah 8:Pengujian
 

 Untuk memeriksa apakah ModSecurity berfungsi, Anda dapat meluncurkan serangan injeksi SQL sederhana di situs web Anda sendiri. (Harap diperhatikan bahwa melakukan pengujian keamanan di situs web orang lain tanpa izin adalah ilegal.) Masukkan URL berikut di browser web Anda.
 
https://domainanda.com/?id=3 atau 'a'='a'
 

 Jika ModSecurity berfungsi dengan baik, server web Nginx Anda akan menampilkan pesan kesalahan 403 terlarang.
 

 
 

 Peramban Firefox mungkin gagal menampilkan pesan kesalahan 403. Anda dapat menekan Ctrl+Shift+I untuk membuka jendela alat pengembang dan pilih network tab. Kemudian tekan F5 untuk memuat ulang halaman web. Anda sekarang akan melihat kode kesalahan 403 di Firefox.
 

 Jika ModSecurity berjalan di DetectionOnly mode, itu tidak akan memblokir serangan injeksi SQL ini.
 
Langkah 9:Memahami Log ModSecurity
 

 Penting untuk menganalisis log ModSecurity, sehingga Anda akan tahu jenis serangan apa yang diarahkan ke aplikasi web Anda dan mengambil tindakan yang lebih baik untuk bertahan melawan pelaku ancaman. Ada dua jenis log di ModSecurity:
 
 
log debug:dinonaktifkan secara default.
 
log audit:/var/log/modsec_audit.log 
 
 

 Untuk memahami log audit ModSecurity, Anda perlu mengetahui 5 fase pemrosesan di ModSecurity, yaitu:
 
 
Fase 1:Periksa header permintaan
 
Fase 2:Periksa isi permintaan
 
Fase 3:Periksa header respons
 
Fase 4:Periksa isi tanggapan
 
Fase 5:Tindakan (mencatat/memblokir permintaan berbahaya)
 
 

 Mereka juga dua jenis file logging.
 
 
Serial :satu file untuk semua log. Ini adalah default.
 
Serentak :beberapa file untuk logging. Ini dapat memberikan kinerja penulisan yang lebih baik. Jika Anda melihat halaman web Anda melambat setelah mengaktifkan ModSecurity, Anda dapat memilih untuk menggunakan jenis logging bersamaan.
 
 

 Peristiwa di log dibagi menjadi beberapa bagian.
 
 
bagian A:header log audit
 
bagian B:header permintaan
 
bagian C:isi permintaan
 
bagian D:dipesan
 
bagian E:badan tanggapan perantara
 
bagian F:header tanggapan akhir
 
bagian G:dipesan
 
bagian H:cuplikan log audit
 
bagian I:alternatif isi permintaan ringkas, yang mengecualikan file
 
bagian J:informasi tentang file yang diunggah
 
bagian K:setiap aturan yang dicocokkan dengan suatu peristiwa, dalam urutan kecocokan
 
bagian Z:batas akhir
 
 

 Jika Anda menjalankan situs web dengan lalu lintas tinggi, log audit ModSecurity bisa menjadi terlalu besar dengan sangat cepat, jadi kami perlu mengonfigurasi rotasi log untuk log audit ModSecurity. Buat file konfigurasi logrotate untuk ModSecurity.
 
sudo nano /etc/logrotate.d/modsecurity
 

 Tambahkan baris berikut ke file ini.
 
/var/log/modsec_audit.log{ putar 14 hari hilangok kompres delaycompress notifempty}
 

 Ini akan merotasi file log setiap hari (setiap hari ), mengompresi versi lama (kompres ). 14 file log sebelumnya akan disimpan (rotasi 14 ), dan tidak ada rotasi yang akan terjadi jika file kosong (notifempty ). Simpan dan tutup file.
 

 Jika log ModSecurity Anda kosong, mungkin Anda perlu memulai ulang Nginx.
 
sudo systemctl restart nginx
 
Langkah 10:Menangani Positif Palsu
 

 ModSecurity adalah firewall aplikasi web generik dan tidak dirancang untuk aplikasi web tertentu. Kumpulan aturan inti OWASP juga merupakan kumpulan aturan umum tanpa memikirkan aplikasi tertentu, jadi kemungkinan Anda akan melihat kesalahan positif setelah mengaktifkan ModSecurity dan OWASP CRS. Jika Anda meningkatkan tingkat paranoia di CRS, akan ada lebih banyak positif palsu.
 

 Misalnya, secara default, CRS melarang injeksi perintah Unix seperti memasukkan sudo di halaman web, yang agak umum di blog saya. Untuk menghilangkan positif palsu, Anda perlu menambahkan pengecualian aturan ke CRS.
 
Pengecualian Aturan Khusus Aplikasi 
 

 Ada beberapa pengecualian khusus aplikasi bawaan yang dikirimkan bersama OWASP CRS. Edit crs-setup.conf berkas.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Buka Pengecualian Aturan Khusus Aplikasi bagian dan temukan baris berikut.
 
#SecAction \# "id:900130,\# phase:1,\# nolog,\# pass,\# t:none,\# setvar:tx.crs_exclusions_cpanel=1,\# setvar:tx.crs_exclusions_drupal=1,\# setvar:tx.crs_exclusions_dokuwiki=1,\# setvar:tx.crs_exclusions_nextcloud=1,\# setvar:tx.crs_exclusions_wordpress=1,\# setvar:tx.crs_exclusions_xenforo=1"
 

 Misalnya, Jika saya ingin mengaktifkan pengecualian WordPress, baris di atas harus diubah menjadi yang berikut. Harap berhati-hati tentang sintaks. Tidak boleh ada komentar di antara t:none,\ dan setvar:tx.crs_exclusions_wordpress=1" . (Garis miring \ karakter di akhir menunjukkan baris berikutnya adalah kelanjutan dari baris saat ini.)
 
SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_wordpress=1"# setvar:tx.crs_exclusions_cpanel=1,\# setvar:tx. crs_exclusions_drupal=1,\# setvar:tx.crs_exclusions_dokuwiki=1,\# setvar:tx.crs_exclusions_nextcloud=1,\# setvar:tx.crs_exclusions_xenforo=1"
 

 Simpan dan tutup file. Kemudian uji konfigurasi Nginx.
 
sudo nginx -t
 

 Jika pengujian berhasil, muat ulang Nginx agar perubahan diterapkan.
 
sudo systemctl reload nginx
 

 Perhatikan bahwa jika Anda memiliki beberapa aplikasi seperti (WordPress, Nextcloud, Drupal, dll) yang diinstal pada server yang sama, maka pengecualian aturan di atas akan diterapkan ke semua aplikasi. Untuk meminimalkan risiko keamanan, Anda harus mengaktifkan pengecualian aturan untuk satu aplikasi saja. Untuk melakukannya, buka /etc/nginx/modsec/coreruleset-3.3.0/rules/ direktori.
 
cd /etc/nginx/modsec/coreruleset-3.3.0/rules
 

 Ganti nama REQUEST-900-EXCLUSION-RULES-BEFORE-CRS berkas.
 
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Kemudian edit file ini.
 
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Tambahkan baris berikut di bagian bawah file ini. Jika WordPress Anda menggunakan blog.yourdomain.com sub-domain dan header permintaan yang dikirim dari browser pengunjung berisi sub-domain ini, maka ModSecurity akan menerapkan pengecualian aturan untuk WordPress.
 
SecRule REQUEST_HEADERS:Host "@streq blog.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"
 

 Jika Anda telah menginstal Nextcloud di server yang sama, maka Anda juga dapat menambahkan baris berikut di file ini, jadi jika pengunjung mengakses sub-domain Nextcloud Anda, ModSecurity akan menerapkan pengecualian aturan Nextcloud.
 
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"
 

 Simpan dan tutup file ini. Kemudian uji konfigurasi Nginx.
 
sudo nginx -t
 

 Jika pengujian berhasil, muat ulang Nginx agar perubahan diterapkan.
 
sudo systemctl reload nginx
 
Pengecualian Aturan Kustom
 

 Mengaktifkan pengecualian aturan khusus aplikasi bawaan mungkin tidak menghilangkan semua kesalahan positif. Jika demikian, Anda perlu memeriksa log audit ModSecurity (/var/log/modsec_audit.log ), periksa aturan mana yang menyebabkan false positive dan tambahkan pengecualian aturan khusus Anda di REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf berkas.
 

 Bagian H di log audit memberi tahu Anda aturan mana yang cocok. Misalnya, Jika saya mencoba menggunakan <code>...</code> HTML dalam bentuk komentar, ModSecurity memblokir komentar saya. Log berikut memberi tahu saya bahwa permintaan HTTP cocok dengan aturan di REQUEST-941-APPLICATION-ATTACK-XSS.conf (baris 527). ID aturannya adalah 941310. URI permintaannya adalah /wp-comments-post.php .
 

 
 

 Ini terdeteksi sebagai serangan penyandian penyandian XSS yang salah. Namun, saya ingin pengguna dapat menggunakan <code>...</code> dan <pre>...</pre> Tag HTML dalam formulir komentar, jadi saya membuat pengecualian aturan. Tambahkan baris berikut di bagian bawah REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf berkas.
 
SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"
 

 Baris ini memberi tahu ModSecurity bahwa jika URI permintaan adalah /wp-comments-post.php , maka jangan terapkan rule ID 941310. Simpan dan tutup file. Kemudian uji konfigurasi Nginx.
 
sudo nginx -t
 

 Jika tes berhasil, muat ulang Nginx.
 
sudo systemctl reload nginx
 

 Jika positif palsu cocok dengan beberapa ID aturan, Anda dapat menambahkan pengecualian aturan dalam satu baris seperti:
 
SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1,ctl:ruleRemoveById=941160 ,ctl:ruleRemoveById=941310 ,ctl:ruleRemoveById=942100 "
 

 Catatan :Tidak disarankan untuk menonaktifkan terlalu banyak aturan level 1 di OWASP CRS, karena akan membuat situs web Anda lebih mudah diretas. Nonaktifkan aturan hanya jika Anda tahu apa yang Anda lakukan.
 
Daftar Putih IP
 

 Jika Anda ingin menonaktifkan ModSecurity untuk alamat IP Anda sendiri, tetapi membiarkannya diaktifkan untuk semua alamat IP lainnya, tambahkan aturan khusus berikut di REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf mengajukan. Ganti 12.34.56.78 dengan alamat IP asli Anda.
 
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"
 

 Untuk memasukkan subnet ke daftar putih, gunakan sintaks berikut, yang akan memasukkan 10.10.10.0/24 ke daftar putih jaringan.
 
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:105,phase:1,allow,ctl:ruleEngine=off"
 

 Simpan dan tutup file. Kemudian uji konfigurasi Nginx.
 
sudo nginx -t
 

 Jika pengujian berhasil, mulai ulang Nginx agar perubahan diterapkan.
 
sudo systemctl restart nginx
 
Aturan Rantai
 

 Jika Nginx Anda memiliki beberapa host virtual, Anda mungkin ingin memasukkan alamat IP Anda ke daftar putih untuk host virtual tertentu. Anda perlu merangkai dua aturan seperti ini:
 
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain"SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:tidak ada"
 

 chain kata kunci di akhir aturan pertama menunjukkan bahwa ruleEngine=off tindakan hanya akan dilakukan jika kondisi pada aturan berikutnya juga benar.
 
(Opsional) Integrasikan ModSecurity dengan Project Honeypot
 

 Project Honeypot menyimpan daftar alamat IP berbahaya yang diketahui, tersedia gratis untuk umum. ModSecurity dapat terintegrasi dengan Project Honeypot dan memblokir alamat IP pada daftar Project Honeypot.
 

 Perhatikan bahwa menggunakan Project Honeypot akan membuat situs web Anda lebih lambat untuk pengunjung baru, karena server web Anda perlu mengirim kueri ke Project Honeypot sebelum dapat mengirim tanggapan kepada pengunjung baru. Namun, setelah data reputasi IP di-cache di server web Anda, dampak kinerjanya akan sangat minimal.
 

 Untuk menggunakan Project Honeypot, pertama buat akun gratis di situs webnya. Kemudian buka dasbor akun Anda dan klik get one link untuk meminta kunci akses untuk daftar hitam HTTP.
 

 
 

 Selanjutnya, edit crs-setup.conf berkas.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Temukan baris berikut.
 
#SecHttpBlKey XXXXXXXXXXXXXXXXXX#SecAction "id:900500,\# phase:1,\# nolog,\# pass,\# t:none,\# setvar:tx.block_search_ip=1,\# setvar:tx.block_suspicious_ip =1,\# setvar:tx.block_harvester_ip=1,\# setvar:tx.block_spammer_ip=1"
 

 Hapus # beginning awal karakter untuk menghapus komentarnya, dan menambahkan kunci API HTTPBL Anda yang diperoleh dari Project Honeypot.
 

 
 

 Perhatikan bahwa block_search_ip harus disetel ke 0 (dinonaktifkan), karena kami tidak ingin memblokir perayap mesin telusur. Simpan dan tutup file. Kemudian muat ulang Nginx.
 
sudo systemctl reload nginx
 

 Sekarang ModSecurity akan menanyakan Project Honeypot pada semua permintaan HTTP. Untuk menguji apakah ini akan berhasil, edit file /etc/nginx/modsec/main.conf.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Tambahkan baris berikut di akhir file ini. Hal ini memungkinkan kita untuk melewatkan alamat IP dalam sebuah URL. (Setelah pengujian berhasil, Anda dapat menghapus baris ini dari file.)
 
SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'
 

 Simpan dan tutup file. Uji konfigurasi Nginx.
 
sudo nginx -t
 

 Kemudian muat ulang Nginx.
 
sudo systemctl reload nginx
 

 Buka situs web Project Honeypot dan temukan alamat IP berbahaya, misalnya 134.119.218.243. Jalankan perintah berikut untuk menguji daftar hitam HTTP.
 
curl -i -s -k -X $'GET' 'https://domainanda.com/?IP=134.119.218.243'
 

 Server web Anda harus mengembalikan 403 respons terlarang, karena alamat IP di Project Honeypot.
 
Cara Menggunakan Brotli dengan ModSecurity di Nginx
 

 Secara tradisional, halaman web dikompres dengan GZIP untuk kecepatan pemuatan yang lebih cepat. Dikembangkan oleh Google, Brotli adalah algoritma kompresi baru yang memberikan rasio kompresi yang lebih baik. Ini didukung oleh semua browser web utama. Untuk menggunakan Brotli di Nginx, pertama-tama Anda perlu menginstal modul Brotli Nginx dari ondrej/nginx-mainline PPA.
 
sudo apt install libnginx-mod-brotli
 

 Kemudian buka file konfigurasi Nginx utama.
 
sudo nano /etc/nginx/nginx.conf
 

 Add the following lines in the http {...} context.
 
 brotli on; brotli_comp_level 6; brotli_static on; brotli_types application/atom+xml application/javascript application/json application/rss+xml application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/x-javascript application/xhtml+xml application/xml font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;
 

 Save and close the file, then test Nginx configurations.
 
sudo nginx -t
 

 If the test is successful, restart Nginx.
 
sudo systemctl restart nginx
 

 Now go to the home page your website, open the developer tools in your web browser (In Firefox you can press Ctrl+Alt+I to open it up). Select the Network tab, and press F5 to reload the web page. Click on the main HTML page.
 

 
 

 Check the response header on the right sidebar. If the content-encoding is set to br , then you have successfully enabled Brotli compression in Nginx.
 

 
 

 If the content-encoding is gzip , then your Nginx web server is still using GZIP.
 
Upgrading Nginx
 

 ModSecurity integrates with Nginx as a dynamic module, so every time the Nginx binary is upgraded, you need to rebuild the ModSecurity module for Nginx. This will make your application offline for a few minutes.
 

 If a newer version of Nginx is available in the repository, the sudo apt upgrade command will upgrade Nginx. The newer version of Nginx is not going to be compatible with the previously compiled ModSecurity module. If Nginx is upgraded by the sudo apt upgrade command, it will fail to restart as shown in the screenshot below.
 

 
 

 And if you run sudo nginx -t command, it tells you that Nginx expects a new version of the ModSecurity module.
 

 
 

 My advice is to prevent Nginx from being upgraded when you run sudo apt upgrade memerintah. This can be achieved by the following command:
 
sudo apt-mark hold nginx
 

 Now if you run sudo apt update;sudo apt upgrade , and the package manager tells you that the nginx package is held back from upgrading, then it means there’s a new nginx version available in the repository.
 

 
 

 You should download the new Nginx source package and compile the ModSecurity module again. Move the newly-compiled ModSecurity module to /usr/share/nginx/modules/ direktori. Basically that means you need to remove everything under /usr/local/src/ directory (sudo rm /usr/local/src/* -rf ) and go through step 2 and step 4 again.
 

 Then unhold Nginx.
 
sudo apt-mark unhold nginx
 

 And upgrade Nginx.
 
sudo apt upgrade nginx
 

 Once the upgrade is complete, hold Nginx again.
 
sudo apt-mark hold nginx
 

 To show what packages are held, run
 
apt-mark showhold
 
Nginx Plus
 

 If you use the commercial Nginx Plus web server, then ModSecurity is included in the Nginx Plus binary. It’s known as the NGINX WAF .
 

 If you don’t want to spend time re-compiling the ModSecurity source code, then you might want to purchase Nginx Plus, as the ModSecurity module is pre-compiled in the Nginx Plus binary. Benefits of Using ModSecurity 3.0 with NGINX Plus:
 
 
You don’t need to compile the ModSecurity dynamic module yourself;  NGINX, Inc. provides a precompiled module for you, saving time and effort.
 
NGINX, Inc. has extensively tested the dynamic module, so you know it’s suitable for production usage.
 
NGINX, Inc. continually tracks changes and updates the module for every important change and security vulnerability, so you don’t have to do this yourself.
 
Each new release of NGINX Plus includes a new version of the dynamic module, so you can upgrade without having to re-compile ModSecurity.
 
You get 24×7 support with both installation of the ModSecurity and the OWASP Core Rule Set, as well as troubleshooting and debugging assistance.
 
 
How to Disable ModSecurity for a Virtual Host
 

 In this tutorial, I added the following line in the http {...} context.
 
modsecurity on;
 

 This will enable ModSecurity for all Nginx server blocks (aka virtual hosts). If you want to disable ModSecurity for a specific server block, then edit the server block file (/etc/nginx/conf.d/example.com.conf ) and add the following line to the server {...} context.
 
modsecurity off;
 

 Reload Nginx for the change to take effect.
 
sudo systemctl reload nginx
 
FAQ
 
Static Module vs Dynamic Module in Nginx
 
 
A static module must be compiled with Nginx and it’s integrated with Nginx as one binary. It can’t be unloaded from Nginx.
 
A dynamic module is a separate package from the main Nginx binary. It can be loaded and unloaded in Nginx.
 
 
What does Binary Compatible Mean?
 
 
If a dynamic module is not binary compatible, then the module and Nginx should be compiled together. If there’s an existing Nginx binary installed from a software repository using apt-get , it must be removed and you need to install the compiled Nginx binary in order to use the dynamic module.
 
If a dynamic module is binary compatible, then this module can be compiled individually without compiling Nginx. The module can be used with your existing Nginx binary installed from a software repository. It’s not perfect, though.
 
 

 No matter a module is static or dynamic, binary compatible or non binary compatible, if you upgrade the Nginx binary later, you need to compile the module again.
 
Upgrade Server RAM
 

 ModSecurity can use a fair amount of RAM. If you can see the following error in your Nginx error log (/var/log/nginx/error.log), it means your server is short of RAM.
 
fork() failed while spawning "worker process" (12:Cannot allocate memory)sendmsg() failed (9:Bad file descriptor)sendmsg() failed (9:Bad file descriptor)sendmsg() failed (9:Bad file descriptor)
 

 You need to restart Nginx and upgrade server RAM, then the above error is not going to happen again.
 
How to Upgrade OWASP CRS
 

 Besides upgrading the ModSecurity Nginx module, you also need to upgrade the core rule set when a new version comes out. The process is straightforward.
 
 
Go through step 6 again to install the new version of core rule set.
 
Then go to step 10. Copy of your custom rules in the crs-setup.conf   and REQUEST-900-EXCLUSION-RULES-BEFORE-CRS file.
 
 

 Next, test Nginx configurations.
 
sudo nginx -t
 

 If the test is successful, reload Nginx for the change to take effect.
 
sudo systemctl reload nginx
 

 How do you know if the new version is working? Launch a simple SQL injection attack like in step 8 and check your server logs. It will show you the CRS version that’s preventing this attack.