Install SSL pada zimbra server dengan private key

Persiapan

  1. SSL Certificate: siapkan ini:
    • file sertifikat (e.g., your_domain.crt)
    • Intermediate sertifikat (e.g., intermediate.crt or CA_bundle.crt)
    • Private key (e.g., your_domain.key)
  2. Akses ke Zimbra Server: butuh root atau sudoers Zimbra server.

tahapan instalasi

1. Upload SSL Files ke Zimbra Server

Upload SSL pada folder,, misalnya /tmp/ssl.

2. pindah ke Zimbra User

pindah ke Zimbra user untuk instalasi:

sudo su - zimbra

3. yang lama di backup dulu

gini caranya:

cp /opt/zimbra/ssl/zimbra/commercial/commercial.key /opt/zimbra/ssl/zimbra/commercial/commercial.key.bak
cp /opt/zimbra/ssl/zimbra/commercial/commercial.crt /opt/zimbra/ssl/zimbra/commercial/commercial.crt.bak
cp /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt.bak

4. di replace ya yang lama

Copy SSL yang baru ke folder kerja:

cp /tmp/ssl/your_domain.crt /opt/zimbra/ssl/zimbra/commercial/commercial.crt
cp /tmp/ssl/your_domain.key /opt/zimbra/ssl/zimbra/commercial/commercial.key
cp /tmp/ssl/intermediate.crt /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt

pastikan permisinya file:

chown zimbra:zimbra /opt/zimbra/ssl/zimbra/commercial/commercial.crt
chown zimbra:zimbra /opt/zimbra/ssl/zimbra/commercial/commercial.key
chown zimbra:zimbra /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt
chmod 640 /opt/zimbra/ssl/zimbra/commercial/commercial.key

5. Verifikasi Certificate dan Key

gini caranya , ini nyambung terus ya:

/opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /opt/zimbra/ssl/zimbra/commercial/commercial.crt /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt

6. Deploy SSL yang baru

Deploy dengan cara berikut, ini nyambung terus ya:

/opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.crt /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt

7. Restart Zimbra Services

Restart servicenya untuk menerapkan:

zmcontrol restart

begitulah kira-kira. ulangin tahapan ini pada semua server zimbra jika server lebih dari satu.

install SSL gak sembarangan, setelah install kamu bisa cek di https://sectigostore.com/ssl-tools/ssl-checker.php untuk memastikan semua komponen terpenuhi

Bagikan saja, itu tidak berat

website diretas dan diinject link slo*t gac*or , kita perbaiki.

sudah lama banget saya gak nulis di blog ini. entah karena sibuk, atau males. kombinasi sih kayaknya hehe.

padahal, banyak banget kerjaan yang bisa di dokumentasiin di blog ini, ya bisa untuk sekedar kenangan, atau portofolio wkwkw

kali ini, saya lagi benerin sebuah website punya client, goverment yang laporannya ada link sl*ot g*acor di dalam website itu. si client meminta saya untuk membersihkan link dan menutup atau mencari tau celah keamanannya.

perpus5

hal pertama yang saya sampaikan kepada client adalah : “apakah sistem masih berjalan normal ?” , “ya, masih normal, jawab sang client”

saya meminta ke client untuk segera melakukan takedown atau memutus trafik ke website dari luar atau dari public. hal ini untuk kepentingan mitigasi.

setelah itu, saya meminta akses server kepada client, dan meminta untuk melakukan karantina, selain saya, jangan ada yang mengakses server tersebut.

kemudian, saya melihat websitenya. dari tampilan websitenya, ini adalah website perpustakaan yang source codenya berasal dari sebuah lembaga yang mengampu terkait perpustaaan, ya, benar, itu PERPUSNAS. dengan engine websitenya yang diberi nama INLISLite . 

INLISLite dibangun menggunakan bahasa pemograman PHP dan database MySql dengan memanfaatkan framework YII.

kemudian saya mencari kemungkinan Vulnerability yang terdapat pada INLISLite ataupun framework YII di mesin pencari google.

saya menemukan vulnerability pada INLISLite. berikut referensinya : Inlislite 3.2 Insecure Settings ≈ Packet Storm (packetstormsecurity.com)

hmmm, kemudian saya lakukan PoC pada website si client, namun tidak bisa. ini dikarenakan kredential tidak valid, ya bisa dirubah oleh admin, atau oleh siperetasnya. hehe

oke, lanjut kemudian saya login ke server. hal yang saya lakukan adalah melihat file log berikut besarannya. apakah syslog yang dibuat oleh administrator itu baik atau tidak. melihat dari sizenya, masih kurang baik sih.

saya tidak langsung membaca isi dari file log, karena bisa mual. saya berselancar dahulu sambil berenang renang ke folder aplikasi itu berada. folder yang saya sorot adalah folder yang memiliki permission full oleh web server. kebetulan, webservernya apache. biasanya, folder website yang memiliki full permission adalah folder dimana user bisa melakukan CRUD pada file/folder.

perpus1

nah, ada yang aneh satu, saya lanjut berselancar lagi deh di folder folder lainnya.

perpus2

nah, nemu lagi deh, coba saya pastikan isi filenya apa

perpus6

fix, ini php backdoor.

disini sekalian saya lihat, kapan siperetas melakukannya.

dan kemudian saya mencari file-file backdoor lainnya.

dari hasil analisis ini, menghapus file backdoor saja tidak cukup. karena pasti peretasnya akan kembali. saya lanjut analisis untuk menemukan celah keamanan pada web tersebut.

nah, saatnya berpusing ria, hehe. file log ini isinya ribuan, bahkan ada jutaan baris. dari hasil analisis diatas, saya sedikit trckly untuk menemukan celah keamanannya.

file backdoor sudah ketemu, berarti saya mencari log yang berkaitan dengan file backdoor tersebut.

perpus3

dari hasil percarian yang bernilai 200 , artinya 200 ini adalah respon ditanggapi oleh server. terlihat peretasan dilakukan sekitar 27 may 2023. namun, posisi file backdoor sudah terupload, belum kelihatan dari mana dia melakukan upload file backdoor tersebut yang disinyalir disitu letak celah keamanannya.

dari hasil percarian diatas, terlihat kan ya IP dari peretas, so sudah pasti dia pakai VPN. saya lanjut mencari tau celah keamanannya dengan membaca log dari IP tersebut. tentunya yang dilakukan pada tanggal 27 may 2023 atau sebelumnya.

perpus4

nah. sampai disini, bisa keliatan kalau emang bug atau vulnerabilitynya itu sama seperti yang saya sampaikan direferensi. berarti emang kredentialnya udah dirubah sama siperetas.

oke, saya lanjut, darimana dia berhasil upload backdoor itu. saya melanjutkan membaca log yang memiliki nilai POST pada diretory backend.

perpusdari hasil pencarian, ketemu. jadi celah keamanannya pada modul katalog dengan cara menambahkan konten-digital, darisinilah peretas mengunggah file backdoor pertamanya.

jadi kesimpulannya :

*peretas memanfaatkan celah keamanan atau vulnerability yang terdapat pada INLISLite

*peretas mengexploitasi celah keamanan dengan mengunggah backdoor atau malware dengan melakukan baypass file upload pada menu konten digital.

*tujuan peretas adalah membuat link sl*ot gac*or pada website

*motif peretas adalah ekonomi.

untuk saat ini, saya lagi bersihin backdoornya, dan ini butuh waktu. karena gak bisa dilakukan dengan bantuan antivirus atau anti anti lainnya, apalagi anti nyamuk.

setelah saya bersihin, baru saya backup database dan file appsnya. untuk jaga-jaga kalau rupanya siperetas punya hidden malware. utamanya, nutup celah kemanannya dengan menghapus folder backend atau merubah kredentialnya.

udah ah, segitu dulu ya. hehe.

 

Bagikan saja, itu tidak berat

Forgot password ubuntu 20.04 server on Vmware Vsphere

lupa password server, atau tidak diberikan password server oleh pemegang sebelumnya adalah hal yang menyebalkan. jika servernya berbentuk fisik, kamu harus mendatangi data center dimana letak server tersebut berada untuk melakukan reset password.

untungnya, dunia sudah canggih, saat ini hampir 90 % server berbentuk virtual. maka kegiatan reset password dapat dilakukan secara remote.

oh, iya, kegiatan ini adalah rangkaian dari sebuah kegiatan diantaranya reserve engineering sebuah server. oke langsung saja ke cara mereset password ubuntu 20.04 server di vmware vsphere.

  1. login kedalam dashboard vmware, kemudian, edit server virtual yang akan di reset.

reset

2. pada tab vm options, menu boot options, isikan lama delay server saat boot, terserah, saya isi dengan 10 sec.

reset23. kemudian, reboot server

Screenshot (3)_LI4. setelah reboot, akan muncul boot option seperti dibawah ini

reset-root-password-on-ubuntu-20-04-015. ketik “e” tanpa kutip untuk edit file boot . maka akan muncul tampilan seperti ini

reset-root-password-on-ubuntu-20-04-026. perhatikan, dan fokus hanya pada tulisan ro quiet splash $vt_handoff

reset-root-password-on-ubuntu-20-04-037. ganti tulisan tersebut menjadi rw init=/bin/bash

reset-root-password-on-ubuntu-20-04-048. setelah selesai edit, tekan Ctrl+x untuk reboot servernya.

9.server akan reboot dan akan menampilkan seperti dibawah ini

reset-root-password-on-ubuntu-20-04-0510. ketik mount | grep -w / pada console untuk verifikasi letak disk OS ubuntu nya

reset-root-password-on-ubuntu-20-04-0611. jika sudah tepat, ketik passwd pada console untuk merubah password root server

reset-root-password-on-ubuntu-20-04-0712. setelah berhasil, ketik exec /sbin/init untuk reboot server, dan silahkan, server sudah bisa login dengan user root dan password yang baru dibuat.

 

terima kasih.

Bagikan saja, itu tidak berat

konfigurasi mysql database master-slave untuk replikasi searah

ide ini sudah muncul sedari lama, namun saya baru bisa mengeksekusi akhir-akhir ini. awal munculnya ide ini karena ada kebutuhan dan permasalahan yang dihadapi oleh client dimana saya sebagai konsultannya.

awal permasalahannya adalah client tidak memiliki sistem backup sama sekali. untuk tindakan urgensi, saat itu saya membuatkan system backup yang berjalan setiap jam tertentu. namun, system backupnya hanya berbentuk dump dengan file ekstensi .sql. langkah ini saya tawarkan karena kebutuhan mendesak dan harus segera dieksekusi untuk melindungi data dari kegagalan fungsi sebuah system.

