Shorewall Di Stretch Tidak Otomatis Berjalan Setelah Sistem Restart

Tag

,

Saat melakukan pemeriksaan pada log status fail2ban, terdapat notice bahwa fail2ban telah melakukan ban pada IP yang melakukan brute force pada port SSH di server. Log tersebut seperti yang terlihat di bawah ini:

2018-12-18 10:17:02,644 fail2ban.actions        [1061]: NOTICE  [sshd] 58.242.83.18X already banned
2018-12-18 10:17:03,522 fail2ban.filter         [1061]: INFO    [sshd] Found 58.242.83.18X
2018-12-18 10:17:04,048 fail2ban.filter         [1061]: INFO    [sshd] Found 58.242.83.18X
2018-12-18 10:17:06,178 fail2ban.filter         [1061]: INFO    [sshd] Found 58.242.83.18X
2018-12-18 10:17:06,223 fail2ban.filter         [1061]: INFO    [sshd] Found 58.242.83.18X
2018-12-18 10:17:08,612 fail2ban.filter         [1061]: INFO    [sshd] Found 58.242.83.18X
2018-12-18 10:17:08,643 fail2ban.filter         [1061]: INFO    [sshd] Found 58.242.83.18X
2018-12-18 10:17:08,651 fail2ban.actions        [1061]: NOTICE  [sshd] 58.242.83.18X already banned

Terlihat bahwa semestinya IP 58.242.83.18X tersebut harusnya setelah di ban, tidak akan kembali melakukan proses koneksi, namun ternyata koneksinya tidak di banned! Karena untuk iptables saya menggunakan shorewall sebagai managemennya, saat dilakukan proses banned pada IP yang bermasalah, bila saya check di shorewall, harusnya akan terlihat IP apa saja yang di banned. Namun muncul error saat dijalankan perintah:

# shorewall show dynamic
   ERROR: Chain 'dynamic' is not recognized by /sbin/iptables.

Saat dijalankan perintah untuk menampilkan status shorewall ditemukan permasalahannya, shorewall tidak berjalan!

# shorewall status
Shorewall-5.0.15.6 Status at apuy-kambe - Tue Dec 18 10:20:19 WIB 2018

Shorewall is stopped
State:Started Fri Nov 16 10:44:49 WIB 2018 from /etc/shorewall/ (/var/lib/shorew                                                           all/firewall compiled Fri Nov 16 10:44:48 WIB 2018 by Shorewall version 5.0.15.6                                                           )

Ternyata setelah server hidup kembali akibat mati listrik di lokasi server berada, didapatkan informasi shorewall tidak berjalan otomatis di Debian Stretch, walaupun telah melakukan setting startup=1 di /etc/default/shorewall. Perlu dilakukan perintah untuk menambahkan shorewall sebagai service yang berjalan otomatis saat sistem berjalan pertamakalinya.

# systemctl enable shorewall
Synchronizing state of shorewall.service with SysV service script with /lib/syst                                                           emd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable shorewall
insserv: warning: current stop runlevel(s) (0 6) of script `shorewall' overrides                                                            LSB defaults (0 1 6).
insserv: warning: current stop runlevel(s) (0 6) of script `shorewall' overrides                                                            LSB defaults (0 1 6).

Setelah itu shorewall dijalankan.

# shorewall start
Compiling using Shorewall 5.0.15.6...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Compiling /etc/shorewall/zones...
Compiling /etc/shorewall/interfaces...
..

Kemudian fail2ban di restart.

# service fail2ban restart

Lalu saat di check kembali pada log, barulah fail2ban dapat berjalan dengan normal dan IP tersebut sukses di banned.

Sumber:

Iklan

Screen: Alat Remote Bermanfaat

Tag

Suatu saat saya pernah login untuk melakukan serangkaian kegiatan administrasi di server remote, akan tetapi belum selesai salah satu proses selesai, koneksi SSH saya terputus dan demikian pula dengan proses yang sedang dijalankan. Akibatnya fatal, saya harus melakukan serangkaian langkah tersebut dari awal lagi. Hal tersebut sebelum saya mengenal screen.

