APNIC honeynet table shows at least 2,869 repeat IPs

Summary

APNIC’s six per-sensor rows total 113,299 source-IP appearances; its “All honeypots” row counts 98,958 unique addresses. The 14,341 excess memberships force a lower bound of 2,869 distinct addresses seen by multiple sensors.
The report’s rounded sensor shares add to 115%, yet it publishes no intersections. Operators can rank each doorway by volume, but cannot see how many sources returned through another one.

The table has a 115% problem

APNIC’s rebuilt Honeynet logged 98,958 unique source IP addresses from 21 to 27 September 2026. Its Table 1 lists six sensors: Cowrie saw 72,256; Dionaea 21,210; OpenCanary 14,393; Fortinet 1,876; ADBHoney 1,841; and Webpot 1,723. Add those rows and the result is 113,299.

The gap is 14,341 sensor-address memberships beyond the number of distinct addresses. The displayed shares—73%, 21%, 15%, 2%, 2% and 2%—add to 115%. Using the counts before rounding, the rows equal 114.49% of the unique-address total.

That is not a mysterious accounting error. These are overlapping sets, not six slices of one pie. If one address reached Cowrie and OpenCanary, it appears in both sensor rows but once in “All honeypots.” If it reached three sensors, it contributes two of the 14,341 excess memberships.

There is a useful lower bound hiding in the subtraction. An address can appear on no more than six sensors, so any repeated address contributes at most five excess memberships. Dividing 14,341 by five and rounding up means at least 2,869 distinct source IPs reached more than one sensor. The exact count could be as high as 14,341 if each repeated address appeared on exactly two sensors. APNIC publishes neither that exact count nor a sensor-by-sensor intersection table.

The missing table matters because the report’s categories are service-shaped. Cowrie imitates SSH and Telnet; OpenCanary includes RDP and databases; Webpot poses as web applications; Fortinet mimics an SSL-VPN portal. Their separate totals answer “how many source addresses reached this sensor?” They do not answer whether the same addresses reached several kinds of service during the same week.

APNIC deliberately uses unique source IPs instead of raw event volume. Its sensors logged 173 million events over the week; one bot can fill logs while another source connects once. That choice stops a noisy source from counting as millions of observations. It still leaves the address as the unit. Table 1 has no device or person field, and its rows cannot be read as a census of distinct operators.

For a security team, recurrence changes the queue. If one source reaches several decoys, an analyst may correlate the observations and check whether the pattern merits a shared response. If each sensor sees mostly different sources, the work may stay service-specific. The current marginals cannot distinguish those situations. The 14,341 excess is not an exact count of recurring addresses, and it does not identify a campaign; it is the number of memberships left after each unique address gets one first appearance.

APNIC could close the gap with aggregates. A distribution of addresses seen by one, two, three or more sensors would reveal the scale of recurrence. The 15 pairwise sensor intersections would show where it concentrates. A short note on source-IP normalization and the observation window would tell readers what those comparisons actually join. Raw addresses need not be published.

The report says the rebuilt network is still too new for detailed analysis. The arithmetic is already detailed enough to expose what the next table should measure. APNIC controls the sensor set and the presentation; network operators decide how to act on the evidence. Put the union, the membership total and the overlap distribution beside one another, and nobody has to reverse-engineer a security chart from a percentage that ends at 115%.