Prove nothing is using it before you switch it off

What happened and why it matters

I found a couple of programs on my computers that were quietly accepting connections from anywhere on my network, when they only ever needed to talk to the machine they were already sitting on. That is a genuine thing worth fixing, and the fix is a single line of settings. It takes ten seconds.

Do not do it in ten seconds. Prove nobody is using it first.

Here is why the ten second version is a trap. A doorway open to the whole network is reachable by other machines. That is the security problem. But it might also be something that another machine is quietly relying on. Some job on a different computer connects to it at three in the morning, once a week, and has done for a year. Nobody wrote it down. The person who set it up was you, eighteen months ago.

So instead of ten seconds, I spent twenty minutes proving it. I looked at what was actually connected to those doorways, and I looked from both ends rather than only from the machine running the program. Nothing outside the machine was talking to them. Then, and only then, I changed the setting so they answer only to programs on their own computer, and I left everything else exactly as it was.

The same care covered the rest of the clear out. I found five programs that were running and doing nothing whatsoever, and two databases belonging to a project that was paused rather than abandoned.

Paused is not the same as finished

The paused project is the interesting one, because it is exactly where people reach for the wrong verb. The instinct when tidying is to remove things. But paused means somebody is coming back, and the thing they will need when they come back is the data.

So the correct move is to stop the thing and keep everything it owns. Nothing was deleted. The stored data stayed exactly where it was. All that changed is that those programs are no longer running and no longer using any memory.

That difference is worth saying out loud, because the tools blur it badly. Stopping something and destroying it are frequently one word apart on the same instruction, and the version that also destroys your data is very often the one suggested in the first answer you find online. Read the instruction you are about to run and specifically ask yourself what happens to the stored data.

The rule this leaves you with

Every cleanup step should be reversible, and you should know the exact way to reverse it before you run the thing that does it.

Switching a program off is reversible. Deleting its data is not. Closing a doorway is reversible. Destroying a database is not. When you have a reversible option and an irreversible one, and both achieve what you want today, the reversible one is not the timid choice. It is simply the correct one.

The whole lesson fits in one sentence. Prove it is unused, make the change reversible, and never let a tidy up be the thing that destroys your data. This is the same idea as measure before you delete, pointed at your network instead of your hard drive.

How to do it yourself

This half is for people who want to actually do it. Steps one to three only look at things and change nothing at all, so they are safe to run out of curiosity. If you would rather stop reading here, you have already got the useful part.

1. See which doorways are open, and how widely

ss -ltnp

# the same list, narrowed to only the ones open to the network
ss -ltnp | grep -E '0\.0\.0\.0|\[::\]'

2. Check whether anything is actually connected, from both ends

# on the machine that hosts it: who is connected right now, and from where
ss -tnp state established "( sport = :PORT )"

# on another machine: is anything here reaching out to it
ss -tnp state established "( dport = :PORT )"

Do not skip the second one. The entire risk here is a dependency you have forgotten about, and forgotten dependencies live on other machines by definition.

3. Watch over a real stretch of time, not a single moment

# log the number of connections, once a minute
while true; do
  printf '%s %s\n' "$(date -Is)" \
    "$(ss -tn state established "( sport = :PORT )" | tail -n +2 | wc -l)"
  sleep 60
done >> /tmp/port-watch.log

sort -k2 -n /tmp/port-watch.log | tail -5

4. Change the setting so it only listens to itself

# PostgreSQL, in the file postgresql.conf
listen_addresses = 'localhost'

# Redis, in the file redis.conf
bind 127.0.0.1

# Docker, in the compose file: publish to this machine only
ports:
  - "127.0.0.1:5432:5432"      # not "5432:5432"

Then run the command from step one again to confirm the address changed, and check that the program on this machine which legitimately uses it still works. If other machines genuinely do need to reach it, the right answer is to put those machines on a private network together rather than opening the door to everything, which is what reach your own computers from anywhere without opening your front door is about.

5. Stop things without losing what they hold

# reversible, and the data is not touched
sudo systemctl disable --now some-service
# to bring it back: sudo systemctl enable --now some-service

# stops them, keeps the containers AND the stored data
docker compose stop

# DANGER: this one deletes the stored data. one word longer.
# docker compose down -v

One more trap worth knowing. If several unrelated things are grouped into the same project, shutting the whole project down can take an innocent neighbour with it. Stop things by name rather than taking down a whole group, unless you have checked what else is in there.

6. Write down how to undo it, before you do it

# rollback.md, kept beside whatever you changed
# 2026-08-14 set the database to listen only to its own machine
#   undo: set listen_addresses='*' in postgresql.conf, restart it
# 2026-08-14 stopped the paused project
#   undo: docker compose start   (the data was never removed)

Related reading: measure before you delete is this same rule aimed at disk space, and give every job its own key is the same instinct aimed at passwords.