Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #2180 > unrolled thread

Slowing/delaying connections when there are already many connections from that source IP

Back to article view | Back to comp.os.linux.networking

Contents

  Slowing/delaying connections when there are already many connections from that source IP Andrew Gideon <c182driver9@gideon.org> - 2013-05-29 18:56 +0000
    Re: Slowing/delaying connections when there are already many connections from that source IP Rick Jones <rick.jones2@hp.com> - 2013-05-29 22:38 +0000
      Re: Slowing/delaying connections when there are already many connections from that source IP Andrew Gideon <c182driver9@gideon.org> - 2013-05-30 13:04 +0000
    Re: Slowing/delaying connections when there are already many connections from that source IP aw@anhrefn.saar.de - 2013-05-30 00:21 +0200
    Re: Slowing/delaying connections when there are already many connections from that source IP Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-05-30 06:45 +0000
      Re: Slowing/delaying connections when there are already many connections from that source IP Andrew Gideon <c182driver9@gideon.org> - 2013-05-30 13:19 +0000
    Re: Slowing/delaying connections when there are already many connections from that source IP Jeff Long <long@ku.edu> - 2013-05-30 10:09 -0500
      Re: Slowing/delaying connections when there are already many connections from that source IP Andrew Gideon <c182driver9@gideon.org> - 2013-06-04 16:34 +0000

#2180 — Slowing/delaying connections when there are already many connections from that source IP

I'm trying to find a good solution for the case where a single IP 
attempts to open a large number of concurrent connections to a web 
server.  I'm less concerned about the rate of connections, at least at 
the moment; it is actual concurrent connections which have my attention.

This comes from the case where I've seen "bad actors" use all connections 
up to Apache's MaxClients.

I know of a couple of different approaches, but neither makes me 
completely happy.  With iptables and connlimit, excess connections can be 
failed (either quietly DROPped or REJECTed with an ICMP error or TCP 
reset).  With mod_security, sufficient connections (at least in the WRITE 
state) can cause return of some "error page" to the browser.

I'm wondering if there's another approach, where the SYN ACK (and so on) 
can simply be delayed until the number of connections drops below some 
threshold.  I looked around and haven't seen an iptables module that does 
this (or which delays accepting or forwarding the SYN, which would 
achieve that effect even more efficiently).

Any pointers or thoughts.  The goal is to let the activity ultimately 
succeed, but more slowly than otherwise.

Thanks...
	
	Andrew

[toc] | [next] | [standalone]

#2181

If you simply, silently drop SYN (or SYN|ACK) segments when the number
of concurrent connections is over the limit, that will, in efect, slow
those connections - the sender TCP will start retransmitting,
presumably with a back-off, and if the concurrent connection count
drops below the limit in the meantime, presuambly then the connection
would proceed after some number of retransmissions.  Not sure there is
much value in "holding" the SYN or SYN|ACK and having to keep track of
it.  True, you could presumably forward it along sooner than the
sender would have retransmitted, but if indeed this is anti-social
behaviour you are looking tomitigate, why optimize the case?

rick jones
-- 
I don't interest myself in "why." I think more often in terms of
"when," sometimes "where;" always "how much."  - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[toc] | [prev] | [next] | [standalone]

#2185

On Wed, 29 May 2013 22:38:27 +0000, Rick Jones wrote:

> If you simply, silently drop SYN (or SYN|ACK) segments when the number
> of concurrent connections is over the limit, that will, in efect, slow
> those connections - the sender TCP will start retransmitting, presumably
> with a back-off

I'd not considered the retry/back-off part of the TCP startup sequence; 
that's a good point.  I'll see how just dropping the SYN works out.

Thanks...

	- Andrew

[toc] | [prev] | [next] | [standalone]

#2183

In article <nbspt.41942$Lw2.3399@fe09.iad>,
Andrew Gideon  <c182driver9@gideon.org> wrote:
>I'm trying to find a good solution for the case where a single IP 
>attempts to open a large number of concurrent connections to a web 
>server.  I'm less concerned about the rate of connections, at least at 
>the moment; it is actual concurrent connections which have my attention.
>
>This comes from the case where I've seen "bad actors" use all connections 
>up to Apache's MaxClients.
>
>I know of a couple of different approaches, but neither makes me 
>completely happy.  With iptables and connlimit, excess connections can be 
>failed (either quietly DROPped or REJECTed with an ICMP error or TCP 
>reset).  With mod_security, sufficient connections (at least in the WRITE 
>state) can cause return of some "error page" to the browser.
>
>I'm wondering if there's another approach, where the SYN ACK (and so on) 
>can simply be delayed until the number of connections drops below some 
>threshold.  I looked around and haven't seen an iptables module that does 
>this (or which delays accepting or forwarding the SYN, which would 
>achieve that effect even more efficiently).

