Return-Path: X-Original-To: apmail-httpd-users-archive@www.apache.org Delivered-To: apmail-httpd-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5E9E110433 for ; Tue, 30 Jul 2013 06:26:02 +0000 (UTC) Received: (qmail 38625 invoked by uid 500); 30 Jul 2013 06:25:56 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 38600 invoked by uid 500); 30 Jul 2013 06:25:55 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 38448 invoked by uid 99); 30 Jul 2013 06:25:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jul 2013 06:25:53 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of emailgrant@gmail.com designates 209.85.212.171 as permitted sender) Received: from [209.85.212.171] (HELO mail-wi0-f171.google.com) (209.85.212.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jul 2013 06:25:46 +0000 Received: by mail-wi0-f171.google.com with SMTP id hr7so2218736wib.16 for ; Mon, 29 Jul 2013 23:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8JKI1DoYrDbpJuZroWbdv/8qaAIFdtYznD1Ce3L/7lc=; b=B12PINlk4DiLdlHTKMrC4u26OITNLCx9gbrkYFDiofaZIegoMjjnMIZlx1Y0TquB1b KRzMOmEMfTfrXvbnjIq0a2GVeSasyLFl23vPVAayQGmoVBjZHERU7oAaeuoArTjVMwFQ 40sQ+wV5gmfhMThaRD6cEi3YB2bYFhCAps0Hza0qhcGbHyuf/8J5n/fqVCEbi2LSQO3G VBBxIPvMswO3VoDnVWheZkpLejEVnTbtkS68aZlFNN1rN+1s9qc+dMDkF1OWkmsmw+T5 m8hRo0tkOEtJLHNlJ6zDir89u2l+OWOpyZmaVlT/RFF8RhO/N8Gee8fBC2PO3rZqhH04 cgwg== MIME-Version: 1.0 X-Received: by 10.180.104.73 with SMTP id gc9mr11468wib.13.1375165526199; Mon, 29 Jul 2013 23:25:26 -0700 (PDT) Received: by 10.194.104.199 with HTTP; Mon, 29 Jul 2013 23:25:26 -0700 (PDT) In-Reply-To: <34f35ad7781b611ea484f0c2793a89ff@itsecuritypros.org> References: <346c265337d1832d580bf92db427ecc7@itsecuritypros.org> <34362e43108806639bfc26468eaaab2a@itsecuritypros.org> <34f35ad7781b611ea484f0c2793a89ff@itsecuritypros.org> Date: Mon, 29 Jul 2013 23:25:26 -0700 Message-ID: From: Grant To: users@httpd.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] Re: apache service interruption > You wouldn't keep a syn proxy rule enabled all the time; only under a DoS > attack. You could also implement ModSecurity. ModSecurity looks good and I think it works with nginx as well as apache. Is everyone who isn't running OSSEC HIDS or ModSecurity vulnerable to a single client requesting too many pages and interrupting the service? - Grant >>> Also, you should be able to limit simultaneous client connections with >>> your >>> firewall and pass the traffic in a syn proxy state. There are numerous >>> ways >>> to achieve this. >> >> >> Is that the best way to go besides OSSEC HIDS? I can imagine that >> sort of thing could cause problems. >> >> - Grant >> >> >>>> You can always compile from source ;) >>>> What version of Apache are you running? >>>> >>>> On 07/29/2013 02:59 AM, Grant wrote: >>>>>> >>>>>> >>>>>> Was it just an IP exhausting the apache service with too many >>>>>> connections? What do you see in the access logs? I use OSSEC HIDS on >>>>>> my >>>>>> apache servers to mitigate this. >>>>> >>>>> >>>>> >>>>> In the access log I see the same IP made many requests during the >>>>> service interruption and I think that exhausted the apache service. >>>>> It looks like there isn't a Gentoo ebuild for OSSEC HIDS. Is there >>>>> another way to prevent this sort of thing? >>>>> >>>>> - Grant >>>>> >>>>> >>>>>>>> My server has 4GB RAM and uses nginx as a reverse proxy to apache. A >>>>>>>> little while ago my website became inaccessible for about 30 >>>>>>>> minutes. >>>>>>>> I checked my munin graphs and it looks like apache processes spiked >>>>>>>> to >>>>>>>> about 29 during this time which is many times greater than usual. I >>>>>>>> have MaxClients at 30 and the error log verifies that MaxClients was >>>>>>>> not reached. The strange part is system disk latency shows a spike >>>>>>>> during the interruption which is only very slightly greater than >>>>>>>> other >>>>>>>> spikes which did not interrupt service. System CPU, memory, and >>>>>>>> swap >>>>>>>> usage don't show anything interesting at all. >>>>>>>> >>>>>>>> Does this make sense to anyone? Should I decrease MaxClients? >>>>>>>> >>>>>>>> - Grant >>>>>>> >>>>>>> >>>>>>> >>>>>>> I've looked over my access_log and I can see there is a particular IP >>>>>>> which was making many requests during the interruption. Since munin >>>>>>> does not show there was an excessive amount of memory or CPU usage, >>>>>>> lowering MaxClients won't help? >>>>>>> >>>>>>> - Grant --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org