search

toxyl / ossh

... is a dirty mix of honey and tar, delivered by a fake SSH server.
Other
2 stars 1 forks source link

Improved security by process isolation #12

Closed dylandreimerink closed 1 year ago

dylandreimerink commented 2 years ago

There are a few security risks with the current architecture of the honeypot which I would like to address. We are playing with fire so to speak since we are inviting the internet to come onto our server and see what they will do. We have to make sure that we don't accidentally allow attackers to escape our sandbox and do actual harm to the host.

We currently run the pot as the root user, which is not ideal for security. However we still want to run as root so we can use some features like mounting file systems to create OverlayFS's.

My proposal is to split the application into two different kinds of processes where we have one 'main' thread which runs as root and can do everything on the system we need it to do. Then when a new SSH session is created, the main thread will setup the environment and spawn a child process(or we have one Go process which will spawn a goroutine). The child process will drop its privileges and change to a 'sandbox' user who can't do anything outside what we allow it to do. We can even place the process in a chroot jail so it can't even attempt to access files outside of its designated directory.

Initially this child process also will not have the SSH connection. We can transfer the file descriptor of the SSH connection over an UNIX socket. We can use this same unix socket to allow the child process to communicate back to the main process to for example send back the captured input/output of the session so the main process can store is in a directory to which the child has no acccess.

In the future we could even expand on this by placing the process in isolated namespaces of we so desire to for example block the process from using the network https://unix.stackexchange.com/questions/68956/block-network-access-of-a-process

toxyl commented 2 years ago

Absolutely agreed. Considering that the honeypot might also catch the latest 0-days or even attract hacking attempts targeted at the pot itself, we can't be careful enough. I'm all for :+1:

The idea with namespaces for a later iteration sounds good, too.

dylandreimerink commented 2 years ago

Looked into this, the whole idea should be doable, the main issue is that the ssh server library maintains a lot of state outside of the TCP connection, this makes it impractical to transfer the connection once the SSH sever has it. That means we have 2 options for implementation as far as I can see:

  1. Run a custom TCP listener on the main process, then transfer the connection before feeding it into the SSH server of the sub process (this means every process will have a server with at most 1 connection which seems wasteful).
  2. Run the whole SSH server permanently as a non-root user which we isolate as much as we can and start a "security daemon" which creates a UNIX socket with permissions for the non-root user and has a API(HTTP or gRPC) over UNIX socket which has very limited functionality like creating an OverlayFS, communicating loot and downloading files/accessing the network outside of the established listening socket.
toxyl commented 2 years ago

I'm not sure if I'm judging it correctly, but to me 1. seems to be easier to implement and less error prone at the cost of more connections? How much of an impact could that be?

toxyl commented 1 year ago

So far I have not seen any breaches, and I have a cluster of 12 running for more than 6 months. What I see coming in is almost exclusively bot traffic and standard payloads. I guess it's a good one for v2 as well.