Debian 13 Pkg networking

Option A: Azure Portal

• Sign in to the Azure Portal.
• Search the Marketplace for Debian 13 Networking Tools and select the SecureAnyCloud offering.
• Click Create.
• Choose your subscription, resource group and region.
• Set the VM size to Standard_B2s or larger.
• Under Administrator account, choose SSH public key, leave the user name as azureuser, and paste your public key.
• Under Inbound port rules, allow SSH (22) only, and restrict the source to your own management address range.
• Select Review + create.

Option B: Azure CLI

az vm create \
  --resource-group my-resource-group \
  --name debian-nettools \
  --image sac:debian-13-pkg-networking:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

ssh azureuser@<vm-ip>

Replace <vm-ip> with your virtual machine's public IP address.

Check that you have the release you expect:

grep -E '^(PRETTY_NAME|VERSION|VERSION_ID|ID)=' /etc/os-release uname -srm cat /etc/debian_version

Expected output:

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

Now confirm the profile. Every entry resolves to a single component, which is the whole point on Debian:

awk -F'\t' 'NF>=3{print $3}' /usr/share/sac/debian-13-pkg-networking.manifest | sort | uniq -c

Expected output:

64 main

That count is the 63 networking packages plus debian-security-support. It is the one package added so the image can report its own support status, which Step 6 uses.

The manifest is generated from the image's own package database at build time, so it cannot drift from what is installed:

head -8 /usr/share/sac/debian-13-pkg-networking.manifest

Expected output (the generation timestamp will differ):

# sac debian-13-pkg-networking — shipped package profile
# Derived from the dpkg database at build time. Do not hand-edit.
# generated: 2026-09-18T21:26:26Z
# suite: trixie (Debian 13) — every entry is component MAIN
#
# [main] — Debian Security Team coverage, then Debian LTS to 2030-06-30 iproute2 6.15.0-1 main net-tools 2.10-1.3 main

List the profile with the versions you have:

awk -F'\t' 'NF>=3 && $3=="main"{printf "%-22s %s\n",$1,$2}' /usr/share/sac/debian-13-pkg-networking.manifest | head -8

Expected output:

iproute2 6.15.0-1 net-tools 2.10-1.3 tcpdump 4.99.5-2 traceroute 1:2.1.6-1 mtr-tiny 0.95-1.1+b1 iperf3 3.18-2+deb13u2 ethtool 1:6.14.2-1 iputils-ping 3:20240905-3

Every package resolves to Debian's own archive. There is no third party repository on this image:

apt-cache policy tcpdump

Expected output:

tcpdump: Installed: 4.99.5-2 Candidate: 4.99.5-2 Version table: *** 4.99.5-2 500 500 mirror+file:/etc/apt/mirrors/debian.list trixie/main amd64 Packages 100 /var/lib/dpkg/status

The only source offering this package is trixie/main. The mirror+file: URI is Debian's own Azure mirror list, azure.deb.debian.cloud. The official Debian cloud images use it so that package downloads stay inside Azure's network. Every package on the image answers the same way.

trixie-backports is enabled in the apt sources, as it is on stock Debian cloud images, but no package on this image comes from it. Backports carry priority 100 against the main archive's 500, so apt never selects them unless you ask for one explicitly.

This property makes the image safe to deploy as it stands. Every service is present and switched off:

systemctl list-unit-files nftables.service frr.service lldpd.service openvpn.service vnstat.service bird.service conntrackd.service netfilter-persistent.service

Expected output:

UNIT FILE STATE PRESET bird.service disabled enabled conntrackd.service disabled enabled frr.service disabled enabled lldpd.service disabled enabled netfilter-persistent.service disabled enabled nftables.service disabled enabled openvpn.service disabled enabled vnstat.service disabled enabled 8 unit files listed.

Note the two columns. PRESET is what Debian would normally do with each unit, which is enable it. STATE is what this image ships, which is disabled. That gap is the deliberate choice this product makes.

These eight are the units with a plain name. The profile also ships the templated units frr@, openvpn@, openvpn-client@, openvpn-server@ and wg-quick@, which start nothing until you name an instance.

And the listening set:

ss -tln | awk '$1=="LISTEN"{print $1, $4}' | sort -u

Expected output:

LISTEN 0.0.0.0:22 LISTEN 127.0.0.53%lo:53 LISTEN 127.0.0.54:53 LISTEN [::]:22

The only socket reachable from the network is SSH on port 22. The two entries on 127.0.0.53 and 127.0.0.54 are systemd-resolved, Debian's stock local DNS stub. They are bound to loopback and cannot be reached from outside the machine.

Check UDP too, because this is where stock Debian differs:

ss -uln | awk 'NR>1{print $4}' | sort -u

Expected output:

10.0.0.10%eth0:68 127.0.0.1:323 127.0.0.53%lo:53 127.0.0.54:53 [::1]:323

Port 68 is the DHCP client, and 323 is chrony on loopback. There is no 5355. Stock Debian 13 enables LLMNR in systemd-resolved, which binds TCP and UDP 5355 on every interface. This image turns it off:

resolvectl status | grep -E 'Protocols|Current Scopes' | head -2

Expected output:

Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current Scopes: DNS

The leading - on -LLMNR confirms that it is off. To turn it back on, remove /etc/systemd/resolved.conf.d/20-sac-no-llmnr.conf and restart systemd-resolved.

The image is fully patched at build time. Check what is pending:

apt-mark showhold
sudo apt-get update -qq sudo apt-get -s dist-upgrade | grep -c '^Inst ' || true

apt-mark showhold prints nothing when no package is held. The count is the number of updates still pending. It grows over time as Debian publishes new updates, and unattended-upgrades applies them for you.

More importantly, nothing on this image has limited or ended security support. Debian publishes that list in the debian-security-support package. It ships on this image, so you can check it yourself at any time:

sudo check-support-status --no-heading

Expected output:

The output is empty, and that is the point. check-support-status names every installed package whose security support has ended or is limited, and on this image it names none. Compare that with Debian's own list of packages it would have flagged:

grep -vE '^#|^$' /usr/share/debian-security-support/security-support.deb13 | wc -l
grep -E '^isc-dhcp' /usr/share/debian-security-support/security-support.deb13

Expected output:

32 isc-dhcp non-supported 4.4.3-P1-2 2023-07-05 https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html

Thirty-two packages are on Debian's watch list for trixie, and the image deliberately carries none of them. isc-dhcp-client is excluded from this profile for exactly the reason shown above.

Everything in this step runs as shipped, with no service to start.

Look at your interfaces:

ip -brief address show ip -brief link show

Expected output (your addresses will differ):

lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 10.0.0.10/24 metric 100 fe80::20d:3aff:fe1c:e2c1/64 lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> eth0 UP 00:0d:3a:1c:e2:c1 <BROADCAST,MULTICAST,UP,LOWER_UP>

Capture live traffic:

sudo timeout 20 tcpdump -i any -c 3 -n -q

Expected output (the addresses and ports will differ):

21:38:06.143187 eth0 Out IP 10.0.0.10.44276 > 168.63.129.16.80: tcp 0 21:38:06.144012 eth0 In IP 168.63.129.16.80 > 10.0.0.10.44276: tcp 0 3 packets captured 30 packets received by filter 0 packets dropped by kernel

168.63.129.16 is Azure's own platform endpoint (the "wire server"). Seeing it here is normal.

Query DNS. The image has two independent resolvers, dig from BIND and drill from ldns:

dig +short A secureanycloud.com | head -3 dig +noall +answer NS debian.org | head -2

Expected output:

d14bmdyrx9dte8.cloudfront.net. 3.167.88.56 3.167.88.51 debian.org. 614 IN NS nsp.dnsnode.net. debian.org. 614 IN NS dns4.easydns.info.

Look up who owns an address.

whois -H 1.1.1.1 | grep -iE '^(netname|descr):' | head -3

Expected output:

netname: APNIC-LABS descr: APNIC and Cloudflare DNS Resolver project descr: Routed globally by AS13335/Cloudflare

Measure throughput. iperf3 normally needs a server at the far end. Before you point it anywhere, you can prove the tool works against your own loopback:

(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 VM size):

[ 5] 0.00-1.00 sec 2.53 GBytes 21707 Mbits/sec 0 sender [ 5] 0.00-1.00 sec 2.53 GBytes 21707 Mbits/sec receiver iperf Done.

The -1 flag makes the server exit after one connection, so nothing is left listening.

Inspect the packet filter.

sudo nft list tables

Expected output:

The output is empty. There are no nftables tables at all, and therefore no host firewall policy on this image. Azure network security groups do that job in front of the VM. If you want a host firewall as well, write /etc/nftables.conf and enable nftables.service. Alternatively, use iptables and save your rules with netfilter-persistent save.

Nothing starts by itself. When you do want a daemon, enable it explicitly:

# Example only — run these when you actually want the service.
sudo systemctl enable --now nftables.service
# load /etc/nftables.conf at boot
sudo systemctl enable --now vnstat.service
# keep long term interface counters
sudo systemctl enable --now lldpd.service
# discover neighbours over LLDP
sudo systemctl enable --now netfilter-persistent.service
# restore saved iptables rules at boot

Know these three things before you enable anything:

• Open the port in your network security group too. The image does not filter, but Azure does. A service that is running and still unreachable is almost always an NSG rule, not the VM.
• nftables.service and netfilter-persistent.service do the same job in two different ways. Enable one, not both. nftables.service loads /etc/nftables.conf, and netfilter-persistent replays rules saved from iptables.
• tshark capture as a non-root user is not available as shipped. dumpcap is deliberately left without the setuid bit and without cap_net_raw, so capture requires sudo. For group-based capture instead, run sudo dpkg-reconfigure wireshark-common, answer yes, and add your account to the wireshark group.

This image applies the standard SecureAnyCloud mitigation for CVE-2026-43284 and CVE-2026-43500. It prevents the kernel's ESP and IP payload compression modules from loading:

cat /etc/modprobe.d/dirtyfrag.conf

Expected output:

install esp4 /bin/false install esp6 /bin/false install ipcomp /bin/false install ipcomp4 /bin/false install ipcomp6 /bin/false install rxrpc /bin/false

This does not affect WireGuard or OpenVPN, the two tunnel implementations on this image, because neither uses kernel ESP. It does mean that if you install strongswan or libreswan and try to terminate an IPsec tunnel on this machine, the kernel refuses to load the modules it needs. If that is your use case, remove the file and reboot:

# Only if you are terminating IPsec ON this VM.
sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo reboot

Traffic through an Azure VPN Gateway is unaffected, because the gateway terminates IPsec, not your VM.