Internet-wide scanning for exposed network device management interfaces.
What gives it awayRepeated attempts on an outside interface from many unrelated source addresses, typically hitting SSH and HTTPS in sequence.
ATT&CK T1046Cisco Secure Firewall ASA · Event 710003
ASA 710003: Something tried to manage the firewall itself
This is not a blocked connection through the firewall — it is a blocked connection to the firewall. Somebody aimed SSH, HTTPS, or SNMP at the ASA's own interface address and was refused because their address is not on the management allow-list.
Also written as %ASA-3-710003ASA 710003access denied by ACL fromASA-3-710003
- How oftenFires regularly
- Vendor calls it%ASA-3 (Error)
- Logsyslog
What it means for you
For an analyst
The distinction from 106023 is the whole point and it is regularly missed: access lists applied to an interface control traffic passing through the box, while to-the-box management access is governed by the ssh, http, telnet and snmp-server commands, which maintain their own allow-lists. That is why adding a permit line to an interface ACL does not fix a 710003. On an outside interface these should be near-zero — if you are seeing them, the management service is listening on the internet and the only thing standing between an attacker and a login prompt is the allow-list.
What it looks like
Sanitised. Addresses come from the RFC 5737 documentation ranges.
%ASA-3-710003: TCP access denied by ACL from 203.0.113.44/51222 to outside:198.51.100.1/sshThe fields that decide it
Everything else in the log line is context.
- Protocol
- TCP or UDP, which narrows which management service was targeted before you even read the port.
- Source address and port
- Who tried. On an inside interface this is usually a workstation someone forgot to add; on an outside interface it is usually the internet at large.
- Interface name
- Which interface the attempt arrived on. This is the field that decides how much to care.
-
inside or a management interfaceAlmost always a legitimate administrator whose address is not permitted yet. -
outsideThe management plane is reachable from the internet. This is the finding, regardless of whether anyone got in. - Destination address and service
- The ASA's own interface address and the service being reached for.
-
sshAttempted SSH management. The most commonly targeted. -
httpsThe ASDM or web VPN interface. Note that a genuine remote-access VPN also lives on 443, so context matters here. -
telnetCleartext management. Should not be enabled at all on a modern configuration. -
snmpMonitoring access. Frequently left with permissive source ranges.
Ordinary reasons this happens
Most of the time it is one of these.
- A new administrator workstation whose address has not been added to the ssh or http allow-list.
- A monitoring or configuration-management system polling from an address that was never permitted.
- An administrator connecting from a different network segment or over VPN, arriving with an unexpected source address.
- A vulnerability scanner run by your own team touching the management ports as part of a scheduled sweep.
- A device with a stale configuration still pointing at an old firewall address.
When it is not ordinary
Credential guessing against the firewall's management service.
What gives it awayPersistent attempts from one external source, often paired with 605004 login-denied messages if any of them reach the service at all.
ATT&CK T1110Reconnaissance from a host already inside the network.
What gives it awayAttempts arriving on an inside interface from a machine with no administrative role, particularly across several management services in a short window.
ATT&CK T1046What to do next
- Read the interface name first. Inside is a configuration gap; outside is an exposure.
- If the interface is outside, check what is actually configured with 'show run ssh', 'show run http' and 'show run snmp-server'. Restricting these to management ranges is the fix, not an ACL change.
- Remember that interface access lists do not govern this traffic. Adding permit lines to an ACL will not stop the message and will not grant the access either.
- Check for 605005 login-permitted messages from the same source or around the same time. That tells you whether anything reached the point of authenticating.
- Look at 113005 and 605004 for failed authentication, which is the next stage if the address was allowed but the credentials were not.
- Where management must be reachable remotely, put it behind the VPN rather than widening the allow-list.
- For internal sources that turn out to be legitimate, add the specific host rather than the subnet.
Queries to run
index=network sourcetype=cisco:asa "710003" | rex "from (?<src>\d+\.\d+\.\d+\.\d+)/\d+ to (?<iface>\w+):(?<dst>\S+)/(?<svc>\w+)" | stats count values(svc) as services by src, iface | sort -countgrep '710003' asa.log | awk '{print $NF, $(NF-2)}' | sort | uniq -c | sort -rn | head -20Syslog | where SyslogMessage has '710003' | extend src = extract(@'from (\d+\.\d+\.\d+\.\d+)', 1, SyslogMessage) | summarize attempts = count() by src, bin(TimeGenerated, 1h) | where attempts > 10Common questions
What is the difference between ASA 710003 and 106023?
106023 is traffic passing through the firewall being denied by an interface access list. 710003 is traffic aimed at the firewall's own address being denied by its management allow-list. The practical consequence is that adding a permit line to an ACL does nothing for a 710003 — the ssh, http, telnet and snmp-server commands are what control that access.
How do I allow a new administrator through, given 710003?
Add their address to the relevant management command, not to an access list. For SSH that is 'ssh <address> <mask> <interface>'; for ASDM it is 'http <address> <mask> <interface>'. Add the specific host rather than the subnet where you can, since these allow-lists are the last line in front of a login prompt.
I see ASA 710003 on my outside interface. How bad is that?
It means a management service is listening on your internet-facing address and being found. Nobody got in — the allow-list refused them — but the service is reachable and the allow-list is now the only control. The right response is to stop offering management on the outside interface at all and require a VPN connection first.
Why is 710003 rated severity 3 when nothing got through?
Cisco assigns severity by message type, not by outcome, and access to the device itself is treated as more serious than access through it. In a log viewer that puts these above ordinary through-traffic denies, which is actually the right priority — but it means a busy inside interface can generate a lot of severity 3 noise from administrators who simply have not been permitted yet.
Read next
- The equivalent of Cisco ASA 106023: Traffic denied by an access-list A deny on traffic passing through the firewall, governed by interface access lists rather than the management allow-lists. The distinction matters because the fix is different.
- Usually comes after ASA 605005: Someone logged in to manage the firewall A successful management login, which is what happens when the source address is permitted and the credentials work.
- Usually comes after Cisco ASA 113005: VPN authentication was rejected AAA authentication being rejected, the next failure stage for a source that is allowed to reach the service.
- Usually comes after ASA 111008: An administrator ran a command on the firewall Commands executed once someone is logged in — what the management access was actually used for.
- The equivalent of Cisco ASA 106001: Inbound TCP connection denied An inbound TCP deny through the firewall, which looks similar in a log viewer and means something quite different.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026