At 01:29 PM 10/26/2016 +0000, Marcel de Rooy wrote:
Content-Language: nl-NL Content-Type: multipart/alternative;
boundary="_000_VI1PR0501MB2591816F386E0F9B467A10E1CEAB0VI1PR0501MB2591_"
More something for the developers list?
What Philippe here says, makes some sense to me. We could at least try to do something; what and how is another thing ;)
F5 DDoS can/should be mitigated at firewall -- see e.g. <https://debian-administration.org/article/187/Using_iptables_to_rate-limit_incoming_connections> -- and while I somewhat agree that it would be "nice" for Koha to consider it, I see this more as a "server admin/setup" that has existed for many years now. Best -- Paul
---------- Van: Koha <koha-bounces@lists.katipo.co.nz> namens Philippe Blouin <philippe.blouin@inlibro.com> Verzonden: woensdag 26 oktober 2016 14:52 Aan: Koha list Onderwerp: Re: [Koha] F5 Attacks
I disagree. If Koha is offered out of the box, and we take time to fix security issues, then it's normal for users to expect "basic" attacks to be taken care of.
More so, blocking IP is not a possibility if genuine users are involved using a station from within the library.
I'm not saying you're wrong that it's mostly sysadmin work and not Koha, but it doesn't mean nothing can be done. From the apache's threads, I found nothing useful (mostly derisive comments). But we could at least talk about it.
What about having a javascript preventing refresh on the page withing 5 sec of each other? Needs to be done in a way that the refresh doesn't restart the timer.
What about having the OPAC search be code where the refresh will basically send nothing ? The checkbox are filled, the request is sent to the backend, but the frontend keeps nothing... I'm just smoking here, but I'm trying to induce some brainstorming in this interesting topic.
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com <<mailto:philippe.blouin@inLibro.com>mailto:philippe.blouin@inLibro.com>
inLibro | pour esprit libre | <http://www.inLibro.com>www.inLibro.com <http://www.inLibro.com> On 10/26/2016 07:13 AM, Jonathan Druart wrote:
Hi, I don't think this can/must be fixed on Koha side. It's a sysadmin duty to take care of that. I would take a look at fail2ban to parse the web server access logs. But make sure not to block your X librarians using the same ip ;)
On Wed, 26 Oct 2016 at 12:28 Pedro Amorim <pjamorim91@gmail.com> wrote:
I have tested this and the stress caused on the server is very severe. It seems that for every request, a new zebra process is created and the server will only respond when the last one is finished. This ofc will result in time outs and eventually a crash in the server.
This is a major critical issue IMO, anyone who knows about this has the power to deny the service of any Koha online without using any additional hacking/attacking software.
The Koha I'm working on right now - still in development - is accessed behind a proxy server, and I will attempt to solve the problem through that, by limiting the requests from the same origin with very little time between them. Still, even if I'm successful with this, the problem will still lie in Koha.
Anyone with some sort of insight is very welcome.
Pedro Amorim
2016-10-26 8:24 GMT+00:00 clint.deckard <clint.deckard@frontiers.co.nz>:
I have had this issue appear today. I have attempted to set up mod_evasive for apache but it doesn't seem to have solved the problem. I would really appreciate some advice. Clint.
rfblanchard wrote:
Assume a basic opac search:
imit=branch%3A349
This would take about 10 seconds to return the first time.
Assume the user refreshes the results using f5 and keep there finger there a moment to long (3s): This would kill my server for about 1 minute.
Any attacker could easily make the server unresponsive indefinitely by simply holding f5 on an opac search.
Any recommendations on how to deal with this problem?
here is a sample from top:
Tasks: 313 total, 3 running, 309 sleeping, 0 stopped, 1 zombie %Cpu(s): 93.7 us, 5.2 sy, 0.0 ni, 1.0 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16465036 total, 1532492 used, 14932544 free, 63180 buffers KiB Swap: 8526844 total, 0 used, 8526844 free. 505124 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7027 peischo+ 20 0 416164 162924 12756 S 58.8 1.0 0:26.43 /usr/share/koha 7009 peischo+ 20 0 416800 163524 12756 S 56.5 1.0 0:33.77 /usr/share/koha 7444 peischo+ 20 0 129832 15216 5900 R 37.2 0.1 0:01.12 zebrasrv 7445 peischo+ 20 0 129832 15216 5900 R 35.6 0.1 0:01.07 zebrasrv 1151 mysql 20 0 886564 181096 10808 S 8.6 1.1 1:27.57 mysqld 7435 koha 20 0 25892 3272 2528 R 0.3 0.0 0:00.03 top 1 root 20 0 176144 5044 3096 S 0.0 0.0 0:01.43 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
-- View this message in context: <http://koha.1045719.n5.nabble>http://koha.1045719.n5.nabble. com/F5-Attacks-tp5906098.html Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list <http://koha-community.org>http://koha-community.org Koha@lists.katipo.co.nz
<https://lists.katipo.co.nz/mailman/listinfo/koha>https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list <http://koha-community.org>http://koha-community.org Koha@lists.katipo.co.nz
<https://lists.katipo.co.nz/mailman/listinfo/koha>https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list <http://koha-community.org>http://koha-community.org Koha@lists.katipo.co.nz
<https://lists.katipo.co.nz/mailman/listinfo/koha>https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list <http://koha-community.org>http://koha-community.org Koha@lists.katipo.co.nz
<https://lists.katipo.co.nz/mailman/listinfo/koha>https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list <http://koha-community.org>http://koha-community.org Koha@lists.katipo.co.nz <https://lists.katipo.co.nz/mailman/listinfo/koha>https://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>
Hi, Please forward to koha-general since I didn't subscribed to that one yet. We had the same issue at Lyon 3, we dealt with them by adding some code in the OpacuserJS syspref to disable page reloading until search result completes. More documentation here : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15855 My colleague Olivier Crouzet have improved the code since : // multi soumission Bouton Valider $("#searchsubmit").click(function(){ $(this).text('en cours...').prop('disabled',true); $("#searchform").submit(); }); // multi soumission Enter var submitted; $('#translControl1').bind('keyup',function() { submitted = false; }); $('#translControl1').bind('keydown',function(event) { code = event.keyCode||event.which||event.charCode||event.char||0; if(code == 13) { if (submitted == false) { submitted = true; $('#searchform').submit(); $("#searchsubmit").text('en cours...'); } else { event.preventDefault(); event.returnValue = false; return false; } } }); Maybe this could be integrated into core koha. All the best, Arthur Le 26/10/2016 à 16:28, Paul A a écrit :
At 01:29 PM 10/26/2016 +0000, Marcel de Rooy wrote:
Content-Language: nl-NL Content-Type: multipart/alternative; boundary="_000_VI1PR0501MB2591816F386E0F9B467A10E1CEAB0VI1PR0501MB2591_"
More something for the developers list?
What Philippe here says, makes some sense to me. We could at least try to do something; what and how is another thing ;)
F5 DDoS can/should be mitigated at firewall -- see e.g. <https://debian-administration.org/article/187/Using_iptables_to_rate-limit_incoming_connections> -- and while I somewhat agree that it would be "nice" for Koha to consider it, I see this more as a "server admin/setup" that has existed for many years now.
Best -- Paul
------------------------------------------------------------------------ *Van:* Koha <koha-bounces@lists.katipo.co.nz> namens Philippe Blouin <philippe.blouin@inlibro.com> *Verzonden:* woensdag 26 oktober 2016 14:52 *Aan:* Koha list *Onderwerp:* Re: [Koha] F5 Attacks
I disagree. If Koha is offered out of the box, and we take time to fix security issues, then it's normal for users to expect "basic" attacks to be taken care of.
More so, blocking IP is not a possibility if genuine users are involved using a station from within the library.
I'm not saying you're wrong that it's mostly sysadmin work and not Koha, but it doesn't mean nothing can be done. From the apache's threads, I found nothing useful (mostly derisive comments). But we could at least talk about it.
What about having a javascript preventing refresh on the page withing 5 sec of each other? Needs to be done in a way that the refresh doesn't restart the timer.
What about having the OPAC search be code where the refresh will basically send nothing ? The checkbox are filled, the request is sent to the backend, but the frontend keeps nothing... I'm just smoking here, but I'm trying to induce some brainstorming in this interesting topic.
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com>
Hi, I don't think this can/must be fixed on Koha side. It's a sysadmin duty to take care of that. I would take a look at fail2ban to parse the web server access logs. But make sure not to block your X librarians using the same ip ;)
On Wed, 26 Oct 2016 at 12:28 Pedro Amorim <pjamorim91@gmail.com> wrote:
I have tested this and the stress caused on the server is very severe. It seems that for every request, a new zebra process is created and
will only respond when the last one is finished. This ofc will result in time outs and eventually a crash in the server.
This is a major critical issue IMO, anyone who knows about this has the power to deny the service of any Koha online without using any additional hacking/attacking software.
The Koha I'm working on right now - still in development - is accessed behind a proxy server, and I will attempt to solve the problem through that, by limiting the requests from the same origin with very
inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> <http://www.inLibro.com <http://www.inlibro.com/>> On 10/26/2016 07:13 AM, Jonathan Druart wrote: the server little time
between them. Still, even if I'm successful with this, the problem will still lie in Koha.
Anyone with some sort of insight is very welcome.
Pedro Amorim
2016-10-26 8:24 GMT+00:00 clint.deckard <clint.deckard@frontiers.co.nz>:
I have had this issue appear today. I have attempted to set up mod_evasive for apache but it doesn't seem to have solved the problem. I would really appreciate some advice. Clint.
rfblanchard wrote:
Assume a basic opac search: http://..../cgi-bin/koha/opac-search.pl?q=dog&branch_group_l imit=branch%3A349
This would take about 10 seconds to return the first time.
Assume the user refreshes the results using f5 and keep there finger there a moment to long (3s): This would kill my server for about 1 minute.
Any attacker could easily make the server unresponsive indefinitely by simply holding f5 on an opac search.
Any recommendations on how to deal with this problem?
here is a sample from top:
Tasks: 313 total, 3 running, 309 sleeping, 0 stopped, 1 zombie %Cpu(s): 93.7 us, 5.2 sy, 0.0 ni, 1.0 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16465036 total, 1532492 used, 14932544 free, 63180 buffers KiB Swap: 8526844 total, 0 used, 8526844 free. 505124 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7027 peischo+ 20 0 416164 162924 12756 S 58.8 1.0 0:26.43 /usr/share/koha 7009 peischo+ 20 0 416800 163524 12756 S 56.5 1.0 0:33.77 /usr/share/koha 7444 peischo+ 20 0 129832 15216 5900 R 37.2 0.1 0:01.12 zebrasrv 7445 peischo+ 20 0 129832 15216 5900 R 35.6 0.1 0:01.07 zebrasrv 1151 mysql 20 0 886564 181096 10808 S 8.6 1.1 1:27.57 mysqld 7435 koha 20 0 25892 3272 2528 R 0.3 0.0 0:00.03 top 1 root 20 0 176144 5044 3096 S 0.0 0.0 0:01.43 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
-- View this message in context: http://koha.1045719.n5.nabble. com/F5-Attacks-tp5906098.html Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com <http://navalmarinearchive.com/>> and <http://UltraMarine.ca <http://ultramarine.ca/>>
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Arthur SUZUKI Service informatique des bibliothèques BIBLIOTHÈQUES UNIVERSITAIRES Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 – 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 16 | http://bu.univ-lyon3.fr L'Université Jean Moulin est membre fondateur de l'Université de Lyon
comment/thought/question: this code will prevent any F5 by mistake, but an attacker who WANT to F5 will just have to prevent javascript from being executed and "problem fixed" [for him] ? Le 26/10/2016 à 17:29, SUZUKI Arthur a écrit :
Hi,
Please forward to koha-general since I didn't subscribed to that one yet.
We had the same issue at Lyon 3, we dealt with them by adding some code in the OpacuserJS syspref to disable page reloading until search result completes.
More documentation here : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15855
My colleague Olivier Crouzet have improved the code since :
// multi soumission Bouton Valider $("#searchsubmit").click(function(){ $(this).text('en cours...').prop('disabled',true); $("#searchform").submit(); }); // multi soumission Enter var submitted; $('#translControl1').bind('keyup',function() { submitted = false; }); $('#translControl1').bind('keydown',function(event) { code = event.keyCode||event.which||event.charCode||event.char||0; if(code == 13) { if (submitted == false) { submitted = true; $('#searchform').submit(); $("#searchsubmit").text('en cours...'); } else { event.preventDefault(); event.returnValue = false; return false; } } });
Maybe this could be integrated into core koha. All the best, Arthur
Le 26/10/2016 à 16:28, Paul A a écrit :
At 01:29 PM 10/26/2016 +0000, Marcel de Rooy wrote:
Content-Language: nl-NL Content-Type: multipart/alternative; boundary="_000_VI1PR0501MB2591816F386E0F9B467A10E1CEAB0VI1PR0501MB2591_"
More something for the developers list?
What Philippe here says, makes some sense to me. We could at least try to do something; what and how is another thing ;)
F5 DDoS can/should be mitigated at firewall -- see e.g. <https://debian-administration.org/article/187/Using_iptables_to_rate-limit_incoming_connections> -- and while I somewhat agree that it would be "nice" for Koha to consider it, I see this more as a "server admin/setup" that has existed for many years now.
Best -- Paul
------------------------------------------------------------------------ *Van:* Koha <koha-bounces@lists.katipo.co.nz> namens Philippe Blouin <philippe.blouin@inlibro.com> *Verzonden:* woensdag 26 oktober 2016 14:52 *Aan:* Koha list *Onderwerp:* Re: [Koha] F5 Attacks
I disagree. If Koha is offered out of the box, and we take time to fix security issues, then it's normal for users to expect "basic" attacks to be taken care of.
More so, blocking IP is not a possibility if genuine users are involved using a station from within the library.
I'm not saying you're wrong that it's mostly sysadmin work and not Koha, but it doesn't mean nothing can be done. From the apache's threads, I found nothing useful (mostly derisive comments). But we could at least talk about it.
What about having a javascript preventing refresh on the page withing 5 sec of each other? Needs to be done in a way that the refresh doesn't restart the timer.
What about having the OPAC search be code where the refresh will basically send nothing ? The checkbox are filled, the request is sent to the backend, but the frontend keeps nothing... I'm just smoking here, but I'm trying to induce some brainstorming in this interesting topic.
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com>
Hi, I don't think this can/must be fixed on Koha side. It's a sysadmin duty to take care of that. I would take a look at fail2ban to parse the web server access logs. But make sure not to block your X librarians using the same ip ;)
On Wed, 26 Oct 2016 at 12:28 Pedro Amorim <pjamorim91@gmail.com> wrote:
I have tested this and the stress caused on the server is very severe. It seems that for every request, a new zebra process is created and
will only respond when the last one is finished. This ofc will result in time outs and eventually a crash in the server.
This is a major critical issue IMO, anyone who knows about this has the power to deny the service of any Koha online without using any additional hacking/attacking software.
The Koha I'm working on right now - still in development - is accessed behind a proxy server, and I will attempt to solve the problem
that, by limiting the requests from the same origin with very
between them. Still, even if I'm successful with this, the
inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> <http://www.inLibro.com <http://www.inlibro.com/>> On 10/26/2016 07:13 AM, Jonathan Druart wrote: the server through little time problem will
still lie in Koha.
Anyone with some sort of insight is very welcome.
Pedro Amorim
2016-10-26 8:24 GMT+00:00 clint.deckard <clint.deckard@frontiers.co.nz>:
I have had this issue appear today. I have attempted to set up mod_evasive for apache but it doesn't seem to have solved the problem. I would really appreciate some advice. Clint.
rfblanchard wrote:
> Assume a basic opac search: > http://..../cgi-bin/koha/opac-search.pl?q=dog&branch_group_l > imit=branch%3A349 > > This would take about 10 seconds to return the first time. > > Assume the user refreshes the results using f5 and keep there finger > there a > moment to long (3s): > This would kill my server for about 1 minute. > > Any attacker could easily make the server unresponsive indefinitely by > simply holding f5 on an opac search. > > Any recommendations on how to deal with this problem? > > here is a sample from top: > > Tasks: 313 total, 3 running, 309 sleeping, 0 stopped, 1 zombie > %Cpu(s): 93.7 us, 5.2 sy, 0.0 ni, 1.0 id, 0.2 wa, 0.0 hi, 0.0 si, > 0.0 > st > KiB Mem: 16465036 total, 1532492 used, 14932544 free, 63180 buffers > KiB Swap: 8526844 total, 0 used, 8526844 free. 505124 cached > Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > COMMAND > 7027 peischo+ 20 0 416164 162924 12756 S 58.8 1.0 0:26.43 > /usr/share/koha > 7009 peischo+ 20 0 416800 163524 12756 S 56.5 1.0 0:33.77 > /usr/share/koha > 7444 peischo+ 20 0 129832 15216 5900 R 37.2 0.1 0:01.12 > zebrasrv > 7445 peischo+ 20 0 129832 15216 5900 R 35.6 0.1 0:01.07 > zebrasrv > 1151 mysql 20 0 886564 181096 10808 S 8.6 1.1 1:27.57 mysqld > 7435 koha 20 0 25892 3272 2528 R 0.3 0.0 0:00.03 top > 1 root 20 0 176144 5044 3096 S 0.0 0.0 0:01.43 > systemd > 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 > kthreadd > > > > -- > View this message in context: http://koha.1045719.n5.nabble. > com/F5-Attacks-tp5906098.html > Sent from the Koha-general mailing list archive at Nabble.com. > _______________________________________________ > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com <http://navalmarinearchive.com/>> and <http://UltraMarine.ca <http://ultramarine.ca/>>
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
-- Arthur SUZUKI Service informatique des bibliothèques BIBLIOTHÈQUES UNIVERSITAIRES Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 – 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 16 |http://bu.univ-lyon3.fr L'Université Jean Moulin est membre fondateur de l'Université de Lyon
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
On 28 October 2016 at 20:52, Paul Poulain <paul.poulain@biblibre.com> wrote:
comment/thought/question: this code will prevent any F5 by mistake, but an attacker who WANT to F5 will just have to prevent javascript from being executed and "problem fixed" [for him] ?
No one doing a legitimate attack is going to be using a browser. They'll just fire up curl-loader or siege on any of the hundreds of tools and hit the url multiple times that way. So trapping it for the mistake ones is a good start. The rest really does boil down to sysadmin tasks. Even if we got Koha to be the fastest thing in the world, you could still swamp it. Tuning your apache server to only be able to answer to as many requests as you can manage is the key. Out of the box, it will do 150 concurrent, I doubt many people have the RAM to handle 150 concurrent requests, tune that down to something realistic. That way an attack will still cause a DOS, but it wont OOM the machine. So as soon as the requests stop, it will continue. Chris
participants (4)
-
Chris Cormack -
Paul A -
Paul Poulain -
SUZUKI Arthur