Pembahasan mengenai log sistem dan log aplikasi pada Fedora-Server 21 sudah ditulis pada artikel sebelumnya (silakan baca di sini). Selanjutnya, artikel ini akan membahas mengenai audit log pengguna, rotasi log, dan remote logging pada Fedora-Server 21.

III. Log Pengguna

a) Yang gagal login

• Berkas log pengguna yang gagal login adalah /var/log/btmp.
• Log btmp berupa berkas binary, untuk dapat membacanya gunakan perintah berikut.

utmpdump /var/log/btmp

b) Yang sedang login

• Berkas log pengguna yang sedang login adalah /var/run/utmp.
• Log utmp berupa berkas binary, untuk dapat membacanya gunakan perintah ‘who‘ atau untuk log yang lebih rinci gunakan perintah berikut.

utmpdump /var/run/utmp

c) Yang pernah login

• Berkas log pengguna yang pernah login adalah /var/log/wtmp.
• Log wtmp berupa berkas binary, untuk dapat membacanya gunakan perintah ‘last‘ atau untuk log yang lebih rinci gunakan perintah berikut.

utmpdump /var/log/wtmp

IV. Rotasi Log

Dari artikel sebelumnya, diketahui bahwa pada umumnya berkas-berkas log tersimpan dalam direktori “/var/log/”. Untuk beberapa aplikasi seperti “httpd” dan “mariadb” mempunyai direktori sendiri dalam  “/var/log/” sebagai tempat penyimpanan berkas-berkas catatannya.

Semakin bertambah banyaknya berkas log yang disimpan, semakin besar pula ukuran direktori “/var/log” hingga suatu saat mungkin akan menghabiskan ruang hardisk yang dapat berakibat tidak berjalannya sistem atau layanan pada Fedora-Server. Untuk mencegah hal tersebut terjadi, Fedora-Server telah dilengkapi dengan mekanisme merotasi berkas-berkas log menggunakan layanan “logrotate“.

Cara kerja rotasi log dengan “logrotate” adalah sebagai berikut.

1. Berkas log lama dipindahkan atau diganti dengan nama lain (misalnya: dari file.log menjadi file.log.1).
2. Selanjutnya buat berkas log yang baru. Proses ini dilakukan pada periode waktu tertentu yang kemudian diulangi kembali pada periode berikutnya (misalnya: file.log.1 –> file.log.2, file.log –> file.log.1, create new file.log) dan seterusnya sampai batas jumlah rotasi yang ditetapkan.

Secara bawaan, “logrotate” dikonfigurasi untuk merotasi berkas log setiap satu minggu dan tetap menyimpan berkas-berkas log sampai empat minggu sebelum-sebelumnya. Ilustrasi mengenai cara kerja logrotate dapat dilihat pada gambar 1.

Untuk melihat/ mengubah konfigurasi layanan “logrotate“, gunakan perintah:

# Konfigurasi berkas log secara umum
vi /etc/logrotate.conf

# Konfigurasi berkas log aplikasi tertentu seperti httpd, mariadb
vi /etc/logrotate.d/namaaplikasi

Berikut ini adalah berkas konfigurasi “logrotate.conf” secara bawaan.

Berikut contoh berkas konfigurasi logrotate dari beberapa aplikasi.

V. REMOTE LOGGING

Pada artikel ini akan diberikan contoh remote logging dengan Windows 7 sebagai host penerima log Fedora-Server 21. Pada contoh ini, Windows 7 menggunakan aplikasi “Syslog Watcher” untuk menerima log tersebut. Adapun langkahnya adalah sebagai berikut.

1. Unduh aplikasi “Syslog Watcher” pada tautan http://www.snmpsoft.com/downloads/SyslogWatcherSetup-4.7.5-win32.msi, lalu pasang.

2. Sembari menunggu pemasangan selesai, cek alamat IP Windows7 dengan perintah “ipconfig” pada Command Prompt.

3. Buka berkas konfigurasi rsyslog pada Fedora-Server dengan perintah berikut.

sudo vi /etc/rsyslog.conf

4. Edit berkas tersebut dengan menambahkan baris berikut, lalu simpan.

*.* @alamatIPdiWindows7

5. Buka aplikasi Syslog Watcher, pilih mode GUI “Manage Local Syslog Server”

6. Setelah itu klik menu “Settings”, lalu pilih “Remote Access”.

7. Beri tanda centang pada pilihan “Allow remote connection” dan tentukan nomor port TCP.

8. Klik “OK”. Lalu mulai ulang aplikasi Syslog Watch.

9. Setelah dimulai ulang, Syslog Watcher akan menampilkan log-log yang di-remote dari Fedora-Server.

Demikian, semoga bermanfaat! 🙂

Pada artikel ini akan dibahas mengenai audit log sistem dan log aplikasi pada sistem operasi Fedora-Server 21.

I. Log Sistem

Sejak versi 20,  log sistem Fedora tidak lagi dikelola oleh “syslog” secara bawaan. Kini Fedora menggunakan layanan bernama “journal“. Sebenarnya layanan ini sudah ada sejak Fedora 17, namun logging yang dilakukan belum persistent  secara bawaan.

• Lokasi log journal terdapat pada direktori /var/log/journal.

• Log journal berupa berkas binary. Namun jika kita ingin membaca log sistem dapat menggunakan perintah “journalctl“.

• Berkas konfigurasi journal adalah /etc/systemd/journald.conf.

II. Log Aplikasi

• Secara umum log aplikasi tersimpan pada direktori: /var/log/namaaplikasi
• Berikut direktori log aplikasi bawaan sistem operasi Fedora-Server 21:

• Berikut contoh isi log dari beberapa aplikasi:

• Selanjutnya akan dibahas mengenai log aplikasi Apache, MySQL, WordPress, dan SELinux secara khusus.

a) Log Apache

Direktori log Apache terdapat pada /var/log/httpd, yang di dalamnya terdapat beberapa jenis log, yaitu:

Berikut diberikan contoh isi dari beberapa berkas log Apache.

Berkas konfigurasi log Apache terdapat pada /etc/httpd/conf/httpd.conf, di mana isinya adalah sebagai berikut.

b) Log MariaDB (MySQL)

Berkas log MySQL adalah /var/log/mariadb/mariadb.log.
Berikut contoh isi log aplikasi MySQL.

Berkas konfigurasi MySQL adalah /etc/my.cnf.

c) Log WordPress

• Untuk membuat log WordPress dari direktori log Apache, terlebih dahulu buat suatu VirtualHost dengan cara:

1. Buat berkas konfigurasi WordPress dengan perintah berikut.

sudo vi /etc/httpd/conf.d/wordpress.conf

2. Ketik baris berikut dalam berkas konfigurasi tersebut, lalu simpan.

3. Mulai ulang aplikasi Apache.

Setelah melakukan langkah di atas, berkas log WordPress akan masuk ke direktori log Apache seperti pada gambar berikut.

• Untuk membuat daftar log akses WordPress, kita dapat menggunakan plugin “WP Security Audit Log”.
• Sebelum memasang plugin, terlebih dahulu ubah kepemilikan folder WordPress menjadi milik pengguna Apache supaya pemasangan tidak menggunakan FTP.

# Untuk membuat folder WordPress menjadi milik pengguna Apache
sudo chown -R apache wordpress/

# Untuk membuat folder WordPress menjadi milik grup Apache
sudo chgrp -R apache wordpress/

# Untuk memberi izin penuh untuk mengakses direktori WordPress
sudo chmod u+wrx wordpress/*

• Adapun langkah pemasangan plugin-nya adalah sebagai berikut.

1. Unduh berkas zip plugin “WP Security Audit Log” di tautan ini.

2. Login ke WordPress. Pada menu “Plugins” klik pilihan “Add New”.

3. Setelah itu, klik “Upload Plugin”. Masukkan nama berkas zip plugin, lalu klik “Install Now”.

4. Pilih “Installed Plugins” pada menu “Plugins” di dashboard, lalu aktifkan plugin “WP Security Audit Log”.

5. Untuk melihat log, klik “Audit Log Viewer” pada menu “Audit Log” di dashboard.

6. Lalu akan muncul daftar log berikut.

d) Log SELinux

Keputusan SELinux, seperti membolehkan atau melarang akses, disimpan sebagai cache yang dikenal sebagai Vector Access Cache (AVC). Pesan penolakan dicatat saat SELinux menolak akses. Penolakan ini juga dikenal sebagai “AVC denials“, dan dicatat ke lokasi yang berbeda, bergantung pada daemon yang berjalan. Berikut daftar lokasinya.

• Untuk membaca log, gunakan perintah berikut.

sealert -a /var/log/audit/audit.log

sealert -a /var/log/messages

• Berikut contoh isi berkas “audit.log” :

Demikian artikel mengenai audit log sistem dan log aplikasi pada Fedora-Server 21.

Pada artikel selanjutnya akan dibahas mengenai audit log pengguna, rotasi log, serta remote logging Fedora-Server 21. ( Silakan baca di sini 😀 )

Sistem Log

OpenBSD menyediakan fasilitas log, untuk alamat penyimpanan berkas log sendiri ada di /etc/syslog.conf. berkas syslog.conf adalah berkas konfigurasi untuk program syslogd (8). Ini terdiri dari blok baris dipisahkan oleh spesifikasi program dengan masing-masing baris berisi dua bidang:

Pertama selectors yaitu menentukan jenis pesan dan prioritas sejauh mana akan di implementasikan. Kedua action yang menentukan tindakan yang akan diambil jika syslogd (8) menerima pesan yang sesuai dengan kriteria. Selecors dan Action dipisahkan oleh satu atau lebih karakter tab.

selectors dikodekan sebagai fasilitas, yaitu titik (‘.’), dan level, dengan tanpa spasi. fasilitas dan level tidak case sensitive.

Fasilitas menggambarkan bagian dari sistem yang menghasilkan pesan, dan memiliki kata kunci berikut: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, syslog, user, uucp and local0 through local7.

Level menggambarkan keparahan pesan, dan kata kunci mengikuti list order tertinggi ke terendah: emerg, alert, crit, err, warning, notice, info and debug.

Fasilitas	Program Yang Direpresentasikan
Auth	Sistem Otorisasi: login(1), su(1), getty(8), dll.
Authpriv	Sama seperti auth, tetapi dapat dibaca oleh beberapa individual yang telah ditentukan.
Cron	Daemon cron, cron(8).
Daemon	Daemon Sistem, seperti dhcp(8), yang tidak diatur secara eksplisit oleh fasilitas lainnya.
FTP	File Transfer Protocol di Daemon ftpd(8).
Kern	Pesan yang dihasilkan oleh kernel. Ini tidak dapat dihasilkan oleh proses pengguna.
local0-local7	Disediakan untuk pengguna lokal.
Lpr	Sistem line printer spooling : lpr(1), lpc(8), lpd(8), dll.
Mail	Sistem Mail.
Mark	Fasilitas khusus yang digunakan syslog.
News	Sistem Network News
Syslog	Pesan yang dihasilkan secara internal oleh syslogd (8).
User	Pesan yang dihasilkan oleh proses pengguna secara acak. Ini adalah identifier fasilitas default jika tidak ada yang ditentukan.
Uucp	Sistem Uucp.
*	Semua facilitas terkecuali Mark, dikarenakan fasilitas Mark menerima pesan setiap 20 menit (lihat syslogd(8)).
,	Multiple Fasilitas bisa digunakan dalam satu level dengan memisahkan menggunakan karakter koma.

Level	Pesan Yang Direpresentasikan
Emerg	Sebuah kondisi panik. Hal ini biasanya disiarkan ke semua pengguna.
Alert	Sebuah kondisi yang harus segera diperbaiki, seperti sistem database rusak.
Crit	Kondisi kritis, misalnya, kesalahan perangkat keras.
Err	Pesan kesalahan.
Warning	Pesan Peringatan.
Notice	Kondisi yang tidak termasuk dalam kondisi salah, tetapi mungkin harus ditangani secara khusus.
Info	Pesan Informasi
Debug	Pesan yang berisi informasi biasanya penggunaan hanya ketika debugging program.
None	Spesial level untuk menonaktivkan fasilitas.

untuk setiap pesan log, biasanya disimpan didalam /var/log/ tetapi bisa dikonfigurasi letak penyimpanannya di berkas syslog.conf, berikut isi berkas syslog.conf.

Rotasi Log

newsyslog disediakan oleh OpenBSD untuk mengelola berkas log. berdasarkan besar berkas dan umur berkas, alamat newsyslog sendiri ada di /etc/newsyslog.conf yang isinya sebagai berikut. Setiap berkas log diberi nama log.1, log.2, log.3, dan seterusnya. ketika berkas log melebihi batas, maka berkas yang paling lama disimpan dihapus. ada dua format untuk merotasi log.

1. Menurut ISO 8601 dengan prefiks (‘@’) : [[[[[cc]yy]mm]dd][T[HH[MM[SS]]]]]

2. Menurut Hari, Minggu, dan Bula dengan prefiks (‘$’) : [DHH], [WW[DHH]], and [Mdd[DHH]].

#3 Log remote
mencoba membuat fitur remote logging pakai syslogd

Terdapat 3 cara untuk melakukan log pada pesan:

1. Logging pada server yang sama: Pesan ditulis di dalam lokal harddisk atau database.
2. Logging menggunakan sebuah remote server: Log akan dikirimkan melalui jaringan menuju sebuah server log terpusat. Pada server log pusat, pesan yang berasal dari berbagai macam sistem ditulis ke dalam lokal drive/database.
3. Relay logging: Cabang ‘A’ and Cabang ‘B’ merekam log pesan pada dua(2) server yang berbeda. Kedua server ini These mengirimkan log pesan ke ‘Head Office’.

Pada percobaan kali ini kita akan menggunakan percobaan 2 (Logging pada sebuah remote server). Ada dua host yaitu host untuk log server dan host client yang mengirimkan pesan log ke log server.

Host A (Log Server) -> Ubuntu 15.04 Pyhsical Host, Alamat IP: 192.168.10.43

Host B (Client)-> Ubuntu 15.04 Virtual Host, Alamat IP:192.168.56.101

Pada Ubuntu kita dapat menggunakan fasilitas remote logging menggunakan rsyslogd secara default.

Pada percobaan kali ini kita akan mencoba menggunakan sebuah klien mengirimkan informasi syslog klien  ke server syslog yang telah kita setting. Topologinya seperti dibawah ini:

File Konfigurasi rsyslog.conf terdiri dari tiga(3) bagian yaitu:

1. Modules. Rsyslog terdiri dari arsitektur modular. Arsitketur tersebut membuat fungsionalitas ditambahkan secara dinamis melalui modul-modul tersebut. Modul tersebut yaitu:
   • Input Modules – Untuk mengumpulkan pesan log dari berbagai sumber
   • Output Modules – Untuk menulis pesan log ke berbagai tempat ( file, socket,dll)
   • Parser Modules – Untuk melakukan parsing isi pesan log
2. Configuration Directives. Seluruh perintah konfigurasi harus dispesifikasikan per baris dan harus dimulai dengan tanda dollar ($). Perintah konfigurasi ini akan berdampak pada rules yang kita buat.
3. Rule line. Setiap rule line terdiri dari dua(2) fields yaitu sebuah ‘selector field’ and sebuah ‘action field’. Selector field dibagi menjadi dua yaitu ‘facilities & priorities’. Action field menspesifikasikan langkah apa yang harus dilakukan untuk mencocokkan dengan rule yang sudah dibuat.

Tutorial

Konfigurasi di Host Log Server (192.168.10.43)

1. Open File di Terminal

sudo nano /etc/rsyslog.conf

2. Edit file (Ubah file konfigurasi seperti dibawah ini)

#################
#### MODULES ####
#################

$ModLoad imuxsock # menyediakan dukungan untuk sistem log di lokal file
$ModLoad imklog # menyediakan dukungan logging kernel
#$ModLoad immark # menyediakan pesan –MARK–

# provides UDP syslog reception
#$ModLoad imudp   –>Hilangkan tanda “#” sehingga server mendengar port tertentu yang telah kita setting
#$UDPServerRun 514   –> Hilangkan tanda “#” – spesifikasi nomor port UDP, secara default port 514

# provides TCP syslog reception
#$ModLoad imtcp   –> Hilangkan tanda “#” sehingga server mendengar TCP port yang telah ditentukan
#$InputTCPServerRun 514  –> Hilangkan tanda “#” – Spesifiaksi nomor port, secara default port 514

Tambahkan pada baris selanjutnya:

#  Ini adalah template untuk menghasilkan nama file log secara dinamis, tergantung pada alamat IP klien
$template FILENAME,”/var/log/%fromhost-ip%/syslog.log”

# Merekam seluruh pesan log ke file dalam bentuk tertentu secara dinamis. Setiap klien (misal alamat IP 192.168.56.101, 192.168.57..101, dll) akan dibuat sebuah direktori terpisah dengan template FILENAME
*.* ?FILENAME

Konfigurasinya seperti dibawah ini:

Setelah selesai konfigurasi restart service rsyslog, dengan mengetikkan di terminal:

/etc/init.d/rsyslog restart

Konfigurasi File di Klien

Kita akan melakukan konfigurasi di host klien (192.168.56.101)/Virtual Host

1. Buka terminal dan ketik sudo nano /etc/rsyslog.conf
2. Edit file konfigurasi seperti di bawah ini$ModLoad imuxsock$ModLoad imklogTambahkan di line file paling bawah:# Melakukan UDP forwarding. Alamat IP adalah Alamat IP Log Server
   *.* @192.168.10.43:514Konfigurasi rsyslog.conf di klien
3. Simpan (Ctrl-X)
4. Restart service: /etc/init.d/rsyslog.conf restart. Catatan: 192.168.10.43 adalah ip log server

Verifikasi log dari klien (192.168.56.101) disimpan di log server (192.168.10.43)

 

 

 

Maka akan muncul tampilan dibawah ini:

Kita juga dapat menggunakan salah satu tools seperti LogAnalyzer untuk menampilkan GUI log server terpusat dengan membuat database mysql terlebih dahulu.

Letak Log dan Konfigurasi Awal

Pada dasarnya letak log pada CentOS ada pada /var/log/. Hanya utmp saja yang terletak pada /var/run/utmp. Sementara untuk melakukan konfigurasi, terdapat pada file rsyslog.conf yang terletak pada /etc/rsyslog.conf.

Pada rsyslog.conf terdapat rules yang dapat digambarkan sebagai berikut: [fasilitas].[level_prioritas]

Nama fasilitas	Program apa yang direpresentasikan
kern	Pesan yang datang dari kernel Linux
messages	melakukan log pada apapun (kecuali mail) dengan level minimal .info
AUTH / AUTHPRIV	Pesan yang datang dari otorisasi dan keamanan yang berelasi dengan event
mail	pesan yang dibuat oleh subsistem mail
cron	pesan yang dibuat oleh subsistem mail
daemon	pesan yang datang dari daemons
news	pesan yang dibuat oleh subsistem berita jaringan
user	pesan yang datang dari program user
local0 hingga local7	dipersiapkan untuk penggunaan local

Sedangkan arti prioritas adalah sebagai berikut (dari paling prioritas)

Prioritas	Arti
emerg	Pesan yang datang dari otorisasi dan keamanan yang berelasi dengan event
alert	kondisi dimana butuh penanganan langsung
crit	kondisi kritis
err	error
warn	peringatan
notice	kondisi yang memerlukan perhatian
info	pesan infomarsi
debug	informasi debug dari program

ISI LOG

Beberapa isi log yang cukup penting adalah sebagai berikut

WTMP, BTMP, dan UTMP

Pada log ini digunakan perintah last -f  untuk tiap log yang ada dan hasilnya adalah sebgai berikut

dengan format:

[username] [terminal_login] [kernel] [hari_tanggal] [waktu_mulai] [waktu_akhir]

lastlog

pada lastlog ,yang berguna sebagai pencatat log terakhir dengan menggunakan user tertentu, hanya tediri dari sebagai berikut

yum.log

log ini berisi tentang daftar penggunaan yum

dengan format:

[waktu] [hal_yang_dilakukan] : [file_yang_terubah]

Apache

Pada direktori apache (/var/log/httpd) terdapat dua buah log yaitu access_log dan error_log

Contoh access_log

Contoh error_log

mysql (mariadb)

pada log ini tedapat tanggal penggunaan, waktu, dan hal yang dilakukan pada basis data yang dimiliki.

Log Rotate

Log rotate adalah sebuah perkakas yang digunakan oleh seorang adminstrator untuk mengelola ruang harddisk untuk menyimpan log. Untuk mengelola log rotate ini diperlukan dua konfigurasi yaitu:

1. generik konfigurasi log rotate pada /etc/logrotate.conf
2. service spesifik yang ada dan disimpan pada /etc/logrotate.d

Generik konfigurasi log (sebelum diganti) berisi (setelah komentar dihilangkan):

1  weekly
2  rotate 4
3  create
4  dateext
5  include /etc/logrotate.d
6  /var/log/wtmp {
7      monthly
8      create 0664 root utmp
9          minsize 1M
10      rotate 1
11  }

Dengan rincian sebagai berikut:

• Baris 1 – weekly pilihan konfigurasi yang memastikan tiap minggu terdapat rotasi semua berkas log dan sesuai dengan direktori /etc/logrotate.d/
• Baris 2 – rotate 4 memastikan setiap log rotate menampung backup sebanyak 4 file
• Baris 3 – create pilihan untuk memerintahkan logrotate membuat berkas log kosong untuk tiap rotasi
• Baris 4 – dateext menambahkan ekstensi ke semua file log yang di rotasi dengan bentuk basis tanggal ketika masing-masing file log tertentu diproses oleh logrotate
• Baris 5 – include menggunakan semua perintah pada direktori /etc/logrotate.d
• Baris 6 – 11 berisi konfigurasi spesifik milik service yang berjalan

sementara pada /etc/logrotate.d tedapat pengaturan spesifik untuk servis. Contoh yang akan diberikan adalah mariadb

maksud dari daftar diatas adalah sebagai berikut

• Create – membuat berkas log baru dengan permission 640 dimana owner dan group nya adalah mysql
• notifempty – jika berkas log kosong maka tidak akan di rotasi
• daily – terdapat rotasi tiap hari
• rotate 3 – berkas log akan di backup selama kali rotasi file
• missingok – jika berkas log hilang maka tidak akan ada keluaran error
• compress – berkas log file akan dikompresi
• post rotate – hal yang terjadi setelah berkas dirotasi

Pada dasarnya setiap log dapat dilakukan log rotate. Hanya saja terkadang semua berjalan secara otomatis. Jika log rotate dari sebuah service tidak ditemukan, admin dapat menambahkannya sendiri.

Studi kasus:

Terdapat sebuah servis baru yang bernama servicebaru. Letak dari log servis tersebut ada pada /var/log/servicebaru.log dan akan dibuatkan sebuah log rotate. Hal yang diinginkan adalah terjadi log rotasi pada tiap hari, mengerti jika kosong, dilakukan kompresi, dan jika ukuran berkas mencapai 20k maka dilakukan rotasi. Berkas baru yang dibuat haruslah hanya dapat digunakan oleh root dan hanya dapat dilakukan read dan write pada berkas tersebut

dari studi kasus diatas maka dilakukan hal berikut

Buat berkas baru dengan perintah vi /etc/logrotate.d/servicebaru dan isi dengan

/var/log/servicebaru.log {
 notifempty
 compress
 size 20k
 daily
 create 0600 root root}

untuk memahami lebih jauh tentang perintah perintah yang ada pada logrotate, dapat membuka terminal dan ketik man logrotate

Remote Log Server

Untuk melakukan remote log server, disini saya menggunakan windows sebagai host untuk menerima log yang ada dari centos. Berikut cara melakukan remote log server

• Lihat IP pada windows (sebagai contoh diatas IP 192.168.10.91)
• Pada centOS, buka rsyslog.conf dan tambahkan line *.* @IP_remote (seperti contoh diatas *.* @192.168.10.91:514). Line ini berguna untuk meneruskan segala macam fasilitas dengan segala level prioritas ke IP yang telah disepakati.
• Untuk menangkap syslog yang dikirim, pada windows saya menggunakan syslogwatcher dapat diunduh http://www.snmpsoft.com/syslogwatcher/syslog-server.html
• Jalankan program syslog watcher dan berikut hasil yang didapat

 

Log pada WordPress

Untuk melakukan logging pada wordpress dapat menggunakan plugin. Salah satu yang cukup mudah digunakan adalah WP-security-audit-log (tautan). Plugin ini dapat mencatat segala hal yang terjadi pada wordpress hanya saja untuk mengeluarkan dalam bentuk file diperlukan extension bernama report extension (tautan) yang dapat digunakan dengan cara berbayar.

Untuk melakukan instalasi plugin cukup lakukan hal berikut:

• unduh plugin
• klik pilihan plugins pada bar, klik add new, dan klik upload plugin

• Muncul popup dan klik browse file ektensi yang telah diunduh

 

• klik install now
• Setelah selesai melakukan instalasi, tekan plugin lalu installed plugin akan muncul seperti berikut

 

• Untuk mengetahui aktifitas yang terjadi pada wordpress, tekan tautan Audit Log Viewer dan akan terlihat seperti gambar dibawah

 

• Jika ingin melakukan ekspor log kedalam berkas bertipe csv diperlukan sebuah ekstensi. Berikut contoh jika ektensi tersebut digunakan. Gambar berasal dari laman asli
• Report dapat dibuat sesuai dengan keinginan pembuat

• Hasil dari log akan berbentuk seperti berikut

 

#2 Log aplikasi:
Wordpress + Mysql + web server.
Letak konfigurasi log aplikasi.
Apakah log dapat dilewatkan ke syslog + apakah ada untung ruginya.

Kita dapat mengetahui lokasi log di WordPress dengan mengintsall plugin. Salah satu plugin yang saya gunakan adalah Simple Login Log Versi 1.1.0. Fitur yang terdapat dalam Simple Login Log adalah :

1. Kemampuan untuk filter dari user name yang berhasil dan gagal login, termasuk timestamp waktunya
2. Dapat diekpor ke file CSV.
3. Log auto-truncation artinya jika rekaman log tidak pernah dihapus dalam log transaksi, maka log tersebut akan memenuhi kapasitast penyimpanan log secara fisik. Log truncation secara otomatis menghapus ruang dari log secara logika untuk digunakan kembali oleh log transaksi.

Tutorial Instalasi Plugin Simple Login Log

Dashboard Plugin di WordPress

Selesai Instalasi Plugin

Cara Menggunakan Simple Login Log:

 

 

 

 

 

 

 

Plugin wordpress lain untuk mengetahui username dan password antara lain WP Security Audit Log dan User Login Log. Plugin Simple User Login Log salah satu plugin yang mudah digunakan untuk log audit pada WordPress.

Konfigurasi log aplikasi di WordPress secara default berada di

Log dapat dilewatkan di syslog dengan melakukan konfigurasi terletak di.

Untungnya log dilewatkan di syslog adalah log terekam di dalam sistem . Ruginya adalah log yang dilewatkan di syslog akan menambah kapasitas fisik log pada sistem, single point of failure.

 

 

 

 

 

System Log di Ubuntu terdiri dari 5 bagian:

1. Authorization Log , merupakan log untuk otorisasi sistem, seperti Pluggable Authentication Module (PAM) system, the sudo command, dan remote logins to sshd. Authorization Log file dapat diakses di /var/log/auth.log.
2. Daemon Log adalah sebuah program yang berjalan di belakang sistem. Daemon log terletaak di /var/log/daemon.log.
3. Debug Log adalah log yang berisi pesan debug dari sistem Ubuntu dan aplikasi akan menyimpan di syslogd pada level DEBUG. Lokas Debug Log terdapat di /var/log/debug
4. Kernel Log adalah pesan log kernel Linux Ubuntu. Lokasi ada di var/log/kern/log
5. System Log berisi tentang log sistem Ubuntu. Lokasi ada di /var/log/syslog.

Rotasi Log

Ketika kita melihat direktori pada /var/log atau subdirektori di bawahnya, kita akan menemukan file log dengan nama seperti daemon.log.0, daemon.log.1.gz, dan seterusnya. Log file apakah ini? File ini adalah ‘rotated’ log files. File-file log tersebut secara otomatis diubah setelah jangka waktu tertentu dan sebuah file log baru dibuat. File log tersebut juga dikompresi dengan kompresi gzip misalnya menjadi  daemon.log.1.gz. Tujuan dari rotasi log adalah untuk penyimpanan dan kompresi file log lama sehingga mengurangi kapasitasi penyimpanan harddisk, tetapi tetap tersedia sewaktu-waktu apabila dibutuhkan.

Perintah logrotate dipanggil system-wide cron script /etc/cron.daily/logrotate, dan didefinisikan pada file konfigurasi di /etc/logrotate.conf.

 Apabila kita ingin menambahkan konfigurasi sendiri dapat di  /etc/logrotate.d (Misal konfigurasi apache2 and mysql disimpan).

Log Aplikasi

Log aplikasi di Ubuntu secara default terletak di /var/log. Jika kita  menginstall apache2 maka log aplikasi tersebut berada di /var/log/apache2.

Log aplikasi di /var/log/apache2 terdiri dari 2 yaitu:

• /var/log/apache2/access.log – .Merekam setiap halaman yang ditampilkan oleh webserver.

• 

  /var/log/apache2/error.log – . Menyimpan seluruh pesan error yang dilaporkan oleh server HTTP

Log yang tidak bisa dibaca manusia

Beberapa file log di dalam subdirektori /var/log tidak dapat dibaca manusia karena bentuknya berupa binary.

Login Failures Log

Setiap kesalahan login akan dicatat di /var/log/faillog,dimana file log tersebut sebenarnya didesain untuk diparsing dan ditampilkan dengan perintah faillog. 

Last Logins Log

Last logins log  berada di /var/log/lastlog biasanya digabungkan dengan perintah lastlog. Cortoh untuk melihat daftar user apa saja yang login kita dapat menggunakan perintah lastlog dan  untuk menampilkan satu halaman kita gunakan perintah less :

lastlog | less

Login Records Log

File /var/log/wtmp berisi tentang rekaman login, /var/log/wtmp perintah who  untuk menampilkan daftar user yang baru saja logged in.

 

Log Sistem

FreeBSD menyediakan logger sistem yaitu syslogd untuk mengelola log. Berkas konfigurasi syslogd ada di /etc/syslog.conf. Konfigurasi ini mengendalikan apa yang syslogd lakukan dengan entri log ketika entri log diterima. Parameter fasilitas mendeskripsikan subsistem mana yang menghasilkan pesan, misalnya kernel atau suatu daemon, dan parameter level mendeskripsikan kondisi dari kejadian yang terjadi.

Nama fasilitas	Program apa yang direpresentasikan
AUTH	Sistem otorisasi: login(1), su(1), getty(8), dan sebagainya.
AUTHPRIV	Sama seperti AUTH, tapi log disimpan ke sebuah berkas yang hanya bisa dibaca oleh pengguna terpilih.
CRON	Daemon cron: cron(8).
DAEMON	Daemon sistem, seperti routed(8), yang tidak disediakan secara eksplisit oleh fasilitas lain.
FTP	Daemon ftp: ftpd(8), tftpd(8).
KERN	Pesan yang dihasilkan oleh kernel. Pesan ini tidak dapat dihasilkan oleh proses pengguna apapun.
LOCAL0-LOCAL7	Disediakan untuk penggunaan lokal.
LPR	Sistem line printer spooling: lpr(1), lpc(8), lpd(8), dan lain-lain.
MAIL	Sistem surat-menyurat.
NEWS	Sistem berita jaringan.
SECURITY	Subsistem keamanan.
SYSLOG	Pesan yang dihasilkan secara internal oleh syslogd(8).
USER	Pesan yang dihasilkan oleh proses pengguna yang acak (random user processes).
UUCP	Sistem uucp. ipfw(4).
*	Semua fasilitas atau program kecuali MARK.
MARK	Fasilitas khusus yang digunakan oleh syslogd.

Nama level	Apa yang direpresentasikan
EMERG	Kondisi panik, biasanya di-broadcast ke semua pengguna.
ALERT	Sebuah kondisi yang harus diperbaiki sesegera mungkin, seperti basis data sistem rusak.
CRIT	Kondisi kritis, misalnya kesalahan pada perangkat keras.
ERR	Kesalahan-kesalahan.
WARNING	Pesan peringatan.
NOTICE	Kondisi yang bukan merupakan kondisi salah, namun kemungkinan harus ditangani secara khusus.
INFO	Pesan informatif.
DEBUG	Pesan-pesan yang berisi informasi yang umumnya digunakan ketika men-debug program.
NONE	Level khusus untuk menonaktifkan fasilitas.

Dalam FreeBSD, biasanya berkas-berkas log berada di direktori /var/log. Namun kita dapat mengubahnya dalam berkas konfigurasi /etc/syslog.conf. Berkas konfigurasi ini berisi satu baris setiap aksinya, dimana sintaks untuk setiap baris adalah selector field yang diikuti oleh action field. Sintaks untuk selector field adalah fasilitas.level yang berarti pesan log diambil dari fasilitas pada tingkat level atau lebih tinggi. Berikut contoh berkas konfigurasi /etc/syslog.conf:

Rotasi Log

Dalam FreeBSD, newsyslog digunakan untuk mengelola berkas-berkas log. Program bawaan ini secara periodik merotasi dan mengkompresikan berkas log, dan secara opsional membuat berkas log yang hilang dan memberi tahu program ketika berkas log dipindahkan. Dalam konfigurasi default, newsyslog berjalan setiap jam. Berkas konfigurasi newsyslog adalah /etc/newsyslog.conf, yang isinya seperti berikut:

Setiap baris dimulai dengan nama dari log yang dirotasi, diikuti dengan pemilik dan grup untuk berkas log yang dirotasi. Kolom mode untuk menetapkan perizinan pada berkas log dan kolom count untuk mengatur berapa banyak berkas rotasi log harus disimpan. Kolom size dan when untuk mengatur kapan newsyslog merotasi berkas. Berkas log dirotasi ketika ukurannya lebih besar dari size (dalam KB) atau ketika waktu dalam when sudah lewat. Ada dua format waktu:

1. Format waktu ISO 8601 (dengan prefiks ‘@’):[[[[[cc]yy]mm]dd][T[hh[mm[ss]]]]]
2. Format waktu hari, minggu, bulan (dengan prefiks ‘$”):[Dhh], [Ww[Dhh]], dan [Mdd[Dhh]]

Kolom flags untuk memberikan instruksi lebih lanjut, misalnya bagaimana mengkompresikan berkas rotasi atau untuk membuat berkas log jika hilang. Dua kolom terakhir adalah opsional, yaitu untuk menspesifikasikan nama berkas Process ID (PID) dari sebuah proses dan nomor sinyal untuk dikirim ke proses tersebut jika berkas dirotasi.

Log Aplikasi

Aplikasi	Berkas konfigurasi log	Berkas log
Apache	/usr/local/etc/apache24/httpd.conf	/var/log/httpd-access.log /var/log/httpd-error.log
MySQL	/usr/local/my.cnf	/var/db/mysql/hostname.err
WordPress	(custom) /usr/local/etc/apache24/Includes/wordpress.conf	(custom) /var/log/wordpress-access_log /var/log/wordpress-error_log

Contoh Log Apache /var/log/httpd-access.log:

Contoh Log Apache /var/log/httpd-error.log:

Contoh Log MySQL /var/db/mysql/foo.err:

Contoh Log WordPress /var/log/wordpress-access_log:

Contoh Log WordPress /var/log/wordpress-error_log:

Log pada WordPress

Tidak ada mekanisme log secara khusus untuk aplikasi WordPress, namun kita dapat memanfaatkan fasilitas log Apache untuk melakukan log WordPress. Pertama, buat sebuah VirtualHost. Buat berkas /usr/local/etc/apache24/Includes/wordpress.conf. Kemudian tulis baris-baris berikut:

• DocumentRoot = lokasi berkas-berkas PHP/HTML WordPress
• ServerName = nama domain tempat dimana VirtualHost ini merespon
• ServerAlias = opsional – digunakan jika kita ingin VirtualHost ini merespon ke lebih dari satu nama domain
• ErrorLog adan CustomLog = fasilitas log dari Apache

Kemudian ubah berkas /usr/local/etc/apache24/httpd.conf, beri tanda komentar pada baris-baris berikut:

sehingga menjadi terlihat seperti berikut:

Hidupkan kembali Apache:

service apache24 restart

 

Log akses pengguna WordPress

WordPress menyediakan plugin Simple History [5] untuk melalukan beberapa log, termasuk log akses pengguna. Ada juga plugin lainnya seperti WP Security Audit Log [5]. Cari plugin ‘Simple History’ pada menu Search Plugins kemudian klik Install Now:

Jika menemukan pesan ‘Abort class-pclzip.php: Missing zlib extensions” seperti gambar di bawah, artinya instalasi gagal karena modul php zlib belum terinstal (secara default tidak masuk dalam instalasi php). Modul php zlib dapat diinstal menggunakan port /usr/ports/archivers/php56-zlib. Setelah modul php zlib diinstal, instalasi plugin Simple History sudah bisa dilakukan:

Setelah instalasi berhasil, aktivasikan plugin Simple History seperti berikut:

Simple History akan menampilkan pesan berapa banyak kejadian di hari itu:

Sayangnya, dalam WordPress kita tidak dapat melihat informasi kejadian apa saja yang dilog oleh Simple History. Namun kita dapat melihatnya dalam basis data wordpress sebagai berikut:

Tabel wp_simple_history menyimpan setiap kejadian dengan id yang berbeda, waktu kejadian, level kejadian (seperti level pada syslogd), pesan (kejadiannya, misalnya log in/log out), dan sebagainya. Tabel wp_simple_history_contexts menyimpan informasi detil kejadian, history_id dalam tabel ini mengacu ke id dalam tabel wp_simple_history.

Melewatkan log aplikasi ke Syslog

Log Apache dapat dilewatkan ke syslog [2], begitu juga log MySQL (sejak versi 5.1.20) [4]. Log akses pengguna WordPress juga dapat dilewatkan ke syslog dengan mengubah kode fungsi log dalam plugin Simple History. Keuntungan dan kerugiannya adalah sebagai berikut:

Keuntungan	Kerugian
Keuntungan sentralisasi log secara umum yaitu kemudahan dalam manajemen log.	Kerugian sentralisasi log secara umum yaitu single point of failure.
Jika ada yang menyerang aplikasi, penyerang tidak bisa menghapus jejaknya (lognya).	Harus ada konfigurasi tambahan agar log juga ter-backup secara lokal (piped logging)
Tidak perlu menghentikan dan menghidupkan kembali aplikasi untuk sekadar mengkompresikan log.

 

Konfigurasi log Apache ke Syslog

Buat berkas /usr/local/bin/apache_syslog yang berisi kode perl berikut. Kode perl ini intinya memanggil fungsi openlog() untuk membuka koneksi ke syslog dan untuk menggunakan fasilitas local2, fungsi syslog() untuk mengirimkan log dengan level info atau lebih tinggi, dan terakhir fungsi closelog() untuk menutup koneksi.

Pastikan bahwa berkas /usr/local/bin/apache_syslog bersifat eksekutabel:

Kemudian instal p5-Sys-Syslog melalui port sysutils/p5-Sys-Syslog.

# cd /usr/ports/sysutils/p5-Sys-Syslog
# make install clean

Dalam berkas konfigurasi Apace /usr/local/apache24/httpd.conf ganti direktif ErrorLog dan CustomLog seperti berikut:

Arti dari baris tersebut adalah kita memerintahkan ErrorLog untuk dilewatkan ke Syslog dengan menggunakan fasilitas local1 dan memerintahkan CustomLog (log akses) untuk mengeksekusi kode perl yang sudah dibuat sebelumnya. Namun karena sebelumnya kita menggunakan VirtualHost untuk log pada WordPress, maka log akan disimpan ke berkas-berkas yang ditetapkan di VirtualHost. Oleh karena itu, kita nonaktifkan VirtualHost dengan risiko log pada /var/log/wordpress-access_log dan /var/log/wordpress-error_log tidak akan aktif lagi.

Tambahkan beberapa baris pada berkas konfigurasi Syslog /etc/syslog.conf sebagai berikut. Artinya log dengan fasilitas local1 (yang telah ditetapkan untuk ErrorLog) dan dengan level apapun akan disimpan dalam berkas /var/log/httpd-error1.log. Begitu pula log dengan fasilitas local2 (yang telah ditetapkan untuk CustomLog) dan dengan level apapun akan disimpan dalam berkas /var/log/httpd-access1.log.

Buat berkas-berkas log dengan perintah berikut:

# touch /var/log/httpd-error.log /var/log/httpd-access.log

Tambahkan baris-baris berikut pada berkas /etc/newsyslog.conf untuk menentukan rotasi log:

Hidupkan kembali syslogd dan apache24:

Berikut isi berkas log /var/log/httpd-access1.log:

Dan berikut isi berkas log /var/log/httpd-error1.log:

 

Konfigurasi log MySQL ke Syslog

Log pada MySQL secara default menggunakan fasilitas daemon, kita dapat menggantinya dengan fasilitas yang lain (local0-local7) agar tidak tercampur dengan log yang lain. Sayangnya fasilitas log pada MySQL di-hard-code dalam mysqld_safe. Oleh karena itu kita harus melakukan beberapa perubahan dalam berkas /usr/local/bin/mysqld_safe sebagai berikut. Intinya adalah kita mendefinisikan fasilitas log sebagai variabel syslog_facility (yang nilai defaultnya daemon) sehingga kita dapat menetapkan nilainya sesuka hati.

Sekarang, kita perintahkan mysqld_safe untuk melewatkan log ke Syslog dan mengganti fasilitas log menjadi local3 dengan menambahkan tiga baris berikut pada berkas konfigurasi MySQL /usr/local/my.cnf. Kemudian mulai/hidupkan mysqld_safe dengan perintah berikut:

# mysqld_safe --defaults-file=/usr/local/my.cnf

Tambahkan baris berikut berkas konfigurasi Syslog /etc/syslog.conf. Baris ini berarti bahwa log dengan fasilitas local3 (yang telah ditetapkan untuk log MySQL) dan dengan level apapun akan disimpan dalam berkas /var/log/mysqld.log.

Buat berkas log dengan perintah berikut, kemudian hidupkan kembali syslogd.

# touch /var/log/mysqld.log

Berikut isi dari berkas log /var/log/mysqld.log:

 

Konfigurasi log akses pengguna WordPress ke Syslog

Dengan mengetahui fakta bahwa terdapat fungsi openlog(), syslog(), dan closelog() dalam PHP (PHP 4 dan PHP 5) mirip seperti pada kode perl sebelumnya, kita dapat menyelipkan kode tersebut ketika plugin Simple History melakukan kueri insert ke basis data. Fungsi dimana plugin Simple History melakukan kueri insert ke basis data adalah fungsi log() dari kelas SimpleLogger dalam berkas /usr/local/www/apache24/data/wp-content/plugins/simple-history/loggers/SimpleLogger.php. Untuk jaga-jaga, salinan berkas SimpleLogger.php.old dibuat sebelum melakukan perubahan.

Dalam fungsi log() ada dua kali kueri insert karena plugin Simple History memiliki dua tabel yaitu tabel wp_simple_history dan tabel wp_simple_history_contexts. Agar tidak terjadi redudansi log, penyelipan kode syslog() dilakukan di satu tempat saja yaitu setelah kueri insert ke tabel wp_simple_history_contexts karena tabel ini menyimpan informasi detil setiap kejadian. Kode yang ditambahkan adalah yang diberi komentar “TAMBAHKAN …” sebagai berikut.

Dalam kode di atas terlihat bahwa fasilitas local0 yang ditetapkan. Tambahkan baris berikut berkas konfigurasi Syslog /etc/syslog.conf. Baris ini berarti bahwa log dengan fasilitas local0 (yang telah ditetapkan untuk log akses pengguna WordPress) dan dengan level apapun akan disimpan dalam berkas /var/log/wordpress.log.

Buat berkas log dengan perintah berikut, kemudian hidupkan kembali syslogd.

# touch /var/log/wordpress.log

 

Berikut isi dari berkas log /var/log/wordpress.log. Kita dapat menentukan pesan apa yang ingin ditampilkan dalam log agar mudah untuk dibaca. Namun karena keterbatasan waktu, pesan yang ditampilkan adalah semua key:value kejadian yang disimpan dalam tabel wp_simple_history_contexts sehingga ada nilai value yang NULL atau redundan. Intinya adalah bahwa log akses pengguna WordPress yang disimpan dalam basis data terbukti dapat dilewatkan ke Syslog, yaitu dengan menyelipkan kode ke dalam plugin Simple History.

Remote Logging

Dalam FreeBSD, pengumpulan, penggabungan, dan rotasi berkas log tersentralisasi dapat dikonfigurasikan menggunakan syslogd dan newsyslog. Untuk mensimulasikan remote logging, kita dapat menggunakan dua jendela VMware, satu untuk mesin virtual server log dan satu untuk mesin virtual klien log. Misalkan server log yang bernama fooserver akan mengumpulkan informasi log untuk jaringan lokal. Klien log yang bernama foo akan dikonfigurasikan untuk mengirimkan informasi log ke server log. Kedua mesin virtual menggunakan sistem operasi FreeBSD 10.1.

Konfigurasi Server Log

Sebelum mengkonfigurasikan server log, perhatikan hal-hal berikut:

1. Jika terdapat firewall antara server log dan klien log, pastikan bahwa ruleset firewall mengizinkan UDP port 514 untuk kedua klien dan server.
   Berikut adalah contoh ruleset firewall dari klien log foo (server log fooserver tidak dipasang firewall) dalam berkas /etc/pf.conf. Setelah dilakukan perubahan ruleset, jangan lupa bahwa ruleset harus dimuat agar dapat digunakan.
2. Server log dan semua mesin klien harus memiliki entri dalam DNS lokal.
   Berikut adalah berkas /etc/hosts pada server log fooserver: Dan berikut adalah berkas /etc/hosts pada klien log foo:

Pada server log fooserver, ubah /etc/syslog.conf untuk menspesifikasikan nama klien yang mengirimkan entri, fasilitas log yang digunakan, dan nama log untuk menyimpan log klien. Kemudian hidupkan kembali syslogd. Berikut contoh ditambahkannya hostname foo, log semua fasilitas, dan simpan entri log dalam /var/log/logfoo.log:

Kemudian konfigurasikan /etc/rc.conf dan hidupkan kembali jaringan:

Entri pertama untuk memulai syslogd ketika sistem boot. Entri kedua untuk mengizinkan entri log dari klien foo, meningkatkan verbosity dari pesan log (-vv), dan mengizinkan log dari banyak klien (-a). Terakhir buat berkas log:

# touch /var/log/logfoo.log

Konfigurasi Klien Log

Selain mengirimkan entri log ke server log fooserver, klien log foo juga menyimpan entri log secara lokal. Setelah server log dikonfigurasi, ubah /etc/rc.conf pada klien log sebagai berikut kemudian hidupkan kembali jaringan:

Entri pertama untuk memulai syslogd ketika sistem boot. Entri kedua untuk mencegah klien foo menerima entri log dari klien lain (-s) dan meningkatkan verbosity dari pesan log (-vv). Kemudian, definisikan server log fooserver dalam /etc/syslog.conf klien foo. Dalam contoh berikut, semua fasilitas log dikirim ke server log fooserver. Setelah perubahan disimpan, jangan lupa untuk menghidupkan kembali syslogd.

Untuk menguji apakah pesan log berhasil dikirim melalui jaringan, gunakan logger(1) pada klien untuk mengirimkan sebuah pesan ke syslogd. Pesan ini seharusnya muncul dalam /var/log/messages pada klien log foo dan /var/log/logfoo.log pada server log fooserver.

# logger "halooooo fooserver"

Berikut isi dari berkas log /var/log/logfoo.log dalam server log fooserver:

Referensi:

1. https://www.freebsd.org/doc/en/books/handbook/configtuning-syslog.html
2. http://www.blissfulidiot.com/2011/09/if-you-need-to-use-syslog-to-send.html
3. http://archive.oreilly.com/pub/a/sysadmin/2006/10/12/httpd-syslog.html
4. http://shinguz.blogspot.com/2010/01/mysql-reporting-to-syslog.html
5. https://wordpress.org/plugins/wp-security-audit-log/screenshots/