Cara Monitoring Log Server Linux — Biar Tahu Kalau Ada yang Mencurigakan Sebelum Terlambat

Jam 2:34 pagi. Gue susah tidur, entah kenapa. Refleks buka laptop, SSH ke salah satu VPS klien, dan iseng-iseng ngetik tail -f /var/log/auth.log. Kebiasaan buruk — atau kebiasaan baik, tergantung lo liatnya. Yang gue liat bikin gue langsung melek total. Baris demi baris scroll dengan kecepatan yang gak normal:

Failed password for root from 103.xxx.xxx.xxx port 45122 ssh2
Failed password for root from 103.xxx.xxx.xxx port 45123 ssh2
Failed password for admin from 103.xxx.xxx.xxx port 45124 ssh2
Failed password for ubuntu from 185.xxx.xxx.xxx port 22222 ssh2
Failed password for test from 185.xxx.xxx.xxx port 22223 ssh2

Ratusan percobaan login. Dari puluhan IP berbeda. Dalam semenit aja, ada 30-an baris baru. Brute force attack yang lagi berlangsung. Beneran lagi berlangsung, saat itu juga. Dan gue kebetulan nemu karena susah tidur.

Kalo gue gak iseng-iseng buka auth.log malam itu, kemungkinan gede dalam beberapa jam salah satu percobaan itu berhasil. Karena password root di server itu… gue malu ngakuinnya, tapi itu password yang lumayan lemah buat standar server. (Jangan ditiru. Serius.)

Dari kejadian itu gue belajar: log itu bukan cuma “catatan.” Log adalah kamera pengawas lo. Log adalah saksi bisu yang ngeliat semua hal yang terjadi di server lo. Dan cara monitoring log server Linux yang bener bisa jadi pembeda antara “ketauan ada yang aneh → langsung gerak” dan “tau-tau server lo udah jadi botnet orang.”

Kenapa Log Server Tuh Penting Banget?

Lo mungkin mikir: “Ah, kan udah ada firewall. Udah ada fail2ban.” Bagus. Tapi setelah ada insiden — setelah server lo kena deface, setelah database lo ke-dump, setelah aplikasi lo crash misterius — lo tau apa yang terjadi dari mana? Satu-satunya sumber kebenaran adalah log. Tanpa log, lo cuma bisa nebak-nebak. Forensik digital tanpa log itu kayak detektif tanpa saksi.

Log bisa ngasih tau lo:

• Siapa yang login (atau nyoba login) ke server lo.
• Dari mana (IP address) koneksi masuk.
• Error apa yang terjadi di aplikasi lo.
• Request aneh yang mungkin SQL injection atau XSS.
• Perubahan konfigurasi sistem.
• Aktivitas user yang mencurigakan.

Tapi log juga ada masalahnya. Dia banyak banget. Server produksi bisa ngasilin ribuan baris log per menit. Kalo lo cuma ngandelin tail dan grep doang, lo bakal tenggelem. Makanya lo butuh strategi: ngerti file log mana yang penting, pake tools yang tepat buat baca dan analisa, dan — yang paling krusial — setup alerting supaya lo gak perlu mantengin log 24/7.

File-File Log Penting yang Wajib Lo Kenal

Sebelum ngomongin tools, lo harus tau di mana aja log itu disimpen. Di Linux (terutama Debian/Ubuntu yang paling umum dipake di Indonesia), sebagian besar log ada di /var/log/. Ini file-file kunci yang selalu gue cek:

/var/log/auth.log

Ini log suci. Semua yang berhubungan dengan autentikasi dicatat di sini: login SSH (berhasil atau gagal), sudo attempts, user creation/deletion, password changes. Kalo lo cuma bisa mantau satu file log, pilih ini. Setiap kali gue SSH ke server, selalu tail -50 /var/log/auth.log dulu — semacem salam pembuka.

Contoh baris yang normal:

Accepted publickey for banditz from 192.168.1.10 port 33445 ssh2

Yang mencurigakan:

Failed password for invalid user admin from 185.220.xxx.xxx port 45678 ssh2

Kalo lo liat puluhan “Failed password” dari IP yang sama, atau dari user yang gak lo kenal — itu red flag.

/var/log/syslog

Log serba-guna sistem. Isinya campur aduk: kernel messages, service startup/shutdown, cron jobs, hardware events. Lebih “noisy” dari auth.log, tapi kadang informasi penting muncul di sini — kayak OOM killer yang nge-kill proses karena memory habis.

/var/log/nginx/access.log dan error.log (atau apache2/)

Kalo lo pake web server, ini harus dimonitor. Access log nyatet semua request yang masuk — dari siapa, akses halaman apa, pake method apa, response code berapa. Error log nyatet error internal.

Di access log, perhatiin:

• Request ke URL aneh (/wp-admin, /adminer.php, /.env, /config.php.bak) → mungkin scanner yang nyari celah.
• Request dengan SQL injection pattern (UNION SELECT, OR 1=1).
• Request dari IP yang sama dengan frekuensi abnormal.

Contoh sederhana:

GET /wp-login.php HTTP/1.1 200 5821 "-" "Mozilla/5.0"
GET /.env HTTP/1.1 404 152 "https://example.com/.env" "python-requests/2.28.0"

Yang pertama: request normal ke login page WordPress. Yang kedua: scanner pake Python nyari file .env — ini hampir pasti malicious.

/var/log/mysql/error.log

Kalo pake MySQL/MariaDB, error log penting buat debug. Query lambat, koneksi ditolak, crash, corrupted table — semuanya di sini.

/var/log/ufw.log atau /var/log/iptables/

Kalo lo pake firewall kayak UFW atau iptables, log-nya nyatet semua koneksi yang diblokir. Ini sumber informasi bagus buat liat dari mana aja serangan masuk.

Tools Dasar: Yang Bisa Lo Pake Sekarang Juga

Gak perlu install apa-apa. Tools ini udah ada di semua distro Linux. Gue masih sering pake kombinasi ini buat quick check:

tail — Lihat Baru-Baru Ini

tail -50 /var/log/auth.log     # 50 baris terakhir
tail -f /var/log/auth.log      # real-time, scroll terus kalo ada event baru

tail -f itu berguna banget buat debug real-time. Lo SSH ke server, jalanin tail -f auth.log, terus lo coba login dari client lain — lo bakal liat langsung event-nya muncul.

grep — Cari Spesifik

grep "Failed password" /var/log/auth.log
grep "185.220" /var/log/auth.log          # cari IP spesifik
grep -c "Failed password" /var/log/auth.log  # hitung berapa kali

less — Baca File Gede Tanpa Load Semuanya

less /var/log/syslog

Di dalam less, lo bisa scroll (pgup/pgdn), search (/keyword), dan loncat ke akhir (G) atau awal (g). Lebih enak daripada cat buat file gede.

Kombinasi Tail + Grep — Filter Real-Time

tail -f /var/log/auth.log | grep "Failed password"

Ini nampilin real-time, tapi cuma baris yang mengandung “Failed password”.

awk, sed, sort, uniq — Advance Filtering

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -10

Command ini ngeluarin top 10 IP yang paling sering gagal login. Detail cara kerjanya:

• grep filter baris dengan “Failed password”
• awk '{print $(NF-3)}' ambil IP (biasanya IP ada di posisi 3 dari belakang — tapi ini tergantung format log, bisa beda-beda)
• sort | uniq -c hitung berapa kali tiap IP muncul
• sort -nr | head -10 urutin dari yang paling banyak, ambil 10 teratas

Command kayak gini yang dulu gue pake pas nemu brute force attack jam 2 pagi itu. Dalam satu command, gue tau IP mana yang paling agresif.

Tools Intermediate — Naik Level Dikit

Kalo lo udah mulai kewalahan pake tail dan grep doang (karena log makin banyak, server makin banyak), saatnya pake tools yang lebih khusus.

journalctl — Buat yang Pake Systemd

Kalo distro lo pake systemd (Ubuntu 16.04 ke atas, Debian 8 ke atas, CentOS 7 ke atas), lo punya journald — logging system bawaan. Aksesnya lewat journalctl.

journalctl -u nginx                    # lihat log service nginx
journalctl -u ssh --since "1 hour ago"  # log SSH sejam terakhir
journalctl -f                          # real-time semua log
journalctl -p err                      # cuma error ke atas
journalctl _UID=33                     # log dari user id 33 (biasanya www-data)

Journalctl enak buat debug spesifik. Tapi kalo lo ngurusin banyak server, journalctl-nya cuma local — gak bisa aggregasi.

lnav — The Log File Navigator

Ini tool yang underrated banget. lnav (Log Navigator) basically “less on steroid.” Dia bisa:

• Baca beberapa file log sekaligus dalam satu view
• Auto-detect timestamp dan merge log berdasaran waktu
• Highlight syntax otomatis (error merah, warning kuning, info putih)
• Filter, search, query log dengan SQL-like syntax
• Parse format log populer otomatis (syslog, nginx, apache, dll)

Install: sudo apt install lnav (Debian/Ubuntu) atau download dari lnav.org.

Usage basic:

lnav /var/log/syslog /var/log/auth.log

Semua log di-merge berdasarkan timestamp, jadi lo bisa liat kronologi event antar service.

multitail — Pantau Beberapa File Sekaligus

Kadang lo pengen liat beberapa file log bersamaan dalam terminal yang sama (split view). Multitail bisa:

multitail /var/log/auth.log /var/log/nginx/access.log

Atau pake tmux / screen dengan split pane — ini workflow yang gue pake sehari-hari: pane kiri tail -f auth.log, pane kanan tail -f access.log.

Tools Advanced — Buat Skala Besar dan Analisis Serius

Kalo lo udah ngurusin 10+ server, atau lo butuh historical data dan visualisasi, saatnya pake stack yang lebih serius.

ELK Stack (Elasticsearch + Logstash + Kibana)

ELK adalah standar de facto buat log management. Cara kerjanya:

• Filebeat (agent) jalan di tiap server, baca file log, kirim ke Logstash atau langsung ke Elasticsearch.
• Logstash (processor) terima log, parsing, filter, enrich, terus forward ke Elasticsearch.
• Elasticsearch (storage) nyimpen log dan bikin bisa di-search dengan cepet.
• Kibana (visualization) bikin dashboard dan query interface yang cantik.

Kelebihan:

• Search engine powerful. Lo bisa cari “semua error Nginx dari IP Indonesia dalam 24 jam terakhir” dalam hitungan detik.
• Dashboard Kibana keren banget. Grafik, peta geolokasi IP, timeline, pie chart.
• Skalabel. Bisa handle jutaan event per detik kalo dikonfigurasi dengan bener.

Kekurangan:

• Resource hungry. Elasticsearch butuh RAM gede. Jangan coba install di VPS 1GB.
• Setup rumit. Butuh beberapa komponen, konfigurasi yang gak sedikit.
• Maintenance overhead. Elasticsearch perlu di-maintain, di-upgrade, di-monitor.

Pengalaman Gue:

Gue pake ELK waktu ngurusin infrastruktur yang lumayan gede (20+ server). Setup awal butuh 2-3 hari (belajar + trial and error). Tapi setelah jadi — luar biasa. Dashboard Kibana gue nampilin real-time attack map, top attacker IP, error rate per service, request latency, dan banyak lagi. Klien gue yang teknis juga dikasih akses ke dashboard read-only biar mereka bisa mantau sendiri.

Grafana Loki — Alternatif Ringan untuk ELK

Loki adalah project dari Grafana Labs yang didesain sebagai alternatif ringan Elasticsearch buat log. Filosofinya: Loki cuma index metadata (label), bukan full text log. Jadi lebih hemat resource.

Kelebihan:

• Ringan banget dibanding Elasticsearch.
• Integrasi native dengan Grafana. Jadi lo bisa punya dashboard yang nampilin metrics (Prometheus) dan log (Loki) dalam satu tempat.
• Bisa jalan di Kubernetes atau standalone.
• Query pake LogQL — mirip PromQL buat metrics.

Kekurangan:

• Fitur search gak se-powerful Elasticsearch (karena gak index full text).
• Ekosistem belum sematang ELK.

Pengalaman Gue:

Buat project skala menengah, gue lebih prefer Loki sekarang. Ringan, integrasi Grafana seamless, dan cukup powerful buat kebanyakan use case. Setup pake Docker Compose, tambahin Promtail sebagai agent, dan beberapa jam udah bisa jalan.

Graylog — Middle Ground

Graylog posisinya di antara ELK (berat) dan Loki (ringan). UI-nya bagus, fitur lumayan lengkap, dan setup-nya lebih gampang dari ELK. Graylog pake Elasticsearch atau OpenSearch sebagai backend storage.

Logwatch — Laporan Harian yang Underrated

Gak semua orang butuh ELK stack yang kompleks. Kadang yang lo butuhin cuma: “Kirimin gue email tiap pagi yang rangkum apa yang terjadi di server semalem.”

Logwatch ngelakuin persis itu. Dia analisa semua log utama, bikin rangkuman, dan kirim via email.

Install:

sudo apt install logwatch

Konfigurasi dasar:

• Edit /etc/cron.daily/00logwatch (atau /etc/logwatch/conf/logwatch.conf)
• Atur email penerima
• Atur detail level (Low, Medium, High)

Output-nya kurang lebih kayak gini:

--------------------- SSHD Begin ------------------------
Failed logins from:
   root (103.145.xx.xx): 47 times
   admin (185.220.xx.xx): 23 times
   ubuntu (45.33.xx.xx): 12 times

Users logging in:
   banditz (192.168.1.10): 3 times

---------------------- SSHD End -------------------------

Ini simple tapi efektif. Lo gak perlu mantengin server tiap jam. Cukup baca email pagi-pagi sambil ngopi. Kalo ada yang aneh, lo investigasi lebih lanjut. Kalo biasa aja, tinggal archive.

Fail2Ban — Dari Monitoring ke Aksi Otomatis

Monitoring log itu bagus. Tapi lebih bagus lagi kalo lo bisa otomatis bereaksi terhadap log yang mencurigakan. Inilah gunanya fail2ban.

Fail2ban terus-terusan mantau file log yang lo tentukan. Begitu dia deteksi pola yang mencurigakan (berdasar regex yang lo atur), dia otomatis ngeblok IP sumber pake iptables/firewalld. Jadi lo gak perlu manual ban IP setelah liat brute force.

Setup dasar fail2ban pake default config sebenarnya udah cukup buat kebanyakan kasus:

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Default-nya, fail2ban bakal mantau SSH (sshd jail) dan beberapa service umum. Kalo ada IP yang gagal login 5 kali dalam 10 menit, IP itu di-ban selama 10 menit (bisa lo atur).

Lo bisa tambahin jail custom buat aplikasi lo sendiri. Contoh, jail buat WordPress:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/nginx/access.log
maxretry = 5
bantime  = 3600

Kalo lo punya aplikasi custom yang gak ada filter bawaan, lo bisa bikin filter sendiri. Ini contoh filter buat ngedeteksi SQL injection attempt di access log Nginx:

[Definition]
failregex = ^<HOST> -.*"(GET|POST).*(union select|select.*from|insert.*into).*
ignoreregex =

Setup fail2ban itu salah satu hal pertama yang gue lakuin setiap deploy server baru. Karena gue tau: bot scanner gak akan berhenti nyerang. Mereka jalan 24/7, dari beratus-ratus IP berbeda. Manual ban mah gak akan cukup. Jadi biarin aja fail2ban yang kerja.

Logrotate — Jangan Sampe Disk Full Gara-Gara Log

Mantau log itu penting. Tapi kalo lo gak nge-manage ukurannya, log bisa numpuk dan bikin disk full. Ini kejadian nyata: server klien gue tiba-tiba nggak bisa nerima email, database error, file upload gagal. Setelah gue cek — disk usage 100%. Ternyata file nginx/access.log udah 47GB. Gila. Cuma log doang segede itu.

Logrotate adalah tool bawaan Linux yang ngatur rotasi log otomatis. Konfigurasinya di /etc/logrotate.conf dan /etc/logrotate.d/. Contoh konfigurasi buat Nginx:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

Artinya: rotasi tiap hari, simpen 30 hari ke belakang, file lama di-compress, simpen dalam format gzip. Jadi maksimal log yang disimpen sekitar 30 file per jenis, bukan 47GB.

Cek logrotate lo udah jalan apa belum:

sudo logrotate -d /etc/logrotate.conf    # dry-run
sudo logrotate -f /etc/logrotate.conf    # force run

Gimana Cara Gue Pribadi Monitoring Log Sekarang

Biar konkret, gue kasi tau setup monitoring log gue saat ini (buat 8 server yang gue kelola):

1. Setiap server: fail2ban jalan dengan konfigurasi default + beberapa jail custom untuk aplikasi spesifik.
2. Setiap server: logrotate dikonfigurasi untuk semua service (gak cuma default).
3. Logwatch: terinstall di semua server, kirim daily report ke email gue tiap jam 7 pagi. Gue baca sambil sarapan. Kalo ada yang mencurigakan (misalnya tiba-tiba ada 200 failed login), gue langsung SSH buat investigasi.
4. Loki + Grafana: buat 3 server production yang traffic-nya lumayan. Dashboard nampilin error rate, top attacker IP, response time anomaly. Alert kalo error rate di atas threshold tertentu.
5. Manual check: seminggu sekali gue SSH ke tiap server dan jalanin tail -100 /var/log/auth.log terus grep manual — lebih karena kebiasaan dan ketenangan batin aja sih. Kadang nemu hal-hal yang kelewat sama logwatch.

Apakah ini overkill? Untuk 8 server — mungkin iya. Tapi setelah pengalaman nyaris kena brute force jam 2 pagi itu, gue lebih pilih overkill daripada under-prepared.

Cara monitoring log server Linux bukan skill yang susah dipelajari. Lo bisa mulai sekarang. Buka terminal, SSH ke server lo, jalanin tail -50 /var/log/auth.log. Ngerti isinya. Perhatiin polanya. Siapa tau lo juga nemu sesuatu yang bikin lo melek kayak gue dulu. Dari situ, pelan-pelan tambahin fail2ban, logwatch, dan kalo udah pede, coba Loki atau ELK. Log lo itu harta karun — isinya petunjuk tentang apa yang sebenernya terjadi di server lo. Tinggal lo mau gali apa enggak.