[ home / overboard ] [ soy / qa / raid / r ] [ ss / craft ] [ int / pol ] [ a / an / asp / biz / mtv / r9k / tech / v / sude / x ] [ q / news / chive / rules / pass / bans / status ] [ wiki / booru / irc ]

A banner for soyjak.party

/news/ - Soy News

The only news (You) need to hear
Catalog
Email
Subject
Comment
File
Password (For file deletion.)

File: ClipboardImage.png 📥︎ (494.67 KB, 1500x1500) ImgOps

 â„–19828[Quote]

https://kuz.kolyma.net/blog.cgi/entry/1763887136

"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."

TL;DR:
The sharty had or still does have a program that shuts the server off if an intruder were to gain access to the servers and touch "honeypot files".

 â„–19829[Quote]

I found this interesting so I decided to share it here

 â„–19830[Quote]

jannies pin dis mane

 â„–19842[Quote]

>>19828 (OP)
gemmy

 â„–19843[Quote]

>>19828 (OP)
but why would somebaldi touch files he isn't looking for?

 â„–19908[Quote]

>>19843
It's like if somephono tries reading files like /etc/passwd and other sensitive files I suppose



[Return][Catalog][Go to top][Post a Reply]
Delete Post [ ]
[ home / overboard ] [ soy / qa / raid / r ] [ ss / craft ] [ int / pol ] [ a / an / asp / biz / mtv / r9k / tech / v / sude / x ] [ q / news / chive / rules / pass / bans / status ] [ wiki / booru / irc ]