Nobody breaks into a weather station to steal temperature readings. That is what most operators think, and it is exactly why station infrastructure ends up as the softest target on the network. The Ecowitt gateway with the default password. The FTP credentials in a plaintext config file. The Grafana dashboard open to the internet with anonymous access enabled because "it's just weather data." I have seen all of these in the wild — and I have been guilty of a few myself during the early years.

The problem is not that someone wants your rainfall data. The problem is that an unsecured station gateway is a foothold on your network. A compromised Davis WeatherLink Live or Ecowitt GW2000 shares the same LAN as your NAS, your cameras, and your workstation. And an FTP server with weak credentials is an open door for malware distribution, spam hosting, or pivot attacks.

This guide covers practical, proportionate security for weather station operators. Not corporate-grade paranoia — just the measures that close the obvious holes without turning your hobby into an IT governance exercise. If you run FTP uploads, the FTP publishing guide covers the protocol mechanics; this article is about making those connections safe. For validating the data itself before it leaves your network, the station data sanity checks guide is the companion piece.

Quick-Answer Summary

Threat Mitigation Effort
Default gateway passwords Change immediately on every device 5 minutes
Plaintext FTP credentials in transit Switch to SFTP with key-based authentication 30 minutes
Exposed station admin panels Bind to LAN IP, use reverse proxy with auth 1 hour
API keys in source control or configs Environment variables, secrets manager 15 minutes
IoT devices on flat network VLAN or firewall segmentation 1–2 hours
Stale firmware with known CVEs Update firmware on a quarterly schedule 15 minutes per device
Unencrypted data at rest Encrypt database volumes or use encrypted filesystems 30 minutes

If you only do one thing from this list, change the default passwords. If you do two, switch FTP to SFTP. Those two actions eliminate the vast majority of real-world risk.

Prerequisites

  • A working station publishing pipeline — either FTP-based, MQTT-based (as covered in the MQTT and Home Assistant integration guide), or both.
  • SSH access to your web server if you plan to set up SFTP with key-based auth.
  • Basic familiarity with your router's admin interface for VLAN and firewall configuration.
  • 30–60 minutes of uninterrupted time. Security changes are the wrong thing to rush.

Default Passwords: The Five-Minute Fix

Every consumer weather gateway ships with a default admin password. Ecowitt devices use admin / (blank) or admin / admin. Davis WeatherLink Live's configuration interface has no authentication at all by default — anyone on the LAN can change station settings. Other brands follow similar patterns.

Change these immediately. Use a unique password for each device, store them in a password manager, and document the device IP addresses alongside the credentials. If a device does not support password changes (some older models), isolate it on a dedicated network segment so that its admin interface is unreachable from your main LAN.

This is not theoretical. Shodan queries for "Ecowitt" and "WeatherLink" return thousands of devices exposed to the internet. Many are inadvertently port-forwarded by UPnP or opened during troubleshooting sessions and never locked down again.

Switching from FTP to SFTP

Plain FTP transmits your username, password, and every byte of data in cleartext. Anyone sniffing the network — whether on your LAN, at your ISP, or on the hosting provider's side — can capture those credentials. SFTP (SSH File Transfer Protocol) encrypts the entire session, including authentication.

Step 1 — Confirm Your Host Supports SFTP

Most modern web hosts enable SFTP by default alongside or instead of FTP. Check your hosting control panel under SSH/SFTP settings. If only FTP is available, request SFTP access or consider switching hosts — it is that important.

Step 2 — Generate an SSH Key Pair

On your station PC (Windows):

ssh-keygen -t ed25519 -C "weather-station" -f "$HOME\.ssh\weather_station_key"

This creates two files: weather_station_key (private) and weather_station_key.pub (public). The private key never leaves your station PC. The public key goes to the server.

On Linux:

ssh-keygen -t ed25519 -C "weather-station" -f ~/.ssh/weather_station_key

Ed25519 is preferred over RSA for its smaller key size and resistance to certain side-channel attacks. If your server requires RSA, use at least 4096 bits.

Step 3 — Install the Public Key on the Server

Copy the contents of weather_station_key.pub to ~/.ssh/authorized_keys on the server:

ssh-copy-id -i ~/.ssh/weather_station_key.pub [email protected]

Or paste it manually into the hosting control panel's SSH key management interface. Test the connection:

sftp -i ~/.ssh/weather_station_key [email protected]

If you get a prompt without a password challenge, key-based auth is working.

Step 4 — Update Your Station Software

In GraphWeather, open the FTP publishing settings and switch the protocol from FTP to SFTP. Point it at port 22, specify the private key path, and remove the stored password. The switching from WeatherLink to GraphWeather guide covers where to find these settings in the UI.

In WeeWX, update weewx.conf:

[StdReport]
    [[FTP]]
        skin = Ftp
        server = yourserver.com
        port = 22
        user = your_user
        secure_ftp = True
        private_key = /home/pi/.ssh/weather_station_key

Step 5 — Disable Plain FTP on the Server

Once SFTP is working, disable FTP entirely on your host. In cPanel, this is under FTP Server Configuration → TLS/SSL settings — set "Allow unencrypted FTP" to "No". On a self-managed server, stop the FTP daemon (vsftpd, ProFTPD, or Pure-FTPd) and ensure only the SSH daemon is running.

Securing Station Dashboards

If you run Grafana, Home Assistant, or a custom web dashboard for your station, access control is essential.

Grafana

  • Disable anonymous access unless you explicitly want a public-facing dashboard. In grafana.ini, set [auth.anonymous] enabled = false.
  • If you do want public dashboards, use Grafana's public dashboard feature (introduced in Grafana 10) rather than enabling anonymous auth globally. This exposes a single read-only snapshot without granting access to the admin interface.
  • Place Grafana behind a reverse proxy (Nginx, Caddy) with HTTPS and HTTP basic auth or OAuth for admin access.

Home Assistant

  • Never expose Home Assistant directly to the internet without the Nabu Casa cloud service or a properly configured reverse proxy with TLS.
  • Enable multi-factor authentication for all admin accounts.
  • If you embedded MQTT weather data per the MQTT integration guide, ensure the MQTT broker requires authentication — set password_file in the Mosquitto config.

Custom PHP/HTML Dashboards

If your station publishes static HTML pages via FTP (a common GraphWeather workflow), the pages themselves are public by design. But any admin endpoints — phpMyAdmin, file managers, control panels — should be behind authentication and restricted by IP if possible.

API Key Management

Station software often stores API keys for Weather Underground, PWSweather, CWOP, and other services in plaintext configuration files. If those files end up in a Git repository or a backup archive, the keys are exposed.

Best practices:

  1. Use environment variables for API keys rather than hardcoding them in config files. Most station software reads from config files, so create a wrapper script that sets environment variables and then launches the application.

  2. Rotate keys periodically. Weather Underground and PWSweather allow key regeneration. Do it at least once a year, or immediately if you suspect a config file was exposed.

  3. Never commit API keys to version control. Add config files containing keys to .gitignore. If you accidentally committed a key, rotate it — deleting the commit from history is not sufficient because forks and caches may retain it.

  4. Use separate keys for separate services. Do not reuse a Weather Underground key for PWSweather even if the format is compatible. Compromise of one service should not cascade.

Network Segmentation for IoT Devices

Your weather station gateway, soil moisture sensors, lightning detectors, and any SDR receivers are IoT devices. They run firmware that is updated rarely, often has known vulnerabilities, and cannot run endpoint protection software. They do not belong on the same network segment as your workstation and NAS.

VLAN Approach

Most consumer routers with aftermarket firmware (OpenWrt, DD-WRT) and prosumer models (UniFi, MikroTik, pfSense) support VLANs. Create a dedicated IoT VLAN:

  1. VLAN 10 — Main LAN: Workstations, phones, NAS.
  2. VLAN 20 — IoT: Weather gateway, sensors, smart home devices.
  3. VLAN 30 — Servers: Home Assistant, Grafana, InfluxDB, MQTT broker.

Firewall rules:

  • IoT VLAN → Servers VLAN: Allow MQTT (1883/8883), deny everything else.
  • IoT VLAN → Main LAN: Deny all.
  • IoT VLAN → Internet: Allow NTP (123), allow HTTPS (443) for firmware updates, deny everything else.
  • Main LAN → Servers VLAN: Allow all (admin access).

This means even if an attacker compromises your Ecowitt gateway, they cannot reach your workstation or NAS. They can only talk to the MQTT broker on the designated port.

Simpler Alternative: Firewall Rules Without VLANs

If your router does not support VLANs, you can achieve partial segmentation by assigning static IPs to IoT devices and creating firewall rules that restrict their communication to specific destination IPs and ports. It is less robust than VLANs (traffic still shares the same broadcast domain) but substantially better than a flat network.

