[imp] hardening imp against spammers
Jon Lewis
stolen credit card info and sending their 419 spams to hundreds of
recipients/message through our webmail system.
Is there any reason not to have something like:
/* impose limit on number of recipients */
if (substr_count($recips,"@") > $conf['user']['max_recipients']) {
Horde::raiseMessage(_("Too many recipients. Try again with fewer."), HORDE_ERROR);
$get_sig = false;
break;
}
/* end impose limit on number of recipients */
in compose.php in case SEND_MESSAGE: right after $recips is filled in? It
seems to work for me anyway.
Also, I've been using iptables to block entire CIDR blocks from which we
see Nigerian spammer logins. As of last night, I've noticed Nigerians
logging in to spam through open proxies. Has anyone done a patch for imp
to deny access (maybe just deny sending) for IPs in various DNSBLs?
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
--
IMP mailing list - Join the hunt: http://horde.org/bounties/#imp
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: imp-uns...@lists.horde.org
Jan Schneider
> Is there any reason not to have something like:
>
> /* impose limit on number of recipients */
> if (substr_count($recips,"@") > $conf['user']['max_recipients']) {
> Horde::raiseMessage(_("Too many recipients. Try again with
> fewer."), HORDE_ERROR);
> $get_sig = false;
> break;
> }
> /* end impose limit on number of recipients */
>
> in compose.php in case SEND_MESSAGE: right after $recips is filled in? It
> seems to work for me anyway.
Beside that it's for a very special problem (that I currently have at a
customer's site too, btw), no.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
Jon Lewis
> > /* impose limit on number of recipients */
> > if (substr_count($recips,"@") > $conf['user']['max_recipients']) {
> > Horde::raiseMessage(_("Too many recipients. Try again with
> > fewer."), HORDE_ERROR);
> > $get_sig = false;
> > break;
> > }
> > /* end impose limit on number of recipients */
>
> Beside that it's for a very special problem (that I currently have at a
> customer's site too, btw), no.
Shouldn't there be at least the option to configure such a limit? This
really frustrated me because we have imp invoking qmail's sendmail, and
short of much more difficult hacks to qmail, there appears to be no other
way to limit the number of recipients. Also, I wasn't quite working on
all cylinders this AM after spending a while trying to hack this into
qmail. That patch should probably be:
/* impose limit on number of recipients */
if ($conf['user']['max_recipients'] > 0 && substr_count($recips,"@")
> $conf['user']['max_recipients']) {
Horde::raiseMessage(_("Too many recipients. Try again with fewer."), HORDE_ERROR);
$get_sig = false;
break;
}
/* end impose limit on number of recipients */
so that if max_recipients isn't set or is set to 0, you get the default
behavior of no limit rather than the breakage I assume would happen as
substr_count would be compared to 0 or undefined and likely be greater.
If we can't shake the Nigerians (they appear to have images of or at least
all the info including CVV2 codes for their stolen cards and are now using
open proxies to access our webmail...so we're having a real hard time
either stopping them from signing up or blocking them by IP from using
webmail), I suspect the next things we'll need are the DNSBL support I
mentioned (which I suspect is easy enough I might end up doing it), and
some form of per-user message rate limiting...i.e. after sending X
messages in Y time, you're done. That'd probably require a new SQL table
holding a key, username, and timestamp in each row so that compose.php
could then do a select and count up how many messages the user has sent
recently and decide if the current message can be sent. I don't suppose
someone's already done something like this?
Another possibility is forcing the outgoing mail through spamassassin.
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
lst_...@kwsoft.de
>
> DNSBL is a *very bad thing*. See
> http://www.acme.com/mail_filtering/shame_frameset.html for a good
> description of the issues.
>
> Personal example: user sets up a machine on a home-based network that
> is on a business broadbank link (i.e. small business operator from
> home). The business broadband provider also happens to provide home
> broadband support also. Complete idiot DNSBL maintainers blacklist the
> user's address because a few (most definitely not all or even some)
> users on the home broadband have either infected computers or are doing
> bad things. Therefore, because DNSBL maintainers are lazy or
> uneducated or both, instead of marking the individual addresses as bad
> they instead mark the entire block of addresses registered to the
> broadband provider as "bad" (We are talking entire Class C blocks
> here). Since broadband provider does not provide information on how
> their blocks are allocated, businesses lose the ability to run their
> own servers due to ineptitude of DNSBL maintainers.
>
> Quite honestly, it is a subtle form of discrimination in that DNSBL
> maintainers can, by their actions, make certain broadband providers
> less desirable due to the fact that their network connection is now
> "tainted".
Let's do not go for this discussion again. Not DNSBL are bad, but using them
without understanding what they do is. At least read and understand the
listing/delisting policy and choose if it matches your requirements.
Regards
Andreas
Jon Lewis
> Quoting Jon Lewis <jle...@lewis.org>:
>
> > Shouldn't there be at least the option to configure such a limit?
>
> "Shouldn't" is a very, very loaded word. Please consider that you are
> dealing with volunteers, that no one may have hit this situation
> before, that no one may have thought of it, etc. And Jan _said_ that
> there wasn't a reason not to add it, and that he was seeing the same
> situation at a customer.
Sorry, I've been dealing with Nigerian webmail abusers on and off for
months and dealing with many other fires recently. I wasn't as much
complaining about the lack of such a feature as suggesting "here it is,
and it'd be great if someone would do whatever cleanup is required and
merge this into the code"...and Jan's message seemed to imply that he
didn't think it was worth incorporating (or did I misinterpret it) even
though he recently needed (wrote?) the same feature for another IMP site?
This one's trivial enough that if I have to maintain it in our own hacked
up IMP, it's no big deal, but others will likely benefit from having it,
and I'd always rather see it in a future version than have to keep my own
patch set.
> > webmail), I suspect the next things we'll need are the DNSBL support I
> > mentioned (which I suspect is easy enough I might end up doing it), and
>
> We could use this for lots of other aplications, too - Agora, Volos,
> etc. Would be a very useful contribution.
I just did this, but the code is even rougher than the max-recipients
thing, so I really doubt it'll be accepted without some serious cleanup
(like moving the dnsbls and codes to $conf rather than hardcoding them in
compose.php), but here it is anyway.
I'm checking njabl for proxies and spamsources, and sbl-xbl for any return
code. I put this function at the top of compose.php:
/**
* Returns a dnsbl the client IP is listed in or FALSE
*/
function dnsblcheck()
{
$dnsbl = array(0 => 'dnsbl.njabl.org', 1 => 'sbl-xbl.spamhaus.org');
$dnsblcode = array(0 => '127.0.0.[49]', 1 => 0);
$rev = array_reverse(explode('.', $_SERVER['REMOTE_ADDR']));
for($dnsblc=0; array_key_exists($dnsblc,$dnsbl); $dnsblc++) {
$lookup = implode('.', $rev) . '.' . $dnsbl[$dnsblc];
$result = gethostbyname($lookup);
if ($lookup != $result) {
if (($dnsblcode[$dnsblc]) && preg_match("/$dnsblcode[$dnsblc]/", $result)) {
return $dnsbl[$dnsblc];
}
if ($dnsblcode[$dnsblc] == 0) {
return $dnsbl[$dnsblc];
}
}
}
return FALSE;
}
The at the tops of case BOUNCE_MESSAGE: and SEND_MESSAGE:, I added:
if (($dnsblname = dnsblcheck()) != FALSE) {
Horde::logMessage(sprintf("dnsblhit in %s from %s",$dnsblname,$_SERVER['REMOTE_ADDR']), __FILE__, __LINE__, LOG_ERR);
Horde::raiseMessage(sprintf(_("Sorry. Your IP is dnsbl listed in %s. You cannot send mail."),$dnsblname), HORDE_ERROR);
$get_sig = false;
break;
}
> I haven't heard of it. That to me sounds like the kind of thing you're
> better off doing at the MTA level, instead of just in a web layer,
> though.
Trouble is, then its MTA-specific. Doing it in IMP makes it more portable
and IMP already does db work, knows the username of the logged in user,
and can give the user a nice error message (like my max-recipients or
dnsbl messages) when they try to send and exceed their rate limit.
Anyway, hopefully what I and others here have already done will convince
the Nigerians to move along again to a service easier to abuse.
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Chuck Hagenbuch
> Sorry, I've been dealing with Nigerian webmail abusers on and off for
> months and dealing with many other fires recently. I wasn't as much
> complaining about the lack of such a feature as suggesting "here it is,
> and it'd be great if someone would do whatever cleanup is required and
> merge this into the code"...and Jan's message seemed to imply that he
> didn't think it was worth incorporating (or did I misinterpret it)
Yes. You asked if there was a reason not to include it. He said no.
-chuck
--
"But she goes not abroad in search of monsters to destroy." - John
Quincy Adams
Chuck Hagenbuch
> Shouldn't there be at least the option to configure such a limit?
"Shouldn't" is a very, very loaded word. Please consider that you are
dealing with volunteers, that no one may have hit this situation
before, that no one may have thought of it, etc. And Jan _said_ that
there wasn't a reason not to add it, and that he was seeing the same
situation at a customer.
> Also, I wasn't quite working on all cylinders this AM after spending
> a while trying to hack this into qmail. That patch should probably
> be:
>
> /* impose limit on number of recipients */
> if ($conf['user']['max_recipients'] > 0 && substr_count($recips,"@")
>> $conf['user']['max_recipients']) {
> Horde::raiseMessage(_("Too many recipients. Try again with
> fewer."), HORDE_ERROR);
> $get_sig = false;
> break;
> }
> /* end impose limit on number of recipients */
I'd use !empty() to be even more forgiving. Otherwise, create an
enhancment request on bugs.horde.org with an actual unified diff,
including the changes to conf.xml, and we'll get it committed.
> webmail), I suspect the next things we'll need are the DNSBL support I
> mentioned (which I suspect is easy enough I might end up doing it), and
We could use this for lots of other aplications, too - Agora, Volos,
etc. Would be a very useful contribution.
> some form of per-user message rate limiting...i.e. after sending X
> messages in Y time, you're done. That'd probably require a new SQL table
> holding a key, username, and timestamp in each row so that compose.php
> could then do a select and count up how many messages the user has sent
> recently and decide if the current message can be sent. I don't suppose
> someone's already done something like this?
I haven't heard of it. That to me sounds like the kind of thing you're
better off doing at the MTA level, instead of just in a web layer,
though.
-chuck
Michael M Slusarz
> If we can't shake the Nigerians (they appear to have images of or at least
> all the info including CVV2 codes for their stolen cards and are now using
> open proxies to access our webmail...so we're having a real hard time
> either stopping them from signing up or blocking them by IP from using
> webmail), I suspect the next things we'll need are the DNSBL support I
> mentioned (which I suspect is easy enough I might end up doing it), and
> some form of per-user message rate limiting...i.e. after sending X
> messages in Y time, you're done. That'd probably require a new SQL table
> holding a key, username, and timestamp in each row so that compose.php
> could then do a select and count up how many messages the user has sent
> recently and decide if the current message can be sent. I don't suppose
> someone's already done something like this?
DNSBL is a *very bad thing*. See
http://www.acme.com/mail_filtering/shame_frameset.html for a good
description of the issues.
Personal example: user sets up a machine on a home-based network that
is on a business broadbank link (i.e. small business operator from
home). The business broadband provider also happens to provide home
broadband support also. Complete idiot DNSBL maintainers blacklist the
user's address because a few (most definitely not all or even some)
users on the home broadband have either infected computers or are doing
bad things. Therefore, because DNSBL maintainers are lazy or
uneducated or both, instead of marking the individual addresses as bad
they instead mark the entire block of addresses registered to the
broadband provider as "bad" (We are talking entire Class C blocks
here). Since broadband provider does not provide information on how
their blocks are allocated, businesses lose the ability to run their
own servers due to ineptitude of DNSBL maintainers.
Quite honestly, it is a subtle form of discrimination in that DNSBL
maintainers can, by their actions, make certain broadband providers
less desirable due to the fact that their network connection is now
"tainted".
michael
_______________________________________
Michael Slusarz [slu...@curecanti.org]
Jon Lewis
> On Wed, 29 Jun 2005, Jan Schneider wrote:
>
> > > /* impose limit on number of recipients */
> > > if (substr_count($recips,"@") > $conf['user']['max_recipients']) {
> > > Horde::raiseMessage(_("Too many recipients. Try again with
> > > fewer."), HORDE_ERROR);
> > > $get_sig = false;
> > > break;
> > > }
> > > /* end impose limit on number of recipients */
> >
> > Beside that it's for a very special problem (that I currently have at a
> > customer's site too, btw), no.
Ok...I think I did misinterpret this and thought you meant "no, it
shouldn't be accepted" when you really meant "no, there's no reason not to
incorporate this feature even though it's only needed in special cases."
Are you dealing with the same problem at that customer's site?
Maybe I'll be a little swifter on the uptake after actually sleeping
tonight.
I'm a little bummed that thus far, the only hits I've gotten on the dnsbl
code appear to be legitimate customers on remote IPs that either are or
recently were systems infected with spam proxies.
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Lord Apollyon
> Ok...I think I did misinterpret this and thought you meant "no, it
> shouldn't be accepted" when you really meant "no, there's no reason not to
> incorporate this feature even though it's only needed in special cases."
>
> Are you dealing with the same problem at that customer's site?
>
> Maybe I'll be a little swifter on the uptake after actually sleeping
> tonight.
>
> I'm a little bummed that thus far, the only hits I've gotten on the dnsbl
> code appear to be legitimate customers on remote IPs that either are or
> recently were systems infected with spam proxies.
Well, I know that sendmail has a configuration item for this. Unless you're
running some kind of mailing list, there's little good reason to allow more
than 40 recipients in a given email transaction.
=R=
Jon Lewis
> DNSBL is a *very bad thing*. See
> http://www.acme.com/mail_filtering/shame_frameset.html for a good
> description of the issues.
Overgeneralized and throwing out the baby with the bathwater. I know the
people who run the DNSBLs I plan to use. I'm not at all worried about
them becoming power hungry weenies.
> Personal example: user sets up a machine on a home-based network that
> is on a business broadbank link (i.e. small business operator from
> home). The business broadband provider also happens to provide home
> broadband support also. Complete idiot DNSBL maintainers blacklist the
> user's address because a few (most definitely not all or even some)
> users on the home broadband have either infected computers or are doing
> bad things. Therefore, because DNSBL maintainers are lazy or
> uneducated or both, instead of marking the individual addresses as bad
> they instead mark the entire block of addresses registered to the
> broadband provider as "bad" (We are talking entire Class C blocks
> here).
I think there's alot you don't understand about DNSBLs.
> Quite honestly, it is a subtle form of discrimination in that DNSBL
> maintainers can, by their actions, make certain broadband providers
> less desirable due to the fact that their network connection is now
> "tainted".
If you live in an IP ghetto, complain to your landlord or move. Don't
blame the DNSBLs for calling a spade a spade.
Besides, the DNSBL data I'm using for IMP blocking is almost entirely
machine generated (not some lazy DNSBL operator) via spamtraps and actual
open proxy testing in response to received mail.
Now, sure, it would be really foolish to use any DUL sort of DNSBL for
blocking access to IMP, but that's not the DNSBL's fault...it's just a
foolish application of the data.
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Jon Lewis
> Well, I know that sendmail has a configuration item for this. Unless you're
> running some kind of mailing list, there's little good reason to allow more
> than 40 recipients in a given email transaction.
I knew sendmail had this feature, though I'm unsure if it's applied to a
locally invoked sendmail vs an SMTP session. That was why I started out
trying to hack it into qmail. I gave up when I couldn't get my hacked up
qmail/sendmail to link. Doing it in IMP turned out to be much simpler and
has the advantage of being portable to any mailer system.
Michael M Slusarz
> Zitat von Michael M Slusarz <slu...@mail.curecanti.org>:
>
>>
>> DNSBL is a *very bad thing*. See
>> http://www.acme.com/mail_filtering/shame_frameset.html for a good
>> description of the issues.
>>
>> Personal example: user sets up a machine on a home-based network that
>> is on a business broadbank link (i.e. small business operator from
>> home). The business broadband provider also happens to provide home
>> broadband support also. Complete idiot DNSBL maintainers blacklist the
>> user's address because a few (most definitely not all or even some)
>> users on the home broadband have either infected computers or are doing
>> bad things. Therefore, because DNSBL maintainers are lazy or
>> uneducated or both, instead of marking the individual addresses as bad
>> they instead mark the entire block of addresses registered to the
>> broadband provider as "bad" (We are talking entire Class C blocks
>> here). Since broadband provider does not provide information on how
>> their blocks are allocated, businesses lose the ability to run their
>> own servers due to ineptitude of DNSBL maintainers.
>>
>> Quite honestly, it is a subtle form of discrimination in that DNSBL
>> maintainers can, by their actions, make certain broadband providers
>> less desirable due to the fact that their network connection is now
>> "tainted".
>
> Let's do not go for this discussion again. Not DNSBL are bad, but using them
> without understanding what they do is. At least read and understand the
> listing/delisting policy and choose if it matches your requirements.
You completely misread what I wrote. The issue is that most users
*can't* read or select the listing/delisting policy because they have
no choice. I have no say in whether *your* provider uses DNSBL, but
that choice directly affects *me*. Simply because your provider uses a
DNSBL that has lazily adopted the idea that "all mail that come from
(supposed) dynamic home IP address blocks" (even though there
information is incorrect) should be blocked now means that I can't send
you emails. stupid. But this list is not the place to start a flame
war on this topic so I promise I will shut up now.
michael
_______________________________________
Michael Slusarz [slu...@curecanti.org]
Kevin Myer
> I knew sendmail had this feature, though I'm unsure if it's applied to a
> locally invoked sendmail vs an SMTP session. That was why I started out
> trying to hack it into qmail. I gave up when I couldn't get my hacked up
> qmail/sendmail to link. Doing it in IMP turned out to be much simpler and
> has the advantage of being portable to any mailer system.
But IMP isn't a MTA. If you need recipient count limitations, pick a MTA that
provides that feature. If your MTA doesn't provide support for that, and the
feature is important enough to you, choose a MTA that does.
I guess I missed something in this thread - how is it that spammers are
getting
access to IMP in the first place?
Kevin
--
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13 http://www.iu13.org
Jon Lewis
> I guess I missed something in this thread - how is it that spammers are
> getting access to IMP in the first place?
They're signing up for accounts using stolen credit cards / credit card
info. I don't know how they get it, but they have card numbers,
expiration dates, CVV2 codes from the backs of the cards, and the billing
address info.
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________