Modern Linux distributions are powerful, but they hide the simple truth:
Linux can boot with almost nothing.

In this article, I’ll walk through how to build a tiny Linux system from scratch using:

• A custom-compiled Linux kernel
  - BusyBox as the entire userspace
  - A hand-written `init` script
  - Initramfs as the root filesystem
  - UEFI (systemd-boot) booting
  - QEMU for testing

The goal is not to create a full distribution, but to understand the Linux boot process end-to-end and end up with a system that boots straight into a BusyBox shell.

1. Reproducible Build Environment (Docker)

To keep the host system clean and avoid dependency issues, everything is built inside Docker.

We run Ubuntu in a privileged container and mount a workspace directory from the host so the results persist.

Inside the container, we install only what’s needed to compile the kernel and build an initramfs.

This guarantees that anyone repeating these steps will get the same results.

# Create a docker directory on the Desktop (if it doesn't exist)
# -p flag prevents errors if directory already exists
mkdir -p ~/Desktop/docker

# Change to the docker directory we just created
cd ~/Desktop/docker

# Pull the official Ubuntu Docker image from Docker Hub
sudo docker pull ubuntu

# Run an interactive Ubuntu container with special configurations:
# --privileged: Gives extended privileges to the container (access to devices)
# -it: Interactive mode with terminal access
# --rm: Automatically remove container when it exits
# -v: Mounts host's docker directory to /workspace/ in container (data persistence)
sudo docker run --privileged -it --rm -v ~/Desktop/docker:/workspace/ ubuntu

# Inside the container now - update package list from Ubuntu repositories
apt update

# Install essential development tools and libraries:
apt install -y bzip2 git vim make gcc libncurses-dev flex bison bc cpio libelf-dev libssl-dev

2. Compiling a Minimal Linux Kernel

Before we create any userspace environment, we need the most fundamental component: the Linux kernel itself. This section guides you through compiling a clean, upstream kernel the same codebase “Linus Torvalds” maintains free from distribution-specific patches or vendor modifications.

2.1 Clone the Linux Kernel Source //.

Why Clone from Torvalds’ Repository?
Unlike downloading pre-packaged kernels from distributions like Ubuntu or Fedora, cloning directly from Linus Torvalds’ repository ensures you get:

• Pure upstream code: No distribution-specific patches or modifications
• Latest features: Access to the newest kernel development
• Transparency: Exactly what the kernel developers are working on
• Control: Complete understanding of every component in your system

# Navigate to the shared workspace inside the container
cd /workspace/

# Clone the latest Linux kernel (--depth 1 for minimal download)
git clone --depth 1 https://github.com/torvalds/linux.git

cd linux/

2.2 Configure the Kernel //.

What is Kernel Configuration?
The Linux kernel is a massive project supporting countless hardware architectures, devices, and features. Configuration lets you select exactly which components to include. Think of it as building a custom car: you choose the engine, seats, and features you need, leaving out unnecessary weight.

# Launch the interactive configuration menu inside the container
make menuconfig

Note: For this minimal system, you can simply exit and save without modifications. This creates a default x86_64 configuration.

2.3 Add VGA support

Why VGA Support Matters
Without proper display drivers, your kernel might boot successfully but show nothing on screen. This silent failure is frustrating for beginners. The commands below ensure the kernel can output to QEMU’s virtual VGA display.

• Frame Buffer (FB): Low-level graphics interface
• Framebuffer Console: Display console output on framebuffer
• VGA Console: Classic VGA text mode support
• Virtual Terminal (VT): Multiple console sessions
• Direct Rendering Manager (DRM): Modern graphics framework
• Simple Framebuffer: Minimal graphics for early boot

sed -i 's/# CONFIG_FB is not set/CONFIG_FB=y/' .config
sed -i 's/# CONFIG_FRAMEBUFFER_CONSOLE is not set/CONFIG_FRAMEBUFFER_CONSOLE=y/' .config
sed -i 's/# CONFIG_VGA_CONSOLE is not set/CONFIG_VGA_CONSOLE=y/' .config
sed -i 's/# CONFIG_VT is not set/CONFIG_VT=y/' .config
sed -i 's/# CONFIG_VT_CONSOLE is not set/CONFIG_VT_CONSOLE=y/' .config
sed -i 's/# CONFIG_DRM is not set/CONFIG_DRM=y/' .config
sed -i 's/# CONFIG_DRM_I915 is not set/CONFIG_DRM_I915=y/' .config
sed -i 's/# CONFIG_FB_SIMPLE is not set/CONFIG_FB_SIMPLE=y/' .config

Alternative Approach:
Instead of sed commands, you could use:

# Enable all necessary options in one go
make menuconfig
# Navigate to: Device Drivers → Graphics support
# Enable: Framebuffer, VGA text console, Simple framebuffer

2.4 Compile the Kernel //.

Compiling the kernel transforms millions of lines of C code into a single executable binary. This process involves:

1. Preprocessing: Handling includes and macros
2. Compilation: Converting C to assembly
3. Assembly: Converting to machine code
4. Linking: Combining all objects into one binary

# Compile with parallel processing (adjust -j number based on your CPU cores)
make -j$(nproc)  # Alternative: make -j16 for 16 threads

This produces an extremely small kernel configuration.

2.5 Prepare the Boot Kernel //.

The kernel is now compiled, producing a single file in folder “arch/x86/boot/” with name “bzImage”.

Now we need to copy file to “/workspace/boot-files” so that we can test it with qemu.

# Create boot directory for kernel image
mkdir -p /workspace/boot-files

# Copy the compressed kernel image
cp arch/x86/boot/bzImage /workspace/boot-files/

# Return to workspace root
cd ..

2.6 Test the Kernel (Host Machine) //.

Why Test Without a Root Filesystem?
Testing the kernel alone confirms:

1. Successful compilation without linker errors
2. Basic hardware initialization works
3. Kernel can reach the point of mounting a root filesystem
4. No immediate crashes or hardware incompatibilities

# On your host machine (outside Docker)
cd ~/Desktop/docker/boot-files
qemu-system-x86_64 -kernel bzImage

Expected Result: The kernel should boot and panic with:

Kernel panic - not syncing: No working init found
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

• “No working init found” = Kernel can’t find /sbin/init
• “Unable to mount root fs” = Kernel can’t find ANY filesystem

Both mean: Your kernel works perfectly but has nothing to run!

Next Steps: The kernel is now ready for pairing with a minimal root filesystem to create a complete bootable system.

3. BusyBox: The Entire Userspace

When building a minimal Linux system, you quickly realize that a kernel alone is like an engine without a car. You need a userspace — the collection of utilities that make an operating system usable. This is where BusyBox shines as the ultimate minimalist solution.

What is BusyBox?

BusyBox is often called “The Swiss Army Knife of Embedded Linux.” It’s a single executable that replaces hundreds of standard Unix utilities (ls, cp, grep, init, sh, etc.) in one compact package. While a typical GNU/Linux distribution might have thousands of separate binaries totaling hundreds of megabytes, BusyBox provides the same core functionality in a single binary that can be as small as 1–2 MB.

BusyBox is compiled as a static binary, which is critical. This allows the initramfs to work without shared libraries or dynamic linking.

Once built, BusyBox is installed into a directory that will become the initramfs root.

# Clone BusyBox source
cd /workspace
git clone --depth 1 https://github.com/mirror/busybox
cd busybox

Now that we have the BusyBox source code, we need to configure it for our minimal system and compile it into a static binary. This process is crucial for creating a self-contained userspace.

Essential Configuration //.

# Launch the BusyBox configuration interface
make menuconfig

This opens an ncurses-based menu where we’ll make two critical changes:

1. Enable Static Compilation //.

Navigate to Settings → Build Options and enable:

[*] Build static binary (no shared libs)

Why this matters: A static binary contains all necessary libraries within the executable itself. This means:

• No external dependencies
• Works on any compatible Linux system
• Perfect for initramfs where no libraries exist
• Eliminates “shared library not found” errors at boot

2. Disable Problematic Features //.

Some BusyBox features may cause compilation errors with certain toolchains. To ensure a clean build:

Navigate to Networking Utilities and disable:

[ ] tc (traffic control utility)

tc is a powerful network traffic shaping tool that depends on kernel networking extensions. For our minimal system, we don’t need it, and disabling it prevents potential compilation issues.

Compiling BusyBox //.

# Build BusyBox with parallel compilation
make -j$(nproc)
# Or specify the number of cores:
# make -j16

The Result //.

After successful compilation, you’ll have:

• A single busybox executable (typically 1-2 MB)
• All core Unix utilities embedded within
• Zero external dependencies
• A binary ready for inclusion in our initramfs

4. Creating the Initramfs

With BusyBox compiled, we now need to create a home for our kernel to live in at boot time. This is where the initramfs (initial RAM filesystem) comes in it’s a temporary root filesystem loaded into memory during the early boot process.

What is an Initramfs?

Think of initramfs as a minimal, self-contained environment that the kernel mounts immediately after starting. It’s:

• Temporary: Lives in RAM, disappears after reboot
• Essential: Contains the bare minimum to continue booting
• Flexible: Can include drivers, tools, and setup scripts
• Critical: Without it, the kernel has nowhere to go

Creating the Structure //.

# Create the initramfs directory structure
mkdir -p /workspace/boot-files/initramfs

This single directory will become our entire root filesystem. Every file, directory, and binary needed for boot will live here.

Installing BusyBox //.

# Install BusyBox into our initramfs directory
make CONFIG_PREFIX=/workspace/boot-files/initramfs install

This command does something beautiful: it takes our single busybox binary and creates a complete Unix environment by generating hundreds of symbolic links.

The Magic of Symbolic Links //.

After installation, look inside your initramfs directory:

ls -la /workspace/boot-files/initramfs/bin/

You’ll see something like:

sh -> busybox
ls -> busybox
cp -> busybox
mkdir -> busybox
cat -> busybox
echo -> busybox
init -> busybox
# ... and hundreds more

Each symbolic link points to the same busybox binary. When you run ls, BusyBox checks argv[0] (how it was invoked) and executes the appropriate functionality.

What You Get //.

Your initramfs now contains:

• /bin/busybox — The main executable
• /bin/ — Directory with all utility symlinks
• /usr/bin/ — Additional symlinks for compatibility
• /sbin/ — System administration tools
• /linuxrc — Traditional initramfs entry point

But we’re not done yet! This filesystem is still empty of the critical directories and configuration files needed for a functioning system. In the next step, we’ll:

1. Create essential directories (/dev, /proc, /sys, etc.)
2. Write an init script to set up the environment
3. Package everything into a format the kernel can load

5. Writing the `init` Script: Becoming PID 1

Every Linux system needs an init process—the very first program the kernel launches after boot. In our minimal system, we're creating this process ourselves, and it carries the sacred PID 1 designation. This isn't just another program; it's the ancestor of all future processes and the guardian of the entire system.

Creating the Essentials //.

# Navigate to our initramfs
cd /workspace/boot-files/initramfs/

# Create critical kernel interface directories
mkdir -p proc sys dev

These directories aren’t just folders — they’re communication channels with the kernel:

• /proc: Live system information (processes, memory, hardware)
• /sys: Kernel objects and device information
• /dev: Device files representing hardware

The init Script //.

# Navigate to our initramfs
cd /workspace/boot-files/initramfs/

# Edit file with vim
vim init

#!/bin/busybox sh

# Mount essential filesystems
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev

# Wait for device initialization
sleep 0.2

# CRITICAL: Create VGA console if it doesn't exist
# Only create once (devtmpfs may have already created it)
if [ ! -c /dev/tty0 ]; then
    echo "Creating VGA console /dev/tty0..."
    mknod -m 620 /dev/tty0 c 4 0
fi

# Create other essential devices if they don't exist
if [ ! -c /dev/tty ]; then
    mknod -m 666 /dev/tty c 5 0
fi

if [ ! -c /dev/null ]; then
    mknod -m 666 /dev/null c 1 3
fi

if [ ! -c /dev/zero ]; then
    mknod -m 666 /dev/zero c 1 5
fi

# Set up /dev/pts for pseudo-terminals
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts

# CRITICAL: Force /dev/console to point to VGA (tty0)
# This ensures the system uses VGA instead of serial
ln -sf /dev/tty0 /dev/console

# CRITICAL: Redirect all standard I/O to VGA console
exec 0</dev/tty0
exec 1>/dev/tty0
exec 2>/dev/tty0

# Set up terminal environment
export TERM=linux
export HOME=/root

# Create home directory
mkdir -p /root

# Clear screen and display welcome message
clear
cat <<!

========================================
Welcome to Micro Linux!
Boot took $(cut -d' ' -f1 /proc/uptime) seconds
Running on VGA console (/dev/tty0)
========================================

!

# CRITICAL: Start shell with proper terminal control for VGA
# setsid cttyhack ensures proper job control on VGA console
exec setsid cttyhack /bin/sh

# If shell exits (shouldn't reach here with exec)
echo ""
echo "System shutting down..."
poweroff -f

Finalizing the Setup //.

# Make init executable
chmod +x init

# Remove the default linuxrc symlink
rm linuxrc

The linuxrc symlink is BusyBox's default init, but we want full control over our PID 1 process.

Why This Architecture Matters //.

Our init represents the absolute minimum viable userspace:

• No login prompts
• No services
• No background daemons
• No multi-user support
• Just you and a root shell

This is Linux distilled to its essence: kernel + shell = functional system.

6. Packaging the Initramfs

We’ve built all the pieces: a kernel, BusyBox utilities, and our init script. Now we need to package everything into a single file the kernel can load at boot time. This is where cpio (Copy In, Copy Out) comes in—an ancient but perfect archiving format for initramfs.

The CPIO Format: Why Old-School Works Best //.

While you might be familiar with tar or zip, the kernel expects initramfs in cpio format because:

• Kernel-native: The Linux kernel has built-in cpio extraction
• Simple structure: No complex compression headers
• Streamable: Can be decompressed on-the-fly during boot
• Proven reliability: Used since the early days of Linux

Creating the Archive //.

# Navigate to our initramfs directory
cd /workspace/boot-files/initramfs/

# Package everything into a cpio archive
find . | cpio -o -H newc > ../initramfs.cpio

What’s Happening Internally?

The kernel will:

1. Load initramfs.cpio into memory during boot
2. Automatically extract it to a temporary in-memory filesystem
3. Execute /init as the first process
4. Mount this as the initial root filesystem

Testing Our Complete System //.

Now for the moment of truth — booting our entire homemade Linux:

# On your host machine (outside Docker)
cd ~/Desktop/docker/boot-files

# Launch QEMU with our kernel and initramfs
qemu-system-x86_64 \
    -kernel bzImage \
    -initrd initramfs.cpio \
    -append "console=tty0"

Expected Result: Within seconds, you should see:

Welcome to Micro Linux!
Boot took 0.23 seconds
Running on VGA console (/dev/tty0)
#

The Complete Boot Chain //.

Let’s visualize what you’ve created:

Kernel (bzImage) → Initramfs (cpio) → init Script → BusyBox Shell
    ↓                    ↓                   ↓            ↓
  Hardware          Root Filesystem      PID 1        User Interface
  Initialization   (in memory)         Process         (Your Shell)

7. SYSTEMD-BOOT: A Modern UEFI Boot Loader

When moving beyond simple QEMU testing to real hardware or more sophisticated virtual setups, you’ll need a proper bootloader. systemd-boot (formerly gummiboot) is a minimalist UEFI boot manager that’s perfect for our lightweight system.

Why systemd-boot?

Unlike traditional BIOS bootloaders (GRUB, LILO), systemd-boot is:

• UEFI-native: Directly EFI executable, no intermediate stages
• Minimal: ~100KB vs GRUB’s ~10MB
• Simple: Plaintext configuration files
• Secure: Supports Secure Boot (with proper signing)
• Fast: Boots in milliseconds

Installation Prerequisites //.

# Inside docker
apt install systemd-boot-efi

Locating the EFI Binary //.

The core EFI executable you need is:

• Filename: systemd-bootx64.efi (for x86_64 systems)
• Standard Location: /usr/lib/systemd/boot/efi/systemd-bootx64.efi

# Copy to our boot directory
cp /usr/lib/systemd/boot/efi/systemd-bootx64.efi /workspace/boot-files/

8. Creating a UEFI Disk Image

Now we transform our scattered boot files into a professional, self-contained bootable disk image that can run on real hardware, virtual machines, or be written to USB drives.

The Anatomy of a Bootable UEFI Disk

Our goal is to create a FAT32-formatted disk image containing everything needed to boot:

uefi.img (FAT32 filesystem)
├── EFI/BOOT/BOOTx64.EFI           # UEFI bootloader (systemd-boot)
├── loader/                        # Bootloader configuration
│   ├── loader.conf                # Global settings
│   └── entries/mll-x86_64.conf    # Boot menu entry
└── minimal/x86_64/                # Our system files
    ├── kernel                     # Compressed Linux kernel
    └── rootfs                     # Initramfs with BusyBox

1. Create the Disk Image

# Create a 64MB empty disk image (adjust size as needed)
dd if=/dev/zero of=uefi.img bs=1M count=64

# Setup loop device (virtual block device)
sudo losetup -fP uefi.img
# Find the loop device (usually /dev/loop0)
sudo losetup -a

# Format as FAT32 (UEFI requires FAT filesystem)
sudo mkfs.vfat -F 32 /dev/loop0

2. Mount and Populate the Filesystem

# Create mount point and mount the image
sudo mkdir -p /mnt/uefi
sudo mount /dev/loop0 /mnt/uefi

3. Install Systemd-Boot

# Create UEFI directory structure
sudo mkdir -p /mnt/uefi/EFI/BOOT

# Copy systemd-boot EFI binary (renamed for automatic detection)
sudo cp systemd-bootx64.efi /mnt/uefi/EFI/BOOT/BOOTx64.EFI

Note: UEFI firmware automatically looks for EFI/BOOT/BOOTx64.EFI on FAT partitions.

4. Copy Kernel and Root Filesystem

# Create organized directory for our system
sudo mkdir -p /mnt/uefi/minimal/x86_64

# Copy kernel and initramfs
sudo cp bzImage /mnt/uefi/minimal/x86_64/kernel
sudo cp initramfs.cpio /mnt/uefi/minimal/x86_64/rootfs

5. Configure the Bootloader

# Create loader directory
sudo mkdir -p /mnt/uefi/loader/entries

# Global loader configuration
sudo tee /mnt/uefi/loader/loader.conf > /dev/null << EOF
default mll-x86_64
timeout 3
EOF

# Boot entry configuration
sudo tee /mnt/uefi/loader/entries/mll-x86_64.conf > /dev/null << EOF
title   Minimal Linux (BusyBox)
linux   /minimal/x86_64/kernel
initrd  /minimal/x86_64/rootfs
options console=tty0 vga=791   # VGA text mode 1024x768
EOF

Boot Options Explained:

• console=tty0: Use VGA console (your monitor)
• vga=791: Set 1024×768 text mode (see Linux VGA modes)

6. Finalize and Cleanup

# Ensure all writes are flushed to disk
sync

# Unmount the image
sudo umount /mnt/uefi

# Detach the loop device
sudo losetup -d /dev/loop0

# Optional: Remove mount point
sudo rmdir /mnt/uefi

10. Testing with QEMU (UEFI)

The final image is tested using QEMU with OVMF firmware.

sudo qemu-system-x86_64 -bios OVMF.fd -m 1024 -drive format=raw,file=uefi.img

If the systemd-boot menu appears and the BusyBox shell starts, the system is complete.

Real-World Applications

The same image can then be written directly to a USB drive using `dd` and booted on real hardware.

sudo dd if=uefi.img of=/dev/sdX bs=4M status=progress conv=fsync

Conclusion

This tiny Linux system proves how little is actually required to boot Linux:

- One kernel
- One statically linked binary
- One small script

No systemd.
No package manager.
No disk installation required.

Just Linux — stripped down to its core.

Once you understand this process, everything else in Linux suddenly makes much more sense.

Introduction

I set out to build a man-in-the-middle (MITM) device for the Wiegand protocol, the standard used by RFID readers and access control systems. The goal was to intercept, manipulate, and replay Wiegand traffic using an ESP-07 microcontroller.

To begin, I prototyped the core functionality using an Arduino Uno. Once I verified the signal handling, spoofing, and replay capabilities worked as expected, I transitioned the project to ESP-07, giving me both a compact form factor and Wi-Fi connectivity.

The result is a lightweight but powerful tool that:

• Sniffs Wiegand traffic
• Allows for spoofing and replay attacks
• Offers DoS (Denial-of-Service) capabilities
• Hosts a web-based interface for remote control and monitoring

Why ESP-07?

While Arduino is great for testing, its 5V logic levels aren’t always ideal for working with Wiegand lines, especially when you’re injecting signals into systems that are sensitive to voltage levels. ESP-07 uses 3.3V logic, which better matches the signaling expectations of many readers and controllers.

However, not all ESP GPIOs are safe for use at boot, so I carefully mapped:

• GPIO12 and GPIO13 as Wiegand input pins (from the reader)
• GPIO4 and GPIO5 as Wiegand output pins (to the controller)

Web Interface Features

Once on ESP-07, I added a web server with three main pages:

1. Home (index.html)

This is the control center where you can:

• Add spoofing pairs manually (Original RFID → Target RFID)
• Clear the spoof list
• Trigger a Replay Attack by sending a tag in HEX format
• Start a DoS Attack, flooding the Wiegand line with 0xFFFFFFFF or similar noise

It’s simple, reactive, and easy to use from both desktop and mobile.

2. List (list.html)

This page acts as an access log and spoof management dashboard:

1. Shows all RFID check-ins, including timestamp, RFID, and name

2. Lets you:

• Update the name associated with a tag
• Trigger a replay attack for that user
• Launch a spoof attack
• Clear the entire log (stored in rfidusers.json on the ESP)

3. Chart (chart.html)

Visualizes access trends:

• Heatmap by day and hour showing when tags were scanned
• Helps identify user behavior, common access times, and patterns

Time Synchronization

Since the ESP’s default time starts from epoch 1970-01-01, all pages include:

• Local device time display
• A Sync Epoch button to align ESP time with your current local time

This ensures all access logs and timestamps are accurate.

Easter Egg: A Hacker’s Homage

For those who look closely (Shift + Left Click on the TT logo in the bottom right), the interface hides a tribute to information warfare:

“The world isn’t run by weapons anymore, or energy, or money. It’s run by little ones and zeros… It’s all just electrons.
There’s a war out there, old friend. A world war. And it’s not about who’s got the most bullets. It’s about who controls the information.
What we see and hear, how we work, what we think… it’s all about the information!”
- Whistler

“Too many secrets.”
- Bishop

Because sometimes, your tools need attitude too.

Final Thoughts

What started as a fun experiment with an Arduino evolved into a fully-featured wireless Wiegand MITM platform with a slick interface, attack capabilities, and real-time analysis.

Whether you’re studying access control protocols, doing red teaming, or just exploring embedded systems, this project shows how flexible and powerful the ESP-07 can be when combined with the web.

Let the little ones and zeros do the talking.

You can find the full source code and all project files on GitHub

What if you could brute-force an Android phone’s PIN code using a $5 USB device that pretends to be a keyboard?

That’s the core idea behind the EvilUSB PIN Brute-Force Tool, a project that leverages the Digispark USB (ATtiny85) — a tiny microcontroller that can emulate a USB keyboard — to repeatedly enter PIN codes on older Android phones. With no lockout protections on those legacy devices, brute-forcing becomes surprisingly easy.

What Is This Tool?

The EvilUSB tool automates PIN entry on Android lock screens. It emulates a real keyboard and “types” PINs directly into the device. While newer Android versions are hardened against this kind of attack, many older devices (Android 9 and earlier) are vulnerable, lacking rate limiting or lockout mechanisms after multiple failed attempts.

All you need is a Digispark board, Arduino IDE, and this script.

This tool was built as a technical challenge — to explore the limits of low-cost, low-power devices and test physical security assumptions.

How It Works

• Sends a sequence of commonly used PIN codes.
• Generates additional PINs using date patterns: DDMMYY and MMDDYY.
• Uses CMD + Backspace (Win + Backspace) to quickly reset input and return to the home screen, avoiding stuck or unresponsive states.
• Sends Arrow Up to simulate a swipe-up gesture and bring up the PIN input screen again, speeding up retries and preventing errors.
• Designed for older Android devices without brute-force protections (e.g. no delays or lockouts after failed attempts).

PIN Strategy

This tool offers three different brute-force strategies for unlocking PIN-protected devices:

Version 1: Smart 6-digit attack

• Tries the most common PINs (e.g. 123456, 000000, 111111, etc.)
• Includes date-based PINs, generated using realistic birthdate formats:
• This ensures broader coverage of common user-chosen PINs based on birthdays and important dates.

Version 2: Full 6-digit brute-force

• Attempts every combination from 000000 to 999999

Version 3: Full 4-digit brute-force

• Attempts every combination from 0000 to 9999
• Uses CMD + Backspace to bypass Android error UI and retry faster

Why It Works on Older Devices

This approach is only effective on phones that:

• Don’t lock or delay after multiple failed attempts
• Allow keyboard input via USB
• Don’t randomize PIN pad layout

Limitations

• On newer Android versions (10+), this attack fails due to:
• Timed lockouts
• Data wipe triggers
• Randomized keypad layouts
• Disabled HID inputs from USB
• The brute-force attack is also time-bound. Each 6-digit PIN takes ~2–3 seconds, so attempting all combinations can take days.

In theory, restarting the phone after every ~5 incorrect attempts might reset the retry counter, but this approach is untested and not the goal of this project.

Final Warning: Use Responsibly

This project demonstrates how simple hardware tools can be used for potentially powerful attacks — especially against outdated systems.

But let me be absolutely clear:

Do not use this tool on any device you do not own or have explicit permission to test.
Unauthorized access is illegal, unethical, and could get you arrested.

Instead, use it to better understand digital security and why even “just a PIN” is not enough in 2025.

If you’re interested in embedded hacking, hardware-based security tools, or DIY cybersecurity gadgets, this is a great project to dive into.

Feel free to fork it, improve it, or adapt it to other platforms.

Build a Reliable Offline IoT System with ESP and GSM

Introduction

In some of my projects, I needed a way to control devices remotely via SMS. To achieve this, I created a system using the ESP-07 microcontroller and a SIM800 GSM module. This setup allows the ESP-07 to process incoming SMS messages and control a relay based on the message’s content.

The system is designed to only respond to authorized phone numbers and secret keyword commands to prevent unauthorized access.

This is useful for remote control applications, home automation, or IoT projects.

Components Required

• ESP-07 (ESP8266 based Wi-Fi module)
• SIM800L GSM module
• 2N2222 NPN transistor
• 1N4007 Diodes
• 220Ω & 1kΩ Resistors
• Relay Module (or standalone relay)
• External 3.7V–4.2V Li-Ion Battery

How It Works

1. Initialization: The ESP-07 sets up communication with the SIM800 module and configures it for SMS reception in text mode.
2. SMS Monitoring: The system continuously checks for incoming SMS messages.

• The system extracts the phone number of the sender.
• It compares the sender’s number with a predefined ADMIN_NUMBER.
• It validates that the SMS text matches a predefined SECRET_CODE.

3. Message Processing: When an SMS is received, the content is checked. If it contains SECRET_CODE, the system activates a relay by driving a GPIO high.

4. If either check fails: The system ignores the message and does not perform any action.

Why Phone Number Verification?

Without checking the sender’s phone number, anyone who knows the device’s SIM number could send a malicious SMS and control your system.
By verifying the sender, we ensure that only trusted commands are executed.

Powering the SIM800 GSM Module

When working with the SIM800 GSM module, it’s crucial to provide it with a separate power source. This is because the SIM800 can draw significant current, especially during transmission. The ESP-07 itself operates on 3.3V, but the SIM800 typically requires around 4V-5V to function properly. Hence, a separate 4V-5V power supply is needed to avoid power instability issues.

Circuit Connections

1. SIM800L to ESP-07:

• SIM800 TX -> ESP-07 RX (GPIO4)
• SIM800 RX -> ESP-07 TX (GPIO5)
• SIM800 GND -> ESP-07 GND
• SIM800 VCC -> 4-5V (with appropriate voltage regulation if needed)

                       ESP-07                   SIM800 GSM
                   Microcontroller                Module
                    .-----------.              .-----------.
                    |           |              |           |   VCC 5V
   GND      +-----> | GPIO-15   |     GND      |           |----------->
 -----------+-----> | GND       | -----------> |           |   GND
                    |           |              |           |----------->
                    |           |              |           |
            +-----> | EN        |              |           |
    VCC     +-----> | RST       |              |           |
 -----------+-----> | VCC       |              |           |
                    |           |              |           |
                    |           |              |           |
                    |    RX (4) | -----------> | SIM800 TX |
                    |    TX (5) | -----------> | SIM800 RX |
                    ,-----------,              ,-----------,

Legend:
- EN (Enable):
  - Connect the EN pin of the ESP-07 to 3.3V. 
  - This pin must be high for the ESP-07 to function.

- RST (Reset):
  - Connect the RST pin of the ESP-07 to 3.3V.
  - This ensures the module is not held in reset mode.

- GND: Ensure GND pins of both devices are connected.

- GPIO 15:
  - Connect the GPIO 15 pin of the ESP-07 to GND.
  - This is a boot configuration pin that must be grounded,
    for the ESP-07 to boot into the correct mode.

In the diagram above, we’ve shown how to wire the ESP-07 to the SIM800 while also ensuring the SIM800 has its dedicated power input.

Why Use 2N2222?

The ESP-07 GPIO pins cannot handle the current needed by most relays.
The 2N2222 transistor acts as an amplifier, allowing a small GPIO signal to control a larger load safely and reliably.

A flyback diode across the relay coil is mandatory to prevent damaging voltage spikes.

Relay Control with 2N2222 NPN Transistor

The relay is controlled indirectly via a 2N2222 transistor acting as a switch.
Here’s the basic schematic for connecting the relay:

        +3.3V
          |
          |
          |            Relay VCC
          +---------+-----------+               +----------------------+
          |         |           |               |                      |
          |      .-------.---------------------------.                 |
 Cathode  |      |       |     COM1    NO1     NC1   |                 |
         ___     |       |                           |                LED
  1N4007 / \     | Relay |        Relay Coil         |                 |
         ---     |       |                           |                .-.
   Anode  |      |       |     COM2    NO2     NC2   |                | |
          |      '-------'---------------------------'                | | 220Ω
          |          |                                                '-'
          +----------|                                                 |
                     |                                                GND
                     |
                     | (C) Collector
             1kΩ    |/
ESP GPIO12----------|   2N2222
                    |\
                     | (E) Emitter
                     |
                     |
                     |
                     |
                    GND


2N2222 Emitter (E) ---> GND
2N2222 Collector (C) --> Relay Coil Negative (GND side)
Relay Coil Positive --> +3.3V


Flyback Diode (1N4007)
- Anode → Collector
- Cathode → +3.3V

Key Points:

• GPIO12 HIGH: Turns ON the relay.
• GPIO12 LOW: Turns OFF the relay.
• 1kΩ Resistor: Limits current into the transistor’s base.
• Flyback Diode: Protects the transistor and ESP-07 from voltage spikes generated by the relay coil.

WebShell: A Command-Line Interface in the Browser

ESP-07 also hosts a minimalist web server serving a custom terminal-style interface styled with the Vim Gruvbox theme. It’s more than just eye candy — it replicates the serial communication interface you’d normally use with Arduino IDE, but now you can access it from any browser over Wi-Fi.

Some of the key built-in command groups include:

• help, helpesp, helpsim — General and module-specific help
• espinfo, systemstatus, listfiles — ESP diagnostics
• cmd <AT> — Send raw AT commands to SIM800
• “Fake” Unix commands like vim, nano, dd, ssh that return jokes

Fun Unix Commands with a Twist

To make things more playful, common Linux commands output tech jokes when typed. For example:

• grep → “My love life is like grep — I'm always searching and never finding.”
• sudo → “I would make a joke about sudo, but you'd have to be root to get it.”
• vim → “I entered VIM 3 days ago. Send help.”
• ls → “ls: because I forgot what I just created 5 seconds ago.”

Complete Source Code

(Updated for full phone number and secret code validation)

The complete source code is available on my GitHub, which includes initialization for the GSM module, handling incoming messages, and activating the relay based on authorized conditions. The system ensures that only a specified administrator phone number and secret code can trigger the relay, making it ideal for secure remote control applications in IoT or home automation projects.

Conclusion

Using ESP-07, SIM800L, and a simple relay circuit driven by a 2N2222, you can remotely control any device securely via SMS, only responding to an authorized administrator. You can expand this basic concept to create more complex remote control systems, home automation solutions, or industrial monitoring applications. The combination of GSM connectivity with the ESP-07’s processing power opens up many possibilities for IoT projects.

Inspired by Halt and Catch Fire

While watching the TV series Halt and Catch Fire, I got fascinated by the scene where they dump firmware from a chip. That scene led me down a rabbit hole of research, where I discovered Ben Eater’s amazing guide on working with EEPROMs. Naturally, I had to try it myself.

I decided to work with the CAT28C16AP, an old-school 2K x 8 EEPROM. Here’s how I wired everything up and what I learned from the process.

How It Works

To read or write data from this chip, we have to control its address pins, manage data lines, and toggle a few control pins like CE(Chip Enable), OE(Output Enable), and WE(Write Enable).

Parts Used:

• CAT28C16AP EEPROM
• DIP switches (DIP8 + DIP3 for address lines)
• LEDs for visual output
• 330Ω, 10kΩ
• Push button
• 5V power supply
• Breadboard and jumper wires
• Write pulse: 1nF capacitor, 10kΩ and 680Ω resistors

In Ben Eater’s YouTube guide, he uses a classic RC (resistor-capacitor) circuit to generate a short LOW pulse on the WE (Write Enable) pin of the EEPROM. This pulse needs to fall within the range of 100 to 1000 nanoseconds to be recognized as a valid write operation by the chip.

How does this work?

The capacitor charges and discharges through the resistors when a button is pressed. This creates a brief voltage drop — essentially a clean and controlled LOW signal — on the WE pin. During this moment:

• CE (Chip Enable) must be LOW (always enabled)
• OE (Output Enable) must be HIGH (disabled)
• WE receives the short LOW pulse that triggers the write

This setup ensures that the timing is consistent and reliable, especially when manually triggering a write with a push button.

My Setup (Minimalist Approach):

In my case, I was able to perform writes without using the capacitor. I only used a 10Ω resistor in line with the push button connected to the WE pin.

Even without a dedicated RC circuit, there are parasitic capacitances in the breadboard wiring and the chip itself. These small inherent delays, combined with the physical “bounce” of a mechanical push button, are often enough to create a brief, naturally-occurring LOW pulse. It may not be as clean or predictable as the RC method, but it can still fall within the required 100–1000ns range needed to write data successfully.

Key Connections Explained

Pin Setup

Power & Enable Pins:

• Pin 24 (Vcc) → 5V
• Pin 12 (GND) → GND
• Pin 18 (CE — Chip Enable) → GND (Always LOW to enable the chip)
• Pin 20 (OE — Output Enable), LOW during read operations (enables output on data pins), HIGH during write operations (disables output)
• Pin 21 (WE — Write Enable), HIGH during normal operation, Pulled LOW briefly (100–1000 ns pulse) to perform a write

Address Lines:

We use a combination of an 8-switch DIP (for A0–A7) and a 3-switch DIP (for A8–A10).

• A0-A7 (pins 1–8) to an 8-position DIP switch
• A8-A10 (pins 23,22,19) to a 3-position DIP switch
• Each switch leg has a 10kΩ pull-down resistor when OFF

This setup allows us to easily set the address we want to read or write.

   DIP8 Switch       DIP3 Switch
  +------------+    +------------+
  | A0 - Pin 8 |    | A8 - Pin23 |
  | A1 - Pin 7 |    | A9 - Pin22 |
  | A2 - Pin 6 |    |A10 - Pin19 |
  | ...        |    +------------+
  | A7 - Pin 1 |
  +------------+
  OFF → 10kΩ to GND
  ON  → 5V

Data Lines

These are bidirectional pins used for both reading and writing.

• I/O0-I/O7 (pins 9–11,13–17) to LEDs with 330Ω current-limiting resistors
• OE (pin 20) → LOW (output enable)
• OE (pin 20) → HIGH (output disable)

  +----------------------------------------------+
  |                Data Lines                    |
  +------------+-----------+---------------------+
  | Pin Number | I/O       | Connection          |
  +------------+-----------+---------------------+
  | 9          | I/O0      | LED → 330Ω → GND    |
  | 10         | I/O1      | LED → 330Ω → GND    |
  | 11         | I/O2      | LED → 330Ω → GND    |
  | 13         | I/O3      | LED → 330Ω → GND    |
  | 14         | I/O4      | LED → 330Ω → GND    |
  | 15         | I/O5      | LED → 330Ω → GND    |
  | 16         | I/O6      | LED → 330Ω → GND    |
  | 17         | I/O7      | LED → 330Ω → GND    |
  +------------+-----------+---------------------+

We use LEDs to visually inspect the output data during reads.

When writing, we manually set the desired data bits HIGH by connecting those I/O pins to 5V.

⚠️ The chip doesn’t limit current, so resistors are mandatory when using LEDs.

Reading the Chip

To read data:

1. Set address using DIP switches
2. CE is already low (enabled)
3. OE is pulled low (output enable)
4. The selected byte appears on I/O lines, lighting the LEDs

Writing to the Chip

To write data to the chip:

1. Set OE (Pin 20) HIGH to disable output mode.
2. Connect the data lines (I/O pins) to 5V for bits you want to write as 1.
3. Pulse WE (Pin 21) LOW for 100ns–1000ns to trigger the write.

Conclusion

There’s something magical about seeing data represented physically through blinking LEDs that makes all the abstract concepts concrete.

This project was a fun mix of retro tech, electronics, and a bit of TV inspiration. Reading and writing data to an old EEPROM with just DIP switches and LEDs is both educational and surprisingly satisfying. Big thanks to Halt and Catch Fire and Ben Eater for sparking the idea!

A DIY Guide to Constructing a Wi-Fi Jammer

Introduction

In this article, we’ll discuss how to build a simple Wi-Fi jammer using an ESP32 microcontroller and an NRF24 module. This setup can disrupt Wi-Fi connections within a limited range, making it a useful tool for testing network resilience and security measures. However, it is essential to use this knowledge responsibly and within legal boundaries, as unauthorized jamming of wireless networks is illegal in many countries.

By understanding how Wi-Fi interference works, network administrators and cybersecurity professionals can better safeguard their networks against potential attacks. This project provides a hands-on way to explore signal disruption mechanisms while emphasizing the importance of ethical usage.

Required Components

To build this Wi-Fi jammer, you will need the following components:

• ESP32 microcontroller
• Two NRF24 modules (preferably NRF24L01+ PA/LNA for better range)
• Two 10µF capacitors (to stabilize power supply)
• One push button (for enabling/disabling the jammer)
• SSD1306 OLED display (for displaying jammer status)
• Soldering equipment (for assembling the components)
• Jumper wires and a breadboard (for prototyping before soldering)

1. Wiring the NRF24 Module

• When using the NRF24L01+ PA/LNA, it is essential to ensure proper power supply stabilization, as these modules require more current than standard NRF24L01 modules.
• Adding a Capacitor: To prevent voltage fluctuations that could cause instability, a 10µF capacitor should be soldered between VCC and GND on each NRF24 module.
• Ensuring Correct Polarity: Make sure the capacitor’s positive lead is connected to VCC and the negative lead to GND to avoid damaging the module.

2. Adding a Push Button

• A push button can be connected to the ESP32 to allow users to switch between different jamming modes. This enables the user to toggle between gradual channel change mode and random channel change mode without having to reprogram the device.

3. Integrating the SSD1306 OLED Display

• The SSD1306 OLED display will be used to show the jammer’s current mode and status.
• It has a 128x64 pixel resolution.
• Uses I2C communication, making it simple to connect to the ESP32.
• Consumes minimal power, making it suitable for portable projects.

4. Software and Implementation

• The ESP32 will control the NRF24 modules and send disruptive signals on the targeted frequency bands. This is accomplished by repeatedly transmitting packets that interfere with Wi-Fi communication in the 2.4 GHz spectrum.

The basic steps for implementation include:

1. Uploading the code to the ESP32, which can be downloaded from GitHub.
2. Initializing the NRF24 modules and setting them to broadcast mode.
3. Configuring the ESP32 to send repeated packets to disrupt Wi-Fi signals.
4. Displaying jammer mode on the OLED screen.
5. Implementing a push button to switch between jamming modes.

Testing and Results

The jammer has been tested on the following devices:

• CAT S42 smartphone
• POCO X3 smartphone
• TP-Link TL-WN722N Wi-Fi adapter

In each case, the jammer successfully disrupted Wi-Fi connections within its operational range. However, its effectiveness varies depending on network congestion and environmental factors.

Legal and Ethical Considerations

While this project serves as an educational experiment in wireless communication and cybersecurity, it is crucial to comply with local laws regarding wireless signal interference. In many countries, operating a Wi-Fi jammer is illegal and can lead to severe penalties.

Ethical hacking and cybersecurity research should always be conducted in controlled environments, such as a personal lab, with explicit permission from network administrators.

Conclusion

This project demonstrates how Wi-Fi interference works and highlights the limitations of jamming in real-world scenarios. Understanding such mechanisms is valuable for improving network security and developing more resilient communication protocols.

However, this knowledge should only be used for educational and legal purposes. Unauthorized use of jamming devices may be illegal in your country, so always ensure compliance with the law before attempting such experiments.

Disclaimer: This article is for educational purposes only. The author does not endorse or encourage illegal activities. Always use this knowledge responsibly.

Transforming a Laptop into a Stealth Command Execution Center with ESP-07 and CH9329

Building upon the stealth capabilities of the ESP-07 module, let’s dive into another intriguing implementation — leveraging the CH9329 TTL serial to USB HID chip for command execution. By replacing the Arduino Pro Micro with the CH9329, we unlock a simpler yet powerful alternative, making the system even more compact while retaining all essential functionalities.

The complete code for this project is available on GitHub, allowing you to explore, modify, and implement it for your specific use case.

The Concept

