pada blog kali ini aku akan membahas snort. Snort adalah sistem deteksi intrusi jaringan Open Source yang diciptakan oleh pendiri Sourcefire dan mantan CTO Martin Roesch. Cisco kini mengembangkan dan mengelola Snort. Sumber: https://en.wikipedia.org/wiki/Snort_(software)

Apa itu Snort?

Snort disebut sebagai packet sniffer yang memantau lalu lintas jaringan, memeriksa setiap paket secara saksama untuk mendeteksi muatan berbahaya atau anomali yang mencurigakan. Sudah lama menjadi yang terdepan di antara alat pencegah dan deteksi intrusi perusahaan, pengguna dapat mengompilasi Snort di sebagian besar sistem operasi (OS) Linux atau Unix. Versi Snort juga tersedia untuk Windows. tapi pada blog ini aku akan membahas snort pada linux saja.

Bagaiamana cara kerja snort?

Snort didasarkan pada library packet capture (libpcap). Libpcap adalah alat yang banyak digunakan dalam tcp/IP address traffic sniffer, content search and analyzer untuk pencatatan paket, analisis lalu lintas waktu nyata, analisis protokol, dan pencocokan konten.

Pengguna dapat mengonfigurasi Snort sebagai sniffer, pencatat paket — seperti TCPdump atau Wireshark– atau metode pencegahan intrusi jaringan.

ok baik itu saja teori nya, langsung saja praktek. silahkan sediakan komputer, server virtual (bisa public atau lokal) dan internet yang cepat.

Install SNORT dan konfigurasi

pertama-tama install snort.

apt install snort -y

maka akan terinstall snort versi 2.9.x.x. kemudian setelah itu buka file bernama /etc/snort/snort.debian.conf kemudian isi variabel DEBIAN_SNORT_OPTIONS dengan value -A full. Maka jadinya seperti ini:

untuk menjalankan snort bisa dua mode, yaitu mode console dan mode background running.

untuk background running bisa menggunakan perintah berikut:

snort -c /etc/snort/snort.conf -l /var/log/snort/ -K ascii -D

untuk running sebagai console

snort -A console -c /etc/snort/snort.conf -i eth0 -v

Keterangan perintah

pada blog ini aku jalan snort mode background.

Dasar Menulis Rules

Snort mendeteksi berdasarkan rule atau aturan yang di buat. Didalam snort sudah banyak rule yang bisa digunakan (file rule ada pada /etc/snort/rule) tetapi kali ini aku membuat rule atau aturan sendiri. Pertama-tama format rule, format rul seperti ini:

action protocol address port direction address port (rule option)

Format rule Snort terdiri dari beberapa bagian, yaitu action, protocol, address, port, direction, address, port, dan rule options. Berikut penjelasan rinci untuk masing-masing bagian:

1. Action

Menentukan tindakan yang dilakukan Snort ketika mendeteksi kecocokan dengan aturan. Contoh tindakan:

• alert: Menghasilkan alert atau notifikasi.
• log: Merekam paket ke dalam file log.
• pass: Mengabaikan paket.
• drop: Menjatuhkan paket (hanya pada mode inline).
• reject: Menolak koneksi dan memberi tahu pengirim.
• sdrop: Menjatuhkan paket tanpa mencatatnya

2. Protocol

Menentukan protokol jaringan yang diperiksa. Contoh protokol:

• tcp: Untuk lalu lintas TCP.
• udp: Untuk lalu lintas UDP.
• icmp: Untuk pesan ICMP.
• ip: Untuk semua lalu lintas IP.

3. Address (Sumber dan Tujuan)

Menentukan alamat sumber dan tujuan paket. Format:

• Alamat IP spesifik: 192.168.1.1
• Subnet: 192.168.1.0/24
• Semua alamat: any
• Negasi: !192.168.1.0/24 (alamat yang tidak termasuk subnet ini).

4. Port (Sumber dan Tujuan)

Menentukan port sumber atau tujuan. Format:

• Port spesifik: 80
• Rentang port: 8000:9000
• Semua port: any
• Negasi: !80

5. Direction

Menentukan arah lalu lintas yang diperiksa:

• ->: Dari alamat sumber ke tujuan.
• <-: Dari alamat tujuan ke sumber.
• <>: Dua arah (bidirectional).

6. Rule Options

Dibungkus dalam tanda kurung () dan berisi kriteria tambahan serta tindakan saat aturan cocok. Beberapa elemen dalam rule options:

• msg: Pesan yang ditampilkan saat aturan cocok.
  Contoh: msg:"Possible SQL Injection";
• sid: ID unik aturan.
  Contoh: sid:1000001;
• rev: Revisi aturan.
  Contoh: rev:1;
• content: String konten yang dicari dalam paket.
  Contoh: content:"SELECT";
• threshold: Mengontrol frekuensi notifikasi.
  Contoh: threshold:type limit, track by_dst, count 1, seconds 60;

Contoh aturan snort untuk mendeteksi permintaan GET dan POST:

Penjelasan aturan GET

Penjelasan aturan POST

Deteksi Serangan DDOS

buka file /etc/snort/rules/local.rules untuk membuat rule sendiri atau kustom:

alert tcp any any -> $HOME_NET 80 (flags: S; msg:"Serangan DDOS"; detection_filter: track by_dst, count 10000, seconds 60; sid:1000002;)

Penjelasan rule:

setelah rule di tulis, jalan service snort dengan perintah systemctl start snort kemudian jalankan snort di latar belakang snort -c /etc/snort/snort.conf -l /var/log/snort/ -K ascii -D. Setelah itu log kita bisa watch file alert nya di /var/log/snort/alert. Jika ingin melihat secara real-time gunakan perintah beritkut watch -n 1 tail /var/log/snort/alert.

Uji Coba Serangan Deteksi DDOS

gunakan hping:

hping3 -S -p 80 -d 120 --flood <IP target>

Penjelasan perintah:

setelah perintah hping di jalankan, maka pada monitor file alert, akan seperti ini:

dari file alert ini, bisa di integrasikan dengan bot telegram untuk notifikasi serangan ke admin. seperti ini contohnya:

Sekian terima kasih sudah membaca sampai akhir, semoga ilmu nya bermanfaat untuk keperluan mu

Artikel Implementasi Snort Pada Real Publik Server pertama kali tampil pada Bhineka blog.

Cerita nya diawali di grub Developer….

ya begitulah cerita nya, di pagi hari dapat rejeki bantuin sesama menggunakan skill yang aku kuasai, hahaha.

setelah aku hubungi yang bersangkutan, aku minta akses vps, dengan baik hati mereka memberikan akses vps, langsung aku gas lah hahaha….

hal pertama yang aku lakukan yaitu mengecek log webserver, website menggunakan webserver nginx dan log nya berada pada direktori /var/log/nginx/access.log.

setelah dilakukan pengecekan ternyata benar website mereka diretas. dan kemungkinan website aplikasi mereka mempunyai celah keamanan arbitrary file upload.

setelah memastikan, langsung aku upload sebuah scanner webshell di domain utama nya dan aku langsung disuguhi webshell hacker berserta index judol mereka,

sesudah itu aku mencari keyword fungsi dari webshell seperti eval, goto, rot13, set_time_limit, fopen, copy, $_files dan hasilnya aku mendapatkan list index judol dan webshellnya.

Hasil yang di dapatkan langsung aku laporkan ke bersangkutan, untuk mereka tindak lanjut dan tidak lupa juga aku berikan mitigasi keamanan.

ok sekian terima kasih, maaf jika banyak sensor karna yang bersangkutan ingin privasi mereka tetap terjaga! happy friday guyss….

Artikel Memberantas Index Judol Dan Webshell Hacker pertama kali tampil pada Bhineka blog.

jadi langsung saja saya login ke VPS-nya dengan  menggunakan user root karena memang beberapa kali server dia ini jebol karena memang didalamnya terdapat banyak sekali domain dan sempat dulu juga saya juga ikut membantu handle dan melakukan restorasi.

Hal pertama pada saat melakukan Incident Response kita fokus pada LOG, karena ini adalah operating sistem linux dan kebetulan yang sudah integrasi dengan cpanel jupiter jadi semua access log webserver itu disimpan pada directory /etc/apache2/logs/domlogs/ dan karena kata teman saya ini curiga mereka pegang akses root jadi untuk mem-validasi kita bisa menggunakan command last 

Dan disini jika dilihat lastlogin pada IP address yang menggunakan user root aman atau tidak ada IP lain selain IP address yang memang wewenang pada VPS tersebut jadi bisa dipastikan attacker tidak mendapatkan akses root. untuk  selanjutnya kita akan lebih fokus pada analisys untuk mengetahui attacker masuk dari mana dan backdoor apa saja yang mereka upload di server.

Karena memang beberapa website di build menggunakan PHP dengan tech stack laravel dan CMS wordpress, jadi saya langsung melakukan filtering file yang mempunyai indikasi backdoor dengan menggunakan find command

Terlihat dari outpunya banyak sekali PHP backdoor yang sudah di tebar oleh attacker dan pada saat dilakukan scanning dari md5 checksum pada salah satu backdoor hasilnya banyak sekali resultnya

