Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Endlessh: An SSH Tarpit

nullprogram.com

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Endlessh: An SSH Tarpit

#72

Post by aboutruby »

xoa wrote: post #35

Neat little project to needle some of the botters a bit (though I assume they'll all evolve to recognize this fairly quickly). I'd echo tyingq's comment below though: Any tarpit has the potential to piss someone off. I'd run it on a sacrificial server with no obvious way to tie back to who is running it. Yeah, just speculating but at least from what I've seen in the past if you successfully tarpit some script kiddie…

Realistically if you do a massive scan you have to handle all kinds of behaviors and this would be a debugging point basically ("oh my script is stuck, let's add a timeout").

The thing is most people will not see the trap as malicious but as a "misconfiguration" on their end or the other person's end (network or ssh in this case).

I see your point but then I never heard of honeypots getting some kind of "revenge" for instance.

Re: Endlessh: An SSH Tarpit

#74

Post by naveen99 »

devy wrote: post #45

On a different note, I love this other tool he wrote: Enchive https://nullprogram.com/blog/2017/03/12/

Nice ! Reminds me of this: https://bitcointalk.org/index.php?topic=196378.0 using bitcoin keys for encryption in addition to handling money. https://github.com/jackjack-jj/jeeq

Re: Endlessh: An SSH Tarpit

#75

Post by koolba »

simias wrote: post #52
Jach wrote: post #47

Earlier quoted context omitted.

Not bitcoin but forcing a proof-of-work scheme has been proposed as an anti-DoS measure before: http://www.csc.kth.se/utbildning/kth/kurser/DD143X/dkand12/G...

The original hashcash algorithm was meant to quench email spam which is not completely unrelated. But in this case I think the parent was proposing tricking the attacker into computing a PoW without realizing it, which sounds pretty tricky.

Just need a protocol that allows for server initiated key renegotiation with PBKDF. Then you trick the client into repeatedly calculating some new key.

Re: Endlessh: An SSH Tarpit

#76

Post by ianai »

btown wrote: post #70
imglorp wrote: post #41

Earlier quoted context omitted.

Good advice, being ready for a revenge DDOS, but I suspect most of these SSH hunters are busy business people who have a quota of zombie hosts to fill for whatever mining or spamming they're up to. DDOSing doesn't pay like those things do.

Even sophisticated/organized hackers have free time, and if someone "messed with them" and caused them to need to push a hotfix at 6pm on a Friday because their cluster got stuck on your tarpit, you can bet they'll give the tarpit operator some of their attention. Woe to you if they happen to find something that's not patched.

Turn it around. How would hackers adapt if nearly every host responded on ssh the same way? Maybe it’d be behavior worthy of being in openssh or elsewhere. Don’t make it cheap to cheat. This might not be the holy grail, but it’s a good avenue.

Re: Endlessh: An SSH Tarpit

#78

Post by [deleted] »

spc476 wrote: post #49
tyingq wrote: post #9

Earlier quoted context omitted.

Any tarpit has the potential to piss someone off. I'd run it on a sacrificial server with no obvious way to tie back to who is running it.

You can always tie it to the organization who is running it, by the simple fact of looking at the IP address that is "acting slow". Years ago when I was playing network admin for a company, I set up a tarpit system which ran for a few years. In that time we never encountered one pissed off person in person (or on the Internet).

[deleted]

Re: Endlessh: An SSH Tarpit

#79

Post by wahern »

maga_2020 wrote: post #66

very interesting, and useful (including newbies like me who do not appreciate the complexities and dangers of having internet-accessible IP address). I wonder if security-oriented OSs like openBSD could offer something like this out of the box. So that an admin can just say enable_tarpits='yes', and it would automatically enable tarpits like this for all the currently installed packages (with some default ports).

OpenBSD ships spamd, a greylister which also tarpits.

PF has the max-src-conn-rate state tracking option which is commonly use to blackhole scanners:

  pass in on egress proto tcp to port ssh keep state \
    (max-src-conn-rate 10/60, overload )
  block quick from
Rather than blocking you could instead redirect new connections to a tar pit by replacing the block rule with something like

  pass in on egress proto tcp from  to port ssh \
    divert-to 127.0.0.1 port 2222
where your SSH tar pit service listens on 127.0.0.1:2222. This is basically the reverse of how spamd works, which diverts all inbound SMTP connections not in the table to spamd. When spamd's greylisting rules are satisfied it adds the sender's IP to .

IPv6 poses a problem for selective tar pitting, though. Realistically you need to tar pit at least /64 subnets, but even then it's not difficult to get your hands on a /48. But if you lumped /48s together you'd have a huge false positive problem. Also, AFAIU PF's state tracking capability can't track subnets, anyhow.

Post reply on HN