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

[Hannes Tschofenig <[e-mail]>]

Hi Jan,


Jan Seedorf wrote:
> Dear Hannes,
>
>   
>> I think we should put Henning's classification somewhere in 
>> our documents.
>>     
> I also like Henning's classification because it narrows down where the problem with botnets regarding SPIT is.
>
>   
>>> - Uses credentials, spams addresses in addressbook: 
>>>       
>> whitelists don't 
>>     
>>> help, but at least the sender can be identified and 
>>>       
>> fixed/fined/taken 
>>     
>>> offline.
>>>       
> I fully agree: this is the problem and the "compromised identity" then needs to be identified and blocked. One question then is, how can we share the identification of a not-trustworthy identity (as perceived by end-users or domains) among SIP-entities/domains. One building block I see here clearly is
> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-00.txt
>   

Let's take an example:
When Henning's host is compromised and a bot is using Henning's account 
to send me spam then I would contact Henning (by using various ways) to 
tell him that something is wrong with his PC/phone/etc. I would not tell 
my VoIP provider that there is something wrong with Henning's account. 
Typically, this will lead to more problems rather than less -- such as 
no communication to Columbia University anymore because my VoIP provider 
just blocks all calls from that domain.

(Just to reflect my experience with email problems in the company....)

> for giving users the possibility to indicate that some identity may not be trustworthy anymore (e.g., because it got compromised in the sense Henning describes above). Additionally,
> http://tools.ietf.org/html/draft-wing-sipping-spam-score-01
> and
> http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semantics-00.txt
> offer a solution for signalling such information between entities. Note that in the semantics draft we tried to point the importance of having a precise meaning associated with a SPIT score.
>   

I haven't read draft-seedorf-sipping-spam-score-semantics-00.txt yet. 
Comments later.


Ciao
Hannes

>  - Jan
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of 
>> Hannes Tschofenig
>> Sent: Friday, February 22, 2008 12:16 PM
>> To: Signaling TO Prevent SPIT
>> Cc: Brian Azzopardi; [e-mail]; Juergen Quittek
>> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft 
>> RUCUS charter
>>
>> 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-sp
>> am-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
>>>   
>>>       
>> _______________________________________________
>> 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