Menggunakan screen saya dapat membuat beberapa virtual terminal, di mana virtual terminal ini akan tetap ada dan terus berjalan, walaupun saya kehilangan koneksi ke mesin server yang sedang saya remote.

Untuk melakukan instalasi apabila belum terinstall:

# apt-get install screen

Langkah selanjutnya apabila ini adalah sesi pertama saya tinggal jalankan perintah

# screen

Untuk keluar dari sesi virtual saat itu tinggal di tekan tombol ctrl-a-d (tekan tombol Control lanjut tombol a dan lanjut tombol d).

Untuk menampilkan daftar sesi screen yang sedang berjalan tinggal ketikkan:

# screen -ls
There is a screen on:
        25167.pts-0.uluhitahkia (12/17/2018 09:54:19 AM)        (Detached)
1 Socket in /run/screen/S-root.

Untuk masuk ke dalam salah satu sesi screen tinggal lakukan perintah:

# screen -r 25167

Perintah screen -r <kode_id> sebagaimana yang ditayangkan di atas, maka kita akan masuk ke dalam sesi pada terminal screen yang kita jalankan sebelumnya.

Apabila kita ingin menghentikan sesi saat itu, benar-benar menghentikannya , maka kita tekan tombol ctrl-a dan dilanjutkan pengetikan :quit.

Referensi:

Upgrade Postgresql 9.6 Ke 10 Pada Debian Stretch

Tag

Persyaratan salah satu proses upgrade di sistem kami adalah penggunaan Postgresql 10. Saat ini, yang digunakan adalah postgresql versi 9.6. Untuk itu, dibutuhkan upgrade ke versi 10.

Sebelumnya setelah berhasil melakukan upgrade pada Sistem Operasi yang kami gunakan, dari Debian Jessie ke Debian Stretch, juga telah melakukan terlebih dahulu proses upgrade dari Postgresql 9.1 ke Postgresql 9.4, dilanjutkan ke Postgresql 9.6.

Agar bisa dilaksanakan pada langkah sebelumnya telah dilakukan proses penambahan repository milik postgresql, dengan menambahkan file di /etc/apt/sources.list.d/pgdg.list berisi perintah sebagai berikut:

deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main

Kemudian langkah yang dilakukan selanjutnya adalah menambahkan kunci digital milik repository, dilanjutkan perintah update paket sebagaimana perintah di bawah (diketikkan pada satu baris).

# wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
# sudo apt-get update

Kemudian dilanjutkan dengan melakukan instalasi postgresql 10.

# apt-get install postgresql-10

Bila telah terinstal, bila dijalankan perintah pg_listcluster, cluster dari postgresql 10 berada pada posisi hidup berdampingan dengan versi 9.6. Untuk melanjutkan proses upgrade cluster 10 harus dimatikan lebih dahulu.

# pg_dropcluster 10 main --stop

Setelah itu dilanjutkan dengan melakukan proses upgrade terhadap cluster yang digunakan saat ini yaitu 9.6.

# pg_upgradecluster 9.6 main

Pada proses upgrade ini akan berlangsung proses upgrade serta beberapa otomatisasi lainnya, di mana lamanya proses bergantung dari besarnya data yang ada. Setelah berhasil maka bila dilakukan perintah pg_lscluster akan terlihat bahwa cluster 9.6 mati dan 10 hidup.

# pg_lscluster
Ver Cluster Port Status Owner    Data directory               Log file
9.4 main    5433 down   postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log
9.6 main    5434 down   postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
10  main    5432 online postgres /var/lib/postgresql/10/main  /var/log/postgresql/postgresql-10-main.log

Di tempat saya karena cluster dari versi sebelumnya tidak dihapus, masih terlihat status 9.4 dan 9.6 ada. Kemudian aplikasi di test dan apabila telah berhasil serta tidak ada yang bermasalah kita tinggal melakukan drop pada cluster yang lain.

