4

Would following be a feasible security feature to detect attempts?

Creating a user with following specs:

  • Username admin
  • Password fairly insecure (not 123456, but a dictonary word)
  • Special permissions: none
  • A .bashrc script that notifies me of the login, ...

Questions

  • Would this create security risks (priviledge escalation, etc.)?
  • Would it be a sensible way of collecting information about an attacker, or should one close the session immediately within the .bashrc script?
  • What steps should be taken to make it feasible/secure?

Purpose

  • To know about a more severe threat before it is "too late"
  • To gather information about an attacker: techniques/tools they are using, who they are (where the attacks come from), etc.
Improve this question
8
  • 5
    Would this create security risks (priviledge escalation, etc.) It might, since there may be local exploits to provide privilege escalation, thus allowing an attacker fully control the host. A possible solution to this is to use a dedicated machine behind a firewall with rules restricting the possible actions an attacker might try to perform.
    – luizfzs
    Jan 31, 2018 at 17:04
  • 2
    Also, there are high interaction honeypots that do this type of thing already, with better logging and more isolation. See Kippo/Cowrie.
    – multithr3at3d
    Jan 31, 2018 at 17:11
  • Thanks for the infos, but I am looking at a scenario where the host is well known to the outside (difficult to hide). Implementing some kind of honeypot on a single machine is pretty much the challenge. I will look into Kippo/Cowrie!
    – Levite
    Jan 31, 2018 at 18:29
  • Lots of questions to ask. What's the purpose? What attempts? Why do you need a valid password to detect attempts (easy passwords only needed if you want them to actually succeed in logging in)? How will this account be used? Why not disable a shell for this user?
    – schroeder ♦
    Jan 31, 2018 at 19:28
  • 1
    This seems like a bad idea with Spectre being so powerful and unpatched.
    – Steve
    Feb 1, 2018 at 2:43

2 Answers 2

Reset to default
1

From your requirements that you state in your comments, you are not looking for a "honey user" but a high-interaction honeypot.

High-interaction honeypots, like the one you are suggesting, must never, ever be run on production systems. Any OS-level vulnerability can enable the attacker to escalate.

Always place high-interaction honeypots on their own walled systems.

But a high-interaction honeypot is only required to gather certain types of info about the attacker. If you are looking to analyse techniques, tools, and gather any other data that can only come from observing the actions of the attacker in real time, then you need a high-interaction honeypot. And then this is not simply a "honey user" as your title suggests, but a full-blown honeypot.

A true "honey user" should not, and need not, be high-interaction. Any attempts to log in as that user can trigger alarms and additional logging. Any use of the user credentials in the system can also be captured. None of these things requires that the credentials actually work, hence there is no security impact. You can capture timestamps, source IPs, and the passwords that have been attempted.

What you are really looking for is Kippo/Cowrie (which I regularly run and have done many presentations on). And the developers are very clear to never run their honeypot on a production system. For the honeypots that I have deployed, I always place them in DMZs, on virtual machines, that reset every 24 hours (or sooner) and the logs are shipped to a central server. Any traffic initiated from the honeypot is blocked. Attackers can get in, but cannot get out, even if they compromise the entire machine.

You should be thinking about a similar setup.

Improve this answer
3
  • 1
    Fun fact: I have left a Kippo/Cowrie VM running for a week, and was able to capture the same user logging in several times, even though they kept running into the "Kippo taunts". The attacker was not sophisticated, so I imagine that they were trying to figure out why the machine was not acting the way they expected it to. I felt sorry for the poor soul. I don't like the risk of keeping a honeypot running that long, but there is the potential to gather more info on an attacker the longer you keep the honeypot running.
    – schroeder ♦
    Feb 1, 2018 at 10:33
  • Sounds good! So for my "single host" project, I could think of redirecting traffic on port 22 or 2222 to a separate machine/VM in an otherwise DMZ that has a similar setup (non-root user on that machine running Kippo/Cowrie on any "non-root" port)? Or would the redirecting/port-forwarding itself be a high enough security risk (DDoS, etc.) not to do so? I tend to think "totally" separate from any production server is really the only way to go, but wanting to verify that. Thanks!
    – Levite
    Feb 1, 2018 at 10:34
  • 1
    Port redirection is fine (depending on configuration) and even suggested by the Kippo devs. DDoS protection is outside the scope of your scenario (layer 3 problem). You have to make a decision on that risk.
    – schroeder ♦
    Feb 1, 2018 at 10:37
1

Allowing execution of an unknown source is not a good idea even if the user has minimal privileges.

Things that can be done by attackers:

  • The attacker can execute code on your hardware, and may use 100% CPU for mining cryptocurrencies for example.
  • The attacker may eventually have the opportunity to use a privilege escalation such as dirty-cow.
  • The attacker may find a suid file that was badly designed for privilege escalation.

There are opensource projects on GitHub that emulate a ssh session, and you can be in full control of the session: https://github.com/micheloosterhof/cowrie/blob/master/README.md

Improve this answer
1
  • Thanks! So according to your answer one would be "safe" by logging the attempts and killing the session immediately, or not giving the user a shell at all?? Concerning Cowrie/Kippo their developers are not really convinced that it could withstand an attack; which is a no-go for a machine that has other stuff running imho.
    – Levite
    Feb 1, 2018 at 10:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .