[Koha-devel] [Koha] F5 Attacks

Paul A paul.a at navalmarinearchive.com
Wed Oct 26 16:28:03 CEST 2016 

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 at lists.katipo.co.nz> namens Philippe Blouin 
><philippe.blouin at 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 at inLibro.com 
><<mailto:philippe.blouin at inLibro.com>mailto:philippe.blouin at 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 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>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>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 at 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 at 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 at 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 at 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 at 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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20161026/80910a88/attachment-0001.html>

More information about the Koha-devel mailing list