[arthur.suzuki@univ-lyon3.fr: Re: [Koha-devel] F5 Attacks]

26 Oct 2016

      Here we go

Chris

----- Forwarded message from SUZUKI Arthur <arthur.suzuki@univ-lyon3.fr> -----

Date: Wed, 26 Oct 2016 17:29:12 +0200
From: SUZUKI Arthur <arthur.suzuki@univ-lyon3.fr>
To: koha-devel@lists.koha-community.org, CROUZET Olivier <olivier.crouzet@univ-lyon3.fr>
Subject: Re: [Koha-devel] [Koha] F5 Attacks
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

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>

        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@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:
        >>>> 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> and <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/

----- End forwarded message -----

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand

Chris Cormack

tags

participants (1)