On 12/21/2011 09:44 PM, Gary Poster wrote:
> Public bug reported:
>
> We had an incident in which codehosting connections spiked because of
> one person connecting 800+ times to our SSH servers, and then not
> authenticating and never letting go of the connection.
> https://wiki.canonical.com/IncidentReports/2011-12-15-LP-codehosting-
> connection-spike
>
> Reviewing the logs by eye, it seems that connections are all
> authenticated within less than half a second. If lp-serve (or bzr?)
> were configured to release unauthenticated connections after a
> relatively short time (1 second might not be conservative enough, but 10
> seconds seems like plenty) then this particular problem might not have
> happened.
>
> Acting on this should of course include a more careful log analysis to
> determine maximum authentication times.
>
> I'm marking this critical based on discussion on the team leads call,
> but it's worth noting that this only really helps with people making
> honest mistakes. if this were a malicious DoS, this would be very
> inadequate.
lp-serve isn't started until the SSH authentication succeeds. The ssh
server code (which runs lp-serve) is all in lib/lp/codehosting/sshserver/.
On 12/21/2011 09:44 PM, Gary Poster wrote: /wiki.canonical .com/IncidentRe ports/2011- 12-15-LP- codehosting- codehosting/ sshserver/ .
> Public bug reported:
>
> We had an incident in which codehosting connections spiked because of
> one person connecting 800+ times to our SSH servers, and then not
> authenticating and never letting go of the connection.
> https:/
> connection-spike
>
> Reviewing the logs by eye, it seems that connections are all
> authenticated within less than half a second. If lp-serve (or bzr?)
> were configured to release unauthenticated connections after a
> relatively short time (1 second might not be conservative enough, but 10
> seconds seems like plenty) then this particular problem might not have
> happened.
>
> Acting on this should of course include a more careful log analysis to
> determine maximum authentication times.
>
> I'm marking this critical based on discussion on the team leads call,
> but it's worth noting that this only really helps with people making
> honest mistakes. if this were a malicious DoS, this would be very
> inadequate.
lp-serve isn't started until the SSH authentication succeeds. The ssh
server code (which runs lp-serve) is all in lib/lp/
Cheers,
Jelmer