Cara Analisis Log Server Linux — Panduan Praktis untuk Pemula di Forensik

Tahun 2018, saya dipanggil ke sebuah perusahaan e-commerce yang lumayan besar di Jakarta. Masalahnya simpel tapi ngeri: database customer mereka — lengkap dengan nama, email, nomor telepon, sama alamat — tiba-tiba muncul dijual di dark web. Pimpinan perusahaan panik. Mereka nggak tahu data itu bocor dari mana, kapan, dan siapa yang nyuri. Tim IT internal udah seminggu nyari tapi nggak nemu apa-apa. Ketika saya tanya “log server-nya udah dicek?”, jawaban mereka bikin saya terdiam: “Log-nya ada sih… tapi kami nggak tahu cara bacanya.” Dan di situlah saya sadar bahwa cara analisis log server adalah skill yang sering diabaikan tapi sebenarnya sangat krusial di dunia forensik digital.

Akhirnya saya menghabiskan tiga hari penuh menganalisis log server mereka. Dan tebak apa yang saya temukan? Attacker udah ada di dalam sistem selama hampir empat bulan. Empat. Bulan. Dan semua jejaknya terekam dengan jelas di log — cuma nggak ada yang baca. Nah, di artikel ini saya pengen sharing cara analisis log server Linux dari kacamata investigator forensik. Bukan cuma teori, tapi teknik-teknik praktis yang saya pakai di lapangan. Kamu nggak perlu jadi sysadmin senior untuk bisa ngikutin — yang penting udah familiar sama terminal Linux.

Kenapa Log Server Itu Penting Banget di Forensik

Sebelum kita mulai teknisnya, saya pengen kamu ngerti dulu kenapa log itu saksi bisu yang paling berharga dalam setiap investigasi forensik. Coba bayangin: setiap kali ada yang login ke server, setiap command yang dijalankan, setiap file yang diakses, setiap koneksi jaringan yang dibuat — semuanya tercatat di log. Attacker secanggih apa pun hampir nggak mungkin beroperasi di sistem tanpa ninggalin jejak di log.

Tapi masalahnya: log juga bisa dihapus, dimodifikasi, atau (yang paling sering terjadi) diabaikan begitu aja karena volumenya terlalu besar. Di perusahaan e-commerce tadi, server mereka menghasilkan sekitar 2 GB log per hari. Dua gigabyte teks. Siapa yang sanggup baca manual? Nah makanya kamu perlu tahu cara analisis log server yang efisien — tools apa yang dipakai, pattern apa yang dicari, dan gimana cara memfilter noise supaya sinyal-nya keliatan.

File Log Penting di Linux yang Wajib Kamu Kenal

Linux nyimpen log di direktori /var/log/. Tapi nggak semua file di situ relevan buat investigasi forensik. Ini beberapa file log kunci yang hampir selalu saya periksa pertama kali:

Ini adalah file paling penting dalam investigasi forensik di Linux. Di sini tercatat semua aktivitas autentikasi: login yang berhasil, login yang gagal, penggunaan sudo, perubahan password, SSH connections, su command, dan banyak lagi. Kalau ada yang berhasil login secara nggak sah, jejaknya hampir pasti ada di auth.log.

Contoh entry yang perlu kamu perhatikan:

Accepted password for root from 103.45.xxx.xxx port 22334 ssh2 — ada yang berhasil login sebagai root dari IP asing. Alarm langsung nyala.
Failed password for root from 185.xxx port 44512 ssh2 — percobaan brute force SSH. Satu atau dua kali mungkin normal. Ratusan kali dalam semenit? Serangan.
session opened for user www-data by (uid=0) — sebuah session dibuka untuk user www-data, dipicu oleh UID 0 (root). Ini red flag kalau user www-data seharusnya nggak pernah login interaktif.

/var/log/syslog — Buku Harian Sistem

Syslog adalah log general-purpose. Isinya macem-macem: kernel messages, service startups dan shutdowns, cron job executions, daemon logs, dan error messages dari berbagai service. Di forensik, syslog berguna buat membangun timeline kejadian secara kronologis — kapan service dimulai, kapan cron job dijalankan, kapan ada error yang nggak biasa.

/var/log/nginx/access.log (atau Apache) — Siapa yang Ngunjungi Web Server Kamu

Kalau target serangan adalah web application, log web server adalah tambang emas. Di sini kamu bisa lihat: IP address pengunjung, URL yang diakses, HTTP method (GET, POST, PUT), response code (200, 403, 404, 500), user agent, dan timestamp. Pattern yang mencurigakan: request ke path yang nggak wajar (kayak /wp-admin padahal bukan WordPress), POST request yang nggak normal, spike traffic dari satu IP, atau user agent yang aneh.

Kedua file ini nyimpen binary log tentang login attempts. wtmp nyimpen record login yang berhasil, btmp nyimpen record login yang gagal. File ini formatnya binary, jadi nggak bisa dibaca pake cat atau grep biasa — kamu perlu perintah last (untuk wtmp) dan lastb (untuk btmp). Kenapa penting? Karena attacker hampir selalu lupa (atau nggak tahu) untuk membersihkan file-file ini.

/var/log/cron — Jadwal Kejahatan

Log ini nyimpen record semua cron job yang dieksekusi. Attacker sering banget make cron buat persistence — misalnya nge-set cron job yang download dan eksekusi malware setiap jam. Di log ini kamu bisa lihat command apa yang dijalankan lewat cron, kapan, dan oleh user mana.

Tools Analisis Log — Senjata di Terminal Kamu

Oke, sekarang kita bahas tools. Di Linux, kamu nggak perlu install software mahal buat analisis log. Tools bawaannya udah luar biasa powerful kalau kamu tahu cara makenya. Ini arsenal saya:

grep — Teman Sejati Sejak Hari Pertama

grep adalah tools paling fundamental dan paling sering saya pakai. Fungsinya simpel: nyari pattern tertentu di file teks. Tapi kombinasikan dengan regex dan opsi yang tepat, grep bisa jadi senjata investigasi yang mematikan. Contoh penggunaan:

# Cari semua login yang berhasil dari IP tertentu
grep "Accepted" /var/log/auth.log | grep "192.168.1"

# Cari semua aktivitas sudo oleh user tertentu
grep "sudo" /var/log/auth.log | grep "USER=banditz"

# Cari attempt SSH brute force (gagal login > 5 kali dari IP sama)
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr

# Cari request ke path sensitif di access log
grep -E "/(admin|wp-admin|phpmyadmin|\.env|config)" /var/log/nginx/access.log

awk — Filtering dan Transformasi Data

Kalau grep buat nyari, awk buat memproses. awk sangat powerfull buat ngekstrak kolom spesifik dari log, melakukan kalkulasi, dan memformat output. Saya sering pakai awk buat ngekstrak IP address dari auth.log, menghitung frekuensi, dan bikin laporan statistik.

# Ekstrak IP address yang gagal login dan hitung frekuensinya
awk '/Failed password/ {print $11}' /var/log/auth.log | sort | uniq -c | sort -nr | head -20

# Ekstrak timestamp, IP, dan username dari percobaan login
grep "Failed password" /var/log/auth.log | awk '{print $1, $2, $3, $9, $11}'

# Hitung berapa kali masing-masing user melakukan sudo
awk '/sudo/ && /COMMAND/ {print $6}' /var/log/auth.log | sort | uniq -c | sort -nr

sed — Cari dan Ganti dengan Cepat

sed berguna buat membersihkan data log sebelum dianalisis. Misalnya: menghapus baris yang nggak relevan, memformat ulang field, atau mengekstrak bagian spesifik dari entry log.

# Hapus semua baris komentar dan baris kosong
sed '/^#/d; /^$/d' /var/log/syslog

# Ambil hanya baris yang terjadi pada jam tertentu
sed -n '/^May 15 1[4-5]:/p' /var/log/auth.log

journalctl — Buat Sistem yang Pakai systemd

Kalau server kamu pakai systemd (yang mana hampir semua distro modern sekarang pakai), log nggak lagi disimpen di file teks tradisional, tapi di journal binary. Buat ngaksesnya, kamu perlu journalctl. Enaknya, journalctl punya fitur filtering yang sangat powerful:

# Lihat semua log SSH
journalctl -u ssh

# Lihat log dalam rentang waktu tertentu
journalctl --since "2022-04-25 00:00:00" --until "2022-04-25 23:59:59"

# Lihat log berdasarkan user ID
journalctl _UID=1000

# Follow log secara real-time (live investigation)
journalctl -f

Apa yang Harus Kamu Cari di Log — Pattern Serangan Umum

Setelah tahu tools-nya, sekarang pertanyaan yang lebih penting: apa yang harus dicari? Berdasarkan pengalaman saya, ini pattern-pattern yang hampir selalu jadi indikasi serangan:

Brute Force SSH — Attack Paling Umum yang Masih Efektif

Pattern: puluhan atau ratusan percobaan login gagal dalam waktu singkat dari IP yang sama. Deteksinya:

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

