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

Discussion in 'Linux Networking' started by Andrew Gideon, May 29, 2013.

  1. 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.


    Andrew Gideon, May 29, 2013
    1. Advertisements

  2. Andrew Gideon

    aw Guest

    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,


    aw, May 29, 2013
    1. Advertisements

  3. Andrew Gideon

    Rick Jones Guest

    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
    Rick Jones, May 29, 2013
  4. Andrew Gideon

    Jorgen Grahn Guest

    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.
    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 Grahn, May 30, 2013
  5. 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.


    - Andrew
    Andrew Gideon, May 30, 2013
  6. 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
    Andrew Gideon, May 30, 2013
  7. Andrew Gideon

    Jeff Long Guest

    Not sure it matches your requirements but have you looked at

    Jeff Long
    Jeff Long, May 30, 2013
  8. 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

    - Andrew
    Andrew Gideon, Jun 4, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.