Security

What this page is for. Everything about who can get into this panel, and a record of what they did.

You need

• The panel open, on the Security page (in the Panel menu group).
• For a new phone: a free authenticator app (Google Authenticator, Aegis, 1Password, Authy).
• For your own panel domain: a domain name, and access to its DNS settings — or a Cloudflare token connected to the panel, in which case it does the DNS for you.

Read this first: the panel is the server

The panel manages the web server, PHP, your files, your database and your certificates. To do that it runs as root on this machine. So whoever can log in to the panel can do anything on the server.

That means your panel login deserves exactly the same care as your SSH key:

• Do not reuse the password anywhere else.
• Do not paste the panel link into a chat group, a ticket, or a screenshot.
• Do not give your own login to a helper. There is a proper way to do that: Let someone else in.

The same works the other way round. Anyone with root SSH on this server can clear the two-factor phone, reset the password and put the panel back on its IP address, all in one command each. That is on purpose — it is your way back in when something locks you out — so guard the SSH access just as carefully.

Your project's own code does not run as root, and cannot reach any of this. Each project runs in its own PHP-FPM pool under its own Linux user (six-default, six-<short id>), which can read and write that project's folders and nothing else on the machine.

There is a second wall behind that one. PHP is started inside its own view of the server, where the whole disk is read-only except the folders your shops actually write to — their own files, the server's log folder and the sockets the database and PHP talk over. Everything else is read-only, and some things are not there at all: PHP cannot see this server's web-server configuration, the settings SixPanel writes for your sites, SixPanel's own program files, or any other program running on the machine. Its temporary folder is its own, so one shop cannot see files another one left in the shared one.

None of that changes anything you do. It is there for the day something gets into one of your shops through a plugin or a theme upload: it does not stop that shop being affected, but it stops whoever did it from reading their way around the rest of the server. It also costs nothing — it was measured against the usual way of doing this (a PHP setting called open_basedir, which is what some other panels use) and that one made every page 17 to 23 milliseconds slower, on every request, forever. This does not.

What is on the page

1. Your username

Your login name was generated when SixPanel was installed — admin plus a few random characters — so that a robot which finds the login page cannot guess it.

To change it, open Your login name, type the new name and press Change username. It must be 3 to 32 characters: small letters, numbers, dot, dash or underscore.

Write the new name down before you press the button. The old name stops working immediately. If you forget the new one, the only way to read it back is over SSH: sudo sixpanel username.

The panel asks for your password (and your 6-digit code) again before it makes the change.

A name already used by a temporary login or by the demo login is refused. Every login on this panel has its own name.

2. Your password

Type the current one, then the new one twice, and save. Minimum 8 characters.

Changing it signs out every other browser. Your username and your 6-digit code stay as they are.

Over SSH, if you cannot log in at all:

sudo sixpanel password reset

It confirms first, then prints a new password. The old one is stored only as a one-way hash and cannot be recovered.

3. Two-factor login

Two-factor login is how this panel is meant to run, and it is set up at your first login (First login). With it on, a stolen password is not a login — it is half of one.

It is not welded on. The enrolment screen offers Not now — continue without two-factor login (it asks you to confirm once), and the Security page shows two-factor as off afterwards with the button to enrol right there. Skipping is recorded in your activity log, and while it is off your panel password is the only thing protecting this server. Leave it on for a project taking real orders.

Moving to a new phone. Open Two-factor login and press the button to move to a new phone. The old authenticator is forgotten and the panel asks you to scan a fresh code straight away. Do this while you still have the old phone if you can — it is one uninterrupted minute.

Lost the phone. Over SSH:

sudo sixpanel 2fa off

It forgets the old phone, and your next login shows a fresh QR code to scan with the new one. If you have no phone at that moment, that screen's Not now — continue without two-factor login is the way in — then enrol again here as soon as you have one.

4. Signed-in devices

Logged-in devices lists every browser that is logged in right now, with the time it signed in, when it was last seen, its IP address and its device.

• Press Sign out on any row you do not recognise.
• Press Log out everywhere else to end every session except this one.

A session lasts 7 days, and ends by itself after 24 hours with no activity. A demo session ends after 2 hours.

5. The secret panel link

Your panel link ends in a secret code. Without that code the address is a blank "not found" page — that is what keeps scanners away from your login.

If the link was ever pasted somewhere it should not have been:

1. Panel address → Change entry code.
2. Confirm. The panel shows the new link at once.

Save this. The new link is shown in a box you will not see again. Copy it and update your bookmark. The old link is dead from that moment, on every device including the one you are using.

Over SSH, the same:

sudo sixpanel entry-code reset

6. Give the panel your own domain

By default the panel answers at https://SERVER-IP:PORT/SECRET-CODE. You can put it on a name like panel.example.com instead. If you did this in the first-run wizard, it is already done.

1. Type the name in Custom domain.
2. Press Make the panel live on this address. One job does all of it: the DNS record (when Cloudflare is connected and manages that domain), the wait for the name to point here, the free certificate, and the web server configuration. You watch each step.

If Cloudflare is not connected, point an A record for that name at this server first — the page shows the exact value — then press the same button.

Check the spelling twice. The panel accepts any name that looks like a hostname. A name typed wrong is saved happily and only fails later, at the certificate step. A wrong name plus a certificate is how people lock themselves out. If you would rather have the name checked before it is saved, do this step over SSH instead: sudo sixpanel domain panel.example.com refuses a name that does not resolve to this server.

Once that domain has a certificate, the plain address with the IP and the port stops working. The domain becomes the only door. Your way back is always SSH:

sudo sixpanel domain none
sudo sixpanel info

The first command drops the panel domain and brings the IP address back. The second prints the address to open.

To remove the custom domain instead, empty the Custom domain box and save.

Every name the panel creates on Cloudflare is proxied, including this one, so your server's address never appears in public DNS. If panel.example.com would sit deeper than one level below your Cloudflare domain, the panel offers you the spelling that works — panel-shop.example.com rather than panel.shop.example.com — because Cloudflare's free certificate does not reach that far.

7. The panel port

The number after the address, like :41397, was picked at random when SixPanel was installed. Only the command line can change it, because the panel has to restart to listen somewhere else:

sudo sixpanel port 30000

Open the new port at your hosting provider first, or the panel becomes unreachable. sudo sixpanel port random picks a new random port; it does not restore an old one.

8. Limit login to your own addresses (optional)

Login IP allowlist names the addresses that are allowed to log in. Anything else is refused at the login page. It never affects your site or your visitors.

Only switch this on if your own address is stable. Most home and mobile connections are given a new address every few days. The day yours changes, the login page refuses you, and no button inside the panel can help — the list is what stops you reaching those buttons. The way back is one command over SSH: sudo sixpanel allowlist clear. Save that line somewhere you can read without the panel, before you add the first address.

1. Type an address or a range, for example 203.0.113.5 or 203.0.113.0/24.
2. Press Allow this address.

An empty list means the feature is off and login works from anywhere.

The panel will not save a list that leaves out the address you are on right now, so you cannot lock yourself out in the same minute. The lockout, when it comes, comes later and on its own.

Locked out? Over SSH as root:

sudo sixpanel allowlist
sudo sixpanel allowlist clear

The first prints the list the panel is enforcing. The second empties it, which switches the feature off, so login is accepted from anywhere again. Your password, your 6-digit code and the secret entry code are not touched.

9. Let someone else in

There are two ways to give somebody access without giving them your own login: a temporary login that ends by itself, and a public demo login that can look at everything and change nothing.

Full page: Let someone else in.

10. Read the activity log

The Activity log records logins, deploys, restores, password changes, secret reveals and setting changes, each with the time and the IP address. Filter it by action (for example, type login) and choose how many rows to show.

When something changed and you do not know why, this is the first place to look.

What is already on, with no setup

• The panel answers over https only.
• The panel port is a random high number, picked at install, and the address ends in a secret code.
• The username is generated, not admin.
• Two-factor login is set up at the owner's first login, and stays on unless the owner chooses to skip it there.
• The password is stored as a one-way hash. Nobody, including us, can read it back.
• 20 wrong passwords from one address within 15 minutes lock that address out for 30 minutes. 5 wrong 6-digit codes do the same. On top of that, 30 login attempts in 15 minutes trip a flood shield.
• Wrong secret entry codes lock an address out too, so the link cannot be guessed by trying.
• If you set up email alerts (Settings → Email alerts), a lockout sends you a mail.
• The web server refuses to serve hidden files and configuration files, and answers nothing at all to a request for a hostname this server does not serve — the connection is closed on port 80 and refused during the handshake on 443, so a scanner learns nothing.
• Push-to-deploy requests are checked against a signature, so a stranger cannot trigger a deploy.
• Ubuntu's own unattended security updates are switched on at install.

What protects the shop itself, with no setup

The list above is about reaching the panel. These are about the traffic that reaches your customers' shop, and none of them need anything from you.

Requests are rate-limited, by what they are. Signing in, asking for a one-time code and resetting a password get the tightest limit, because those are the requests somebody guessing passwords or burning your SMS credit has to make. Searching gets its own. Ordinary browsing gets a generous one, because a phone opening your app legitimately fires a dozen requests at once. Anything refused gets a 429, which an app can retry — never a broken page.

There is also a ceiling on the whole server, not just on one visitor. Four requests per PHP worker may be in front of the application at any moment. Past that, the next request is refused immediately instead of joining a queue that gets longer than anyone will wait for. That is the difference between a busy shop and a shop that stops answering: without it, a handful of addresses each staying politely inside their own limit is still several times what the hardware can serve, and everybody — including the customer who made one request — gets an error page.

Only one file on the server can run as a program. 6amMart, in both the version sold on CodeCanyon and ours, has exactly one entry point. Nothing else ending in .php will run, anywhere under your site, even if something manages to put a file there. That entry point cannot be requested directly either — it is reachable only from inside the web server.

Scanners are answered by the web server, not by your shop. A public server takes a constant background of probes for software it does not run — /wp-admin/, /phpmyadmin, /telescope, and a dozen more. Each of those used to start your whole application and run a database query to build a "not found" page. They are now refused before any of that happens.

Repeated failed SSH logins get the address banned for an hour, after five tries in ten minutes. Port 22 is open on every server — it is how you get back in when everything else is broken — and this is what stops someone working through a password list against it. Server → Health shows you how many addresses are banned right now.

The server's own network settings are sized for a burst. Ubuntu's defaults are a general-purpose compromise; the queues that hold connections while your server answers them are set for a shop, and SYN-flood protection is on. Health reads the live values back, so if something else on the server changes one, you are told.

Nothing here filters by who you are — no country blocks, no "prove you are a browser" challenge. Your customers arrive from phone apps, which cannot pass a browser challenge, so anything that asked them to would simply lose you orders. Filtering by address belongs at your provider's edge, where the packets never reach this server at all: Firewall walks you through it.

Would you know if something changed?

Three things are watched, and all three are on Server → Health.

SixPanel's own files. Every release carries a list of what it installed and what each file should contain. If one of them is different, or missing, the check-up says which.

Your shop's files. Your code comes from your git repository, so the panel can tell you when a file on the server no longer matches what you deployed — which is what a file dropped into your site by someone else looks like. Files your shop legitimately writes as it runs are not counted.

The settings files SixPanel writes. Web server configuration, PHP settings, the certificate jobs: about forty files. If you edit one by hand the panel tells you, rather than quietly writing over it the next time it renders that file.

Two things about your project, not the panel

The rest of this page is about who can reach the panel. These two are about the 6ammart app itself, and Server → Health checks both for you.

Your shop's encryption key

6amMart uses one secret value — its "app key" — to sign the cookie that keeps people signed in, and to scramble a few stored values. It has to be yours alone.

The 6amMart download ships with an example key already filled in, and for a long time a new install simply kept it. Anyone who has bought the same software has that key. SixPanel gives every new install its own, and Health shows a card for it.

If that card is red on a project installed earlier, change the key — but pick your moment, because a new key signs everyone out at once:

1. Choose a quiet hour. Nothing is deleted and no order, product or customer is affected — people simply sign in again.
2. Open the project's App .env page, clear the APP_KEY value, and save.
3. Run a deploy from Deploys. It generates a fresh key.
4. Sign in to your 6amMart admin again. Tell your staff to do the same.

"Remember me" on the 6amMart admin login

When someone ticks remember me on your shop's admin login (not the panel), 6amMart saves their e-mail and password in their browser, scrambled with the key above. Scrambled is not the same as hashed — with that key, it can be turned back into the real password.

Nothing to switch off, but two habits are worth having: keep the key above unique to your shop, and do not tick remember me on a shared or public computer. SixPreflight reports this too.

How to check it worked

• Your login shows two-factor as on.
• Panel address shows your domain with an active HTTPS chip.
• sudo sixpanel ssl status lists a certificate for the panel domain with the days left.
• The Activity log has a fresh row for what you changed.

If it went wrong

• The panel domain does not open — the certificate may not be there yet. Run sudo sixpanel ssl status. To go back to the IP address: sudo sixpanel domain none.
• The allowlist locked you out — no button in the panel can fix this, because the list is what keeps you out of the panel. Over SSH: sudo sixpanel allowlist clear. It confirms first, empties the list and leaves the password, the 6-digit code and the entry code alone. It works with the panel running and with the panel stopped.
• Too many wrong tries locked you out — the lockouts above are meant for a stranger guessing, and they cannot tell you apart from one. sudo sixpanel unlock lists what is locked and why; sudo sixpanel unlock all clears it and the login works on the next attempt. It also clears the flood shield, which is the half that appears in no file at all.
• You cannot log in at all — see When something is broken. A username, a password and a two-factor reset each take one command over SSH.

Ports to open, and nothing more: Firewall and ports.