Kalau satu IP muncul >20 kali, itu hampir pasti brute force attack. Tapi hati-hati: ada juga yang namanya slow brute force — cuma 1-2 percobaan per jam biar nggak terdeteksi. Makanya penting juga untuk lihat pola dari waktu ke waktu, bukan cuma snapshot.

Perintah yang Nggak Biasa — Tanda Tangan Attacker

Begitu attacker berhasil login, mereka biasanya langsung menjalankan perintah-perintah tertentu: reconnaissance (whoami, id, uname -a, ifconfig), privilege escalation (wget script exploit, chmod +x, ./exploit), persistence (crontab -e, systemctl enable, menambah SSH key di authorized_keys), dan data exfiltration (curl/wget ke server eksternal dengan data, tar + scp).

Cek command history user yang mencurigakan:

cat /home/<user>/.bash_history
journalctl _UID=<uid_user>

Tapi ingat: attacker yang jago biasanya membersihkan command history. Jadi kalau .bash_history user tertentu kosong atau cuma isinya exit, itu justru mencurigakan.

File yang Dimodifikasi — Jejak Digital yang Nggak Bisa Bohong

Attacker sering ninggalin file — entah itu malware, backdoor, script exploit, web shell, atau hasil eksfiltrasi yang belum sempat dikirim. Cari file yang baru dibuat atau dimodifikasi di direktori yang nggak biasa:

# File yang dimodifikasi dalam 24 jam terakhir
find / -type f -mtime -1 2>/dev/null | grep -v "^/proc\|^/sys\|^/run"

# File dengan permission mencurigakan (world-writable)
find / -type f -perm -o+w 2>/dev/null

# File tersembunyi (dimulai dengan titik) di direktori web
find /var/www -name ".*" -type f 2>/dev/null

# File yang di-upload ke /tmp (lokasi favorit attacker)
ls -la /tmp --time=ctime | head -20

Cron Jobs Mencurigakan — Persistence Favorit Attacker

Attacker suka banget make cron buat persistence. Periksa semua cron jobs yang ada:

# Cek crontab semua user
for user in $(cut -f1 -d: /etc/passwd); do sudo crontab -u $user -l 2>/dev/null; done

# Cek system-wide cron
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.hourly/
ls -la /etc/cron.daily/

# Cek log cron untuk melihat cron jobs yang dieksekusi
grep -i "CMD" /var/log/cron

Red flag: cron job yang eksekusi script dari /tmp, cron job yang download sesuatu dari internet, atau cron job yang jalan sebagai root tapi script-nya writable oleh user lain.

Koneksi Jaringan — Komunikasi dengan Dunia Luar

Attacker perlu berkomunikasi dengan server mereka — entah buat ngirim data curian, nerima perintah, atau download tools tambahan. Cek koneksi yang mencurigakan:

# Lihat established connections
ss -tlnp
netstat -anp | grep ESTABLISHED

# Cari koneksi ke port yang nggak biasa (bukan 80, 443, 22)
ss -tan | grep -vE ':(80|443|22|53) '

Tapi ini cuma bisa dilakukan di sistem yang masih nyala. Kalau sistem udah mati atau log adalah satu-satunya sumber, cek firewall logs:

grep "DROP\|REJECT" /var/log/ufw.log  # kalau pakai UFW
grep "DENY" /var/log/iptables.log      # kalau pakai iptables logging

Contoh Kasus Nyata — Deteksi Web Shell dari Log

Biar makin jelas, saya kasih satu contoh kasus nyata ya. Ini terjadi sekitar 2019. Sebuah perusahaan media punya WordPress yang di-host di VPS Linux. Mereka sadar ada yang aneh setelah halaman utama mereka redirect ke website judi online. Tim internal udah coba bersihin — hapus file mencurigakan, ganti password. Tapi besoknya kena lagi. Mereka manggil saya.

Setelah saya cek, langkah pertama adalah analisis access log Apache. Saya cari pattern upload:

grep -E "POST.*/(wp-admin|wp-content|wp-includes)" /var/log/apache2/access.log | grep -v "200\|302"

Dan nemu sesuatu yang aneh: ada POST request ke file wp-content/plugins/akismet/akismet.php dengan response code 200. Padahal akismet.php seharusnya nggak menerima POST request langsung. Ini jelas web shell. Attacker memanfaatkan plugin yang legitimate sebagai tempat nyimpen web shell biar nggak mencurigakan.

Dari situ saya trace IP attacker dari access log:

grep "91.xxx.xxx.xxx" /var/log/apache2/access.log

Terus cross-reference dengan auth.log untuk lihat apakah IP ini juga dipakai buat SSH:

grep "91.xxx.xxx.xxx" /var/log/auth.log

Dan bener — ada beberapa percobaan login SSH dari IP yang sama. Artinya attacker nggak cuma masuk lewat web shell, tapi juga berusaha dapetin akses SSH.

Dari log juga saya bisa lihat file-file lain yang diupload attacker:

grep "91.xxx.xxx.xxx" /var/log/apache2/access.log | grep -E "PUT|POST" | awk '{print $7}' | sort | uniq

Hasilnya nemu beberapa web shell tambahan yang disembunyiin di folder themes dan uploads. Semua ini ketahuan cuma dari analisis log — tanpa nyentuh server sama sekali. Setelah semua web shell dibersihin, vulnerability di-plugin ditambal, dan password di-reset, baru deh serangannya beneran berhenti.

Log Centralization — Karena Log di Server yang Kena Hack Itu Nggak Bisa Dipercaya

Ini pelajaran penting yang sering banget saya tekankan ke klien: log yang disimpen di server yang sama dengan yang kena serangan itu pada dasarnya nggak bisa dipercaya. Kenapa? Karena begitu attacker dapet akses root, mereka bisa menghapus, memodifikasi, atau memalsukan log sesuka hati. Bahkan ada teknik yang namanya “log tampering” — di mana attacker menginjeksi entry palsu ke log untuk menyesatkan investigator atau menutupi jejak mereka.

Solusinya: log centralization. Kirim semua log secara real-time ke server terpisah yang dedicated buat logging. Tools yang bisa dipakai:

rsyslog dengan remote forwarding — built-in di Linux, tinggal konfigurasi.
Fluentd atau Logstash — lebih fleksibel, bisa parsing dan transform log sebelum dikirim.
Graylog, ELK Stack (Elasticsearch + Logstash + Kibana), atau Splunk — untuk indexing dan visualisasi log. Bikin analisis jadi jauh lebih cepat dan powerful.

Dengan log centralization, meskipun attacker berhasil menghapus semua log di server yang kena, copy log tetap aman di server logging. Ini adalah kontrol keamanan yang simpel tapi dampaknya luar biasa besar.

Log Integrity dan Timestamp — Yang Sering Terlupakan

Satu hal lagi yang sering kelewat: integrity dan timestamp log. Di forensik, keakuratan timestamp adalah segalanya. Kalau jam server nggak akurat (beda beberapa menit atau jam dari waktu sebenarnya), timeline kejadian kamu bakal kacau. Dan di pengadilan, ketidakakuratan timestamp bisa dipakai buat mendiskreditkan bukti kamu.

Pastikan:

Server pakai NTP (Network Time Protocol) yang dikonfigurasi dengan benar
Zona waktu (timezone) semua server konsisten — kalau nggak, korelasi log antar server bisa sangat membingungkan
Log disimpan dalam UTC kalau memungkinkan — ini menghindari kebingungan zona waktu dan daylight saving

Dan soal integrity: simpan hash dari file log (SHA-256) secara berkala. Ini berguna untuk membuktikan bahwa log belum dimodifikasi sejak waktu tertentu. Kalau kamu pakai log centralization dengan ELK atau Graylog, fitur ini biasanya udah built-in.

Penutup — Log Adalah Saksi yang Tidak Pernah Tidur

Cara analisis log server yang efektif bukan cuma soal tools — tapi soal mindset. Kamu harus selalu bertanya: kalau saya jadi attacker, apa yang bakal saya lakukan? Command apa yang bakal saya jalankan? File apa yang bakal saya sentuh? Log apa yang bakal saya hapus? Dengan cara berpikir kayak gini, kamu akan lebih mudah ngenalin pattern yang mencurigakan di antara ribuan baris log yang kelihatannya biasa-biasa aja.

Dan satu saran terakhir: latihan, latihan, latihan. Bikin lab virtual sendiri. Install Linux server, jalanin beberapa service, terus coba “serang” server kamu sendiri — brute force SSH, upload web shell, bikin cron job aneh. Terus coba deteksi serangan itu dari log. Semakin sering kamu latihan, semakin terlatih mata kamu buat ngenalin pattern serangan di log.

Karena pada akhirnya, di dunia forensik digital, log adalah saksi yang tidak pernah tidur. Dia selalu mencatat. Tugas kamu cuma satu: belajar cara membacanya.

Table of Contents

Related Articles