• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

SSH client always using port 10000

fossette

Active Member

Thanks: 30
Messages: 119

#26
Testing a random number generator is very simple. No need to use the whole TCP stack, but it's the utmost importance to find out exactly which routine is being used. Testing the wrong routine won't bring any good.

What I do is simply brute force the algorithm. That is, pick a seed at the beginning, then repetitively call the routine to generate random numbers and log them in memory. What we are looking for is when the pattern repeat itself. The longer it is, the better, so it's more difficult to predict. Note that this sequence is the result of the original seed, and the random mathematical function algorithm.

If the log shows the same value that repeats itself, then the mathematical function is less than par. This is why weak random number generator algorithms require that the seed be regularly refreshed by the timeclock (or some other external event like a key pressed on the keyboard) for the repeat pattern or stuck sequence to be less predictable. For telecommunication, encryption, or a casino slot machine, this is a vulnerability.

No random number generator is perfect. This is why we call them Pseudo Random Number Generators.

Dominique.
 

Murph

Well-Known Member

Thanks: 176
Messages: 297

#27
You really need to look at more than just when it repeats. Ideally you want to be checking for a reasonably flat distribution across the range; possibly via the standard deviation, or just counting the results into buckets and confirming that all buckets are receiving a similar number of data points.
 

ronaldlees

Aspiring Daemon

Thanks: 262
Messages: 664

#29
You really need to look at more than just when it repeats. Ideally you want to be checking for a reasonably flat distribution across the range; possibly via the standard deviation, or just counting the results into buckets and confirming that all buckets are receiving a similar number of data points.
Right, because that validates the strength of the algorithm and its entropy, rather than a datum from a point in time (or several).
 

fossette

Active Member

Thanks: 30
Messages: 119

#30
Ideally you want to be checking for a reasonably flat distribution across the range
Murph, with that assumption, one could expect to win the lottery just by picking the same combination ticket week after week. Lol!!!
Dominique.
 

Murph

Well-Known Member

Thanks: 176
Messages: 297

#31
That clarifies the port picking quite a bit. But, by those terms, my machines would have always been in "random" mode.
DNS activity could, perhaps, be generating frequent spikes of port allocations. I'd need to do some digging into source to confirm it, but I think BIND will allocate new random ports (via the OS allocator) for each query that it generates. Unbound is probably similar. With several levels of delegation, and corresponding DNSSEC queries, repeating truncated queries via TCP, and querying both IPv4 and IPv6 addresses, resolving a single hostname to address can easily involve quite a few DNS queries.
 

ronaldlees

Aspiring Daemon

Thanks: 262
Messages: 664

#32
Murph, with that assumption, one could expect to win the lottery just by picking the same combination ticket week after week. Lol!!!
Dominique.
If you didn't have a flat distribution, then indeed you could expect more value from your carefully chosen lottery ticket!
 

Murph

Well-Known Member

Thanks: 176
Messages: 297

#33
Murph, with that assumption, one could expect to win the lottery just by picking the same combination ticket week after week. Lol!!!
Dominique.
Not really. If you only look for repeats, i++; would pass the test until integer overflow. Verifying that the distribution is reasonably flat is essential. Lottery numbers should be a flat distribution, otherwise you could look at past statistics and improve your chances by picking numbers in the hotter part of the distribution. Lotteries rely on the very large number of possible results, combined with a very flat distribution.
 

ronaldlees

Aspiring Daemon

Thanks: 262
Messages: 664

#34
DNS activity could, perhaps, be generating frequent spikes of port allocations. I'd need to do some digging into source to confirm it, but I think BIND will allocate new random ports (via the OS allocator) for each query that it generates. Unbound is probably similar. With several levels of delegation, and corresponding DNSSEC queries, repeating truncated queries via TCP, and querying both IPv4 and IPv6 addresses, resolving a single hostname to address can easily involve quite a few DNS queries.
Maybe I'll keep one machine around just to see if I can duplicate this scenario. Nothing seems amiss today. The "mode switching" described in the ip() man page means much more involvement within the allocator than simple use of a PRNG - so we shouldn't necessarily blame the latter or blame anything OS related. I'm still leaning towards the stray bit leaking through my firewall as the origin of this thing. It's definitely not normal.

Update: It's two weeks later, and still there are no further signs of any ports being stuck to #10000. Whatever it happened to be, it is/was an infrequent thing. Glad for that. One other curious item that I didn't mention: The ISP DNS here was excruciatingly slow for about three days in the referenced time frame. It was so slow that I eventually changed the config on everything so it would get DNS from the outside (ISP was averaging over 2 seconds per query, and as long as 5 seconds).
 
Last edited:
Top