Nginx hardening: semak HTTPS, had akses dan reload

Audit konfigurasi Nginx bermula dengan memahami tetapan yang digunakan, kemudian menguji perubahan kecil yang boleh dipulihkan. Panduan ini membantu admin Linux menyemak HTTPS, had request dan akses tanpa bergantung pada satu konfigurasi salin-tampal.

Mulakan dengan bukti konfigurasi

Matlamat hardening di sini ialah menghasilkan rekod perubahan yang boleh disemak: tetapan asal, sebab perubahan, keputusan ujian dan pelan pemulihan. Panduan ini bersifat evergreen, bukan laporan vulnerability atau insiden baharu. Ia sesuai untuk admin yang mengendalikan Nginx pada Linux, termasuk pemasangan Ubuntu.

Dokumentasi upstream menyediakan semantik directive; nilai yang sesuai tetap bergantung pada aplikasi. Bezakan keputusan “konfigurasi sah” dengan keputusan “aplikasi berfungsi mengikut polisi”. Untuk latihan, gunakan staging atau makmal yang anda miliki dan diberi kebenaran mengurusnya. Arahan di bawah tidak dijalankan pada server Nginx dalam penyediaan artikel ini.

Ringkasan audit Nginx dengan fokus HTTPS, had request dan pengesahan sebelum reload

Kenal pasti instance dan laluan perubahan

Tentukan scope dahulu: nama laman, endpoint pentadbiran, aliran upload dan pihak yang meluluskan perubahan. Sediakan salinan konfigurasi asal melalui proses backup organisasi. Simpan salinan itu di lokasi terkawal, bukan dalam direktori yang disajikan kepada pengguna web. Catat cara memulihkan konfigurasi sebelum mula menyuntingnya.

Gunakan arahan berikut pada instance makmal yang hendak diaudit. nginx -V memaparkan versi, compiler dan parameter binaan. nginx -t menyemak sintaks serta cuba membuka fail yang dirujuk konfigurasi. nginx -T menambah paparan fail konfigurasi kepada semakan tersebut. Dokumentasi parameter Nginx.

nginx -V
nginx -t
nginx -T

Jalankan dengan akaun operasi yang dibenarkan membaca fail konfigurasi berkaitan. Pastikan binary dan konteks konfigurasi sama dengan service sebenar; jika pemasangan menggunakan konfigurasi alternatif, dokumentasi menyediakan pilihan -c. Jangan menganggap semakan konfigurasi default mewakili semua instance. Output konfigurasi hendaklah disimpan secara terkawal dan disanitasi sebelum dimasukkan ke tiket atau laporan.

Pada Ubuntu, dokumentasi rasmi menggunakan sudo systemctl status nginx untuk menyemak service. Status berjalan memberi titik mula bagi semakan operasi; pasukan masih perlu menguji fungsi aplikasi selepas perubahan. Panduan Ubuntu.

HTTPS: semak kunci dan keserasian client

Private key perlu disimpan dengan akses terhad, tetapi masih boleh dibaca oleh master process Nginx. Jangan longgarkan akses seluruh direktori hanya untuk menghilangkan ralat bacaan. Semak pemilik fail dan mekanisme pengurusan sijil bersama admin yang bertanggungjawab. Dokumentasi Nginx juga menetapkan sijil server mendahului sijil perantara dalam fail gabungan. Konfigurasi HTTPS Nginx.

OWASP mengesyorkan TLS 1.3 sebagai default dan membenarkan TLS 1.2 bagi keserasian, sambil melumpuhkan TLS 1.0 serta TLS 1.1. Jadikan ini sasaran polisi dan semak keupayaan client sebelum perubahan. Panduan TLS OWASP.

Nginx menyatakan default protokol pernah berubah. Oleh itu, semak versi terpasang dan konfigurasi sebenar sebelum bergantung pada default. Sebagai contoh pembelajaran, directive ssl_protocols TLSv1.2 TLSv1.3; dalam konfigurasi HTTPS upstream mengehadkan pilihan protokol tersebut. Ia bukan konfigurasi HTTPS lengkap atau bukti bahawa semua client organisasi sudah serasi. Dokumentasi HTTPS.

Untuk pengesahan, gunakan nama laman yang sebenar dalam makmal, semak sijil yang diterima client dan bandingkan dengan jangkaan. Rekod kejayaan serta kegagalan client yang mewakili penggunaan organisasi. Jangan menutup ralat sijil sebagai cara meluluskan ujian. Jika keserasian gagal, tangguhkan perubahan dan tentukan puncanya sebelum melonggarkan polisi.

Aliran operasi audit daripada backup kepada semakan sintaks, reload dan ujian fungsi

Had request dan akses mesti ikut aplikasi

client_max_body_size menentukan had saiz request body; request yang melebihinya menerima HTTP 413. Nilai 0 mematikan semakan saiz itu. Cadangan praktikalnya ialah menyenaraikan endpoint upload dan had yang diperlukan sebelum memilih nilai, bukannya menetapkan had paling kecil untuk semua laluan. Nginx core module.

Bagi latihan staging dengan keperluan maksimum 2 MiB, contoh directive ialah client_max_body_size 2m; dalam konteks server atau location yang berkaitan. Nilai ini contoh polisi makmal, bukan saranan universal. Sediakan fail ujian kecil yang diterima dan satu fail sedikit melebihi had; jalankan request biasa secara manual, tanpa ujian beban. Semak response serta fungsi upload, kemudian laraskan berdasarkan keperluan yang diluluskan.

client_body_in_file_only mengawal penyimpanan keseluruhan request body ke fail dan boleh digunakan untuk debugging. Dokumentasi menyatakan nilai on meninggalkan fail sementara selepas request diproses. Semak sama ada tetapan debugging masih diperlukan dan siapa boleh membaca storan tersebut. Jangan gunakan data pelanggan sebenar untuk latihan ini. Nginx core module.

Untuk access control berasaskan alamat client, Nginx memeriksa allow dan deny mengikut urutan sehingga padanan pertama. Rule pada aras lebih tinggi hanya diwarisi apabila aras semasa tidak mempunyai directive allow atau deny sendiri. Semak setiap lokasi sensitif dan laluan berlapis sebelum menganggap polisi diwarisi. Nginx access module.

Cadangan semakan akses: gunakan client makmal yang sepatutnya dibenarkan dan client yang sepatutnya ditolak. Uji endpoint sama melalui laluan penggunaan sebenar. Rekod alamat client yang dinilai dan hasilnya. Jika terdapat proxy di hadapan Nginx, minta pemilik seni bina mengesahkan identiti client sebelum menerima keputusan audit.

Perbandingan semakan protokol, saiz request, fail debugging dan urutan rule akses

Lulus sintaks, kemudian sahkan fungsi

Ubah satu kumpulan tetapan pada satu masa. Selepas backup dan suntingan dalam makmal, jalankan nginx -t. Jika semakan gagal, betulkan ralat atau pulihkan salinan asal dahulu. Reload hanya selepas semakan lulus dan perubahan diluluskan; nginx -s reload ialah arahan upstream untuk meminta master process memuat semula konfigurasi. Parameter Nginx.

Nginx menerangkan bahawa apabila penerapan konfigurasi baharu gagal semasa reload, master process meneruskan konfigurasi lama. Apabila berjaya, worker baharu bermula dan worker lama menyelesaikan client sedia ada sebelum tamat. Mekanisme ini tidak menggantikan ujian fungsi: polisi yang sah sintaks masih boleh bercanggah dengan keperluan aplikasi. Kawalan Nginx.

Kriteria penerimaan yang dicadangkan: laman dapat dibuka melalui HTTPS tanpa ralat sijil, upload sah masih berjaya, request melebihi had ditolak dan akses pentadbiran menepati polisi. Bandingkan log operasi sebelum dan selepas perubahan. Kod ralat sahaja tidak mencukupi untuk menyimpulkan berlaku serangan; padankan masa, endpoint dan tindakan ujian yang telah direkodkan.

Pemulihan dan tindakan pasukan Malaysia

Jika semakan fungsi gagal, hentikan perubahan seterusnya. Pulihkan konfigurasi daripada backup yang diketahui baik, jalankan semula semakan sintaks, kemudian reload melalui prosedur operasi yang diluluskan. Ulang ujian penerimaan yang sama. Catat sebab pemulihan supaya pasukan seterusnya tidak mengulangi perubahan tanpa memahami kesannya. Ini pelan operasi yang disyorkan, bukan keputusan ujian server sebenar.

Bagi pasukan Malaysia, masukkan pemilik aplikasi dan petugas sokongan ke dalam jadual perubahan. Tetapkan siapa menyemak sijil, siapa mengesahkan upload dan siapa boleh memutuskan pemulihan. Simpan bukti yang disanitasi bersama tiket, termasuk masa semakan dan konfigurasi yang diluluskan. Pilih waktu yang membolehkan pemilik aplikasi memberi maklum balas segera.

MITRE ATT&CK M1030 menyarankan pengasingan service yang menghadap Internet daripada rangkaian lain. Gunakan panduan itu untuk perbincangan seni bina berasingan; checklist Nginx ini tidak membuktikan segmentasi rangkaian organisasi berkesan. MITRE Network Segmentation.