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

[Hannes Tschofenig <[e-mail]>]

Hi Kai,

Fischer, Kai wrote:
>> 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....)
>>     
>
> I don't assume that the sender of spam usually is a person I personally
> know and whom I want to contact directly (still more personal
> disturbance and effort). Applying very restrictive white lists allowing
> only personal known people to contact me may be yes, but I expect that
> this is not usual scenario (I have no email white list).
>
>   

The spammer is not known; however, for the case we are considering here 
the account of someone from your buddy list is being used for spamming. 
If you are spamming me then I would obviously get in touch with you and 
ask you what you want.

It is true that you have no email white list -- this is, however, a 
drawback for email that we don't need to repeat again.
Consider Instant Messaging, for example, many people us a mixture 
between white lists and black lists. Very common today!
For the PSTN there are obviously no white lists either

Ciao
Hannes

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