The CH9329 acts as a USB HID device capable of emulating keyboard inputs, much like the Arduino Pro Micro. Coupled with the ESP-07 module, it enables wireless command execution while minimizing complexity. The CH9329 eliminates the need for programming a microcontroller (Arduino Pro Micro), as it operates natively as a bridge between the ESP-07 and the host computer.

Voltage Compatibility

The ESP-07 operates at 3.3V logic, while the CH9329 provides a 5V output for powering other devices. However, since the ESP-07 only requires 3.3V, two diodes are used in series to step down the voltage from 5V to approximately 3.3V.

Importantly, when connecting the ESP-07 TX to the CH9329 RX, no voltage divider is needed because, the CH9329 RX pin can directly handle the 3.3V UART signal from the ESP-07 TX pin, so no level shifting is required.

Connection Diagram

Here’s the wiring for ESP-07 and CH9329 integration:

      CH 9329                                ESP-07  
       ______________                           ___________
      |              |                         |           |  
      |              |                 +-----> | GPIO 15   |  
      |         GND  | <---------------+-----> | GND       |  
      |              |                         |           |  
      |              |                         |           |  
      |              |                 +-----> | EN        |  
      |              |                 +-----> | RST       |  
      |       VCC-5V | <---|>|--|>|----+-----> | VCC       |  
      |              |  2 x (1N4007)           |           |  
      |              |                         |           |  
      |              |                         |           |  
      |     UART RX  | <---------------------> | TX (5)    |  
      |              |                         |           |  
      |______________|                         |___________|


Legend:
- Power Connection:
  - Use two diodes in series (1N4007) to drop VCC from 5V to 3.3V for ESP-07.

- Communication:
  - ESP-07 TX (3.3V)   → Direct Connection → CH9329 RX


- EN (Enable):
  - Connect the EN pin of the ESP-07 to 3.3V. 
  - This pin must be high for the ESP-07 to function.

- RST (Reset):
  - Connect the RST pin of the ESP-07 to 3.3V.
  - This ensures the module is not held in reset mode.

- GND: Ensure GND pins of both devices are connected.

- GPIO 15:
  - Connect the GPIO 15 pin of the ESP-07 to GND.
  - This is a boot configuration pin that must be grounded,
    for the ESP-07 to boot into the correct mode.

Simplified Design: By omitting the CH9329 TX to ESP-07 RX connection, no voltage divider is needed, reducing complexity while maintaining functionality.

Command Processing

The CH9329 interprets UART commands sent by a host device like the ESP-07 and translates them into keyboard actions.

We’ll break down a piece of code designed to send keyboard commands using the CH9329 chip, which is commonly used for USB HID (Human Interface Device) emulation.

Sending Strings as Keystrokes

This function allows you to send entire strings of text, making it useful for automating text input. It iterates through each character in the input string and maps it to the corresponding HID keycode and modifier (e.g., Shift for uppercase letters). It then sends the keystroke using sendKeyCommand and releases the keys immediately after.

void sendString(const char *text) {
    while (*text) {
        uint8_t keycode = 0, modifier = 0;
        char c = *text++;

        // Mapping characters to HID codes
        if (c >= 'a' && c <= 'z') {
            keycode = 0x04 + (c - 'a');
        } else if (c >= 'A' && c <= 'Z') {
            keycode = 0x04 + (c - 'A');
            modifier = 0x02;  // Shift modifier
        } else if (c >= '1' && c <= '9') {
            keycode = 0x1E + (c - '1');
        } else if (c == '0') {
            keycode = 0x27;
        } else if (c == ' ') {
            keycode = 0x2C;
        } else if (c == '\n') {
            keycode = 0x28;
        } else {
            // Handle special characters
            switch (c) {
                case '!': modifier = 0x02; keycode = 0x1E; break;
                case '@': modifier = 0x02; keycode = 0x1F; break;
                // ... (other special characters)
                default: continue;  // Ignore unsupported characters
            }
        }

        if (keycode) {
            sendKeyCommand(modifier, keycode);
            delay(5);
            releaseKeys();
        }
    }
}

Sending Keyboard Commands

This function allows you to send individual keystrokes, including combinations like Shift+A or Ctrl+C. It constructs a command array that includes a header (0x57, 0xAB), the modifier (e.g., Shift, Alt, Ctrl), and the keycode (e.g., 'A', 'B', 'Enter'). The sendCommand function is then called to send this array to the CH9329 chip.

void sendKeyCommand(uint8_t modifier, uint8_t keycode) {
    const uint8_t command[] = { 0x57, 0xAB, 0x00, 0x02, 0x08, modifier, 0x00, keycode, 0x00, 0x00, 0x00, 0x00, 0x00 };
    sendCommand(command, sizeof(command));
}

Sending Commands to CH9329

This function is the backbone of communication with the CH9329 chip, ensuring that commands are sent correctly and reliably. It first prints the command bytes in hexadecimal format for debugging purposes. It then writes the command bytes to the CH9329 chip via the CH9329_SERIAL interface. After sending the command, it appends the checksum and flushes the serial buffer to ensure all data is sent. A small delay (delay(10)) is added to prevent overwhelming the chip.

void sendCommand(const uint8_t *command, size_t length) {
    Serial.print("Sending command: ");
    for (size_t i = 0; i < length; i++) {
        Serial.print(command[i], HEX);
        Serial.print(" ");
    }
    Serial.println();

    CH9329_SERIAL.write(command, length);
    CH9329_SERIAL.write(calculateChecksum(command, length));
    CH9329_SERIAL.flush();

    delay(10);
}

This code provides a robust way to emulate keyboard input using the CH9329 chip. By breaking down the functionality into smaller, reusable functions, it becomes easy to send individual keystrokes, strings, or even complex key combinations. Whether you’re automating tasks or building a custom input device, this code serves as a solid foundation for interacting with a computer via USB HID.

HTML Interface for Command Control

Users can choose from various reverse shell methods based on their requirements.

• The chosen parameters are transmitted to the CH9329 via the ESP-07, enabling execution of commands.
• By default, the system uses the hardcoded AP values:
  SSID: ESP8266-Access-Point
  Password: 123456789

Demonstration

In this demonstration, we’ll connect our laptop to the ESP-07, which acts as an access point. After we connect with the default credentials, we’ll select a reverse shell and press “Run Shell”. Then, we’ll wait for the connection on the laptop. For simplicity, we’ll use the loopback address to simulate the connection.

Conclusion

The CH9329 offers several advantages for keyboard emulation projects. Its simplified design eliminates the need for a dedicated microcontroller, reducing complexity and power consumption. With native HID support, it functions as a keyboard without requiring additional software libraries. Additionally, its compact size makes it ideal for space-constrained applications, including discreet or embedded systems. These benefits make the CH9329 a powerful choice for automation, scripting, and hardware-based keystroke injection.

By replacing the Arduino Pro Micro with the CH9329, this project achieves an even more streamlined and efficient design. Coupled with the ESP-07, it retains all core functionalities while reducing complexity. Whether for security research, education, or innovative applications, this approach exemplifies the versatility of modern embedded systems.

With these enhancements, you’re not just creating a covert command center — you’re pushing the boundaries of what compact, DIY hardware can accomplish.

Transforming a Laptop into a Stealth Command Execution Center with ESP-07 and Arduino Pro Micro

Have you ever wanted to turn a laptop into a covert command execution center? In this project, we’ll explore how to combine the ESP-07 Wi-Fi module and an Arduino Pro Micro to create a stealthy, powerful tool that can wirelessly execute commands, including reverse shells, while remaining hidden within your laptop.

The Concept

The ESP-07 module serves as a Wi-Fi access point, enabling remote devices like smartphones or laptops to send commands wirelessly. These commands are then processed and executed by the Arduino Pro Micro, which can emulate a keyboard using the HID (Human Interface Device) protocol. The Arduino remains hidden inside the laptop, interfacing seamlessly through a small USB hub that preserves the laptop’s USB functionality.

The complete code for this project is available on GitHub, allowing you to explore, modify, and implement it for your specific use case.

Hardware Setup

Voltage Compatibility

To ensure smooth communication between the Arduino Pro Micro and the ESP-07, it’s important to address their differing voltage levels:

• Arduino Pro Micro: Operates at 5V logic.
• ESP-07: Operates at 3.3V logic.

You can resolve this difference using a voltage divider made from resistors (3.3kΩ and 2.2kΩ) to drop the Arduino’s 5V signal to 3.3V. The connection scheme includes:

• Arduino TX (5V) → Voltage Divider → ESP RX (3.3V).
• ESP TX (3.3V) → Arduino RX (5V tolerant) (direct connection).

Serial Communication Pins

The devices communicate via serial ports:

• ESP-07: Pin 4 (RX), Pin 5 (TX).
• Arduino Pro Micro: Pin 14 (RX), Pin 16 (TX).

To structure the data exchange, commands are formatted in JSON, ensuring easy parsing and flexibility.

Connection diagram example:

        Arduino Pro Micro                            ESP-07
       __________________                           __________
      |                  |                         |          |
      |                  |                 +-----> | GPIO 15  |
      |             GND  | <---------------+-----> | GND      |
      |                  |                         |          |
      |                  |                         |          |
      |                  |                         |          |
      |                  |                 +-----> | EN       |
      |                  |                 +-----> | RST      |
      |             VCC  | <---|>|--|>|----+-----> | VCC      |
      |                  |  2 x (1N4007)           |          |
      |                  |                         |          |
      |                  |                         |          |
      |             TX16 | <-- Voltage Divider --> | RX (4)   |
      |                  |                         |          |
      |             RX14 | <---------------------> | TX (5)   |
      |                  |                         |          |
      |__________________|                         |__________|





Voltage Divider Example:
    Arduino TX (5V) ----- R1 (2.2kΩ) ----- ESP RX (3.3V)
                                  |
                              R2 (3.3kΩ)
                                  |
                                 GND


Legend:
- Power Connection:
  - If using a 5V Arduino Pro Micro, use two diodes in series (1N4007)
    to drop VCC from 5V to 3.3V for ESP-07.

- Communication:
  - Arduino TX (5V) → Voltage Divider   → ESP RX (3.3V).
  - ESP TX (3.3V)   → Direct Connection → Arduino RX

- Voltage Divider: Ensure the lower resistor (R2) connects to GND to 
  properly drop the voltage.

- EN (Enable):
  - Connect the EN pin of the ESP-07 to 3.3V. 
  - This pin must be high for the ESP-07 to function.

- RST (Reset):
  - Connect the RST pin of the ESP-07 to 3.3V.
  - This ensures the module is not held in reset mode.

- GND: Ensure GND pins of both devices are connected.

- GPIO 15:
  - Connect the GPIO 15 pin of the ESP-07 to GND.
  - This is a boot configuration pin that must be grounded,
    for the ESP-07 to boot into the correct mode.

Powering the ESP-07

When powering the ESP-07 directly from the Arduino’s VCC pin:

• If you are using a 5V Arduino Pro Micro, the ESP-07 cannot handle 5V on its power line as it lacks a built-in voltage regulator. In this case, you must lower the voltage to 3.3V using two diodes in series (e.g., 1N4007) to drop the voltage to a safe level.

Integration

The ESP-07 and Arduino Pro Micro can be embedded inside the laptop’s casing or within peripherals like a keyboard if space allows or behind the computer motherboard. The stealthy design ensures the setup remains inconspicuous while maintaining full functionality.

Key Functionalities

Serial-to-HID Bridge

The core of this project is the Serial-to-HID bridge, which translates serial data into simulated keyboard inputs:

1. The ESP-07 sends commands via the serial port using the Serial library.
2. The Arduino receives the data, interprets it, and emulates keyboard inputs using the HID library.
3. The host computer perceives these inputs as if they came from a physical keyboard.

This approach enables seamless remote control of the laptop without the need for additional software on the host machine.

HTML Interface for Command Control

The ESP-07 hosts an HTML interface that allows users to:

• Log in with credentials.
• Specify details for reverse shell commands (IP address, port, and shell type).

Reverse Shell Types

Users can choose from various reverse shell methods based on their requirements:

• bash: Uses Netcat to send data over TCP.
• mkfifo: Employs named pipes for communication in restricted environments.
• nc-e: Leverages Netcat’s “-e” flag to execute shells.
• python3: Creates a Python-based TCP connection.
• socat: Establishes a two-way connection with pseudo-TTY support.

The chosen parameters are transmitted to the Arduino via the ESP-07, enabling precise execution of commands.

Wi-Fi Settings

The HTML interface also includes a dedicated page for configuring the ESP-07’s Wi-Fi settings, such as SSID and password.

By default, the system uses the hardcoded values:
SSID: ESP8266-Access-Point
Password: 123456789

These default credentials are essential for the first-time login, ensuring users can access the device without additional setup.

Once logged in, the interface provides the flexibility to set a custom SSID and password. However, it’s important to note that these changes are only valid until the device is restarted. After a reboot, the system reverts to the default credentials, maintaining a consistent and reliable fallback for future access.

Demonstration

In this demonstration, we’ll connect our phone or laptop to the ESP-07, which acts as an access point. After logging in with the default credentials, we’ll select a reverse shell and press “Run.” Then, we’ll wait for the connection on the laptop. For simplicity, we’ll use the loopback address to simulate the connection.

Conclusion

By combining the ESP-07 and Arduino Pro Micro, you can transform an ordinary laptop into a covert, Wi-Fi-enabled command center. This project demonstrates the power of integrating hardware and software to create unique, practical solutions for remote command execution. Whether for education, research, or creative tinkering, this DIY project opens the door to endless possibilities.

Creating a prototype with Arduino can be an exciting and educational way to explore various aspects of electronics and programming. In this project, we will focus on building a system for cloning RFID cards using an Arduino. The project involves using a button, an OLED display, and an RFID reader. Each of these components has its specific role, connection method, and required libraries. This article will provide technical details on connecting and using each of these components.

To use the OLED display and RFID reader with Arduino, you’ll need to install the required libraries in the Arduino IDE. Here’s a step-by-step guide to installing the necessary libraries: Adafruit_GFX, Adafruit_SSD1306, and MFRC522.

Installing Libraries in Arduino IDE

1. Open Arduino IDE:
- Launch the Arduino IDE on your computer.

2. Open the Library Manager:
- Go to Sketch > Include Library > Manage Libraries…. This will open the Library Manager.

