News AI
July 15th, 2024

Show HN: Blitzping – A far faster nping/hping3 SYN-flood alternative with CIDR

Blitzping project on GitHub enhances IP packet transmission speed, surpassing hping3 and nping. It utilizes POSIX headers, C11's libc, supports CIDR notations, and offers various optimizations and features for efficient packet handling. Detailed repository includes benchmarks, compilation guidance, and device specifications.

Read original articleLink Icon
Show HN: Blitzping – A far faster nping/hping3 SYN-flood alternative with CIDR

The Blitzping project on GitHub focuses on sending IP packets quickly in userland, outperforming tools like hping3 and nping through performance optimizations. It uses standard POSIX headers and C11's libc, supporting CIDR notations for IP addresses. The project offers features like pre-generated packet buffers, asynchronous socket configuration, multithreading, and compiler optimizations. Detailed instructions, benchmarks against hping3 and nping, compilation guidance, target device specification, and cross-compilation package requirements are provided in the repository. Visit the Blitzping GitHub repository for more information.

Related

The FreeBSD-native-ish home lab and network

The FreeBSD-native-ish home lab and network

The author details a complex home lab setup with a FreeBSD server on a laptop, utilizing Jails for services like WordPress and emphasizing security measures and network configurations for efficiency and functionality.

Bpftop: Dynamic real-time view of running eBPF programs

Bpftop: Dynamic real-time view of running eBPF programs

The GitHub repository for `bpftop` by Netflix provides real-time monitoring of eBPF programs with statistics like average runtime, events per second, and CPU usage. Visit https://github.com/Netflix/bpftop for more details.

How eBPF is shaping the future of Linux and platform engineering

How eBPF is shaping the future of Linux and platform engineering

eBPF, developed by Daniel Borkmann, revolutionizes Linux by enabling custom programs in the kernel. It enhances networking, security, and observability, bridging monolithic and microkernel architectures for improved performance and flexibility.

P4TC Hits a Brick Wall

P4TC Hits a Brick Wall

P4TC, a networking device programming language, faces integration challenges into the Linux kernel's traffic-control subsystem. Hardware support, code duplication, and performance concerns spark debate on efficiency and necessity. Stalemate persists amid technical and community feedback complexities.

Puck

Puck

Puck is a GO tool for checking apt package updates efficiently. It features a small CLI, YAML configuration, and supports multiple systems. Early in development, more features are planned. Find details on the GitHub repository.

Link Icon 6 comments
By @VioletVillain - 6 months
For the posterity, I've managed to make Blitzping much faster: on the ARMv8-A device, it went from ~10.5 MiB/s to ~120 MiB/s. Instead of sendto(), I used a single connect() call to bind the raw socket to its destination, and then I used writev() calls to "queue" many packets for sending. Internally, writev() [and its other counterpart, sendmmsg()] still uses the same for-loop'ing mechanism to iterate through its queue, but said loop would exist in kernelspace, requiring less userspace->kernelspace syscalls to accomplish the same goal.
By @LinuxBender - 7 months
This looks interesting, I might try attacking my own nodes with it. Out of curiosity have you done anything to make the packets more "real looking" than hping3? I ask because dropping floods from hping3 can be done with a single iptables rule as they do not set options in the header that would make the syn packets appear to be legit. MSS being the most obvious

Have you also tried taking the reverse challenge a.k.a. blue team and defend against your own tool? What methods would you use if someone were using this against servers you wanted to stay up? e.g. CDN? IP stack hardening? eBPF rules?

By @Emjayen - 7 months
Those numbers seem awfully low; even going via the relatively slow kernel/kernel stack, you can comfortably achieve around 2Mpps (64B) tx, per core (single flow), on ~2010 commodity hardware via standard Linux userspace APIs.

For reference, bypassing the kernel you can saturate a 10G link for ~14Mpps on a single downclocked 500MHz core with same class of hardware.

Stuck on phone at the moment; will check out the code later.

By @mike_d - 7 months
Can you help me understand the intention of this other than just being a DoS tool?