Koozali.org: home of the SME Server
Obsolete Releases => SME Server 8.x => Topic started by: Bozely on November 25, 2015, 03:21:02 PM
-
We have been receiving a consistent low volume of spam of late which often is not too difficult to identify. This particular example, however, beyond the username and password being compromised, has me stumped. I see no (smtp-auth username [username], mechanism login) in the header and it neither appears to have been generated locally which has me wondering how it ever got delivered...
Return-Path: <HR@direct-eng.com>
Delivered-To: maillog@directserv01.mail.direct-eng.com
Received: (qmail 15345 invoked by alias); 23 Nov 2015 09:06:41 -0000
Delivered-To: alias-localdelivery-maillog@mail.direct-eng.com
Received: (qmail 15339 invoked by uid 453); 23 Nov 2015 09:06:41 -0000
X-Spam-Level: *
X-Spam-Status: No, hits=0.0 required=4.0
tests=FSL_HELO_NON_FQDN_1,MIME_QP_LONG_LINE
X-Spam-Check-By: mail.direct-eng.com
Received: from Unknown (HELO [10.17.57.102]) (37.245.168.233)
by mail.direct-eng.com (qpsmtpd/0.84) with ESMTP; Mon, 23 Nov 2015 09:06:39 +0000
From: HR@direct-eng.com
To: johnhill@direct-eng.com
Subject: Employee Documents – Internal Use
Date: Mon, 23 Nov 2015 13:05:51 +0400
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="Mark=_2015112317334673iiQQnum"
X-Mailer: Print Manager v1.10.305.20037
Accept-Language: en-US
Content-Language: en-US
Message-ID: <2015112398306308YLyGXce@direct-eng.com>
Envelope-To: <johnhill@direct-eng.com>
X-Copied-To: maillog
X-Virus-Checked: Checked by ClamAV on mail.direct-eng.com
I would appreciate any insights in to the above header and any anti-spam suggestions that are not implemented outside of the vanilla SME setup.
Since this message I have configured SPF, we use SpamAssassin, LearnAsSpam and Bayesian Autolearning and the RBL blacklists. We disabled the SBL functionality as it was generating too many false positives.
Currently we are referencing RBLList=2.0.0.127.b.barracudacentral.org:zen.spamhaus.org:whois.rfc-ignorant .
Thanks.
-
We have been receiving a consistent low volume of spam of late which often is not too difficult to identify. This particular example, however, beyond the username and password being compromised, has me stumped. I see no (smtp-auth username [username], mechanism login) in the header and it neither appears to have been generated locally which has me wondering how it ever got delivered...I would appreciate any insights in to the above header and any anti-spam suggestions that are not implemented outside of the vanilla SME setup.
First thing is to look in the logs and match the email to the log entry so you can see where it is coming from
Have a look at /var/log/qpsmtpd/current
I usually do something like
grep 10.17.57.1002 /var/log/qpsmtpd/current
Look for the number after the date and time e.g. here 5934
2015-11-26 00:25:36.048624500 5934 dispatching
Now you can do
cat /var/log/qpsmtpd/current |tai64nlocal |grep 5934
or
grep 5934 /var/log/qpsmtpd/current |tai64nlocal
(tai64nlocal unravels the cryptic date)
That should be the transaction log for that mail
Remove anything sensitive and paste it here so someone can take a look - note that 'current' may rotate quickly so you might have to either pick a newer mail or hunt through some of the other files in there.
B. Rgds
John
PS - Charlie will correct me if I am wrong :-)
-
Thanks for the reply John,
2015-11-23 09:05:56.316620500 14847 Accepted connection 1/40 from 37.245.168.233 / Unknown
2015-11-23 09:05:56.316691500 14847 Connection from Unknown [37.245.168.233]
2015-11-23 09:05:56.317835500 14847 tls plugin (init): ciphers: HIGH:!SSLv2:!ADH:!aNULL:!MD5:!RC4
2015-11-23 09:05:56.319234500 14847 tls plugin (init): ciphers: HIGH:!SSLv2:!ADH:!aNULL:!MD5:!RC4
2015-11-23 09:05:56.323889500 14847 tls plugin (init): ciphers: HIGH:!SSLv2:!ADH:!aNULL:!MD5:!RC4
2015-11-23 09:05:57.325801500 14847 check_earlytalker plugin (connect): remote host said nothing spontaneous, proceeding
2015-11-23 09:05:57.329875500 14847 220 directserv01.mail.direct-eng.com ESMTP
2015-11-23 09:05:58.340399500 14847 dispatching EHLO [10.17.57.102]
2015-11-23 09:05:58.341570500 14847 250-mail.direct-eng.com Hi Unknown [37.245.168.233]
2015-11-23 09:05:58.341582500 14847 250-PIPELINING
2015-11-23 09:05:58.341608500 14847 250-8BITMIME
2015-11-23 09:05:58.341612500 14847 250-SIZE 20000000
2015-11-23 09:05:58.341617500 14847 250 STARTTLS
2015-11-23 09:06:03.269451500 14847 dispatching MAIL FROM:<HR@direct-eng.com>
2015-11-23 09:06:03.269602500 14847 full from_parameter: FROM:<HR@direct-eng.com>
2015-11-23 09:06:03.485623500 14847 getting mail from <HR@direct-eng.com>
2015-11-23 09:06:03.485671500 14847 250 <HR@direct-eng.com>, sender OK - how exciting to get mail from you!
2015-11-23 09:06:03.485718500 14847 dispatching RCPT TO:<johnhill@direct-eng.com>
2015-11-23 09:06:11.488107500 14847 dnsbl plugin (rcpt): Whitelisthelo not found
2015-11-23 09:06:11.488132500 14847 dnsbl plugin (rcpt): Whitelistsender not found
2015-11-23 09:06:11.489875500 14847 check_goodrcptto plugin (rcpt): stripping '-' extensions
2015-11-23 09:06:11.503462500 14847 250 <johnhill@direct-eng.com>, recipient ok
2015-11-23 09:06:11.503541500 14847 dispatching DATA
2015-11-23 09:06:11.503748500 14847 354 go ahead
2015-11-23 09:06:13.038213500 14847 spooling message to disk
2015-11-23 09:06:39.300766500 14847 bcc plugin (data_post): message copied to maillog
2015-11-23 09:06:41.326442500 14847 spamassassin plugin (data_post): check_spam: No, hits=0.0, required=4.0, tests=FSL_HELO_NON_FQDN_1,MIME_QP_LONG_LINE
2015-11-23 09:06:41.326683500 14847 virus::clamav plugin (data_post): Changing permissions on file to permit scanner access
2015-11-23 09:06:41.366299500 14847 virus::clamav plugin (data_post): clamscan results: /var/spool/qpsmtpd/1448269573:14847:0: OK
2015-11-23 09:06:41.366882500 14847 logging::logterse plugin (queue): ` 37.245.168.233 Unknown [10.17.57.102]<HR@direct-eng.com><johnhill@direct-eng.com>,Mail::Address=ARRAY(0x90c79d4) queued <2015112398306308YLyGXce@direct-eng.com> No, hits=0.0 required=4.0_
2015-11-23 09:06:41.367760500 15339 queue::qmail_2dqueue plugin (queue): (for 14847 ) Queuing qp 15339 to /var/qmail/bin/qmail-queue
2015-11-23 09:06:41.440524500 14847 250 Queued! 1448269601 qp 15339 <2015112398306308YLyGXce@direct-eng.com>
2015-11-23 09:06:41.491135500 3655 cleaning up after 14847
Here's the output from the log files...
Regards,
Brad
-
You received a spam from 37.245.168.233. It's sent to a valid email address (johnhill@direct-eng.com), so no need to auth, as there's no relay, just local delivery. The sender address is just faked
-
Thanks Dan, I guess what threw me off was that the user does not exist, there is no pseudonym for that user and the originating IP is not a valid sending address for our domain.
I guess the next question then is, is there any way to reject emails that claim to be from our domain and are not?
As I understand it, our SPF record will now allow other people to do that for our domain if they are configured to do so but is further configuration required for our own SME install required to do the same check?
-
Thanks for the reply John,
No worries. here to help if we can !
Seems I got some stuff a bit right :-)
Here are my lists
RBLList=bl.spamcop.net:dnsbl-1.uceprotect.net:dnsbl-2.uceprotect.net:psbl.surriel.com:zen.spamhaus.org
SBLList=multi.surbl.org:rhsbl.sorbs.net:black.uribl.com
I don't get many false positives - usually they are from Fasthosts in the UK and I whitelist the addresses with the WBL contrib. uceprotect are the most savage I think (yes I know the debates about them being profiteers etc)
Still get too much junk... I don't use auto learn but I probably should....
I do use geoipblock which kills quite a bit - the IP you have here was in the UAE with no domain name attached so a geoiplook may help depending on where your normal mail and junk comes from.
Daniel, isn't there anything to stop stuff that has no reverse domain ?
e.g
Accepted connection 0/40 from 72.26.200.203 / mail.centos.org
is possibly better than
Accepted connection 1/40 from 37.245.168.233 / Unknown
Just curious.
B. Rgds
John
For a bit of fun, here are geoip senders from my logs (can't attach a plain.tx file)
It's a pain as we get a large amount of junk from the US, but regrettably a few good mails.... I'd block them all if I could :-)
46013 US
13382 GB
11449 RU
9059 VN
7850 IN
4915 DK
4848 PL
4059 CN
3998 EU
3522 TR
3288 RO
2963 FR
2717 DE
1997 BR
1765 CL
1645 IT
1554 MX
1529 ES
1423 NL
1408 MY
1263 JP
1174 SE
1157 ID
996 IR
994 KR
970 PK
862 AR
778 IL
758 TW
743 TH
-
As I understand it, our SPF record will now allow other people to do that for our domain if they are configured to do so but is further configuration required for our own SME install required to do the same check?
Yes, there are ways to block this, even if it's not enabled by default. Here's how I do this:
Create /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0/30check_spf
{
my $spf = $qpsmtpd{'CheckSPF'} || 'disabled';
return '' unless ($spf =~ m/^[012]$/);
return "sender_permitted_from spf_deny $spf";
}
Now, you can enable SPF verification for email comming from outside with:
db configuration setprop qpsmtpd CheckSPF 1
signal-event email-update
(vallid values are 0, 1, 2, see /usr/share/qpsmtpd/plugins/sender_permitted_from for details).
Ok, now you can check emails are indeed sent by the permitted host, but this won't work for your own domains, simply because for your own domains, your SME Server is usually the DNS server, which has no SPF entries. Lets fix this:
Create /etc/e-smith/templates-custom/var/service/tinydns/root/data/85Spf
{
if (($qpsmtpd{RejectSpoofedLocalDomains} || 'disabled') eq 'enabled'){
$OUT .= "# SPF entries for local domains\n";
my $allowed = '';
foreach my $ip ( split /[;,]/, ($qpsmtpd{AllowedRemoteIP} || '')){
$allowed .= 'ip4\072'.$ip.' ';
}
foreach my $domain (get_domains()){
$OUT .= "'$domain:v=spf1 mx $allowed-all:3600\n";
$OUT .= ":$domain:99:\041v=spf1 mx $allowed-all:3600\n";
}
}
else{
$OUT .= "\n";
}
}
Now, you can configure SME to reject emails if the sender is using one of your locally managed domain
db configuration setprop qpsmtpd RejectSpoofedLocalDomains enabled
signal-event domain-modify
But, if you happen to have an external server which should be allowed to use one of your domain, you can allow it:
db configuration setprop qpsmtpd AllowedRemoteIP 12.13.14.15,25.26.27.28
signal-event domain-modify
-
Merci de votre aide :D
Final question (I think!). What is the behaviour of this setup for domains sending emails to our server but do not currently have an SPF record defined?
Regards,
Brad
-
they won't be rejected by SPF checks, but all other filtering plugins still applies
-
SBLList=multi.surbl.org:rhsbl.sorbs.net:black.uribl.com
For what it's worth, I recently added 'dbl.spamhaus.org' to my SBLList, which has been very good at blocking spam. Before adding spamhaus I did not think the rhsbl plugin did anything useful; after adding it the rhsbl plugin is blocking 50%+ of the email coming in to my server:
check_badmailfrom_patterns {Total} 392 (10.6%)
check_earlytalker {Total} 10 (0.3%)
check_goodrcptto {Total} 47 (1.3%)
check_spamhelo {Total} 3 (0.1%)
dnsbl {Total} 518 (14.0%)
queued {Total} 644 (17.4%)
rhsbl {Total} 2078 (56.2%)
spamassassin {Total} 1 (0.0%)
tls {Total} 2 (0.1%)
{{Total}} 3695 (100.0%)
-
For what it's worth, I recently added 'dbl.spamhaus.org' to my SBLList, which has been very good at blocking spam. Before adding spamhaus I did not think the rhsbl plugin did anything useful; after adding it the rhsbl plugin is blocking 50%+ of the email coming in to my server:
Nice - I'll give it a whirl thanks !
What's your groovy little script to test that ?
-
What's your groovy little script to test that ?
http://wiki.contribs.org/Email_Statistics#Count_emails_by_TLD_and_disposition_for_today_and_yesterday
-
Daniel
Yes, there are ways to block this, even if it's not enabled by default. Here's how I do this:
Create /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0/30check_spf
{
my $spf = $qpsmtpd{'CheckSPF'} || 'disabled';
return '' unless ($spf =~ m/^[012]$/);
return "sender_permitted_from spf_deny $spf";
}
How does this differ from the wiki instructions http://wiki.contribs.org/Email#SPF_mail_rejection.2Fflagging_policy (http://wiki.contribs.org/Email#SPF_mail_rejection.2Fflagging_policy) ?
Your method above ( correct me if wrong ) deems to be the "correct way" to apply what I've linked to above , in that it allows one to enable / disable the feature with db config commands ???
does the wiki need updating ?
-
Yes, it's the same thing, with a db key to control it. Better than just wiki updating, this could be a NFR.