Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implement interval jitter #109

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

rarescosma
Copy link

@rarescosma rarescosma commented May 9, 2024

Adds a new argument called interval_jitter, expressed as a percentage number (range 0-100) that has the following effects:

If 0 => no effect.

If >0 => choose a random integer in the [-(interval * jitter / 100), +(interval * jitter / 100)] range and use it as an offset for the sleep interval.

So for example, if our interval is 1000ms and we pick interval_jitter=20, then the sleep values will be randomized in the range [800ms, 1200ms]

This has been a requested feature in the original implementation, and is useful to twarth SSH scanners that have tarpit-detecting logic.

Link: skeeto/endlessh#71

Adds a new argument called 'interval_jitter', expressed as a percentage
number (range 0-100) that has the following effects:

If 0 => no effect.

If >0 => choose a random integer in the
[-(interval * jitter / 100), +(interval * jitter / 100)] range

and add use it as an offset for the sleep interval.

So for example, if our interval is 1000ms and we pick
interval_jitter=20, then the sleep values will be
in the range [800ms, 1200ms]

This has been a requested feature in the original implementation,
and is useful to twarth SSH scanners that have tarpit-detecting logic.

Link: skeeto/endlessh#71
@shizunge
Copy link
Owner

Is there a proof this is the correct way to resolve the problem?

@shizunge
Copy link
Owner

And is it a problem we need to resolve?

@rarescosma
Copy link
Author

Hey, thanks for checking in - I guess we could collect a few weeks of data with the feature enabled/disabled and compare, but it would hardly qualify as a controlled experiment.

If you read the original issue they're claiming clients disconnect after exactly two intervals without the random delay.

Are we collecting data about number of intervals as well, or is everything quantified in time?

As for the "need to solve" - I can't comment. The velocity of this project is low enough to be OK to maintain a fork for the foreseeable future, so I'll leave the decision to you :)

@shizunge
Copy link
Owner

shizunge commented Oct 2, 2024

If you read the skeeto/endlessh#71 they're claiming clients disconnect after exactly two intervals without the random delay.

There is no saying that the clients keep connection more than two interval with a random delay.

The two interval is quite easy to explain. endlessh can only report the connection time as a multiple of the interval, and it is a round-up. If the connection dies before the first tick, endlessh (sorry I don't remember exactly) probably won't report it. If the connection dies between the first tick and the 2nd tick, it reports 2x interval. E.g. assume the interval is 5 seconds, endlessh will reports 10 seconds for all connections between 5 seconds and 10 seconds, including 6s, 7s, 8s , 9s, we will never know the exact connection time.

Actually, before hitting the 2nd tick, the client won't know that the server periodically sends garbage, as the client never see the 2nd response. The client knows that it receives data at 5s, but before 10s, the connection is already broken, the client won't not know whether it will receive data at 10s. I don't think adding a jitter improve this.

And I believe attacker won't spend time to develop and deploy an advanced tarpit-detecting logic. If you were an attacker, would you spend time to study whether a server periodically sends garbage data and, and take the corresponding actions? Even so, it should after the 2nd tick, or you won't know the interval. We should see the connection keeps at least 3x interval. I think they won't waste resource on this. If I were the attacker, I will kill the connection with a simple timeout.

@shizunge
Copy link
Owner

shizunge commented Oct 2, 2024

If you can find the exact connection time, it definitely helps for a better report.

@rarescosma
Copy link
Author

Hey 👋🏼

I could run some tests with or without the patch applied and check if it has any real impact on the mean trapped time. Problem is I introduced a bunch of other patches on my fork to deal with the slow grafana dashboard..

It's fine to close this for now, I'll just stay in sync with upstream.

~R

@shizunge
Copy link
Owner

shizunge commented Oct 2, 2024

Logically I don't think jitter solves that endlessh sees the clients disconnect at the 2nd tick.

From skeeto/endlessh#71

delay@10000 = [email protected]
delay@12543 = [email protected]

I believe that means

client saw the 1st tick @10000 = [email protected]
client saw the 1st tick @12543 = [email protected]

Now with jitter, what would you fill into the blank ?

client sees the 1st tick @9000 = disconnect@_______
client sees the 1st tick @11000 = disconnect@_______

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants