DEV Community: Raghavvram Johnson

Yara Rule (Malware Detection)

Raghavvram Johnson — Fri, 30 Oct 2026 17:23:40 +0000

RegEx in Yara

==Yes, regular expressions are fully supported in YARA==.

How to Use Regex in YARA

In a YARA rule, regular expressions are defined inside the strings section by enclosing them in forward slashes (/) instead of double-quotes:

rule ExampleRegexRule {
    strings:
        $re1 = /md5: [0-9a-fA-F]{32}/
        $re2 = /state: (on|off)/
    condition:
        $re1 and $re2
}

Supported Modifiers

You can attach string modifiers to your regular expressions:

nocase or the i flag (placed after the closing slash, e.g., /foo/i): Ignores case.
s flag (e.g., /bar./s): Allows the dot (.) character to match newline characters.
ascii and wide: Matches ASCII or UTF-16/wide-character equivalents.
fullword: Ensures the match is not preceded or followed by an alphanumeric character.

Limitations of YARA's Engine

YARA uses its own internal regular expression engine (rather than full PCRE), which has a few important constraints: [1]

No capture groups: You cannot use backreferences or group-capturing features.
No POSIX character classes: Classes like [[:alpha:]] or [[:digit:]] are not supported (though standard shorthand like \d, \w, and \s work).
No lookaheads / lookbehinds: Features like negative lookahead ((?!...)) are not supported and will trigger compilation errors.
Performance impact: Overly broad regex patterns (especially leading wildcard patterns like .*) can slow down scanning speeds because YARA has to evaluate them across the target file or memory space.

Wildcard in Yara Strings

In YARA (a tool used for malware research and pattern matching), the question mark (?) acts as a wildcard that matches any single byte in a hexadecimal string pattern.

Example Usage in Hex Strings:

01 ? 03: Matches a sequence starting with 01, followed by any single byte, and then 03.
AA ?? CC: Matches AA followed by any two individual wildcard bytes, and then CC.

Yara for Memory Analysis

Using YARA for memory analysis ==allows you to scan RAM dumps, live processes, or memory images for malicious signatures, injected code, and fileless malware==.

Step 1: Acquire a Memory Dump

Before YARA can scan memory, you need to capture a snapshot of the target system's RAM:

Windows/Linux/macOS: Use dedicated memory acquisition tools like WinPMem, Volatility (vmem/raw dumps), DumpIt, or LiME (Linux Memory Extractor) to save physical memory to a file (e.g., memory.dmp or ram.raw).
Live Process Scanning (Direct): On supported endpoint protection agents (such as Trend Micro Apex Central), you can run YARA memory scans directly on active processes without manually dumping the full disk/RAM image first.

Step 2: Write or Obtain a YARA Rule

A YARA rule consists of metadata, pattern strings (text, hex, or regular expressions), and a matching condition:

rule Detect_Suspicious_Memory_Pattern {
    meta:
        description = "Detects injection or malicious strings in memory"
        author = "Analyst"
        date = "2026-03-31"
    strings:
        $cmd = "cmd.exe /c powershell" ascii wide
        $hex_pattern = { 4D 5A 90 00 03 00 00 00 } // DOS/PE header or shellcode
    condition:
        any of them
}

Step 3: Run YARA Against a Memory Dump

You can run the standard YARA command-line tool directly against a raw memory dump file:

yara -s /path/to/rule.yar /path/to/memory.dmp

-s: Prints the matching strings found inside the memory dump.
-p <number>: Sets the number of threads to speed up large memory image scans.

Step 4: Use YARA with Memory Forensics Frameworks (E.g., Volatility)

Frameworks like Volatility include built-in plugins to run YARA signatures directly against virtual address spaces or physical memory pages:

In Volatility 3: Use the yarascan plugin to search a memory image for matches:

vol -f memory.dmp windows.yarascan.YaraScan --yara-file /path/to/rule.yar

This scans process memory spaces, kernel memory, and unallocated slack space, outputting the exact virtual addresses, process names (e.g., svchost.exe), and matching rule names.

Best Practices for Memory Analysis

Account for Volatility/Structure: Memory is fragmented. Strings might be split across page boundaries, or encoded (XOR/Wide-char ASCII/UTF-16). Use modifiers like wide and ascii in your YARA string definitions.
Filter by Process: Cross-reference YARA memory hits with process lists (pslist or netscan in Volatility) to confirm whether the matched memory region belongs to a legitimate service or a rogue/injected process.
Tune for False Positives: Raw RAM contains vast amounts of normal application data; keep conditions specific to avoid noise from common strings.

Sigma Rule (Detection Logic)

Raghavvram Johnson — Fri, 30 Oct 2026 17:20:50 +0000

A Sigma rule is ==a generic, open-source YAML format used in detection engineering to describe suspicious security events in a log-source-agnostic way==. It acts as a universal signature—like Snort for network traffic or YARA for files—allowing defenders to write a detection once and automatically translate it into SIEM queries like Splunk, Microsoft Sentinel, or Elastic.

Core Structure of a Sigma Rule

A standard Sigma rule is divided into several mandatory and optional key-value blocks in YAML:

1. Header (Metadata)

Provides context, administration, and tracking details for the rule.

title: Short, human-readable name of the rule.
id: Unique GUID/UUID used to track the rule over time.
status: Maturity level (e.g., experimental, test, stable, deprecated).
description: Detailed explanation of what behavior or adversary TTP the rule targets.
author: Creator or contributor name.
date / modified: Creation and update timestamps.
references: Links to threat intelligence reports, blog posts, or analysis.
tags: Categorization tags, commonly mapping to MITRE ATT&CK tactics and techniques (e.g., attack.execution, attack.t1059.001).
level: Severity rating (e.g., low, medium, high, critical).
falsepositives: Known benign activities or administrative tools that might trigger false alerts.

2. Log Source (`logsource`)

Tells the translation backend which logs or platforms the rule applies to.

category: High-level log type (e.g., process_creation, network_connection, file_event).
product: Operating system or application (e.g., windows, linux, aws).
service: Specific service or channel (e.g., security, sysmon, dns).

3. Detection Block (`detection`)

The core logic defining what patterns, strings, or field values to look for. It consists of individual search statements (selections or filters) combined via a boolean condition.

Selections (Lists / Dictionaries):
- Lists (YAML arrays [ ]) represent OR logic (matching any item in the list).
- Dictionaries/Maps represent AND logic (matching all key-value pairs simultaneously).
Modifiers: Appended to field names using a pipe (|) to alter string matching behavior:
- contains: Matches substring anywhere in the field.
- startswith / endswith: Anchors the match to the start or end of the string.
- all: Changes a list from OR to strict AND.
- re: Passes the pattern to a regular expression engine. [11]
Condition (condition): Boolean statement that connects selections and filters (e.g., selection and not filter).

4. Output Fields (`fields`)

Specifies which log attributes should be extracted and displayed when an alert triggers (e.g., CommandLine, ParentImage, User).

Example Sigma Rule Skeleton

title: Suspicious PowerShell Download Cradle
id: 12345678-1234-1234-1234-1234567890ab
status: experimental
description: Detects PowerShell executing a download command from a remote URL
author: Detection Engineer
date: 2026/10/27
tags:
  - attack.execution
  - attack.t1059.001
level: high
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'DownloadString'
      - 'IEX '
  filter:
    ParentImage|endswith: '\sccm.exe'
  condition: selection and not filter
fields:
  - CommandLine
  - ParentImage
  - User

The logsource section in a Sigma rule ==defines where and what kind of logs the detection logic should look through==. It acts as a filter so that conversion tools (backends) know which tables, indexes, or log types in your SIEM (like Splunk, Microsoft Sentinel, or Elastic) to target.

The Three Main Fields

The logsource section uses a combination of three primary attributes:

product: Selects the overall software, operating system, or platform family generating the logs (e.g., windows, apache, aws, linux).
category: Selects a standardized, high-level functional type or event class across different products (e.g., process_creation, file_event, firewall, dns).
service: Narrows down the logs to a specific sub-service, daemon, or log channel within that product (e.g., sysmon, sshd, security, application).

How They Work Together (from Broad to Specific)

You do not always have to fill out all three fields. You combine them depending on how specific the rule needs to be:

Broad / Generic Category Only:

logsource:
  category: process_creation

- _Meaning:_ Look for process creation events anywhere it is supported, regardless of the underlying product or OS.

Product + Category:

logsource:
  product: windows
  category: process_creation

- _Meaning:_ Look for process creation events specifically coming from Windows systems. [4]

Product + Service + Category (Most Specific):

logsource:
  product: windows
  service: sysmon
  category: process_creation

- Meaning: Specifically target Windows logs generated by the Sysmon service under the process_creation category (Event ID 1).

Why the Logsource Section Matters

Portability: When you convert a Sigma rule using a translator tool (like sigmac or pySigma), the backend uses logsource to map generic field names (like Image or CommandLine) to the exact schema of your specific SIEM.
Efficiency: It prevents your SIEM from running heavy search queries across irrelevant datasets or indexes.
Standardization: It ensures that whether you write a rule for Linux, Windows, or cloud providers, the target telemetry is clearly labeled and expected.

The detection block in a Sigma rule is ==the core logic section that tells your security system what specific evidence or patterns to look for in log data==.

It acts as the "search brain" of the rule and is broken down into three main parts: selections, filters, and a condition.

1. Selections (What to Find)

What it is: A list of field-and-value pairs or keywords that represent suspicious or specific behavior.
How it works: You pick log fields (like EventID, Image, or CommandLine) and define what values trigger a match.
Example:
```
detection:
  selection:
    EventID: 4625
    TargetUserName: "admin"
```
(This selection looks for a Windows event ID 4625—a failed logon—targeting the username "admin".) [1, 4, 5, 6, 7]

2. Filters (What to Ignore)

What it is: Optional criteria used to exclude normal or safe activity (false positives).
How it works: If a log matches your selection but also matches your filter, it gets dropped so it doesn't trigger a fake alert.

Example:

  filter:
    SourceIpAddress: "192.168.1.100" # Ignore internal scanner

3. Condition (the Boolean Glue)

What it is: A statement that connects your selections and filters using logic like AND, OR, NOT, or parentheses.
How it works: It tells the engine how to evaluate the matches.
Example:
```
  condition: selection and not filter
```
(This triggers an alert only if the selection happens, and the filter does not.)

Simple Analogy

Think of the detection block like setting a security camera rule:

Selection: "Record if anyone wears a ski mask and carries a crowbar."
Filter: "Except if it's Bob from the maintenance crew."
Condition: "If Selection A is true, and Filter B is false -> Sound the alarm."

If you'd like, share a sample Sigma rule or scenario you are working on, and I can help you break down or write its detection block.

In Sigma rules, ==selection defines the specific malicious or suspicious indicators you want to find, while filter removes known false positives or expected benign activity==.

1. Selection

The selection is the core matching logic of a Sigma rule. It tells the SIEM what fields and values to search for in log data.

What it does: Captures suspicious attributes (e.g., a specific command-line argument, a unique registry key, or a rare process name).
Structure: Written as YAML dictionaries (representing logical AND statements) or YAML lists (representing logical OR statements).

Example:

detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: 'EncodedCommand'
  condition: selection

Meaning: Match any event where the Image ends with powershell.exe AND the CommandLine contains EncodedCommand.

2. Filter

The filter (often named filter1, filter_..., or handled via standalone Sigma Filters) narrows down the results by excluding normal, authorized, or repetitive administrative behavior.

What it does: Subtracts or ignores benign events that would otherwise trigger a false positive.
Logic integration: Combined with selections using boolean operators like NOT or and not in the condition line.

Example:

detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: 'EncodedCommand'
  filter:
    User: 'NT AUTHORITY\SYSTEM'
  condition: selection and not filter

Meaning: Find all encoded PowerShell commands, except when run by NT AUTHORITY\SYSTEM (assuming that service account runs safe scripts in your environment).

How They Work Together

Match: The selection grabs a broad or specific bucket of potentially bad events.
Prune: The filter sweeps through that bucket and throws out known-good noise.
Condition: The condition statement ties them together (e.g., selection and not filter) to produce the final alert.

(Note: You can also use separate, modular Sigma Filters in modern pySigma workflows to manage environment-wide exclusions externally without editing the base detection rule).

Here is exactly what happens for each condition, using the security camera analogy (Selection = Someone in a ski mask, Filter = It is Bob the maintenance worker):

condition: selection and not filter

What it means: Trigger an alert only for malicious activity.
What happens: The activity you are looking for must happen (selection), AND it must not be the safe/excluded activity (not filter).
Analogy: "Sound the alarm if someone in a ski mask shows up, and it is not Bob."
Outcome: You catch the real bad guy. Bob can walk by in his ski mask freely.

condition: selection or not filter

What it means: Trigger an alert for almost everything (A dangerous rule).
What happens: The alert fires if the malicious activity happens OR if anything else happens that doesn't match the filter. Because the "not filter" side is true for 99.9% of all normal network traffic, this rule will completely flood your system with fake alerts.
Analogy: "Sound the alarm if someone is in a ski mask, or if the person is not Bob."
Outcome: The alarm goes off constantly for every single employee, customer, and delivery person who is not Bob, regardless of what they are wearing.

condition: selection and filter

What it means: Trigger an alert only when your exception happens.
What happens: The alert fires only when the activity matches the suspicious criteria AND simultaneously matches the exclusion criteria.
Analogy: "Sound the alarm if someone is in a ski mask, and that person is Bob."
Outcome: You are specifically spying on Bob. You will only get an alert when Bob wears a ski mask, while an actual criminal in a ski mask will walk right past the camera undetected.

condition: selection or filter

What it means: Trigger an alert for either behavior.
What happens: The alert fires if the malicious activity happens, OR if the safe/excluded activity happens.
Analogy: "Sound the alarm if someone is in a ski mask, or if Bob walks by (even in his normal uniform)."
Outcome: You catch the bad guy, but you also generate an annoying alert every single time Bob does his normal daily job.

Jenkins Setup in Docker using Docker Compose

Raghavvram Johnson — Mon, 26 Oct 2026 16:57:39 +0000

To run Jenkins in Docker, use the following production-ready docker-compose.yml file. This configuration includes data persistence and mounts the Docker socket so Jenkins can build and run other Docker containers inside your pipelines.

1. The `docker-compose.yml` File

services:
  jenkins:
    image: jenkins/jenkins:lts
    container_name: jenkins
    restart: unless-stopped
    privileged: true
    user: root
    ports:
      - "8181:8080"   # Jenkins Web UI
      - "50000:50000" # Jenkins inbound agents port
    volumes:
      - ./jenkins_data:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock

2. How to Start Jenkins

Create a directory for your project and navigate into it:
```
mkdir jenkins-docker && cd jenkins-docker
```
Save the configuration above into a file named docker-compose.yml.
Start the container in the background:
```
docker compose up -d
```

3. Retrieve the Initial Admin Password

Once the container starts, Jenkins will generate a one-time setup password. Run this command to read it directly from the container:

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Copy the printed code, open your browser to http://localhost:8181, and paste it in to finish your setup.

Host SonarQube Community Edition using Docker Compose

Raghavvram Johnson — Mon, 26 Oct 2026 16:30:18 +0000

The below is a production-ready docker-compose.yml file to spin up SonarQube Community Build alongside a persistent PostgreSQL database.

`docker-compose.yml`

services:
  sonarqube:
    image: sonarqube:community
    container_name: sonarqube
    depends_on:
      - db
    ports:
      - "9111:9000"
    networks:
      - sonarnet
    environment:
      - SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonar
      - SONAR_JDBC_USERNAME=sonar
      - SONAR_JDBC_PASSWORD=sonar_secure_password
    volumes:
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_logs:/opt/sonarqube/logs
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

  db:
    image: postgres:15-alpine
    container_name: sonarqube_db
    networks:
      - sonarnet
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=sonar_secure_password
      - POSTGRES_DB=sonar
    volumes:
      - postgresql_data:/var/lib/postgresql/data

networks:
  sonarnet:
    driver: bridge

volumes:
  sonarqube_data:
  sonarqube_extensions:
  sonarqube_logs:
  postgresql_data:

⚠️ Critical Prerequisite (Elasticsearch Fix)

SonarQube bundles an internal Elasticsearch instance. By default, most host operating systems limit the number of virtual memory map counts, which causes the Sonarqube container to crash immediately on startup.

Before running the compose file, you must run the following command on your host machine to increase this limit:

sudo sysctl -w vm.max_map_count=524288

To make this change permanent, add vm.max_map_count=524288 to your /etc/sysctl.conf file.

How to Start and Access

Start the services in the background:
```
docker compose up -d
```
Wait a minute or two for the database migrations to finish, then navigate to http://localhost:9111 in your browser.
Log in using the default credentials:

Username: admin
Password: admin

You will be immediately prompted to change this default password.

Data handlers (CISSP)

Raghavvram Johnson — Tue, 13 Oct 2026 17:47:19 +0000

Data handlers

1. Data Subject

Who they are: The individual (natural person) to whom the personal data relates. This is the person whose information is being collected, processed, or stored.

What they do: They are the rights-holder under privacy regulations (GDPR, CCPA, etc.). They can exercise rights like access, rectification, erasure, and portability.

Data Lifecycle Stage: Creation/Collection — they are the source of data. They also appear at Disposal when exercising the "right to be forgotten."

CISSP Relevance: Domain 2 (Asset Security) — understanding whose data you protect; Domain 1 (Security & Risk Management) — legal/regulatory compliance.

2. Data Owner

Who they are: A senior-level individual (often a business unit head or C-level executive) who has ultimate accountability for a specific dataset. They "own" the data from a business perspective.

What they do:

Determines data classification and sensitivity levels
Authorizes access and approves data sharing
Ensures data quality and proper use
Bears responsibility for data breaches within their domain

Data Lifecycle Stage: Present across all stages, but most active at Creation/Collection (classification decisions) and Use/Sharing (access authorization).

CISSP Relevance: Domain 2 (Asset Security) — data classification and ownership; Domain 5 (Identity & Access Management) — access control decisions.

3. Data Auditor

Who they are: An independent party (internal or external) responsible for reviewing and verifying that data handling practices comply with policies, standards, and regulations.

What they do:

Conducts audits of data access logs and processing activities
Verifies compliance with data protection regulations
Identifies control gaps and non-compliance
Produces audit reports for management and regulators

Data Lifecycle Stage: Primarily active during Use/Processing and Retention stages, but audits can span the entire lifecycle.

CISSP Relevance: Domain 1 (Security & Risk Management) — governance, risk, and compliance; Domain 7 (Security Operations) — monitoring and auditing.

4. Data Steward

Who they are: Operational-level role responsible for day-to-day management and oversight of data assets on behalf of the Data Owner. They are the "hands-on" custodians.

What they do:

Implements data policies and standards set by the Data Owner
Manages data quality, metadata, and documentation
Handles data access requests and user provisioning
Ensures data is properly labeled, stored, and maintained

Data Lifecycle Stage: Active across all stages, particularly Storage, Use/Processing, and Retention.

CISSP Relevance: Domain 2 (Asset Security) — data handling and maintenance; Domain 5 (Identity & Access Management) — operational access control.

5. Data Controller

Who they are: The entity (person, organization, or authority) that determines the purposes and means of processing personal data. They make the "why" and "how" decisions.

What they do:

Decides what data to collect and for what purpose
Determines legal basis for processing (consent, contract, legitimate interest, etc.)
Bears primary legal responsibility for data protection compliance
Must maintain records of processing activities (ROPA)

Data Lifecycle Stage: Creation/Collection (deciding what to collect and why), Use/Processing (determining how data is used), and Disposal (retention schedules).

CISSP Relevance: Domain 1 (Security & Risk Management) — legal/regulatory compliance; Domain 2 (Asset Security) — data governance.

6. Data Processor

Who they are: An entity that processes personal data on behalf of the Data Controller. They do not decide the purpose or means — they execute the Controller's instructions.

What they do:

Performs operations like storage, retrieval, analysis, or transmission
Must process data only per the Controller's documented instructions
Implements security measures to protect data
Must notify the Controller of breaches
Often requires a Data Processing Agreement (DPA)

Data Lifecycle Stage: Primarily Storage, Use/Processing, and sometimes Sharing (if sub-processors are involved).

CISSP Relevance: Domain 2 (Asset Security) — third-party/vendor risk; Domain 1 (Security & Risk Management) — contractual and legal obligations.

7. Data Custodian

Who they are: The technical/IT professional responsible for the physical and logical protection of data assets. Unlike the Data Steward (business-focused) or Data Owner (accountability-focused), the Custodian is hands-on technical — they manage the systems, infrastructure, and controls that house the data.

What they do:

Implements and maintains security controls (encryption, backups, access controls)
Manages storage infrastructure, databases, and cloud environments
Performs backups, recovery, and disaster recovery operations
Configures and monitors technical access controls (firewalls, permissions, DLP)
Ensures data availability, integrity, and confidentiality at the technical layer
Handles data migration, archiving, and secure deletion

Data Lifecycle Stage: Active across all stages, but most critical during:

Storage — managing where and how data resides
Use/Processing — maintaining system availability and performance
Retention — enforcing retention policies and archival
Disposal — executing secure deletion, degaussing, or destruction

CISSP Relevance:

Domain 2 (Asset Security) — data handling requirements, classification enforcement
Domain 3 (Security Architecture & Engineering) — designing secure storage and processing systems
Domain 7 (Security Operations) — backup, recovery, and monitoring
Domain 5 (Identity & Access Management) — technical access control implementation

How Data Custodian Differs from Data Steward

Aspect	Data Custodian	Data Steward
Focus	Technical protection	Business/data quality
Responsibility	How data is secured	What data means and how it's used
Tasks	Backups, encryption, patching	Metadata, quality rules, access requests
Reports to	IT/Security leadership	Data Owner / Business unit
CISSP Domain	2, 3, 7	2, 5

Simple analogy: The Data Owner is the homeowner, the Data Steward is the property manager who handles tenant rules, and the Data Custodian is the security guard and maintenance crew who physically protect and maintain the building.

Summary Table

Role	Primary Responsibility	Key Lifecycle Stage	CISSP Domain
Data Subject	Rights-holder	Creation/Collection	1, 2
Data Owner	Accountability & classification	All (esp. Creation, Use)	2, 5
Data Auditor	Compliance verification	Use, Retention	1, 7
Data Steward	Operational data management & quality	All stages	2, 5
Data Custodian	Technical protection & infrastructure	Storage, Retention, Disposal	2, 3, 7
Data Controller	Determines purpose & means	Creation, Use, Disposal	1, 2
Data Processor	Executes processing on behalf	Storage, Use, Sharing	1, 2

Apache Kafka

Raghavvram Johnson — Tue, 13 Oct 2026 17:44:33 +0000

Apache Kafka is a powerful open-source distributed event streaming platform designed to handle real-time data feeds. It was originally developed by LinkedIn and is now maintained by the Apache Software Foundation. Kafka is widely used for building real-time data pipelines and streaming applications.

Core Concepts of Apache Kafka

