标签：#linux

This is the first article in a four-part series where I document how I turned a 10€/month VPS into a production-grade platform hosting my portfolio, a university group webapplication and a SaaS product, all isolated from each other with Kubernetes. In this part, we take a fresh Ubuntu server and lock it down properly before installing anything else. Why bother with hardening? The moment your VPS gets a public IP address, it starts receiving attacks. Not "might receive", it starts . Within minutes, automated bots will probe port 22, try root:root , admin:admin123 and thousands of other credential combinations. If you skip this step and jump straight to deploying your apps, you are building on sand. The good news: an hour of work is enough to eliminate the vast majority of these threats. Here is what we will set up: A non-root user with sudo privileges SSH key authentication, with passwords and root login disabled UFW as a simple, effective firewall Fail2ban to ban brute-force attackers automatically Automatic security updates What you need A fresh VPS running Ubuntu 24.04 LTS or newer. I use a Hostinger KVM 2 (2 vCPU, 8 GB RAM, 100 GB NVMe), but any provider works: Hetzner, DigitalOcean, OVH, Contabo. The root password or SSH key your provider gave you. A terminal on your local machine (macOS, Linux, or WSL on Windows). Throughout this tutorial, replace YOUR_SERVER_IP with your server's IP address and deploy with the username you want to use. Step 1: First login and system update Connect as root for the first and last time: ssh root@YOUR_SERVER_IP Update everything before touching anything else: apt update && apt upgrade -y apt autoremove -y If a kernel update was installed, reboot now: reboot Wait a minute, then reconnect. Step 2: Create a non-root user Working as root is like driving without a seatbelt: fine until it isn't. One mistyped rm -rf and the party is over. Create a dedicated user: adduser deploy Choose a strong password (you will still need it for sudo ,

Installing Ubuntu Server 24.04 LTS in an offline mode (no LAN cable or WiFi connected) leaves you with an unmanaged network interface which requires manual configuration post-install. The interface enp4s0 is unmanaged by systemd-networkd and also the service itself is disabled. NOTE: This guide applies to Ubuntu server. On Ubuntu desktop you have the NetworkManager service installed and the steps would be different. To fix the problem follow the steps below: Create a Brand New Netplan Configuration File Look into /etc/netplan . You will probably see the dir is empty. This means the installer completely gave up on configuring the network and didn't create any profiles. Create a new file, e.g. vim /etc/netplan/01-netcfg.yaml . Paste the following configuration network : version : 2 renderer : networkd ethernets : enp4s0 : dhcp4 : true This makes the interface managed by networkd instead of the desktop NetworkManager. Fix permissions The new file needs to be readable only by root so fix it's permissions chmod 600 /etc/netplan/01-netcfg.yaml . Enable network service Enable the network service and make it start on boot: systemctl enable systemd-networkd systemctl start systemd-networkd Run netplan Finally, we need to tell Ubuntu to use our new configuration and activate the network netplan generate netplan apply Network should be up! ip a

When you delete files in your virtualbox VM in order to free up space on the host filesystem, this space is not automatically reclaimed. In order for the host system to see the changes you need to rewrite the free space with zeroes. Follow the below steps to perform this operation: Install zerofree package. It is needed to rewrite the free space with zeroes. Mount the filesystem as "readonly". This is needed for the tool to be able to perform it's task. If you're working with the "/", easiest way to mount it as readonly is to edit the kernel parameters. Edit /etc/default/grub . Find the GRUB_CMDLINE_LINUX_DEFAULT line. Add init=/bin/bash to it reboot Run zerofree -v /dev/sdX . This could run for some time, depending on the size of your disk. After it's done, run exec init to finish booting up. Shutdown the VM in order to be able to run the next command which requires a lock on the VDI volume. On the Windows host run VBoxManage.exe modifymedium "path\to\disk.vdi" --compact

I had just aced my mentor’s Docker exam, so of course I thought I understood containers. I had said all the right words: namespaces, cgroups, images, layers, PID 1, Kubernetes Pods. Then I typed my first serious command and Linux reminded me that knowing the nouns is not the same thing as building the thing. $ sudo unshare -p 1 test unshare: failed to execute 1: No such file or directory That was the opening scene. I had not even built anything yet. I had typed the flags wrong and accidentally asked unshare to execute a program called 1 . This was going to be less “implement Docker” and more “let the kernel correct my confidence, one error at a time.” v1: namespaces, or the first time PID 1 lied to me The first version was supposed to be easy: run a process in a new PID namespace and prove it sees itself as PID 1. So I ran the command the way I thought it worked: $ sudo unshare --pid bash # echo $$ 25184 That was not PID 1. That was just embarrassing. The rule I had missed is simple: PID namespaces apply to children. The process that calls unshare --pid does not magically become PID 1. You need to fork. The first child born into the new namespace becomes PID 1. So the working version was: $ sudo unshare --pid --fork bash # echo $$ 1 That one line changed the tone. I was inside a different process universe. The shell thought it was process 1. Signals felt different. Orphans came home to it. Then I ran ps , and got humbled again. # ps -o pid,ppid,comm PID PPID COMMAND 25310 25304 bash 25344 25310 ps That made no sense at first. I was PID 1, but ps was showing host-looking PIDs. The next reveal: ps does not ask the kernel some pure “what processes exist?” question. It reads files. If /proc still points at the host procfs, your tools will tell you the host story. So I remounted /proc from inside the namespace: # mount -t proc proc /proc # ps -o pid,ppid,comm PID PPID COMMAND 1 0 bash 7 1 ps That was when it clicked. The namespace did not become real to my eyes until /pr

I broke my own project on purpose, twice, before it worked. Here's the story. Round one: the debate club My first idea for this hackathon sounded great in my head. Six AI agents, each with a "role" — security, architecture, performance, whatever — and they'd debate each other across multiple rounds before agreeing on a final answer. Like a mini panel of experts arguing it out. I built it. I ran it against some vulnerable test code. It came back with 127 findings. I got excited for about four minutes. Then I actually read them. Maybe three were real. The other 124 were the agents politely agreeing with each other about problems that didn't exist, or restating the same bug five different ways because five different agents happened to notice it. Precision was somewhere around 2%. Worse than a single model working alone. That stung a little, not going to lie. I'd spent days on the debate logic. Round two: quieter, and better So I ripped it apart. No more debate rounds. No more six agents shouting over each other. I went down to four, gave each one exactly one job, and — this is the part that actually fixed things — made them depend on each other in order instead of all firing at once. One agent maps out the code first. Two others use that map to look at security and quality separately. A last one compares what they found, throws out duplicates, and — importantly — actually checks the line numbers against the real file instead of trusting the AI's word for it. Same test file. This time: real vulnerabilities, correctly flagged, nothing made up. Point it at clean code afterward and it correctly said nothing was wrong, which honestly felt like a bigger win than finding the bugs did. The annoying lesson I wanted this project to feel impressive. More agents, more debate, more "look how sophisticated this is." What actually worked was the boring answer: fewer agents, clear roles, one checking the other's work instead of everyone talking at once. I named the final version Synod

I like neofetch / fastfetch , but I wanted one with a genuinely empty dependency graph — nothing pulled from crates.io. So I built purefetch : a small system-info fetcher written entirely in Rust using only std plus raw Linux syscalls. Disclosure up front: purefetch was built largely with AI assistance (Claude Code). I directed the design, and every change was reviewed and tested — including running it on four architectures under QEMU — but most of the code is AI-generated. I'd rather be honest about that than pretend otherwise. _,met$$$$$gg. ooonea@unicorn ,g$$$$$$$$$$$$$$$P. ────────────── ,g$$P" """Y$$.". OS Debian GNU/Linux 13.5 (trixie) x86_64 ,$$P' `$$$. Host ThinkPad P53 (20QQS0JD01) ',$$P ,ggs. `$$b: Kernel 6.12.94+deb13-amd64 `d$$' ,$P"' . $$$ Uptime 6 days, 15 hours, 30 mins $$P d$' , $$P Packages 2477 (dpkg), 1 (flatpak) $$: $$. - ,d$$' Shell zsh 5.9 $$; Y$b._ _,d$P' Display 1920x1080 (eDP-1) Y$$. `.`"Y$$$$P"' DE GNOME 48.7 `$$b "-.__ WM Mutter (Wayland) `Y$$ Terminal kitty 0.41.1 `Y$$. CPU Intel(R) Core(TM) i7-9850H @ 4.60 GHz `$$b. GPU Quadro RTX 3000 `Y$$b. Memory 15.28 GiB / 62.61 GiB (24%) `"Y$b._ Swap 0 B / 8.00 GiB (0%) `""" Disk (/) 8.52 GiB / 489.57 GiB (2%) Locale en_US.UTF-8 Battery 76% (Not charging) Zero dependencies, really No libc crate, no sysinfo , no nix , no color crate — nothing from crates.io. Almost everything is just reading and parsing /proc and /sys . The result is a single ~484 KiB binary that builds offline. The only things std can't do are statfs (disk usage) and ioctl (terminal size / tty check). Instead of pulling in a binding crate, those are issued as raw Linux syscalls via core::arch::asm! : #[cfg(target_arch = "x86_64" )] unsafe fn syscall3 ( n : usize , a1 : usize , a2 : usize , a3 : usize ) -> isize { let ret : isize ; core :: arch :: asm! ( "syscall" , inlateout ( "rax" ) n as isize => ret , in ( "rdi" ) a1 , in ( "rsi" ) a2 , in ( "rdx" ) a3 , out ( "rcx" ) _ , out ( "r11" ) _ , options ( nostack ), ); ret } Four arch

A gente sempre ouve falar que o sistema operacional impede que um processo veja a memória do outro ou que o programa fale diretamente com o hardware, mas normalmente não explicam o "como". Eu sempre achei isso meio mágico até que eu resolvi ir atrás da resposta, e é bem interessante. Vou me basear na arquitetura x86, mas é provável que outras arquiteturas sejam parecidas. O problema: a CPU Pra CPU não existe processo, kernel, sistema operacional. Existe só endereços de memória de onde ela lê a próxima instrução e executa. Se a CPU pode falar direto com a RAM, SSD, teclado, mouse, tela... O que me impede de escrever um programa pra ler suas senhas e tokens direto da RAM? Ou de ler arquivos e alterar arquivos sensíveis direto no SSD? Por outro lado, se o kernel fiscalizasse cada instrução que da CPU antes dela executar, isso seria extremamente lento... Outro problema: os interrupts Se a CPU só executasse sequencialmente, seu sistema poderia executar várias coisas e esquecer de checar se uma tecla foi apertada, se o mouse mexeu, etc... Então certos eventos interrompem o que quer que a CPU esteja fazendo para serem tratados assim que possível. Alguns exemplos de interrupt são: Teclas do teclado pressionadas ou soltas Botões e movimento do mouse Timers Operações de disco assíncronas Pacotes de rede recebidos/transmitidos Uma solução: rings Os processadores da arquitetura x86 tem o esquema de rings. Pense em rings como grau de limitação. Ring 0 significa limitação zero, ou seja, acesso a todas as instruções da CPU e consequentemente acesso total ao hardware e memória. O kernel roda em ring 0, ou kernel mode. O kernel assim que é carregado configura todos os interrupts handlers da CPU para executar o handler apropriado do kernel, em kernel mode, claro. Em ring 3 a CPU fica limitada e não pode fazer instruções consideradas privilegiadas. E obviamente em ring 3 a CPU não consegue se colocar em ring 0 sozinha, pois dessa forma qualquer programa conseguiria se pôr em ring 0. O

Seven days of flow. Fixed a peer identity binding issue in py-libp2p, automated my Neovim lockfile merges, and added a massive batch of notes on xv6 and Category Theory. 10 commits and a solid PR in the works. TL;DR I managed to hit a perfect seven-day streak this week, balancing some deep-dive p2p networking work with necessary maintenance on my local environment. The highlight was opening a PR in py-libp2p to tighten up how PeerRecords are handled in the Kademlia DHT. On the side, I spent time automating the annoying parts of my Neovim config and dumping a fresh batch of notes into my knowledge base. 10 commits, 204 lines added, and a much cleaner workflow to show for it. What I Built Neovim Configuration & CI I’m a firm believer that your editor should work for you, not the other way around. My nvim repo saw a lot of action this week—9 commits in total—but most of it was under-the-hood maintenance. I’ve been leaning on Lua to keep things snappy, and this week was about ensuring my plugin ecosystem doesn't rot. I pushed several updates to keep plugins at their latest versions, but the real "quality of life" improvement was adding a chore to auto-resolve lazy-lock.json merge conflicts. If you’ve ever worked on your Neovim config across multiple machines, you know the headache of the lockfile drifting. I set up a flow to prioritize incoming changes, which saves me from manually triaging JSON diffs every time I pull from dev . It’s a small tweak, but it removes a recurring friction point in my daily flow. I also spent time cleaning up the root of the config, with about 37 additions and 33 deletions—refactoring is a constant process when you live in your terminal. The Knowledge Base I also put some serious time into main-notes . I’m currently going deep on a few different subjects, and I use this repo as my "second brain." I added 167 lines of new material across 13 files, covering a pretty diverse range of topics: xv6 (the re-implementation of Unix V6), Category Theo

I once spent forty minutes at eleven at night debugging a deploy that wasn't broken. The release script ran the database migration, the migration threw connection refused , the script exited non-zero, the deploy rolled itself back, and I got paged. So I did the things you do. I read the migration. I read the logs. I checked the database — it was up, it was healthy, it accepted my connection instantly. I re-ran the deploy and it worked. I chalked it up to gremlins and went to bed, which is the part I'm not proud of, because it happened again two days later. That time I watched the timing: the script brought up a fresh database container and started the migration about six seconds before Postgres finished initializing and began accepting connections. The migration was racing the database's boot. Most of the time it won. The times it lost, I lost forty minutes. The script wasn't wrong about anything except one assumption: that a dependency is ready the instant you ask for it. In production, dependencies are eventually ready That's the mental model shift. Networks blip. A service you call returns a 503 for the two seconds it takes to finish a rolling restart. An API rate-limits you with a 429 it fully expects you to retry. A fresh container's database isn't accepting connections for its first few seconds. Treating the first failure as fatal turns every one of these normal, transient conditions into a paged engineer — and the script that handles them isn't smarter — it declines to give up on the first try. But retrying naively is its own trap. Retry instantly and you hammer a recovering service into staying down. Retry forever and a genuinely dead dependency hangs your script indefinitely. Retry a 404 and you wait a minute to confirm what you already knew. Good retries are bounded, backed off, and selective. A retry function you can reuse anywhere #!/bin/bash # Purpose: survive transient failures instead of dying on the first error set -euo pipefail CHECK = "✓" CROSS = "

I connected one client to a blocking TCP server and held the socket open without sending a single byte. Then I connected a second client and sent it a line of text. The second client sat there for 1.51 seconds with no reply. It got its echo back one millisecond after I closed the first connection. That 1.51 seconds is the reason the other six versions of this server exist. Last week I wrote up why I rebuilt this server seven times : framework knowledge resets every few years, the layer underneath it compounds. That piece stayed at the level of outcomes. This one goes the other way, down into the code and the numbers. The claims that matter here are the kind you can read a hundred times without being able to derive them. "select is O(n)." "epoll only hands you the ready fds." I had read both for years. I wanted to make my own machine say them out loud. The target the whole exercise is built around is Dan Kegel's old C10K problem : how do you serve ten thousand clients at once on one server? Each of the seven versions hits a wall, and the wall is what names the next one. The whole thing is one echo server written seven times, no libraries beyond libc, on GitHub . Every number below is from running it on macOS (Apple clang 21, darwin 25.4) on 2026-06-29. The binaries are built with AddressSanitizer and UBSan on, so read the absolute microseconds loosely. The structure is what holds. Phase 01: blocking, and the 1.5 second stall The first server is the one everybody writes first. Accept a connection, talk to it, close it, accept the next. for (;;) { int client_fd = accept ( server_fd , NULL , NULL ); if ( client_fd == - 1 ) { perror ( "accept" ); continue ; } handle_client ( client_fd ); close ( client_fd ); } handle_client loops on read until the client hangs up. Both accept and read block: when there is nothing to do, the thread sleeps in the kernel. That is good for idle cost and fatal for everything else. While the server is parked in read waiting on client A, client

When something breaks in Linux, experienced engineers don’t guess. They check the logs. 👉 Logs are the “black box recorder” of a Linux system. They tell you: what happened when it happened why it failed If you can read logs properly, you can debug almost anything. What Are Logs? Logs are records of system and application activity. Linux constantly records: System events Errors User activity Application behavior Linux constantly records: Where are Logs Stored? Most Linux logs are stored inside: /var/log Check logs directory: cd /var/log ls This is the first place DevOps engineers check during system issues. Important Log Files Log File Purpose Command to View /var/log/syslog General system messages tail /var/log/syslog /var/log/auth.log Login attempts & authentication tail /var/log/auth.log /var/log/kern.log Kernel & hardware messages dmesg or tail /var/log/kern.log /var/log/nginx/error.log Web server errors (Nginx) tail /var/log/nginx/error.log /var/log/dmesg Boot and hardware logs dmesg /var/log/apache2/ -> Apache logs These logs help you identify system, security, and application-level issues. View Logs Using cat cat /var/log/syslog Good for small files. Using less less /var/log/syslog Useful keys:: Space → Next page b → Previous page q → Quit 👉 Best for large log files. Using tail tail /var/log/syslog Show last 10 lines. Real-Time Monitoring (tail -f) tail -f /var/log/syslog 👉 -f = follow live updates This is one of the most-used debugging commands in production servers. Stop with: Ctrl + C Searching Logs with grep grep error /var/log/syslog Case-insensitive: grep -i failed /var/log/auth.log Show latest matching errors: grep error /var/log/syslog | tail -n 50 👉 Essential for filtering huge logs quickly. Boot & Hardware Logs (dmesg) dmesg Shows: Boot messages Hardware detection Kernel events Useful for startup and hardware troubleshooting. Modern Log System: journalctl Modern Linux systems use systemd logs . journalctl Recent errors: journalctl -xe Specific servic

Overview Tulisan ini menceritakan pengalaman saya meng-install NixOS di VPS Jetorbit memakai nixos-anywhere , dideploy dari laptop macOS (nix-darwin). Komposisi Laptop (macOS + nix-darwin) : Semua konfigurasi NixOS dibuat di sini, lalu dikirim ke server. VPS Jetorbit (x86_64 Linux) : target deploy. Boot lewat legacy BIOS , dengan IP statis (bukan DHCP). nixos-anywhere : dipakai sekali saja untuk install awal. nixos-rebuild : dipakai untuk update konfigurasi setelah install awal. Catatan Penting : VPS tidak perlu menyimpan file konfigurasi sendiri. Kita edit config di laptop, lalu push ke VPS lewat SSH. Tidak ada apt update , tidak ada config drift, dan kondisi server selalu reproducible dari git. Pre-flight: Cek Sebelum Menyentuh Server Banyak kegagalan install sebenarnya bisa dicegah kalau kita cek tiga hal ini: 1. Mode boot: UEFI atau legacy BIOS? Ini menentukan konfigurasi bootloader. Salah konfigurasi di sini dapat menyebabkan GRUB gagal saan install nanti. Di VPS (SSH ke VPS): [ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS" Di Jetorbit secara default adalah BIOS . Artinya konfigurasi GRUB mode legacy BIOS, bukan EFI. 2. Networking: IP, netmask, dan gateway Jetorbit memakai IP statis, bukan DHCP. Kalau konfigurasi NixOS kita set IP maka NixOS akan fallback ke DHCP, dan akan gagal dapat IP, sehingga server jadi tidak bisa diakses sama sekali setelah reboot. Di VPS: ip -4 a # lihat IP + CIDR dan nama interface (misal. ens3) ip route # lihat "default via X.X.X.X", itu gateway-nya Contoh: 2: ens3: ... inet 110.XXX.XXX.XXX/24 brd 110.XXX.XXX.255 scope global ens3 3. SSH Root nixos-anywhere memerlukan akses root ke server untuk bisa melakukan instalasi. Akses ini didapat lewat SSH key, bukan password. Jadi pastikan Di VPS: public key sudah terdaftar di root . Konfigurasi SSH root ini bisa dilakukan saat install OS awal di panel Jetorbit atau dikonfigurasi secara manual di ~/.ssh/authorized_keys . Cara Kerja nixos-anywhere Sebelum menjalankan perintahnya, ada ba

Aprenda a substituir o velho Cron por systemd timers para ganhar logs nativos, controle de dependências e maior robustez.

I am committed to understand how systems actually work. I'm working on a multi-node lab to follow the complete path of a request from Python APIs to Linux processes, through Docker containers, networking and observability. The idea is simple: build a system that observes another system to understand the abstraction layers behind modern infrastructure. This project is about learning by building, experimenting and understanding what happens under the hood. Link: [ https://github.com/daniloprandi/devops-network-automation-lab ] DevOps #Linux #Python #Docker #Networking #Observability #Infrastructure

AI can now scan major open-source projects and surface a batch of real, exploitable vulnerabilities in a single pass. That's a defensive win — until you remember attackers have the same tools. Anthropic, Google, Microsoft, OpenAI, AWS, and 15 other organizations aren't waiting for that race to get worse. On Thursday they launched Akrites under the Linux Foundation — a coordinated body built specifically for AI-era vulnerability discovery, remediation, and disclosure in critical open-source software. What actually changed A shared Security Incident Response Team (SIRT) replaces the fragmented model where multiple orgs independently scan the same libraries, file duplicate CVEs, and bury maintainers in noise Patch first, publish second — findings are held under strict confidentiality until a fix is ready and tested Fallback maintainer coverage — if a project has no active maintainer, Akrites steps in so fixes still reach downstream users Funded by Alpha-Omega , an OpenSSF project with $7M+ annual budget backed by the same founding members Three membership tiers — Premier (critical infra operators), General (contributing orgs), Associate (OSS foundations, free) The name comes from the Akritai — Byzantine soldiers who guarded the empire's outermost borders. The places most exposed, most frequently attacked, and most dependent on whoever showed up to defend them. The problem it's actually solving The current coordinated disclosure model was designed around a world where finding vulnerabilities took weeks of expert work. AI has collapsed that timeline. Endor Labs CEO Varun Badhwar put a number on it: thousands of validated open-source vulns surfaced by AI in recent months, with fewer than 5% patched. And the old model makes it worse — every org independently sitting on knowledge of an unpatched flaw is another leak risk before a fix exists. "For years, we have believed finding vulnerabilities was never the hard part. Fixing them was. AI has made that gap impossible to igno

nginx Event Loop — Complete Lifecycle Reference A precise, bottom-up reference covering every buffer, syscall, interrupt, and data movement from the moment a TCP packet hits the NIC to the moment a response is sent back. Two concurrent users are used throughout as a concrete example. Table of Contents Foundations — fd and Socket Hardware Layer — NIC, DMA, Interrupts Kernel Structures and All Buffers epoll — How the Worker Waits Efficiently nginx Startup Sequence Complete Request Lifecycle — Two Concurrent Users What Happens While Worker is Busy All Buffers — Master Reference All Syscalls — Master Reference Failure Modes 1. Foundations 1.1 Everything is a File Linux's core philosophy: every I/O resource — files on disk, network connections, pipes, terminals, devices — is represented as a file. This means one unified API ( read , write , close ) works on all of them. The kernel manages the actual resource. Your process holds a token. 1.2 File Descriptor (fd) A file descriptor is just an integer . It is a per-process token that refers to a kernel-managed resource. The kernel maintains a table per process called the fd table — a simple array where the index is the fd and the value is a pointer into the kernel. Process fd table: ┌─────┬───────────────────────────────┐ │ fd │ points to │ ├─────┼───────────────────────────────┤ │ 0 │ stdin │ │ 1 │ stdout │ │ 2 │ stderr │ │ 3 │ listen socket (nginx) │ │ 5 │ User A client connection │ │ 6 │ User B client connection │ │ 12 │ backend connection for User A │ │ 13 │ backend connection for User B │ └─────┴───────────────────────────────┘ 0, 1, 2 are always pre-assigned. Application fds start from 3 upward. The fd is meaningless on its own. It only means something when passed to a syscall — the kernel uses it to look up the real resource. 1.3 Socket A socket is the kernel's internal data structure representing one end of a network connection. Created when your process calls socket() . Lives entirely in kernel RAM. Your process nev

Research Context "In advanced network observability, understanding the default behavior of various operating systems is vital for traffic profiling. This article explores the structural differences in ICMP Echo Requests across different OS environments and analyzes how 'Traffic Mimicry' can be used to evaluate the accuracy of Network Intrusion Detection Systems (NIDS)." 1. The Anatomy of an ICMP Signature A standard ICMP Echo Request is not just a simple signal; it carries a specific "fingerprint" based on the operating system that generated it. These fingerprints consist of: Total Packet Size TTL (Time to Live) values Default Payload Content 2. Cross-Platform Discrepancies (Linux vs. Windows) When a system sends a "ping," the default data size ($D$) and the total packet length ($L$) vary significantly between architectures. Feature Linux (Typical) Windows (Typical) Data Size ($D$) 56 Bytes 32 Bytes ICMP Header ($H$) 8 Bytes 8 Bytes Total ICMP Length ($L$) 64 Bytes 40 Bytes Default Payload Timestamp + Data abcdefg... The Linux Signature In most Linux distributions, the ping utility sends 56 bytes of data. When combined with the 8-byte ICMP header, it totals 64 bytes. A key characteristic of Linux ICMP traffic is that the first few bytes of the payload are often occupied by a high-resolution timestamp, used to calculate RTT (Round Trip Time) with microsecond precision. The Windows Signature Windows systems default to a 32-byte data payload. The payload content is static and follows a predictable alphabetical sequence: abcdefghijklmnopqrstuvwabcdefghi. This static nature makes Windows ICMP traffic easily identifiable during deep packet inspection (DPI). 3. The Concept of Traffic Mimicry Traffic Mimicry is a research method used to test the resilience of network filters. By aligning custom communication protocols with the default signatures of a specific OS, researchers can evaluate whether a security appliance is biased toward certain traffic patterns. For example, wh

Research Context When doing low-level network programming in Assembly, you experience firsthand the immense chaos running behind the scenes of operations we solve with a single line in high-level languages (Python, C, etc.). While developing the Nested-ICMP-Communication Analysis project, specifically an Encapsulated ICMP framework, I hit exactly this kind of wall: extracting an IP address from a packet header and printing it to the screen in the correct format. Sounds simple, right? However, when x86 architecture and network protocols are involved, seeing 5.1.168.192 instead of 192.168.1.5 on your terminal is extremely common. So why does this happen, and what kind of algorithm did I develop to overcome this issue during the debugging process? Let's dive into the background. The Endianness Problem in Network Headers When you capture a packet coming over the network and read the source/destination IP address inside the sockaddr_in structure, the data arrives in Network Byte Order (Big-Endian) format. This means the most significant byte is stored at the lowest memory address. However, the x86/x64 processor architectures we use rely on Little-Endian (Host Byte Order). When the processor pulls this 4-byte IP data into a register, the reading direction is effectively reversed for our purposes. The result? A packet that arrives as 192.168.1.5 appears scrambled if we try to naively print it from memory. The inet_ntoa() function in high-level languages handles this conversion in the background. But if you are writing a custom sniffer in pure Assembly, you must do this conversion byte by byte yourself. Debugging Hell: The Problems Encountered While writing this conversion, I encountered a few critical issues that cost me hours in GDB (GNU Debugger): Register Clashes: While separating each octet (byte) of the IP address and converting it to an ASCII character (string), you must use the AX register for division operations (DIV). If you don't carefully manage your remainders

After several years carrying a beta tag, the Kubernetes Security Profiles Operator went 1.0.0 on June 26, freezing eight CRD APIs and clearing a third-party security audit with no criticals. For cluster admins, the practical effect is small but consequential: the syscall and LSM profile a workload runs under is now declared on APIs that will not move under your feet. The release was announced by Sascha Grunert of Red Hat on the CNCF blog. SPO is the Kubernetes operator that manages seccomp, SELinux and AppArmor profiles as cluster-scoped objects, then attaches them to pods. Until now the value proposition was good and the API was provisional. v1.0.0 nails the second half down. What's actually stable All eight CRDs graduated to v1, including SeccompProfile , ProfileRecording , SelinuxProfile , RawSelinuxProfile , and the AppArmor profile type. Conversion webhooks ship with the release, so a cluster running earlier API versions can roll forward without scheduling downtime. The older versions remain available and are slated for removal in a future release. The migration is on the clock, not on fire. The audit pass came with some shape changes that are worth reading before you upgrade. SelinuxProfile swapped its boolean permissive field for a mode enum with Enforcing and Permissive values, which means any GitOps templates that hard-coded permissive: true need a rewrite. RawSelinuxProfile is now gated by an enableRawSelinuxProfiles configuration flag and a validating admission webhook, so the most privileged path through the operator is off by default. AppArmor inputs run through strict regex validation, raw policy payloads are capped at 500 KB, and the eBPF profile recorder picked up explicit resource limits. Why a cluster team should care The point of an operator like this is to take the profile out of the host's filesystem and into the API. That changes the blast radius of "we shipped a container with no profile at all." With SPO and a workload-attached profile, the r

Hi folks! I’m the architect behind WLOADCTL, a commercial workload scheduling system for enterprise automated task orchestration and RPA docking. A quick share of my daily work focus: Distributed task scheduling core development with Java & C Cross-system automation scripts built by Python & Shell Backend frontend based on SpringBoot + Vue3 Edge traffic protection & access optimization using Cloudflare Enterprise RPA integration to automate repetitive backend operations I’ve been tackling a lot of real-world pain points like cross-Linux distro compatibility, high-frequency API access security and mass task concurrency control recently. If you’re working on workload scheduling, backend automation or Cloudflare security tuning, feel free to leave a comment to chat!