Once the Gateway was showing me real traffic, the next problem was making sure it could keep collecting evidence without becoming a problem of its own.

This was never meant to be a normal server sitting on my home network. It was a deliberately exposed research machine, so I treated it differently from the computers and devices I actually trusted. The services running on it had one job: accept the kind of traffic I wanted to study, record what happened, and keep that activity away from everything else.

The first part was separating the services. Cowrie handled the fake SSH and Telnet sessions. Other decoys had their own jobs and their own logging. I did not want every service sharing the same files, permissions, or process space. If one service had a problem, it should not automatically have access to the others.

The logs were kept separate from the operating system as much as possible. Session history, command records, connection details, downloaded artifacts, and notification state all had their own storage locations. That made it easier to review what happened later, and it also meant I could preserve the evidence without constantly mixing it into the rest of the machine.

The storage arrangement mattered more than I expected. A honeypot can collect a surprising amount of information, especially when automated tools keep reconnecting and repeating the same steps. I wanted the system to record the useful details without filling the operating-system partition or making it difficult to tell the difference between current activity and older evidence.

Notifications were another part of the setup. I did not want to sit in front of the Gateway all day waiting for something to happen. The notification watcher could tell me when a session or captured item needed attention, while the full details stayed in the local logs. The alert was only the starting point. The real investigation still came from reading the original session and checking what the honeypot had recorded.

I also kept management access separate from the services exposed to the outside. The public-facing bait was there to receive unwanted traffic. Administrative access was for me, and it was handled through a different path. That separation made it much easier to shut down, inspect, or change a service without treating the honeypot itself as a trusted computer.

The network layout followed the same idea. The Gateway lived on an isolated segment rather than beside the machines I used every day. The point was not to make the system impossible to reach. The point was to make sure that anything reaching the honeypot had nowhere useful to go if it escaped the fake service.

That distinction became important once the sessions started doing more than scanning. A connection attempt was one thing. A successful fake login followed by system fingerprinting, file creation, permission changes, download attempts, or forwarding requests was something else entirely. The Gateway needed to record that progression while preventing the session from becoming a real foothold.

This was all built with limited hardware and a lot of trial and error. I was not designing a commercial security platform. I was trying to build something small enough to understand, isolated enough to be safe, and useful enough to show me what automated attacks actually did after they found a door.

The Gateway eventually became more than an old computer collecting random connection attempts. It became a place where I could watch the sequence unfold: discovery, authentication, system checks, follow-on commands, and attempted retrieval. The separation between services, storage, notifications, and network access was what made those observations useful instead of reckless.

The next step was looking at what happened when the Gateway started receiving complete sessions instead of isolated probes—the files it was offered, the commands that followed a login, and the difference between a scan and a real automated campaign.

Keeping It Small on Purpose

The Gateway was not a powerful machine. It was an old laptop with limited memory and limited storage speed, so I had to be selective about what I ran. I could not just enable every honeypot service I could find and hope the machine would handle it. Every service used resources, created another log stream, and added another thing I would eventually have to understand.

That forced me to make better decisions. I started with the services that gave me the most useful information and left the rest disabled. If a service did not add something meaningful to the research, it did not need to be exposed just because the software supported it.

I also learned to test everything locally before opening it to outside traffic. A service could appear to be running while still writing to the wrong directory, failing to save sessions, or using more memory than the machine could spare. A local test showed me whether the listener worked. The real traffic showed me whether the entire evidence path worked from beginning to end.

That evidence path mattered. It was not enough for a connection to appear on a screen. I wanted to know that the event had been logged, that the session could be reviewed, that any captured material had been stored separately, and that the notification system could tell me something had happened without exposing the whole machine.

I kept the captured material away from the operating system whenever possible. The idea was simple: if the honeypot collected something suspicious, it should be stored as evidence, not treated like a normal file on the computer. I did not open captured files on the Gateway, and I did not use the honeypot as a workstation. It was a sensor and an evidence collector.

The same rule applied to maintenance. I wanted to be able to stop one service without taking down everything else. I wanted to review logs without changing them. I wanted to restart a watcher without accidentally deleting the records it was watching. Those little details were not exciting, but they made the difference between a useful experiment and a pile of confusing files.

There was also a practical lesson in keeping administrative access separate. I needed a way to manage the machine, but I did not want the management path mixed into the bait. The public-facing services were there for strangers and automated tools. The management path was for me. Keeping those purposes separate made the system easier to reason about and easier to shut down if something did not behave the way I expected.

The Gateway taught me that a honeypot is not just a fake login page or an open port. It is the whole chain behind it: the service, the network boundary, the storage, the alerting, the evidence handling, and the discipline to leave the captured material alone until it can be reviewed safely.

That was the part I had not really understood when I started. The interesting work was not simply attracting traffic. It was building a small enough system that I could follow what happened from the first connection all the way through the recorded session, without putting the rest of my network in the middle of it.