Summary

  • The APNIC 62 programme calls the result “1.27M Attacks in 204 Days”; its abstract says “attack events”, while the deck reports 1,272,286 “Total Events”.
  • The observation came from one honeynet sensor on one public IP with SSH and Telnet deliberately exposed. It is not a census of attacks across the Asia Pacific.
  • The deck reports 198,973 successful-login signature events but only 4,530 unique source IPs at the successful-login stage. Both figures may be useful; they answer different questions.
  • A public metric receipt should bind every headline number to its sensor set, services, window, event taxonomy, severity rule, deduplication key and unit.

Three names for one headline number

The session title in APNIC's programme says the University of Dhaka deployment saw 1.27 million attacks in 204 days. The programme abstract narrows that to 1.27 million attack events. The first slide says simply 1.27 million events. By the dashboard, the exact total is 1,272,286.

This is not wordplay. An event is a record produced by a sensor or a rule. An attack event is an interpretation of that record. An attack, in ordinary reporting, sounds like a bounded act or incident. The three can be related without being interchangeable.

The deployment boundary is unusually clear. The presentation describes one Ubuntu virtual machine, one CPU core, 2 GB of memory, 20 GB of log retention and one dedicated public IP. Port 22 for SSH and port 23 for Telnet were open; inbound traffic was intentionally left open. That is a purposeful lure, not a passive sample of all traffic reaching Bangladeshi networks, much less the APNIC region.

The experiment is valuable precisely because it is narrow. It shows what automated and interactive traffic did when two familiar services were offered by a decoy. It does not count everything that happened elsewhere.

The login pair exposes the denominator

The clearest audit lies on one slide. A signature table reports 198,973 “SSH login successful” events. Beside it, an attack funnel headed “Unique IPs” reports 4,530 successful logins. The likely distinction is repeated events versus deduplicated source addresses at that stage. The deck does not publish enough schema to reproduce the join, but it does publish enough to show that a bare “successful logins” label is incomplete.

The difference is substantial: about 44 successful-login events for every source IP reaching that funnel stage. Neither side should be discarded. Event volume describes pressure on a sensor and the repetition of behaviour. The source-IP count describes the cardinality of addresses after a stated deduplication rule. Neither number identifies a unique person, organization or campaign.

A source address can sit behind automation, NAT, a relay, a compromised host or shared infrastructure. It can be reassigned. One operator can use many addresses; many operators can appear behind one. Calling 36,598 unique source IPs “36,598 unique attackers” turns a network identifier into an identity conclusion the deck does not establish.

The same discipline applies to the other dashboard tiles. The reported 78,411 unique passwords are credential strings, not 78,411 accounts. The 7,107 usernames are values presented to a decoy, not verified identities. The 19,255 malware downloads, 2,430 commands, 95 active C2 URLs and 4,280 autonomous systems each have their own unit and relationship to the sensor.

A honeypot success is designed to succeed

The word “successful” also needs its object. A honeypot is built to receive, observe and contain behaviour that a production service should reject. A successful login to the decoy is evidence that the sensor admitted a session under its configured rules. It is not, on its own, evidence that a university production server was compromised.

That distinction does not make the observation harmless. The presentation records command execution, downloads and persistent-behaviour patterns after login. Those are useful indicators for defenders. But the defensive value comes from preserving the sequence—connection, authentication attempt, accepted decoy session, command and payload—not from compressing it into a breach count.

The protocol totals offer one clean reconciliation. The deck reports 1,016,974 SSH events and 255,312 Telnet events, exactly the 1,272,286 dashboard total. The displayed signature table is less tidy: its eight counts add to 1,272,287, one higher. The public slides do not say whether signature classes overlap, whether one cell contains a transcription error or whether a filter differs. The responsible conclusion is simply that this table cannot be reconciled from the published definitions.

Publish the metric receipt

The missing object is small. For each headline value, publish the sensor set and exposed services, the exact observation window, the raw event type, the severity rule, the deduplication key, the unit and the known identity limitations. For a funnel, add the transition rule between stages. For a signature table, state whether categories are exclusive and show a checksum against the total.

This metric receipt is Theo March's editorial proposal, not a requirement announced by APNIC or the University of Dhaka. It would not expose sensitive payloads. It would let an operator distinguish pressure from reach, source addresses from actors, and a decoy login from a production compromise.

What the sources do and do not establish

The APNIC programme and presentation establish the session wording, deployment design and displayed counts. APNIC's project pages establish that the programme uses honeypot sensors to collect suspicious traffic, malware and attack-pattern data. The sources do not establish a unique-human count, incident count, country attribution, regional prevalence or production breach. They also do not explain the one-count difference in the displayed signature table.

Sources