[Koha] F5 Attacks

Fri Oct 28 20:23:57 NZDT 2016

Hi! 

If this is actually related to Zebra I wonder if the problem will persist when the switch to Elasticsearch is made? And if so: is there anything that could be done about it now while work is done on Elastic anyway? It’s always easier to get it right from the start. 

If I understand the description of the problem correctly what we would want is a way to drop previous queries when the search engine is flooded with rerequest of queries from the same session id? Dropping the traffic in the firewall seems like the best solution since it’s as upstream as possible for a attacker with intent. It seems possible to implement something in JS as well but that will only protect from clumsy refreshers without intent. 

IF we are feeling helpful towards inexperienced system librarians who forgot or misconfigured the firewall
AND it’s really only Zebra that can’t handle the load while apache and Koha are doing fine
AND there is already some part of Koha or Zebra that’s already aware of active queries and their session ids 
AND there is no caching in Zebra to try first activate 
AND it’s not a passing thing with Elastic coming
AND someone have the funds or time and knowledge to fix it
THEN it seems reasonable to see if we could also drop traffic inside Koha to decrease the load

Kind regards
Viktor Sarge

Senior regional library development officer
Regional development council of Halland, Sweden

26 okt 2016 kl. 12:28 skrev Pedro Amorim <pjamorim91 at gmail.com>:

> 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