Re: NDRs from spamming

["Bradley D. Moore" <brad.moore () circlecity net>]

I have been dealing with issues like this for more than a year now, coming 
from far-eastern subnets.  I too have found the reporting channels quite 
unresponsive, but since I don't speak chinese/korean, nor have access to a 
translator, I send off the obligatory notification to "abuse," add the entire 
network (and sometimes other networks of the same owner, based on apnic/krnic 
lookups) to the gateway router ACL.  

I've provided output from a "show access-list" command from one of my 
customers, to enhance the short list of networks I've seen so far on this 
thread.

In the example below, I drop *all* traffic from the offending networks (not 
just port 25) - but this particular customer provides a *very* local service, 
and so does not really need to be accessable from the world.  Also, this 
example comes from a customer running an out-of-date GroupWise (5.5) system 
that delivered about 4x the normal amount of NDRs for a mis-addressed 
message.  BTW - That's the same version of GroupWise that gets you on ORDB 
(or used to) because it acts like it accepts relays (220) but then drops them 
as undeliverable, and of course sends NDRs to admin.  So...this particular e-
mail server *looks* like a good spam target if you just test for a 220 on an 
off-domain address.  Needless to say, this draws a lot of relay attempts.  As 
you can see in the output below, I still take numerous hits from some of 
these sources.

One down-side to this approach is that, sooner or later, you run into a 
legitimate host/subnet that you have to make an exception for.  But when my 
customer got sick of cleaning 2000+ messages/day out of the admin mailbox, I 
started getting a little more "broad" with my ACLs.

(B.)

-----OUTPUT FROM show access-list-----
deny ip 61.72.0.0 0.7.255.255 any log-input (89 matches)
deny ip 61.80.0.0 0.1.255.255 any log-input
deny ip 61.82.0.0 0.1.255.255 any log-input (28 matches)
deny ip 61.84.0.0 0.1.255.255 any log-input
deny ip 61.30.0.0 0.0.255.255 any log-input
deny ip 61.98.134.0 0.0.0.255 any log-input
deny ip 61.0.0.0 0.255.255.255 any log-input (2353 matches)
deny ip 128.134.0.0 0.0.255.255 any log-input
deny ip 203.232.0.0 0.0.255.255 any log-input
deny ip 210.123.0.0 0.0.255.255 any log-input (2 matches)
deny ip 210.58.0.0 0.0.255.255 any log-input
deny ip 210.0.0.0 0.255.255.255 any log-input (19344 matches)
deny ip 211.104.0.0 0.7.255.255 any log-input (134 matches)
deny ip 211.192.0.0 0.7.255.255 any log-input (7 matches)
deny ip 211.216.0.0 0.7.255.255 any log-input (76 matches)
deny ip 211.224.0.0 0.7.255.255 any log-input (68 matches)
deny ip 211.0.0.0 0.255.255.255 any log-input (1964 matches)
deny ip 130.94.0.0 0.0.255.255 any log-input (346 matches)
deny ip 209.19.192.0 0.0.63.255 any log-input
deny ip 216.113.192.0 0.0.31.255 any log-input
deny ip 218.184.0.0 0.0.255.255 any log-input (4 matches)


-------------------------------------
It's easier to take it apart than to put it back together.
                -- Washlesky
-------------------------------------
Bradley D. Moore, CNE, CCDA, CCNA
brad.moore () circlecity net
317-577-1189 (Ph)
317-577-1169 (Fx)
-------------------------------------
PGP Public Key: http://www.circlecity.net/brad.moore.asc
PGP Fingerprint: 347D 05BB 56D4 0675 5D2C F3A6 42AA B1B0 F4BD 610B



---------- Original Message -----------
From: "James C. Slora Jr." <Jim.Slora () phra com>
To: <incidents () securityfocus com>
Sent: Fri, 19 Sep 2003 10:25:47 -0400
Subject: Re: NDRs from spamming

> Justin Cooksey wrote
>
> > I have recently had exactly this problem on two independent systems that
> > I help maintain. One using Exchange 5.5 SP3, the other Exchange 2000 SP3.
> > Both systems are not open relays.
> > Both systems are free from known viri, at the date the incidents were
> noticed.
> > Both had well over 1000 NDRs in the queues when we stopped SMTP services.
>
> > I guess one solution is to disable any and all NDR ?
>
> NDR is pretty worthless nowadays IMO. Most are for spam anyway. 
> Sending NDRs just lets the spammers validate their address lists - 
> they send mail to impossible addresses fishing for NDRs, then send 
> mail to their normal recipients to see if the response is different.
>
> Also, if all the sender information is faked by the spammer or the message
> was sent through a proxy, your NDR does not even go to the people 
> who tried to send the mail - so you either are left with 
> undeliverable NDRs or you end up bombarding the victim of a joe job.
>
> One method of handling the badly addressed mail is to add the bogus
> recipient addresses into a bitbucket mailbox. If you can afford the 
> time for manual NDR decisions you can notify legitimate senders and 
> send the rest to the bitbucket.
>
> > I have found that all these Reverse NDR are coming from Chinese subnets,
> > and have simply blocked these subnets from seeing the two systems.
> > Perhaps a bit of overkill as a solution, but it definitely worked.
>
> > The following are the subnets I have blocked:
> > 218.70.0.0/255.255.0.0
> > 211.158.32.0/255.255.248.0
> > 211.158.80.0/255.255.248.0
>
> > I'm hesitant to send complaints to the listed emails for these subnets.
> > I'm just not sure if it will be taken seriously.  Does anyone have an
> > opinion on the worth of sending complaints????
>
> Complaints are not helpful, but notifications to responsible and ethical
> admins are ;)
>
> It takes plenty of research to determine whether there is a 
> responsible and ethical upstream contact for spam sources. You will 
> probably also need help from a Chinese speaker to communicate 
> effectively with the source contacts. English has generally not been 
> useful to me in dealing with far east domains, but others have 
> reported success when they communicate in the native language of 
> their contacts.
>
> FWIW I'd rather block spam sources than try to navigate the abuse 
> process, since spam is a well-funded commercial and criminal 
> enterprise with high-level support around the world. I save my 
> reporting time for the script kiddies and worms, where smaller 
> effort can reap larger rewards.
>
> ---------------------------------------------------------------------------
> Attend Black Hat Briefings & Training Federal, September 29-30 
> (Training), October 1-2 (Briefings) in Tysons Corner, VA; the 
> world's premier technical IT security event.  Modeled after the 
> famous Black Hat event in Las Vegas! 6 tracks, 12 training sessions, 
> top speakers and sponsors.  Symantec is the Diamond sponsor.  Early-
> bird registration ends September 6.Visit us: www.blackhat.com
> ----------------------------------------------------------------------------
------- End of Original Message -------


---------------------------------------------------------------------------
----------------------------------------------------------------------------