Part 1 described the external view: what an attacker sees when they scan your network from outside. This part is about what happens after the scan — how attacker behaviour appears in the log record, and what the intersection of the external and internal views reveals that neither alone can show.

The honeynet experience is relevant here, though the context is different. In the honeynet, the external view was deliberate — a service designed to attract attention. In a production network, the services that attract attention were not designed for that purpose. The attacker's behaviour in the log is the same either way: connection attempts, credential guessing, service enumeration, the pattern of an automated tool working through a checklist. What differs is the baseline. In production, you need to distinguish attacker activity from legitimate traffic. In a honeynet, everything is attacker activity.

What automated scanning looks like in logs

Automated scanning has a characteristic signature: high connection rate, sequential or pseudo-random address patterns, regular timing, credential lists in a known order. Firewall logs from any internet-exposed service show continuous background scanning from a large number of source addresses. This is not targeted — it is opportunistic, the automated equivalent of trying every door in every building in a city.

The noise threshold is important to establish before you attempt to identify signal. What is the baseline rate of connection attempts to each service? What is the baseline rate of authentication failures? What does the distribution of source addresses look like? When something deviates from those baselines — a higher-than-normal rate from a specific address range, an unusual service being targeted, a sequence of connection attempts that suggests enumeration rather than random scanning — it registers against the established baseline as something worth examining.

Cross-referencing with the external view

The most productive analysis combines the external scan results with the log data. For each service visible from outside, the logs should show some level of inbound connection attempts. The absence of connection attempts to a visible service is itself informative: either the logs are not capturing those attempts, or the service is less visible from the internet than the scan suggested, or the service was only recently exposed.

Services that the external scan reveals but the logs do not show any activity for deserve investigation. Logging that is not working is a gap. A service that appeared recently without a corresponding log configuration change is a gap. A service that is consistently being targeted but whose authentication logs are not being reviewed is also a gap — the activity is recorded but not actioned.

What the honeynet logs added to this picture

Running a honeynet alongside a production network, where the honeynet is visible from the same external vantage points as the production services, provides a comparison: what does the honeynet attract that the production services also attract? What does it attract that the production services do not? The difference is a map of targeting: what the scanning tools are looking for, versus what is on the network.

The Oracle honeynet attracted credential-guessing traffic for Oracle-specific default accounts within hours of appearing on the network. The production services at the same addresses attracted credential-guessing for SSH default accounts, HTTP administration paths, and a long tail of application-specific exploits. The comparison showed that the automated scanning tools had databases of service-specific attack sequences and were applying them selectively based on banner information. The targeting was not random. It was specific, efficient, and would have been invisible without the honeynet providing a baseline for comparison.

The external PING and the internal log are two views of the same event. Neither is complete alone. The gap between them — what sent packets that were not logged, what was logged but never examined — is where the honest picture of the network's security posture lives. Close the gap, or at least measure it accurately.