Opened 14 years ago

Closed 13 years ago

#279 closed enhancement (wontfix)

DoS protection support for spiffy

Reported by: Mario Domenech Goulart Owned by: sjamaan
Priority: not urgent at all Milestone:
Component: extensions Version: 4.5.x
Keywords: spiffy, dos Cc:
Estimated difficulty:


Some tips Brian Mastenbrook gave on #scheme. I'm pasting them here in case we want a DoS protection module for spiffy someday. Here are the relevant parts:

<chandler> mario-goulart: I think a sufficient approach would be to
	   (a) limit the number of active connections, (b) kill
	   connections according to a least-recently-transmitted
	   policy, and (c) set a timeout for connections in the
	   receiving headers phase, and another timeout for sending

<mario-goulart> chandler: wouldn't (c) mess up with things like comet
		and long live connection intentionally requested to
		avoid the multiple requests overhead?

<chandler> If the server is blocking before responding to a request,
           don't time out.

<chandler> But the client shouldn't be allowed to connect or start
	   sending a request and then block indefinitely before
	   finishing sending headers.

<chandler> mario-goulart: Furthermore, if the server has data to send
	   to the client but hasn't actually been able to send it for
	   several seconds, the connection should be terminated as

Change History (4)

comment:1 Changed 14 years ago by felix winkelmann

Milestone: 4.6.0

comment:2 Changed 13 years ago by sjamaan

Owner: set to sjamaan
Status: newassigned

comment:3 Changed 13 years ago by sjamaan

Are there good ways to test something like this? How do you know what is sane behaviour? If someone initiates a DDoS attack, this shouldn't start semi-randomly killing existing connections of real users.

comment:4 Changed 13 years ago by sjamaan

Resolution: wontfix
Status: assignedclosed

Closing this since I have absolutely no clue how to fix this. If you have a concrete test or patch, please reopen.

Note: See TracTickets for help on using tickets.