Once the Gateway was running on antiX, the next question was what to put on it. I did not want to turn the old computer into a giant software project or install every security tool I could find. The hardware was limited, so I built a small, focused setup around the services that would give me useful information.
There was a partial T-Pot setup involved, but it was not the full T-Pot suite. I used selected services instead of trying to run everything at once. The two main pieces were Cowrie and Dionaea, and each one gave me a different view of what was happening.
Cowrie handled SSH and Telnet activity. It presented a fake login environment where connection attempts, usernames, passwords, commands, and session details could be recorded without giving anyone access to the real operating system. If somebody logged in with a common username and password, I could see the attempt. If the fake shell accepted the session and the visitor started typing commands, those commands were recorded as well.
That distinction mattered. A connection by itself only told me that something had found the service. A login attempt showed more intent. A command session showed that the visitor, bot, or automated tool had gone further. Cowrie gave me a way to separate those stages instead of treating every connection as the same event.
Dionaea handled a different kind of traffic. It exposed several deliberately fake network services and recorded the probes, connection attempts, login activity, and file activity aimed at them. Not everything on the internet is looking for SSH. Some scanners check file-sharing services, database services, message services, and other systems that may answer on an exposed network.
Dionaea was useful because it gave me a broader picture. I could see which protocols were being tested, whether a connection was just a quick probe, and whether a session continued far enough to produce a file or another artifact. It also gave me another source of evidence to compare with the SSH and Telnet activity from Cowrie.
The Gateway had dashboards for both services. I wanted to see the important parts without opening a raw log file every time, so the dashboards summarized recent connections, sessions, sources, service types, and other activity. They were useful for getting oriented, but they were never the authoritative record. The original logs were still the place to go when I needed to verify what actually happened.
Notifications worked the same way. I had watchers that looked for selected Cowrie and Dionaea events and sent summaries through ntfy. I did not want an alert for every routine scan, because that would quickly turn into noise. The idea was to get a notification when something deserved attention, then go back to the stored logs and dashboards for the details.
The services were supervised so they could be restarted if something stopped. The capture storage was also kept separate from the operating system and the service files. That was not glamorous work, but it became important as soon as the Gateway started collecting real traffic. Logs and captured files needed to be preserved independently instead of being mixed into whatever software happened to be running at the time.
The setup was not fast. The Atom processor was old, the memory was limited, and every service had to earn its place. I had to watch how much the dashboards used, how often the notifications fired, and whether the system could keep recording without falling behind. That limitation was actually useful because it forced me to understand what each part was doing.
The first traffic was mostly scanning, login attempts, protocol probes, and automated tools checking whether the services would respond. That may sound ordinary, but it was exactly the kind of activity I wanted to observe. The Gateway was no longer just an old computer running in the corner. It was now recording how outside systems interacted with a deliberately exposed set of services.
The important lesson was that a honeypot is not valuable just because it accepts a connection. The value comes from the trail that follows: the protocol used, the attempted login, the commands entered, the files requested, the artifacts captured, and the time relationship between events. Once those pieces were stored together, I could start comparing activity instead of looking at isolated alerts.
That was the point where the project changed for me. I stopped thinking of the Gateway as a rescued computer and started treating it as a sensor. It was not a high-end platform, and it was not running every feature available in T-Pot. It was a small, selective setup built around an old machine, a few useful services, and the discipline to keep the evidence organized.
The tools behind this setup are open-source projects, and the original repositories are worth looking at if you want to understand how the pieces work. T-Pot is the larger multi-honeypot platform, while Dionaea focuses on broader network-service emulation. Cowrie handled the SSH and Telnet side of my setup.
Those are the official repositories. T-Pot is the full platform, while Dionaea and Cowrie are individual components that can also be used separately.
Next time, I’ll show what the first real traffic looked like after the Gateway was running. After that, I’ll walk through how I built the setup itself, including the software, storage, notifications, and network decisions that turned an old computer into a working honeypot.
Leave a Reply