3 ms·
But the bots can easily detect these, cant they? As long as there is a timeout on socket read, this shouldn't waste that much of the scanners time. Or am I mis
by daghamm 3y ago
But the bots can easily detect these, cant they? As long as there is a timeout on socket read, this shouldn't waste that much of the scanners time.
Or am I misunderstanding this?
- c0wb0yc0d3r 3y agoYes a bot can, and sophisticated bots do. At the same time it's much easier to write code that just died the bare minimum. Imagine you're a bot herder, if your bot net consists of stolen CPU cycles what difference does it make if your bots are slowed down. It doesn't cost you money.
- throw10920 3y ago> if your bot net consists of stolen CPU cycles what difference does it make if your bots are slowed down. It doesn't cost you money. This is wrong. It does cost you money - either directly, because you paid money to use someone else's botnet, or as an opportunity cost, in that you can't use your bots on as many targets.
- LysPJ 3y agoEndlessh periodically sends data so the read timeout won't trigger. Specifically, it draws out the crypto negotiation stage indefinitely by exploiting a feature of the SSH protocol. (Of course, the bot author could detect that behaviour too.) There's more info from the author of Endlessh: https://nullprogram.com/blog/2019/03/22/ https://nullprogram.com/blog/2019/03/22/
- gnfargbl 3y agoYou're understanding perfectly. The way this works is that it sends a slow drip of junk before the SSH version banner string. A scanner running at any real scale is going to have an overall timeout beyond which it doesn't bother waiting any longer for the banner string. This is going to very slightly irritate some of the extremely low-level actors. Is setting up a tool to do that a good use of time? If you want to effectively deter attackers using a sand-trap approach, you need to find some kind of task with asymmetric cost in your favour. This isn't that.
- eddd-ddde 3y agoWhat is a good example of assymetrical cost in your favour?