
Cowrie: a medium-interaction SSH and Telnet honeypot - Fazel94
https://github.com/cowrie/cowrie
======
mergy
Caution for folks: I ran this for a few weeks and it was very informative. You
see how simple many attacks really are, how many corporate assets are
comprimised, and where most of the source attacking countries are.

But, there is a downside.

The downside is any site you put it on will be flagged and attacked 100x more
since it registers as a vulnerable destination. After turning it off, the
deluge of attacks for the site continues and I ended-up rigging a fail2ban
setup to just deny if a destination port is hit. (See >>
[https://mergy.org/2019/08/setting-up-a-killswitch-for-
attack...](https://mergy.org/2019/08/setting-up-a-killswitch-for-attacks-with-
ufw-and-fail2ban-on-ubuntu-linux/))

But, it is fun and interesting to see. Highly recommend but know the legacy on
that as well.

~~~
mergy
Here is what a playmaker session looks like if you are interested

[https://vimeo.com/345068825/86f8c8f97e](https://vimeo.com/345068825/86f8c8f97e)

------
segfaultbuserr
> _records the interactions of hackers_

Before you get too excited, I would say that a common mistake of inexperienced
sysadmins is assuming all those brute-force attempts in the logs are results
of those "hackers" and "crackers", it's not, not even a scriptkid.

All you can get by running a honeypot, like this one, is pretty boring
activities by soulless, ancient worms and viruses, or automatic global
Internet scanners running 24x7, not humans. Most of those are not even worth
your time to block (e.g. if you only use strong password or pubkey, there are
few reasons to fail2ban).

It's nothing personal. Any machine will be port scanned, vuln probed, brute
forced, blindly hit with ancient "1 shot" exploits (e.g.
?file=../../../etc/passwd ). This is how the Internet works.

Another lesson is: _never_ run any unsecured webserver/service on the public
Internet, _never ever_ , not even for debugging, period. Don't listen
0.0.0.0:80 if you have just installed your PHP management system, don't reset
your forgotten MySQL password by disabling privilege checking before turning
off networking first, if you just installed a new VPS with root password
123456 in a morning, don't wait until afternoon, change it immediately, etc.

The reason is exact the opposite, not because of "hackers" but those stupid
worms. Ordinary life is boring: if you run a webserver with password 123456
(e.g. for debugging an issue on a disposable server - just for 20 minutes, you
think, then you forgot it), you won't (or unlikely) to see someone hacking
into your system, but it's a certainty that one of those stupid worms/viruses
would infect your machine within hours, sometimes it's as quick as having your
lunch. And it probably won't do much damage, but you would spend your time to
reinstall the system again...

~~~
lrem
Wasn't it just a couple minutes at the hight of Windows XP?

~~~
yjftsjthsd-h
Oh yeah, the "infected before you can install patches" time

~~~
segfaultbuserr
Thanks for the memory. Your comment reminded me about the suggestion _" You
must disconnect your machine from the Internet before/during the installation
of patches."_ from 2000s computer magazines.

------
HocusLocus
I opened up port 23 telnet and had it connect immediately to a playable
Crowther & Woods' original adventure,

YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING. AROUND
YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE BUILDING AND DOWN A GULLY.

In a year and a half I had logged over a million probes. No humans at all. I
would have known because they would have typed something to do with the game
or tried to play it. So I must conclude no one is checking the logs of the
worms either.

~~~
liability
In a strange way, it's a bit sad that there aren't more humans out there.

~~~
orf
Of course there are. They are all over the place. But the internet is _vast_
so you narrow down your targets using tools before you waste even a second of
your time connecting manually.

If he had his telnet service return something that looked interesting (and no,
not Crowther & Woods interesting), then he'd have a lot of people connecting.

------
IanGabes
My team and i run some different honeypot solutions, and we base a lot of them
off of cowrie. As pointed out by previous comments, most interactions are not
so interesting, except for the fact that many cowrie based honeypots imitating
IoT devices have their attackers running a simple script that pulls down a
number of second stage binaries, for a variety of cpu architectures.

One downside to running software like cowrie is that generally speaking
crawlers like shodan will be able to figure out that you are running a
honeypot, and will have you fingerprinted in a hurry.

A better strategy for increasing the cost of an attack is actually
implementing something i read about on HN called a ssh tarpit, where one can
"hang" an incoming ssh connection indefinitely. A lot of the attacks on
honeypots are automated, so instead of having a 3 second attack, one can waste
the attackers time for about 30s to 1m on average as these scripts have very
generous timeouts (and sometimes no timeouts at all).

~~~
tastroder
> ssh tarpit

Interesting, like slow request attacks in reverse? Is that actually useful for
something? It seems like that would just needlessly burn resources on your
end. The majority of attacks on my instance seem to have come from other
infected routers/devices/etc. that pretty much perform these attacks for free.

~~~
IanGabes
Depends on your goals! If you are defending a network, increasing the cost of
attack is something we actively try to optimize for. It costs me next to
nothing to hold a socket open and send a keep alive every 15 seconds or so, in
addition to the extra threat intel from the initial connection.

You might have a point, and maybe i should try to turn these subjective
feelings into harder metrics in terms of cost, but we have figured at this
point it has a net good. If we slow the scanning down by a magnitude, in my
opinion its a good thing!

~~~
bediger4000
Is there any research on what proportion of services (ssh, telnet, FTP,
WordPress) have to be honey pots or tar pits for it to make a difference?

I've been running honey pots or tar pits for years out of a belief that anyone
who can has an ethical duty to do so, to slow down the attacks on those who
can't.

~~~
IanGabes
I havent seen anything terribly relevant, most of the thesis projects i have
seen are more interested in creating realistic and believable honeypots for
specific protocols, eg RDP.

In my experience, honeypots and tarpits are not the same sort of thing, and
fufill different goals. Tarpits get you more utilitarian good, honeypots get
you more representative threat intel.

~~~
bediger4000
Thank you, and good points. From the view point of increasing the utility of
scanning for weak-password ssh ports, a honeypot and a tarpit are both
entities the human setting up the scanning would like to avoid. I think that
ultimately a human looking for easily-guessed ssh or telnet or whatever
passwords would want to avoid tarpits and honeypots equally. They might have
to code differently for a tarpit than a honeypot, but the goal would be to
detect and avoid instances of both things. What proportion of "something to
detect and avoid" would cause a scanner to be less than profitable, or just
give up?

To illustrate: I've been giving the people that staff robocaller's "service
centers" a hard time for years. I believe that my phone number is in some of
their systems as a "bad actor" \- I've occasionally heard an audible,
computer-generated voice telling the "service rep" that this is a known
troublesome number. They also occasionally hang up on me a sentence in to the
script. I usually tell them I'm Edward Snowden, but you can call me Ed. That
gets a hangup maybe 5% of the time. So giving them a hard time wastes their
resources enough that at least a few boiler room/"service centers" put effort
towards avoiding me, and the few others like me. What proportion of resource-
wasters would it take to make them quit?

------
CliffStoll
Wish that this were available 33 years ago...

~~~
HocusLocus
Mr. Cuckoo's Egg, I presume? Well met!!! I really enjoyed your sleuthing tale
in the age of modemy Compuserve and Telenet-with-an-e ... which I also did
some exploring on. The telephone NPA plus a couple digits was an explorer's
dream. Hope you are doing well in this whacky 21st century.

------
cordite
any examples of replay logs on asciinema or even youtube?

Just curious about what these look like

~~~
mergy
I played back a friend banging on my cowrie setup a while back. Here you go.

[https://vimeo.com/345068825/86f8c8f97e](https://vimeo.com/345068825/86f8c8f97e)

------
iforgotpassword
I want to give this a try. Years ago I stumbled upon a similar project written
in python which I don't remember the name of, but something about its
handshake must have been fishy as most clients disconnected again right away
without trying to authenticate. (The initial version string sent by the server
looked fine but I wasn't motivated enough to dig any further.)

~~~
spydum
You might be thinking of kippo? Honeypots are fun to think about and toy with
- I just never have any idea what to do with the logs and data?

~~~
achillean
The major use case for them nowadays is to help filter out the noise in your
alerts. See for example a company such as GreyNoise
([https://www.greynoise.io](https://www.greynoise.io)) to help companies focus
on real attacks and not just background noise/ automated attacks.

~~~
yjftsjthsd-h
Alternatively, run on your internal network and alert on every attempt....