# pg_dropcluster 9.6 main

Referensi:

fail2ban Bermasalah Setelah Upgrade Debian 8 Ke Debian 9

Tag

Aplikasi fail2ban merupakan aplikasi yang sangat berguna sangat ingin melakukan langkah pengamanan terhadap sistem.

Setelah melakukan upgrade ke Debian 9 fail2ban menolak untuk berjalan sebagaimana mestinya. Untuk ini saya tinggal lakukan proses uninstall dan install ulang 😀

# apt-get --purge remove fail2ban
# apt-get install fail2ban

Referensi:

Shorewall Bermasalah Setelah Upgrade Ke Debian 9

Tag

Setelah melakukan upgrade dari Debian 8 (Jessie) ke Debian9 (Stretch), pada saat proses upgrade terdapat pemberitahuan untuk melakukan perubahan pada konfigurasi Shorewall di /etc/shorewall/shorewall.conf.

Secara default proses upgrade terhadap konfigurasi, sistem memilih untuk tidak melakukan penimpaan terhadap konfigurasi yang sudah ada, saya pun memilih untuk opsi default. Akan tetapi pada proses ini ternyata terdapat perubahan pada konfigurasi shorewall yang mengharuskan untuk melakukan update terhadap konfigurasinya.

Untuk proses update tinggal menjalankan perintah:

# shorewall update

Dilanjutkan dengan check terhadap konfigurasi, dilanjutkan dengan proses untuk menjalankan service.

# shorewall check
# shorewall start

Upgrade Debian 8 Ke Debian 9

Tag

, ,

Berikut ini merupakan catatan saya terkait proses upgrade pada server production yang kami gunakan saat ini.

Langkah pertama yang dilakukan adalah melakukan backup terhadap beberapa data penting, di server kami menggunakan database mysql, postgres, serta melakukan backup terhadap konfigurasi pada folder /etc. Untungnya pada semua server yang kami gunakan telah rutin di-backup menggunakan rsnapshot. Untuk berjaga-jaga, dilakukan beberapa backup secara manual.

# mysqldump --defaults-file=/etc/mysql/debian.cnf -cCeQ --hex-blob --quote-names --routines --events --triggers --all-databases -r all_databases.sql
# tar -pczf etc.tar.gz /etc

Perintah di atas melakukan proses backup terhadap database mysql dikarenakan terdapat perubahan aplikasi, di mana Debian 9 memutuskan untuk menggunakan MariaDB.

Langkah kedua yang dilakukan adalah melakukan perintah update dan upgrade serta dilanjutkan dengan dist-upgrade pada sistem yang berjalan, di mana versi yang digunakan sebelum upgrade adalah debian 8.11 (jessie).

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Setelah proses selesai dilanjutkan dengan Langkah Ketiga untuk melakukan pemeriksaan terhadap konsistensi paket aplikasi yang ada, atau apakah ada paket yang sudah tidak mendapatkan upgrade di Debian 9.

# dpkg -C
# apt-mark showhold

Bila tidak ada yang permasalahan yang muncul, di tempat saya ke-dua perintah di atas tidak menghasilkan keluaran apa-apa, maka bisa dilanjutkan untuk melakukan tahapan upgrade berikutnya. Bila tidak, maka perlu dipikirkan untuk melakukan tindakan lanjutan terhadap paket yang bermasalah tersebut.

Langkah Keempat adalah melakukan update terhadap repository. Saya melakukan backup terhadap konfigurasi lama dan melakukan perubahan terhadap nama versi Debian dari jessie ke stretch.

# cp /etc/apt/sources.list /etc/apt/sources.list.ori
# nano /etc/apt/sources.list

Berikut ini adalah contoh isi konfigurasi tersebut.

deb http://kambing.ui.ac.id/debian stretch main non-free contrib
deb-src http://kambing.ui.ac.id/debian stretch main non-free contrib
deb http://ftp.debian.org/debian stretch-backports main

deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free

Karena ada instalasi paket tambahan, di server terdapat PHP dan Postgresql, dilakukan pula untuk konfigurasi tersebut.

