Re: [Koha] F5 Attacks

2016-11-01 Thread Jonathan Druart
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

Re: [Koha] F5 Attacks

2016-10-28 Thread Viktor.Sarge
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

Re: [Koha] F5 Attacks

2016-10-27 Thread Jason Sherman
Just FYI, we run Koha behind the open source version of nginx, and it has lots of flexibility for rate-limiting by client ip and doing pretty sophisticated cache handling. On Thu, Oct 27, 2016 at 7:50 AM, Pedro Amorim wrote: > Hello all, > > As I said before, the Koha I'm

Re: [Koha] F5 Attacks

2016-10-27 Thread Pedro Amorim
Hello all, As I said before, the Koha I'm currently working on is behind a proxy server, namely HAProxy (http://www.haproxy.org/). My solution for this was adding the following lines in the frontend of my haproxy.cfg: # Table definition stick-table type ip size 100k expire 30s store

Re: [Koha] F5 Attacks

2016-10-26 Thread clint.deckard
Thank you to everyone who replied, I appreciate you taking the time. I understand that this is not a Koha specific problem, I understand the solution is a sys admin responsibility and I understand that there is probably not a 'one size fits all' solution given the many different system

Re: [Koha] F5 Attacks

2016-10-26 Thread Harry
Even though "sharing" is not obligatory, I had the impression that this is a somewhat "sharing community". If someone is willing he/she could share his solution-experience-howto or what ever. Probably this is the wrong place to ask for this kind of help ... Look into places like SHOREWALL

Re: [Koha] F5 Attacks

2016-10-26 Thread Huck
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.

Re: [Koha] F5 Attacks

2016-10-26 Thread Philippe Blouin
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

Re: [Koha] F5 Attacks

2016-10-26 Thread Jonathan Druart
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

Re: [Koha] F5 Attacks

2016-10-26 Thread Pedro Amorim
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

Re: [Koha] F5 Attacks

2016-10-26 Thread clint.deckard
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:

[Koha] F5 Attacks

2016-10-06 Thread rfblanchard
Assume a basic opac search: http:///cgi-bin/koha/opac-search.pl?q=dog_group_limit=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