Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter

[Hannes Tschofenig <[e-mail]>]

I think we should put Henning's classification somewhere in our documents.

I had a chat with Peter Saint-Andre this week and he reported me about 
problems they had with malicious users (potentially using the XMPP 
servers for file sharing) in their XMPP server infrastructure. He told 
me that their community is looking into a mechanism to allow one domain 
to report problems to another domain. This would correspond to Henning's 
2nd category below and a mechanisms similar to the one described in 
http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-00.txt 
would be useful (expect that it would not be run between the end host 
and the VoIP provider but between two VoIP providers).

Ciao
Hannes

PS: I put Peter on CC in case I misunderstood something.

Henning Schulzrinne wrote:
> There are three sub-cases of bot nets:
>
> - Just uses host, without credentials: identity-based whitelisting  
> works (subject to the usual problems with whitelisting)
>
> - Uses credentials, but spews randomly: unlikely that the recipient  
> will have that person in their whitelist, so still manageable.
>
> - Uses credentials, spams addresses in addressbook: whitelists don't  
> help, but at least the sender can be identified and fixed/fined/taken  
> offline.
>
> I'm not trying to downplay bot nets, just that this is a bit more  
> nuanced.
>
> Henning
>
> On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote:
>
>   
>> Dan,
>>
>> I am afraid that we may have to hit the ground running. Email spam  
>> is already a big industry with well established operators. Spewing  
>> out SPIT instead of email spam is just another ‘product’ for them.  
>> Only amateur SPITers will use spitter and other such tools – the  
>> professional ones already have the infrastructure in place and  
>> they’d be irrational not to reuse it for SPIT – they will just short- 
>> circuit to your step 5.  We do need to think deeply about botnets –  
>> they are the principal means of sending spam and have been for at  
>> least the last 2 years.
>>
>> Regards,
>>
>> Brian Azzopardi - Senior Business Analyst
>> GFI Software - www.gfi.com
>>
>>
>> From: [e-mail] [mailto:[e-mail]] On  
>> Behalf Of Dan York
>> Sent: 19 February 2008 21:24
>> To: Juergen Quittek
>> Cc: [e-mail]; Signaling TO Prevent SPIT
>> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter
>>
>> Juergen (and Saverio and others),
>>
>> I appreciate the point you are raising here.  My interest and  
>> passion are in networking, communication and security.  To me,  
>> botnets are both incredibly fascinating and incredibly terrifying.   
>> I agree with you that botnets very certainly may be the biggest  
>> source of SIP spam in the future.
>>
>> Here's my problem:
>>
>>      We have to crawl before we can walk and before we can run.
>>
>> Let's say that this is the (incredibly simplistic view of the)  
>> evolution of email spam:
>>
>> 1. Someone figures out that they can send advertisements to a range  
>> of email addresses they have collected.
>> 2. Someone realizes that they can add those addresses to a "mailing  
>> list" to easily send to a large number of addresses.
>> 3. Tools are developed that automate the collection of addresses and  
>> the sending out of messages.
>> 4. At a certain time, there are enough people using email out there  
>> that this whole area of email advertising is a huge financial  
>> marketplace. Companies/entities set up server farms to just send out  
>> tons of email messages. (Defenders blacklist those servers.)
>> 5. Those "servers" get distributed into massive botnets and are then  
>> able to avoid blacklisting, etc.
>>
>> I have absolutely no doubt that SIP spam will unfortunately follow  
>> the exact same trajectory. We're already seeing the tools to  
>> automate SPIT (here's one: http://www.hackingvoip.com/tools/spitter.tar.gz 
>>  ).  At some point we will hit my #4 when there are enough people  
>> using SIP *with publicly accessible SIP addresses* that it becomes  
>> financially lucrative enough for the larger automation to occur -  
>> and following on the heels of that will be the botnets.  It will  
>> happen.  To me it's not a question of IF but rather WHEN.
>>
>> Right now, though, we're still in my steps 1-3 as people start to  
>> get SIP endpoints and realize how they can abuse them.
>>
>> My concern about adding the focus on botnets into RUCUS is the fact  
>> that we can easily get distracted into looking at how to solve  
>> bigger issues and not get done the smaller issues that we can  
>> perhaps address today.
>>
>> Let's face it, probably all of us on this list would be categorized  
>> as early adopters who like to explore cutting edge technologies.  We  
>> like to chase bright shiny objects and what is new and sexy and  
>> interesting.  Let's say that you have a choice at the next IETF to  
>> listen to either:
>> 1. a presentation on a SIP header to pass a "spam score" value  
>> between a SIP proxy and a UA; or
>> 2. a presentation about SIP botnets, how they are constructed and  
>> the threats they pose.
>> I would expect that probably 90% of us would choose the botnet talk.  
>> (No disrespect intended to the spam-score folks, just using an  
>> example.) The reality, though, is that the spam score discussion  
>> might be far more useful in moving us toward solutions that will  
>> help us with the people abusing SIP systems today.  I don't want to  
>> wake up some day and find out that while we've been having a ton of  
>> discussions about botnets, some idiot meanwhile is repeatedly  
>> connecting to my SIP server and pumping our voicemail system full of  
>> SPIT.
>>
>> Maybe it's crazy on my part, but I want to see RUCUS have a charter  
>> that results in an achievable plan and architecture.
>>
>> Yes, we should consider botnets as a potential source of SIP spam  
>> and, yes, the potential existence of SIP botnets should be included  
>> in our thinking about an architecture to address SIP spam (so that  
>> any architecture we come up with does not discount dealing with  
>> botnets).  But I also think we need to stay focused on what we can  
>> do now about the threats that are out there today (before it's too  
>> late).   Let's crawl first, then walk, then run.
>>
>> My 2 cents,
>> Dan
>>
>> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote:
>> Today, most of the spam email comes from bot-nets and recently
>> email spammers started to send massively from compromized
>> valid email accounts.  I do not see why this would not become
>> also the biggest source of SIP spam in the future.
>>
>> Consequently, we should address this issue when developing an
>> architecture for reducing SIP spam in the RUCUS WG.  The
>> architecture should be general enough for covering also means
>> that reduce SIP spam from bot nets and compromized accounts
>>
>> Whether or not to work on this problem is being discussed
>> highly controversially in the IETF. But considering that the
>> RUCUS BoF is targeted at establishing not a regular working
>> group, but an RFC 5111 Exploratory Group, I do not think it
>> would be appropriate to exclude such work from the beginning.
>>
>> It should rather be part of the exploratory work to find out
>> whether or not reducing SIP spam from bot nets is a target
>> worth to be attacked by the IETF.
>>
>> -- 
>> Dan York, CISSP, Director of Emerging Communication Technology
>> Office of the CTO    Voxeo Corporation     [e-mail]
>> Phone: [phone]  Skype: danyork  http://www.voxeo.com
>> Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com
>>
>> Bring your web applications to the phone.
>> Find out how at http://evolution.voxeo.com
>>
>>
>>
>>
>>
>>
>> DISCLAIMER
>> The information contained in this electronic mail may be  
>> confidential or legally privileged. It is for the intended  
>> recipient(s) only. Should you receive this message in error, please  
>> notify the sender by replying to this mail. Unless expressly stated,  
>> opinions in this message are those of the individual sender and not  
>> of GFI. Unauthorized use of the contents is strictly prohibited.  
>> While all care has been taken, GFI is not responsible for the  
>> integrity of the contents of this electronic mail and any  
>> attachments included within.
>>
>> This mail was checked for viruses by GFI MailSecurity. GFI also  
>> develops anti-spam software (GFI MailEssentials), a fax server (GFI  
>> FAXmaker), and network security and management software (GFI  
>> LANguard) - www.gfi.com
>>
>> _______________________________________________
>> Rucus mailing list
>> [e-mail]
>> http://www.ietf.org/mailman/listinfo/rucus
>>     
>
> _______________________________________________
> spitstop mailing list
> [e-mail]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
>   

_______________________________________________
Rucus mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/rucus