Before you enable protection
LetSecure can drop traffic before it reaches your server apps. That is the point, but it also means a wrong setting can block real users or your own access.
Use this checklist before enabling protections on a production server.
Keep a recovery path
Section titled “Keep a recovery path”Make sure you have at least one way back in:
- Provider web console.
- Rescue console.
- A second SSH session already open.
- Someone with server console access.
If a rule blocks you, stop LetXDP from the server console:
sudo systemctl stop letxdpConfirm your interface
Section titled “Confirm your interface”The interface is the network device LetSecure protects. You can list interfaces with:
ip linkCommon names are:
| Interface | Usually means |
|---|---|
eth0 | Common VPS network card name. |
ens3 | Common cloud server network card name. |
enp1s0 | Common physical or virtual NIC name. |
Save the correct value in Settings > Network interface name.
Enable one change at a time
Section titled “Enable one change at a time”Do not enable five protections at once on a live server. Turn on one protection, test the service, then continue.
Match the profile to the server
Section titled “Match the profile to the server”| Server type | Good first profile |
|---|---|
| Website using Cloudflare proxy | Only Cloudflare proxy |
| SSH exposed to internet | SSH Anti-brute-force |
| Minecraft server | Minecraft |
| Public VPS with no private LAN clients | Anti-spoofing |