Debian 13 networking tools

Option A: AWS Marketplace console

• Open the SecureAnyCloud Debian listing on AWS Marketplace, choose View purchase options, then choose Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace (or Launch from EC2 Console for full control). In Version, choose Debian 13 Networking Tools - YYYY-MM-DD (the date is when the version was added), then choose your Region.
• Instance type: m5.large is recommended, and any current x86_64 type works. The software charge is $0.04 per vCPU per hour.
• Key pair: choose your EC2 key pair. It is the only way in. RSA and ED25519 keys both work.
• Security group: allow inbound TCP 22 from your own IP address or network only.
• Storage: the root volume is 8 GiB gp3 by default. Choose a larger size if you keep packet captures on the instance. cloud-init grows the root partition and filesystem to fill it on first boot.
• Metadata: leave the defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this command on your own workstation. Replace the AMI ID with the one shown for your Region on the Marketplace launch page, and replace the key pair, security group and subnet with your own. The root device of this AMI is /dev/xvda:

aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --block-device-mappings 'DeviceName=/dev/xvda,Ebs={VolumeSize=20,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=debian-13-networking-tools}]'

You do not need --metadata-options, because the AMI already makes IMDSv2 required.

From your workstation, connect as admin with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem admin@<public-ip>

There is no password to enter. If SSH asks for one, or says Too many authentication failures, see Troubleshooting below.

You can also connect without opening port 22 at all, through AWS Systems Manager Session Manager. This requires an instance profile that allows Systems Manager. The agent is installed and running on this image.

Check the Debian release, the kernel and the installed package count:

cat /etc/debian_version grep -E '^(PRETTY_NAME|VERSION_ID|VERSION_CODENAME|ID)=' /etc/os-release uname -srm dpkg-query -W -f='${db:Status-Abbrev}\n' | grep -c '^ii'

Expected output:

13.7 PRETTY_NAME="Debian GNU/Linux 13 (trixie)" VERSION_ID="13" VERSION_CODENAME=trixie ID=debian Linux 6.12.113+deb13-cloud-amd64 x86_64 495

This version follows Debian 13. It receives every Debian 13 point release (13.7 at build time) through normal apt updates. Your kernel version may be newer if updates have installed since this image was built.

The package count moves by a few as kernels and updates install. It moves by one more if your account runs Amazon Inspector, whose Systems Manager association installs its own inspectorssmplugin package.

The image describes its own networking set. The build wrote the manifest from the package database when the image was created. Count the entries and show the first few:

grep -vc '^#' /usr/share/doc/sac/pkgprofile-networking-manifest.txt
grep -v '^#' /usr/share/doc/sac/pkgprofile-networking-manifest.txt | head -6

Expected output (each line is package, version at build time, licence, licence verdict):

56 iproute2 6.15.0-1 GPL-2.0-only allow net-tools 2.10-1.3 GPL-2.0-or-later allow tcpdump 4.99.5-2 BSD-3-Clause allow traceroute 1:2.1.6-1 GPL-2.0-or-later allow mtr-tiny 0.95-1.1+b1 GPL-2.0-or-later allow iperf3 3.18-2+deb13u2 BSD-3-Clause-LBNL allow

• The versions are the ones installed when the image was built. apt updates them like any other package, and dpkg -l <package> shows what is installed now.
• curl is marked base-image. It is part of every Debian image already, and its licence (the curl licence) is listed as it is.
• The manifest also lists the excluded packages with their reasons, the 17 masked services, and every dependency the networking set pulled in (117 packages in total). Read it all with less /usr/share/doc/sac/pkgprofile-networking-manifest.txt.

Each package's full licence text is in /usr/share/doc/<package>/copyright.

The evaluation that the build ran after its reboot ships on the image, as in the standard Debian 13 version. Print the summary and the failing rules:

python3 -c "import json; s=json.load(open('/usr/share/doc/sac/cis-l1-summary.json')); print('profile: ', s['profileLabel'], '(SCAP Security Guide', s['ssgVersion'] + ')'); print('scored rules: ', s['scored'], ' pass:', s['pass'], ' fail:', s['fail'], '(+%d error)' % s['error'], ' rate:', str(s['ratePct']) + '%'); print('waived: ', s['waived'], ' not applicable:', s['notapplicable'])"
python3 -c "import json; [print(r) for r in json.load(open('/usr/share/doc/sac/cis-l1-summary.json'))['failingRules']]"

Expected output:

profile: CIS Level 1 Server (SCAP Security Guide 0.1.82) scored rules: 363 pass: 359 fail: 3 (+1 error) rate: 98.9% waived: 6 not applicable: 33 file_ownerships_var_log journald_forward_to_syslog service_systemd-journal-upload_enabled systemd_journal_upload_url

These files are in /usr/share/doc/sac/: the HTML report (cis-l1-report.html), the machine-readable results (cis-l1-arf.xml), the tailoring (cis-l1-tailoring.xml) and the six waived rules with their reasons (cis-l1-waivers.txt). The Debian 13 guide explains each waiver.

The four rules that do not pass stay in the score rather than being hidden:

• journald forwarding and the remote journal upload (journald_forward_to_syslog, service_systemd-journal-upload_enabled, systemd_journal_upload_url) are the same three as in the standard Debian 13 version. The profile asks for both journal forwarding settings at once, and the image cannot know your log collector. To send the journal to yours, set URL= in /etc/systemd/journal-upload.conf, then run sudo systemctl enable --now systemd-journal-upload.
• Log file ownership (file_ownerships_var_log) reports error, not fail. The check accepts only files owned by root or a syslog account, and Debian has no syslog account. The one file it trips on is /var/log/aide/aide.log, which belongs to the _aide account on purpose. Debian's daily AIDE check runs as _aide and has to rotate its own log. If that file belonged to root, the daily check would fail every day, and the instance would report a failed service.

To re-run the evaluation yourself, which takes about a minute, run:

sudo oscap xccdf eval \
  --tailoring-file /usr/share/doc/sac/cis-l1-tailoring.xml \
  --profile xccdf_co.sac_profile_cis-l1_ec2_single \
  --results /tmp/cis-check-results.xml --report /tmp/cis-check-report.html \
  /usr/share/xml/scap/ssg/content/ssg-debian13-ds.xml > /tmp/cis-check.log 2>&1 echo "oscap exit code: $? (2 = at least one rule did not pass)"
sudo python3 -c "import re,collections; c=collections.Counter(re.findall(r'<result>(\w+)</result>', open('/tmp/cis-check-results.xml').read())); s=sum(c[k] for k in ('pass','fail','error','unknown')); print(dict(sorted(c.items()))); print('pass rate: %.1f%%' % (100.0*c['pass']/s))"

Expected output:

oscap exit code: 2 (2 = at least one rule did not pass) {'error': 1, 'fail': 4, 'notapplicable': 33, 'notchecked': 1, 'notselected': 380, 'pass': 358} pass rate: 98.6%

A running instance scores one rule lower than the shipped evaluation (file_permissions_backup_etc_shadow). On first boot, cloud-init locks the admin password, and the system writes a new /etc/shadow- backup at mode 0640. Running sudo chmod 0000 /etc/shadow- makes the rule pass again. The Debian 13 guide explains it in full.

Send one metadata request without a token and one with a token:

