Inspect Service Exposure Before Changing Ports

A service listening on every interface is not proof that the Internet can reach it, and a closed router port is not proof that no other route exists. Start by identifying the listener, intended clients and actual connection path.

Outcome: a service-exposure inventory and a harmless connection to a temporary localhost-only server. You need ss on the Pi, Python 3 for the optional lab, and curl in a second Pi terminal. Complete the SSH access check first. Do not change the firewall or router for this lesson.

1. Read the local listeners

Run these read-only commands on the Pi host:

ss -lnt
ss -lnu

-l selects listeners/bound listening-style sockets, -n keeps numeric addresses/ports, and -t/-u select TCP/UDP. UDP does not have TCP's connection/listen handshake. The iproute2 ss manual describes the fields and filters.

Interpret a binding separately from its reachability:

• 127.0.0.1:8765: IPv4 loopback on this host; a separate machine cannot directly reach that address on your Pi.
• A specific LAN address: bound to that address, subject to routing and access controls.
• 0.0.0.0:22: all local IPv4 interfaces for this socket, not “Internet access confirmed.”
• [::]:22: an IPv6 wildcard; whether it also accepts IPv4 depends on the socket/system configuration.

Some listeners belong to a socket-activation service, container proxy or another manager. Identify ownership before disabling it. Privileged process details may need administrative inspection; their absence from ordinary-user output is not proof that a socket has no owner.

2. Trace the route a client would use

Write one row per intended service in your private notes: service, account, local bind address, intended clients, authentication, and route. A route might be LAN, VPN, an SSH tunnel, a reverse proxy/tunnel, or router forwarding.

A reverse proxy may expose an application whose own listener is loopback-only. A VPN may add clients beyond the home LAN. IPv6 routing is not identical to IPv4 NAT. Do not judge exposure from one router screen alone.

Test only your own authorized service from the relevant client. A connection succeeding proves reachability for that source/path at that moment; it does not enumerate all possible paths. A failure may be caused by routing, a firewall, authentication, service state or DNS. Do not scan networks you do not administer.

3. Optional loopback-only lab

This lab creates one new private directory and a disposable text file on the Pi, then starts a foreground server for at most 30 seconds. It does not use root, open a firewall or bind to the LAN. Use two Pi terminals, which may be separate SSH sessions.

First check whether the practice port is already in use:

ss -lnt 'sport = :8765'

If a socket is listed, do not stop it. Choose a different unused high port and substitute it consistently, or skip the lab.

In Pi terminal A, run the whole block:

(
    set -eu
    umask 077
    exposure_lab=$(mktemp -d /tmp/pi-security-exposure.XXXXXXXX)
    printf 'Practice directory: %s\n' "$exposure_lab"
    printf 'Loopback practice only.\n' > "$exposure_lab/hello.txt"
    timeout 30s python3 -m http.server 8765 \
        --bind 127.0.0.1 --directory "$exposure_lab"
)

While it runs, in Pi terminal B:

ss -lnt 'sport = :8765'
curl --max-time 3 http://127.0.0.1:8765/hello.txt

Expect a 127.0.0.1:8765 listener and the sample text. The Python http.server documentation explains --bind and warns against using this development server for production. Do not serve your home directory or real secrets.

The timeout ends the server and normally returns status 124; that is expected here, not a service failure. Ctrl+C in terminal A stops it earlier. Confirm afterward that the listener is gone. The private sample directory is left for inspection; remove only its sample file and then the empty directory when finished.

If the port becomes occupied between checks, the server should fail to bind. Do not kill an unrelated process or switch to a wildcard bind to make the example work. 127.0.0.1 in a client-computer terminal refers to that computer, not the Pi—run terminal B on the Pi as specified.

Authentication, encryption and filtering are separate

Authentication decides who may use an application. TLS protects a connection's transport and helps authenticate its endpoint. A firewall filters traffic; router forwarding changes a route. None automatically substitutes for the others or corrects an application vulnerability.

Choose a private-access method deliberately before exposing an administrative UI. The remote-access guide and SSH/firewall hardening guide cover implementation choices. This lesson creates no persistent network configuration.

Checkpoint: why can a loopback application still be exposed through a reverse proxy? What does an all-interface listener tell you, and what does it not tell you?

Next: test one service restriction in a transient user service. Return to Security.

The loopback lab, sample response and automatic stop were checked on the verification Pi. This was not a LAN/Internet exposure test; see the verification scope.