Your gateway is blocking an SSH scan every five minutes. The source is inside your network. It is your monitoring box, and it is doing exactly what you told it to.
This assumes you run IDS or IPS on your gateway. UniFi, pfSense and OPNsense all use the same Suricata rules, so the signature names here will match.
It assumes you have more than one VLAN.
It assumes your monitoring server checks hosts over SSH.
Your threat log fills up with one signature:
"signature":"ET SCAN Potential SSH Scan OUTBOUND"
"signature_id":2003068
"action":"blocked"
"src_ip":"192.168.1.45"
"dest_ip":"192.168.10.5"
"dest_port":22The source is your monitoring server. The destination is a box on another VLAN.
Count them by signature with command
grep -o '"signature":"[^"]*"' threat.log | sort | uniq -c | sort -rn
Here is what mine said:
615 "signature":"ET SCAN Potential SSH Scan OUTBOUND"
30 "signature":"ET DROP Dshield Block Listed Source group 1"
3 "signature":"ET CINS Active Threat Intelligence Poor Reputation IP"615 of 663. That is 93 percent of my threat log.
All of it was me.
I retired a container. I stopped it. I set onboot to 0.
I never removed it from monitoring.
So every check cycle, the monitoring server opened an SSH connection to a host that was not there. The connection failed. It tried again a few minutes later. Forever.
Repeated failed SSH connections to a dead host is the exact shape of a port scan. Suricata is not wrong. That is what a scanner looks like.
The VLAN boundary is what makes it visible. Traffic inside one VLAN never reaches your gateway, so the IPS never sees it. Cross a boundary and every packet is inspected.
Same-VLAN monitoring does this too. You just never find out.
Real inbound attacks were still landing the whole time. Reputation list hits against my reverse proxy, my NAS and my mail relay. All blocked, all genuine, all buried under my own traffic at thirteen to one.
This is the log you open after you suspect a breach.
An alert stream that is 93 percent self inflicted is not a log. It is a wall you scroll past.
Count alerts by source and destination pair:
grep -oE '"src_ip":"[^"]*"|"dest_ip":"[^"]*"' threat.log \
| paste - - | sort | uniq -c | sort -rn | headAny RFC1918 address in the source column is your own gear.
On UniFi the log is at /var/log/ulog/threat.log on the gateway. SSH in as root to read it.
The alert list in the UniFi UI will not help you here. It shows a client MAC and almost nothing else. No port, no protocol, no signature. Read the Suricata log directly.
Delete the monitoring object for the host you retired.
Do not suppress the signature.
The signature is correct. Something on your network really is repeatedly probing SSH on a dead host. Suppressing it means the next time that happens for a bad reason, you will not hear about it.
Order matters if your monitoring is fed from an inventory system:
Mark the host offline in your source of truth first. NetBox, your CMDB, whatever feeds the sync.
Then delete it from monitoring.
Do it the other way around and the next sync puts it straight back.
Verify by running a full sync by hand and confirming the host does not return. Config that looks right is not the same as behaviour you watched happen.
This is the part that catches people.
Scheduling a downtime silences notifications. It does not stop the poller. Your monitoring server keeps opening connections on exactly the same schedule, and your IPS keeps logging every one.
A host in downtime looks quiet on your dashboard and screams in your firewall log.
If a host is gone for good, remove it. Downtime is for a host that is coming back.
Sometimes you do want a host on a locked down VLAN monitored.
Do not give the monitoring server a route to it.
On Proxmox, use the hypervisor API instead. The special agent talks to your Proxmox host, and Proxmox already knows about every guest. You get CPU, memory, disk, network and backup status with no packet ever crossing into the isolated VLAN.
In Checkmk, create the host with agent set to no-agent and address family set to no-ip.
The host then shows an address of 0.0.0.0 and the status
Host is always assumed to be up. No ping. No SSH. No IPS alert.
I did this for a trading bot on an isolated VLAN. It went from zero monitoring to eight real checks, including backup status, without opening a single hole.
Check what your own gear is doing before you go looking for an intruder.
Every monitoring system, backup agent and discovery scanner you run is a machine whose whole job is connecting to things on a schedule. That is also the definition of a scanner.
When you retire a host, the guest is the easy part. The things that were watching it outlive it, and they keep knocking.