system backup yang berbentuk file hasil dump tersebut saya kirim dari server production ke server backup dengan tujuan jika ada kegagalan fungsi pada server production, mereka masih memiliki data hasil backup terjadwal.

sejauh ini, metode diatas sangat bermanfaat, terbukti beberapa kali server production mengalami gagal fungsi, antara lain: disk crash, network fail, system error dll, untuk mengembalikan system agar berjalan kembali, tentunya di restore dari file hasil backup tersebut.

namun, permasalahan berikutnya pasti akan muncul. tentunya ini berdasarkan tuntutan ya, jika client tidak nuntut, harusnya masih nyaman-nyaman saja dengan metode diatas. yang ada dalam benak saya beberapa waktu lalu, bagaimana jika client menuntut untuk data backup itu realtime,? artinya, jika data di input, misalnya huruf A pada server production, data huruf A tersebut juga langsung berada pada server backup secara realtime? tentunya metode backup terjadwal bukan lagi jawaban atas masalah ini.

mysql database master-slave adalah solusinya. dengan konfigurasi ini, maka data akan dikirim secara realtime dengan jeda data loss sangat kecil, ya sekian detiklah. ini tergantung dari kecepatan Network antara database master yang mengirim ke database slave, selain network, kecepatan menulis dan membaca pada disk atau yang dalam bahasa IT nya IOPS juga sangat berpengaruh.

untuk melakukan konfigurasi tersebut, gampang-gampang susah, jika anda hoki, mungkin mengikuti tutorial yang bertebaran di internet, bisa langsung implementasi. tapi saran dari saya, sebaiknya anda khatam dulu tentang Server dasar, kemudian khatam database enginer. kemudian memperkaya jam terbang dengan menyelesaikan berbagai persoalan hidup server. dengan begitu, anda akan paham dengan apa yang anda ketik, yang anda lalukan diserver. jadi kemungkinan salah eksekusi sangat tipis. jika anda tidak memahami itu, bisa saja anda salah eksekusi, misalnya menghapus database, atau mengubah privileges dari user server, seperti yang sering saya temui.

Screenshot_18

gambar diatas adalah salah satu perintah fatal yang dilakukan didalam server yang saya temui.

oke, kita langsung saja masuk ya ke teknisnya, sekarang saya memiliki dua server, yang pertama adalah master, dan yang kedua adalah slave. inti dari replikasi ini adalah bagaimana server slave dapat membaca binary log dari server master. maka, konfigurasi awal adalah pada server master

konfigurasi pada server master.

edit file berikut dan masukkan konfigruasi atau sesuaikan

[root@Master ~]# vim /etc/my.cnf
[mysqld]
log-bin=/data/bin/mysql-bin
binlog-format=row
server-id=1

2. membuat direktory binary log

[root@Master ~]# mkdir /data/bin
[root@Master ~]# chown -R mysql:mysql /data/bin

3. restart service mysql

[root@Master ~]# systemctl restart mysql

4. lihat hasil konfigurasi dengan perintah

[root@Master ~]# mysql -e "SHOW MASTER LOGS;"
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |     26753 |
+------------------+-----------+

5. membuat user mysql untuk melakukan replikasi

"GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'IP SERVER SLAVE' IDENTIFIED BY 'DISIPASSWD';"

Konfigurasi pada server slave.

  1. tambahkan atau modifikasi file berikut
[root@Slave ~]# vim /etc/my.cnf
[mysqld]
read-only
server-id=2

2. restart service mysql

[root@Slave ~]# systemctl restart mysql

3. menambahkan konfigurasi pada mysql

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='IP MASTER', MASTER_USER='repluser', MASTER_PASSWORD='PASSWDYGTADI', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=26753;
MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G

jika konfigurasi berhasil, harusnya akan muncul tampilan seperti dibawah ini.

Screenshot_8

sampai disini, tujuan sudah tercapai, yaitu mysql database replikasi searah secara realtime. disini perlu adanya monitoring dan throubleshooting jika ada error pada system replikasi. selain monitoring dan throubleshooting, diperlukan juga tunning database untuk performa lebih baik.

Saya Riyanto, seorang Sysadmin. familiar dengan linux server dan Open source. jika butuh dukungan, bisa hubungi saya pada surel riyanto1337@gmail.com

Bagikan saja, itu tidak berat

Extend disk CentOS Virtual Server pada VMWare Vsphere

menambahkan disk pada virtual server centos logical volume di VMWare Vsphere

tulisan ini sebagai catatan pekerjaan agar tidak lupa dan sebagai Portofolio, kali aja ada yang lirik 😀

  1. harus login dulu ke dashboard Vspere nya.
  2. kemudian, pilih VM yang akan di extend disknya, dan klik kanan, dan pilih edit setting.

Screenshot_737

Screenshot_738

lalu kamu bisa edit jumlah disknya mau jadi berapa. setalh itu , klik Oke.

 

5. lanjut, SSH ke CentOS servernya. ketik fdisk -l untuk mengetahui diskname dan apakah disk sudah tertambah

[root@localhost /]# fdisk -l

Disk /dev/sda: 2199.0 GB, 2199023255552 bytes, 4294967296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0009a189

 Device Boot Start End Blocks Id System
/dev/sda1 * 2048 2099199 1048576 83 Linux
/dev/sda2 2099200 419430399 208665600 8e Linux LVM

