Reading logs and spotting oddities

uniq compares each line with the one just before it and ignores the rest, so identical lines scattered through the file are counted separately. Sorting first brings them together. Leaving the sort out is the commonest mistake in this pattern because it fails quietly, handing back a wrong count rather than an error you would notice.

cut splits each line on the delimiter given by -d and keeps the field named by -f. In this log the fields are the timestamp, the user and the source, so field three is src=.... Reducing every line to just that value is what makes the later count a count per source rather than a count per line, which is the question you actually wanted answered.

The -n option tells sort to compare the leading number as a number rather than as text, so 6 ranks above 10 instead of below it. The -r option reverses the order, which puts the biggest count on top. Without -n the comparison would be alphabetical, and a count of 10 would sort before a count of 6, so the ranking would be wrong in a way that is easy to miss.

A run of failures from one source followed at once by a success is the shape a successful guess leaves behind. It is not proof, because a broken script or a forgotten saved password can produce the same pattern, so the log raises the question and you then check the account and the source before deciding anything. The burst itself only tells you where to look.