curl -s -o /dev/null -w 'IMDSv1 request without a token: HTTP %{http_code}\n' http://169.254.169.254/latest/meta-data/instance-id
TOKEN=$(curl -s -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' http://169.254.169.254/latest/api/token)
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" -w '\n' http://169.254.169.254/latest/meta-data/placement/region

Expected output (your Region may differ):

IMDSv1 request without a token: HTTP 401 us-east-1

Check the firewall, the listening ports and the state of the masked services:

sudo ufw status verbose
sudo ss -tlnp systemctl is-enabled frr.service bird.service openvpn.service wg-quick@.service lldpd.service vnstat.service nftables.service || true

Expected output (process IDs vary):

Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- Anywhere on lo ALLOW IN Anywhere 22/tcp ALLOW IN Anywhere 68/udp ALLOW IN 67/udp
# DHCP client: replies from a DHCP server (port 67) 53 on lo ALLOW IN Anywhere
# systemd-resolved loopback stub 127.0.0.54:53 (lo only) Anywhere (v6) on lo ALLOW IN Anywhere (v6) 22/tcp (v6) ALLOW IN Anywhere (v6) 53 (v6) on lo ALLOW IN Anywhere (v6)
# systemd-resolved loopback stub 127.0.0.54:53 (lo only) State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=852,fd=6)) LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=336,fd=17)) LISTEN 0 20 127.0.0.1:25 0.0.0.0:* users:(("exim4",pid=1452,fd=5)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=336,fd=15)) LISTEN 0 20 [::1]:25 [::]:* users:(("exim4",pid=1452,fd=6)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=852,fd=7)) masked masked masked masked masked masked masked

• Only sshd listens on a network address, on port 22. The DNS stub resolver (127.0.0.53 and 127.0.0.54) and the local mail service (exim4, port 25) listen on loopback only, exactly as on the standard Debian 13 version.
• masked means the service cannot be started, by hand, at boot or by a package update, until you unmask it (Step 8). The full list is in the manifest.
• ufw and the packet filtering tools. ufw is the host firewall. It drives the kernel's packet filter through iptables (the nftables backend), so sudo nft list ruleset and sudo iptables -S show ufw's chains. Use these commands to inspect, and make changes with ufw. If you would rather manage the firewall with your own nftables ruleset, disable ufw first (sudo ufw disable), then unmask and enable nftables.service. Never run both.
• Opening a port for your own service takes two steps. Allow it in the instance's security group, and allow it in ufw (for example sudo ufw allow 179/tcp for BGP).

Nothing starts by itself. To run one of the masked services, unmask it, enable it, then open its port in the security group and ufw. For example, to start LLDP neighbour discovery:

sudo systemctl unmask lldpd.service
sudo systemctl enable --now lldpd.service
sudo lldpcli show neighbors

The other services follow the same pattern: frr.service (configure the daemons in /etc/frr/daemons first), bird.service (/etc/bird/bird.conf), openvpn-server@<name>.service or openvpn-client@<name>.service (with /etc/openvpn/server/<name>.conf or /etc/openvpn/client/<name>.conf), wg-quick@<interface>.service (with /etc/wireguard/<interface>.conf), vnstat.service, conntrackd.service and iperf3.service. To put one back the way it shipped, run:

sudo systemctl disable --now lldpd.service
sudo systemctl mask lldpd.service

Three things to know before you route or tunnel traffic through the instance:

• IP forwarding is off. The CIS profile turns it off in /etc/sysctl.conf (net.ipv4.conf.all.forwarding = 0, net.ipv6.conf.all.forwarding = 0 and their default counterparts). A router or VPN gateway needs it on, which is a deliberate departure from the benchmark. Change the IPv4 line to 1 in /etc/sysctl.conf, and uncomment net/ipv4/ip_forward=1 in /etc/ufw/sysctl.conf (ufw applies that file when it starts). Do the same for the IPv6 lines if you route IPv6. Then run sudo sysctl --system && sudo ufw reload. /usr/sbin/sysctl net.ipv4.ip_forward then reports 1, and it stays on after a reboot.
• ufw blocks routed traffic (disabled (routed)). Allow what you route with sudo ufw route allow ....
• EC2 drops traffic that is not addressed to the instance unless you turn off source/destination check on its network interface (EC2 console, Networking, Change source/destination check). Routing and VPN gateway instances need it off.

Every example below runs as shipped, with no service to start.

Interfaces and addresses:

ip -brief address show

Expected output (your addresses will differ):

lo UNKNOWN 127.0.0.1/8 ::1/128 ens5 UP 172.31.89.177/20 metric 100 fe80::10ff:ceff:fec9:ef13/64

Capture traffic (capture needs sudo). This command starts a capture of ICMP on the instance's network interface, then sends two pings so there is something to see:

(sudo timeout 20 tcpdump -i ens5 -c 4 -n -q icmp 2>&1 &); sleep 2; ping -c 2 -q 1.1.1.1 >/dev/null; sleep 2

Expected output (your address and the timings will differ):

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ens5, link-type EN10MB (Ethernet), snapshot length 262144 bytes 21:10:41.816124 IP 172.31.89.177 > 1.1.1.1: ICMP echo request, id 1, seq 1, length 64 21:10:41.817042 IP 1.1.1.1 > 172.31.89.177: ICMP echo reply, id 1, seq 1, length 64 21:10:42.817182 IP 172.31.89.177 > 1.1.1.1: ICMP echo request, id 1, seq 2, length 64 21:10:42.818098 IP 1.1.1.1 > 172.31.89.177: ICMP echo reply, id 1, seq 2, length 64 4 packets captured 4 packets received by filter 0 packets dropped by kernel

On a Nitro instance the network interface is ens5 (ip -brief address show lists it). tshark -i ens5 captures the same way with Wireshark's decoders.

Query DNS with BIND's dig or ldns's drill:

dig +short A secureanycloud.com | head -3 drill -Q debian.org NS | head -3

Expected output (the answers change over time):

d14bmdyrx9dte8.cloudfront.net. 3.167.88.51 3.167.88.56 dns4.easydns.info. sec1.rcode0.net. sec2.rcode0.net.

Trace a path:

mtr -n -r -c 2 -m 4 1.1.1.1

Expected output (hops and timings depend on your Region and network):

Start: 2026-10-24T20:55:07+0000 HOST: ip-172-31-89-177 Loss% Snt Last Avg Best Wrst StDev 1.|-- 244.5.8.69 0.0% 2 7.1 4.8 2.4 7.1 3.3 2.|-- 240.0.60.131 0.0% 2 0.5 0.5 0.5 0.5 0.0 3.|-- 242.1.11.87 0.0% 2 1.0 1.2 1.0 1.4 0.3 4.|-- 52.46.166.112 0.0% 2 1.6 1.8 1.6 2.0 0.3

Measure throughput. iperf3 needs a server at the far end. You can prove the tool works against the instance's own loopback first. The -1 flag makes the server exit after one test, so nothing is left listening:

(iperf3 -s -1 -p 5399 -B 127.0.0.1 >/dev/null 2>&1 &) ; sleep 1; iperf3 -c 127.0.0.1 -p 5399 -t 1 -f m | tail -4

Expected output (the rate depends on your instance type):

[ 5] 0.00-1.00 sec 3.44 GBytes 29539 Mbits/sec 0 sender [ 5] 0.00-1.00 sec 3.44 GBytes 29537 Mbits/sec receiver iperf Done.

To test between two instances, run iperf3 -s on one (allow TCP 5201 from the other in both the security group and ufw) and iperf3 -c <its private IP> on the other.

Plan addresses:

ipcalc-ng 10.20.0.0/22 | head -8

Expected output:

Network: 10.20.0.0/22 Netmask: 255.255.252.0 = 22 Broadcast: 10.20.3.255 Address space: Private Use HostMin: 10.20.0.1 HostMax: 10.20.3.254 Hosts/Net: 1022

Tool versions. Several of the routing and tunnel tools live in /usr/sbin:

dpkg-query -W -f='${Package} ${Version}\n' frr tshark wireguard-tools iperf3 bind9-dnsutils /usr/sbin/openvpn --version | head -1 /usr/sbin/bird --version 2>&1 | head -1

Expected output (the versions move forward with Debian security updates):

frr 10.3-3+deb13u1 tshark 4.4.19-0+deb13u1 wireguard-tools 1.0.20210914-3 iperf3 3.18-2+deb13u2 bind9-dnsutils 1:9.20.30-1~deb13u1 OpenVPN 2.6.14 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] BIRD version 2.17.5