Disk /dev/mapper/centos-root: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/centos-swap: 8455 MB, 8455716864 bytes, 16515072 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/centos-home: 151.5 GB, 151523426304 bytes, 295944192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

oke, sudah tertambah ya jadi 2 TB. lanjut ketik fdisk /dev/sda dan seperti langkah2 dibawah ini

[root@localhost /]# fdisk /dev/sda

WARNING: The size of this disk is 2.2 TB (2199023255552 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).

Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p

Disk /dev/sda: 2199.0 GB, 2199023255552 bytes, 4294967296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0009a189

 Device Boot Start End Blocks Id System
/dev/sda1 * 2048 2099199 1048576 83 Linux
/dev/sda2 2099200 419430399 208665600 8e Linux LVM

Command (m for help): n
Partition type:
 p primary (2 primary, 0 extended, 2 free)
 e extended
Select (default p): p
Partition number (3,4, default 3): 3
First sector (419430400-4294967295, default 419430400): 419430400
Last sector, +sectors or +size{K,M,G} (419430400-4294967294, default 4294967294): 4294967294
Partition 3 of type Linux and of size 1,8 TiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

kamu bisa reboot VM nya, atau ketik partprobe , saya pilih reboot saja biar hackul yakin.

kemudian ketik vgs untuk mengetahui volume groups

[root@localhost ~]# vgs
 VG #PV #LV #SN Attr VSize VFree
 centos 1 3 0 wz--n- <199,00g 4,00m

oke, disitu nama volume groupnya centos

kemudian, ketik lsblk, untuk mengetahui letak dan nama disknya yang baru

[root@localhost ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2T 0 disk 
├─sda1 8:1 0 1G 0 part /boot
├─sda2 8:2 0 199G 0 part 
│ ├─centos-root 253:0 0 50G 0 lvm /
│ ├─centos-swap 253:1 0 7,9G 0 lvm [SWAP]
│ └─centos-home 253:2 0 141,1G 0 lvm /home
└─sda3 8:3 0 1,8T 0 part 
sr0 11:0 1 1024M 0 rom

sda3 adalah nama disk yang baru itu. lalu, kita tambahkan disk yang baru itu pada volume group centos dengan perintah :

[root@localhost ~]# vgextend centos /dev/sda3
 Volume group "centos" successfully extended

lanjut, kita lihat dulu, apakah command diatas berhasil, yaitu volume goups sudah tertambah :

[root@localhost ~]# vgdisplay centos | grep Free
 Free PE / Size 473088 / 1,80 TiB

sudah tertambah ya, jadi 1.8 TB. lanjut , kita extend, nah disini bebas, mau extend full, atau beberapa sesuai kebutuhan, dan juga, yang di extend sesuai mount point, ya istilahnya bagi-bagi kuelah. ada beberapa mount point pada volujme group, khususnya centos, ada root,swap, dan home disini saya akan extend yang root saja dengan menambahkan 500GB dari 1.8 TB. untuk extend full

 lvextend -l 100%FREE /dev/centos/root

[root@localhost ~]# lvextend -L+500G /dev/centos/root 
 Size of logical volume centos/root changed from 50,00 GiB (12800 extents) to 550,00 GiB (140800 extents).
 Logical volume centos/root successfully resized.

setelah di tambahkan, tinggal proses sync meta data dengan perintah growfs

[root@localhost ~]# xfs_growfs /dev/centos/root
meta-data=/dev/mapper/centos-root isize=512 agcount=4, agsize=3276800 blks
 = sectsz=512 attr=2, projid32bit=1
 = crc=1 finobt=0 spinodes=0
data = bsize=4096 blocks=13107200, imaxpct=25
 = sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=6400, version=2
 = sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 13107200 to 144179200

kemudian lihat, apakah sudah tertambah

[root@localhost ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3,9G 0 3,9G 0% /dev
tmpfs 3,9G 0 3,9G 0% /dev/shm
tmpfs 3,9G 8,8M 3,9G 1% /run
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/mapper/centos-root 550G 50G 501G 10% /
/dev/sda1 1014M 194M 821M 20% /boot
/dev/mapper/centos-home 142G 109G 33G 77% /home
tmpfs 783M 0 783M 0% /run/user/0

 

Bagikan saja, itu tidak berat

Mitigasi host yang menjadi bot

awalnya saya hanya melakukan rutinitas pengecekan firewall di kantor yang saya tangani.

dari hasil monitoring, ada lalu lintas yang tidak wajar dari salah satu host. kemudian saya mencoba mencari tau lebih jauh.

aktifitas tidak wajar

aktifitas tidak wajar

dari gambar diatas, dapat diketahui bahwa host tersebut berasal dari farmserver, dimana aktifitas outgoing yang tidak normal menuju port tertentu.

mitigasi selanjutnya saya remote SSH server tersebut. hal pertama yang saya cek adalah konsumsi resource

resource penuh

resource penuh

selain resource penuh, ada proses yang tidak wajar berjalan pada server, saya mitigasi lebih jauh terkait proses tersebut dengan melihat lebih rinci dengan perintah :

ps aux | grep netsnd

proses tidak wajar

proses tidak wajar

hasilnya adalah gambar diatas.  ada proses yang menjalankan file tttt yang targetnya random. oke, disini sudah jelas kalau memang aneh. saya lanjutkan migitasinya dengan mencari keberadaan file tttt dan kemudian membaca isi file tersebut,

letak file tttt dan rekan2 nya

letak file tttt dan rekan2 nya

dari hasil pencarian, menemukan letak file tersebut, kemudian saya membaca isi dari file tersebut dan file-file lainnya.

menjalankan nmap

menjalankan nmap

dari sana dapat dibaca, bahwasannya, proses yang tidak wajar tersebut adalah menjalankan perintah nmap pada host random di internet.

proses tersebut akan memakan resource, baik CPU, RAM dan Network.

darisana sudah bisa disimpulkan, bahwa server tersebut sudah menjadi ROBOT yang dikendalikan oleh orang lain diluar sana untuk proses-proses yang dia inginkan.

oiya, selain menjalankan perintah nmap, rupanya server tersebut juga digunakan untuk mining

miner

miner

siapa pelakunya ? bagaimana cara masuknya ? 

diperlukan mitigasi lebih dalam untuk mengetahui pelakunya, sementara ini, server tersebut saya karantina agar tidak berproses sementara waktu, dengan demikian, aplikasi diserver tersebut juga tidak dapat diakses sampai dengan waktu yang belum ditentukan.

terima kasih telah mau membaca. :*

Bagikan saja, itu tidak berat

Script Kill all processes of deleted files that are still open | skrip menghapus semua proses delete file yang berjalan

 

Berawal dari matinya service postgresql pada salah satu server, disebabkan karena partisi pada disk penuh.

penyebab penuhnya kala itu adalah kesalahan konfigurasi pada network yang menyebabkan attack ter-record pada log web server hingga puluhan GB.

solusi cepatnya adalah memperbaikin konfig network, kemudian menghapus file log yang menjadi penyebab partisi penuh.

namun, setelah dihapus, partisi masih terlihat penuh saat di lihta menggunakan perintah :

[root@localhost var]# df -h

Screenshot_430

padahal….

Screenshot_431

oke, kemudian saya melihat list open file yang berjalan.

Screenshot_432

akeh cuk, kalau kill satu persatu, bisa lelah jari eike yang lembut ini.

kira-kira perintahnya begini : kill -9 82363

oke, saya bikin aja dalam bentuk bash script, nantinya bash script ini juga bisa dijalankan di server lain. bikin file dengan ekstensi .sh , terserah. misalnya jancuk.sh, bikin permisinya 777, lalu tambahkan code, begini codenya,

#!/bin/bash

lsof|grep deleted|awk {print $2}|xargs kill -9

simpan, dan buang jalankan.

sebelum kamu copy pasti script diatas, pastikan kamu memahami apa isinya, jangan asal copas, bisa jadi itu script buat delete seluruh folder / mu 🙂

Continue reading

Bagikan saja, itu tidak berat

Analisa Sistem dan Infrastruktur untuk pemecahan masalah ( khusus pemula )

halo semua, seperti biasa, nulis untuk kebutuhan catatan saja bagi saya. atau bisa juga sebagai Portofolio, kali aja artikel saya ini di lirik sama seseorang yang sedang membutuhan jasa saya. hehehe wkwkwk. judulnya itu analisa sistem dan infrastruktur untuk pemecahan masalah.

oiya, artikel ini khusus pemula, untuk yang sudah Pro = Profesional, jangan dibaca. karena saya bisa diketawain. wkwkwkwkw begitu. karena ini analisa abal-abal alias sembarangan. saya sendiri baru pertama kali melakukan analisa se kompleks ini. permasalah ini sudah beberapa bulan terjadi, dan saya baru sempat nulisnya sekarang.

berawal dari laporan client, bahwa aplikasinya lambat di akses. errornya itu lo yang bikin menarik. :

error tcp

error tcp

dari error diatas, rata-rata mahluk hidup di muka bumi ini pasti menduga ada masalah dengan jaringan, lalu mereka akan berasumsi bahwa bandwith di servernya bermasalah. karena mereka buka yutub aman kok, dan web-web lain aman. bandwith servernya nih pasti. gitchu~~~

btw, wait… eh, itu di akses jam 11 malam loh, (lihat pojok kiri atas). harusnya, jam segitu bandwith server gak tinggi. oke deh, untuk memanstikan, saya terpaksa hubungi pihak provider, apakah benar, pada jam segitu bandwith mentok. dan jawabannya, tidak. mentoknya kalo siang wkwkwkw.

oke, kita bahas yang benerannya, error tersebut terjadi karena ada lost koneksi dari client (HP) ke server aplikasi. penyebabnya ? bisa jaringan di client, jaringan di server, query, bandwith, daaaaaaaann server yang terlalu sibuk, gak tau deh ngapain dan lain-lain, banyak deh. oke, kita eliminasi masalah, ini yang penting, bisa eliminasi. seperti indonesian idol aja ya. wkwkkw

A. eliminasi permasalahan

  1. internet client bermasalah? tidak mungkin. karena doi bisa buka yutub dan web web lain
  2. trafik network server bermasalah, ? tidak mungkin juga. karena itu diakses jam 11 malam, yang begitu di konfirmasi ke pihak provider juga aman.
  3. logic dari aplikasi, ? bisa jadi. mari kita cek untuk memastikan.
  4. utilitas server bermasalah ? bisa jadi, mari kita cek untuk memastikan.

B. cek utilisasi server

kemudian, saya akses server. hal pertama yang dilakukan adalah ketik htop . wkwkw, ini perintah paling lazim dilakukan untuk liat kondisi server.

dan ternyata, benar… resourcenya CPU nya tinggi banget. nah, ada apa ini ? wah wah.. kok bisa. ini yang bikin error disisi usernya

mentok cuk

mentok cuk

wealah, kok bisa ya CPU 16 core mentok. ini server ngapain ya ? seperti sedang dipakai mining Bitcoin ajah, wkwkkw. sek. kok ya jadi kepikiran ya mining Bitcoin pake server, lumayan juga buat nambah asupan gizi dimasa pandemi gini, wkwkwkw. wes wes sadar.

agak aneh bagi saya, dan bagi teman-teman yang saya tanyai. apalagi setelah melihat dari fungsi aplikasi, kegunaan, jumlah user akses, dan logicnya. 16 core VCPU harusnya udah lebih dari cukup.

nah, bagi orang yang panikan, biasanya langsung buru-buru untuk menjustifikasi masalah pada cpu yang penuh, dan harus di tambah, tidak main-main, 4 kali lipat sekaligus. wew, emangnya mau bikin Data Center Bos pakai 64 core ??? 😀 lagian, belum tentu kan masalahnya teratasi ????. tenang, mari kita cari tau masalahnya lebih dalam.

C. cek aplikasi yang memakan resource

ada dua aplikasi yang tertinggi memakan resource dari server tersebut, yang pertama database, yang kedua web server. saya melakukan penangkapan slow query log pada kedua aplikasi tersebut. yang pertama backend web server hasilnya :

Screenshot_2

benar, aplikasi tersebut menggunakan engine php untuk menjalankannya. perlu diingat, php itu bukan akronim dari Pemberi Harapan Palsu , ya.

dari error php tersebut mengarah ke database.

Screenshot_1

benar, satu query di eksekusi sampai dengan 15 -20 detik, panteslah error disisi clientnya TCP error.karena server gagal melayani permintaan dari client.

sampai disini, sysadmin harus berkomunikasi dengan Programmer dan Database Engineer. harus ada hubungan yang harmonis antara ketiga elemen tersebut.

hubungan ini tidak akan terjadi jika sebuah project hanya di handle oleh satu orang saja. biasa di sebut Full Stack Developer. dia programmernya, dia database enginernya, dia juga sysadminnya. bisa mabok darat doi. wkwkwkw

sysadmin menanyakan kepada Database engineer, apakah query pada aplikasi sudah di sederhanakan secara maksimal. jika jawabannya sudah, namun masih terdapat error slow query log. maka harus mencari penyebab lainnya.

D. pengecekan di sisi perangkat.

pengecekan dilanjutkan disisi perangkat. yang berhubungan dengan itu adalah perangkat Input Output. ada dua, NIC dan Disk. saya cek NIC terlebih dahulu. setelah di cek, NIC dalam kondisi baik. NIC dengan 10 Gbps dapat dilewati dengan mulus oleh data-data yang di transfer.

kemudian say cek Disk. untuk cek disk, bisa menggunakan hdparm, fdisk, dll, banyak toolsnya, disini saya menggunakan fio. yaitu aplikasi untuk mengecek Read & Write pada Disk. dan, setelah di cek ini hasilnya :

iops

iops

FYI, server ini masih menggunakan HDD , IOPS segitu untuk digunakan aplikasi yang trafik dan Read Write datanya tinggi, sangat jelek, bahkan bisa dikatakan jeblok. lihat saja Readnya, hanya 38.

beberapa orang yang pasrah dengan keadaan, maksudnya ya hanya punya server itu dan gak mungkin upgrade, maka akan mengakali dengan memecahnya menjadi banyak bagian aplikasi pada server.

untuk aplikasi, bisa menggunakan teknologi kekinian yang biasa di kenal Microservices. bisa di baca disini : https://medium.com/codelabs-unikom/microservices-apaan-tuh-b9f5d56e8848

untuk database, bisa upgrade ke yang lebih mumpuni untuk pengolahan data besar, Postgresql, atau Monggo DB lebih sangat bagus. setelah itu di cluster. Read dan Write database di pisah, menggunakan Proxy. pasti akan jadi pekerjaan berat nan keren. ya gimana lagi, adanya server itu. wkwkwkw

solusi yang kedua, upgrade SSD, maka masalah IOPS beres. begini penampakan IOPS yang menggunakan SSD

iops2

jauh banget kan ya ? hehehe

oke. lanjut.

pada kasus ini, server sudah upgrade menggunakan SSD, dan ternyata, aplikasi sudah beres, aman dan kenceng.

coba deh di lihat CPU nya, pasti tidak load mentok lagi. karena query yang di Read dan Write di Dsik tidak antri, tidak lama lagi waktunya, otomatis, CPU juga tidak bekerja keras lagi. dan loadnya menurun.

sampai disini saya tidak cek server lagi dari sisi sistem Operasi, karena sudah di handle oleh sysadminnya. saya hanya menyediakan SSD.

jadi, tidak perlu upgrade CPU kan ? bayangkan saja jika harus upgrade CPU, larang regone Rekkkkkk. dan kerjaannya ribet Rekkkk. kudu backup data, matiin server, bongkar, halah, mumet. semetara aplikasi diburu kudu running dan yang lebih kacau, bisa jadi setelah upgrade CPU masalah tidak teratasi.

Mal Praktek Rekkkk jenenge neng dunia kedokteran. 😀

yoweslah, sekian aja, yang penting client udah tersenyum lebar karena aplikasinya udah aman. disitu saya merasa dipuasin oleh client . walaupun clientnya LANANGAN.

Bagikan saja, itu tidak berat

High avaibility moodle server using nginx load balancer and nfs server

nah loh, judulnya pakai bahasa inggris , yaitu High avaibility moodle server using nginx load balancer and nfs server , biar keren aja sih, karena saya akan tetap menulisnya dalam bahasa indonesia, saya kan cinta negeri ini, hehehe

oiya, hari ini saya sedang cukup bahagia, sebabnya saya iseng-iseng cek judul artikel, eh, muncul di page one nya google. gimana gak bahagia coba, artikel saya bersaing paling banyak di lihat dengan website-website kelas kakap di dunia. hahaha.

http://mandrivaputri.info

http://mandrivaputri.info

artikel yang mana ? yang ini http://mandrivaputri.info/2018/07/cara-load-balancing-web-server-dengan-haproxy-dan-glusterfs/

nah, artikel yang saya tulis ini adalah sambungan dari artikel diatas, hanya berbeda metode dan kebutuhan. maksudnya tetap sama.

selamat membaca dan selamat berbahagia untuk kalian yang sedang berlibur panjang dengan keluarga. salam hangat dari saya yang tersandar sendirian di kamar kosan. apalah daya, keluarga jauh. semoga harapan kita semua bisa tercapai 🙂 🙂 🙂 🙂 🙂 😉 😉 🙁 🙁 ;'(

jadi, saya mendapatkan tugas, ya sekalian saya anggap sebagai tantangan, sejauh mana kemampuan otak dan tenaga saya mampu menyelesaikan tugas tersebut.

tugasnya adalah : membangun dan mengoptimasi website learning manajement system dengan moodle

sebelumnya, website ini sudah ada, tapi diaksesnya lambat, dan terdapat beberapa trouble yang lumayan bikin bingung untuk mengatasinya.

sebelum melakukan aksi, terlebih dahulu saya menggali informasi tentang aplikasi tersebut, khususnya user akses. yang perlu di ketahui adalah :

  1. berapa banyak user yang akan mengakses aplikasi tersebut ?
  2. apakah random, atau concurrent ?
  3. berapa besar BW internet yang tersedia?
  4. berapa besar resource server yang tersedia ?

dari analisa diatas, dapat dihitung kebutuhannya. misalnya BW yang dibutuhkan, jumlah core CPU, jumlah RAM dan disk. disini saya memutuskan awal menggunakan total RAM 15 GB , CPU 4 core pada setiap server.

setelah melakukan analisa, saya mulai mengeksekusi tugas tersebut. oh, hal ini yang dinamakan analis sistem. tugasnya seorang sistem analis, tapi pada kasus kebanyakan, yang analis juga yang mengeksekusi, wkwkwkw. ya gapapalah, yang penting nambah ilmu, minimal jadi portofolio kali aja saya ditendang dari sini dan pindah ke tempat baru hahahaha

solusi dari permasalah diatas adalah saya menawarkan load balancing server. karena menggunakan moodle, yaitu sebuah aplikasi open source, maka kita tidak terlalu banyak bisa mengoptimasi sari sisi codingnya.

nah, mahalnya disini. ketika ada solusi. 😀 , kalau eksekusi kan hanya tinggal jalankan saja.

load balancing adalah membagi beban aplikasi yang di distribusikan ke beberapa server. 

begini diagramnya.

begini diagramnya.

metode diatas menggunakan tiga buah server apps, satu buah server load balancer, satu buah server database, dan satu buah server NFS. akan lebih baik jika server databasenya juga ada tiga, di cluster. tapi ya itu nantilah, dipengembangan berikutnya, dan seberapa penting ini aplikasi digunakan :p

senjata yang saya gunakan adalah :

  1. nginx
  2. nfs
  3. postgresql
  • server load balancer IP 192.168.85.10
  • server A IP 192.168.85.1
  • server B IP 192.168.85.2
  • server C IP 192.168.85.3
  • server NFS IP 192.168.87.3
  • server database IP 192.168.87.4

A. install dan konfig server load balancer

yang pertama adalah instalasi nginx load balancer pada server load balancer. ini instalasi nginx seperti biasa, hanya script untuk configurasinya menggunakan load balancer dengan metode round robind. yang pernah kuliah harusnya tau nih :p . ada beberapa metode, seperti least conn, ya tergantung kebutuhan aja sih, silangkan di explore.

ant@loadbalancer:~$ yum update -y

ant@loadbalancer:~$ yum install -y nginx

ant@loadbalancer:~$ systemctl enable nginx

ant@loadbalancer:~$ systemctl start nginx

ant@loadbalancer:~$ systemctl status nginx

 

nginx

nginx

membuat script configurasi vhost pada nginx

ant@loadbalancer:~$ vi /etc/nginx/conf.d/loadbalancer.conf

isinya :

upstream backend {

server 192.168.85.1;
server 192.168.85.2;
server 192.168.85.3;
}

server {
listen 80;
server_name xxxx.id;
return 301 https://$server_name$request_uri;
location / {
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://backend;
}
}

upstream backendssl {

server 192.168.85.1:443;
server 192.168.85.2:443;
server 192.168.85.3:443;
}

server {
listen 443 ssl;
server_name xxxx.id;
ssl_certificate /etc/nginx/serti/bundle.crt;
ssl_certificate_key /etc/nginx/serti/priv.key;

location / {
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://backendssl;
}
}

 

disini, SSL dari aplikasi akan di handle oleh server loadbalancer.

B. Instalasi nginx pada semua server A,B,C

ant@server-A:~$ yum update -y

ant@server-A:~$ yum install -y nginx

ant@server-A:~$ systemctl enable nginx

ant@server-A:~$ systemctl start nginx

ant@server-A:~$ systemctl status nginx

membuat konfigurasi vhost pada server A,B dan C

server {
listen *:443 ssl;
listen [::]:443 ssl;
root /usr/share/nginx/html/moodle/moodle/;
index index.php index.html index.htm;
server_name 192.168.85.1;

ssl_certificate /etc/nginx/serti/bundle.crt;
ssl_certificate_key /etc/nginx/serti/priv.key;

location / {
try_files $uri $uri/ =404;
}

location /dataroot/ {
internal;
alias /data/moodledata/;
}

location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_index index.php;
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
include fastcgi_params;
proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

}

disini, moodledata diarahkan pada server NFS.

C. instalasi postgresql server.

ant@db-server:~$ rpm -Uvh https://yum.postgresql.org/11/redhat/rhel-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

ant@db-server:~$ yum -y install postgresql11-server postgresql11

ant@db-server:~$ /usr/pgsql-11/bin/postgresql-11-setup initdb

ant@db-server:~$ systemctl enable postgresql-11.service

ant@db-server:~$ systemctl start postgresql-11.service

konfigurasi agar server database postgresql dapat di akses dari luar server. tutorialnya banyak di google, hehe

D. instalasi dan konfigurasi server NFS ke server A,B,C

ant@nfs-server:~$ yum install nfs-utils

ant@nfs-server:~$ mkdir /data/moodledata

ant@nfs-server:~$ vi /etc/exports

/data/moodledata 192.168.85.1(rw,sync,no_root_squash,no_all_squash)
/data/moodledata 192.168.85.2(rw,sync,no_root_squash,no_all_squash)
/data/moodledata 192.168.85.3(rw,sync,no_root_squash,no_all_squash)

ant@nfs-server:~$ systemtl enable nfs-server

ant@nfs-server:~$ systemctl start nfs-server

disini, saya membuat folder /data/moodledata untuk di mount ke server A,B,C

E. mounting disk pada server NFS ke server A,B,C

ant@nfs-server:~$ mkdir /data

ant@nfs-server:~$ mount 192.168.87.3:/data/moodledata /data

tambahkan script ini agar auto mount saat server restart

ant@nfs-server:~$ vi /etc/fstab

192.168.87.3:/data/moodledata /data nfs  defaults    0       0

cek, apakah disk server NFS sudah termount dengan perintah df -h

Screenshot_24

fuih,, capek ya. selanjutnya, siap untuk instalasi moodle nya.

oiya, saya males nulis tutorial install moodle, karena sudah banyak di internet, bisa di pelajari disini : https://docs.moodle.org/39/en/Installing_Moodle

yang perlu diperhatikan pada saat instalasi moodle :

  1. pastikan database sudah di buat di server database postgresql
  2. arahkan moodledata pada folder /data
  3. arahkan database pada IP 192.168.87.4

udah, sekian dulu, kalau tidak berhasil alias gagal, coba di perhatikan gagalnya dimana, atau bisa bertanya pada kolom komentar ya. capek banget saya nulisnya wkwkwkwk.

sekian dulu tulisan tentang High avaibility moodle server using nginx load balancer and nfs server.

sampai bertemu di lain artikel…. :*

 

 

Bagikan saja, itu tidak berat

Postgresql database auto restore

Halo, hari yang lelah, setelah membuat automation dump restore database mariadb/mysql, kali ini membuat script untuk auto dump dan restore untuk database Postgresql.

saya tidak akan mengulang, saya mau merujuk dari artikel saya sebelumnya : http://mandrivaputri.info/2020/08/membangun-data-ware-house-yang-aman/

artikel diatas memang sulit di pahami, karena basic nya saya memang bukan penulis apalagi pengajar, wkwkwkw, tapi setidaknya ini catatan bagi saya jika suatu saat ada pekerjaan serupa, jadi saya bisa lihat lagi dokumentasi saya. atau catatan ini bisa jadi portofolio saya jika saya hendak melamar pekerjaan di tempat lain :p

langsung saja ke script yah, script ini di jalankan di server :

{DATA WARE HOUSE}

yang pertama, kamu pastikan dulu kalau database server untuk postgresqlnya sudah terinstall.

bisa membaca artikel disini : https://computingforgeeks.com/how-to-install-postgresql-12-on-centos-7/

setelah itu, jalankan script dan cronjobnya pada user postgres

[root@db-warehouse ~]# su postgres

bash-4.2$ vi importpostgre.sh
#import db postgre
echo “halo bos”
dropdb database
createdb database
echo “buat db selesai”
cd /home/postgre/db
tar -xf *.tar.bz2
echo “extrac rampung”
rm -rf *.tar.bz2
echo “tar bz sudah di hapus”
for i in `find /home/postgre/db -type f -ctime -1`
do
psql database < $i
done
cd /home/postgre/db
rm -rf *
echo “rampung”

nah, jadi seperti itu scriptnya. jalankan di cronjob pada user postgres.

bash-4.2$ crontab -e

ya pokoknya gitulah, hehehe :*

Bagikan saja, itu tidak berat