Pertanyaan ini jarang muncul begitu saja. Server melambat, penyedia hosting mengirim surat soal lalu lintas keluar, atau di kotak surat ada pemberitahuan login yang tidak pernah Anda lakukan. Setelah itu bagian yang tidak menyenangkan dimulai: tidak jelas apa yang harus dilihat dan dalam urutan apa, dan naluri pertama — hapus semuanya lalu pasang ulang — hampir selalu terlalu tergesa-gesa.

Di bawah ini adalah urutan pemeriksaan yang memakan sekitar dua puluh menit dan pada sebagian besar kasus memberi jawaban yang jelas. Ia bergerak dari yang paling murah ke yang paling mahal: pertama yang langsung terlihat, lalu yang harus dibandingkan dengan suatu acuan.

Langkah satu: siapa yang login

Mulailah dari login. Kalau ada orang lain yang masuk, hampir pasti ia masuk lewat SSH, dan jejaknya masih ada.

last -20
lastb | head -20
who

last menampilkan login sukses terakhir, lastb yang gagal, dan who siapa yang terhubung saat ini. Yang penting bukan jumlahnya melainkan bentuknya. Ribuan percobaan gagal dari alamat yang tidak pernah kembali adalah latar belakang biasa; itu berjalan tanpa henti terhadap setiap alamat publik dan tidak berarti apa-apa.

Yang perlu dikhawatirkan adalah hal lain:

  • login sukses dari alamat yang tidak ditempati siapa pun dari pihak Anda;
  • login dengan nama pengguna yang tidak pernah Anda buat;
  • percobaan gagal terhadap nama yang benar-benar ada di mesin ini — artinya seseorang sudah mengetahui daftar pengguna Anda alih-alih menjajal kamus;
  • sesi yang terbuka sekarang yang tidak Anda buka.

Periksa terpisah apakah ada kunci asing yang muncul. Berkas ~/.ssh/authorized_keys adalah cara bertahan yang paling umum: kata sandi boleh diganti sesering apa pun, kuncinya tetap ada.

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

Setiap baris di sana adalah akses milik seseorang. Kalau Anda tidak bisa mengatakan milik siapa, anggap itu milik orang lain.

Langkah dua: apa yang berubah di sistem

Penyusupan hampir selalu meninggalkan jejak di disk: berkas biner yang diganti, satu baris tambahan di berkas konfigurasi, berkas baru di direktori server web. Memeriksanya dengan mata adalah sia-sia — perlu acuan pembanding.

Di Debian dan Ubuntu acuan itu sudah tersedia: setiap paket tahu checksum berkas-berkasnya sendiri.

sudo apt install debsums
sudo debsums -c

Perintah ini mendaftar berkas yang berbeda dari yang dipasang distribusi. Sebagian temuan akan sah — berkas konfigurasi di /etc memang ada untuk diubah. Tetapi berkas eksekusi yang berubah di /usr/bin, /usr/sbin atau /bin pada server yang tidak pernah Anda sentuh dengan tangan adalah perkara yang sama sekali berbeda.

Sumber kedua adalah berkas baru di tempat yang seharusnya tidak ada yang baru. Sebuah web shell biasanya duduk di direktori unggahan dan terlihat seperti berkas .php yang tak berbahaya:

find /var/www -type f -name '*.php' -mtime -14 -ls

Empat belas hari hanyalah titik awal; gunakan rentang waktu yang Anda yakin tidak menerbitkan apa pun.

Langkah tiga: apa yang keluar

Server yang sudah dikuasai jarang dibobol demi dirinya sendiri. Ia dipakai: untuk mengirim spam, menambang, menjangkau jaringan lain, menampung berkas orang lain. Semua itu menciptakan koneksi keluar yang sebelumnya tidak ada.

ss -tulpn
ss -tp state established

Perintah pertama menunjukkan apa yang sedang mendengarkan, yang kedua apa yang terhubung saat ini. Bacalah kolom prosesnya. Yang memunculkan pertanyaan: proses asing yang mendengarkan di 0.0.0.0; koneksi keluar ke port tinggi di alamat yang tidak ada urusannya dengan aplikasi Anda; dan yang terutama, proses yang dijalankan dari /tmp atau /dev/shm — tidak ada yang sah berjalan dari direktori itu.

Sekalian lihat beban sistemnya. Penambang membuka dirinya sendiri dengan membuat prosesor sibuk terus-menerus pada situs yang sama sekali tidak populer.

Kalau tandanya sudah muncul

Dorongan pertama adalah cepat-cepat membersihkan: hapus kunci asing, hentikan proses, hapus berkas. Jangan — bersamaan dengan itu Anda menghancurkan justru hal yang nantinya bisa menjelaskan bagaimana mereka masuk. Dan kalau itu tetap tidak jelas, mereka akan kembali, mungkin besok juga.

Urutan yang menyelamatkan data sekaligus gambaran keseluruhan:

  1. Ambil snapshot disk di penyedia kalau tersedia. Ini satu-satunya langkah yang tidak bisa diulang kemudian.
  2. Putuskan mesin dari jaringan, atau tutup semuanya kecuali IP Anda — tetapi jangan matikan. Mematikan menghilangkan daftar proses dan koneksi terbuka, dan itu separuh bukti.
  3. Salin log keluar dari mesin: /var/log/auth.log, log server web, keluaran tiga perintah di atas.
  4. Dan baru sekarang cari tahu bagaimana mereka masuk.

Pemasangan ulang yang bersih adalah akhir yang benar kalau akses diperoleh dengan hak root. Tidak ada pembersihan yang menjamin tidak ada sesuatu yang tertinggal. Tetapi memasang ulang tanpa memahami penyebabnya tidak ada gunanya: Anda akan menaruh lubang yang sama ke sistem yang baru.

Agar pertanyaan ini tidak datang tiba-tiba

Semua di atas adalah pemeriksaan manual sekali jalan, dan ia menjawab pertanyaan «apa yang sedang terjadi sekarang». Masalahnya, pertanyaan itu biasanya diajukan terlambat: ketika penyedia sudah menulis surat atau situs sudah tumbang.

Setiap pemeriksaan itu ada sebagai perkakas terpisah yang bisa mengawasi terus-menerus: login gagal — fail2ban, perubahan berkas — AIDE, integritas paket — debsums, port terbuka — snapshot ss secara berkala. Memasangnya satu per satu tidak sulit; yang sulit adalah membiasakan diri masuk setiap hari untuk membaca enam keluaran berbeda, dan karena itulah dalam praktiknya tidak ada yang membacanya.

Makna sebuah panel yang mengumpulkan semuanya justru terletak di situ: data yang sama, tetapi pada satu halaman dan dengan riwayat, sehingga «kemarin tidak begini» terlihat dengan sendirinya tanpa perlu dicari khusus. Halaman demo di bawah menunjukkan bagaimana tampilannya ketika dirangkai.