900220 - Set a default maximum allowed number of FTP connections per server

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: FTP, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

It may be a good idea to restrict the number of allowed FTP connections by default, similar to the way we restrict the number of allowed HTTP connections per server to 6, as per the default value of network.http.max-persistent-connections-per-server.

Currently we do not set a default maximum allowed number of FTP connections per server.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Code used in demonstration at Black Hat 2013

At Black Hat 2013, Jeremiah Grossman and Matt Johansen gave a talk titled "Million Browser Botnet", and as part of the talk, pointed out that while Firefox limited the number of http connections per server to 6, the number of ftp connections was not, and they used the code in this photo to demonstrate that they could overwhelm an Apache server.

This was not the main focus of the talk, but we should still consider restricting this number.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

CC'ing some networking folks for their thoughts.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I'm not a networking person if I can avoid it. But I hear dougt knows something about ftp... ;)

Comment 4

[Daniel Veditz [:dveditz]]

We don't really want a separate pool for each protocol we support, we want a general limit on connections of any type to avoid swamping hosts.

Comment 5

[Doug Turner (:dougt)]

dveditz, this isn't the same bug. I am a lot more concerned about making that sort of change.

Comment 6

[Doug Turner (:dougt)]

jason, I am not convinced on some arbitrary limited for the number of total socket connections per host.  But restricting ftp feels like a win.  Thoughts?

Comment 7

[Patrick McManus [:mcmanus]]

can anyone think of a non ftp protocol?

WS has a mechanism.. rtc iirc too, we killed gopher.. and sysapps have chrome privs.

http limits are pretty complicated (6 is really not a hard limit).. I'd like to see a separate patch for .. as WS vs http sharding shows often this is something not necessarily meant to be shared logic.

Comment 8

[Doug Turner (:dougt)]

all of the webrtc stuff. no idea how that would interact with some global limit.

i'd much rather restrict ftp, than try to figure out the *right* global limit across ff.

Comment 9

[Patrick McManus [:mcmanus]]

in comment 7 I meant to say I'd like to see a patch specific to ftp (as would dougt).. the limits of a soft keyboard defeated my clarity.

Comment 10

[Jason Duell]

I agree an FTP-specific patch is probably a good idea.

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Not sure if we should track this, nominating anyway. It'll be good to have a quick follow-up post-Black Hat, and also nice to have this in the next ESR, version 24.

Comment 12

[Alex Keybl [:akeybl]]

non-critical security fixes shouldn't end up on the tracking list. please re-nominate if this gets a sec-high/sec-critical rating.

Comment 13

[Patrick McManus [:mcmanus]]

We are in a period where ftp is clearly deprecated and in general, making changes to the code is riskier than letting it ride unless there is a patch and reviewer available to make a good judgment about it. So I'm going to wontfix ftp bugs related to enhancements, interop errors, etc.. We will be better off putting our energy into including a different js based ftp stack.