[Koha] F5 Attacks

Thu Oct 27 06:07:13 NZDT 2016

Koha isn't offered 'out of the box'... there is extensive setup required 
and the most basic portion(a webserver) is a requirement, and that would 
be the responsibility of the server's administrator, not a function of a 
Koha developer.

On 10/26/2016 5:52 AM, Philippe Blouin wrote:
> 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 at inLibro.com <mailto:philippe.blouin at inLibro.com>
>
> inLibro | pour esprit libre | 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 at 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 at 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 at lists.katipo.co.nz
>>>>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>>>>
>>>> _______________________________________________
>>>> Koha mailing list  http://koha-community.org
>>>> Koha at lists.katipo.co.nz
>>>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>>>
>>> _______________________________________________
>>> Koha mailing list  http://koha-community.org
>>> Koha at lists.katipo.co.nz
>>> https://lists.katipo.co.nz/mailman/listinfo/koha
>>>
>> _______________________________________________
>> Koha mailing list  http://koha-community.org
>> Koha at lists.katipo.co.nz
>> https://lists.katipo.co.nz/mailman/listinfo/koha
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha