-
Notifications
You must be signed in to change notification settings - Fork 31
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
base: main
Are you sure you want to change the base?
Conversation
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
Is there a proof this is the correct way to resolve the problem? |
And is it a problem we need to resolve? |
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 :) |
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. |
If you can find the exact connection time, it definitely helps for a better report. |
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 |
Logically I don't think jitter solves that endlessh sees the clients disconnect at the 2nd tick. From skeeto/endlessh#71
I believe that means
Now with jitter, what would you fill into the blank ?
|
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 pickinterval_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