Skip to content

O
osrm-server-setup
Commit 3790712c by Bambang Adrian
Options

chore(doc): remove some unused contents and add some used git scenarios

parent 320f0bcf
Showing with 38 additions and 93 deletions
configs/cloudflared/cloudflare-setup.md
......@@ -5,9 +5,9 @@ Dokumen ini menjelaskan langkah-langkah lengkap untuk mempublikasikan layanan OS
#### **Premis dan Kompromi Utama**
Tujuan kita adalah membuat layanan dapat diakses melalui domain publik `geotency.com`, sementara domain teknis yang terhubung ke Cloudflare adalah `diffsquare.web.id`.
Tujuan proses ini adalah membuat layanan dapat diakses melalui domain publik `geotency.com`, sementara domain teknis yang terhubung ke Cloudflare adalah `diffsquare.web.id`.
Karena batasan pada **Cloudflare Free Tier**, kita tidak bisa menggunakan `CNAME` dari domain eksternal (`geotency.com`) untuk menyembunyikan domain teknis. Oleh karena itu, kita akan menggunakan solusi **URL Redirect (Pengalihan URL)**.
Karena batasan pada **Cloudflare Free Tier**, proses ini tidak bisa menggunakan `CNAME` dari domain eksternal (`geotency.com`) untuk menyembunyikan domain teknis. Oleh karena itu, proses ini akan menggunakan solusi **URL Redirect (Pengalihan URL)**.
**Konsekuensi Penting:** Saat pengguna mengakses `https://osrm.geotency.com`, bilah alamat di browser mereka akan **otomatis berubah** menjadi `https://osrm.diffsquare.web.id`. Ini adalah kompromi yang tidak bisa dihindari pada paket Free.
......@@ -191,6 +191,4 @@ Karena batasan pada **Cloudflare Free Tier**, kita tidak bisa menggunakan `CNAME
2. **Tes Routing:** Di halaman `https://osrm.diffsquare.web.id`, coba lakukan routing. Buka *developer tools* (F12) dan pastikan permintaan XHR ditujukan ke `https://route.diffsquare.web.id` dan berhasil (Status 200 OK).
3. **Akses Publik (Uji Redirect):** Buka browser dalam mode penyamaran (incognito).
* Ketik `https://osrm.geotency.com` dan tekan Enter. Bilah alamat **harus berubah** menjadi `https://osrm.diffsquare.web.id` dan menampilkan frontend.
* Ketik `https://route.geotency.com` dan tekan Enter. Bilah alamat **harus berubah** menjadi `https://route.diffsquare.web.id` dan menampilkan respons JSON.
Jika semua verifikasi ini berhasil, maka seluruh sistem telah dikonfigurasi dengan benar sesuai dengan batasan dan tujuan yang ada.
\ No newline at end of file
* Ketik `https://route.geotency.com` dan tekan Enter. Bilah alamat **harus berubah** menjadi `https://route.diffsquare.web.id` dan menampilkan respons JSON.
\ No newline at end of file
configs/cloudflared/reload-tunnel-setup.md
......@@ -113,11 +113,11 @@ Untuk memastikan semuanya sudah bersih:
### **Analisis Situasi**
Mari kita bedah apa artinya ini:
Mari proses ini bedah apa artinya ini:
1. **Dua Instalasi yang Berkonflik**: saat ini memiliki dua "mode" `cloudflared` yang ter-setup:
* **Mode Sistem (Yang Sedang Aktif)**: Dikelola dengan `sudo systemctl`, konfigurasinya berada di `/etc/cloudflared/config.yml`, dan berjalan sebagai user `root`. Inilah yang ditunjukkan oleh output.
* **Mode User/Rootless (Yang Kita Tuju)**: Dikelola dengan `systemctl --user`, konfigurasinya berada di `~/.cloudflared/config.yml`, dan berjalan sebagai user `sysadmin`.
* **Mode User/Rootless (Yang proses ini Tuju)**: Dikelola dengan `systemctl --user`, konfigurasinya berada di `~/.cloudflared/config.yml`, dan berjalan sebagai user `sysadmin`.
2. **Sumber Masalah**: Service level sistem ini kemungkinan besar adalah sisa dari instalasi sebelumnya atau dari mengikuti panduan yang berbeda. Karena service ini sudah `enabled` dan `active`, ia akan selalu berjalan di latar belakang dan bisa menyebabkan:
* **Kebingungan**: mungkin mengedit file di `~/.cloudflared/config.yml`, tetapi `cloudflared` yang aktif justru membaca dari `/etc/cloudflared/config.yml`.
......@@ -126,11 +126,11 @@ Mari kita bedah apa artinya ini:
### **Rekomendasi Solusi**
Untuk menjaga konsistensi dengan tujuan setup rootless kita dan untuk menghindari semua potensi konflik, sangat disarankan untuk **menonaktifkan dan menghapus service level sistem ini**. Dengan begitu, kita bisa memastikan bahwa satu-satunya `cloudflared` yang berjalan adalah yang kita kelola sebagai user `sysadmin`.
Untuk menjaga konsistensi dengan tujuan setup rootless proses ini dan untuk menghindari semua potensi konflik, sangat disarankan untuk **menonaktifkan dan menghapus service level sistem ini**. Dengan begitu, proses ini bisa memastikan bahwa satu-satunya `cloudflared` yang berjalan adalah yang proses ini kelola sebagai user `sysadmin`.
### **Langkah-Langkah untuk Menonaktifkan Service Sistem**
Silakan jalankan perintah berikut secara berurutan. Perhatikan penggunaan `sudo` karena kita berinteraksi dengan service sistem.
Silakan jalankan perintah berikut secara berurutan. Perhatikan penggunaan `sudo` karena proses ini berinteraksi dengan service sistem.
1. **Hentikan Service Sistem:**
Perintah ini akan menghentikan proses `cloudflared` (PID 1571) yang sedang berjalan.
......@@ -170,4 +170,4 @@ sudo mv /etc/cloudflared /etc/cloudflared.backup
### **Langkah Berikutnya**
Setelah service sistem ini tidak aktif, kita bisa melanjutkan proses penghapusan tunnel dari sisi *user* (rootless) seperti yang kita diskusikan di pesan sebelumnya, tanpa ada gangguan dari proses lain. sekarang memiliki kontrol penuh atas proses `cloudflared` yang berjalan sebagai user.
\ No newline at end of file
Setelah service sistem ini tidak aktif, lanjutkan proses penghapusan tunnel dari sisi *user* (rootless) seperti yang proses ini diskusikan di pesan sebelumnya, tanpa ada gangguan dari proses lain. sekarang memiliki kontrol penuh atas proses `cloudflared` yang berjalan sebagai user.
\ No newline at end of file
docs/altinstall-osrm.md
......@@ -315,17 +315,3 @@ Frontend URL:
Logs stored at: ~/data/docker-data/osrm/logs/osrm-installer-20251015.log
```
---
## 10. Konfirmasi Sebelum Implementasi
Mohon konfirmasi hal berikut:
1. Apakah semua flag dan behavior sudah sesuai (termasuk pemisahan `update-*` & `remove-*`)?
2. Apakah format URL backend `http://{backend-domain}:{backend-port}/osrm/{api-version}/{profile}` sudah final?
3. Apakah lokasi default (`~/data/docker-data/osrm`) boleh di-hardcode dalam skrip (dapat diubah via `--work-dir`)?
4. Apakah backup otomatis (zip sebelum override) tetap diaktifkan?
5. Apakah kamu ingin output tambahan berupa file `config-summary.json` untuk dokumentasi hasil instalasi?
Setelah kamu konfirmasi, saya akan lanjut ke tahap **penulisan bashscript implementasi final** sesuai spesifikasi ini.
docs/install-compose-rootless.md
......@@ -469,23 +469,3 @@ Output yang tampilkan secara definitif memvalidasi beberapa poin kritis dari skr
4. **Verifikasi Ganda**:
* **Verifikasi Internal**: Langkah "Memverifikasi instalasi..." di dalam skrip berhasil, yang berarti perintah `docker compose version` dapat dijalankan oleh skrip itu sendiri.
* **Verifikasi Manual**: melakukan verifikasi manual pasca-eksekusi dengan `docker compose version`, yang memberikan konfirmasi akhir dan tak terbantahkan bahwa plugin telah terintegrasi dengan benar ke dalam Docker CLI.
### Kesimpulan dan Status Final
Ini adalah studi kasus yang sempurna tentang pentingnya *debugging* dan verifikasi. Laporan bug yang presisi memungkinkan identifikasi dan perbaikan cepat, menghasilkan produk akhir yang jauh lebih kuat.
Dengan ini, saya menyatakan bahwa skrip `install-compose-rootless.sh` versi 2.1, seperti yang terdokumentasi dalam **KB-DEVOPS-2024-001**, telah terverifikasi dan divalidasi untuk penggunaan di lingkungan target. Skrip ini sekarang memenuhi semua spesifikasi yang diminta:
* **Modular dan DRY**: Ya.
* **Dinamis dan Parameterized**: Ya.
* **Verbose dan Dry Run Mode**: Ya, dan sekarang berfungsi dengan benar.
* **Penanganan Error yang Handal**: Ya, terbukti dari perbaikan `set -e`.
* **Validasi dan Pengecekan Lengkap**: Ya.
### Langkah Selanjutnya yang Direkomendasikan
1. **Standarisasi**: Gunakan skrip versi 2.1 ini sebagai standar untuk semua deployment baru.
2. **Version Control**: Simpan skrip ini di dalam repositori Git (misalnya, dalam direktori `scripts` atau `automation`) untuk pelacakan perubahan dan kolaborasi tim.
3. **Integrasi Otomatisasi**: sekarang dapat dengan percaya diri mengintegrasikan skrip ini ke dalam *playbook* Ansible, skrip *provisioning* Terraform, atau pipeline CI/CD lainnya, dengan mengetahui bahwa skrip ini akan berperilaku secara konsisten danl.
Proses ini telah berhasil diselesaikan dengan standar tertinggi. Terima kasih atas kolaborasi yang sangat baik dalam mencapai hasil ini.
\ No newline at end of file
docs/install-docker.md
......@@ -235,8 +235,6 @@ main "$@"
Jika melihat pesan "Hello from Docker!", instalasi dan konfigurasi telah berhasil sepenuhnya.
Tentu, saya akan melakukan peninjauan ulang yang sangat detail, baris per baris, dan secara keseluruhan terhadap skrip Bash yang telah saya buat. Tujuannya adalah untuk memastikan skrip ini se-robust mungkin dan bebas dari potensi error atau perilaku yang tidak terduga.
### Tinjauan Keseluruhan
Skrip ini dirancang dengan baik dan sudah menerapkan banyak praktik terbaik dalam scripting Bash:
......@@ -248,7 +246,7 @@ Skrip ini dirancang dengan baik dan sudah menerapkan banyak praktik terbaik dala
### Analisis Detail Baris per Baris
Mari kita bedah setiap bagian penting.
Mari proses ini bedah setiap bagian penting.
---
......@@ -315,7 +313,7 @@ log_error() {
* **`parse_arguments()`**: Logikanya solid. Loop `while`, `case`, dan `shift` adalah pola standar untuk parsing argumen. Validasi `if [[ -z "$USERNAME" ]]` juga sangat penting dan diimplementasikan dengan benar. **Tidak ada error**.
* **`check_prerequisites()`**:
* `if [[ "$EUID" -ne 0 ]]`: Pengecekan hak akses root yang benar dan standar.
* `if ! grep -q ... || ! grep -q ...`: Logika untuk memeriksa OS dan versi sudah benar. Menggunakan `-q` (quiet) efisien karena kita hanya peduli dengan status keluarnya. **Tidak ada error**.
* `if ! grep -q ... || ! grep -q ...`: Logika untuk memeriksa OS dan versi sudah benar. Menggunakan `-q` (quiet) efisien karena proses ini hanya peduli dengan status keluarnya. **Tidak ada error**.
---
......
docs/install-ngpm.md
......@@ -19,7 +19,7 @@
Dokumen ini berfungsi sebagai panduan definitif untuk melakukan instalasi, penyiapan, dan konfigurasi **Nginx Proxy Manager (selanjutnya disebut "ngpm")** pada sistem operasi **Rocky Linux 10**.
* **WHAT (Apa):** Prosedur ini menguraikan deployment ngpm, sebuah antarmuka manajemen berbasis web untuk Nginx yang mempermudah pengelolaan *reverse proxy*, sertifikat SSL/TLS dari Let's Encrypt, dan *custom Nginx configurations* tanpa perlu menyentuh file konfigurasi secara manual.
* **WHY (Mengapa):** Metode ini dipilih karena mengedepankan prinsip keamanan dan isolasi modern. Dengan menjalankan kontainer Docker dalam **mode rootless**, kita secara drastis mengurangi permukaan serangan (*attack surface*). Jika terjadi kompromi pada kontainer, dampaknya terbatas pada lingkup pengguna non-root (`sysadmin`), bukan seluruh sistem. Penggunaan skrip otomasi memastikan proses yang konsisten, dapat diulang (*reproducible*), dan bebas dari kesalahan manusia (*human error*).
* **WHY (Mengapa):** Metode ini dipilih karena mengedepankan prinsip keamanan dan isolasi modern. Dengan menjalankan kontainer Docker dalam **mode rootless**, proses ini secara drastis mengurangi permukaan serangan (*attack surface*). Jika terjadi kompromi pada kontainer, dampaknya terbatas pada lingkup pengguna non-root (`sysadmin`), bukan seluruh sistem. Penggunaan skrip otomasi memastikan proses yang konsisten, dapat diulang (*reproducible*), dan bebas dari kesalahan manusia (*human error*).
* **WHO (Siapa):** Panduan ini ditujukan untuk para profesional teknis seperti System Administrator dan DevOps Engineer yang bertugas mengelola infrastruktur web dan memerlukan solusi *reverse proxy* yang efisien dan aman.
* **WHERE (Di Mana):** Implementasi dilakukan pada server yang menjalankan Rocky Linux 10, dengan prasyarat Docker Engine yang sudah terinstal dan dikonfigurasi untuk mode rootless di bawah pengguna `sysadmin`. Seluruh data persisten dan konfigurasi akan ditempatkan secara terstruktur di dalam direktori `~/data/docker-data/ngpm/`.
* **WHEN (Kapan):** Prosedur ini ideal untuk diterapkan pada lingkungan pengembangan, pengujian, maupun produksi baru di mana diperlukan gerbang (*gateway*) yang aman untuk mengekspos layanan internal ke jaringan publik atau internet.
......@@ -50,7 +50,7 @@ Solusi ini terdiri dari beberapa komponen utama yang bekerja sama dalam sebuah e
#### **3.0 Analisis Prosedur dan Tahapan Kritis**
Skrip otomasi yang akan kita kembangkan akan mengeksekusi serangkaian tahapan yang telah divalidasi secara logis.
Skrip otomasi yang akan proses ini kembangkan akan mengeksekusi serangkaian tahapan yang telah divalidasi secara logis.
1. **Parsing Argumen:** Langkah pertama adalah memproses input dari pengguna. Ini memungkinkan fleksibilitas tinggi tanpa harus mengubah kode skrip. Mode `--dry-run` akan diidentifikasi pada tahap ini.
2. **Pengecekan Pra-Instalasi (Pre-flight Checks):** Tahap paling krusial. Skrip akan memverifikasi:
......@@ -247,17 +247,17 @@ Jika semua verifikasi ini berhasil, maka instalasi dan konfigurasi Nginx Proxy M
#### **7.0 Analisis dan Penyempurnaan Skrip**
Skrip referensi awal sudah cukup baik, namun beberapa area dapat ditingkatkan untuk memenuhi standar perfeksionis dan skeptis yang kita anut. Berikut adalah perubahan kunci dan justifikasinya:
Skrip referensi awal sudah cukup baik, namun beberapa area dapat ditingkatkan untuk memenuhi standar perfeksionis dan skeptis yang proses ini anut. Berikut adalah perubahan kunci dan justifikasinya:
1. **Modularitas:** Fungsi-fungsi telah diorganisir kembali ke dalam blok logis yang lebih jelas: *Helpers*, *Pre-flight*, *Setup*, *Core Logic*, dan *Main Execution*.
2. **Penanganan Parameter:** Penggunaan `getopts` atau loop `case` adalah standar, namun saya akan memastikan validasi input lebih ketat dan pesan kesalahan lebih spesifik untuk setiap argumen yang tidak valid.
2. **Penanganan Parameter:** Penggunaan `getopts` atau loop `case` adalah standar, namun perlu memastikan validasi input lebih ketat dan pesan kesalahan lebih spesifik untuk setiap argumen yang tidak valid.
3. **Robustisitas:**
* **Quoting Variabel:** Semua ekspansi variabel (contoh: `"${PROJECT_DIR}"`) diapit dengan kutip guntuk mencegah masalah dengan spasi atau karakter khusus dalam path atau nama. Ini adalah praktik fundamental yang sering diabaikan.
* **Heredoc Safety:** Penulisan file konfigurasi menggunakan `heredoc` telah diperbaiki untuk menghindari ekspansi variabel yang tidak diinginkan di dalam *template*. Variabel akan diekspansi secara eksplisit dan aman.
* **Error Handling `cd`:** Perintah `cd` dapat gagal. Saya akan memastikan skrip berhenti jika gagal berpindah direktori untuk mencegah eksekusi perintah di lokasi yang salah.
* **Error Handling `cd`:** Perintah `cd` dapat gagal. Skrip berhenti jika gagal berpindah direktori untuk mencegah eksekusi perintah di lokasi yang salah.
4. **Keamanan:**
* **Permissions:** Meskipun tidak diminta secara eksplisit, *best practice* adalah mengatur izin pada file sensitif seperti `.env`. Namun, dalam konteks rootless, risiko ini sudah diminimalkan karena file dimiliki oleh user `sysadmin` dan tidak dapat diakses oleh user lain secara default.
* **Password Handling:** Penggunaan `openssl` untuk *password generation* sudah tepat. Saya akan memastikan tidak ada *logging* password ke stdout kecuali dalam mode `--dry-run` yang sangat eksplisit.
* **Password Handling:** Penggunaan `openssl` untuk *password generation* sudah tepat. Perlu memastikan tidak ada *logging* password ke stdout kecuali dalam mode `--dry-run` yang sangat eksplisit.
5. **Kepatuhan pada Permintaan Spesifik:**
* **Penamaan:** Penggunaan *dash-case* (`kebab-case`) akan diterapkan secara konsisten pada nilai default dan di seluruh dokumentasi. Istilah "ngpm" akan digunakan secara eksklusif.
* **Parameterized Variables:** Semua variabel yang minta telah dijadikan parameter yang dapat di-override melalui argumen CLI.
......@@ -856,7 +856,7 @@ Bagian ini menyediakan instruksi langkah-demi-langkah yang jelas untuk menyimpan
**9.2. Pemberian Izin Eksekusi**
1. **WHY:** Secara default, file baru tidak memiliki izin untuk dieksekusi. Kita harus memberikannya secara eksplisit untuk dapat menjalankan skrip.
1. **WHY:** Secara default, file baru tidak memiliki izin untuk dieksekusi. proses ini harus memberikannya secara eksplisit untuk dapat menjalankan skrip.
2. **HOW:** Gunakan perintah `chmod` untuk menambahkan *flag* eksekusi (`+x`).
```bash
chmod +x install-ngpm.sh
......@@ -1171,6 +1171,3 @@ Berdasarkan anomali healthcheck, berikut adalah langkah-langkah definitif yang h
3. **Periksa Sumber Daya Sistem Host:**
* Jalankan `top` atau `htop` pada server untuk memastikan tidak ada lonjakan CPU atau penggunaan memori yang ekstrem yang dapat memperlambat proses startup Docker container.
**Kesimpulan Akhir:**
Skrip berfungsi dengan sangat baik. Skrip ini tidak hanya melakukan tugasnya tetapi juga cukup cerdas untuk mendeteksi potensi masalah (healthcheck gagal) dan melaporkannya dengan jelas tanpa menghentikan proses secara tidak perlu. Log yang berikan adalah contoh sempurna dari bagaimana otomasi yang robust seharusnya bekerja: **eksekusi, verifikasi, dan pelaporan anomali.**
\ No newline at end of file
docs/install-osrm-ngpm.md
......@@ -23,7 +23,7 @@
### **1. Analisis Kebutuhan dan Ringkasan Spesifikasi**
Sebelum memulai implementasi, mari kita rekapitulasi dan validasi seluruh kebutuhan yang telah sampaikan. Ini memastikan keselarasan pemahaman dan menjadi dasar untuk semua keputusan teknis yang akan diambil.
Sebelum memulai implementasi, mari proses ini rekapitulasi dan validasi seluruh kebutuhan yang telah sampaikan. Ini memastikan keselarasan pemahaman dan menjadi dasar untuk semua keputusan teknis yang akan diambil.
#### **1.1. Format Tabular**
......@@ -470,7 +470,7 @@ check_file_exists() {
is_found=true
fi
# Jika dalam mode dry-run dan file tidak ditemukan, kita skip pengecekan fisik.
# Jika dalam mode dry-run dan file tidak ditemukan, proses ini skip pengecekan fisik.
if [ "$DRY_RUN" = "true" ] && ! $is_found; then
check_status="${COLOR_YELLOW}Skipped${COLOR_RESET}"
fi
......@@ -948,7 +948,7 @@ main "$@"
* **Profil Kustom `motorcycle.lua`:**
* **Why:** OSRM tidak menyediakan profil motor secara default. Konfigurasi ini dibuat untuk meniru perilaku pengendara motor di Indonesia.
* **What it does:**
1. **`require('car')`**: Menggunakan profil mobil sebagai dasar, jadi kita tidak perlu mendefinisikan ulang semua kecepatan jalan dari awal.
1. **`require('car')`**: Menggunakan profil mobil sebagai dasar, jadi proses ini tidak perlu mendefinisikan ulang semua kecepatan jalan dari awal.
2. **`restrictions`**: Bagian terpenting. Ini secara eksplisit melarang motor memasuki jalan tol (`highway:motorway`), jalan khusus mobil (`motorcar:yes`), dan jalan berbayar (`toll`). Aturan ini didasarkan pada tag OpenStreetMap.
3. **`properties`**: Sedikit mengubah parameter seperti penalti putar balik (`u_turn_penalty`) dan kecepatan maksimum (`max_speed`).
......
docs/jupyterlab.md
......@@ -202,12 +202,3 @@ jupyterlab -d /home/user/projects -p 9999
* [Jupyter Lab Documentation](https://jupyterlab.readthedocs.io/en/stable/)
* [Miniconda Installation](https://docs.conda.io/en/latest/miniconda.html)
---
✅ **Dokumentasi ini self-contained**, mencakup semua langkah dari setup Conda/Mamba sampai wrapper script untuk Jupyter Lab.
---
Kalau mau, aku bisa buat **versi PDF siap cetak** atau **Markdown lengkap dengan snippet copy-paste**, supaya bisa langsung dibagikan ke tim.
Kamu mau aku buatkan versi PDF/Markdown itu juga?
docs/osrm-requirements.md
......@@ -383,6 +383,3 @@ flowchart TD
| Domain/API structure | ✅ Confirmed |
| Mermaid workflow | ✅ Included |
---
Apakah kamu ingin saya jadikan **dokumen `.md` (Markdown)** dari daftar di atas, agar bisa langsung digunakan sebagai **AI-prompt atau dokumentasi teknis proyek**?
docs/ssh-hardening-fail2ban.md
### Tahap 1: Pemahaman Konteks Fail2Ban dan Persiapan
Sebelum kita masuk ke instalasi dan konfigurasi, mari kita pahami apa itu Fail2Ban, mengapa ia penting, dan apa saja yang perlu dipersiapkan.
Sebelum proses ini masuk ke instalasi dan konfigurasi, mari proses ini pahami apa itu Fail2Ban, mengapa ia penting, dan apa saja yang perlu dipersiapkan.
#### Apa Itu Fail2Ban?
......@@ -9,7 +9,7 @@ Fail2Ban adalah sebuah framework pencegah intrusi berbasis log yang memindai fil
#### Mengapa Fail2Ban Penting untuk Hardening SSH?
Meskipun kita sudah melakukan banyak langkah hardening SSH (mengubah port, SSH Key, dll.), Fail2Ban menambahkan lapisan keamanan yang proaktif dan reaktif:
Meskipun proses ini sudah melakukan banyak langkah hardening SSH (mengubah port, SSH Key, dll.), Fail2Ban menambahkan lapisan keamanan yang proaktif dan reaktif:
1. **Pertahanan Reaktif Terhadap Brute-Force:** Ini adalah fungsi utamanya. Jika ada penyerang yang mencoba SSH key yang berbeda-beda, atau jika ada port scanner yang menemukan port SSH baru dan mencoba brute-force, Fail2Ban akan mendeteksi upaya login yang gagal dan secara otomatis memblokir IP tersebut.
2. **Mengurangi Beban Server:** Dengan memblokir penyerang sejak dini, mengurangi beban pada server karena upaya autentikasi yang berulang tidak akan sampai ke daemon SSH lagi.
......@@ -27,8 +27,8 @@ Meskipun kita sudah melakukan banyak langkah hardening SSH (mengubah port, SSH K
1. **Rocky Linux 10:** Sistem operasi target.
2. **Akses Root atau `sudo`:** Diperlukan untuk instalasi dan konfigurasi.
3. **`firewalld` Aktif dan Berjalan:** Fail2Ban akan berinteraksi dengan `firewalld` untuk menerapkan blokir IP. Pastikan `firewalld` sudah terinstal dan berjalan (seperti yang kita konfigurasikan di tahap hardening SSH sebelumnya).
4. **Port SSH Kustom:** Asumsi bahwa sudah mengubah port SSH default (misalnya ke 22222) seperti yang kita lakukan di tutorial sebelumnya. Fail2Ban akan dikonfigurasi untuk memantau port ini.
3. **`firewalld` Aktif dan Berjalan:** Fail2Ban akan berinteraksi dengan `firewalld` untuk menerapkan blokir IP. Pastikan `firewalld` sudah terinstal dan berjalan (seperti yang proses ini konfigurasikan di tahap hardening SSH sebelumnya).
4. **Port SSH Kustom:** Asumsi bahwa sudah mengubah port SSH default (misalnya ke 22222) seperti yang proses ini lakukan di tutorial sebelumnya. Fail2Ban akan dikonfigurasi untuk memantau port ini.
5. **SSH Server Berjalan:** Daemon OpenSSH (`sshd`) harus berjalan dan aktif agar Fail2Ban dapat memantau log-nya.
#### Arsitektur Fail2Ban (Dependency & Use Case)
......@@ -53,11 +53,11 @@ Seorang penyerang mencoba login SSH ke server pada port 22222 dengan pengguna `a
### Tahap 2: Instalasi Fail2Ban
Pada tahap ini, kita akan menginstal paket Fail2Ban dari repositori default Rocky Linux 10.
Pada tahap ini, proses ini akan menginstal paket Fail2Ban dari repositori default Rocky Linux 10.
#### Mengapa Perlu Menginstal Fail2Ban?
Fail2Ban bukanlah bagian dari instalasi minimal Rocky Linux secara default. Oleh karena itu, kita perlu menginstalnya secara manual agar fungsionalitas pencegahan intrusi berbasis log ini dapat berjalan di server kita.
Fail2Ban bukanlah bagian dari instalasi minimal Rocky Linux secara default. Oleh karena itu, proses ini perlu menginstalnya secara manual agar fungsionalitas pencegahan intrusi berbasis log ini dapat berjalan di server.
#### Cara Menginstal Fail2Ban
......@@ -160,7 +160,7 @@ Jika melihat output versi seperti di atas, artinya instalasi berhasil.
**3. Aktifkan dan Mulai Layanan Fail2Ban**
Setelah instalasi, kita perlu mengaktifkan layanan Fail2Ban agar secara otomatis berjalan saat sistem booting dan memulainya sekarang.
Setelah instalasi, proses ini perlu mengaktifkan layanan Fail2Ban agar secara otomatis berjalan saat sistem booting dan memulainya sekarang.
```bash
sudo systemctl enable fail2ban
......@@ -200,7 +200,7 @@ Cari `Active: active (running)`. Jika melihat ini, layanan Fail2Ban berjalan den
### Tahap 3: Konfigurasi Fail2Ban (Jail dan Filter)
Pada tahap ini, kita akan mengkonfigurasi Fail2Ban untuk memantau upaya login SSH yang gagal di port kustom. Fail2Ban menggunakan konsep "jail" untuk menentukan layanan mana yang akan dimonitor dan bagaimana cara menangani insiden.
Pada tahap ini, proses ini akan mengkonfigurasi Fail2Ban untuk memantau upaya login SSH yang gagal di port kustom. Fail2Ban menggunakan konsep "jail" untuk menentukan layanan mana yang akan dimonitor dan bagaimana cara menangani insiden.
#### Struktur Konfigurasi Fail2Ban
......@@ -211,17 +211,17 @@ Urutan prioritas konfigurasi adalah:
2. `/etc/fail2ban/jail.d/*.conf` (konfigurasi kustom, menimpa `jail.conf`)
3. `/etc/fail2ban/jail.local` (konfigurasi kustom, menimpa `jail.conf` dan `jail.d/` jika konflik)
Kita akan membuat file konfigurasi baru di `/etc/fail2ban/jail.d/` untuk jail SSH kita.
proses ini akan membuat file konfigurasi baru di `/etc/fail2ban/jail.d/` untuk jail SSH.
#### Mengapa Konfigurasi Khusus Diperlukan?
* **Port Kustom:** Konfigurasi default Fail2Ban untuk SSH memantau port 22. Karena kita telah mengubah port SSH (misalnya ke 22222), kita perlu memberi tahu Fail2Ban untuk memantau port yang benar.
* **Port Kustom:** Konfigurasi default Fail2Ban untuk SSH memantau port 22. Karena proses ini telah mengubah port SSH (misalnya ke 22222), proses ini perlu memberi tahu Fail2Ban untuk memantau port yang benar.
* **Best Practice:** Menggunakan file `.local` atau `.d/` memastikan konfigurasi kustom tetap utuh saat Fail2Ban di-upgrade.
* **Fleksibilitas:** Memungkinkan penyesuaian parameter banning (seperti durasi ban, jumlah percobaan gagal) sesuai kebutuhan keamanan spesifik.
#### Parameter Konfigurasi Kunci
Berikut adalah parameter utama yang akan kita konfigurasikan:
Berikut adalah parameter utama yang akan proses ini konfigurasikan:
* **`ignoreip`**: Daftar alamat IP atau subnet yang akan diabaikan oleh Fail2Ban. Masukkan IP sendiri di sini agar tidak terkunci secara tidak sengaja.
* **`bantime`**: Durasi (dalam detik) IP akan diblokir. Default: 10 menit (600 detik).
......@@ -236,7 +236,7 @@ Berikut adalah parameter utama yang akan kita konfigurasikan:
**1. Buat File Konfigurasi Jail Kustom untuk SSH**
Kita akan membuat file `/etc/fail2ban/jail.d/ssh_hardening.conf`.
proses ini akan membuat file `/etc/fail2ban/jail.d/ssh_hardening.conf`.
```bash
sudo vi /etc/fail2ban/jail.d/ssh_hardening.conf
......@@ -272,7 +272,7 @@ ignoreip = 127.0.0.1/8 ::1 your_ip_address_or_subnet # Ganti ini!
action = %(action_)s
```
**Penjelasan Parameter Kunci dalam Konteks Kita:**
**Penjelasan Parameter Kunci dalam Konteks:**
* **`[sshd]`**: Ini mendefinisikan sebuah "jail" bernama `sshd`. Fail2Ban akan memantau layanan ini.
* **`enabled = true`**: Mengaktifkan jail ini.
......@@ -369,11 +369,11 @@ Setelah `bantime` berakhir, IP secara otomatis akan di-unban, dan bisa mencoba l
### Tahap 4: Rangkuman Konfigurasi Fail2Ban dan Full Bash Script untuk Otomatisasi
Kita telah menginstal dan mengkonfigurasi Fail2Ban secara manual. Sekarang, mari kita rangkum konfigurasi dan kemudian membuat skrip bash untuk mengotomatisasi proses ini, yang dapat digunakan untuk penerapan yang konsisten dan cepat.
proses ini telah menginstal dan mengkonfigurasi Fail2Ban secara manual. Sekarang, mari proses ini rangkum konfigurasi dan kemudian membuat skrip bash untuk mengotomatisasi proses ini, yang dapat digunakan untuk penerapan yang konsisten dan cepat.
#### Rangkuman Konfigurasi Fail2Ban (Best Practice)
Berikut adalah ringkasan dari konfigurasi Fail2Ban untuk SSH yang kita telah buat di `/etc/fail2ban/jail.d/ssh_hardening.conf`:
Berikut adalah ringkasan dari konfigurasi Fail2Ban untuk SSH yang proses ini telah buat di `/etc/fail2ban/jail.d/ssh_hardening.conf`:
```ini
# ==============================================================================
......
scripts/ssh-hardening-core.sh
......@@ -46,7 +46,7 @@
SSH_CONFIG="/etc/ssh/sshd_config"
SSH_BAK_DIR="/etc/ssh/sshd_config.bak"
FIREWALLD_ZONE="public"
DEFAULT_SSH_PORT=22222 # Port SSH default yang akan kita gunakan
DEFAULT_SSH_PORT=22222 # Port SSH default yang akan proses ini gunakan
DRY_RUN=false
NEW_SSH_PORT=""
ALLOW_USERS_LIST=""
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment