kuz

root~$: cat /dev/ass > /dev/head

NEW: The Doomsday Machine

2025-11-23
The Doomsday Machine. Or, a somewhat ill advised approach to cybersecurity. Now declassified!

What was it?

Embedded image



not exactly...


Embedded image


Well... no, it doesn't do that either.

But it does have one thing in common with the one from the movie

Embedded image


The movie I am talking about is Dr. Strangelove (1964). (Spoilers may be ahead)

The plot of this movie revolves around a fictional device known as the Doomsday Machine, a fail-deadly deterrence system built by the USSR in the cold war. It's based off of the supposedly real "Dead Hand" system, which Russia still has today. Supposedly.

The Doomsday Machine in the movie was a series of underground nuclear bombs salted with a chemical compound that increases the fallout produced, creating a Doomsday-shroud of toxic, radioactive dust that would, apparently, blot out the sun and end life on earth.

The machine was designed to be triggered automatically if the Soviet command was beheaded, and thus lacked the means to carry out an official strike. The machine was also designed to detonate if any attempt was made to disarm it.

Fortunately, our device does no such thing. Instead, it was designed to act as a final layer of security against intrusions into our servers. The premise and design of the device was much the same.

The device itself was not to be considered a real part of our security setup, but more of a disaster-management tool. If the device was to ever be triggered, we were already in deep deep trouble. The way it worked was simple.

It relied mainly on thousands and thousands of honeypot files and folders scattered throughout the server, which were never accessed by any legitimate program. If any of these files were accessed, then one could say with certainty that an intruder has successfully made their way into the server. Though it had other triggers, with varying ranges of "sensitivity" that could also cause it to activate.

If this occurred, then the device would "detonate", i.e., the server would turn itself off. Turning the server off was not something we considered at first, for several reasons. Not the least of which being that it meant we would have to wait several days for someone to go to the centre and turn it back on. But simply booting off proved to be the most effective and immediate course of action in case of an intruder.

This would mean, that unless the intruder was able to determine, prior to accessing the server, which files were real and which were triggers, that any attempt to read or exfiltrate any data would instantaneously disconnect him from the server, locking him out permanently.

That was really all there was to it. It was not a complex program, I wrote it in Go in about 3 weeks.

The second aspect of the device was causing it to trigger if someone tried to disarm it.

Designing programs that the average user can't turn off is pretty easy. But an intelligent intruder could simply send a SIGKILL, which is very hard to make your program "immune" to, although there are several workarounds

The most bulletproof method was to have the program embedded directly into the kernel. Kernel modules/threads can run with flags that make them unkillable. So even an intruder with root access issuing a SIGKILL on it would do nothing since the scheduler would ignore any such signals. Many antivirus software, rootkits, and some malware do exactly this.

This machine, which I only ever used on my own servers, was top secret until I made this post. The effectiveness of the machine depended somewhat on potential intruders not knowing it existed. Given that my days of running servers is now past, I can now bring this clever device into the light.












































Embedded image

★ KOLYMA: blog.cgi (KolymaNET::LIVEJOURNAL)