The image is fully patched at build time. Check what is pending now and how long Debian supports what is installed:

sudo apt-get update -qq apt list --upgradable 2>/dev/null cat /etc/apt/apt.conf.d/20auto-upgrades check-support-status --no-heading

Expected output on an instance launched soon after the image was built (later launches list the updates released since):

Listing... APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; * Source:rust-rpm-sequoia Details: See https://www.debian.org/releases/trixie/release-notes/issues.en.html#go-and-rust-based-packages Affected binary package: - librpm-sequoia-1:amd64 (installed version: 1.8.0-2)

check-support-status (from Debian's debian-security-support package, installed for this purpose) lists installed packages whose security support is limited or ended. None of the networking packages is listed.

The one entry is librpm-sequoia-1, a Rust-based library that OpenSCAP's scanner depends on. It is on every SecureAnyCloud Debian 13 version. Debian's release notes explain that Go-based and Rust-based packages get security updates on a best-effort basis.

unattended-upgrades runs daily and installs updates from the Debian and Debian-Security archives automatically, the networking packages included. To update everything now, run sudo apt-get update && sudo apt-get -y upgrade. Reboot if a new kernel was installed.

Check the root account, the SSH settings, the time source and the file integrity timer:

sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|x11forwarding|maxauthtries) ' stat -c '%a %U:%G %n' /usr/bin/dumpcap chronyc -n sources | grep '^\^\*' systemctl is-enabled aidecheck.timer systemctl is-system-running

Expected output (the time source timings vary):

root L 2026-10-21 0 99999 7 -1 maxauthtries 4 permitrootlogin no passwordauthentication no x11forwarding no 755 root:root /usr/bin/dumpcap ^* 169.254.169.123 3 4 377 6 +16us[ +16us] +/- 490us enabled running

• L means the root account is locked. SSH is key-only (pinned in /etc/ssh/sshd_config.d/00-ec2-key-only.conf).
• dumpcap is mode 755 with no setuid bit and no file capabilities, so only root can capture. To let a group capture without sudo, run sudo dpkg-reconfigure wireshark-common, answer yes, and add the account to the wireshark group.
• chrony uses the Amazon Time Sync Service (169.254.169.123), which works in a private subnet.
• AIDE checks file integrity at boot and daily (aidecheck.timer, with results in journalctl -u aidecheck). After you install or change software, refresh its database with sudo aide --config /etc/aide/aide.conf --init, then sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
• running means no service failed during boot.

EC2 Serial Console. No account on this image has a password, so the serial console cannot log in until you set one for your own user (sudo passwd admin).