3. Install Adafruit GFX Library:
- In the Library Manager, type “Adafruit GFX” in the search bar.
- Find the Adafruit GFX Library in the list of results.
- Click on the library entry, then click the Install button. Wait for the installation to complete.

4. Install Adafruit SSD1306 Library:
- In the Library Manager, type “Adafruit SSD1306” in the search bar.
- Find the Adafruit SSD1306 in the list of results.
- Click on the library entry, then click the Install button. Wait for the installation to complete.

5. Install MFRC522 Library:
- In the Library Manager, type “MFRC522” in the search bar.
- Find the MFRC522 library by Miguel Balboa in the list of results.
- Click on the library entry, then click the Install button. Wait for the installation to complete.

Button

The button is a basic input component that will be used to initiate the process of reading and cloning an RFID card. In this project, the button is connected to pin 2 on the Arduino, with the other end connected to GND.

Required Equipment and Connection:

• Button: Connect one pin to pin 2 on the Arduino and the other to GND.
• Internal Pull-up Resistor: Enabled in the code, so no additional wiring is needed.

#define BUTTON_PIN 2
pinMode(BUTTON_PIN, INPUT_PULLUP);

OLED Display

The OLED display will be used to show information about the system status and the read card’s UID. We are using an SSD1306 OLED display, which communicates via the I2C protocol.

Required Equipment and Connection:

• OLED Display: Connect SDA and SCL pins to the corresponding pins on the Arduino.
• Pins: SDA to A4, SCL to A5 (for Arduino Uno).

Required Libraries:

• Adafruit_GFX
• Adafruit_SSD1306

#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 64
#define OLED_RESET 4

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);

RFID Reader

The RFID reader is used for reading from and writing to RFID cards. In this project, we are using the MFRC522 RFID module. The module connects via the SPI protocol.

For the RFID reader (MFRC522) connected to the Arduino, the following pin configuration is used:

SDA (SS) — Connect to digital pin 10 on the Arduino.
SCK — Connect to digital pin 13 on the Arduino.
MOSI — Connect to digital pin 11 on the Arduino.
MISO — Connect to digital pin 12 on the Arduino.
RST (Reset) — Connect to digital pin 5 on the Arduino.
GND — Connect to the ground (GND) pin on the Arduino.
VCC — Connect to the 3.3V pin on the Arduino.

This configuration uses the SPI communication protocol, where:

• SDA (SS) serves as the Slave Select pin, allowing the Arduino to communicate with the RFID reader.
• SCK (Serial Clock) provides the clock pulses used to synchronize data transmission.
• MOSI (Master Out Slave In) is used to send data from the Arduino (master) to the RFID reader (slave).
• MISO (Master In Slave Out) is used to send data from the RFID reader (slave) to the Arduino (master).

Make sure to connect these pins correctly to ensure proper communication between the Arduino and the RFID reader.

Required Library: MFRC522

#define RST_PIN 5
#define SS_PIN 10
MFRC522 mfrc522(SS_PIN, RST_PIN);

Final Code

In this section, we’ll review the complete code for the RFID cloning project using Arduino. The code integrates the functionality of the button, OLED display, and RFID reader to create a seamless experience for reading and cloning RFID cards. Here’s a breakdown of the final code and its components:

#include <SPI.h>
#include <MFRC522.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define RST_PIN         5          // Configurable, see typical pin layout above
#define SS_PIN          10         // Configurable, see typical pin layout above
#define BUTTON_PIN      2          // Pin connected to the button

#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 64 // OLED display height, in pixels

// Declaration for an SSD1306 display connected to I2C (SDA, SCL pins)
#define OLED_RESET     4 // Reset pin # (or -1 if sharing Arduino reset pin)
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);


MFRC522 mfrc522(SS_PIN, RST_PIN);  // Create MFRC522 instance

MFRC522::Uid storedUid;            // Variable to store UID of read card
MFRC522::Uid NewStoredUid;            // Variable to store UID of read card

bool cardRead = false;             // Flag to indicate if card has been read

void setup() {
  Serial.begin(9600);              // Initialize serial communications with the PC
  while (!Serial);                 // Do nothing if no serial port is opened (added for ATMEGA32U4)

  // SSD1306_SWITCHCAPVCC = generate display voltage from 3.3V internally
  if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) { // Old Address 0x3D for 128x64
    Serial.println(F("SSD1306 allocation failed"));
    for(;;); // Don't proceed, loop forever
  }

// Initialise variables
  int x0 = 5; // 3 pairs of co-ordinates
  int y0 = 5;
  int x1 = 120;
  int y1 = 23;
  int x2 = 55;
  int y2 = 60;
  int w = 105; // width
  int h = 55;  // height
  int r = 25;  // radius
  int cw = SSD1306_WHITE; // colour white
  int cb = SSD1306_BLACK; // colour black
  int wait = 2000; // 2 second delay
  
// Title screen
  display.clearDisplay();
  display.setTextSize(1);             // Normal 1:1 pixel scale
  display.setTextColor(cw);
  display.setCursor(28,25);
  display.println("Clone RFID");
  display.display(); delay(wait);
  randomSeed(analogRead(3));
  display.fillScreen(cw);              // Fill screen WHITE
  display.display(); delay(wait); 
  display.fillScreen(cb);              // Fill screen BLACK
  display.display();
  
// Pixels
  for (int i = 0; i <= 25; i++)  {     // 25 random pixels
    int xx = random(127);
    int yy = random(63);
    display.drawPixel(xx, yy, cw);
    display.display();
    delay(200);
  }

  display.clearDisplay();
  display.setTextSize(1);             // Normal 1:1 pixel scale
  display.setTextColor(cw);
  display.setCursor(10,20);
  display.println("Press button to");
  display.setCursor(10,40);
  display.println("read card...");
  display.display();


  
  SPI.begin();                     // Init SPI bus
  mfrc522.PCD_Init();              // Init MFRC522
  pinMode(BUTTON_PIN, INPUT_PULLUP); // Initialize button pin as input with internal pull-up resistor

  Serial.println(F("Press button to read card..."));
}

void loop() {
  if (digitalRead(BUTTON_PIN) == LOW) { // Check if button is pressed
    delay(200);                        // Debounce delay

    if (!cardRead) {
      readCard();
    } else {
      writeCard();
    }

    while (digitalRead(BUTTON_PIN) == LOW); // Wait for button release
  }
}

void readCard() {
  if (mfrc522.PICC_IsNewCardPresent() && mfrc522.PICC_ReadCardSerial()) {
    // Copy the UID of the card to storedUid
    storedUid = mfrc522.uid;

    display.clearDisplay();
    display.setTextSize(1);             // Normal 1:1 pixel scale
    display.setTextColor(SSD1306_WHITE);
    display.setCursor(15,20);             
    display.println("Card read. UID: ");
    
    display.setCursor(15,40);             
    // Display UID in hex format
    for (byte i = 0; i < storedUid.size; i++) {
      if (storedUid.uidByte[i] < 0x10) {
        display.print("0"); // Dodaj '0' za jednocifrene vrednosti
      }
      display.print(storedUid.uidByte[i], HEX);
      if (i < storedUid.size - 1) {
        display.print(" ");
      }
    }
    display.display();
    
    Serial.print(F("Card read. UID: "));
    for (byte i = 0; i < storedUid.size; i++) {
      Serial.print(storedUid.uidByte[i] < 0x10 ? " 0" : " ");
      Serial.print(storedUid.uidByte[i], HEX);
    }
    Serial.println();
    
    // Dump debug info about the card; PICC_HaltA() is automatically called
    //mfrc522.PICC_DumpToSerial(&(mfrc522.uid));

    delay(5000); 
    
    display.clearDisplay();
    display.setTextSize(1);             // Normal 1:1 pixel scale
    display.setTextColor(SSD1306_WHITE);
    
    display.setCursor(10,10);             
    display.println("Press button again");

    display.setCursor(10,30);             
    display.println("to write");

    display.setCursor(10,50);             
    display.println("to new card...");
    display.display();

    
    Serial.println(F("Press button again to write to new card..."));
    cardRead = true;
    mfrc522.PICC_HaltA(); // Halt the card
  }
}


void writeCard() {
  // Ensure the card is present and read it again
  if (!mfrc522.PICC_IsNewCardPresent() || !mfrc522.PICC_ReadCardSerial()) {
    Serial.println(F("Failed to re-read card."));
    return;
  }

  // Prepare new UID from storedUid
  byte newUid[4];
  for (byte i = 0; i < 4; i++) {
    newUid[i] = storedUid.uidByte[i]; // Copy each byte from storedUid to newUid
  }

  
  // Set new UID
  if ( mfrc522.MIFARE_SetUid(newUid, (byte)4, true) ) {
    Serial.println(F("Wrote new UID to card."));
  }

  display.clearDisplay();
  display.setTextSize(1);             // Normal 1:1 pixel scale
  display.setTextColor(SSD1306_WHITE);
  
  display.setCursor(10,30);             
  display.println("Cloning done...");
  display.display();
  delay(4000);  

  
  // Halt PICC and re-select it so DumpToSerial doesn't get confused
  mfrc522.PICC_HaltA();
  if ( ! mfrc522.PICC_IsNewCardPresent() || ! mfrc522.PICC_ReadCardSerial() ) {
    return;
  }
  
  // Dump the new memory contents
  Serial.println(F("New UID and contents:"));
  mfrc522.PICC_DumpToSerial(&(mfrc522.uid));

  
  NewStoredUid = mfrc522.uid;
  display.clearDisplay();
  display.setTextSize(1);             // Normal 1:1 pixel scale
  display.setTextColor(SSD1306_WHITE);
  display.setCursor(15,20);             
  display.println("New card UID: ");
  
  display.setCursor(15,40);             
  // Display UID in hex format
  for (byte i = 0; i < NewStoredUid.size; i++) {
    if (NewStoredUid.uidByte[i] < 0x10) {
      display.print("0"); // Dodaj '0' za jednocifrene vrednosti
    }
    display.print(NewStoredUid.uidByte[i], HEX);
    if (i < NewStoredUid.size - 1) {
      display.print(" ");
    }
  }
  display.display(); 

  
  delay(2000);  
}

1. Secure BIOS

Securing the BIOS and disabling USB booting are essential steps to enhance the security of your system by preventing unauthorized access and booting from external devices.

• Set a BIOS/UEFI Password
• Disable USB Booting

2. Hard Disk Encryption

Encrypting your hard disk is a crucial step in protecting your data from unauthorized access. Below are steps to encrypt a hard disk on a Linux system using LUKS (Linux Unified Key Setup).

3. Disable USB Usage on Linux

Disabling USB usage can be an effective way to prevent unauthorized data transfer and improve system security. Below are different methods to disable USB usage on a Linux system.

Using USBGuard to Secure USB Usage

USBGuard is a software framework for managing access control for USB devices. It allows you to define and enforce policies to control the access of USB devices on your system.

sudo apt-get update
sudo apt-get install usbguard

To create a default policy that allows currently connected USB devices, run:

sudo usbguard generate-policy -X >/etc/usbguard/rules.conf

Start and Enable USBGuard Service

sudo systemctl start usbguard
sudo systemctl enable usbguard

Block USB storage devices using a udev rule

To block USB storage devices using a udev rule, you can create a rule that prevents the usb-storage driver from being used by these devices. The following rule will do this by unbinding the device when it is added.

1. Create a new file in /etc/udev/rules.d/, e.g., 99-usb-storage.rules

sudo vim /etc/udev/rules.d/99-usb-storage.rules

2. Add the Rule to Block USB Storage Devices:

ACTION=="add", SUBSYSTEM=="block", SUBSYSTEMS=="usb", DRIVERS=="usb-storage", RUN+="/bin/sh -c 'echo 1 > /sys$env{DEVPATH}/authorized'"

Here’s a breakdown of the components of this udev rule:

• ACTION=="add": The rule applies when a new device is added to the system.
• SUBSYSTEM=="block": The rule applies to devices in the "block" subsystem, which includes storage devices.
• SUBSYSTEMS=="usb": The rule further restricts it to devices that are part of the "usb" subsystem.
• DRIVERS=="usb-storage": The rule applies to devices that use the "usb-storage" driver, which is commonly used for USB storage devices like external hard drives and USB flash drives.
• RUN+=”/bin/sh -c ‘echo 0 > /sys$env{DEVPATH}/../authorized’”: This command sets the authorized attribute to 0, disabling the device.

3. Reload the udev rules to apply the new rule:

sudo udevadm control --reload-rules

Warning: Be Cautious with udev Rules

Modifying udev rules can have significant impacts on your system's hardware functionality. Incorrect or overly broad rules can unintentionally disable critical devices, such as your keyboard, mouse, or even your entire USB subsystem.

4. Restrict Core Dumps, Configure Exec Shield, Enable Randomized Virtual Memory

Restrict Core Dumps

Core dumps are files that contain the memory of a process at a specific time, usually when the process crashes. Restricting core dumps can prevent sensitive information from being exposed.

1. Edit /etc/security/limits.conf

sudo vim /etc/security/limits.conf

• Add the following line to restrict core dumps:

* hard core 0

• This setting applies to all users (*) and prevents core dumps.

2 . Edit /etc/sysctl.conf

sudo vim /etc/sysctl.conf

• Add the following line to further restrict core dumps:

fs.suid_dumpable = 0

• Apply the changes immediately: sudo sysctl -p

Configure Exec Shield

Exec Shield helps prevent buffer overflow attacks by protecting the memory regions where executable code can run.

• Edit /etc/sysctl.conf

sudo vim /etc/sysctl.conf

• Add the following line to enable Exec Shield:

kernel.exec-shield = 1

• Apply the changes immediately: sudo sysctl -p

Enable Randomized Virtual Memory Region Placement

Randomizing the virtual memory regions helps protect against certain types of attacks, such as buffer overflow exploits.

• Edit /etc/sysctl.conf

sudo vim /etc/sysctl.conf

• Add the following line to enable randomized virtual memory region placement:

kernel.randomize_va_space = 2

• Apply the changes immediately: sudo sysctl -p

By restricting core dumps, configuring Exec Shield, and enabling randomized virtual memory region placement, you can significantly enhance the security posture of your system. These steps help protect sensitive information and mitigate the risk of various attacks.