Firmware Updates

Weather station firmware updates are the chore everyone skips. Manufacturers release updates that fix security vulnerabilities, improve connectivity, and occasionally add features. Check for updates quarterly:

  • Ecowitt: The WS View Plus app checks for gateway firmware updates automatically. You can also check the Ecowitt website for console firmware.
  • Davis: WeatherLink firmware updates are delivered through the WeatherLink software or via USB.
  • Fine Offset clones: Firmware updates are rare but occasionally available from the OEM. Check your reseller's support page.

Before updating, export your current configuration and note the firmware version. Firmware updates on embedded devices occasionally fail, and having a rollback reference saves hours of reconfiguration.

Encrypting Data at Rest

If you log weather data to a local database (InfluxDB, SQLite, MariaDB), the data files on disk are plaintext by default. For most home operators, this is acceptable — physical access to the server is the threat model, and if someone has physical access you have larger problems.

However, if you run the database on a cloud VPS or a NAS that might be accessed by other household members, enabling volume encryption is a reasonable precaution:

  • InfluxDB on Docker: Use an encrypted Docker volume or run on an encrypted filesystem (LUKS on Linux, BitLocker on Windows).
  • SQLite (Home Assistant recorder): Home Assistant's data directory can sit on an encrypted partition.
  • MariaDB/MySQL: Enable Transparent Data Encryption (TDE) in the server configuration.

The performance overhead of filesystem-level encryption on modern hardware is negligible — typically under 3% for weather-scale write volumes.

Common Mistakes

  1. Leaving default passwords on gateways. I listed this first because it is the single most common vulnerability in every home weather setup I have audited. Five minutes to fix. No excuses.

  2. Exposing station admin panels to the internet. Port forwarding your Ecowitt gateway's web interface "so you can check it from work" is an invitation for drive-by exploitation. Use a VPN to reach your home network instead.

  3. Not updating firmware. The Ecowitt GW1100 had a vulnerability in 2024 that allowed unauthenticated configuration changes over the LAN. A firmware update fixed it. If you never updated, the vulnerability is still there.

  4. Storing credentials in plaintext configs that get backed up to cloud storage. Your weewx.conf with the FTP password ends up in a Dropbox sync, a Time Machine backup, or a Git repo. Treat config files containing credentials as sensitive.

  5. Using the same password for FTP and the station gateway and your email. Credential reuse is the force multiplier for attackers. A password manager eliminates this risk entirely.

  6. Disabling security features during troubleshooting and forgetting to re-enable them. "I'll turn the firewall rule back on after I fix this" is the prelude to months of running wide open. Use a calendar reminder.

Related Reading

FAQ

Is SFTP the same as FTPS? No. SFTP runs over SSH (port 22) and is a completely different protocol from FTP. FTPS is FTP with TLS encryption layered on top (port 990 for implicit, or 21 with STARTTLS for explicit). Both encrypt data in transit, but SFTP is simpler to configure — no passive-mode port range issues, no separate data channel. Prefer SFTP unless your host only supports FTPS.

My station software only supports plain FTP. What can I do? Run a local SFTP proxy. Tools like sshfs (mount the remote server as a local directory) or a scheduled rsync over SSH can replace the FTP upload. Your station writes files locally; the proxy or cron job pushes them securely. It adds a moving part, but it eliminates plaintext credentials on the wire.

Do I really need VLANs for a home weather station? Need? No. But the effort-to-security ratio is excellent if your router supports them. A one-time 90-minute setup gives you defence in depth that requires zero ongoing maintenance. If VLANs are not an option, firewall rules on static IPs are the next best thing.

How do I know if my station gateway has been compromised? Look for unexpected configuration changes (upload targets you did not set, changed Wi-Fi credentials), unusual network traffic (connections to unfamiliar IPs), or firmware downgrades. A network monitoring tool like Pi-hole's query log or a dedicated IDS (Suricata on pfSense) makes anomalies visible.

Should I encrypt MQTT traffic on my home LAN? If MQTT stays within a trusted LAN segment (especially a dedicated IoT VLAN), unencrypted MQTT on port 1883 is pragmatically fine. If MQTT crosses the internet — for example, publishing to a cloud broker — encrypt with TLS on port 8883. The overhead is minimal and the risk of credential interception over the internet is real.