Security

Welcome to this guide to the Security menu. This module gathers everything that protects your controller: the password that guards access to it, the firewall that filters what can reach it, and the audit log that keeps a record of what happens on it. Version 1.3.8 brings important new features here, presented one by one below.

Prerequisites

The HAI-P200-4G controller
An administrator account (the admin user)

1. The administrator password

At first setup

The controller first shows you its login page and expects the factory credentials: user admin, password hai1@. Once those are entered, it opens a configuration screen asking you to choose your own administrator password. Until that is done, no other page and no setting is reachable.

The factory password therefore only serves to get through that step: it will never be the one you administer the controller with. The same applies after a full reset, which restores those factory credentials.

The password requested has to obey two rules:

At least 12 characters.
At least three character families among: lower case, upper case, digits, special characters.

Words that are too obvious (related to the product, or classics such as admin and azerty) are refused. The rules are shown on screen and are ticked off as you type.

Changing it later

The password can be changed at any time:

Go to the Security > Password Manager menu.
Fill in your Current Password.
Type the new one in New Password, then again in Confirm New Password.
Click Change Password.

The same strength rules apply as at first setup.

What happens after repeated mistakes?

After five consecutive failures, the controller slows the following attempts down: 5 seconds’ wait, then 10, then 20, and so on up to a maximum of 5 minutes. The counter clears after a quarter of an hour with no new attempt, and a correct entry resets it.

2. Add-on passwords

Some add-ons have their own account, independent of the controller’s: Grafana, Ignition, PostgreSQL and pgAdmin. Node-RED does not. Installing and managing those applications has a page of its own, Add-ons.

Up to the previous version, those passwords were identical on every controller and printed in our manuals. They are now generated when your device first boots, and belong to it alone. Since they can no longer appear in documentation, the controller shows them to you directly.

Where do you find them?

Go to the Add-ons menu.
On the relevant add-on’s card, open the ⋮ menu (the three dots).
Click Credentials.

A window then shows two fields:

User: the user name, in plain text.
Password: the password, masked by default. The eye icon reveals it, and the Copy button puts it in your clipboard without you having to display it.

3. The firewall

The Security > Firewall page shows you what is allowed to reach your controller, and lets you adjust it. As delivered, the web interface only answers on your local networks and on the VPN — never on the 4G link — and SSH access is closed.

Adding a rule

In the Add a Firewall Rule card, fill in the following fields:

IP Address: the address concerned. Type nothing for “from anywhere”.
Port: the port targeted (502 for Modbus/TCP, for example).
Protocol: tcp or udp.
Action: Allow to permit, Block to block.
Direction: IN for what comes into the controller, OUT for what leaves it.
Networks: the networks the rule applies to.

Then click Add Rule.

The Networks field: local or 4G?

This field offers two values:

Local networks only (recommended) — the default value. The rule only applies to your local networks and to the VPN. This is what you want in order to open a port for a technician who is on site.
Every network, including the 4G link — the rule also applies to the mobile link. An orange banner then appears to warn you.

Reading your rules back

The rules table repeats that scope for every row, in a Networks column: Local only or ⚠ Including 4G. A single glance therefore tells you what is exposed beyond your workshop.

The rules the controller maintains

The expandable System rules — maintained by the gateway section shows the rules the controller installs and updates by itself. They cannot be modified: deleting the loopback or the tracking of replies would cut the controller off from itself.

They are shown to you nonetheless, with a plain-language translation alongside. A page that presents itself as the view of your firewall has to show you everything, including what it does not let you change.

Monitoring SSH access

The SSH access monitoring card lists the most recent SSH connections opened on the controller, with their source address and the network used: local network, VPN or Internet. It is on this page because this is where port 22 is opened, or not.

The RESET ALL RULES button

At the top of the page, this button restores the base rule set after a simple confirmation.

IPv6 is disabled at kernel level: nothing goes through any more, neither inbound nor in transit.
IPv4 returns to a DROP policy: anything not explicitly allowed is rejected.
Ports 80 and 443 stay reachable from your local networks and through Tailscale, never from the 4G link.
Ports 53 and 67 stay open on the local interfaces, eth1 and the WiFi access point.
Ping, traffic arriving over Tailscale and the replies to connections the box opened itself keep going through.

Those openings are not a leftover: they are the ones without which the reset would cut you off from the box.

443 and 80 — the web administration interface. Closing them would amount to locking the door of the very page you have just clicked from. Port 80 also serves the captive portal: a device joining a WiFi network queries an address over plain HTTP to find out whether it should show a login page. Over HTTPS alone, it would see nothing.
67 and 53 — address distribution and name resolution for the devices the box hosts on its local networks. Closed, no phone could join the WiFi access point any more: neither receive an address, nor be redirected to the portal.

These rules do not depend on the state of connection sharing: they are laid down at every reset, unconditionally.

None of those openings exposes your equipment: they serve the box and the devices it hosts on its own networks. Your PLCs stay behind the DROP policy as long as you do not explicitly open a port for them.

The configured connection sharing is reapplied right afterwards: the WiFi access point immediately, the wired sharing some twenty seconds later.

4. Audit & Logs

The Security > Audit & Logs page gathers everything your controller keeps about itself: accesses, configuration changes and administration actions.

What is recorded?

Every event carries a date, an action and a category. The Recent activity list can be filtered by category using the Show menu:

Category	What you will find there
Authentication	Logins to the interface, successful and failed, and the slowdown triggered by a run of failures.
Network and firewall	Firewall rules added or deleted, network changes, VPN port forwarding.
Administration	Add-on installations and removals, updates, setting changes.
System	Service start-ups and events specific to the device.

Physical access

A separate card lists what happens in front of the machine: a screen and a keyboard plugged into the controller, a session opened on a text console or on the serial port, and the opening of the reset screen.

Network access (SSH)

The next card does the same for sessions opened from another machine, keeping their origin. Repeated failures are recorded once per run rather than one line per attempt: an automated scan therefore cannot drown your real sessions in noise.

Downloading the archive

The Download audit logs button produces a .tar.gz file containing the application’s audit trail, the system audit daemon’s log, the list of SSH sessions, an extract of the system log, and a manifest with the SHA-256 fingerprint of every file.

That fingerprint lets you demonstrate that the archive has not been altered after the fact. This is the format to hand to an auditor, or to keep before an intervention.

How long are the logs kept?

The audit trail is written to the controller’s internal memory, so it survives a power cut. It is capped at 10 MB in total, which is several months of ordinary use; beyond that, the oldest records are dropped, so that a log can never fill the storage and block the controller.

The system log, for its part, stays in RAM and disappears at every restart — which is precisely why the audit trail is written separately.

Turning recording off

A single switch, Record security activity on this gateway, governs the whole thing: the audit trail, the system daemon and SSH monitoring.

5. Starting again from a clean base

Two pages in the System menu complete this set-up. They have a detailed guide of their own; here is the essence of it.

Factory Reset

Two levels of erasure are offered: everything the controller holds, or only the application settings — in which case the networks, the VPN, the password and the recorded measurements are kept. After a full wipe, the controller asks you for an administrator password again at first access, and returns to the as-delivered firewall, SSH closed.

Configuration (export / import)

This page exports your controller’s settings into an encrypted file, which you can import onto another one — to replace a box, or to restore it after a reset. What is specific to a device does not travel: the network configuration, the VPN identity, the password and the measurements stay on their original controller.

6. Secure boot

Secure boot seals the device: the processor checks the software’s signature before launching it, and refuses to boot a system that is not ours. A sealed controller therefore cannot be reprogrammed by someone with physical access to the board.

This protection is coming on our next devices. Controllers already in service do not have it: it is a property burned in at manufacturing time, and it cannot be added by an update.

How do I know whether my controller has it?

Open the Home page. The information is shown along with the HAI-OS version and the kernel, in one of these three forms:

✅Secure boot: sealed device Your device is sealed. Only software signed by Hexa-AI can boot on it.

⚠️Secure boot: not enabled on this device Your device is not sealed: this is the case for the current generation.

No line shown The controller could not read the information. It then prefers to show nothing rather than wrongly announce an absence of sealing.

The value is read once at boot, from permanently burned fuses: it can neither change while the machine is running, nor be modified by software.

7. The other protections

These protections require nothing of you. They are mentioned here so that you know what has changed:

The web interface is now only reachable from your local networks and the VPN. It used to answer on every interface, including 4G, which put it on the Internet with a SIM card holding a public address.
Each controller now signs its sessions with its own key. That key was identical on every device manufactured since April 2025.
Updates are verified before installation. The web interface no longer installs anything itself: it files the request, and an isolated service checks the Hexa-AI signature. Downloads go exclusively over HTTPS.
Node-RED no longer runs as administrator, which prevents a flow from taking over the controller. Two consequences: a flow acting as a server on a port below 1024 has to move above it (a Modbus/TCP server on 502 moves to 1502; querying a device on port 502 is unaffected), and exec nodes no longer run as administrator.
Services restart indefinitely instead of giving up after a few attempts, and a hardware watchdog restarts the controller if the system freezes.