Forem: Shresth Paul

Building a High-Density "OS Terminal" for Windows Forensics in Pure C

Shresth Paul — Sat, 21 Mar 2026 19:45:04 +0000

What happens when you combine low-level Windows C-programming with a Zero-Dependency WebSocket dashboard? You get OS Terminal—a hyper-lean alternative to bloated modern monitoring tools.

The Objective: Zero Bloat, Total Visibility
Most monitoring tools today are Electron-based or rely on heavy WMI queries that spike your CPU. I wanted to see how far I could push the Win32 API to create a forensic tool that uses less than 30MB of RAM while providing "Extreme Observability."

The Tech Stack
Native C-Engine: Directly hooks into ntdll.dll and advapi32.dll.
Node.js Bridge: Acting as a high-speed asynchronous relay.
Vanilla CSS/JS Dashboard: 100% dependency-free. No React. No Vite. No 150MB node_modules folder.
Key Technical Challenges Overcome

Ripping Process Strings from the PEB
Standard APIs often mask command-line arguments for protected processes. OS Terminal uses NtQueryInformationProcess with ProcessCommandLineInformation (Class 60). By elevating the process to SeDebugPrivilege, we can reach into the remote Process Environment Block (PEB) of any binary and extract the raw execution parameters before they are obfuscated.
Shannon Entropy Analysis in C
Detecting malware often comes down to unpredictability. I implemented a Shannon Entropy formula in the polling loop. If a process starts running a Base64-encoded script, its entropy score spikes (usually > 5.0). The UI detects this delta and red-flags it instantly.
Async Kernel Registry Traps
Polling the Registry is slow. Instead, I built an asynchronous C-thread that "crashes" into a Kernel wait state using RegNotifyChangeKeyValue. It sits silently at 0% CPU usage until a Persistence Key (like HKLM\Run) is touched, at which point it drains a thread-safe Ring Buffer straight to the dashboard.

Check out the source code and the architecture here: 👉 GitHub Repository [https://github.com/SecByShresth/OS-Terminal.git]

VulnFeed 2.0: Building a Zero-Server Vulnerability Dashboard (Level 2 Release)

Shresth Paul — Sat, 06 Dec 2025 20:02:47 +0000

DEV.TO ARTICLE

Hey dev community! 👋

We just shipped Level 2 of our vulnerability intelligence project, and I'm excited to share what we built and how it works technically.

The Problem

Most vulnerability dashboards are either:

Too expensive - Enterprise SaaS tools with high price tags
Too limited - Focused on one ecosystem or distribution
Privacy nightmares - Track your data, your queries, your team
Too complex - Require backend infrastructure to maintain

We wanted something radically different.

Enter Onyx Intelligence

Onyx is a completely static, zero-server vulnerability dashboard that aggregates data from 25+ sources (CISA, Red Hat, all major Linux distros, npm, PyPI, Maven, RubyGems, Cargo, Composer, etc.) into one beautiful, interactive interface.

Think of it as the Level 2 evolution of VulnFeed — everything you loved, but supercharged.

Key Stats:

📊 25+ vulnerability data sources
🔄 Auto-updates every 6 hours via GitHub Actions
🏗️ Zero backend required (GitHub Pages deployment)
🔒 Zero tracking, zero data collection
🎨 Beautiful glassmorphism UI with light/dark themes
📱 Fully responsive (mobile, tablet, desktop)
🧠 Asset exposure scanning (optional)

How It Works (The Tech)

The Data Collection Pipeline

Everything starts with a scheduled GitHub Actions workflow that runs every 6 hours:

# .github/workflows/osv-feed-update.yml
schedule:
  - cron: '0 */6 * * *'  # Every 6 hours

Here's what happens behind the scenes:

# scripts/fetch_osv_data.py
import requests
import json
from datetime import datetime

# Fetch from OSV.dev for all ecosystems
ecosystems = ['npm', 'PyPI', 'Maven', 'Cargo', 'Go', 'NuGet', 'Composer', 'RubyGems']

for ecosystem in ecosystems:
    response = requests.get(f'https://api.osv.dev/v1/query', 
        json={'package': {'ecosystem': ecosystem}})

    # Validate and deduplicate
    vulnerabilities = response.json()

    # Store as clean JSON
    with open(f'data/{ecosystem.lower()}.json', 'w') as f:
        json.dump(vulnerabilities, f)

# Also fetch CISA KEV, Red Hat, Linux distros
# Everything gets merged, validated, and deployed

The output? Clean, structured JSON files ready for your frontend to consume.

Frontend Rendering

On the client side, it's pure vanilla JavaScript with no frameworks or bloat:

// Load vulnerability data from static JSON files
async function loadVulnerabilities() {
    const response = await fetch('/data/vulnerabilities.json');
    return response.json();
}

// Build interactive visualizations with Chart.js
function renderSeverityChart(vulnerabilities) {
    const severityData = {
        labels: ['Critical', 'High', 'Medium', 'Low'],
        datasets: [{
            data: [
                vulnerabilities.filter(v => v.severity === 'CRITICAL').length,
                vulnerabilities.filter(v => v.severity === 'HIGH').length,
                vulnerabilities.filter(v => v.severity === 'MEDIUM').length,
                vulnerabilities.filter(v => v.severity === 'LOW').length
            ]
        }]
    };

    new Chart(ctx, { type: 'doughnut', data: severityData });
}

// Real-time filtering and search (no backend calls!)
function searchVulnerabilities(query, severity, days) {
    return vulnerabilities.filter(v => 
        (v.description.toLowerCase().includes(query.toLowerCase()) ||
         v.id.includes(query)) &&
        (severity === 'ALL' || v.severity === severity) &&
        (isWithinDays(v.published, days))
    );
}

No API calls. No server requests. Just static assets and client-side logic doing the heavy lifting.

Deployment Magic

The deployment is almost magical in its simplicity:

Commit changes to your fork
GitHub Actions workflow triggers automatically
Python scripts fetch fresh data
Static HTML/CSS/JS gets generated
Deployed to GitHub Pages automatically

Your dashboard is live at: yourusername.github.io/Onyx-Intelligence/

Key Features We Built

✅ Multi-Source Aggregation

Instead of maintaining 25 browser tabs for different vulnerability sources, everything lives in one place:

// Single search across CISA, Red Hat, npm, PyPI, Maven, etc.
const allVulnerabilities = [
    ...cisaKEV,
    ...redHatAdvisories,
    ...npmVulnerabilities,
    ...pypiVulnerabilities,
    ...mavenVulnerabilities,
    // ... 20+ more sources
];

// Now search once and get results from everywhere
const results = allVulnerabilities.filter(v =>
    v.id.includes('CVE-2024-') || 
    v.packages.includes('lodash') ||
    v.source === 'CISA'
);

✅ Smart Filtering

Advanced filters without the backend complexity:

// Critical vulnerabilities from the last 30 days
const criticalRecent = vulnerabilities.filter(v =>
    v.cvss >= 7.0 && 
    daysOld(v.published) <= 30 &&
    v.status === 'EXPLOITED'
);

// Filter by ecosystem
const npmVulns = vulnerabilities.filter(v => 
    v.ecosystem === 'npm'
);

// Combine filters
const targetedResults = vulnerabilities.filter(v =>
    (v.severity === 'CRITICAL' || v.severity === 'HIGH') &&
    v.ecosystem.includes('Linux') &&
    daysOld(v.published) <= 7
);

✅ Asset Exposure Scanner

Optional feature that scans IPs and domains against multiple intelligence sources:

// Scan an IP against Censys, Shodan, AbuseIPDB, VirusTotal
async function scanAsset(ipOrDomain) {
    const results = await Promise.all([
        fetch(`/api/scan?ip=${ipOrDomain}&provider=censys`),
        fetch(`/api/scan?ip=${ipOrDomain}&provider=shodan`),
        fetch(`/api/scan?ip=${ipOrDomain}&provider=abuseipdb`),
        fetch(`/api/scan?ip=${ipOrDomain}&provider=virustotal`)
    ]);

    return {
        censys: await results[0].json(),
        shodan: await results[1].json(),
        abuseipdb: await results[2].json(),
        virustotal: await results[3].json()
    };
}

API keys? Stored safely in GitHub Secrets - never exposed in frontend code.

✅ Privacy by Design

Zero tracking. Zero data collection. Just pure, honest software:

// Only localStorage for theme preference
localStorage.setItem('theme', 'dark');
localStorage.setItem('lastViewed', 'npm');

// Everything else is session-only, in-memory
const sessionData = {
    currentFilters: { severity: 'HIGH', days: 30 },
    selectedVulnerability: null
};

// No Google Analytics
// No Mixpanel
// No Segment
// No data collection whatsoever

✅ Beautiful UI

We didn't just build a tool — we built something that looks premium:

/* Glassmorphism cards */
.vulnerability-card {
    background: rgba(255, 255, 255, 0.1);
    backdrop-filter: blur(10px);
    border: 1px solid rgba(255, 255, 255, 0.2);
    border-radius: 12px;
    padding: 1.5rem;
    transition: all 0.3s ease;
}

.vulnerability-card:hover {
    background: rgba(255, 255, 255, 0.15);
    transform: translateY(-2px);
    box-shadow: 0 8px 32px rgba(0, 0, 0, 0.1);
}

/* Dark mode support */
@media (prefers-color-scheme: dark) {
    .vulnerability-card {
        background: rgba(30, 27, 75, 0.2);
        border-color: rgba(255, 255, 255, 0.1);
    }
}

/* Responsive grid */
@media (max-width: 768px) {
    .grid {
        grid-template-columns: 1fr;
    }
}

Smooth animations. Light and dark themes. Fully responsive.

Getting Started (Seriously, 5 Minutes)

Step 1: Fork the Repository

Just hit that fork button on GitHub. We'll wait.

Step 2: Enable GitHub Actions

Settings → Actions → General
→ Set workflow permissions to "Read and write"
→ Check "Allow GitHub Actions to create pull requests"

Step 3: Enable GitHub Pages

Settings → Pages
→ Source: GitHub Actions

Step 4: Trigger the Workflow

Actions → "🔄 Onyx OSV Intelligence Feed"
→ Run workflow

Watch it fetch 25+ data sources and build your dashboard.

Step 5: Visit Your Dashboard

https://yourusername.github.io/Onyx-Intelligence/

Done. Your enterprise-grade vulnerability dashboard is live.

Bonus: Enable Asset Scanning

Add your API keys (optional):

Settings → Secrets and variables → Actions

Add these secrets:

CENSYS_API_ID
CENSYS_API_SECRET
SHODAN_API_KEY
ABUSEIPDB_API_KEY
VIRUSTOTAL_API_KEY

Now you have advanced asset exposure scanning too.

Tech Stack Breakdown

Frontend: Vanilla JavaScript (no React, Vue, Svelte — just pure JS)
Styling: CSS3 with glassmorphism effects
Charts: Chart.js for visualizations
Automation: GitHub Actions
Data Processing: Python 3.11
Hosting: GitHub Pages (free, reliable, zero maintenance)

Intentionally simple. Intentionally dependency-light.

Customization is Easy

Change Update Frequency

Want updates every 12 hours instead of 6?

# .github/workflows/osv-feed-update.yml
schedule:
  - cron: '0 */12 * * *'  # Every 12 hours

Or daily:

schedule:
  - cron: '0 0 * * *'  # Daily at midnight

Add a New Ecosystem

# scripts/fetch_osv_data.py
OSV_ECOSYSTEMS = [
    'AlmaLinux',
    'Debian',
    'Ubuntu',
    'YourCustomEcosystem',  # Add it here
]

Customize Colors

:root[data-theme="light"] {
    --accent: #6366f1;
    --accent-hover: #4f46e5;
    --background: #ffffff;
    --text: #1f2937;
}

:root[data-theme="dark"] {
    --accent: #818cf8;
    --accent-hover: #6366f1;
    --background: #0f172a;
    --text: #f1f5f9;
}

Everything is designed for customization without complexity.

Real-World Use Cases

Security Teams: Centralized threat tracking, CISA BOD 22-01 compliance, patch prioritization workflows

DevOps Engineers: Monitor vulnerabilities in your infrastructure and dependencies, automated alerts

System Admins: Track patches across heterogeneous Linux environments, prioritize updates

Security Researchers: Analyze vulnerability trends, track exploits, cross-ecosystem correlation

Solo Developers: Stay updated on vulnerabilities in your tech stack without SaaS costs

CTOs/Leadership: Executive dashboard showing your security posture in real-time

The Roadmap (Level 2.x)

We're actively developing:

[ ] SBOM (Software Bill of Materials) upload and analysis
[ ] MITRE ATT&CK mapping - link CVEs to attack techniques
[ ] Email and Webhook notifications for critical vulnerabilities
[ ] Custom dashboard configurations per team
[ ] Historical vulnerability timeline analysis
[ ] REST API for integration with your tools
[ ] Browser extension for quick CVE lookups
[ ] Local agent for air-gapped environments

The Philosophy Behind Onyx

We believe vulnerability management should be:

Free - No SaaS costs, no licensing fees
Private - No data collection, no tracking, no surveillance
Simple - No complex infrastructure to maintain
Powerful - Enterprise features without enterprise complexity
Open - Fully auditable code, complete transparency

Onyx proves you don't have to sacrifice any of these.

What Sets This Apart from VulnFeed

VulnFeed was good. Onyx is great because:

Multi-ecosystem - 25+ data sources vs limited scope
Beautiful UI - Modern glassmorphism design
Asset scanning - IP/domain intelligence built-in
Better automation - More frequent updates, easier customization
More sources - CISA, Red Hat, all major Linux distros, package managers
Advanced analytics - Interactive charts and visualizations
Better search - Across all sources simultaneously

It's a complete evolution.

Get Involved

Try the live demo: No installation needed, just visit and explore

Fork the repository: Run your own instance in minutes

Open an issue: Found a bug? Have an idea? Let us know

Contribute: Help us expand features, improve UI, add data sources

Spread the word: Share with your team, write about your experience, give us a ⭐

This is what enterprise vulnerability management should look like: simple, beautiful, private, and free.

No compromises. No bullshit.

Just pure, powerful vulnerability intelligence built for the security community.

Ready to level up? Fork the repo and deploy your dashboard today.

🔐 The Linux Security Architecture - PAM, Capabilities, MAC & Beyond

Shresth Paul — Fri, 28 Nov 2025 04:23:54 +0000

Linux powers everything from cloud servers to Android smartphones - trusted not just because it's open-source, but because its security architecture is layered, modular, and resilient.

Instead of depending on a single control, Linux enforces defense-in-depth through authentication frameworks, access controls, kernel-level enforcement, and isolation.

Here's a breakdown of the 7 key layers that make Linux secure:

1️⃣ Discretionary Access Control (DAC) - The Classic Unix Model

DAC is the foundation of Linux security. Every file and process has:

An owner
A group
Permissions for user */ **group */ **others

Example:

-rwxr-xr--  root  admin  script.sh

👉 Fast and simple
❌ But compromise the owner → attacker inherits full access
This is why Linux security evolved beyond just DAC.

2️⃣ Pluggable Authentication Modules (PAM) - How Users Login & Prove Identity

PAM decides how authentication works in Linux - and it's completely modular.

It controls:

Authentication - passwords, MFA, smart cards
Account restrictions - lockouts, expiration, allowed login times
Session rules - mounting home directories, environment setup
Password policies - complexity, aging, history

Example policy enforcement:

password required pam_pwquality.so retry=3 minlen=10 ucredit=-1 lcredit=-1

Admins can enhance security without modifying applications - big win.

3️⃣ Linux Capabilities - Breaking the "Root is God" Problem

Historically, root ** meant **unlimited power.
Even to bind to port 80 → full root access required.

Capabilities divide root into small, controlled privileges:

CAP_NET_BIND_SERVICE - bind to privileged ports
CAP_SYS_ADMIN - broad admin power
CAP_SETUID - change user IDs

Example - secure Nginx without full root:

sudo setcap 'cap_net_bind_service=+ep' /usr/bin/nginx

Result → drastically reduced attack surface.

4️⃣ Mandatory Access Control (MAC) - Security Even Root Must Obey

MAC enforces zero-trust on system resources.

Two major Linux MAC systems:

SELinux - label-based, very fine-grained
AppArmor - profile-based, simpler to implement

Even if root is compromised:

✋ MAC blocks access to confidential files and processes

E.g., a hacked Apache process cannot read /etc/shadow.

Containment becomes default behavior.

5️⃣ Namespaces & cgroups - The Core of Container Security

Containers are secure because the kernel enforces isolation:

Namespaces- isolate visibility of PIDs, networking, users, etc.
cgroups - restrict CPU, memory, and I/O usage
seccomp- block dangerous syscalls (like ptrace)

This ensures:

✔ Containers can't spy on others
✔ Rogue containers can't hog resources
✔ Attackers face syscall roadblocks

Ideal for cloud + microservices workloads.

6️⃣ Linux Security Modules (LSM) - The Kernel Enforcement Engine

LSM provides security hooks inside the kernel, used by:

SELinux
AppArmor
Landlock
TOMOYO
Yama

Check what's active:

cat /sys/kernel/security/lsm

This makes security pluggable, similar to PAM but inside the kernel.

7️⃣ Secure Boot, dm-crypt, TPM - Protecting Integrity & Data-at-Rest

Modern Linux supports enterprise-grade protection:

Secure Boot - blocks boot-level malware/tampering
TPM- hardware root-of-trust, key attestation
dm-crypt / LUKS - encrypted disks → stolen device ≠ stolen data

Security now starts before the kernel even loads.

🧩 Linux Security Layered Model - Quick Summary

1️⃣ Identity & ownership → DAC
2️⃣ Who can log in → PAM
3️⃣ Least privilege → Capabilities
4️⃣ Mandatory rules → MAC
5️⃣ Strong isolation → Namespaces & cgroups
6️⃣ Kernel enforcement → LSM
7️⃣ Trusted boot & encryption → Secure Boot, TPM

👉 Each layer is powerful
💪 Together they are extremely difficult to bypass

🎯 Final Thoughts
Linux security isn't about one feature -
it's the stacked architecture that makes it reliable under attack.

Stay curious about what's happening beneath the shell…
because Linux was built to defend itself. 🛡️🐧

🖥️ Stay tuned for more Linux thoughts - this is my weekly Linux Series exploring the OS one layer at a time. 🚀

Ephemeral Vulnerability Scanner: Pure Client-Side JS for Windows/Linux/macOS Vuln Analysis

Shresth Paul — Wed, 26 Nov 2025 09:00:56 +0000

Hey Dev.To community! 👋

I've just launched a new open-source project that might be of interest to those building CI/CD pipelines or managing internal security tooling: Ephemeral Vulnerability Scanner.

This is a 100% client-side application built with vanilla JS/HTML/CSS. You clone it, open index.html, upload your system inventory (inventory.json), and get an instant, privacy-safe vulnerability report.

💡 Why this architecture?

It addresses the privacy concern: No sensitive system data leaves your device.
It's fast and eliminates backend maintenance overhead.
It's transparent: you can literally inspect the app.js source to see the entire logic.

Under the Hood:

We use platform-specific commands (PowerShell, dpkg, rpm, brew) to generate the initial JSON inventory.
The analysis logic hits MSRC CSAF API (Windows), OSV.dev API (Open Source), and CISA KEV for a strict, verified lookup.
Results are grouped into clean, actionable "Package Cards" with the minimum safe version calculated automatically.

Check out the repo, try the demo, and let me know what you think of the client-side approach for security analysis!

🔗 Live Demo: VulnScan

🔍 MANTA – A Fully Ephemeral, AI-Powered Malware Analysis Tool (Built on GitHub Pages)

Shresth Paul — Thu, 20 Nov 2025 21:31:04 +0000

I recently shipped a project I’m really proud of: MANTA – Malware Analysis Tool & Assistant

It’s a privacy-first malware static analysis tool with:

No backend server
No database
No persistence
100% client-side AI heuristics
Optional GitHub Actions backend
Runs entirely on GitHub Pages

Here’s the live version:
👉 Malware Analysis Tool

🏗 Architecture Overview

MANTA is built as a hybrid:

Client-Side Browser Engine (Primary Mode)

File never leaves the browser
JS-based static analysis
Hashing + PE header parsing
String extraction
Entropy + packer detection
Suspicious IOCs
AI heuristic scoring

GitHub Actions Backend (Optional Deep Scan)

Triggered only if configured.

Capabilities:

YARA scanning
Advanced static tooling
Python-based static analysis
AI-enhanced summaries

Backend is fully serverless.
Files delete immediately after processing.

✨** Features**

Modern UI
Drag & drop support
Real-time progress indicators
JSON / HTML / TXT report export
Zero logging, zero tracking
Auto-wipe memory on refresh
Works completely offline in client mode

🎯 Why GitHub Pages + GitHub Actions?

Because they offer:

Free hosting
Zero maintenance
Full transparency
Serverless execution
Easy forkability

And it keeps the tool fully open-source and reproducible.

📦 Repo

MANTA

If you're into malware analysis, browser-based tooling, or serverless architectures, feel free to explore the repo or contribute enhancements.

Thanks for reading!
Happy to get feedback, PRs, or ideas for the next release.

🚀 ElasticSecOpsCoPilot — Autonomous IOC Enrichment for Elastic Security

Shresth Paul — Wed, 19 Nov 2025 21:20:32 +0000

I just released ElasticSecOpsCoPilot, a Python-powered continuous enrichment engine.

🔥 What It Does

Extracts IOCs from logs-* and events-*
Enriches them using:
- VirusTotal
- AbuseIPDB
- Shodan
- WHOIS
- IPLocation.net
Writes structured enriched documents back into Elasticsearch

🧠 Why I Built It
Most SOCs don’t have continuous enrichment pipelines, especially small/medium teams relying heavily on Elastic Security. This tool closes that gap with:

Real-time enrichment loop
Rate-limited API calls
Lightweight document schemas
Zero vendor lock-in

🛠️ Tech Stack: -
Python, Elastic Cloud Serverless, VirusTotal API, AbuseIPDB, Shodan, free Geo IP APIs.

📦 Repo: -
👉 https://github.com/SecByShresth/ElasticSecOpsCoPilot

🧠 How User-Space and Kernel-Space Affect Security in Linux

Shresth Paul — Thu, 13 Nov 2025 04:41:17 +0000

When we talk about Linux security, most people think of firewalls, sudo permissions, or file ownership.
But the real security story begins much deeper — at the boundary between user-space and kernel-space.

Understanding this boundary is essential for anyone working in cybersecurity, system hardening, or malware analysis.
Because once this barrier is broken… you no longer control your system — the attacker does.

🔍 What Are User-Space and Kernel-Space?

Think of your operating system as a high-security building.

The kernel-space is the restricted control room — only a few trusted personnel (kernel code, drivers, privileged processes) are allowed here.
The user-space is the public area — where regular users and applications operate.

In Linux, these two areas are isolated for safety. User-space programs can’t directly touch hardware or memory used by the kernel.
Instead, they make *system calls * (like read(), write(), open()) to request the kernel to perform those actions safely.

This isolation prevents your text editor from corrupting memory, or your browser from crashing the system.

🧱 Why This Separation Matters for Security

Memory Protection:
User-space processes can’t access kernel memory directly.
This stops malware from easily overwriting system-level structures.
Privilege Isolation:
Even if a user-space app is compromised, it stays confined to user privileges — unless it exploits a kernel bug.
Controlled Interfaces (Syscalls):
System calls act as a gatekeeper between user-space and kernel-space. Every interaction is validated, sanitized, and logged (in modern systems).
Crash Containment:
A crash in user-space (say, Firefox) doesn’t crash the kernel. But a kernel crash (via a bad driver) can panic the entire system — that’s why kernel security is sacred.

⚠️ How Attackers Exploit This Boundary

Attackers are obsessed with crossing the user-to-kernel boundary, because that’s where they gain ultimate control.

Common exploitation techniques include:

Kernel Vulnerabilities:
Bugs in device drivers or kernel modules (like use-after-free or buffer overflow) allow attackers to execute code in kernel-space.

Privilege Escalation:
Exploiting flaws in syscalls or permissions to elevate from a normal user to root.

Malicious Kernel Modules (Rootkits):
Attackers load custom modules that hide processes, intercept syscalls, or modify kernel behavior.

Abusing /dev and /proc interfaces:
Misconfigured device interfaces can provide direct access to kernel memory or configuration, bypassing restrictions.

🔒 How to Strengthen This Boundary

Here’s how defenders can keep this line secure:

Keep the Kernel Updated:
Most privilege escalations stem from kernel CVEs. Regular updates close these holes before attackers find them.
Restrict Kernel Module Loading:
Use lsmod, modprobe -r, and set kernel.modules_disabled=1 (after boot) for high-security systems.
Enable Mandatory Access Controls:
SELinux or AppArmor helps enforce strict policies around system calls and process access.
Use Syscall Filtering (seccomp):
Modern services (like Chrome, Docker) use seccomp to block dangerous syscalls from ever being executed.
Audit and Monitor Kernel Behavior:
Tools like auditd, osquery, and Falco help detect abnormal kernel interactions in real-time.

🧩 Real-World Example

In 2022, a privilege escalation flaw (Dirty Pipe, CVE-2022-0847) allowed attackers to overwrite read-only files from user-space — effectively writing arbitrary data into the kernel’s memory mappings.
This was possible because of a flaw in how user-space interacted with kernel buffers — a perfect example of this boundary being breached.

Patches fixed it quickly, but it reminded everyone:

The line between user-space and kernel-space is thin — and must be guarded relentlessly.

🚀 Final Thoughts

Linux’s design is inherently secure — but its power lies in how well you understand and protect its foundations.
User-space and kernel-space separation isn’t just a performance or stability feature — it’s one of the strongest lines of defense in system security.

Once that line is crossed, there’s no firewall or antivirus that can save you.

So the next time you hear about a kernel exploit, remember — that’s not “just another CVE.”
That’s an attack on the very wall that keeps your system safe.

🚀 Introducing VulnFeed - Real-Time Vulnerability Tracking for CISA & Red Hat

Shresth Paul — Mon, 03 Nov 2025 20:06:04 +0000

“What started as a late-night experiment turned into a fully automated vulnerability intelligence dashboard.”

Over the past few days (and one long night 😅), I built VulnFeed — a real-time feed that tracks and visualizes CISA’s Known Exploited Vulnerabilities and Red Hat Security Data API updates.
It’s open-source, lightweight, and automatically refreshes every few hours using GitHub Actions.

🔍 Why I Built This
Keeping track of actively exploited vulnerabilities has always been a challenge — especially across multiple sources.
Most dashboards are either slow, paywalled, or overly complex.
I wanted something simple, fast, and transparent — something that could be used both by security teams and curious researchers.

⚙️ How It Works

- 🧠 Data Sources:

CISA Known Exploited Vulnerabilities Catalog
Red Hat Security Data API

- 🔄 Automation:
A GitHub Action runs every few hours to pull the latest data and publish updates to the site.

- 💡 Frontend:
Built with simple HTML + JS for now — fast, clean, and hosted via GitHub Pages.

- 📂 Open Source:
You can explore the repository and workflows here → GitHub — SecByShresth/VulnFeed

💬 Final Thoughts
Security data should be accessible, open, and real-time.
VulnFeed is my small step toward that goal.
If you’re into threat intelligence, DevSecOps, or vulnerability management, I’d love to hear your feedback or ideas for improving it.

Check it out here → https://secbyshresth.github.io/VulnFeed/
GitHub Repo → https://github.com/SecByShresth/VulnFeed

✍️ Built by Shresth Paul — fueled by curiosity, caffeine, and a bit of insomnia.

🛡️ What Makes Linux Secure (and Where It's Weak - Plus How to Fix It)

Shresth Paul — Wed, 29 Oct 2025 21:11:47 +0000

When people say "Linux is more secure than Windows", they're often half right - and half overconfident.

Linux is built on strong security principles, but it's not immune to misconfigurations, privilege escalations, or human mistakes.

Let's explore why Linux is secure, where it's weak, and most importantly - how to fix those weaknesses.

🔍 Why Linux Is Secure by Design

1. Open-Source Transparency
Linux's open codebase means vulnerabilities rarely stay hidden.
With thousands of eyes reviewing patches and commits daily, flaws are usually caught quickly.

✅ Security Tip:
Stay subscribed to your distro's security mailing list (arch-security, debian-security-announce, etc.).
Use automatic updates where safe - or run:

sudo pacman -Syu      # Arch
sudo apt update && sudo apt upgrade -y  # Debian/Ubuntu

2. User Privilege Separation
Linux's privilege model prevents normal users from harming system-level components.
Root access requires explicit elevation (sudo), and every sudo command gets logged.

✅ Security Tip:

Never run applications as root unless absolutely necessary.
Review your sudoers file using:

sudo visudo

Disable passwordless sudo access.

3. Granular Permissions and Ownership
The rwx (read, write, execute) permission model provides precise control over access.
Combined with proper ownership, this limits how much damage a compromised process can do.

✅ Security Tip:

Regularly audit permissions:

sudo find / -perm -2 ! -type l -ls 2>/dev/null

(This finds world-writable files.)
Use chmod, chown, and groups wisely - avoid chmod 777 at all costs.

4. Modular Security Layers
Linux layers security with PAM **(authentication), **AppArmor/SELinux (access control), and iptables/nftables (firewalling).

✅ Security Tip:

Use ufw or firewalld to manage firewalls easily.
Enable AppArmor or SELinux policies:

sudo aa-status 
getenforce

If they're not active, enable them - they help contain compromised applications.

5. Community and Rapid Patching
Unlike proprietary OSes, Linux distros release patches within hours or days after a CVE surfaces.

✅ Security Tip:
Use a vulnerability scanner like Lynis or OpenVAS periodically to check system health:

sudo lynis audit system

⚠️ Where Linux Is Weak - and How to Fix It

1. Misconfiguration and Human Error
Most real-world intrusions come from weak SSH setups or careless file permissions.
💡 How to Fix It:

Disable SSH password authentication:

PasswordAuthentication no

Use SSH keys instead.
Close unnecessary ports and then block unwanted services via your firewall.

sudo ss -tuln

2. Outdated or Unpatched Systems
Attackers often exploit unpatched software, especially on servers that haven't been updated in months.
💡 How to Fix It:

Enable automatic updates or schedule a weekly cron job.
For long-term servers, test patches in a staging VM before production rollout.

3. Weak Application Sandboxing
Desktop and server apps sometimes run with more privileges than they should.
💡 How to Fix It:

Use Flatpak or Snap to run untrusted apps in containers.
Enforce AppArmor profiles - even basic confinement limits access to files and devices.

4. Privilege Escalation Exploits
Kernel and sudo vulnerabilities can allow attackers to gain root access.
💡 How to Fix It:

Keep kernel packages up to date.
Limit who's in the sudo group:

getent group sudo

Use auditd to log and monitor privilege use:

sudo auditctl -l

5. Overconfidence
Linux's reputation for security sometimes breeds complacency.
Admins skip hardening steps thinking, "It's Linux - I'm safe." That's exactly how breaches happen.
💡 How to Fix It:

Perform regular security audits using checklists like CIS Benchmarks for Linux.
Treat every system as if it's already under attack - and design accordingly.

🧭 Takeaway
Linux provides every tool you need to build a secure environment - but none of them work if you ignore them.
True security isn't about the OS you use; it's about the discipline you maintain.
"Security in Linux isn't a product - it's a process."

Maintaining Arch Linux AUR Packages: Update for python-zfec

Shresth Paul — Mon, 27 Oct 2025 18:50:22 +0000

As part of my ongoing maintenance work on Arch Linux AUR packages, I’ve updated the python-zfec package — the Python bindings for the ZFEC erasure coding library.

What Changed

Previous state: Older release based on a previous version of the ZFEC library.
Update: The AUR package now tracks the latest upstream release with cleaner metadata and improved Python packaging standards.

The goal was to make the build more consistent with upstream Python packaging practices, ensuring the module installs cleanly with current versions of Python on Arch.

Why It Matters
python-zfec provides Python support for ZFEC, a fast, open-source implementation of erasure coding — often used for data redundancy and recovery.
With this update:

Build scripts are simplified
Dependencies are better aligned with current Python packaging
The module works smoothly on modern Arch systems

How to Install (AUR)

yay -S python-zfec

Verify the installation:

python -c "import zfec; print('ZFEC imported successfully')"

Closing Thoughts

Maintaining AUR packages is about keeping the Linux ecosystem consistent and reliable. This small but important update ensures that Arch users can continue using ZFEC-based tools without compatibility issues.

Stay tuned for more updates from my AUR maintenance journey!

Maintaining Arch Linux AUR Packages: Updates for python-nspektr and rapidyaml

Shresth Paul — Thu, 02 Oct 2025 18:37:11 +0000

As part of my ongoing effort to maintain and improve Arch Linux AUR packages, I recently updated two projects — python-nspektr and rapidyaml. Both required more than just bumping versions: I had to revisit sources, streamline dependencies, and ensure smooth builds for both C++ and Python components.

Here’s a breakdown of what changed and how you can use these updated packages.

1. Updating python-nspektr

Previous state: Built from a Git commit (0.5.0).
Update: Now at 0.5.1, sourced from the official PyPI release.
Why it matters: Using the PyPI tarball results in a cleaner package with minimal dependencies, ensuring stability for Arch users.
How to install (AUR):

yay -S python-nspektr

Verify installation:

python -c "import nspektr; print(nspektr.__version__)"

2. Updating rapidyaml (C++ library)This update focused solely on the C++ rapidyaml library, not the Python bindings.

Previous state: Version 0.9.0 built from Git.
Update: Now bumped to 0.10.0, with improved packaging for the C++ components.
AUR change: When I updated rapidyaml, the separate python-rapidyaml package was automatically dropped from the AUR. This wasn’t because of a change in the upstream project’s Python bindings, but rather because the AUR packaging now only includes the C++ library.
What was tested:

Verified the C++ rapidyaml library with a simple YAML parsing test. -Python bindings remain available upstream, but they’re no longer part of the Arch AUR package.

How to install (AUR):

yay -S rapidyaml

Test the C++ library:

#include <ryml.hpp>
#include <iostream>
int main() {
    c4::yml::Tree tree = ryml::parse_in_arena(R"(
        hello: world
        number: 42
    )");
    std::cout << tree["hello"].val() << std::endl; // prints: world
}

Compile and run:

g++ test.cpp -o test -lryml
./test

Updated Packages Overview
PackageVersion Updated ToNotespython-nspektr0.5.1Switched from Git commit to PyPI tarball, trimmed dependenciesrapidyaml0.10.0Includes both C++ library and Python bindings (AUR auto-removed the separate python-rapidyaml package)

Closing Thoughts
Maintaining AUR packages isn’t just about version bumps — it’s about keeping packages clean, reliable, and easy for users to install. With these updates, both python-nspektr and rapidyaml are now aligned and ready for Arch Linux users.

If you’re also maintaining AUR packages, here are some quick tips:

Prefer PyPI tarballs over Git commits for Python projects.
Keep C++ libraries and their Python bindings in sync.
Always test with a real-world example after building.
Don’t forget to regenerate your .SRCINFO with:

makepkg --printsrcinfo > .SRCINFO

I’ll continue sharing updates from my AUR maintenance journey — stay tuned for more!

Maintaining Arch Linux AUR Packages: Updates for python-nspektr and rapidyaml

Shresth Paul — Thu, 02 Oct 2025 18:37:10 +0000

Here’s a breakdown of what changed and how you can use these updated packages.

1. Updating python-nspektr

yay -S python-nspektr

Verify installation:

python -c "import nspektr; print(nspektr.__version__)"

2. Updating rapidyaml (C++ library)This update focused solely on the C++ rapidyaml library, not the Python bindings.

Verified the C++ rapidyaml library with a simple YAML parsing test. -Python bindings remain available upstream, but they’re no longer part of the Arch AUR package.

How to install (AUR):

yay -S rapidyaml

Test the C++ library:

#include <ryml.hpp>
#include <iostream>
int main() {
    c4::yml::Tree tree = ryml::parse_in_arena(R"(
        hello: world
        number: 42
    )");
    std::cout << tree["hello"].val() << std::endl; // prints: world
}

Compile and run:

g++ test.cpp -o test -lryml
./test

If you’re also maintaining AUR packages, here are some quick tips:

Prefer PyPI tarballs over Git commits for Python projects.
Keep C++ libraries and their Python bindings in sync.
Always test with a real-world example after building.
Don’t forget to regenerate your .SRCINFO with:

makepkg --printsrcinfo > .SRCINFO

I’ll continue sharing updates from my AUR maintenance journey — stay tuned for more!