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

["Fischer, Kai" <[e-mail]>]

> 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).


> -----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