Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jesse Bowling
    @JesseBowling
    That said, I’d apprecciate your feedback on the documentation/approach with the personalities!
    Robin Lennox
    @robinlennox
    @JesseBowling Thanks for getting back to me... I'll have a look and keep you posted on where I get :) I agree that there is an issue with 22 being used for remote management that may being difficult for some to overcome; and we need to consider what we do to ensure we keep the simplicity of the auto deployment.
    Robin Lennox
    @robinlennox
    Hey, from what I've been reading on the github page for chn-server it looks like the team is working on revamping the UI? Did I read that right?
    Mike
    @kraigu
    I can't speak for the team, but I believe you did read it correctly, yes
    Robin Lennox
    @robinlennox
    @kraigu Thanks for the heads up... I save my time looking at the UI if it's going to change.
    Robin Lennox
    @robinlennox
    I don't think it's possible but thought I'd check. Is it possible to pull the country code along with the IP via the API?
    Jesse Bowling
    @JesseBowling
    @robinlennox I don’t believe that’s possible today. Most of the CC lookup stuff was a bit bolted on, and some of it broke when the Maxmind database format 1 EoL’ed. That said, if it’s important to you please file an issue so we can know people want it (and if more do, they can thumbs up it, etc.).
    Robin Lennox
    @robinlennox
    Robin Lennox
    @robinlennox
    Has anyone noticed that the docker image for dionaea logs are huge... is there a reason the logs are kept around?
    Jesse Bowling
    @JesseBowling
    They do get huge..I know there was a rotation added in for them at some point; it’s primarily the bistream logs and mostly seem to be wannacry related. :-/
    That said, we added the rotation to cut down on HOW huge they got, but didn’t expose the rotation settings. Should be do-able though
    Robin Lennox
    @robinlennox
    Thanks for that I'll take a look
    :)
    Robin Lennox
    @robinlennox
    Quick question about the docker containers... I was thinking it would be better to use the latest tag rather than version tags . This would allow the docker images to be auto patched each week and then pulled by the end users. I'm concerned about these containers not being patched regularly... what does everyone think?
    Jesse Bowling
    @JesseBowling
    We started with that idea…We moved to a specific version because we wanted to ensure that people could control their destinies there, and upgrade at a pace they were comfortable with. We also wanted to reclaim “latest” as something that might get build out of master regularly
    Although potentially we could use a new tag, such as “stable” for those situations.
    Robin Lennox
    @robinlennox
    Understandable to be sticking with versions to allow end users to have an upgrade path; would it be possible to have the versions with security patching that are run on a regular basis and pushed out? Also it would be gone for some in the community to be running the latest versions of the stable codebase as we have setups that could raise the flag early if there is a problem.
    Jesse Bowling
    @JesseBowling
    I’ve been thinking about the os patching; I think we could use our CI/CD stream to rebuild an re-push images for the same tag regularly…That will take a bit of setup on our side, but ought to be cleanest in the long run.
    Robin Lennox
    @robinlennox
    That sounds awesome! Doing that would help ensure the project is producing less vulnerable containers... I'd hate to see a honeypot get popped due to a 6 month old vulnerability...
    Mark Gardner
    @mkgvt_gitlab
    Just installed our first CHN honeypot yesterday and set up Cowrie. Today the security office alerted me that the FireEye saw that the honeypot node downloaded the Mirai virus. Is this normal or abnormal behavior?
    Jesse Bowling
    @JesseBowling

    Hi @mkgvt_gitlab ! Thanks for the interest in the project!

    This is one that often gives folks pause; cowrie’s default behavior is to let attackers “log in” and then record the commands that are attempted by the attacker. If cowrie recognizes an attempt to pull down a file (such as "wget badsite.com/malware”), cowrie will go fetch the file, hash it, and store the file in the local filesystem (in this case, inside the container).

    So yes, it can be expected that the honeypots would trigger this sort of behavior. It’s possible to modify the honeypot so that this sort of activity would not be possible (i.e., a custom personality with a userdb.txt that does not allow any logins to succeed), but you would lose some valuable information about what attackers are trying to accomplish.
    That said, each environemnt has different risk profiles, so there might be some work to be done in udnerstanding the behaviors of the various honeypots and what might be expected. To be fair, this is a question I’m getting more and more often, so we’ll try to work up some documentation on this soon.
    Mark Gardner
    @mkgvt_gitlab
    That is the conclusion we came to today by sifting through our monitoring logs and docker logs. But it is comforting to hear you say it. :-)
    Jesse Bowling
    @JesseBowling
    Well I’m sorry you all had to spend all that time investigating! I was on vacation last week and missed the message. :)
    On the positive side, I’m guessing you all learned a lot about the honeypot? :D
    d90
    @d90
    I have a general question: how do we generate deploy key
    @JesseBowling the honeypots require this but i don't see info on how to generate them.
    Jesse Bowling
    @JesseBowling

    Hi @d90 ! So the easiest way to get the key is to use the webui, and browse to the ‘Deploy’ tab. Select one of the honeypot scripts. The command line displayed will include the deploy key…for example:

    deploy.sh https://stingar.url 8characterdeploykey &&

    You can also run docker-compose exec chnserver grep DEPLOY_KEY /opt/config.py
    And finally, if you want a predictable DEPLOY_KEY, you can set it in chnserver.sysconfig: DEPLOY_KEY=“”
    d90
    @d90
    OK. thank you
    Mark Gardner
    @mkgvt_gitlab
    Our CHN honeypots seem to be running just fine. Next step. How do we get the data back? Was it in the documentation and I missed it?
    d90
    @d90
    @JesseBowling I have a concern with cowrie. When I nmap scan it clearly announces this is a honeypot. I'm wondering if this could be obfuscated 23/tcp open telnet Cowrie Honeypot telnetd
    Mike
    @kraigu
    @mkgvt_gitlab you can look at it GUI-wise on your CHN server system, the default userid is admin@localhost and there's steps in the docs to set a password. Or you can pull things out with an API key + some curl / favourite scripting/scraping language
    or if you've configured it to do so, your CIF server, but I'm assuming you didn't do that
    @mkgvt_gitlab or, based on backscroll, your security office will tell you :D
    Mark Gardner
    @mkgvt_gitlab
    Thanks @kraigu. I'll look into it. As for the ITSO, he is already aware of my activities. :-)
    Mike
    @kraigu
    no worries =]
    Chris O'Donnell
    @chodonne_twitter
    @d90 looks like cowrie fixed the nmap scanning issue with 1.5.3, but the CHN repo currently pulls 1.5.2. https://github.com/cowrie/cowrie/releases
    Jesse Bowling
    @JesseBowling
    @chodonne_twitter thanks for the note about cowrie! We’ll look at updating that.

    @d90 : One (underused) option that may help in this case (unsure since I’m not sure what NMap is keying on; chodonne’s answer may be what’s needed) is to use the personalities option for the honeypot:

    https://communityhoneynetwork.readthedocs.io/en/stable/cowrie/#adding-a-custom-cowrie-personality

    Chris O'Donnell
    @chodonne_twitter
    when routing multiple subnets via AnyIP, are there any other configs that need to be tweaked? Like either the docker daemon or cowrie configs?
    Jesse Bowling
    @JesseBowling
    Oof, that’s one for @drewstinnett…I think all we have on that is at https://communityhoneynetwork.readthedocs.io/en/stable/config/#accepting-all-traffic-from-a-default-route
    That said, this works fine for smaller, non-overlapping dark networks. It does NOT work well when using default routes, due to kernel confusion on where to route things. to be more concrete...
    Chris O'Donnell
    @chodonne_twitter
    I saw that and still having issues (possibly something weird on our end). I’ll keep digging
    Jesse Bowling
    @JesseBowling

    Routing 10.0.10.0/24 to an anyip host with a “real/management” interface on 10.0.20.5 is just dandy.

    But if you tried to send a default route of 10.0.0.0/16 at the anyip interface, your management interface traffic will end up sucked into the honeypot as well, which is of course not ideal. :-/

    I think the answer there is multiple routing tables with priority based on interface, but I’ve yet to actually work out exactly how to make that work.
    Chris O'Donnell
    @chodonne_twitter
    ok…we’re working on routing subnets that aren’t on the same one in the main interface.