Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Closer telnet-brute integration with the brute library #1269
I'll start by listing what I think are the existing features of
For connection backoff, it seems like we could increase the connect timeout and allow the connection to die. This would reduce the number of threads again and slow down the rate of retry because threads that connect too quickly will be left waiting for longer. I admit I'm not quite sure of the exact behavior this is trying to work around, so there may be a better approach, and it may be a call to sleep as you used before. Maybe if you describe the behavior of telnet daemons that this addresses I'd have a better idea.
Connection pooling is a really neat idea, and I completely missed it in my initial attempt. I'll have to look at it again and see if it's something we could build into brute.lua, since I think other services would also benefit. As I understand it, this is to avoid closing and restarting the TCP connection if the service allows multiple authentication attempts in a single connection.
referenced this issue
Jul 12, 2018
Well, I spotted an interesting detail in
To make it even more awkward, if the
We would have to verify that all the existing scripts can tolerate a single Driver instance having its
With this new setup, the Driver would be able to keep track of its own internal state and use the
I am guessing that this could turn out to be a very simple replacement with
The reason behind the current code is that in some cases I have observed that the daemon got unresponsive, i.e. behaving way outside of its typical latency, and, interestingly enough, the reaction was a RST, not a timeout. Think of it as if the daemon gets periodically restarted. I assume that in such cases the retry with increasing back-off time is the way to go, while timeout would specifically not work.
I have not implemented a true connection pooling in the traditional sense in that threads check in and check out connections, specifically to preserve the socket-thread affinity. In
Back when I was coding
So, in my opinion, refactoring
One other feature that I have implemented is that the presence of TLS is tested only once. All threads then simply either do or do not request TLS, instead of invoking
Connection reuse does reduce the impact but not as greatly as one would hope. In my experience each telnet connection tends to be useful only for a small number of login attempts, before it gets closed on the server side.