5. Refine User Access

Implement the principle of least privilege by limiting user permissions. Avoid logging in as the root user; instead, use sudo for administrative tasks. Regularly audit user accounts and remove those no longer needed to minimize potential entry points for attackers.

Disabling root login

• Minimize Attack Surface: Root accounts are prime targets for attackers because they have unrestricted access to the entire system. By disabling direct root login, you reduce the chances of an attacker exploiting this highly privileged account. Instead, users can perform administrative tasks using sudo, which limits the time and scope of elevated privileges.
• Enhanced Accountability: When users perform administrative tasks using sudo, their actions are logged with their individual usernames. This improves accountability and makes it easier to track and audit changes made to the system. In contrast, actions performed as root can be harder to trace back to a specific user, complicating forensic investigations if something goes wrong.
• Reduce Risk of Brute Force Attacks: The root account is often targeted by brute force attacks, where attackers attempt to guess the password. By disabling root login, you make it harder for attackers to exploit this vulnerability. They would need to compromise a user account and then escalate privileges, which adds an additional layer of difficulty.
• Encourage Best Practices: Disabling direct root login encourages the use of sudo for administrative tasks. This practice enforces the principle of least privilege, where users only have the minimum permissions necessary to perform their tasks. It also ensures that elevated privileges are used temporarily and only when necessary.
• Mitigate the Impact of Compromised Accounts: If an attacker gains access to a standard user account, they would need to exploit additional vulnerabilities or escalate privileges to gain root access.

Disabling root login (PermitRootLogin no in /etc/ssh/sshd_config).

1. Use vim and edit file sshd_config

sudo vim /etc/ssh/sshd_config

2. Find the line that says PermitRootLogin yes and change it to:

PermitRootLogin no

3. Restart the SSH service to apply the changes:

sudo systemctl restart sshd

Managing User Permissions

Proper management of user permissions is a critical component of securing a Linux system. By carefully controlling what users can and cannot do, you can significantly reduce the risk of unauthorized access and potential damage. Here’s a deeper look into the commands used for managing user permissions and the reasons behind their importance.

• Principle of Least Privilege: The principle of least privilege dictates that users should have only the permissions necessary to perform their tasks. This minimizes the risk of accidental or malicious changes to system files and configurations. By adhering to this principle, you limit the potential damage that can be done by compromised or malicious accounts.
• Reduce Attack Surface: Users with excessive permissions can inadvertently expose sensitive data or system functionalities to threats. Properly managing permissions helps in restricting access to only those parts of the system that are required, thus reducing the overall attack surface.
• Improved Security Auditing: When user permissions are correctly managed, it’s easier to audit who has access to what and track changes. This is essential for identifying potential security issues and ensuring that no unauthorized modifications have been made.
• Containment of Security Breaches: If an account is compromised, having granular permissions ensures that the attacker cannot easily gain full control over the system. By limiting what each user can do, you contain the potential damage and reduce the risk of a full system compromise.

Commands for Managing User Permissions

• To see a list of all users and their associated groups, use: cat /etc/passwd
• This file contains information about each user, including their username, user ID (UID), group ID (GID), home directory, and login shell.

Checking File and Directory Permissions

• To check the permissions of a specific file or directory, use: ls -l /path/to/file
• This command displays the file’s permissions, owner, and group. Permissions are shown as a string of characters (e.g., -rw-r--r--), indicating read, write, and execute permissions for the owner, group, and others.

Adding a User to a Group

• To grant a user additional permissions by adding them to a group, use: sudo usermod -aG group_name username
• This command appends the user to the specified group without removing them from other groups. Group memberships can grant users additional rights, such as access to shared resources or administrative functions.

Removing a User from a Group

• To remove a user from a group, use: sudo gpasswd -d username group_name
• This command removes the user from the specified group, which can be useful for revoking permissions or adjusting access levels.

6. Disable Bash History

Open the ~/.bashrc file (or ~/.bash_profile ) in a text editor

Add the following lines to disable history

# Disable Bash history
export HISTFILE=/dev/null
export HISTSIZE=0
export HISTFILESIZE=0

Source the .bashrc file to apply the changes source ~/.bashrc

symlink If you prefer to use a symbolic link (symlink) to effectively disable the Bash history, you can redirect the history file to /dev/null by creating a symlink.

• Remove the Existing History File rm~/.bash_history
• Create a symbolic link from the history file to /dev/null.

ln -s /dev/null ~/.bash_history

• This command creates a symlink named .bash_history in your home directory that points to /dev/null.

7. Configure TCPWrappers

TCP Wrappers provide a mechanism to control access to internet services based on IP addresses or hostnames. It works by intercepting incoming requests to network services and applying rules defined in configuration files to decide whether to allow or deny access.

• On most Unix-like systems, TCP Wrappers is included by default. If not, you can install it using your package manager.

sudo apt-get install tcpd

TCP Wrappers uses two main configuration files:

• /etc/hosts.allow: Specifies which hosts are allowed to access services.
• /etc/hosts.deny: Specifies which hosts are denied access.

Open these files with a text editor. For example, to allow access to SSH only from a specific IP address:

• Edit /etc/hosts.allow:

sshd: 192.168.0.98 192.168.0.53

sshd: server1.lan server2.lan

• Edit /etc/hosts.deny to deny access from all other hosts:

sshd: ALL
vsftpd : ALL

8. Configure Iptables

A firewall acts as a barrier against unwanted network traffic. Utilize tools like iptables or firewalld to set up rules that permit only necessary connections while blocking potentially harmful ones.

Use this script as a template and adapt it to your specific needs and requirements. The script is provided as a reference and starting point. Review all parts of the script, adjust them according to conditions, and ensure that all parameters and options align with the system and requirements.

#!/bin/sh


#Root Check and Color Setup
if [ $EUID -ne 0 ]; then
  echo "${yellow}This script must be run as root.${reset}"
  exit 1
fi

# Set Colors
red=`tput setaf 1`
yellow=`tput setaf 3`
reset=`tput setaf 7`

PATH="/sbin:/usr/sbin:/bin:/usr/bin:${PATH}"
export PATH
IPTABLES="/sbin/iptables"
INT_NET=10.0.0.0/255.255.255.0

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Backup Current iptables Rules
#

echo "${yellow}[+] Would you like to backup iptables to root folder? (y/n)${reset}"
read foo
if [ "$foo" = "y" ]; then

NOW=$(date +"%F")
backup="iptable-backup-$NOW.log"
/bin/sudo /sbin/iptables-save | /usr/bin/sudo /usr/bin/tee /root/iptables-works-"$backup"

echo ""
echo "${red}Done ...${reset}"
fi

read -n 1 -r -s -p $"${yellow}Press enter to continue...${reset}"
clear

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Flushing existing iptables rules
#
echo ""
echo ""
echo "${yellow}[+] Basic setup${reset}"
echo " - ${yellow}[+]${reset} Flushing existing iptables rules..."
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Set Default Policies
echo " - ${yellow}[+]${reset} Set chain policy setting to DROP..."
$IPTABLES -P INPUT   DROP
$IPTABLES -P OUTPUT  DROP
$IPTABLES -P FORWARD DROP

# Flush tables
cat /proc/net/ip_tables_names | while read table; do
  test "X$table" = "Xmangle" && continue
  $IPTABLES -t $table -L -n | while read c chain rest; do
      if test "X$c" = "XChain" ; then
        $IPTABLES -t $table -F $chain
      fi
  done
  $IPTABLES -t $table -X
done

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Create Custom Chains
# 

echo " | "
echo "${yellow}[+] Create Filters...${reset}"
$IPTABLES -N LOG_WAF
$IPTABLES -N DROP_INVALID
$IPTABLES -N LOGGING
$IPTABLES -N SPOOFING
$IPTABLES -N BLOCK_COMMON_ATTACKS
$IPTABLES -N PORTSCAN

# - - - - - - - - - - - - 
# Create Filter Rules, Define Rules for Custom Chains
#

echo " - ${yellow}[+]${reset} Create Filters Rules..."

$IPTABLES -A LOG_WAF -m limit --limit 10/min  -j LOG --log-prefix "Firewall> drop: LOG_WAF " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A LOG_WAF -j DROP

$IPTABLES -A LOGGING -m limit --limit 10/min  -j LOG --log-prefix "Firewall> drop: everything_else " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A LOGGING -j DROP

$IPTABLES -A DROP_INVALID -m limit --limit 10/min -j LOG --log-prefix "Firewall> drop: invalid " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A DROP_INVALID -j DROP

$IPTABLES -A SPOOFING -m limit --limit 10/min -j LOG --log-prefix "Firewall> drop: spoofed source IP" --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A SPOOFING -j DROP

$IPTABLES -A PORTSCAN -m limit --limit 10/min -j LOG --log-prefix "Firewall> drop: portscan " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A PORTSCAN -j DROP

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Whitelist your IP address at the top of your policy rules
# Placeholder rules for whitelisting specific IPs and allowing SSH access.
#

# $IPTABLES -I INPUT -s <your IP> -j ACCEPT

# Allow inbound SSH
# $IPTABLES -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW  -j ACCEPT

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Filter_by_MAC_address
# Placeholder for filtering based on MAC addresses.
#

#iptables -N ACCEPTED_MAC
#iptables -vnL
#iptables -A ACCEPTED_MAC -m mac --mac-source B8:E3:98:22:C7:6B -j ACCEPT
#iptables -A ACCEPTED_MAC -m mac --mac-source B8:E3:98:22:C7:5B -j ACCEPT
#iptables -A ACCEPTED_MAC -m mac --mac-source B8:E3:98:22:C7:4B -j ACCEPT
#iptables -A ACCEPTED_MAC -m mac --mac-source B8:E3:98:22:C7:3B -j ACCEPT
#iptables -A ACCEPTED_MAC -m mac --mac-source B8:E3:98:22:C7:2B -j ACCEPT

#iptables -A INPUT -j ACCEPTED_MAC

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Accept any related or established connections
#

echo " | "
echo "${yellow}[+] Set:${reset} Accept any related or established connections..."
$IPTABLES -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
#$IPTABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Drop invalid
#
echo "${yellow}[+] Set:${reset} Drop invalid connections..."
$IPTABLES -A INPUT   -m conntrack --ctstate INVALID -j DROP_INVALID
$IPTABLES -A OUTPUT  -m conntrack --ctstate INVALID -j DROP_INVALID
$IPTABLES -A FORWARD -m conntrack --ctstate INVALID -j DROP_INVALID

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Blacklist
#

# $IPTABLES -I OUTPUT -d 192.168.100.150/32 -j DROP
# $IPTABLES -I INPUT  -p tcp --dport 22 -j DROP
# $IPTABLES -I INPUT -p tcp --dport 22 –s 10.0.0.0/8 –d 192.168.100.101 -j DROP

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Drop spoofed pkt
#

echo " | "
echo "${yellow}[+] Set: Drop spoofed pkt...${reset}"

echo " - ${yellow}[+]${reset} Drop: Self-Identification [RFC 3330]"
$IPTABLES -A INPUT -s 0.0.0.0/8 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: Private[RFC 1918] - CLASS A"
$IPTABLES -A INPUT -s 10.0.0.0/8 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: Link Local [RFC 3330]"
$IPTABLES -A INPUT -s 169.254.0.0/16 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: Private[RFC 1918] - CLASS B"
$IPTABLES -A INPUT -s 172.16.0.0/12 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: Private[RFC 1918] - CLASS C"
$IPTABLES -A INPUT -s 192.168.0.0/16 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: 6to4 Relay Anycast [RFC 3068]"
$IPTABLES -A INPUT -s 192.88.99.0/24 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: NIDB Testing"
$IPTABLES -A INPUT -s 198.18.0.0/15 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: Reserved - IANA - TestNet1"
$IPTABLES -A INPUT -s 192.0.2.0/24 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: Reserved - IANA - TestNet2"
$IPTABLES -A INPUT -s 198.51.100.0/24 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: Reserved - IANA - TestNet3"
$IPTABLES -A INPUT -s 203.0.113.0/24 -j SPOOFING

echo " - ${yellow}[+]${reset} Drop: MC, Class D, IANA"
$IPTABLES -A INPUT -s 224.0.0.0/4 -j SPOOFING

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Restrict an IP address range
#

# host -t a www.facebook.com
# www.facebook.com is an alias for star.c10r.facebook.com.
# star.c10r.facebook.com has address 31.13.65.17
# whois 31.13.65.17 | grep inetnum
# inetnum:        31.13.64.0 - 31.13.127.255

echo " | "
echo "${yellow}[+] Restrict an IP address range${reset}"
echo " - ${yellow}[+]${reset} Block facebook.com ..."
#$IPTABLES  -A OUTPUT -p tcp -o eth0 -d 31.13.64.0/18 -m limit --limit 10/min -j LOG --log-prefix "Firewall> output_drop:facebook " --log-tcp-options --log-ip-options --log-level 4
#$IPTABLES  -A OUTPUT -p tcp -o eth0 -d 31.13.64.0/18 -j DROP -m comment --comment "Block facebok"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Restrict an IP address range -  Regulate by time
#

# $IPTABLES –A OUTPUT -p tcp -m multiport --dport http,https -i eth0 -o eth1 -m time --timestart 12:00 --timestart 12:00 –timestop 13:00 –d 31.13.64.0/18  -j ACCEPT

# Scenario: During planned downtime for system maintenance, you need to deny all TCP and UDP traffic between the hours of 2AM and 3AM so maintenance tasks won't be disrupted by incoming traffic. This will take two iptables rules:
# $IPTABLES -A INPUT -p tcp -m time --timestart 02:00 --timestop 03:00 -j DROP 
# $IPTABLES -A INPUT -p udp -m time --timestart 02:00 --timestop 03:00 -j DROP

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Limit connections with iptables
#

# Let's look at what this rule does. If a host makes more than 20 (-–connlimit-above 20) new connections (–p tcp –syn) in a minute to the web servers (-–dport http,https), reject the new connection (–j REJECT) and tell the connecting host you are rejecting the connection (-–reject-with-tcp-reset).

# $IPTABLES –A INPUT –p tcp –syn -m multiport -–dport http,https –m connlimit -–connlimit-above 20 –j REJECT -–reject-with-tcp-reset

# $IPTABLES -A INPUT -p tcp -m limit --limit 10/min  -m tcp --dport 22 -j LOG --log-prefix "Firewall> SSH port: "
# $IPTABLES –A INPUT –p tcp –syn -m multiport -–dport http,https –m connlimit -–connlimit-above 20 –j DROP

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Drop malicious
#

echo " | "
echo "${yellow}[+] Set: WAF firewall rules ...${reset}"
#echo " - ${yellow}[+]${reset} No rules set jet"

# Create blacklist
# ----------------
# This will create a blacklist that is located in the /proc filesystem in /proc/net/xt_recent/blacklist_180 (or /proc/net/ipt_recent/blacklist_180 ). 

# You can have a look at the blacklist by doing :
# cat /proc/net/xt_recent/blacklist_180

# A packet can be automatically dropped and source IP added in that blacklist using the next rule :
# iptables -A INPUT <IPTABLES FILTERING OPTIONS> --name blacklist_180 --set -j DROP

# You can also manually add an IP address to the blacklist, example :
# echo +192.168.0.2 > /proc/net/xt_recent/blacklist_180

# To manually remove an IP address :  
# echo -192.168.0.2 > /proc/net/xt_recent/blacklist_180
$IPTABLES -A INPUT -m recent --name blacklist_60 --rcheck --seconds 60 -m comment --comment "Drop packet from IP inserted in blacklist last 60 sec" -j DROP

echo " | "
echo "${yellow}[+] Set: Block Port Scanning${reset}"
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j PORTSCAN
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j PORTSCAN
$IPTABLES -A INPUT -p tcp --tcp-flags ACK,URG URG -j PORTSCAN
$IPTABLES -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j PORTSCAN
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j PORTSCAN
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j PORTSCAN
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j PORTSCAN
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,FIN -j PORTSCAN

echo " | "
echo "${yellow}[+] Set: Blocking Common Attacks${reset}"
echo " - ${yellow}[+]${reset} Forcing Fragments packets check"
$IPTABLES -A INPUT -f -j LOG --log-prefix "Firewall> input_drop: Forcing Fragments packets check " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -f -j DROP

echo " - ${yellow}[+]${reset} Drop all NULL scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix "Firewall> Null scan " --log-tcp-options --log-ip-options --log-level 4
#$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE  -m recent --name blacklist_60 --set -m comment --comment "Drop/Blacklist Null scan" -j DROP

echo " - ${yellow}[+]${reset} Drop all Xmas scan"
# Log attacks
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix "Firewall> XMAS scan " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix "Firewall> XMAS-PSH scan " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix "Firewall> XMAS-ALL scan " --log-tcp-options --log-ip-options --log-level 4
# Drop and blacklist for 60 seconds IP of attacker
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -m recent --name blacklist_60 --set  -m comment --comment "Drop/Blacklist Xmas/PSH scan" -j DROP  # Xmas-PSH scan
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -m recent --name blacklist_60 --set  -m comment --comment "Drop/Blacklist Xmas scan" -j DROP   # Against nmap -sX (Xmas tree scan)
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -m recent --name blacklist_60 --set  -m comment --comment "Drop/Blacklist Xmas/All scan" -j DROP    # Xmas All scan

echo " - ${yellow}[+]${reset} Drop all Fin scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix "Firewall> FIN scan " --log-tcp-options --log-ip-options --log-level 4
# Drop and blacklist for 60 seconds IP of attacker
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN -m recent --name blacklist_60 --set  -m comment --comment "Drop/Blacklist FIN scan" -j DROP

echo " - ${yellow}[+]${reset} Drop all Fin scan"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW  -m comment --comment "Drop TCP connection not starting by SYN" -j DROP

echo " - ${yellow}[+]${reset} Forcing SYN packets check"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "Firewall> input_drop: Forcing SYN packets check " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

echo " - ${yellow}[+]${reset} Set trapped ports for SYN scan"
### Trapped ports - ports you are sure you do not need are trapped to react against any connection attempted to them...
# log  probable sS and full connect tcp scan
$IPTABLES -A INPUT -p tcp  -m multiport --dports 23,79 --tcp-flags ALL SYN -m limit --limit 3/m --limit-burst 5 -j LOG --log-prefix "Firewall>SYN scan trap:" --log-tcp-options --log-ip-options --log-level 4
# blacklist for three minuts
$IPTABLES -A  INPUT -p tcp  -m multiport --dports 23,79 --tcp-flags ALL SYN -m recent --name blacklist_60 --set -j DROP

echo " - ${yellow}[+]${reset} Drop zero ttl traffic"
$IPTABLES -A INPUT -p ip -m ttl --ttl-eq 0 -m limit --limit 10/min -j LOG --log-prefix "Firewall> input_drop: zero_ttl_traffic " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p ip -m ttl --ttl-eq 0 -j DROP

echo " - ${yellow}[+]${reset} Drop malicious min-delay_tos"
$IPTABLES -A INPUT -p ip -m tos --tos 16 -m limit --limit 10/min -j LOG --log-prefix "Firewall> input_drop: malicious_min-delay_tos " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p ip -m tos --tos 16 -j DROP

echo " - ${yellow}[+]${reset} Drop large icmp message"
$IPTABLES -A INPUT -p icmp -m length --length 1028 -m limit --limit 10/min -j LOG --log-prefix "Firewall> input_drop: large_icmp_message " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p icmp -m length --length 1028 -j DROP

echo " - ${yellow}[+]${reset} Drop all UDP scan"
$IPTABLES -A INPUT -p udp -m limit --limit 6/h --limit-burst 1 -m length --length 0:28 -j LOG --log-prefix "Firewall>0 length udp " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p udp -m length --length 0:28 -m comment --comment "Drop UDP packet with no content" -j DROP


# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# DoSProtection - connection limit module
#

# $IPTABLES -A INPUT -p tcp --dport 21 --syn -m connlimit --connlimit-above 5 -j REJECT --reject-with tcp-reset
# $IPTABLES -A INPUT -p tcp --dport 22 --syn -m connlimit --connlimit-above 5 -j REJECT --reject-with tcp-reset
# $IPTABLES -A INPUT -p tcp --dport 25 --syn -m connlimit --connlimit-above 5 -j REJECT --reject-with tcp-reset

#### Limit Echo Requests - Prevents DoS attacks
# $IPTABLES -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -m hl --hl-eq 255 -j ACCEPT
# $IPTABLES -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -m hl --hl-eq 255 -j ACCEPT
# $IPTABLES -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -m hl --hl-lt 255 -j DROP
# $IPTABLES -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -m hl --hl-let 255 -j DROP
# $IPTABLES -A INPUT -j REJECT --reject-with icmp6-adm-prohibited
# $IPTABLES -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited

#### Create syn-flood chain
$IPTABLES -N syn-flood
# Jump into syn-flood chain when a syn packet is detected
$IPTABLES -A INPUT -p tcp --syn -j syn-flood
# Limit packet rate to 2 per second with a 6 per second burst
$IPTABLES -A syn-flood -m limit --limit 2/s --limit-burst 6 -m comment --comment "Limit TCP SYN rate" -j RETURN
# Log flooders
$IPTABLES -A syn-flood -m limit --limit 6/h --limit-burst 1 -j LOG --log-prefix "Firewall>Probable syn flood "  --log-tcp-options --log-ip-options --log-level 4
# Ban flooders for 3 minutes
$IPTABLES -A syn-flood -m recent --name blacklist_60 --set  -m comment --comment "Blacklist source IP" -j DROP

IPTABLES#### Create chain for UDP flood
$IPTABLES -N udp-flood
# Jump to chain if UDP
$IPTABLES -A INPUT  -p  udp -j udp-flood
# Limit UDP rate to 10/sec with burst at 20 (sometimes it is not enough, if you know a better average rate, let me know!)
$IPTABLES -A udp-flood -m limit --limit 10/s --limit-burst 20  -m comment --comment "Limit UDP rate" -j RETURN
# Log
$IPTABLES -A udp-flood -m limit --limit 6/h --limit-burst 1 -j LOG --log-prefix "Firewall>Probable udp flood "  --log-tcp-options --log-ip-options --log-level 4
# 3 minutes ban for flooders
$IPTABLES -A udp-flood -m recent --name blacklist_60 --set -m comment --comment "Blacklist source IP" -j DROP

#### Create chain dedicated to ICMP flood
$IPTABLES -N icmp-flood
# Jump to that chain when ICMP  detected
$IPTABLES -A INPUT  -p icmp -j icmp-flood 
# Get out of chain if packet rate for the same IP is below 4 per second with a burst of 8 per second
$IPTABLES -A icmp-flood -m limit --limit 4/s --limit-burst 8  -m comment --comment "Limit ICMP rate" -j RETURN
# Log as flood when rate is higher
$IPTABLES -A icmp-flood -m limit --limit 6/h --limit-burst 1 -j LOG --log-prefix "Firewall>Probable icmp flood "  --log-tcp-options --log-ip-options --log-level 4
# Blacklist IP for 3 minutes
$IPTABLES -A icmp-flood -m recent --name blacklist_60 --set -m comment --comment "Blacklist source IP" -j DROP

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Drop icmp
#

echo " | "
echo "${yellow}[+] Set:${reset} ICMP rules ..."
$IPTABLES -A INPUT -p icmp -m icmp --icmp-type 8 -j LOG --log-prefix "Firewall> input_drop: icmp " --log-tcp-options --log-ip-options --log-level 4
$IPTABLES -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP -m comment --comment "Drop incoming ping"

# Accept icmp_outIPTABLES
$IPTABLES -A OUTPUT -p icmp -j ACCEPT -m comment --comment "Allow ping"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# DHCP-Server
#

echo "${yellow}[+] Set:${reset} DHCP rules ..."
#$IPTABLES -A INPUT  -p tcp -m multiport --dports 67,68 -m conntrack --ctstate NEW -j ACCEPT
#$IPTABLES -A INPUT  -p udp -m multiport --dports 67,68 -m conntrack --ctstate NEW -j ACCEPT
#$IPTABLES -A OUTPUT -p tcp -m multiport --dports 67,68 -m conntrack --ctstate NEW -j ACCEPT
#$IPTABLES -A OUTPUT -p udp -m multiport --dports 67,68 -m conntrack --ctstate NEW -j ACCEPT

# Allow outbound DHCP request
$IPTABLES -I INPUT  -i eth0 -p udp -d 255.255.255.255 --dport 67:68 --sport 67:68 -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -p udp --dport 67:68 --sport 67:68 -m conntrack --ctstate NEW -j ACCEPT -m comment --comment "DHCP output"
$IPTABLES -A INPUT  -i eth0 -p udp --dport 67:68 --sport 67:68 -m conntrack --ctstate NEW -j ACCEPT -m comment --comment "DHCP input"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# DNS-Server
#

echo "${yellow}[+] Set:${reset} DNS rules ..."
# $IPTABLES -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
# $IPTABLES -A INPUT  -p udp -m udp --sport 53 -j ACCEPT

# Outbound DNS lookups
$IPTABLES -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT -m comment --comment "DNS"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# traceroute
#
#echo "${yellow}[+] Set:${reset} DNS rules ..."
$IPTABLES -I OUTPUT -p udp --dport 33434:33474 -j ACCEPT -m comment --comment "Allow traceroute"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# WHOIS
#

echo "${yellow}[+] Set:${reset} Allow whois connection ..."
$IPTABLES -A OUTPUT -p tcp --dport 43 -j ACCEPT -m comment --comment "Allow whois requests"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# NTP_Server
#

echo ""
echo ""
echo "${yellow}Would you like to allow NTP? (y/n)${reset}"
read foo
if [ "$foo" = "y" ]; then

# $IPTABLES -A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 123 -j ACCEPT -m comment --comment "NTP"
# $IPTABLES -A INPUT -m conntrack --ctstate -m udp -p udp --dport 123 -j ACCEPT -m comment --comment "NTP"

# Outbound Network Time Protocol (NTP) requests
$IPTABLES -A INPUT -p udp --sport 123 -j ACCEPT -m comment --comment "NTP"
$IPTABLES -A OUTPUT -p udp --dport 123 -j ACCEPT -m comment --comment "NTP"

fi

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# Allow outbound email
# $IPTABLES -A OUTPUT -i eth0 -p tcp -m tcp --dport 25 -m state --state NEW  -j ACCEPT -m comment --comment "EMAIL-SMTP"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Standard loopback rule
#

echo "${yellow}[+] Set:${reset} Standard loopback rules ..."
$IPTABLES -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
$IPTABLES -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

$IPTABLES -A INPUT  -i lo -s 127.0.1.1 -d 127.0.1.1 -j ACCEPT
$IPTABLES -A OUTPUT -o lo -s 127.0.1.1 -d 127.0.1.1 -j ACCEPT

# Allow all traffic on the loopback interface
# $IPTABLES -A INPUT -i lo -j ACCEPT
# $IPTABLES -A OUTPUT -o lo -j ACCEPT

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Allow HTTP, HTTPS
#

echo "${yellow}[+] Set:${reset} Allow https connections..."
$IPTABLES -A OUTPUT -p tcp -m tcp --dport 80  -m conntrack --ctstate NEW -j ACCEPT -m comment --comment "HTTP"
$IPTABLES -A OUTPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT -m comment --comment "HTTPS"

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# Allow broadcast
#

echo ""
echo ""
echo "${yellow}Would you like to allow broadcast? (y/n)${reset}"
read foo
if [ "$foo" = "y" ]; then
 $IPTABLES -A OUTPUT -p udp -m pkttype --pkt-type broadcast -d 255.255.255.255 -j ACCEPT
 $IPTABLES -A OUTPUT -p udp -m pkttype --pkt-type broadcast -d 10.0.0.255 -j ACCEPT
 echo "${yellow}[+] Set:${reset} Allow broadcast ..."
fi

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# DROP everything else
#
echo "${yellow}[+] Set:${reset} DROP to everything else..."
#$IPTABLES -A INPUT -j DROP
#$IPTABLES -A OUTPUT -j DROP
#$IPTABLES -A FORWARD -j DROP

$IPTABLES -A INPUT   -j LOGGING
$IPTABLES -A OUTPUT  -j LOGGING
$IPTABLES -A FORWARD -j LOGGING

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

echo ""
echo "${red}Done ...${reset}"

9. Turn Off IPv6

• To disable IPv6 permanently, you need to modify system configuration files.
• For Systems Using grub (useful for more persistent configurations). Edit the GRUB configuration file sudo vim /etc/default/grub
• Find the GRUB_CMDLINE_LINUX line and add ipv6.disable=1

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet splash"
GRUB_CMDLINE_LINUX="ipv6.disable=1"

• Update GRUB with the new configuration: sudo update-grub
• Verify IPv6 is Disabled Permanently . After rebooting or applying the configuration, verify that IPv6 is disabled using: ip a | grep inet6

10. Use SELinux or AppArmor

Security-Enhanced Linux (SELinux) and AppArmor provide additional layers of security by enforcing mandatory access controls. These tools help limit what processes and applications can do, reducing the impact of potential vulnerabilities.

11. Implement File Integrity Monitoring

Deploy file integrity monitoring tools such as AIDE (Advanced Intrusion Detection Environment) or Tripwire to keep track of changes to critical system files. This can help detect unauthorized alterations and potential security breaches.

AIDE (Advanced Intrusion Detection Environment) is a file and directory integrity checker that helps monitor changes to files and directories. To run and use AIDE on a Linux system, follow these steps:

• First, you need to install AIDE. The installation command depends on your Linux distribution:

sudo apt-get update
sudo apt-get install aide

• Before using AIDE, you need to initialize its database. This database will store the initial state of the files and directories that AIDE will monitor.

sudo aideinit

By default, this command initializes the database at /var/lib/aide/aide.db.new. After initialization, rename the new database to the default database location:

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Configure AIDE

• The configuration file for AIDE is usually located at /etc/aide/aide.conf. This file defines which files and directories to monitor, and how to perform the checks. Open the configuration file in a text editor:

sudo vim /etc/aide/aide.conf

• Add or modify rules to specify which files and directories to include or exclude from monitoring. For example:

# Monitor all files in /etc
/etc    p+i+n+u+g+s+m+c+md5

• p: Permissions
• i: Inode
• n: Number of links
• u: User
• g: Group
• s: Size
• m: Modification time
• c: Checksum (e.g., md5, sha1)

Save the file and exit the editor.

Run AIDE Check

• To perform a check against the initialized database, use the following command: sudo aide --check

Update AIDE Database

• If you make legitimate changes to your system and want to update the AIDE database to reflect these changes, run:

# Update Database:
sudo aide --update

# After updating, rename the updated database:
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Automate AIDE Checks

• To automate AIDE checks, you can set up a cron job sudo crontab -e
• Add a line to schedule regular checks, for example, to run daily at midnight

0 0 * * * /usr/sbin/aide --check

12. Harden Network Services

Minimize attack surfaces by disabling unused network services. Use commands like netstat or ss to review open ports and running services, and shut down those that are not necessary.

List Open Ports and Running Services

• To identify which network services are running and listening for connections, you can use tools like netstat or ss.

sudo netstat -tuln
sudo ss -tuln
sudo lsof -i -Png

Identify Unnecessary Services

• Review the output from the above commands to see which services are listening on which ports. Compare this list to your needs and security policies.

Stop and Disable Unnecessary Services

• To stop and disable services, you typically use the systemctl command on systems using systemd, or service on older systems.

# Stop a service
sudo systemctl stop [service_name]

# Disable a service (prevent it from starting on boot)
sudo systemctl disable [service_name]

Check for Legacy Protocols:

Legacy communication services can be a security risk due to outdated protocols and lack of modern encryption standards.

Look for services using outdated protocols such as:

• FTP (use SFTP or FTPS instead)
• Telnet (use SSH instead)
• HTTP (use HTTPS instead)
• SNMPv1/2 (use SNMPv3 instead)
• NTPv3 (use NTPv4 or newer)

sudo systemctl stop telnet
sudo systemctl disable telnet

sudo apt-get remove telnet

13. Minimize Software to Minimize Vulnerability

Reducing the amount of installed software on a system minimizes the attack surface, reducing the potential for vulnerabilities. Unnecessary software and services can introduce security risks and should be removed or disabled.

Identify and review all installed packages to determine which ones are necessary and which can be removed.

dpkg --list  # For Debian-based systems

Uninstall packages that are not required for your system’s operation.

sudo apt-get remove <package_name>  # For Debian-based systems

Review running services and disable those that are not necessary.

sudo systemctl list-units --type=service --state=running

sudo systemctl disable <service_name>
sudo systemctl stop <service_name>

sudo systemctl disable bluetooth
sudo systemctl stop bluetooth

14. Secure System Configuration

Review and adjust system settings to bolster security. This includes enforcing strong password policies, disabling non-essential features, and setting appropriate file permissions.

Enforce Strong Password Policies

• Configure Password Complexity: Modify the /etc/security/pwquality.conf file to set password complexity requirements. For example: sudo vim /etc/security/pwquality.conf
• Add or modify the following settings:

minlen = 16
minclass = 4
dcredit = -1
ucredit = -1
ocredit = -1

• minlen: Minimum password length.
• minclass: Minimum number of character classes (lowercase, uppercase, digits, special characters).
• dcredit, ucredit, ocredit: Controls the requirement for digits, uppercase, and other characters.

dcredit: This parameter controls the number of required digits in the password. If set to -1, it means that at least one digit is required. Positive values specify the maximum number of digits allowed.

ucredit: This parameter controls the number of required uppercase letters in the password. If set to -1, it means that at least one uppercase letter is required. Positive values specify the maximum number of uppercase letters allowed.

ocredit: This parameter controls the number of required special characters (e.g., !, @, #, $) in the password. If set to -1, it means that at least one special character is required. Positive values specify the maximum number of special characters allowed.

Enforce Password Expiration and History:

Modify /etc/login.defs to enforce password expiration and history policies: sudo vim /etc/login.defs\

Set:

PASS_MAX_DAYS   90
PASS_MIN_DAYS   7
PASS_MIN_LEN    16
PASS_WARN_AGE   7

PASS_MAX_DAYS: Maximum number of days a password may be used.
PASS_MIN_DAYS: Minimum number of days between password changes.
PASS_MIN_LEN: Minimum length of the password.
PASS_WARN_AGE: Number of days to warn before a password expires.

Locking User Accounts After Login Failures

To enhance security by preventing brute-force attacks, you can configure the system to lock user accounts after a specified number of unsuccessful login attempts. This can be achieved using the pam_tally2 or pam_faillock modules, depending on your Linux distribution

Using pam_faillock (for newer systems)

pam_faillock is recommended for newer Linux distributions. It can be configured in the PAM (Pluggable Authentication Modules) system to lock user accounts after a number of failed login attempts.

Open the PAM configuration file for login attempts, usually found at /etc/pam.d/system-auth and /etc/pam.d/password-auth.

sudo vim /etc/pam.d/system-auth
sudo vim /etc/pam.d/password-auth
sudo vim /etc/pam.d/sshd

Add the following lines to both files:

auth        required      pam_faillock.so preauth silent audit deny=5 unlock_time=900
auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900
account     required      pam_faillock.so

Parameters:

• required: This module is required; if it fails, authentication is denied.
• preauth: This module checks the failed attempts before the actual authentication.
• silent: Prevents displaying error messages to the user about lockout.
• audit: Logs all authentication attempts, including failures.
• deny=5: Number of allowed failed attempts before lockout.
• unlock_time=900: Time in seconds that the account remains locked after reaching the maximum number of failed attempts.
• [default=die]: If the module fails to load or is not configured properly, it will deny access.
• authfail: This module tracks failed authentication attempts.

Here’s what the configuration does:

• Pre-authentication Phase (preauth): Tracks failed attempts and applies lockout silently before the user is asked for credentials.
• Authentication Failures (authfail): Manages failed login attempts and enforces lockout if the user exceeds the allowed number of failures.
• Account Management: Ensures that accounts are properly checked for lockout status during the account management phase.

Using pam_tally2 (for older systems)

pam_tally2 is an older module used to lock user accounts after a specified number of failed login attempts.

Open the PAM configuration files for login attempts, usually found at /etc/pam.d/common-auth and /etc/pam.d/common-account.

sudo vim /etc/pam.d/common-auth
sudo vim /etc/pam.d/common-account

Add the following lines to both files:

auth required pam_tally2.so deny=5 unlock_time=900 onerr=fail audit
account required pam_tally2.so

Checking and Resetting Failed Login Attempts

To check the number of failed login attempts and reset them, use the following commands:

Check Failed Attempts:

pam_tally2 --user=<username>

Reset Failed Attempts:

pam_tally2 --user=<username> --reset

Note: Replace <username> with the actual username.

15. Fail2ban: Enhancing Linux Security by Preventing Brute Force Attacks

Fail2ban is a powerful intrusion prevention tool for Linux that helps protect your system from brute force attacks and other malicious activities by monitoring log files for suspicious behavior. When a predefined number of failed login attempts or other suspicious activities are detected, Fail2ban automatically updates firewall rules to block offending IP addresses.

Install Fail2ban: sudo apt-get install fail2ban

Edit the configuration file /etc/fail2ban/jail.conf to define rules and settings.

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
bantime = 600

Start and Enable Fail2ban:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Check Fail2ban Status:

sudo fail2ban-client status

16. Port Knocking on Linux: Installation and Configuration

Port Knocking is a security technique that uses a sequence of network port requests to dynamically open ports on a firewall, providing an additional layer of access control. It’s useful for securing services by keeping ports closed until the correct “knock” sequence is received.

To implement port knocking on Linux, you need to install the knockd package. On Debian-based systems, use: sudo apt-get install knockd

Edit the configuration file /etc/knockd.conf to define the port knocking sequence and the corresponding actions.

[options]
logfile = /var/log/knockd.log

[openSSH]
sequence    = 7000,8000,9000
seq_timeout  = 5
command     = /usr/sbin/ufw allow 22/tcp
tcpflags    = syn

[closeSSH]
sequence    = 9000,8000,7000
seq_timeout  = 5
command     = /usr/sbin/ufw deny 22/tcp
tcpflags    = syn

• sequence: Defines the port sequence that must be "knocked" in the correct order.
• seq_timeout: Time limit for the sequence to be completed.
• command: Command to execute when the sequence is matched (e.g., opening or closing a port).
• tcpflags: Specifies TCP flags to be used for the knocking.

Start and Enable knockd:

sudo systemctl start knockd
sudo systemctl enable knockd

17. Set Email Notifications for sudo Users

To keep track of sudo activity and receive notifications when sudo commands are executed, you can configure email notifications on your Linux system. This helps monitor and audit privileged operations performed by users.

1. Mail Server: Ensure you have a mail server or an SMTP relay configured on your system. You can use tools like sendmail, postfix, or msmtp for sending emails.

sudo apt-get install postfix

• Open the Postfix configuration file /etc/postfix/main.cf in a text editor

relayhost = [smtp.example.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:username:password
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

2. Ensure sudo Logging is Enabled: Typically, sudo logs to /var/log/auth.log or /var/log/secure.

• Open the sudoers file using visudo, which safely edits the file and checks for syntax errors: sudo visudo
• Add the following lines to configure logging and email notifications:

Defaults logfile="/var/log/sudo.log"
Defaults mailto="admin@staff.example.com"
Defaults mail_always

• logfile: Specifies the location of the sudo log file.
• mailto: Specifies the email address to receive notifications.
• mail_always: Sends an email every time a user runs sudo.

Additional sudo Email Notification Options

• mail_badpass Sends an email to the mailto user if the user running sudo does not enter the correct password.
• mail_no_host Sends an email to the mailto user if the invoking user exists in the sudoers file but is not allowed to run commands on the current host.
• mail_no_perms Sends an email to the mailto user if the invoking user is allowed to use sudo, but the command they are trying to run is either not listed in their sudoers file entry or is explicitly denied.
• mail_no_user Sends an email to the mailto user if the invoking user is not in the sudoers file.

Defaults mailto="admin@staff.example.com"   # Set the email address for notifications
Defaults mail_always                        # Always send an email
Defaults mail_badpass                        # Notify on bad password attempts
Defaults mail_no_host                        # Notify if the user is not allowed to run commands on the current host
Defaults mail_no_perms                       # Notify if the user tries to run a command not listed or denied

By setting up postfix or another mail server and configuring sudo logging, you ensure that you receive email notifications whenever sudo commands are executed on your system. This setup helps you monitor sudo usage and enhance system security.

18. Validating Security Configurations and Identifying Risks

When hardening your Linux system, it’s crucial to perform several key security checks to ensure proper configuration and mitigate potential vulnerabilities.

Check for Empty Passwords

Ensuring that no user accounts have empty passwords is crucial for maintaining system security.

sudo passwd -S | grep 'NP'
sudo awk -F: '($2 == "" ) { print $1 }' /etc/shadow
sudo grep '^[^:]*::' /etc/shadow

Ensure Only the Root Account Has UID 0

Ensuring that only the root account has a UID (User ID) of 0 is crucial for system security. UID 0 provides full administrative privileges, and only the root user should have this level of access. Here’s how you can check and rectify any issues related to non-root accounts having a UID of 0.

awk -F: '($3 == 0) { print $1 }' /etc/passwd

Identifying and Disabling Unwanted SUID and SGID Files

SUID (Set User ID) and SGID (Set Group ID) bits are special permissions that can grant elevated privileges to users executing a file. While they are useful for certain legitimate processes, they can also pose security risks if misconfigured or unnecessary. Disabling unwanted SUID and SGID binaries is an important step in hardening your Linux system.

# List SUID Binaries:
find / -type f -perm -4000 -ls 2>/dev/null

#List SGID Binaries:
find / -type f -perm -2000 -ls 2>/dev/null

Checking for World-Writable Files in Linux

One crucial step in hardening your Linux system is to identify and mitigate world-writable files. World-writable files can be modified by any user, posing a significant security risk. To check for world-writable directories that are not sticky (which means they don’t have the “restricted deletion” flag set), you can use the find command:

find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

Checking for Files with No Owner in Linux

Files with no assigned owner or group can indicate misconfiguration or potential security issues. To identify such files on your Linux system, you can use the find command as follows:

find / -xdev \( -nouser -o -nogroup \) -print

19. Regular Backups

Ensure you have a regular backup schedule for your critical data and system configurations. Store backups securely and periodically test them to ensure they are intact and recoverable.