Delaying the SYN/ACK will probably not be a very good way to do this, as
the SYN will be resent after some timeout anyways. Possibly it will be
better to just drop the first (or first few) SYNs of a connection you want
to be slowed. This can be done with the statistic extension of iptables,
AFAICS.

cu

AW
-- 
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (aw@linux.de)

[toc] | [prev] | [next] | [standalone]

#2184

On Wed, 2013-05-29, Andrew Gideon wrote:
> I'm trying to find a good solution for the case where a single IP 
> attempts to open a large number of concurrent connections to a web 
> server.  I'm less concerned about the rate of connections, at least at 
> the moment; it is actual concurrent connections which have my attention.

Keep in mind that this is a bit unfair to people who are behind NAT
and appear to share one IP address, or use it as some kind of
anonymizing gateway or proxy, or simply share a computer.

> This comes from the case where I've seen "bad actors" use all connections 
> up to Apache's MaxClients.

In the HTTP case, can you tell it's not just a lot of people behind a
company or ISP HTTP proxy?

I'm not saying you shouldn't do this. But keep in mind that
"a single IP" doesn't equate a single user.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2186

On Thu, 30 May 2013 06:45:11 +0000, Jorgen Grahn wrote:

> I'm not saying you shouldn't do this. But keep in mind that "a single
> IP" doesn't equate a single user.

I do know this, but thanks for reminder.

No, I'm not sure.  That's why I'm using mod_security to try to put up a 
warning page at a threshold lower than the "syn drop" (as it is now) in 
iptables.  The idea is that people will notify us if they see the warning 
page, and this tells us we need to tweak our values.

Unfortunately, mod_security doesn't seem to have an exact match to 
iptable's connlimit (at least as far as I can tell).  It can limit the 
number of connections in the READ or WRITE states, but not the union of 
these (nor does it count those threads in a Keepalive wait).

Hmm.  I could, I suppose, use connlimit to trigger a DNAT to send the 
request to a different - lighter weight - web server which displayed a 
warning page.  That may be overkill for what I'm trying to accomplish, 
but I think I'll mull that over.

Perhaps I should look again for an Apache module that more directly 
corresponds to the behavior of iptable's connlimit.

However, I confess that I do believe the problem is at least most often a 
case of "bad actors".  In one case, for example, an Internet search 
yielded claims that the IP was a source of comment spam.

	- Andrew

[toc] | [prev] | [next] | [standalone]

#2187

On 05/29/2013 01:56 PM, Andrew Gideon wrote:
> I'm trying to find a good solution for the case where a single IP
> attempts to open a large number of concurrent connections to a web
> server.  I'm less concerned about the rate of connections, at least at
> the moment; it is actual concurrent connections which have my attention.
>
> This comes from the case where I've seen "bad actors" use all connections
> up to Apache's MaxClients.
>
> I know of a couple of different approaches, but neither makes me
> completely happy.  With iptables and connlimit, excess connections can be
> failed (either quietly DROPped or REJECTed with an ICMP error or TCP
> reset).  With mod_security, sufficient connections (at least in the WRITE
> state) can cause return of some "error page" to the browser.
>
> I'm wondering if there's another approach, where the SYN ACK (and so on)
> can simply be delayed until the number of connections drops below some
> threshold.  I looked around and haven't seen an iptables module that does
> this (or which delays accepting or forwarding the SYN, which would
> achieve that effect even more efficiently).
>

Not sure it matches your requirements but have you looked at 
mod_limitipconn?

Jeff Long

[toc] | [prev] | [next] | [standalone]

#2195

On Thu, 30 May 2013 10:09:40 -0500, Jeff Long wrote:

> Not sure it matches your requirements but have you looked at
> mod_limitipconn?

Thanks for the pointer; I'd not seen that previously and it does look 
like an exact match.  I also like the documentation's reference to 
mod_remoteip, which might help discern proxies from "bad actors" (though 
I imagine that bad actors can reliably mimic proxies, so probably not 
{8^).

	- Andrew

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web