The SecureByDefault Brief #013: My firewall blocked 4,326 packets in a day. Here's what I checked.

Gmail is free, but you pay with your data. Proton Mail is different.

We don’t scan your messages. We don’t sell your behavior. We don’t follow you across the internet.

Proton Mail gives you full-featured, private email without surveillance or creepy profiling. It’s email that respects your time, your attention, and your boundaries.

Email doesn’t have to cost your privacy.

Ditch the Gmail data grab

After #012 I went back to the logs, but not the SSH ones. I looked at the firewall's.

In the last 24 hours, UFW on my test server blocked 4,326 packets aimed at ports 80 and 443. Nothing on that server listens on either port.

That raised a better question than "who's knocking?" It was: what is this server actually listening on, and who can reach it?

Here's how I checked.

Each flag earns its place:

Here's my output, trimmed to the columns that matter:

Read the Local Address column first. It tells you who is allowed to connect:

So on my server, the DNS resolver is local-only, and SSH is listening everywhere. That matches what I did in #012. (On Ubuntu, systemd also shows up on the SSH lines because it holds the listening socket.)

To see the difference for yourself, run a tiny web server two ways. Python is already on Ubuntu, so there's nothing to install. Use an empty folder so it can't serve real files:

First, bind it to localhost only:

In a second terminal on the server:

Mine showed 127.0.0.1:8080, owned by python3. And from the server itself:

That returned 200 OK.

Now from my Windows PC, against my own server:

TcpTestSucceeded : False. The server answers itself and nobody else. That's the point of 127.0.0.1.

Stop that server with Ctrl+C and start another, this time on every interface:

Now ss showed 0.0.0.0:8081. (Only IPv4, since I asked for 0.0.0.0 and not ::.)

Here's the catch. The server was now listening on every interface, but when I tried it from my PC, it timed out:

UFW's default is to deny incoming connections, and I'd only allowed SSH. A service can be listening on 0.0.0.0 and still be unreachable because the firewall drops the traffic first.

So I opened that one port on purpose:

UFW added a rule for IPv4 and one for IPv6, and the status listed both.

I expected the next test to succeed. It didn't. curl.exe from my PC still timed out.

What I could confirm:

So the listener was fine, the host firewall was fine, and my PC could reach the server on SSH. Something else was in the path.

It was a second firewall. My server had a cloud firewall attached in the provider's dashboard, sitting in front of the server and separate from UFW. After I removed it, the same test succeeded, and curl got an answer:

That is the "make sure they agree" point from #012, caught on my own server. The port was open in UFW and still unreachable, because a second firewall said no. Two layers, two rule sets. I removed the cloud firewall entirely just to test, which I wouldn't do on a server that matters. The better move is to add the one port to it for the test, then take that rule back out. I put my cloud firewall back after the lab.

When I was done, I removed the rule and stopped the server:

Then I stopped the demo with Ctrl+C, removed the folder, and ran ss -tulnp and ufw status verbose again to confirm I was back where I started.

Back to those 4,326 packets. UFW writes what it blocks to the kernel log, so I counted them:

Then I used the same counting trick from #011:

Nothing was listening on either port. UFW dropped every one before it mattered.

Then I checked where they came from:

The top five sources sent 744, 300, 249, 237, and 20 packets. The first four add up to about a third of the total. In all, the 4,326 packets came from 1,835 different source addresses.

A few honest caveats:

What I will say is that the only door I left open on this server is SSH, and #012 was about making that one hard to use.

Use a disposable Ubuntu server, not one anyone depends on. The whole lab took me about 40 minutes, including opening and closing the port. Give yourself an hour the first time.

Save the before and after output, the commands, and what surprised you. Mine surprised me at step 6, and I'd rather you saw that than a tidy ending.

Only do this on your own server, and keep the demo port open for minutes, not days. A demo web server is a throwaway tool, not something to leave running on the internet.

ufw man page, logging section
https://manpages.ubuntu.com/manpages/noble/en/man8/ufw.8.html

It explains the logging levels and says low is rate-limited, which is why my block counts are a floor.

ss man page
https://man7.org/linux/man-pages/man8/ss.8.html

The full list of flags and filters.

Why spend your evenings on ss, firewalls, and Linux basics? Because employers keep asking for these skills. Here are four current remote roles, from true entry level to early career.

Listings can close quickly. I checked each one on the employer's own page while preparing this issue, but always check the employer's page before applying.

Remote | Salary starting at $45,000 | 1+ year in customer service or technical support

A Linux-heavy support role at a managed hosting company. You'd help customers by phone, ticket, and chat with Linux and AWS server problems. They list Ubuntu or CentOS, DNS, networking and IP routing, MySQL, cPanel, and hands-on AWS (EC2, CloudWatch, Auto Scaling). Know before you apply: this is a 24/7 support environment, and they ask for availability for weekends and overnight shifts.

View the role

Remote U.S., Eastern Time hours | 0-2 years | $27.30-$45.90 per hour depending on location, plus equity eligibility

A genuine entry-level IT role. The work is desktop and end-user support: setting up and retiring laptops, basic troubleshooting for network connectivity, printing, and account access, and documenting what you did in the ticketing system. They ask for a high school diploma or equivalent and 0-2 years of related experience.

View the role

Remote, U.S. Eastern Time Zone (hybrid for NYC) | $70K-$90K + equity | 1-3 years

Hands-on troubleshooting across TCP/IP, DNS, DHCP, routing, firewalls, servers, and edge devices. Linux and Python are nice-to-haves. Know before you apply: this is an evenings and weekends support position, and you must live in the Eastern Time Zone.

View the role

Remote U.S. | $72K-$90K base + equity + bonus eligibility | 2+ years

Support for a cloud file-streaming product across macOS, Windows, and Linux. The work includes reproducing customer issues, running live debug sessions, and collecting logs and debug data. TCP/IP knowledge is required, with cloud, networking, and scripting as pluses. Daytime U.S. hours.

View the role

What these have in common

Look at the four together and the same things keep coming up: Linux, networking basics, troubleshooting, reading logs, documenting your work, and explaining it clearly to someone else. Knowing what your server is listening on, and who can reach it, is exactly the kind of thing those basics cover.

None of that guarantees a job. Nothing does. But these skills keep showing up because employers keep needing them, and every one of them is something you can practice on a cheap server or a free VM this weekend.

I'm also building SecureByDefault Learning Paths, a free GitHub repo that organizes Linux, networking, troubleshooting, cloud, hands-on projects, and career paths into a learning order. It's a work in progress and I add to it regularly.

https://github.com/SecureByDefault-io/securebydefault-learning-paths

New to Linux?

The free Linux Starter Kit includes the commands, a practice plan, log examples, and a beginner server checklist.

If someone forwarded you this issue, you can subscribe here: https://newsletter.securebydefault.io/

My server greets me every time I log in with the same two messages: a restart is required, and some security updates are waiting. Next time: what to do about updates on a Linux server, what "restart required" actually means, and how to see what's pending before you touch anything.

Talk soon,

Ron
SecureByDefault