You could potentially deny legitimate users access. I limit so many
connections per second per source IP. If I knew I were getting a ton of
traffic from a University I would have to adjust it accordingly.
The setting in pfsense is Maximum new connections / per second(s) -
that's per IP. My site I wouldn't say is pegged with University traffic
sharing the same IP. I'm just giving you examples and tailor to your
needs. If you get a bunch of traffic from a shared IP, obviously, this
would not be the best way to go. I try to mitigate using rate limiting.
I don't like to wait for the traffic to pass to Apache and have to
configure a module to fix it. Apache should be handling web requests,
not having to deal with tons of traffic (bruteforce/DoS). I try to
handle that stuff before it even gets passed to Apache.
From the Cisco side you could implement ACL's and rate limiting.
http://www.debian-administration.org/articles/187
On 08/02/2013 01:49 AM, Grant wrote:
Truthfully, I've always limited connections from the source IP via a
firewall before the traffic is even passed to apache.
Do you do this only when under DoS attack or all the time?
Won't you potentially prevent legitimate users from making a single
connection if they're connecting with a shared IP from a university
campus (for example)?
How is this accomplished with iptables?
- Grant
Two different things come to mind. Kingcope found an Apache
byterange
vulnerability and the PoC code he wrote for it exhausts the
resources on
a
server running Apache. Only 1 instance of his perl script had to
be ran.
LOIC is another that could possible DoS your server from one
source. What
IP address was hitting your box when this happened?
I'd rather not post the IP if that's OK. I did notice my
access_log
entries were out of chronological order for the IP address in
question. Does that indicate a Slowloris attack? Maybe it's just
the
result of the server bogging down in response to so many requests
in a
short amount of time.
So I'm sure I understand, a regular browser or unsophisticated
script
shouldn't be able to interrupt apache service by simply requesting
a
large number of pages in a short amount of time? If not, how does
apache prevent that from happening?
- Grant
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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
