[afnog] UCEPROTECT-Network Level 3
Frank Habicht
geier-lists-afnog at tih.co.tz
Wed Jul 25 05:29:32 UTC 2007
Hello,
So there is this AfriNIC SIG and mailing list "Antispam" and I sent the
below to it.
Alain - is it possible for others to join it?
Your input will be appreciated.
I guess there is a serious limitation with my email-sorting arrangement
based on (qmail style) user-extension at domain.tld addresses.
I have to use that address as sender for sending to the mailing list
(solved that part),
but thus can't send to 2 mailing lists at the same time.
Anybody solved this already? Or should I scrap this arrangement?
No, never heard of procmail.
Frank
-------- Original Message --------
Subject: Re: [afrinic-anti-spam-discuss] Re: [afnog] UCEPROTECT-Network
Level 3
Date: Wed, 25 Jul 2007 08:22:26 +0300
From: Frank Habicht <geier-lists-afrinic-antispam at tih.co.tz>
To: aalain at trstech.net
CC: anti-spam at afrinic.net
References:
<56134.81.199.119.60.1185265377.squirrel at webmail.accesskenya.com>
<46A5DAE3.9030406 at tih.co.tz> <200707241838.02825.aalain at trstech.net>
Hi all,
Thanks Alain for forwarding.
I had intended to include this list in the below email, but didn't work :-(
there are 2 parts to the spam story:
- you don't want to get spam
- you don't want to cause spam (I hope)
I'd like to start with the second - you don't want to cause spam.
I'm not with an ISP. I'm in charge for a smallish corporate network
50-60 PCs, including some outside the main office.
Main IP (NAT) of our main internet connection was blacklisted 2-3 weeks
ago. By "SpamCop"
First I noticed another mail server outside refused email from us. It
didn't say why (in the SMTP dialog) - bad.
Next mail server that refused mail from us said why and gave a link to
spamcop - better.
As soon as i was convinced this wasn't a joke or once-off, I did this:
- allow our own in-house mail server to send emails out (allow outgoing
packets to a destination port tcp:25)
- block every other internal ip from sending emails (packets outgoing to
dest port tcp:25)
..... and log these events!
Note: these should have been done earlier. by myself. I'm also to blame
that we were blacklisted. it would have prevented the blacklisting.
Sure enough: as soon as the rules were in place I saw in the logs one
(always the same) internal IP trying to connect to outside mail servers
(tcp:25).
from the IP I found it was a private laptop of an employee. That was
very quickly disconnected and confiscated. Obviously there was
malware/worms/viruses etc. And I think it is not hard ("soft") to guess
which small ("micro") company produced the operating system... ;-)
note: after blocking it was in my case not too bad to get off this list
- would have gone off anyway after 24 hours, and I had alternate IPs to
use, but a short explanation in their response form about what was done
helped.
For an ISP this can be harder, as clients (customers) may operate their
own mail servers that want to send legitimate emails out.
One possibility: use the ISP's mail server at a smart host or mail
gateway. Second (more likely): allow those few specific IPs that need it
to send out email, but make sure the customers know how to avoid open
relays etc and will adhere to your AUP....
Another trouble:
When you block outgoing connections to port tcp:25 , you are blocking
users in your network visiting from somewhere else. They might need to
use their own email server as outgoing mail server (maybe because of SPF
- below).
But there the solution is to use a MSA - message submission agent on
another port (587) on the far-away server.
This will allow a user to send outgoing email (to relay the mail) - but
only after authentication !!
Of course then the authentication info (passwords) go a long way over
the internet and we should use encryption, so: smtp-ssl on port 465 !
Spammers can also spam with secured email servers, if an authentication
password (&username) leaks out.
[ I once saw a host from a DSL range in Austria make many many attempts
to authenticate with POP3 at my corporate server - sure it wanted to get
passwords ]
Then there's another possibility to avoid spam getting sent in the first
place.
It is controversial and likely not applicable in every situation.
Especially when (automatic) forwarding of emails is involved.
SPF - Sender Policy Framework. I personally like it, but make up your
own mind and choice!
It's designed to let a domain owner specify from which addresses (names,
dns records or IPs) emails from the domain can come out from.
Example: I'm sending this email from domain "tih.co.tz"
There's a special record
tih.co.tz. 86400 IN TXT "'v=spf1"
"ip4:41.222.63.192/28" "ip4:217.172.181.156" "-all'"
for that domain in DNS, specifying possible IPs originating emails from
this domain. And "-all" - meaning "and noone else!".
So a receiving email server (anywhere in the world), if the admin
chooses to look at SPF, can see that if a ..... Kenyan IP address
196.207.17.4 for example connects and tried to send an email from domain
'tih.co.tz' that this is _not_ legitimate.
There are some drawbacks though!
The other part. (not) receiving spam.
1.
I use RBL(s). I think I hear "Spamhaus" is good, but don't quote me,
don't rely on me, mainly because : I don't know why I think so.
I would strongly, hereby and officially, advise against using
"UCEPROTECT" mentioned in the other email(s) including on AfNOG mailing
list.
They are just blocking too much and don't seem to know different /20
netblocks can be with different ISPs and they think they can push it to
the RIR as the police. No.
2.
Greylisting seems to work (I haven't tried it yet), but personally I
believe spammers will catch up with it.
OpenBSD's spamd seems very good and I'd try it when given opportunity.
very mean to spammers.
Also, since spam senders often try to send the spam to backup MX
servers, I believe that:
- 1st choice: not having backup MX
- 2nd choice: have one, on IP in same block with same routing and then
block any ip sending only to backup and not to main MX
(that's just an idea, not sure if it'd work or have bad side-effects)
3.
Spamtrap addresses - addresses no human should send to because on that
webpage you clearly say: send to this address and I consider you a spammer.
The scripts harvesting email addresses don't understand that and store
the email address and will start sending to it. You know: someone
sending to this addres can only be a spammer.
4.
Spamassassin.
At work, I reject in the SMTP dialog at score >10 and tag emails with
>5.5
your milage may vary
But speaking of that....
It is important - very important - to reject in the SMTP dialog.
Don't let your mail server say "250 OK" to a message that is spam.
Say NO or whatever the mail servers said to me when I was blacklisted.
Some servers, including some antispam servers, are accepting the spam.
Then they are generating a bounce. That will likely go to the sender
address... which was forged....
and spam with a bounce an innocent bystander.
And the real bad ones then send another email to the intended recipient
of the original spam saying:
"look I blocked this spam for you" - which is in my eyes generating
spam/advertisements for itself, and it should have happened silently.
I hate these Barracudas!
So: If you're getting spam don't accept it in SMTP!
then the one server trying to send it to you has to take care of the
message.
Either it's the spammer itself - good.
Or it's some server unintentionally helping by not stopping the spam and
we have to push the burden back towards the origin of the spam.
I believe there are many documents and advisories available.
Most things have to be adapted to the local circumstances - everywhere.
I believe for all of us there is something we can do.
- talk to misbehaving RBLs
- if no success: talk to those (email providers(server operators) )
using misbehaving RBLs
(they and their customers should still be intersted in your
legitimate emails)
- we talk to our clients to be responsible and avoid compromised mail
servers or PCs
- network monitoring of SMTP traffic...?
- blocking outgoing port 25 in my opinion, at least for IP ranges like
dialup and DSL where chances of unmanaged compromised Windows hosts are high
- blocking even corporate customers if they are really spamming
(violating your acceptable use policy) - and working with them to
resolve the problem
- start reading email headers, find out ip originating the spam you just
got -- watch out, some headers can be forged, inserted before sending
the spam
- use whois on those addresses.
- the providers keep those whois addresses up-to-date
- when receiving an email complaint about spam on those abuse addresses,
act on them and reply to it... ;-)
And I just remembered an outstanding spam complaint and did send a
reminder on a mailing list ;-)
I hope this can serve as a start.
I hope everyone can contribute.
Don't wait for others to start something. It's up to us.
Now I want to ask a favour.
I have another little project - which caused me not to reply earlier on
this list.
For the project I ask you to send me a list of netblocks (cidr,
196.207.16.0/20, 41.200.4.0/22, etc) peering at the Internet Exchange.
I'd like this to measure some traffic. For common benefit.
If you're not connected to the IXP - why?
If you don't have an IXP - why?
Thanks,
Frank Habicht
On 7/24/2007 9:38 PM, Alain Patrick AINA wrote:
> i expect that this kind of situation clear our mind on what we have to do
> here.
>
> exchanging experience is one thing , but there are more to do.
>
> can this thread acts as starter ?
>
>
> --alain
>
> On Tuesday 24 July 2007 10:56:35 am Frank Habicht wrote:
>
>> On 7/24/2007 11:22 AM, S. Oduor wrote:
>>
>>>> there is no net police agency, sorry. and afrinic is not the police
>>>> agency which does not exist.
>>>>
>>> I dont mean to put afrinic on Internet Police level, but I think they are
>>> better placed than me since I dont own the whole netblock of
>>> 196.207.0.0/16, there lots of folks with smaller subnets on this netblock
>>> suffering Probably some of them are on this list, having one
>>> representation from a bigger entity like afrinic will as a matter of
>>> fact get things moving & we will be focused on other errands trying to
>>> make the internet efficient.
>>>
>>> Besides I think this is a good forum to brain storm on best ways to
>>> combat this kind Crime Perpetrated by UCEPROTECT & many other RBL's that
>>> deflect genuine emails not spams, to me this is no big difference from
>>> hacking or abuse of high level resulting to loss, I already got lots of
>>> rejected mails from my customers affecting their businesses you might
>>> never really know the extent of the damage its impacts are far reaching
>>> when a legit email bounces . One day someone will really think of what
>>> he has done or not done to ensure he is protected by a net police agency
>>> ? the wisdom & influence to get one operational now is really you choice.
>>>
>>>
>>>> contact the folk at whoever is being what you think is mean to your
>>>> packets. nothing else will help you no matter how loudly you scream; in
>>>> fact, screaming reduces one's credibility in the long term.
>>>>
>>> Before screaming I normally prefer mature ways of sorting out a main
>>> problem and this really does help many at times. If you literally happen
>>> to step on my toe I would tell you to step off while holding back my
>>> breath and if it jst happens that I scream am either about to give up or
>>> do something that will ensure I am free from the pain (human nature), I
>>> will try not to scream cauze some good folks are already assisting me &
>>> hope someone who is silently suffering will take up his responsibility. I
>>> hope their provider was here to drop their AS to ensure that RBL is not
>>> reachable.
>>>
>>> UCEPROTECT is demanding 250 Euro payment which I maintain grounds is
>>> stealing either knowingly or unknowingly.
>>>
>>> Their is an Auto whitelist of 7 Days that we can bet is not going to
>>> happen on a block of /16 thats on level 3 owned by different
>>> Organisations, I have been trying to sort this for months now and through
>>> my search I subscribed to AFNOG cauze I trust it has experienced chaps
>>> who have been sorting out internet related problems for ages than
>>> brushing them off in a clever way.
>>>
>> Hello,
>>
>> Now we have at AfriNIC a AnitSpam Bof/SIG/WG/.... (which I'm part
>> of...)
>>
>> This probably means that there is something AfriNIC can (should?) do.
>> Not talking about policing.
>>
>> I agree it is "wrong" what this particular RBL is doing.
>> We can and I believe should be talking and reasoning with them (educate
>> them) - and I believe Bill Woodcock did.
>> If they won't listen, we could publicly name&shame them....
>> you could also take the list of failing destination addresses (those
>> mail domains using the rbl) and tell postmaster@<domain> how bad that
>> rbl is...?
>>
>> This is one thing.
>>
>> We could also (at the same time) look at
>> $ grep 196.207. delegated-afrinic-20070716
>> afrinic|NG|ipv4|196.207.0.0|4096|20050309|allocated
>> afrinic|KE|ipv4|196.207.16.0|4096|20050530|allocated
>> afrinic|ZA|ipv4|196.207.32.0|4096|20050309|assigned
>> afrinic|MU|ipv4|196.207.48.0|4096|20050903|allocated
>> afrinic|NG|ipv4|196.207.128.0|16384|20050118|allocated
>> afrinic|SN|ipv4|196.207.192.0|16384|20050203|allocated
>>
>> run whois and talk to our colleagues. avoid the spam.
>> adapt/read/develop/copy&paste some best current practices ...
>> sorry - and implement!
>> get the antispam wg/sig working (i take ~5% of the blame ;-)
>>
>> So i see some place in the "coordination of efforts" and the education
>> where AfriNIC can play a role.
>> And I'm all in favour of this being bottom-up !
>>
>>
>> Regards,
>>
>> Frank
>> (who should be busy with something else...)
>>
>> PS: Now how do i make this email sendable (acceptable) ?
>> use sender address geier-lists-afrinic-antispam at afrinic.net to
>> submit to the afrinic mailing list
>> or use address geier-lists-afnog at afnog.org to submit to afnog ?
>> or think about receiving recipes and get all list traffic in on one
>> address ...?
>>
>>
>> _______________________________________________
>> afnog mailing list
>> http://afnog.org/mailman/listinfo/afnog
>>
>
>
> _______________________________________________
> anti-spam mailing list
> anti-spam at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/anti-spam
>
More information about the afnog
mailing list