[CLUE-Tech] SMTP relay attempts - what to do?

[Dave Hahn]

Although I'm philosophically against the Open SMTP Relay / SMTP Probing 
problem Jeff has sited, performing port scans of remote machines without 
permission is seen by many people as tantamount to the beginning of an 
attack.  (Software like portsentry is designed to specifically black 
ball IPs performing this action.) So, someone watching traffic over the 
wire may consider the below action just as bad as scanning for open SMTP 
relays or worse.

Looking at Jeff's traffic, the orblist at seed.net.tw could be one of the 
Open Relay Black List (orblist) systems, checking to see if your SMTP 
software is allowing relaying.  These types of tests are used to build 
and verify many of the RBL lists used by tools like SpamAssassin.  This 
the asks the question, should the ORBL lists be doing this type of 
scanning?  The answer is that someone has to in order to be proactive 
about open relays. 

The second connection definitely looks a little funny tho' - ISP 
subscribers, generally, should only be connecting to their ISPs mail 
servers.  (Expect for my qmail server at home of course ;-) )

What would prove to be another useful bit of information is if the 
source IP address attempted connections to any other ports the machine.

As to getting any action from the ISP of the second connection 
(Level3.net) best of luck.  I'm convinced their abuse e-mail box and 
phone mail box are blackholes.

-d

Mike Staver wrote:

>Well, I am also on your side about doing anything you can to fight this 
>kind of thing, but here's the problem I see - can you prove they are 
>spamming, or simply just trying to send some mail, and some how stumbled 
>along your smtp server?  We all know what is going on, but proving it may 
>be harder - and like you said, they probably just have a dial up account 
>for the weekend via some "owned" box out there that became the subject of 
>a trojan windoze virus - so it will probably be extremely hard to get any 
>action taken.  
>
>Now, I'm all in favor of *other* ways to go about this sort of thing.  I'm 
>no hacker, but a few quick port scans of that ip may give you some 
>information you might need to make this spammers life a little harder this 
>weekend.  Not that I condone such practices.... but there are known ways 
>to bring down a box such as this one:
>
>Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2003-12-05 23:10 
>MST
>Host dialup-67.73.1.44.Dial1.LosAngeles1.Level3.net (67.73.1.44) appears 
>to be up ... good.
>Initiating SYN Stealth Scan against 
>dialup-67.73.1.44.Dial1.LosAngeles1.Level3.net (67.73.1.44) at 23:10
>Adding open port 5000/tcp
>Adding open port 5101/tcp
>Adding open port 1025/tcp
>Adding open port 135/tcp
>Adding open port 445/tcp
>Adding open port 707/tcp
>The SYN Stealth Scan took 34 seconds to scan 1657 ports.
>For OSScan assuming that port 135 is open and port 1 is closed and neither 
>are firewalled
>Insufficient responses for TCP sequencing (3), OS detection may be less 
>accurate
>Interesting ports on dialup-67.73.1.44.Dial1.LosAngeles1.Level3.net 
>(67.73.1.44):
>(The 1651 ports scanned but not shown below are in state: closed)
>PORT     STATE SERVICE
>135/tcp  open  msrpc
>445/tcp  open  microsoft-ds
>707/tcp  open  unknown
>1025/tcp open  NFS-or-IIS
>5000/tcp open  UPnP
>5101/tcp open  admdog
>Device type: general purpose
>Running: Microsoft Windows NT/2K/XP
>OS details: Microsoft Windows 2000 Professional, Microsoft Windows 2000 
>SP1
>IPID Sequence Generation: Busy server or unknown class
>
>Nmap run completed -- 1 IP address (1 host up) scanned in 39.112 seconds
>
>The problem with that though, is that this is probably some poor 80 year 
>old man's computer who won't know what to do if it dies.  On the other 
>hand, it could be a spammer using a stolen dial up account with his own 
>computer.  Tough call.
>
>On Fri, 5 Dec 2003, Jeff Cann wrote:
>
>  
>
>>Date: Fri, 5 Dec 2003 22:30:52 -0700
>>From: Jeff Cann <j.cann at isuma.org>
>>Reply-To: clue-tech at clue.denver.co.us
>>To: clue-tech at clue.denver.co.us
>>Subject: [CLUE-Tech] SMTP relay attempts - what to do?
>>
>>Greetings.
>>
>>I have SASL configured to work with postfix SMTP - just turned it on this 
>>morning.   Only authenticated users are allowed to relay, which I confirmed 
>>via testing.  Already, I'm seeing attempts by random spam scum to use my SMTP 
>>server:
>>
>>Dec  2 08:02:55 bluespark postfix/smtpd[25652]: reject: RCPT from 
>>unknown[210.202.214.141]: 554 <orblist at seed.net.tw>: Recipient address 
>>rejected: Relay access denied; from=<orblist at mail.apol.com.tw> 
>>to=<orblist at seed.net.tw>
>>
>>Dec  5 09:09:59 bluespark postfix/smtpd[29596]: reject: RCPT from 
>>dialup-67.73.1.44.Dial1.LosAngeles1.Level3.net[67.73.1.44]: 554 
>><billpike37 at inbox.lv>: Recipient address rejected: Relay access denied; 
>>from=<mjkiw at starzentrale.de> to=<billpike37 at inbox.lv>
>>
>>My question:  Should I do anything about this folks, such as report their 
>>actions to their ISP?  My guess is that since it's friday night, these 
>>scumbags get a dialup account and spam for the weekend.  By the time the ISP 
>>sees my message on Monday, it's already too late.
>>
>>They cannot use my SMTP server to relay, since it's not open.  I'm just 
>>philosophically opposed to this bs and I'm wondering what other mail admins 
>>do about it (if anything).
>>
>>Thanks
>>
>>    
>>
>
>  
>