Topics:
- A Kafka topic is a category or feed name to which records are sent by producers.
- Topics are partitioned, meaning each topic can have multiple partitions to allow parallel processing.
- Example: A topic named user_activity could store logs of user actions on a website.
Partitions:
- Each topic is divided into partitions, which are ordered, immutable sequences of records.
- Partitions allow Kafka to scale horizontally by distributing data across multiple brokers.
- Each record in a partition is assigned a unique offset.
Producers:
- Producers are applications that send data to Kafka topics.
- They can specify which partition to send data to or let Kafka decide based on a partitioning strategy.
Consumers:
- Consumers are applications that read data from Kafka topics.
- They can subscribe to one or more topics and process the data in real-time.
Brokers:
- Kafka brokers are servers that store data and serve client requests.
- A Kafka cluster consists of multiple brokers, and each broker is identified by a unique ID.
ZooKeeper:
- ZooKeeper is used for managing and coordinating Kafka brokers.
- It handles tasks like leader election for partitions and storing metadata.
Offsets:
- An offset is a unique identifier for each record within a partition.
- Consumers use offsets to keep track of their position in the topic.
Replication:
- Kafka replicates data across multiple brokers to ensure fault tolerance.
- Each partition has one leader and multiple replicas.

Kafka APIs

Producer API:
- Allows applications to send streams of data to topics.
Consumer API:
- Enables applications to read streams of data from topics.
Streams API:
- Used for building real-time stream processing applications.
Connect API:
- Facilitates integration between Kafka and other systems like databases or file systems.

Bridged, NAT, and Host-Only in Vmware

Raghavvram Johnson — Tue, 13 Oct 2026 17:42:10 +0000

VMware Workstation Pro provides three main default network modes (Bridged, NAT, and Host-Only) along with custom and specialized networking options managed through virtual switches (VMnet interfaces).

Main Network Modes

Bridged Networking (VMnet0)
- How it works: Connects the virtual machine directly to your physical local area network (LAN) using the host's physical network adapter.
- IP address: Receives a distinct IP address directly from your physical router or DHCP server on the same subnet as your host.
- Best for: Running servers, testing network services, or making the VM appear as a separate physical machine on your network.
NAT (Network Address Translation) Networking (VMnet8)
- How it works: Shares the host computer's IP address to access external networks or the internet through a built-in virtual NAT device and virtual DHCP server.
- IP address: Assigned a private IP address by VMware's internal DHCP server; inbound traffic is blocked unless port forwarding is configured.
- Best for: Safe internet access and general lab environments where the VM needs web access without exposing itself directly to the local network.
Host-Only Networking (VMnet1)
- How it works: Creates a completely isolated, private network container that links only the host and the virtual machines.
- IP address: Assigned by a virtual DHCP server on a closed internal subnet. The VM has no access to external networks or the internet.
- Best for: Secure sandboxing, offline testing, and practicing multi-machine setups like Active Directory or DNS.

Additional & Custom Options

Custom Networks (VMnet2 through VMnet255 on Linux / up to 20 on Windows)
- Allows you to use the Virtual Network Editor to build custom switch configurations (combining custom NAT, Bridged, or Host-Only rules) to isolate specific groups of VMs.
LAN Segments
- Specialized private networks that operate without a DHCP server or host connectivity.
- Best for: Multi-tier application testing or isolated multi-node cluster simulations.
Advanced Features
- Custom MAC address assignment, network throttling (simulating bandwidth limits or latency), and "Replicate physical network connection state" for mobile or Wi-Fi roaming laptops.

Here is the comparison table for the three primary network modes in VMware Workstation Pro:

Feature	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
IP Address Source	Physical network router / DHCP	VMware virtual DHCP	VMware virtual DHCP
Subnet Location	Same subnet as the host	Separate private subnet	Separate private subnet
Internet Access	Yes	Yes (via host IP)	No
Host Communication	Yes	Yes	Yes
External Network Visibility	Visible as a unique device	Hidden behind host IP	Completely hidden / Isolated
Inbound Connections	Allowed by default	Blocked (requires port forwarding)	Blocked from outside host
Best Use Case	Server hosting / Network scanning	Safe web browsing / Software updates	Malware sandboxing / Private labs

Advanced Connectivity Matrix

Feature	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
VM-to-VM Access	Yes (If on the same physical network)	Yes (If on the same `VMnet8` switch)	Yes (If on the same `VMnet1` switch)
Access from another physical device (Same Network)	Yes (Directly via VM's IP)	No (Unless Port Forwarding is configured)	No (Completely isolated from physical network)
Access from the Internet	Yes (Requires port forwarding on physical router)	Yes (Requires double port forwarding: router $\rightarrow$ host $\rightarrow$ VM)	No (Cannot be routed out)
VM Access to Host	Yes	Yes	Yes
VM Access to Same Network Devices	Yes	Yes (Outbound traffic is NATed via host IP)	No
VM Access to the Internet	Yes (Direct outbound)	Yes (Outbound via host NAT)	No
Port Forwarding Possible	N/A (Not needed; it has a direct IP)	Yes (Built into VMware Virtual Network Editor)	No
Reverse Connection / Reverse Shell Success	Yes (To any device on the network or internet)	Yes (To host, network, or internet via NAT)	Host/Internal Only (Cannot reach external devices)

Key Takeaways for Advanced Control

Reverse Connections: If you are testing reverse shells or callbacks in a security lab, NAT allows the VM to reach out to an external listening device seamlessly, while Host-Only blocks all outbound packets from leaving your local machine.
The "Vice Versa" Rule: If a VM cannot see a network (like Host-Only looking at the internet), devices on that network cannot see it either. Outbound access usually dictates inbound capability unless explicit translation (NAT/Port Forwarding) is placed in between.

Advanced Capabilities & Performance Comparison

Technical Metric / Feature	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
DHCP Management	Handled by external physical router / network team	Handled internally by VMware DHCP Service	Handled internally by VMware DHCP Service
Bandwidth & Latency Throttling	Limited by host NIC and physical switch infrastructure	Controlled via VM Network Adapter advanced settings	Controlled via VM Network Adapter advanced settings
Promiscuous Mode / Packet Sniffing	Supported (Can capture physical network broadcast traffic)	Limited (Only captures traffic passing through the NAT gateway)	Isolated (Only captures traffic within the private host vSwitch)
MAC Address Handling	Exposes VM MAC directly to the physical network switch	Masked behind the host’s physical MAC address	Never exposed to the physical network
IP Address Exhaustion Risk	High (Can exhaust company/home DHCP pool limits)	None (Uses local private `192.168.x.x` scope)	None (Uses local private `192.168.x.x` scope)
Physical Link State Replication	Supported (VM drops connection if host unplugges Ethernet/Wi-Fi)	N/A (Virtual switch link stays up even if host loses internet)	N/A (Completely independent of physical link status)
VLAN Tagging (802.1Q)	Supported (If host NIC driver allows tagging pass-through)	Not Supported	Not Supported
Host System Resource Overhead	Lowest (Packets pass straight to hardware layer)	Highest (Host CPU translates packet headers via `vmnat.exe`)	Low (Handled entirely in host kernel RAM/vSwitch)

Contextual Metrics Broken Down

Security Risk & Network Isolation: In Bridged mode, a misconfigured firewall or a compromised VM exposes your entire physical corporation or home network to risk. NAT offers a default perimeter hardware firewall behavior, while Host-Only offers standard air-gapped sandboxing.
Wi-Fi / Roaming Stability: Bridged mode frequently drops connections or fails to pull an IP address when your host laptop switches between Wi-Fi access points or moves to an 802.1X authenticated corporate network. NAT eliminates this problem because the VM only cares about its stable link to the host OS.
Virtual Network Editor Customization: While VMnet0, VMnet8, and VMnet1 are default placeholders, you can change the underlying subnets, toggle the local DHCP servers on/off entirely, or restrict IP allocation ranges manually using the VMware Virtual Network Editor utility.

Security & Threat Exposure Matrix

Security Feature / Metric	Bridged (`VMnet0`)	NAT (`VMnet8`)	Host-Only (`VMnet1`)
Default Isolation Level	None (Fully exposed to the host's physical network segment)	Partial (Inbound blocked; outbound allowed via translation)	High / Strict (Air-gapped from external networks; host-guest only)
Attack Surface Exposure	Highest (VM can be directly targeted by any device on the physical LAN)	Low (Hidden behind host IP; only targetable via explicit port forwards)	Lowest (Invisible to the outside world; targetable only by the host or internal VMs)
Malware Sandbox Suitability	Dangerous (Malware can worm/spread to physical devices on your home/office network)	Risky (Malware can dial out to Command & Control servers or scan the LAN via NAT)	Excellent (Malware is safely contained within the local virtual switch infrastructure)
Network Sniffing Risk (Host Side)	High (Host machine can easily sniff all VM traffic via local interfaces)	Medium (Host can sniff traffic passing through the virtual gateway)	Medium (Host can sniff traffic passing through the virtual gateway)
Network Sniffing Risk (LAN Side)	High (Physical network attackers can capture VM broadcast/multicast packets)	Protected (Physical LAN attackers only see the host's traffic packets)	Completely Immune (No data packets ever touch the physical medium)
IP/MAC Spoofing Impact	Severe (A malicious VM can disrupt or poison the physical network's ARP table)	Contained (Spoofing only breaks or disrupts the internal `VMnet8` virtual switch)	Contained (Spoofing only breaks or disrupts the internal `VMnet1` virtual switch)
Enterprise Policy Compliance	Often Violates (Connecting unauthorized VMs directly to corporate ports frequently trips rogue device alerts)	Usually Allowed (Appears to corporate monitoring tools as standard, single-host traffic)	Safe (Does not interact with corporate infrastructure, preserving compliance)

Key Security Implementations

The Inbound Hardware Barrier: NAT acts as a unidirectional firewall by default. External machines cannot initiate a handshake with a NAT VM unless you intentionally program a rule into the Virtual Network Editor.
The Threat of Lateral Movement: If you run a vulnerable machine (like an unpatched Windows or Linux target for hacking practice) on Bridged mode, any infected machine on your actual living room or corporate Wi-Fi can attack it, and vice versa.
True Air-Gapping: To simulate a completely isolated environment (e.g., analyzing ransomware), Host-Only is the baseline standard. To completely sever the host machine from the loop as well, you would transition the VM from Host-Only to an isolated LAN Segment.

Common JS vs ECMAScript Modules

Raghavvram Johnson — Tue, 13 Oct 2026 17:39:50 +0000

CommonJS (CJS) and ECMAScript Modules (ESM) are the two main systems used in JavaScript to organize, import, and export code across files.

Key Differences

Syntax:
- CommonJS uses require() and module.exports.
- ESM uses import and export.
Loading Mechanism:
- CommonJS loads modules synchronously (blocking) at runtime.
- ESM loads modules asynchronously and supports top-level await.
Standardization:
- CommonJS is the original module format built specifically for Node.js.
- ESM is the official W3C/ECMAScript standard supported natively in modern web browsers and Node.js.
- CommonJS does not support reliable tree-shaking (dead code elimination) because exports are dynamic and not statically analyzable.
- ESM supports static analysis, allowing bundlers to drop unused code cleanly.
File Extensions & Config:
- CommonJS uses .cjs or default .js (unless overridden).
- ESM uses .mjs, or .js when "type": "module" is declared in package.json.
Global Variables:
- CommonJS provides direct access to __dirname and __filename.
- ESM does not have these globals; instead, it relies on import.meta.url.

Feature Comparison

Feature	CommonJS (CJS)	ECMAScript Modules (ESM)
Syntax	`require()` / `module.exports`	`import` / `export`
Loading	Synchronous (blocking)	Asynchronous (non-blocking)
Browser Support	No (needs a bundler)	Yes (native)
Tree-Shaking	Limited / Not supported	Fully supported
Default in Node.js	Yes (for `.js` files)	Yes (when configured)

Which Should You Use?

Use ESM as the default choice for all new projects, modern libraries, and browser-based applications.
Use CommonJS primarily when maintaining legacy Node.js codebases, working with older tools that lack ESM support, or when migrating would cause high disruption.

🚀 Splunk Core deployment Guide: Docker Server & Arch Linux Forwarder

Raghavvram Johnson — Tue, 13 Oct 2026 17:38:28 +0000

This reference manual documents the complete architecture, configurations, and commands required to spin up a standalone Splunk indexer and securely ingest host operating system events.

Part 1: Splunk Enterprise Server (Docker Compose)

We deployed a permanent Splunk Free environment on the x86_64 architecture. Using Docker volumes ensures all indexed data, search structures, and dashboards persist through restarts.

Deployment File Configuration

Create a dedicated working directory and save this file exactly as docker-compose.yml:

services:
  splunk:
    image: splunk/splunk:latest
    container_name: splunk_free
    environment:
      # Accept the mandatory Splunk licensing terms
      - SPLUNK_START_ARGS=--accept-license
      - SPLUNK_GENERAL_TERMS=--accept-sgt-current-at-splunk-com

      # Activates the perpetual 500MB/day Free license immediately
      - SPLUNK_LICENSE_URI=Free

      # Required for internal initialization protocols
      - SPLUNK_PASSWORD=YourSecurePassword123!
    ports:
      - "8000:8000"   # Splunk Web UI Browser Console
      - "8088:8088"   # HTTP Event Collector (HEC) API Ingestion
      - "9997:9997"   # Splunk Indexer - Receiving port for Forwarders
    volumes:
      - splunk_etc:/opt/splunk/etc  # Stores configuration settings and custom apps
      - splunk_var:/opt/splunk/var  # Stores raw indexed log databases
    restart: unless-stopped

volumes:
  splunk_etc:
  splunk_var:

Operational Operations

Start Stack: docker compose up -d
Stop Stack: docker compose down
Web UI URL: Access http://localhost:8000 (Free Mode automatically routes directly into the unauthenticated workspace).

Server Configuration Constraint (Crucial Step)

Before any external machine can communicate with this container, the indexer engine must be instructed to listen on its data pipeline port:

Navigate to Settings > Forwarding and receiving.
Click Configure receiving under the Receive data column header.
Select New Receiving Port, enter 9997, and click Save.

Part 2: Host Node Log Ingestion (Arch Linux)

Because Arch Linux relies natively on systemd-journald instead of traditional structural text files (like syslog), we implemented a direct, low-overhead native script architecture.

Install the Agent Binary via AUR

Install the stable binary tracking from the Arch User Repository:

paru -S splunkforwarder

Initial Setup Credentials

Initialize the runtime parameters to establish the root control passwords:

sudo /opt/splunkforwarder/bin/splunk start --accept-license

(Provide username admin and create a distinct local agent password when prompted, then stop the session via sudo /opt/splunkforwarder/bin/splunk stop to return control to systemd).

Establish System Target Routing

Map the outbound forwarding path toward the container server. If the agent runs on the same underlying operating system as Docker, target the internal loopback:

sudo /opt/splunkforwarder/bin/splunk add forward-server 127.0.0.1:9997 -auth admin:<YourForwarderPassword>

Overcome Arch Systemd Journal Security Boundaries

The splunk daemon user created by the package must be explicitly allowed to look inside binary operating system logging streams:

sudo usermod -aG systemd-journal splunk

Configure Native Journal Ingestion File

Rather than fighting text-file translation limits, manually specify a high-performance native journald input receiver stream.

Open the system configuration manager:

sudo nvim /opt/splunkforwarder/etc/system/local/inputs.conf

Overwrite or append the exact parameters below:

[default]
host = arch-workstation

[journald://system_logs]
disabled = false
index = main
sourcetype = journald

Permission Realignment & Service Activation

Force a complete runtime ownership sync on application directories and hand engine lifecycle tracking to the native scheduler:

sudo chown -R splunk:splunk /opt/splunkforwarder
sudo chmod -R 755 /opt/splunkforwarder
sudo systemctl enable --now splunkforwarder.service

Part 3: Telemetry Analysis

To confirm telemetry streams are transmitting across isolation boundaries, load the Splunk Search Panel and run the following queries:

Verify Infrastructure Logs Inbound:
```
index="main" sourcetype="journald"
```
Verify Client-to-Server Health Interconnectivity:
```
index="_internal" sourcetype="splunkd"
```

And Congratulations, you have successfully installed Splunk Free Edition

🔐 Demystifying NIST SP 800-53

Raghavvram Johnson — Fri, 02 Oct 2026 12:53:48 +0000

If you’re getting started with Cybersecurity, GRC, Compliance, or Security Engineering, you’ll eventually come across NIST SP 800-53.

But what exactly is it?

🏛️ What is NIST?

NIST stands for the National Institute of Standards and Technology.

It is a non-regulatory agency of the U.S. Department of Commerce, founded in 1901.

NIST develops standards, guidelines, and frameworks that help organizations manage technology, security, privacy, and risk.

🔐 What is NIST SP 800-53?

NIST Special Publication 800-53 is a comprehensive catalog of security and privacy controls for information systems and organizations.

In simple terms:

NIST 800-53 tells you what security and privacy controls you should consider implementing to manage risk.

It is widely used as a foundation for building and assessing security programs, particularly in U.S. federal environments.

📌 What does "Revision 5" mean?

Revision 5 is the fifth major revision of NIST SP 800-53.

It significantly modernized the publication by:

• Integrating privacy controls
• Introducing a more flexible, organization-centric approach
• Moving away from controls being tied strictly to specific technologies
• Expanding coverage for modern cybersecurity and supply-chain risks

📊 NIST SP 800-53 Rev. 5 — The Numbers

The catalog contains:

🔹 20 Control Families

🔹 ~1,200 total controls and control enhancements

🔹 Approximately 300 base controls, with the remainder consisting largely of control enhancements.

Impact-based baselines are also defined, with controls/enhancements allocated across:

• Low: 149
• Moderate: 287
• High: 370

🧩 The 4-Level Hierarchy

Think of NIST 800-53 like a tree:

Level 1 — The Catalog

The complete NIST SP 800-53 Rev. 5 catalog containing the security and privacy controls.

Level 2 — Control Families

The catalog is organized into 20 families, each covering a broad security or privacy domain.

Examples:

• AC — Access Control
• IR — Incident Response
• SC — System and Communications Protection
• SR — Supply Chain Risk Management

Level 3 — Base Controls

These are the foundational requirements within each family.

For example:

AC-2 — Account Management

Level 4 — Control Enhancements

Enhancements add additional requirements or rigor to a base control.

For example:

AC-2(1) — Automated System Account Management

So you can think of it as:

NIST SP 800-53
→ Control Family
→ Base Control
→ Control Enhancement

Once you understand this hierarchy, navigating NIST 800-53 becomes much less intimidating.

🔐 Cybersecurity isn't just about tools. It's also about understanding the controls, processes, and frameworks that define how security is managed.

Simple TCP Server in Python

Raghavvram Johnson — Thu, 01 Oct 2026 16:33:35 +0000

TCP Server

Creating TCP servers in Python is just as easy as creating a client. You might want to use your own TCP server when writing command shells or crafting a proxy (both of which we’ll do later). Let’s start by creating a standard multi-threaded TCP server. Crank out the code below:

import socket
import threading

bind_ip = "0.0.0.0"
bind_port = 9999

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind((bind_ip, bind_port))
server.listen(5)
print(f"[*] Listening on {bind_ip}:{bind_port}")

def handle_client(client_socket):
    request = client_socket.recv(1024)
    print(f"[*] Received: {request.decode()}")
    client_socket.send(b"ACK!")
    client_socket.close()

while True:
    client, addr = server.accept()
    print(f"[*] Accepted connection from: {addr[0]}:{addr[1]}")
    client_handler = threading.Thread(target=handle_client, args=(client,))
    client_handler.start()

To start off, we pass in the IP address and port we want the server to listen on.
Next we tell the server to start listening with a maximum backlog of connections set to 5.
We then put the server into its main loop, where it is waiting for an incoming connection.
When a client connects, we receive the client socket into the client variable, and the remote connection details into the addr variable.
We then create a new thread object that points to our handle_client function, and we pass it the client socket object as an argument.
We then start the thread to handle the client connection, and our main server loop is ready to handle another incoming connection.
The handle_client function performs the recv() and then sends a simple message back to the client.

import socket

target_host = "127.0.01"
target_port = 9999

client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect((target_host, target_port))
client.send(b"AAABBBCCC")
response = client.recv(4096)

print(response.decode())

If you use the TCP client that we built earlier, you can send some test packets to the server and you should see output like the following:

[] Listening on 0.0.0.0:9999
[] Accepted connection from: 127.0.0.1:62512
[*] Received: ABCDE

That’s it! Pretty simple.

Simple UDP Client in Python

Raghavvram Johnson — Thu, 01 Oct 2026 16:29:28 +0000

A Python UDP client is not much different than a TCP client; we need to make only two small changes to get it to send packets in UDP form.

import socket

target_host = "127.0.0.1"
target_port = 80

client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
client.sendto(b"AAABBBCCC", (target_host, target_port))
data, addr = client.recvfrom(4096)
print(data.decode())

As you can see, we change the socket type to SOCK_DGRAM when creating the socket object.
The next step is to simply call sendto(), passing in the data and the server you want to send the data to.
Because UDP is a connectionless protocol, there is no call to connect() beforehand.
The last step is to call recvfrom() to receive UDP data back.
You will also notice that it returns both the data and the details of the remote host and port.

DEV Community: Raghavvram Johnson

Yara Rule (Malware Detection)

RegEx in Yara

How to Use Regex in YARA

Supported Modifiers

Limitations of YARA's Engine

Wildcard in Yara Strings

Example Usage in Hex Strings:

Yara for Memory Analysis

Step 1: Acquire a Memory Dump

Step 2: Write or Obtain a YARA Rule

Step 3: Run YARA Against a Memory Dump

Step 4: Use YARA with Memory Forensics Frameworks (E.g., Volatility)

Best Practices for Memory Analysis

Sigma Rule (Detection Logic)

Core Structure of a Sigma Rule

1. Header (Metadata)

2. Log Source (logsource)

3. Detection Block (detection)

4. Output Fields (fields)

Example Sigma Rule Skeleton

The Three Main Fields

How They Work Together (from Broad to Specific)

Why the Logsource Section Matters

1. Selections (What to Find)

2. Filters (What to Ignore)

3. Condition (the Boolean Glue)

Simple Analogy

1. Selection

2. Filter

How They Work Together

Jenkins Setup in Docker using Docker Compose

1. The docker-compose.yml File

2. How to Start Jenkins

3. Retrieve the Initial Admin Password

Host SonarQube Community Edition using Docker Compose

docker-compose.yml

⚠️ Critical Prerequisite (Elasticsearch Fix)

How to Start and Access

Data handlers (CISSP)

Data handlers

1. Data Subject

2. Data Owner

3. Data Auditor

4. Data Steward

5. Data Controller

6. Data Processor

7. Data Custodian

How Data Custodian Differs from Data Steward

Summary Table

Apache Kafka

Core Concepts of Apache Kafka

Kafka APIs

Bridged, NAT, and Host-Only in Vmware

Main Network Modes

Additional & Custom Options

Advanced Connectivity Matrix

Key Takeaways for Advanced Control

Advanced Capabilities & Performance Comparison

Contextual Metrics Broken Down

Security & Threat Exposure Matrix

Key Security Implementations

Common JS vs ECMAScript Modules

🚀 Splunk Core deployment Guide: Docker Server & Arch Linux Forwarder

🔐 Demystifying NIST SP 800-53

🏛️ What is NIST?

🔐 What is NIST SP 800-53?

📌 What does "Revision 5" mean?

📊 NIST SP 800-53 Rev. 5 — The Numbers

🧩 The 4-Level Hierarchy

Simple TCP Server in Python

TCP Server

Simple UDP Client in Python

2. Log Source (`logsource`)

3. Detection Block (`detection`)

4. Output Fields (`fields`)

1. The `docker-compose.yml` File

`docker-compose.yml`