# cat /etc/apt/sources.list.d/pgdg.list
#deb http://apt.postgresql.org/pub/repos/apt/ jessie-pgdg main
deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main
# cat /etc/apt/sources.list.d/php.list
#deb https://packages.sury.org/php/ jessie main
deb https://packages.sury.org/php/ stretch main

Setelah proses tersebut selesai, lakukan update.

# apt-get update

Setelah proses selesai, maka coba test untuk melihat paket apa saja yang akan di-upgrade dengan menjalankan perintah:

# apt list --upgradable

Kemudian langkah terakhir adalah dua langkah penentu, melakukan upgrade pada masing-masing paket dan upgrade ke Debian stretcth.

# apt-get upgrade
# apt-get dist-upgrade

Setelah ini semestinya proses telah selesai, dan lakukan reboot bila dibutuhkan.

# reboot

Referensi:

Mengakses Komputer Lokal Dari Internet Tanpa IP Publik

Tag

Pada laptop yang saya gunakan terdapat integrated webcam, namun tidak pernah digunakan. Hingga saat saya memutuskan untuk membeli paket Internet yang ditawarkan oleh Indihome. Ide pun muncul, bagaimana bila saya memberdayakan saja laptop yang lebih sering ditinggal di rumah ini untuk untuk memonitor isi rumah? Karena webcam nya ada, saya pikir jaringan internet di rumah kalau saya tinggal harus ada gunanya. Untuk itu, muncul kebutuhan untuk melakukan remote dari Internet ke komputer laptop di rumah.

Apabila IP Publik merupakan fasilitas yang didapatkan dari paket indihome, maka tentu saja semuanya akan lebih mudah. Namun, saat mengakses ke router saya kecewa karena yang saya dapatkan bukan merupakan IP Public.

Bila saja ada IP Public tentu saja saya tinggal melakukan setting IP Forwarding di router, agar mem-forward request dari WAN ke service laptop saya. Tidak kekurangan akal, hasil dari pencarian di internet menggunakan google, saya dapatkan informasi menggunakan layanan milik ngrok.com.

Secara sederhana Ngrok membuat tunneling diantara komputer dan saya yang mengaksesnya dari luar jaringan lokal rumah. Karena Ngrok , saya tidak perlu lagi melakukan setting tambahan di router Indihome, selama terdapat akses internet maka saya dapat mengakses komputer di rumah.

Di Ubuntu instalasinya sangat mudah, tinggal melakukan download terhadap binary client ke laptop, dilanjutkan inisiasi otentifikasi token yang didapatkan setelah mendaftar di web ngrok.com, saya dapat langsung menggunakan layanannya yang gratis.  Untuk detailnya silahkan diakses pada web ngrok.com.

Langkah selanjutnya pada laptop dengan webcam tadi saya tinggal menjalankan perintah:

$ ./ngrok http 8081

di mana webcam server yang saya install nanti menggunakan port 8081 dan melayani request menggunakan protokol http.

 

 

Reload nginx Setelah Letsencrypt Berhasil Terupdate

Tag

, ,

Pada salah satu server web yang menggunakan Letsencrypt untuk sertifikat SSL-nya, untuk proses pembaharuan kami menggunakan crontab sebagaimana yang biasanya dilakukan.

0    0,12    *    *    *   certbot renew  >/dev/null 2>&1

Akan tetapi pada aplikasi server yang digunakan, di mana kami menggunakan nginx, ternyata tidak secara otomatis melakukan pembaharuan pula terhadap sertifikat yang digunakan oleh salah satu domain. Akibatnya, Letsencrypt telah melakukan pembaharuan, nginx tidak melakukannya.

Sebagai solusi sebenarnya sangat sederhana, yaitu dengan menjalankan perintah reload untuk server nginx-nya menggunakan perintah service nginx reload.

