12 ms·
Endlessh: An SSH Tarpit
- GNOMES 8y agoI must not be understanding something... Does this still allow whitelisted machines to connect, or is this just a troll thing to do?
- vermilingua 8y agoPresumably legitimate access would be on port 22, whereas only bots would hit 2222.
- velcrovan 8y agoalmost, but backwards. The bots all know port 22. Only you know which random other port is the real ssh port.
- sm4rk0 8y agoAnd the second guess would be port 2222, so don't use it for a real ssh server!
- simias 8y agoI suspect that bots that randomly scan IP addresses for vulnerable hosts don't bother trying anything besides 22. I've been running my sshd on port 622 for a long time and I never get fishy connections (while I'd get at least one a week on port 22). On the other hand a dedicated attacker who really wants to pwn your server will just scan all the ports and figure out what is listening and where. At this point you're better off implementing some form of port knocking if that's a cause for concern. That being said, running sshd on port 2222 is probably not a good idea because it's not a privileged port.
- aaronmdjones 8y agoEvery machine I control has sshd listening on port 222 for that last reason.
- cozzyd 8y agoI use 12345 as my SSH port (not really)
- lucb1e 8y agoThe idea is that you run your real SSH server somewhere else, like on a different port. If you scroll down a little (like, skim over the article) you see some example code that is basically the entire server. It's just a few lines of code, there is no real SSH implementation in this thing. And that's the whole idea: it can't really be hacked and it thwarts attackers.
- velcrovan 8y agoThis will not allow any machine to connect on the port it's listening on. The idea is that you set Endlessh on your server's port 22 (standard SSH port), then configure "actual" SSH to listen on a different (randomly selected) port. You connect to that port to get stuff done. Bots that troll for connections on port 22 will get stuck on port 22.
- LinuxBender 8y agoI could see a few ways to use this. For me, what makes sense for my public sftp servers is to put this on a higher port, then use ipset lists to dynamically add bots to a DNAT rule and send them to this instead of the proper sshd. i.e. you get 2 chances to authenticate correctly, then I put you in this hamster wheel for a day. Hamster wheels and intermittent fasting are all the rage these days.
- JohnFen 8y agoI was thinking of something similar, but in reverse -- turn this into part tarpit, part honeypot. I was thinking I could take the IP address of anyone who hangs out in the tarpit for longer than a minute or so and automatically add it to my firewall's blacklist.
- 1996 8y agoI used to run an honeypot. For fun and giggles, I also kept the user and password they tried to see if any of my systems was at risk
- linuxdude314 8y agoYes, it's just a troll thing.
- LinuxBender 8y agoI like this! It's tiny, simple, yet effective. 2019-03-22T19:54:06.303Z ACCEPT host=::ffff:196.52.43.xx port=50327 fd=4 n=1/4096 2019-03-22T19:54:38.838Z CLOSE host=::ffff:196.52.43.xx port=50327 fd=4 time=32.535 bytes=199 2019-03-22T19:57:12.008Z ACCEPT host=::ffff:141.98.81.xx port=53646 fd=4 n=1/4096 2019-03-22T19:57:21.118Z CLOSE host=::ffff:141.98.81.xx port=53646 fd=4 time=9.110 bytes=30 The 141 bot never stays longer than 5 seconds. I'm guessing they are using 'expect' and waiting 5 seconds for a particular string. The only thing missing is setting some glibc hardening options RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH No 0 8 ./endlessh I modified one line in the Makefile CFLAGS = -std=c99 -Wall -Wextra -Wno-missing-field-initializers -D_FORTIFY_SOURCE=2 -O2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -ftrapv -s -g -Wl,-z,relro,-z,now -Wl,-z,noexecstack -pipe -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -fstack-clash-protection --param ssp-buffer-size=4 -fPIE -pie -m64 -mtune=generic It's better now RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 3 4 ./endlessh
- velcrovan 8y agoYou should submit a pull request!
- LinuxBender 8y agoThe thought crossed my mind, but I am lazy and the proper change would be to write a configure script that checks for the availability of the various hardening options. There are decent examples in the Tor source code.
- LukeShu 8y agoThanks for introducing me to `checksec`!
- 8y ago
- iknowordidthat 8y agoIs a poll necessary? Simple timer to count to 10. Go over all open sockets, drain incoming, pump junk. Handle accept. Repeat.
- JohnFen 8y agoThis is awesome. Like the author, I run my real SSH server on a nonstandard port. Unlike the author, I run nothing on the standard SSH port. I think that I'll start running this there.
- ams6110 8y agoI'm not sure I like this. How secure is it? Anything you put on port 22 is going to be attacked relentlessly. I think I'd rather have OpenSSH handling those attacks than some tarpit program that may or may not have been subjected to the audits and the trial-by-fire that OpenSSH has.
- nemo1618 8y agoA program like this has vastly less attack surface than a full SSH protocol implementation. In particular, it doesn't support the part of the SSH protocol that allows executing commands on a remote host. So the only way this will be less secure than OpenSSH is if there's some memory unsafety or a leak of some kind.
- throwaway2048 8y agoalmost all of the SSH protocol isn't exposed until you authenticate, and in the vast majority of setups that means you get a shell to execute commands with anyways, so while still important, the key problems are with pre-auth security.
- nemo1618 8y agoSure, but "isn't exposed" is very different from "that functionality is physically not present in this executable."
- tyingq 8y agoAny 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.
- sverige 8y agoWhy worry about pissing off the kind of person who scans for open SSH ports for no apparent legitimate reason? Are you concerned that the Chinese are going to try even harder to hack your machine, like they're not already doing everything they can to break in?
- allanrbo 8y agoEwww, sticky service! Hilarious! :-D
- ahazred8ta 8y agoConsistency is a virtue. 'Tacky' is a consistency. O:-)
- EvanAnderson 8y agoI haven't used it in years, but Tom Liston's "Labrea" tarpit is an interesting take on this concept: https://github.com/Hirato/LaBrea https://github.com/Hirato/LaBrea It listens in your unused IP space and both tar-pits scanners and creates actionable intelligence about scans against your hosts.
- lucb1e 8y agoI love the fake arp responses, that's a brilliant way so you can run this on any machine (doesn't have to be a router) and not worry about managing new hosts (no black/whitelist to manage of which IPs are unused).
- penagwin 8y agoI'm definitely not going to try this because it sounds like an easy way to get in trouble, but would this work on a host like DO/linode/vultr, etc? Again, this seems really easy to detect
- LinuxBender 8y agoYes be super careful with Labrea on VPS providers and dedicated server providers. They tend to get upset if you are trying to pick up IP's. In most cases it won't even work on KVM hosts. I've used Labrea on unused address space to make ARIN/RIPE happy back in the day and that was harmless, as entire /16's and /17's were unused. They used to nag about nothing in the /16's being pingable, so Labrea made it all 100% pingable
- damir 8y agoAwesome! Love reading hacks like these.
- deleted 8y ago[deleted]
- blastbeat 8y agoAssuming you run a legit SSH server on port A and an SSH tarpit on port B. What hinders an attacker to connect to port A an B at the same time? What is the advantage having an attacker connected for weeks on port B?
- AlexCoventry 8y agoPerhaps this could be useful if you ran it on a vast number of ports. Just running it on the one doesn't seem to make an attacker's life much more difficult.
- penagwin 8y agoRunning it on just 22 should be pretty effective on it's own. Large scale port scanning is semi-difficult, as you'll get banned really fast, even if you're just scanning an uncommon port. To pull it off, you'll either need your host to be okay with the abuse complaints (that are usually automated) or have a botnet/proxy list. However even then there's 65535 different ports (not to mention almost 4.3 billion ipv4 addresses), and you'll likely can firewalled off pretty fast. So instead of scanning 65535 ports, scanning just 22 usually works anyway, as few people change their ssh ports (and those that do are more likely to have other security measures in place)
- LinuxBender 8y agoThat would be easy to do with an iptables DNAT rule. You can take a large set of ports and forward them to this daemon. iptables -t nat -I PREROUTING -m tcp -p tcp --dport 1:79 -j DNAT --to-destination x.x.x.x:2222 iptables -t nat -I PREROUTING -m tcp -p tcp --dport 81:442 -j DNAT --to-destination x.x.x.x:2222 ...etc Just remember to open those same ports in the INPUT rules. If you get DDoS, then also create NOTRACK target rules in the raw table to avoid hitting the conntrack table.
- fxfan 8y agoYou truly sound like a bender. Is there a quick start to iptables somewhere? Is iptables the defacto network tool? And can one prevent ddos using iptables?
- 0db532a0 8y agoiptables is a firewall/NAT interface. nftables is newer and easier to learn, at least to me. You might want to get into that instead of iptables.
- mehrdadn 8y agoThis is great but what happens when clients start watching out for strings they don't expect? Seems like only a matter of time.
- stcredzero 8y agoCould the return strings be generated by a Deep Learning powered fuzzer?
- viraptor 8y agoWhat are you trying to achieve?
- stcredzero 8y agoStickier tar.
- mises 8y agoHe's trying to crash a script-kiddy's box with fuzzing. It's a fun thought, though I'm not sure it's practical as you'd only get a few tries. Fuzzing is typically an approach of throwing it the wall and seeing what sticks; if your deep learning found something that crashed most ssh clients that would just be a zero-day.
- acct1771 8y agoIt doesn't have to crash them all...just the one it's working on.
- stcredzero 8y agoMaybe deep learning technobabble that might convince a script kiddie into "researching" what was coming back?
- craftyguy 8y agoThe return strings could be anything, provided they fall under the max length in the spec. DP fuzz it all you want.
- egorfine 8y agoBeautiful!
- xoa 8y agoNeat 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 and they notice the IP their scan got stuck on there is some potential to move from "one of a billion random lowest common denominator bulk scan targets" to "paid attention to specifically some minimal amount", which is a genuinely different scenario. Even if all that amounts to is a relatively low volume revenge DDOS pointed at you for a bit it's still more of a disruption then if the auto scan had just moved on without seeing anything of note in the first place. This looks like fun on some systems, but on anything real I'm inclined to just stick to cutting down on log spam via single packet auth or a port knocker or the like. The old outrun-the-hiker-not-the-bear aphorism fits a lot of cases, just something to keep in mind before implementing something like this if you aren't directly experimenting with more active reactions. Conversely as a research project I'm now actually curious what sort of extra attention even something like this could attract. Maybe these days everyone would just adapt and move on instead and the above is all obsolete?
- imglorp 8y agoGood 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.
- spydum 8y agoExactly.. figuring out why one host out of 500000 you probed got hung up is generally not a wise use of a bot operators time. Now if enough of these tar pits start showing up you can be sure they will quick patch a time limit to defeat stalls like this.
- btown 8y agoEven 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.
- cryptonector 8y agoMassively async ssh scanners won't care. They'll time out and move on without being held up at all.
- cosmin800 8y agoI can confirm that most ssh scanning attempts/scanners I've seen implement timeouts and will usually move on after 30 seconds or so.
- HashBasher 8y agoI wonder if you could make the attacker crunch out some shah-256 and you can profit by mining Bitcoin.
- Jach 8y agoNot 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/Group5Mikael/final/Jonatan_Landsberg_and_Anton_Lundqvist.pdf http://www.csc.kth.se/utbildning/kth/kurser/DD143X/dkand12/G...
- simias 8y agoThe 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.
- koolba 8y agoJust need a protocol that allows for server initiated key renegotiation with PBKDF. Then you trick the client into repeatedly calculating some new key.
- SamPatt 8y agoYou can no longer profit mining Bitcoin with a CPU or GPU. ASICs are needed.
- ufmace 8y agoThe idea of this sort of scheme is that it's perfectly profitable if you aren't paying for the CPU and the power it uses.
- devy 8y agoOn a different note, I love this other tool he wrote: Enchive https://nullprogram.com/blog/2017/03/12/ https://nullprogram.com/blog/2017/03/12/
- naveen99 8y agoNice ! Reminds me of this: https://bitcointalk.org/index.php?topic=196378.0 https://bitcointalk.org/index.php?topic=196378.0 using bitcoin keys for encryption in addition to handling money. https://github.com/jackjack-jj/jeeq https://github.com/jackjack-jj/jeeq
- z3t4 8y agoI can recommend setting up a server and do extensive logging. Then watch hackers as they attempt to break in. I had a server hacked last week and today i read the logs to figure out how they did. From first discovery, trying to figure out what system they're on, to gaining a shell, and figure out how to execute stuff, gaining network access. It was better then watching an actual movie. And a humbling experience. But also entertaining, watching the struggle against my hardening and even stumbled on a bug, feeling his/her frustration. And the wow feeling when they finally got a shell.
- acct1771 8y agoPostmortem on your blog?
- oedmarap 8y agoNeat little tool! Since switching to Teleport I haven't had OpenSSH listening publicly for a while, just reverse proxies. Still, I'll prob spin up a small server for this to observe the patterns and IP locations. Also, don't think that posting this blog article on March 22 didn't go unnoticed :)
- ape4 8y agoWould be nice if it logged something fail2ban could act on. So it could ban the IP-address - after bugging the bot for a couple hours.
- maga_2020 8y agovery 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).
- wahern 8y agoOpenBSD 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 <scanners>) block quick from <scanners> 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 <scanners> 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 <nospamd> table to spamd. When spamd's greylisting rules are satisfied it adds the sender's IP to <nospamd>. 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.
- deleted 8y ago[deleted]
- fxfan 8y agoI want my tarpit to endlessly repeat "your mother is a whore" in Chinese
- dang 8y agoPlease don't do this here.
- userbinator 8y agoThis is the Internet equivalent of keeping phone scammers on the line by not just refusing to hang up, but actively interacting with them until they hang up (search YouTube for "tech support scammer trolling" for some entertainment...) That said, I'm a little confused even after reading the linked RFC paragraph; it claims "The primary use of this feature is to allow TCP-wrappers to display an error message before disconnecting." but I'm not familiar with that term and there are no other occurrences of the word "wrapper" in that document. Firefox and Chrome will spin on that server for hours before giving up. For a web browser, this behaviour makes a lot of sense: timeouts are usually based on "I've waited for X and haven't received anything", not "this connection is like collecting water from a dripping tap". As long as there is a slow but steady stream of content coming in, you wouldn't want to abort until the user gives up or an internal limit on the data collected is hit (which is probably what happened with the author's tests --- a quick search doesn't yield the maximum size of the response headers browsers will accept, but servers usually have a configurable limit of a few KB at most for the request headers alone.)
- schoen 8y agoTCP Wrappers was a popular access control mechanism in earlier decades: https://en.wikipedia.org/wiki/TCP_Wrappers https://en.wikipedia.org/wiki/TCP_Wrappers It does a number of things in userspace (with a simple minimalist code base) that people might nowadays more often do in a firewall.
- A2017U1 8y ago> actively interacting with them until they hang up The best stuff is automated. Lenny has been at it for years now. https://www.reddit.com/r/itslenny/comments/aylq20/lenny_qualifies_for_some_great_new_promotions_in/ https://www.reddit.com/r/itslenny/comments/aylq20/lenny_qual...
- tejtm 8y agoWhat a wonderful opportunity to rickroll ... to prolong detection time rot13 it or walk through all the ciphers you can get away with. cause we are never going to give you up ;)
- viraptor 8y agoIf you don't want to waste resources and run a separate service, you can do a very similar thing with just iptables. Look for the TARPIT target. > Captures and holds incoming TCP connections using no local per-connection resources. Connections are accepted, but immediately switched to the persist state (0 byte window), in which the remote side stops sending data and asks to continue every 60-240 seconds. Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes.
- craftyguy 8y agoI'm guessing this may not work, since OP's app sends every 10 seconds and seems to imply that there is some timeout associated with receiving data from the server, but not necessarily a timeout associated with receiving the correct 'SSH-' string needed to move on.
- pmc 8y agoSSH brute-force attacks still pose a significant risk. See our related paper on SSH auditing driven by attacker's attempts here https://pmcao.github.io/caudit/ https://pmcao.github.io/caudit/
- nullc 8y agoI found that disabling password authentication makes ssh probing mostly stop. Attackers that are smart enough to detect and avoid pubkey only hosts will probably easily adapt to this program.
- 0db532a0 8y agoWouldn’t cycling over the lines of an ASCII middle finger be more efficient and equally as useful as generating random strings? The middle finger would fit in a few cache lines at most.
- earthboundkid 8y agoI wrote one of these for HTTP: https://github.com/carlmjohnson/heffalump https://github.com/carlmjohnson/heffalump
- nullhead 8y agoSet this up on a server last night. In 20 hours I've got 75 connections. Took a capture of trying to connect to it from my laptop: https://www.cloudshark.org/captures/b64150b66908 https://www.cloudshark.org/captures/b64150b66908 IP addresses have been change to protect the innocent. This is from macOS but definitely seeing some different behavior from other clients.
- HocusLocus 8y agoI opened up port 22 once so that it connected (without crypto) and issued the phrase, 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. > and if they typed in something it would continue to play the game. After hundreds of thousands of automated SSH worm probes over several months, an actual human did connect and play the game for a few minutes! But even this triumph was short lived, they did not even play it to the end to see if something interesting might be unlocked (it would have been an invitation to contact my email address).
- silenceper 8y agotest