Link each Docker container to the IP of the attacker
unixfox opened this issue · 10 comments
Description of the feature
It could be great to add a feature that links each Docker container to the IP of the attacker.
The Docker container is stopped after session exit and if it's the same IP that reconnects after, honSSH starts the same Docker container.
It could be another way to recognize the attacker like saving his public key and compare if it is the same that connects. (the SSH client always sends his public key no matter what if it's a password auth or not.)
Actual behavior
When an attacker closes the SSH connection, the Docker container is instantly killed and it confuses the attacker if he reconnects after.
Scenario of the feature
The attacker connects to the honeypot, then place for example his DDoS IRC tool, then disconnect, the Docker container stops. Then after a few hours, the attacker reconnects to the honeypot, the Docker container (in which it was previously connected) starts and he finds his previous environment.
A container TTL would also be needed to cleanup at some time.
@unixfox There you go https://github.com/bang-uin/honssh/commits/feature/container_reuse
It's based on my "fs_watch" branch, because i made some changes that simplified "reuse".
It wouldn't be too hard to implement it in the master, but i was too lazy :)
TTL is not implemented yet.
Containers are tied to the attackers ip.
What do you think?
@bang-uin Wow, I really appreciate the time you put on honSSH ;)!
That's a great beginning, if we could integrate another way to recognize the attacker it could be great! Like a priority:
- Test if the SSH client provided public key, use this method.
- If not, use his IP to recognize him.
I don't know if there are another ways to trace the attacker.
I'm not an ssh protocol guru, but from reading the protocol spec getting the pubkey during the SSH_MSG_USERAUTH_REQUEST is not possible. The pubkey is only provided if that auth method is actually used. Meaning that honssh needs to first make a real pubkey auth and then abort it to do a password fallback. This behaviour would introduce a recognition vector.
Okay and why it could be suspicious? If I try to log into my a random ssh server and my public key is not valid, the SSH client switch to password auth.
Yeah, true :D
Hmm, so i need to find the code where the publickey auth is handled.
Maybe you or @tnich can point me at that.
I'm not sure, but i think that the pubkey auth is not working at all. Looks like there is some implementation missing. @tnich could you give a short statement?
Thanks
Hi Both, Sorry for the slow reply, it's been a busy week.
HonSSH does not work with public keys as it would be tricky to MITM it. It might potentially be possible but I've never seen anyone add their public key to a honeypot before so never looked into it.
@bang-uin I've had a quick look at your container reuse and fa watch stuff - they look great. Can you create a pull request when you are happy with them?
Cheers,
Hi, thanks for the reply.
container_reuse: I would suggest to stick with the IP for now. We can later add publickey if needed.
fs_watch: I'm basically happy with it. The only 2 things i would like to change in future is the twisted-inotify fix and the near zero out possibility. Also i would like to add 2 more things 'max_filesize' and 'revision'. revision would fix the near zero out problem. We'll see, but this will become a separate pull request.