Agar proses reload server nginx dapat dilaksanakan secara otomatis setelah pembaharuan berhasil, maka pada salah satu konfigurasi milik Letsencrypt di /etc/letsencrypt/renewal/domain.com.conf tinggal ditambahkan perintah nginx untuk reload.

# Options used in the renewal process
[renewalparams]
renew_hook = service nginx reload

Setelah itu semestinya nginx akan di reload pada saat Letsencrypt berhasil melakukan pembaharuan.

rsnapshot Menyebabkan Hardisk Full Karena Hardisk Eksternal Gagal Di Mount Oleh autofs

Tag

,

Pada kasus sebelumnya terjadi hardisk full pada saat melakukan backup ke hardisk eksternal menggunakan rsnapshot, diakibatkan oleh automatic mounting hardisk eksternal yang dilakukan oleh autofs tidak berjalan sempurna. Hal ini bisa terjadi karena terdapat corrupt pada struktur file di hardisk eksternal tersebut atau hal lainnya.

Misalnya dalam kasus ini menggunakan autofs hardisk eksternal akan di-mount ke path /backuper/usbhd. Hal ini bisa dijelaskan bahwa lazimnya penggunaan autofs, maka pada mesin akan dibuat dahulu folder /backuper dan berdasarkan setting autofs hardisk eksternal yang kita pilih, di mounting ke path /backuper/usbhd.

Namun seperti yang disampaikan, pada saat rsnapshot melakukan pekerjaannya dan hardisk gagal di mounting, rsnapshot tetap melakukan proses backup dengan membuat folder /backuper/usbhd; akan tetapi alih-alih dibuat di hardisk eksternal ternyata folder ini dibuat di hardisk mesin. Akibatnya, data sebesar ratusan Giga memenuhi root yang hanya memiliki ukuran kurang lebih 10GB sehingga mengakibatkan salah satu mesin server production berhenti bekerja dan harus di reset.

Seharusnya: apabila hardisk eksternal gagal di mounting maka demikian pula proses backup harus dihentikan!

Untunglah solusinya sangat mudah, kita tinggal mengaktifkan salah satu setting yang memang dibuat untuk permasalahan ini pada bagian no_create_root. Berikut setting yang harus dibuat pada file konfigurasi rsnapshot yang digunakan.

# If no_create_root is enabled, rsnapshot will not automatically create the
# snapshot_root directory. This is particularly useful if you are backing
# up to removable media, such as a FireWire or USB drive.
#
no_create_root 1

Pelajaran dari ini adalah: hidup dan cintai komentar dan manual yang ada!

 

 

Remote Backup Menggunakan rsnapshot dengan Login Root

Tag

, ,

Backup adalah suatu hal yang sangat krusial dalam rangka mengamankan aset yang kita miliki. Akan tetapi terkadang backup harus dilakukan pada beberapa bagian yang selama ini hanya bisa diakses oleh user root, sehingga bagi mesin yang tidak bisa diakses langsung oleh root butuh proses tambahan untuk memastikan berjalannya backup dan pengamanannya. Pada tulisan ini dibahas bagaimana caranya backup menggunakan rsnapshot dapat dilaksanakan melalui cron, sehingga agar proses ini dapat berjalan membutuhkan sesi remote tanpa memerlukan interaksi user untuk mengetikkan password.

ASUMSI

Terdapat dua buah mesin di mana mesin yang akan menjadi tempat backup adalah mesin backup dan mesin yang dijadikan sumber adalah mesin server. Kita namakan saja mesin backup dengan MB dan mesin server dengan MS. MB memiliki IP 10.10.4.2 sedangkan MS memiliki IP 10.10.4.1.

Selain itu pada kedua mesin telah dilakukan instalasi ssh server dan rsync, serta MB bisa melakukan koneksi ke MS ditandai dengan bisa dibuat koneksi melalui ssh. Untuk membedakan di mana perintah dijalankan, pada masing-masing baris perintah ada ditambahkan tag MB ataupun MS untuk menunjukkan lokasi mesinnya.

Pada implementasi ini yang mengakses dan melaksanakan rsnapshot ada pada MB. Hal ini dilatari pada aspek keamanan, bahwa Mesin Production adalah mesin yang pertama kali akan diserang, sehingga apabila akses berhasil didapatkan maka satu-satunya kesempatan bagi kita untuk melakukan recovery adalah dengan melakukan instalasi ulang pada Mesin Production. Tentu saja, apabila Mesin Production berhasil diambil aksesnya dan terdapat informasi yang mendukung akses ke Mesin Backup maka hal ini berarti kiamat bagi kita. Oleh karena itu, proses backup dilaksanakan dari Mesin Backup dengan mengakses ke Mesin Production, tidak sebaliknya.

Langkah #1 SSH Tanpa Password

Untuk melakukan ini, login tanpa perlu melakukan penginputan password maka kita harus mengenerate kunci RSA di MB. Tentu saja hal ini dibutuhkan apabila sebelumnya belum dilaksanakan. Untuk melakukan pengecekan apakah sudah pernah digenerate (asumsi private dan public key ada di /root/.ssh/):

MB# cat /root/.ssh/id_rsa.pub

Apabila tidak ada file tersebut maka lakukan generate. Bila diminta untuk memasukkan password, abaikan saja.

MB# ssh-keygen -t rsa
MB# chmod og-rwx /root/.ssh/id_rsa
MB# chmod og-wx /root/.ssh/id_rsa.pub

Kemudian lakukan copy kunci publik MB ke MS.

MB# ssh-copy-id -p 22 root@10.10.4.1

WARNING: SAMPAI DI SINI KITA HARUS PAHAM BAHWA siapapun tidak diperbolehkan untuk dapat mengakses kunci private (file tanpa akhiran pub) tersebut, terkecuali si pemilik.

Langkah selanjutnya adalah silahkan check pada file /root/.ssh/authorized_keys di MS dan pastikan bahwa terdapat kunci publik dari MB dimasukkan di sana. Pada mesin MS perintah dijalankan dengan hasil kurang lebih seperti berikut (cat: semestinya berada pada satu baris, di sini dipisah untuk memudahkan):

MS# cat /root/.ssh/authorized_keys
ssh-rsa MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDPfsjvKCWkkbT+inF/bTX7eT5
UL+8H8Q03cCT+95SWfTf365I+c08ogPBb2GemxH3ng3q1gphLHomBLGqMakMmxfL
DR+UHMLqQqJKiGdBE86Xz9qcnp50DNKrn1XMFysoRq9OcOAFV5qUiaeQs8D8IccZ
3pVDqTnV36Z853xN5wIDAQAB root@MB

Setelah itu silahkan untuk melakukan login ke MS dari MB melalui ssh dan semestinya tidak ada proses permintaan password. Bila masih terdapat permintaan password, silahkan ulangi lagi proses di atas dan pastikan tidak ada yang terlewat.

Langkah #2 Test rsync dan Pengamanan Tambahan

rsnapshot merupakan sebuah utility yang berdiri di atas rsync, jadi harus dipastikan bahwa perintah rsync dapat berjalan dengan sempurna, tanpa kita harus memasukkan password.

Misalnya pada MS terdapat sebuah folder yang ingin kita dapatkan semua isinya.

MS# file /disk2/file/file_prod/
/disk2/file/file_prod/: directory

Maka kita coba lakukan proses untuk melakukan synchronized file diantara keduanya.

MB# rsync -avh -e "ssh -i /root/.ssh/id_rsa -p 22" root@10.10.4.1:/disk2/file/file_prod /home/backup-production/

Perintah di atas menjalankan rsync menggunakan ssh dan perintah “-i” menginformasikan private key di MB pasangan dari public key MB di MS, di mana public key nya telah dikirimkan ke MS sebelumnya. Seharusnya proses bisa berjalan tanpa ada permintaan password root.

Akan tetapi, pada setting kali ini kita ingin memastikan bahwa yang dilakukan oleh mesin backup hanyalah perintah dari rsync serta dilaksanakan dari satu buah mesin saja, yaitu mesin MB di 10.10.4.2. Untuk itu kita akan menambahkan setting filter IP dan script yang harus dijalankan saat sebuah koneksi melalui ssh dilakukan. Pada mesin MS di file /root/.ssh/authorized_keys tambahkan pada bagian depan setting filter from berisikan IP milik MB, serta setting script sehingga kurang lebih menjadi seperti ini.

MS# cat /root/.ssh/authorized_keys
from="10.10.4.2",command="/root/validate-remote-rsync" ssh-rsa MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDPfsjvKCWkkbT+inF/bTX7eT5
UL+8H8Q03cCT+95SWfTf365I+c08ogPBb2GemxH3ng3q1gphLHomBLGqMakMmxfL
DR+UHMLqQqJKiGdBE86Xz9qcnp50DNKrn1XMFysoRq9OcOAFV5qUiaeQs8D8IccZ
3pVDqTnV36Z853xN5wIDAQAB root@MB

Pada kode setting ssh di atas kita memastikan bahwa pengguna kunci publik tersebut berasal dari 10.10.4.2 yaitu MB dan saat sesi SSH dijalankan perintah yang dikirimkan secara remote akan diperiksa oleh script di /root/validate-remote-rsync.

Pastikan kode setting pada authorized_keys tersebut berada pada satu baris saja!

Berikut ini adalah kode script untuk /root/validate-remote-script di MS tersebut.

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\(*)
echo "Rejected"
;;
*\{*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
*\<*)
echo "Rejected"
;;
*\>*)
echo "Rejected"
;;
*\`*)
echo "Rejected"
;;
*\|*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac

Tentu saja ada setting hak akses yang juga perlu dilakukan.

MS# chmod u+rw,og-rwx /root/.ssh
MS# chmod gu+r,o-rwx /root/.ssh/authorized_keys
MS# chmod gu+rx,o+x,o-rw /root/validate-remote-script

Untuk melakukan testing silahkan akses melalui ssh dari MB ke MS, semestinya akan keluar pesan rejected dan sesi berhenti.

MB# ssh root@10.10.4.1 -p 22
Rejected
Connection to 10.10.4.2 closed.

Namun apabila yang dijalankan adalah perintah remote rsync dari MB ke MS, proses bisa berjalan dengan baik.

Langkah #3: Setting rsnapshot

Untuk setting di rsnapshot, selain yang standar maka terdapat beberapa tambahan diantaranya:

# setting untuk cmd_ssh diaktifkan 
cmd_ssh /usr/bin/ssh
# setting ssh argumen, apalagi bila port bukan default
ssh_args -p 1428 -o BatchMode=yes -i /root/.ssh/id_rsa
# log dan pid
logfile /var/log/rsnapshot-spse-prod.log
lockfile /var/run/rsnapshot-spse-prod.pid
# saya menyukai untuk sync dahulu untuk memastikan bahwa proses
# sync berjalan sempurna baru rotating dilaksanakan
sync_first 1

Setelah itu untuk melakukan proses backup dari MB tinggal menambahkan perintah backup. Sebagai contoh di sini rsnapshot akan melakukan backup untuk folder di MS yang akan disimpan ke MB.

backup root@10.10.4.1:/data/file-prod/2018 file_prod/

Lalu di test untuk memastikan bahwa sudah berjalan.

MB# rsnapshot -t sync && rsnapshot -t hourly

Apabila testing berhasil, dilanjutkan dengan perintah backupnya.

MB# rsnapshot sync && rsnapshot hourly

Tentu saja kita bisa melihat lognya berdasarkan setting di atas.

MB# tail -f /var/log/rsnapshot-spse-prod.log

Untuk setting rsnapshot di cron bisa check pada tulisan ini.

Sumber:

  1. https://www.ullright.org/ullWiki/show/secure-rsync-via-ssh-as-root
  2. http://positon.org/rsync-command-restriction-over-ssh
  3. http://troy.jdmz.net/rsync/
  4. http://troy.jdmz.net/rsnapshot/