[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Framework for web control panel.

Adam McGreggor wrote:
> Do you mind sharing your config/the rule-set that you're using?
> Obviously, the fine-tuning will be up to individual
> mail-admins/postmasters, but roughly speaking?

All what we do is published in our control panel, including the iptables
rules in our dtc-dos-firewall (included in Debian, but I suggest you to
get the latest in our debian repo, or have a look on our gitweb). All
rates are configurable through a config file in /etc/dtc.

> Do you trust all hosts the same (and rate-limit accordingly), or are
> you less/more fierce/strict with some hosts?

I trust that for each type of server hardware, there are limits that you
should enforce in order to not have your server blow up. What is written
in the package as default works in most cases though, for an average
actual dedicated server, but it's best to tweak it. For example, for the
SMTP receiving, you should have a look at the amount of email you are
receiving on average (we use mailgraph to know that), and then set it to
something like 4 or 5 times that amount to be able to handle peak
connections. In some cases, best might be to do the opposite way:
enforce something restrictive, then relax until nobody complains
anymore. That's what we did for mod_bwshare. The following parameters
for mod_cband wont be annoying in most cases:

        <Directory />
                BW_tx1debt_max          500
                BW_tx1cred_rate         0.95
                BW_tx2debt_max          6000000
                BW_tx2cred_rate         50000000

One more thing. Our iptables script is being quite restrictive with the
number ssh connections. In some cases, this can be dangerous because if
someone does constant connections, you wont be able to log into your
server. We don't care as we have KVM over IP on all our servers, so if
someone does that, we still got access. It's extremely important to do
this with sshd, as it forks quite fast and can die or fill up the memory
quickly, like many other daemons.

Here's a link to our script in the latest entry of our Git (quite a
moving target, so this is valid for this week only! :)):


I believe that the version for Xen servers is a way better though:


Note the REJECT vs LOGDROP thing. The nice thing with LOGDROP is that
you will see in syslog what's happening whenever someone abuses. Droping
packets is quite a nice thing to do, especially for SMTP and web
servers, because what's going to happen is that the client will keep
trying for a while before timing-out and give up. This is not always
wanted though, like for ssh where we decided that REJECT was ok.

Contributions are obviously welcome, all this is quite basic, I'm not
particularly proud of it, but it does its service protection job.


Reply to: