Re: [qmailtoaster] I cannot install qmailtoaster on Centos 6.5 64 bit
Hi Eirc, Could you please send me the complete procedure for install QMT. Because here a lot of title and packages are there and couldn't understand to install QMT. Please assist me. On Sat, Feb 22, 2014 at 9:43 PM, Eric Broch ebr...@whitehorsetc.com wrote: When you get qt-bootstrap-2 downloaded edit it and replace http://mirrors.qmailtoaster.com/current/nodist/$qmt_release_pkg with http://mirrors.qmailtoaster.com/testing/nodist/$qmt_release_pkg On 2/22/2014 12:51 AM, Chandran Manikandan wrote: Dear All, I have tried to install centos 6.5 64 bit server on below procedure. But it's not working means cannot install and shows not found the url on below instructions. Installation Instructions (pre-wiki) .) install CentOS minimal # curl https://raw.github.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-1 qt-bootstrap-1 I cannot download this file # sh qt-bootstrap-1 (system will reboot) # curl https://raw.github.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-2 qt-bootstrap-2 # sh qt-bootstrap-2 I cannot download this file # qt-install --Cannot run this commands .) yum install man .) qt-install-repoforge .) yum install simscan dovecot vqadmin qmailadmin (etc) .) qt-mysql-secure-vpopmail .) qt-install-dns-resolver Could you please give me the correct url and procedure to install qmailtoaster. -- *Thanks,* *Manikandan.C* *System Administrator* -- *Thanks,* *Manikandan.C* *System Administrator*
RE: [qmailtoaster] I cannot install qmailtoaster on Centos 6.5 64 bit
Chandran,
This is for you,
1. install CentOS minimal
2. curl
https://raw.github.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-1
qt-bootstrap-1
3. sh qt-bootstrap-1
(system will reboot)
4. curl
https://raw.github.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-2
qt-bootstrap-2
vi qt-bootstrap-2
Change:
http://mirrors.qmailtoaster.com/current/nodist/qmailtoaster-release-2.0-1.qt
.nodist.noarch.rpm
To:
http://mirrors.qmailtoaster.com/testing/nodist/qmailtoaster-release-2.0-1.qt
.nodist.noarch.rpm
5. cd /etc/yum.repos.d
vi qmailtoaster-nodist.repo
{{{ Same in qmailtoaster-dist.repo }}}
enabled from 1 to 0 in the [qmailtoaster-current] and from 0 to 1 in the
[qmailtoaster-testing].
save and run yum clean all
6. sh qt-bootstrap-2
7. qt-install
8. service dovecot restart and chkconfig dovecot on
Regards,
Vivek Patil
system admin
From: Chandran Manikandan [mailto:tech2m...@gmail.com]
Sent: Monday, February 24, 2014 4:01 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] I cannot install qmailtoaster on Centos 6.5 64
bit
Hi Eirc,
Could you please send me the complete procedure for install QMT. Because
here a lot of title and packages are there and couldn't understand to
install QMT. Please assist me.
On Sat, Feb 22, 2014 at 9:43 PM, Eric Broch ebr...@whitehorsetc.com wrote:
When you get qt-bootstrap-2 downloaded edit it and replace
http://mirrors.qmailtoaster.com/current/nodist/$qmt_release_pkg
with
http://mirrors.qmailtoaster.com/testing/nodist/$qmt_release_pkg
On 2/22/2014 12:51 AM, Chandran Manikandan wrote:
Dear All,
I have tried to install centos 6.5 64 bit server on below procedure. But
it's not working means cannot install and shows not found the url on below
instructions.
Installation Instructions (pre-wiki)
.) install CentOS minimal
# curl
https://raw.github.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-1
qt-bootstrap-1
I cannot download this file
# sh qt-bootstrap-1
(system will reboot)
# curl
https://raw.github.com/QMailToaster/qmailtoaster-util/master/qt-bootstrap-2
qt-bootstrap-2
# sh qt-bootstrap-2
I cannot download this file
# qt-install --Cannot run this commands
.) yum install man
.) qt-install-repoforge
.) yum install simscan dovecot vqadmin qmailadmin (etc)
.) qt-mysql-secure-vpopmail
.) qt-install-dns-resolver
Could you please give me the correct url and procedure to install
qmailtoaster.
--
Thanks,
Manikandan.C
System Administrator
--
Thanks,
Manikandan.C
System Administrator
Re: [qmailtoaster] Blocking more spam
On Feb 22, 2014, at 12:18 PM, Eric Shubert e...@shubes.net wrote:
It's not a terrible idea though. I wonder if fail2ban could be configured to
count DENIED_RDNS messages for each IP address, and if there were more than a
certain number of failed attempts in a given time period, then block the IP
address.
I'd like to hear from anyone with more familiarity with F2B than myself about
this possibility. This might be an additional F2B configuration we could
include.
For Fail2Ban to be effective, you'd want (a) repeat attempts from one IP to be
large enough that you could usefully reduce load by banning offenders, and (b)
the total number of offenders to be small enough that you don't end up adding
thousands of entries to iptables. (I'm assuming that if you add enough entries
to iptables you will eventually start seeing some kind of a performance hit,
but I don't know if that is in fact the case, or where the cutoff point comes).
I did a quick informal study with:
grep DENIED_RDNS /var/log/qmail/smtp/current | awk '{print $9}' | sort
| uniq -c | grep -v 1 | grep -v 2
to find out how many hosts made 3 or more attempts.
In a sample based on about 90 minutes worth of mail, there were just over 100
hosts, only 8 of which made 3 or more attempts to deliver. The 'worst offender'
made 15 attempts.
In a larger sample, representing about 10 days worth of mail, 8206 hosts were
denied, with the 'worst offender' making 1325 attempts, and 528 hosts making 3
or more attempts.
In my (unscientific) sample, just under 7000 of the hosts sent a single message
each. There were 27 hosts that tried to send more than 100 messages, and that
accounted for just over 10,000 messages, about 40% of the total. Of course, if
you set 100 as the cut-off point, you can't ban them until they deliver their
100th message, so - based on my sample - you'd reduce load by about 25%.
That doesn't sound bad, though.
If you set the ban point at 20 messages, you'd ban about 100 hosts, and reduce
load by 47%.
Banning at 10 messages leads to banning 150 hosts, and reduces load by about
52%.
But I've been looking at 10 days of mail, which is probably unreasonable.
Fail2Ban allows you to tune the 'findtime' for a jail (i.e. the period for
which Fail2Ban will track failed attempts). The default seems to be 600 seconds
(10 minutes). Would a 1-day window be appropriate for this application?
cat `find /var/log/qmail/smtp/ -mtime -1` | grep DENIED_RDNS | awk
'{print $9}' | more | sort | uniq -c
gets me results for just 1 day.
A 1-day sample of my messages turned up 941 unique hosts, and 2672 messages.
Banning after 10 failures would have banned 43 hosts and reduced load by about
37% (i.e. 37% of the attempted delivery connections would have been rejected by
iptables rather than spamdyke).
Incidentally, things get interesting if you look at networks rather than
individual IPs. There are definite 'clusters', and it could be that banning a
few selected class C's would have substantial payoff. (The old joke about
eliminating 95% of all spam by null-routing China, Florida and BurstNet comes
to mind). But you might not want to give a robot power to ban class C's without
supervision (Things have gotten awfully quiet around here lately ...)
I think you could write a Fail2Ban rule, and depending on where you set the
cutoff point, it would probably reduce your server load by 25-50% of the
difference between banning-by-spamdyke and banning-by-firewall. Assume that if
you keep the number of entries in iptables reasonably low, there's no cost to
an iptables ban. Assume also that having fail2ban scan the quickly-changing
smtp/current log and tracking up to n hosts (where 'n' is the number of hosts
failing for RDNS_DENIED per day) is also 'free'. Then you can reduce load by
25-50% of however much load spamdyke is putting on your box. And I have no idea
how to calculate what that might be.
TL;DR: It looks as if this approach would offer savings, but you need to look
at usage patterns on your own servers to figure out how big those savings might
be.
Angus
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Blocking more spam
On 02/24/2014 09:46 AM, Angus McIntyre wrote:
On Feb 22, 2014, at 12:18 PM, Eric Shubert e...@shubes.net wrote:
It's not a terrible idea though. I wonder if fail2ban could be configured to
count DENIED_RDNS messages for each IP address, and if there were more than
a certain number of failed attempts in a given time period, then block the
IP address.
I'd like to hear from anyone with more familiarity with F2B than myself
about this possibility. This might be an additional F2B configuration we
could include.
For Fail2Ban to be effective, you'd want (a) repeat attempts from one IP to
be large enough that you could usefully reduce load by banning offenders, and
(b) the total number of offenders to be small enough that you don't end up
adding thousands of entries to iptables. (I'm assuming that if you add enough
entries to iptables you will eventually start seeing some kind of a
performance hit, but I don't know if that is in fact the case, or where the
cutoff point comes).
I did a quick informal study with:
grep DENIED_RDNS /var/log/qmail/smtp/current | awk '{print $9}' | sort
| uniq -c | grep -v 1 | grep -v 2
to find out how many hosts made 3 or more attempts.
In a sample based on about 90 minutes worth of mail, there were just over 100
hosts, only 8 of which made 3 or more attempts to deliver. The 'worst
offender' made 15 attempts.
In a larger sample, representing about 10 days worth of mail, 8206 hosts were
denied, with the 'worst offender' making 1325 attempts, and 528 hosts making
3 or more attempts.
In my (unscientific) sample, just under 7000 of the hosts sent a single
message each. There were 27 hosts that tried to send more than 100 messages,
and that accounted for just over 10,000 messages, about 40% of the total. Of
course, if you set 100 as the cut-off point, you can't ban them until they
deliver their 100th message, so - based on my sample - you'd reduce load by
about 25%.
That doesn't sound bad, though.
If you set the ban point at 20 messages, you'd ban about 100 hosts, and
reduce load by 47%.
Banning at 10 messages leads to banning 150 hosts, and reduces load by about
52%.
But I've been looking at 10 days of mail, which is probably unreasonable.
Fail2Ban allows you to tune the 'findtime' for a jail (i.e. the period for
which Fail2Ban will track failed attempts). The default seems to be 600
seconds (10 minutes). Would a 1-day window be appropriate for this
application?
cat `find /var/log/qmail/smtp/ -mtime -1` | grep DENIED_RDNS | awk
'{print $9}' | more | sort | uniq -c
gets me results for just 1 day.
A 1-day sample of my messages turned up 941 unique hosts, and 2672 messages.
Banning after 10 failures would have banned 43 hosts and reduced load by
about 37% (i.e. 37% of the attempted delivery connections would have been
rejected by iptables rather than spamdyke).
Incidentally, things get interesting if you look at networks rather than
individual IPs. There are definite 'clusters', and it could be that banning a
few selected class C's would have substantial payoff. (The old joke about
eliminating 95% of all spam by null-routing China, Florida and BurstNet comes
to mind). But you might not want to give a robot power to ban class C's
without supervision (Things have gotten awfully quiet around here lately
...)
I think you could write a Fail2Ban rule, and depending on where you set the
cutoff point, it would probably reduce your server load by 25-50% of the
difference between banning-by-spamdyke and banning-by-firewall. Assume that
if you keep the number of entries in iptables reasonably low, there's no cost
to an iptables ban. Assume also that having fail2ban scan the
quickly-changing smtp/current log and tracking up to n hosts (where 'n' is
the number of hosts failing for RDNS_DENIED per day) is also 'free'. Then you
can reduce load by 25-50% of however much load spamdyke is putting on your
box. And I have no idea how to calculate what that might be.
TL;DR: It looks as if this approach would offer savings, but you need to look
at usage patterns on your own servers to figure out how big those savings
might be.
Angus
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Nice analysis Angus.
On my server I allow 3 attempts then you're gone for 24 hours. Since I
have e mail confirmation of bans I know it's reducing the load
considerably during peak SPAM barrages. I know in my application it has
certainly cut down on unwanted attempts to SPAM or gain access through
password guessing.
I've seen delays in administrating iptables (hand editing) when the
files are large, but no noticable difference in access speed. This is
only anecdotal and I have no hard number to back up my claim.
[qmailtoaster] bl.spamcop.net FPs
Has anyone else (besides a user of mine) observed any False Positives on spamcop recently? Just wondering if how wide-spread the problem is. spamcop's historically had very low FP rates (ttbomk). Thanks. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Blocking more spam
On 02/24/2014 11:28 AM, Cecil Yother, Jr. wrote:
On 02/24/2014 09:46 AM, Angus McIntyre wrote:
On Feb 22, 2014, at 12:18 PM, Eric Shubert e...@shubes.net wrote:
It's not a terrible idea though. I wonder if fail2ban could be configured to
count DENIED_RDNS messages for each IP address, and if there were more than a
certain number of failed attempts in a given time period, then block the IP
address.
I'd like to hear from anyone with more familiarity with F2B than myself about
this possibility. This might be an additional F2B configuration we could
include.
For Fail2Ban to be effective, you'd want (a) repeat attempts from one IP to be
large enough that you could usefully reduce load by banning offenders, and (b)
the total number of offenders to be small enough that you don't end up adding
thousands of entries to iptables. (I'm assuming that if you add enough entries
to iptables you will eventually start seeing some kind of a performance hit,
but I don't know if that is in fact the case, or where the cutoff point comes).
I did a quick informal study with:
grep DENIED_RDNS /var/log/qmail/smtp/current | awk '{print $9}' | sort | uniq -c | grep -v
1 | grep -v 2
to find out how many hosts made 3 or more attempts.
In a sample based on about 90 minutes worth of mail, there were just over 100
hosts, only 8 of which made 3 or more attempts to deliver. The 'worst offender'
made 15 attempts.
In a larger sample, representing about 10 days worth of mail, 8206 hosts were
denied, with the 'worst offender' making 1325 attempts, and 528 hosts making 3
or more attempts.
In my (unscientific) sample, just under 7000 of the hosts sent a single message
each. There were 27 hosts that tried to send more than 100 messages, and that
accounted for just over 10,000 messages, about 40% of the total. Of course, if
you set 100 as the cut-off point, you can't ban them until they deliver their
100th message, so - based on my sample - you'd reduce load by about 25%.
That doesn't sound bad, though.
If you set the ban point at 20 messages, you'd ban about 100 hosts, and reduce
load by 47%.
Banning at 10 messages leads to banning 150 hosts, and reduces load by about
52%.
But I've been looking at 10 days of mail, which is probably unreasonable.
Fail2Ban allows you to tune the 'findtime' for a jail (i.e. the period for
which Fail2Ban will track failed attempts). The default seems to be 600 seconds
(10 minutes). Would a 1-day window be appropriate for this application?
cat `find /var/log/qmail/smtp/ -mtime -1` | grep DENIED_RDNS | awk
'{print $9}' | more | sort | uniq -c
gets me results for just 1 day.
A 1-day sample of my messages turned up 941 unique hosts, and 2672 messages.
Banning after 10 failures would have banned 43 hosts and reduced load by about
37% (i.e. 37% of the attempted delivery connections would have been rejected by
iptables rather than spamdyke).
Incidentally, things get interesting if you look at networks rather than individual IPs.
There are definite 'clusters', and it could be that banning a few selected class C's
would have substantial payoff. (The old joke about eliminating 95% of all spam by
null-routing China, Florida and BurstNet comes to mind). But you might not want to give a
robot power to ban class C's without supervision (Things have gotten awfully quiet
around here lately ...)
I think you could write a Fail2Ban rule, and depending on where you set the
cutoff point, it would probably reduce your server load by 25-50% of the
difference between banning-by-spamdyke and banning-by-firewall. Assume that if
you keep the number of entries in iptables reasonably low, there's no cost to
an iptables ban. Assume also that having fail2ban scan the quickly-changing
smtp/current log and tracking up to n hosts (where 'n' is the number of hosts
failing for RDNS_DENIED per day) is also 'free'. Then you can reduce load by
25-50% of however much load spamdyke is putting on your box. And I have no idea
how to calculate what that might be.
TL;DR: It looks as if this approach would offer savings, but you need to look
at usage patterns on your own servers to figure out how big those savings might
be.
Angus
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Nice analysis Angus.
On my server I allow 3 attempts then you're gone for 24 hours. Since I
have e mail confirmation of bans I know it's reducing the load
considerably during peak SPAM barrages. I know in my application it has
certainly cut down on unwanted attempts to SPAM or gain access through
password guessing.
I've seen delays in administrating iptables (hand editing) when the
files are large, but no noticable difference in access speed. This is
only anecdotal and I have no hard number to back up my claim. That was
on another
[qmailtoaster] Re: Blocking more spam
On 02/24/2014 09:16 PM, cj yother wrote: I ban no host name, no rDNS and failed login attempts after 3 tries for 24 hours. It's made a measurable difference on the load on the server. What constitutes no host name? (I think I know what no rDNS is). Failed login attempts are an entirely different animal, at least in the context of this thread. Can you separate this aspect from the other 2 with regards to measurable difference? You say measurable difference on the load. Can you share these measures? (Be specific. It's not that I don't trust you of course. ;) ) Also, does your postfix configuration reject rDNS (or no host name) outright, or are these messages scanned? If they're not rejected outright (without being scanned, or even accepted), I'm afraid that your measurable difference would not be applicable when spamdyke is used. spamdyke rejects these messages without even receiving them. What say you? Thanks. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Blocking more spam
On 02/24/2014 09:37 PM, Eric Shubert wrote:
On 02/24/2014 09:16 PM, cj yother wrote:
I ban no host name, no rDNS and failed login
attempts after 3 tries for 24 hours. It's made a measurable difference
on the load on the server.
What constitutes no host name? (I think I know what no rDNS is).
This is the entry I use for no host name. This is where it's taken some
of the load off the server. It bans them when they try 3 or more time
from the same IP with no reverse hostname. Postfix rejects the first
three and Fail2ban takes it from there.
failregex = reject: RCPT from (.*)\[HOST\]: 450 4.7.1 Client host
rejected: cannot find your reverse hostname
Failed login attempts are an entirely different animal, at least in
the context of this thread. Can you separate this aspect from the
other 2 with regards to measurable difference?
I use this Fail2ban entry for failed login attempts. It bans them after
3 attempts from the same IP.
failregex = (?i): warning: [-._\w]+\[HOST\]: SASL
(?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [
A-Za-z0-9+/]*={0,2})?\s*$
You say measurable difference on the load. Can you share these
measures? (Be specific. It's not that I don't trust you of course. ;) )
I only measure it comparing the Logwatch SASL attempts before and after
implementing the Fail2ban. Sorry about the lack of detail.
Also, does your postfix configuration reject rDNS (or no host name)
outright, or are these messages scanned? If they're not rejected
outright (without being scanned, or even accepted), I'm afraid that
your measurable difference would not be applicable when spamdyke is
used. spamdyke rejects these messages without even receiving them.
Postfix processes them and rejects them like this:
postfix/smtpd[15414]: NOQUEUE: reject: RCPT from unknown[64.206.88.186]:
450 4.7.1 Client host rejected: cannot find your reverse hostname,
Not sure if that's pre processing it or not. NOQUEUE would tell me it's
not making it to the QUE. If that's not reading too much into it.
What say you?
Thanks.
I hope this helps.
--
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
