| Anonymous | Login | 2024-11-21 21:27 EST |  |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |||
| 0000879 | PacketFence | performance | public | 2009-12-14 12:43 | 2011-01-26 15:38 | |||
| Reporter | obilodeau | |||||||
| Assigned To | obilodeau | |||||||
| Priority | high | Severity | major | Reproducibility | N/A | |||
| Status | closed | Resolution | fixed | |||||
| Platform | OS | OS Version | ||||||
| Product Version | ||||||||
| Target Version | Fixed in Version | 1.9.1 | ||||||
| Summary | 0000879: captive portal "denial of service" | |||||||
| Description | Right now, we sometimes experience non-maliciously intended denial of service on our captive portal. This mostly happens because a client connected to an open wifi and (upon successful connection) all of his apps started to reach for various web services and such. iPod touch are especially good at that. We need to be able to expect ~ 300 hits for a 2 minute period. Let's try to resist to that. Several things were suggested: - optimize the path of redir.cgi removing all unneeded stuff to get there (single captive portal hit takes a few seconds, probably suboptimal) - apache rate limiting based on IP address: http://dominia.org/djao/limitipconn2.html [^] - apache whitelist / blacklist of useragents (ensure that only human initiated connections reach the portal) - iptables tcp rate limiting There might be other alternatives also. A post to the -users mailing list would be interesting. | |||||||
| Tags | No tags attached. | |||||||
| fixed in git revision | ||||||||
| fixed in mtn revision | 2e045af575176e6fbb263037a3dea64bd8cabbb9 | |||||||
| Attached Files | ||||||||
 Relationships |
||||||
|
||||||
 Relationships |
|
Notes |
|
|
(0001449) obilodeau (reporter) 2009-12-17 14:21 |
another option: use mod_perl instead of cgi handler |
|
(0001460) obilodeau (reporter) 2010-02-01 13:14 edited on: 2010-02-01 15:16 |
Today I looked at: - mod_evasive: http://www.zdziarski.com/projects/mod_evasive/ [^] (found by Ludo) - mod_security only: http://blog.cherouvim.com/simple-dos-protection-with-mod_security/ [^] - mod_security + httpd-guardian + blacklist: http://apache-tools.cvs.sourceforge.net/viewvc/apache-tools/apache-tools/ [^] mod_evasive seems really simple to install but there is a limitation that it's only hosting state within a single child so it might not do the job correctly. See http://permalink.gmane.org/gmane.comp.apache.mod-security.user/5335 [^] |
|
(0001544) obilodeau (reporter) 2010-05-05 09:35 |
Another option is to take the opposite approach at User-Agent blocking: blacklist all agents except the known big desktop browsers. Chances are that a given user will carry at least one of firefox, chrome, opera, safari or IE. Yes, maybe they use Flock or Links but when they have no network access, they'll try the other ones. |
|
(0001681) obilodeau (reporter) 2010-09-21 14:43 |
For the purpose of this ticket, the 'denial of service' aspect has been considered a performance problem. The current fix doesn't consider malicious DoS but more misconfigured clients, softwares who we putting a lot of pressure on the portal. The 'fix' can be divided in two: - use of mod_perl to get more performance out of the current cgi scripts Our current portal scripts were used as CGI which means that apache started a perl interpreter, compiled the code and handed over the execution to a new process for each request. Moving under mod_perl where the perl interpreter is part of the apache thread is a huge gain right there. This is phase 1 of several phases where we integrate better with mod_perl's philosophy. - some rewrite rules to return HTML Forbidden (status 403) to non-browser clients (disabled by default) A lot of the requests are done by misbehaving clients (ex: iPhone Apps trying very hard to fetch stuff from the web spawning thousands of web requests over a few hours). Since we redirect 'every' request to the captive portal these clients hurt. By having easy to implement rules that cut all that crap from reaching our captive portal, we can get improved performance. See 0001072 for more info on this. The work has been done in a feature branch: org.packetfence.feature.captive-portal-performance |
|
(0001682) obilodeau (reporter) 2010-09-21 15:02 |
fix is now in branch 1.9 (feature branch merged) |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2009-12-14 12:43 | obilodeau | New Issue | |
| 2009-12-14 12:43 | obilodeau | Status | new => assigned |
| 2009-12-14 12:43 | obilodeau | Assigned To | => obilodeau |
| 2009-12-14 12:44 | obilodeau | Description Updated | |
| 2009-12-17 14:21 | obilodeau | Note Added: 0001449 | |
| 2010-02-01 13:14 | obilodeau | Note Added: 0001460 | |
| 2010-02-01 15:16 | obilodeau | Note Edited: 0001460 | |
| 2010-05-05 09:35 | obilodeau | Note Added: 0001544 | |
| 2010-05-05 09:36 | obilodeau | Category | future => 1.9.x |
| 2010-09-21 14:14 | obilodeau | Category | 1.9.x => performance |
| 2010-09-21 14:43 | obilodeau | Note Added: 0001681 | |
| 2010-09-21 14:43 | obilodeau | Relationship added | related to 0001072 |
| 2010-09-21 15:02 | obilodeau | mtn revision | => 2e045af575176e6fbb263037a3dea64bd8cabbb9 |
| 2010-09-21 15:02 | obilodeau | Note Added: 0001682 | |
| 2010-09-21 15:02 | obilodeau | Status | assigned => resolved |
| 2010-09-21 15:02 | obilodeau | Fixed in Version | => 1.9.1 |
| 2010-09-21 15:02 | obilodeau | Resolution | open => fixed |
| 2011-01-26 15:38 | obilodeau | Status | resolved => closed |
|
Issue History |
| Copyright © 2000 - 2012 MantisBT Group |
 |