[{"content":"Initial setup of a freshly deployed Linux server is a critical stage. By default, fresh distributions may have vulnerabilities due to standard user accounts, open ports, or disabled firewalls.\nIn this article, we will review a basic security checklist for a Debian/Ubuntu-based server.\n1. Connecting and Updating the System First, connect to your server via SSH (usually as user root):\nssh root@your_server_ip Once logged in, update the package list and install all pending security updates:\napt update \u0026amp;\u0026amp; apt upgrade -y 2. Creating a New User with Sudo Privileges Never perform routine tasks and administration under the root account. Create a new user and grant them administrator privileges.\nCreate a user (e.g., sysadmin):\nadduser sysadmin Add the user to the sudo group:\nusermod -aG sudo sysadmin Now switch to the newly created user for further work:\nsu - sysadmin 3. Setting Up SSH Key Authentication Password authentication is vulnerable to brute-force attacks. Using SSH keys guarantees a high level of security.\nStep 3.1. Key Generation (on your local computer) If you don\u0026rsquo;t have a key pair yet, run this on your local machine:\nssh-keygen -t ed25519 -C \u0026#34;your_email@example.com\u0026#34; Step 3.2. Copying the Key to the Server Copy your public key to the server:\nssh-copy-id sysadmin@your_server_ip After doing this, make sure you can log into the server via SSH without entering a password:\nssh sysadmin@your_server_ip 4. Hardening the SSH Server Now disable password authentication and direct root login.\nOpen the SSH configuration file:\nsudo nano /etc/ssh/sshd_config Find and modify the following parameters (if they are commented out with #, remove the hash symbol):\nPermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes PermitEmptyPasswords no X11Forwarding no MaxAuthTries 3 Save the file (Ctrl + O, then Enter) and exit (Ctrl + X).\nCheck the configuration for syntax errors:\nsudo sshd -t If there are no errors, restart the SSH service:\nsudo systemctl restart ssh Important! Do not close your current terminal session until you open a new window and verify that you can successfully connect via SSH as the new user using your key.\n5. Setting Up a Firewall (UFW) Blocking unused network ports is a security standard. Let\u0026rsquo;s install and configure ufw (Uncomplicated Firewall).\nInstall UFW (if not already installed):\nsudo apt install ufw -y Set default policies (deny all incoming, allow all outgoing):\nsudo ufw default deny incoming sudo ufw default allow outgoing Allow SSH (make sure to do this before enabling the firewall, otherwise you will lose access!):\nsudo ufw allow OpenSSH # Or if using a non-standard port: # sudo ufw allow 2222/tcp Enable the firewall:\nsudo ufw enable Check status:\nsudo ufw status verbose 6. Brute-Force Protection with Fail2ban Fail2ban monitors service logs (such as SSH) and temporarily blocks IP addresses exhibiting multiple failed login attempts.\nInstall Fail2ban:\nsudo apt install fail2ban -y Create a local configuration file:\nsudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local Open the configuration file:\nsudo nano /etc/fail2ban/jail.local Find the [sshd] section and ensure it is enabled:\n[sshd] enabled = true port = ssh logpath = %(sshd_log)s maxretry = 3 bantime = 1h Save the file and restart the service:\nsudo systemctl enable fail2ban sudo systemctl restart fail2ban 7. Configuring Automatic Security Updates To receive security patches on time without manual intervention, configure the unattended-upgrades package.\nInstall the package:\nsudo apt install unattended-upgrades -y Configure automatic updates:\nsudo dpkg-reconfigure -plow unattended-upgrades Select Yes in the dialog window.\nConclusion You have completed the basic security setup of your new Linux server:\nCreated an isolated user with sudo privileges. Configured secure SSH-key access (password and root logins disabled). Configured the firewall (UFW). Installed brute-force protection (Fail2ban). Enabled automatic security updates. Now your server is ready for deploying applications and services!\n","permalink":"https://tomahawk-center.info/posts/secure-server-setup/","summary":"\u003cp\u003eInitial setup of a freshly deployed Linux server is a critical stage. By default, fresh distributions may have vulnerabilities due to standard user accounts, open ports, or disabled firewalls.\u003c/p\u003e\n\u003cp\u003eIn this article, we will review a basic security checklist for a Debian/Ubuntu-based server.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"1-connecting-and-updating-the-system\"\u003e1. Connecting and Updating the System\u003c/h2\u003e\n\u003cp\u003eFirst, connect to your server via SSH (usually as user \u003ccode\u003eroot\u003c/code\u003e):\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003essh root@your_server_ip\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eOnce logged in, update the package list and install all pending security updates:\u003c/p\u003e","title":"Initial Secure Setup Guide for Linux Servers"},{"content":"The Caddy web server is a modern, extremely powerful, and easy-to-use web server written in Go. Its standout feature is built-in automatic HTTPS support (via Let\u0026rsquo;s Encrypt), which works out of the box without manual SSL certificate issuance and renewal via Certbot.\nIn this guide, we will look at how to install Caddy on Linux distributions (using Ubuntu/Debian as an example), configure its configuration file (Caddyfile), and launch the service.\n1. Installing Caddy on Linux (Ubuntu / Debian) The recommended installation method is using the official developer repository. This ensures you get the up-to-date version with all security updates.\nRun the following commands in your terminal:\n# 1. Install necessary dependencies sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl # 2. Add the official Caddy repository GPG key curl -1sLf \u0026#39;https://dl.cloudsmith.io/public/caddy/stable/gpg.key\u0026#39; | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg # 3. Add the official Caddy repository curl -1sLf \u0026#39;https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt\u0026#39; | sudo tee /etc/apt/sources.list.d/caddy-stable.list # 4. Update package lists and install Caddy sudo apt update sudo apt install caddy Managing the Systemd Service After installation completes, Caddy automatically starts as a system service. You can manage it using standard systemctl commands:\n# Check service status sudo systemctl status caddy # Restart Caddy sudo systemctl restart caddy # Stop Caddy sudo systemctl stop caddy # Enable automatic startup on system boot sudo systemctl enable caddy 2. Configuration Structure (Caddyfile) The main configuration file is the Caddyfile, which is typically located at /etc/caddy/Caddyfile.\nThe Caddyfile syntax is extremely concise and avoids excessive curly braces when parameters are on separate lines.\nExample of a Basic Configuration File: example.com { # Site root directory root * /var/www/html # Enable file server / static file serving file_server # Response compression (gzip, zstd) encode gzip zstd # Request logging log { output file /var/log/caddy/example.com.log } } 3. Setting Up a Static Website Create a directory for your website:\nsudo mkdir -p /var/www/html Create a simple test page index.html:\nsudo nano /var/www/html/index.html Add the following code:\n\u0026lt;!DOCTYPE html\u0026gt; \u0026lt;html lang=\u0026#34;en\u0026#34;\u0026gt; \u0026lt;head\u0026gt; \u0026lt;meta charset=\u0026#34;UTF-8\u0026#34;\u0026gt; \u0026lt;title\u0026gt;Caddy is working!\u0026lt;/title\u0026gt; \u0026lt;/head\u0026gt; \u0026lt;body\u0026gt; \u0026lt;h1\u0026gt;Hello, World! Caddy web server successfully configured.\u0026lt;/h1\u0026gt; \u0026lt;/body\u0026gt; \u0026lt;/html\u0026gt; Set the correct file owner permissions (so the caddy user has access to the site):\nsudo chown -R caddy:caddy /var/www/html 4. Reverse Proxy One of the most common tasks for Caddy is proxying requests to local applications (e.g., Node.js, Python, Docker containers).\nExample Caddyfile configuration for proxying requests to an application running on port 3000:\napp.example.com { reverse_proxy localhost:3000 } If the application runs inside Docker on the same host, you can specify the container name or internal port:\napp.example.com { reverse_proxy 127.0.0.1:8080 } Caddy will automatically issue an SSL certificate for app.example.com and initiate a secure (HTTPS) connection with the client, forwarding requests to the backend over plain HTTP.\n5. Validating and Applying Configuration After making changes to /etc/caddy/Caddyfile, always check the configuration for syntax errors:\nsudo caddy validate --config /etc/caddy/Caddyfile If validation succeeds, reload the configuration without stopping the web server itself (graceful reload):\nsudo systemctl reload caddy Conclusion We have successfully installed the Caddy web server on Linux, created a basic site structure, set up static content serving, and configured a reverse proxy. Thanks to automatic TLS certificate management, Caddy spares the administrator from routine Certbot maintenance, making administration fast, reliable, and secure.\n","permalink":"https://tomahawk-center.info/posts/caddy-installation-guide/","summary":"A step-by-step guide on installing Caddy on Linux, configuring Caddyfile, serving static sites, and setting up reverse proxy with automatic HTTPS.","title":"Installing and Basic Configuration of Caddy Web Server on Linux"},{"content":"Under heavy network load (high-throughput or low-latency services, databases, storage, video streaming, routing), default Linux network stack settings often lead to invisible packet drops (packet drops), jitter, and reduced throughput.\nIn this article, we will examine how packets travel through Linux buffers, how to diagnose bottlenecks, and how to correctly optimize parameters at all levels: from the network card to application sockets.\nNetwork Stack Buffering Architecture A packet passes through several buffering tiers:\n[ Physical Cable / Network Environment ] │ ▼ ┌────────────────────────────────────────┐ │ 1. NIC Hardware \u0026amp; RX Ring Buffer │ (Managed via ethtool) └────────────────────────────────────────┘ │ DMA -\u0026gt; sk_buff, NAPI poll / SoftIRQ ▼ ┌────────────────────────────────────────┐ │ 2. Kernel Backlog Queue (netdev) │ (net.core.netdev_max_backlog) └────────────────────────────────────────┘ │ Routing, Netfilter, IP stack ▼ ┌────────────────────────────────────────┐ │ 3. TCP/UDP Socket Receive Buffer │ (net.core.rmem_*, tcp_rmem) └────────────────────────────────────────┘ │ recv() / read() ▼ ┌────────────────────────────────────────┐ │ 4. User Space Application │ (nginx, postgres, custom app) └────────────────────────────────────────┘ If at any of these stages the buffer overflows before the next layer can process the data, the packet is dropped by the kernel or the card.\n1. Diagnostics: How to Identify Buffer Issues Before changing configurations, collect baseline metrics.\nDrops at the Network Card Level (NIC / Ring Buffer) # View general interface statistics ip -s link show eth0 # Detailed driver statistics (look for rx_dropped, rx_missed_errors, rx_fifo_errors, rx_no_buffer_count) ethtool -S eth0 | grep -E -i \u0026#34;drop|discard|miss|fifo|overrun|error\u0026#34; Drops at the Kernel and TCP Stack Level # Drops in the netdev_max_backlog queue (second column /proc/net/softnet_stat) cat /proc/net/softnet_stat # Socket buffer overflow errors and TCP listen backlog nstat -az | grep -E \u0026#34;TcpExtListenOverflows|TcpExtListenDrops|TcpExtTCPRcvQDrop|TcpExtTCPWmemDrop\u0026#34; # Real-time socket monitoring ss -ntip 2. Network Card Level: Ring Buffers (RX/TX Rings) A Ring Buffer is a circular memory structure area (DMA descriptors) where the network adapter places incoming packets before CPU processing.\nChecking Current and Maximum Sizes ethtool -g eth0 Example output:\nRing parameters for eth0: Pre-set maximums: RX: 4096 TX: 4096 Current hardware settings: RX: 512 TX: 512 Increasing Buffer Size If Current is less than Pre-set maximums, under high loads it is recommended to increase the size to the maximum or a reasonable value (e.g., 2048/4096):\nsudo ethtool -G eth0 rx 4096 tx 4096 Persistence: To ensure settings persist after reboot:\nsystemd-networkd: add a [Link] section with ReceiveBufferSize=4096 to your .network file. Netplan: receive-buffer-size: 4096 parameter under the match block. udev rule: /etc/udev/rules.d/10-ring-buffer.rules ACTION==\u0026#34;add\u0026#34;, SUBSYSTEM==\u0026#34;net\u0026#34;, NAME==\u0026#34;eth0\u0026#34;, RUN+=\u0026#34;/sbin/ethtool -G eth0 rx 4096 tx 4096\u0026#34; 3. Kernel Queue: netdev_max_backlog and somaxconn When the network card generates a SoftIRQ, packets are placed into the kernel input queue if the driver does not use NAPI mode or packets arrive faster than the CPU can process them.\nnet.core.netdev_max_backlog — maximum number of packets in the kernel processing queue. net.core.somaxconn — length of the pending connection queue (listen() backlog). # Recommended values for high-load servers (10G/40G/100G) sudo sysctl -w net.core.netdev_max_backlog=16384 sudo sysctl -w net.core.somaxconn=65535 4. Kernel Socket Buffers: rmem and wmem BDP (Bandwidth-Delay Product) Calculation For TCP, the transmission window size and socket buffer directly determine the maximum throughput on a link with a specific round-trip time (RTT):\n$$\\text{BDP} = \\text{Bandwidth (bps)} \\times \\text{RTT (s)}$$\nFor example, for a 10 Gbps link with a 20 ms ping ($0.02\\text{ s}$): $$\\text{BDP} = 10 \\times 10^9 \\times 0.02 = 200,000,000\\text{ bits} \\approx 25\\text{ MB}$$\nIf the maximum TCP buffer size (tcp_rmem / tcp_wmem) is less than 25 MB, the connection will physically be unable to utilize the full 10G bandwidth.\nsysctl Configuration Basic Network Kernel Limits (net.core) # Maximum socket receive/send buffer sizes (in bytes) net.core.rmem_max = 67108864 # 64 MB net.core.wmem_max = 67108864 # 64 MB # Default buffers net.core.rmem_default = 262144 # 256 KB net.core.wmem_default = 262144 # 256 KB TCP Auto-tuning (net.ipv4.tcp_rmem and tcp_wmem) Parameters accept three values: [min] [default] [max] (in bytes):\n# min, default, max for incoming TCP buffers net.ipv4.tcp_rmem = 4096 87380 67108864 # min, default, max for outgoing TCP buffers net.ipv4.tcp_wmem = 4096 65536 67108864 # Enable Window Scaling (RFC 1323) — mandatory for buffers \u0026gt; 64KB! net.ipv4.tcp_window_scaling = 1 Global TCP Memory Pool (net.ipv4.tcp_mem) Specified in memory pages (typically 1 page = 4096 bytes): [low] [pressure] [high]. By default, the kernel calculates this based on RAM size, but on memory-constrained machines it\u0026rsquo;s worth checking:\nsysctl net.ipv4.tcp_mem 5. Mitigating Bufferbloat: Qdisc and BBR Excessive buffer increases lead to Bufferbloat: packets are not lost, but accumulate in huge queues, causing massive latencies (RTT jumps from milliseconds to seconds).\nTo prevent this:\nUse modern queue management algorithms: Fair Queueing (fq) or fq_codel / cake. Use BBR (Bottleneck Bandwidth and RTT) as the congestion control algorithm: net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr Ready Configuration File Create file /etc/sysctl.d/99-network-performance.conf:\n# ==================================================================== # Linux Network Buffer and Stack Optimization for High-Load # ==================================================================== # Maximum queue lengths net.core.somaxconn = 65535 net.core.netdev_max_backlog = 16384 # Maximum and default socket buffer sizes (bytes) net.core.rmem_max = 67108864 net.core.wmem_max = 67108864 net.core.rmem_default = 262144 net.core.wmem_default = 262144 # TCP buffer auto-tuning: min default max (bytes) net.ipv4.tcp_rmem = 4096 87380 67108864 net.ipv4.tcp_wmem = 4096 65536 67108864 # Enable TCP Window Scaling and Timestamps net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_sack = 1 # Qdisc and congestion control (Bufferbloat mitigation) net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr # TCP SYN flood protection net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 16384 Apply parameters without rebooting:\nsudo sysctl --system Verification Checklist Check ethtool -S for rx_dropped / rx_fifo_errors. Increase network card Ring Buffer (ethtool -G rx \u0026lt;max\u0026gt; tx \u0026lt;max\u0026gt;). Calculate BDP for primary server network routes. Configure sysctl socket buffers and TCP window scaling. Enable fq + bbr to reduce latency and eliminate Bufferbloat. Perform load testing using iperf3 -P \u0026lt;threads\u0026gt; or wrk before and after changes. ","permalink":"https://tomahawk-center.info/posts/network-buffer-tuning/","summary":"A comprehensive practical guide to Linux networking stack tuning: NIC ring buffers (ethtool), kernel backlog queues, TCP socket buffers (rmem/wmem), BDP calculation, and Bufferbloat mitigation.","title":"Linux Network Buffer Tuning: From Ring Buffers to TCP Socket Memory"}]