hall ini bisa kita jadikan acuan pada saat melakukan log analisys, karena attacker menebar PHP backdoor / webshell memiliki pola yang sama yaitu diletakkan pada direktori /.well-known/463asda646d/ dan sepertinya attacker menggunakan auto mass generate unutk membuat folder serta file index.php

masuk pada directory /etc/apache2/logs/domlogs/namauser untuk monitoring access log / request pada webserver karena banyaknya domain kita tidak mungkin cek satu persatu jadi kita langsung saja filter request hanya pada path ‘/.well-known/463asda646d/index.php‘ dan ditemukan salah satu domain yang pertama kali infected anggap saja domain.xyz karena jika dilihat dari timestampnya attacker pertama kali akses pada 26/Sep/2024 jam 07:43:44 pagi

kita disini akan fokus pada domain.xyz karena dari IOC(indicator of compromised) attacker masuk melalui domain tersebut, jadi kita akan cek archive lognya pada 26 september pagi yang berada pada directory /home/log/ dan ada file yaitu domain.xyz.-Sep-2024.gz dan domain.xyz.-ssl_log-Sep–2024.gz dimana perbedaan dari 2 file tersebut yaitu pada file ssl_log request dari client menggunakan https atau TLS begitupun sebaliknya

disini setelah saya melakukan filterin dan greping menemukan IP yang mencurigakan yaitu 104.28.215.133 yang mengakses endpoint /wp-content/plugins/aa3d742778e9f335ec234e10ac868df1/get_index.php dengan response status 200

nah disini kita menemukan data yang berharga atau kalo dalam digital forensic disebut sebagai artifact, nah kita sudah menemukan salah satu IP attacker disini kita bisa dengan mudah identifikasi dari IP address tersebut pada log file

dan pada saat melihat accessnya pada IP 104.28.215.133 yaitu pertama dia melakukan request ke wp-login dan kemudian melakukan redirect ke endpoint wp-admin/plugin-install.php

Disini saya langsung konfirmasi pada teman saya, yaitu bagaimana dia melakukan konfigurasi pada wordpress dan apakah theme/plugin yang di install bersifat nulled serta bagaimana passhprase credentialnya apakah rumit atau tidak dan yang mengejutkan disini kata dia wordpress pada domain tersebut belum digunakan dan hanya hasil dari extract sebuah wp zip tanpa melakukan konfigurasi apapun.

sempet berfikir bagaimana attacker ini mendapatkan akses, setelah menghabiskan satu batang rokok akhirnya terfikir yaitu jika wordpress tanpa konfigurasi memang bisa user melakukan manual installation yaitu dengan mengakses pada endpoint wp-admin/setup-config.php jadi disini saya menggali lebih dalam pada log file yang ada

dan benar saja asumsi tadi disini attacker memperoleh initial access dengan melakukan default installation pada wordpress sekitar jam 7 pagi dan disitu juga terlihat ada request ke /index.php/2024/09/26/hello-world/ dimana page hello-world merupakan default page dari wordpress saat selesai instalasi

Disini terlihat timestamp pada file wp-config.php di jam 07:07 pagi bisa diambil kesimpulan jika analisys pada log file tersebut valid. Disini bagaimana attacker bisa melakukan instalasi tanpa mengetahui credential database yaitu dengan membuat suatu instance remote mysql pada server C2 mereka

Terlihat pada IP 194.163.155.171 dan port 443 yang merupakan remote database dari server attacker, attacker sangat cerdik dimana seharusnya request ke port selain 80 dan 443 di block oleh outbound firewall dari sini attacker melakukan setup MySQL pada port 443 yang digunakan untuk bypass pada firewall

pada saat dilakukan enumeration dan banner grabbing menggunakan nmap, benar saja di server attacker, port 443 running service MySQL

Kesimpulan

disini kita sudah membahas bagaimana melakukan Incident Response pada suatu server yang compromised, melakukan Incident Response sendiri bisa sulit bisa juga mudah tergantung dari setup server, banyaknya database, service dan juga bagaimana konfigurasi-nya bahkan ada tim khusus untuk melakukan hal semacam ini. Tetapi hal-hal seperti ini wajib dikuasai oleh sysadmin atau devops engineer dan orang-orang yang memang bertugas untuk menghandle suatu server dan teruntuk developer pastikan untuk selalu melakukan pendekatan keamanan pada source code yaitu dengan melakukan secure coding dan menerapkan best-practice dari tech stack yang digunakan. dan jangan lupa terus belajar dan melakukan eksplorasi

“Learning is never done without errors and defeat.” -Vladimir Lenin

Artikel Incident Response Pada Suatu Server Yang Compromised pertama kali tampil pada Bhineka blog.