<![CDATA[[SecurityRatty] tag: descriptive]]> http://securityratty.com/tag/descriptive Mon, 10 Mar 2008 22:54:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Blue Box #84: New Cisco, Avaya, Nortel VoIP security vulnerabilities from VoIPShield, Skype in China, UCSniff and other new tools, news and more]]> http://securityratty.com/article/5ad9e83dc3458677a18e9f3f40c0fb21 http://securityratty.com/article/5ad9e83dc3458677a18e9f3f40c0fb21

Synopsis:  Blue Box #84: New Cisco, Avaya, Nortel VoIP security vulnerabilities from VoIPShield, Skype in China, UCSniff and other new tools, news and more

Welcome to Blue Box: The VoIP Security Podcast #84, a 30-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, MB) or subscribe to the RSS feed to download the show automatically. 

You may also listen to this podcast right now:

Show Content:

NOTE: Long-time listeners will note that the show notes above are in a less descriptive form than usual. After almost three years of using one wiki for preparing for our shows, Jonathan and I switched to using a new system and are still working out some of the details that will speed the input into show notes.

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

]]> Mon, 20 Oct 2008 04:32:28 +0000 skype blue box news tools voipshield comments audio comments podcast skype messages Blue Box #84: New Cisco, Avaya, Nortel VoIP security vulnerabilities from VoIPShield, Skype in China, UCSniff and other new tools, news and more <![CDATA[VMWare is Better Than Microsoft]]> http://securityratty.com/article/a030161b183f83f292761020fb04b7d9 http://securityratty.com/article/a030161b183f83f292761020fb04b7d9 After barely surviving the VMworld registration process, my first session was “From Hypervisors to VMware Infrastructure – What Matters?” – or as I would have called it “why VMware is so much better than Microsoft…and if you don’t believe that we can help you make even more money on top of your already successful Microsoft business.” (I know, that title is way too long but quite descriptive.)

The session took place at the beginning of Partner Day. The “regular” conference sessions actually begin tomorrow. Today is spent focusing on partner issues and enablement.

The panel for this session included:

  • Mark Chuang Group Manager, Product Marketing, VMware, Inc.
  • Kenon Owens Staff Systems Engineer, VMware, Inc.

You have to remember that most of the Partners here are not vendors like ScienceLogic, but big and small shops that are selling IT, networking and now virtualization solutions into end-customer environments. For these guys, understanding what virtualization partner programs and tools are at NetApp, for example, is very useful. And many of these companies are already selling Microsoft software and surrounding services for Microsoft products. So if you’re VMware, what’s the message to these partners in the face of the Microsoft juggernaut?

Microsoft to partners: “You may not like to admit it, but you’re probably already in bed with us.”

VMware to partners: “Our hypervisor technology outperforms Hyper-V and Xen, especially at scale. And anyway, it’s not about the battle at the hypervisor. It’s about the V-services on top of the hypervisor – VMotion, Storage VMotion, DRS, etc.”

Interesting and what we all already know, or think we know. The scale issue is an interesting one – too soon for Hyper-V and who uses Xen? But also interestingly enough, no announcement or even talk about extending VMware management tools to other hypervisors. The point, as the VMware product marketing guy made a point of saying, is that the question they needed to answer used to be “Why Virtualization?” and now it’s “Why VMware?”.

One more tidbit – this survey run by VMware asking their customers:

What are the top 6 apps you are running on VMware today

  • IIS
  • Apache
  • Active Directory
  • SQL Server
  • Sharepoint
  • Exchange

That means, 5 of 6 are Microsoft applications. Certainly it makes it even more challenging for VMware to navigate a path here.

The change since 2004 – would have talked about why virtualize. And now why VMware. (Duh.)

Talking to partners – many of which already have a successful Microsoft business. How VMware enhances your existing Microsoft business.

Top 6 apps running on VMware today (5 of 6 are Microsoft applications)

  • IIS
  • Apache
  • AD
  • Sql server
  • Sharepoint
  • Exchange

Source: VMware survey

Esxi - VMware – true thin hypervisor; maximizes resources utilization (over 100% memory commitment – allows avg of 2:1 memory overcommit) – host system memory is usually the resource bottleneck – plus Advanced Scheduler runs VMs better under load and to a greater capacity (hard to show this part); performance acceleration – using binary translation (32bit), para-virtualization and Hardware Assist (for 64-bit)

(rvi – rapid virtualization indexing)

No parent partition that all hypervisors have to go through

Vs ms/xen

Parent partition – dom 0 => potentially problem at scale; i/o that could be a bottleneck

Hyper-v SPECjbb comparison

= 9 vms on VMware and hyper-v hypervisors

Outperform (CPU) by 50% - general purpose scheduler isn’t able to keep up? “got to be”

(cpu only test)

Also used VMmark – to demonstrate again that VMware is performance tuned and designed to run at scale vs Hyper-V

Size Does Matter:

Vmware ESXi: 32MB

Hyper-v – 2.6 GB

Xen – 1.2 GB

Hyper-V uses Microsoft Server Core – so the last two Patch Tuesdays had to make changes to Server Core (nothing to do with Hyper-V) but service interruption for Hyper-V.

VMware VMsafe – “Provides an unprecedented level of security” “virtual is more secure than Real” (uh oh – clearly didn’t read about the

*****************

VMware TEST:512 mb vms on server w/ 4gb ram –

7 vms - xensource (w/no memory overcommit)

6vms – hyper-v before error (w/no memory overcommit)

14vms - w/memory overcommit and management

Running sql io sim – heavy workloads

TCO – not just license; now ESXi is free – so hardware

809 - ESXi

871 – vi3 foundation ($995)

1168- vi3 enterprise ($5750)

1621 – hyper-v – 2x cost because of hw

Xen – 1618

Memory overcommit (89% in production vs. test/dev)

Survey – 37% of respondents at 2:1 RATIO OR HIGHER; real average is around 1.8: 1

*********************

This guy Mark sounds like a used car salesman:

“Always On, On Demand Data Center”

Hypervisor is very important but what is more important are the v-services on top of this. Manage shared, pooled resources. “Value Above the Hypervisor”

How does all this save “your customers” $$?

VMotion – saves cost on planned maintenance: no more overtime, no more time scheduling maintenance windows (see cost framework below)

10 (# of servers) x 6 (@ of updates) x [ (overtime cost 2hrs x $150/hr) + (scheduling downtime # of apps per server 15 x time spend scheduling per app 0.75 hr x $50/hr)] = $58,500

Same thing with using VMware Storage VMotion

Overtime cost + scheduling downtime + planning move + alternative tool cost - $68,750 (2.5 TeraBytes)

The Value of High Availability

- cost of lost business, lost work

- cost of lost productive time

4 hours of downtime x # of users per vm 10 x number of vms per host 15 x cost of user productive time $50/hr x failures per year in 10-host cluster 2 = $60K

(10 servers, 150 vms)

SAVINGS (using enterprise version)

Update management 149,760

HA 60K

DRS, VMotion Storage VMotion 187,250

808,259 – hw, power cooling, etc.

]]> Mon, 15 Sep 2008 19:00:12 +0000 vmware microsoft survey vmware survey vmware enhances vmware infrastructure test vmware test overtime cost 2hrs VMWare is Better Than Microsoft <![CDATA[ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars]]> http://securityratty.com/article/913d52903ceaedff758808be4b11d5bf http://securityratty.com/article/913d52903ceaedff758808be4b11d5bf such as this one, based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy change. But there was confusion over exactly what the policy was; most people just assumed it followed the recommendations of the GNSO council from April. The incomplete information caused some confused analysis such as this from CADNA (the Coalition Against Domain Name Abuse). I asked ICANN and they sent me the actual e-mail that they sent out to registrars. It is published below. My analysis of it is in a column on eWEEK.
Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.

]]> Tue, 08 Jul 2008 11:42:32 +0000 icann directly fees directly fees registrar fees effective effective registrar-level fees fee per-transaction fee ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars <![CDATA[ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars]]> http://securityratty.com/article/1438af7a2605c2bbe5326444d5bd9d27 http://securityratty.com/article/1438af7a2605c2bbe5326444d5bd9d27 such as this one, based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy change. But there was confusion over exactly what the policy was; most people just assumed it followed the recommendations of the GNSO council from April. The incomplete information caused some confused analysis such as this from CADNA (the Coalition Against Domain Name Abuse). I asked ICANN and they sent me the actual e-mail that they sent out to registrars. It is published below. My analysis of it is in a column on eWEEK.
Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.

]]> Tue, 08 Jul 2008 11:42:32 +0000 icann directly fees directly fees registrar fees effective effective registrar-level fees fee per-transaction fee ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars <![CDATA[ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars]]> http://securityratty.com/article/266456c2c42bc5e4cf836f3ca19af1c2 http://securityratty.com/article/266456c2c42bc5e4cf836f3ca19af1c2 such as this one, based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy change. But there was confusion over exactly what the policy was; most people just assumed it followed the recommendations of the GNSO council from April. The incomplete information caused some confused analysis such as this from CADNA (the Coalition Against Domain Name Abuse). I asked ICANN and they sent me the actual e-mail that they sent out to registrars. It is published below. My analysis of it is in a column on eWEEK.
Dear Registrar, This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar. Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP). Please note that this message is a summary of changes that affect registrars. You should refer to the adopted budget document and adopted motions for further information. Summary of Important Timing Issues After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP. Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July 2008 and deleted during the Add Grace Period above a certain minimum threshold. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. The budget assumes the transaction fee rate will remain at US ./send.20. The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion). The implementation timing of this change has not been set, but should be expected to take place over a period of some months. ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation. Budget - Registrar Fees Effective 1 July 2008 The Operating Plan and Budget details for 2008-2009 fiscal year can be found at: http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0 8-en.pdf Relevant section from the approved budget: * Registrar-Level Transaction Fees In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate). The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees. As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command. FY09 revenue is estimated to be .4 million for registrar-level transaction fees. Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g. at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction. n Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year. While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries. (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts. It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario. ICANN Board Resolution Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability. Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater. Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting" , which outlines the full text of the motion and the full context and procedural history of this proceeding. Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget , which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting. Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents. Domain tasting motion approved by the GNSO Council 17 April 2008 Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting; Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting; Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting"); Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting; Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP; The GNSO Council recommends to the ICANN Board of Directors that: 1. The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator"). Specifically, for each Applicable gTLD Operator: a. During any given month, an Applicable gTLD Operator may not offer any refund to a registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater. b. A Registrar may seek an exemption from the application of such restriction in a specific month, upon the documented showing of extraordinary circumstances. For any Registrar requesting such an exemption, the Registrar must confirm in writing to the Registry Operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside of the Registrar's control. Acceptance of any exemption will be at the sole reasonable discretion of the Registry Operator, however "extraordinary circumstances" which reoccur regularly will not be deemed extraordinary. c. In addition to all other reporting requirements to ICANN, each Applicable gTLD Operator shall identify each Registrar that has sought an exemption, along with a brief descriptive identification of the type of extraordinary circumstance and the action (if any) that was taken by the Applicable gTLD Operator. 2. Implementation and execution of these recommendations shall be monitored by the GNSO. Specifically; a. ICANN Staff shall analyze and report to the GNSO at six month intervals for two years after implementation, until such time as the GNSO resolves otherwise, with the goal of determining; i. How effectively and to what extent the policies have been implemented and followed by Registries and Registrars, and ii. Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages, b. The purpose of these monitoring and reporting requirements are to allow the GNSO to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.
]]> Tue, 08 Jul 2008 11:42:32 +0000 icann directly fees directly fees registrar fees effective effective registrar-level fees fee per-transaction fee ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars <![CDATA[China's CERT Annual Security Report - 2007]]> http://securityratty.com/article/8eec1b2624eb89fa1310133e71a9abdb http://securityratty.com/article/8eec1b2624eb89fa1310133e71a9abdb Every coin has two sides, and while China has long embraced unrestricted warfare and people's information warfare for conducting cyber espionage, China's networked infrastructure is also under attack, and is logically used as stepping stone to hit others country's infrastructures, thereby contributing to the possibility to engineer cyber warfare tensions.

A week ago, China's CERT released their annual security report (in Chinese for the time being), outlining the local threatscape with data indicating the increasing efficiency applied by Turkish web site defacement groups, in between the logical increases in spam/phishing and malware related incidents. Here's an excerpt from the report :

"According CNCERT / CC monitoring found that in 2007 China's mainland are implanted into the host Trojans alarming increase in the number of IP is 22 times last year, the Trojans have become the largest Internet hazards. Underground black mature industrial chain for the production and the large number of Trojans wide dissemination provides a very convenient conditions, Trojan horses on the Internet led to the proliferation of a lot of personal information and the privacy of data theft, to the personal reputation and cause serious economic losses; In addition, the Trojans also increasingly being used to steal state secrets and secrets of the state and enterprises incalculable losses, the Chinese mainland are implanted into the Trojan Horse computer controlled source, the majority in China's Taiwan region, the phenomenon has been brought to the agency's attention. Zombie network is still the basic network attacks platform means and resources. 2007 CNCERT / CC sampling found to be infected with a zombie monitoring procedures inside and outside the mainframe amounted to 6.23 million, of which China's mainland has 3.62 million IP addresses were implanted zombie mainframe procedures, and more than 10,000 outside the control server to China Host mainland control. Zombie networks primarily be used launch denial of service (DdoS) attacks, send spam, spread malicious code, as well as theft of the infected host of sensitive information, issued by the zombie network flow, distributed DDOS attack is recognized in the world problems not only seriously affect the operation of the Internet business, but also a serious threat to China's Internet infrastructure in the safe operation. 2007 China's Internet domain name registration and the use of quantitative rapid growth, reaching 11.93 million, an annual growth rate of 190.4 percent, while hackers use of domain names has become a major tool. Use of domain names, the attackers could be flexible, hidden website linked to the implementation of large-scale horse zombie network control, network malicious activities such as counterfeiting. Fast-Flux domain names, such as dynamic analysis technologies, resulting in accordance with the IP to the attacks more difficult to trace and block; 2007 domain names which has been in use analytical services for the existence of security flaws, the public domain analysis of the server domain hijacking security incidents, a large number of users without knowing the circumstances of their fishing lure to the site or sites containing malicious code, such incidents very great danger. Therefore, the strengthening of the management of domain names and domain names analytic system's security protection is very important."

6.23 million botnet participating hosts according to their stats, where 3.62 million are Chinese IPs is a great example of how the Chinese Internet infrastructure's getting heavily abused by experienced malware and botnet masters, primarily taking advantage of what's old school social engineering, and outdated malware infection techniques, which undoubtedly will work given China's immature and inexperienced from a security perspective emerging Internet generation.

Getting back to the globalization and efficiency of Turkish web site defacement groups' worldwide web application security audit, indicated in the report, according to China's CERT these are the top 10 defacers, where 7 are well known Turkish ones, and 3 are interestingly Chinese :

sinaritx - 1731 defacements
1923turk - 1417 defacements
the freedom - 1156 defacements
aLpTurkTegin - 1052 defacements
Mor0Ccan Islam Defenders Team - 864 defacements
iskorpitx - 761 defacements
lucifercihan - 525 defacements

It's also interesting to see pro-democratic Chinese hackers attacking homeland networks.

Cyber warfare tensions engineering is only starting to take place, and state sponsored or perhaps even tolerated cyber espionage building capabilities in order for the state to later on acquire the already developed resources and capabilities in a cost-effective manner. However, considering the recent cyber attacks against "Free Tibet" movements, as well as the DDoS attack attempts at CNN due to CNN's coverage of Tibet, Chinese cyber warriors continue demonstrating people's information warfare, and Internet PSYOPs by developing an anti-cnn.com (121.52.208.243) community, with some catchy altered images from the originals broadcasted worldwide, and with a special section to improve China's image across the world.

And logically, there's a PSYOPs centered malware released in the wild, a sample of which is basically embedding links to a non-existent domain, descriptive enough to point to TibetIsAPartOFChina.com :

%\CommonDocuments%\My Music\My Playlists\WWW.cgjSFGrz_TibetIsAPartOFChina.COM

%CommonDocuments%\My Music\WWW.bimStzno_TibetIsAPartOFChina.COM

%CommonDocuments%\My Videos\WWW.kUJs_TibetIsAPartOFChina.COM

%CommonPrograms%\Accessories\Accessibility\WWW.RSulr_TibetIsAPartOFChina.COM

%CommonPrograms%\Accessories\System Tools\WWW.aEGXBl_TibetIsAPartOFChina.COM

Now that's effective digital PSYOPs, isn't it? If you're visionary enough to tolerate the development of underground communities, whereas ensuring their nationalism level remain a priority for anything they do, you end up with a powerful cyber army whose every action perfectly fits with your political and military doctrine, without you even bothering to coordinate their efforts, thereby eliminating the need for a command and control structure.

Related posts:

China's Cyber Espionage Ambitions
Chinese Hackers Attacking U.S Department of Defense Networks
Inside the Chinese Underground Economy
China's Cyber Warriors - Video
]]> Sun, 20 Apr 2008 22:34:07 +0000 china internet infrastructure chinese internet infrastructure chinese zombie network flow zombie network interestingly chinese infrastructure chinese underground economy China's CERT Annual Security Report - 2007 <![CDATA[Malware and Exploits Serving Girls]]> http://securityratty.com/article/54840fe4f746ae945f8f255443f2f0a3 http://securityratty.com/article/54840fe4f746ae945f8f255443f2f0a3 Descriptive domains such as beautiful-and-lonely-girl dot com, amateur homepage looking sites, a modest photo archive of different girls, apparently amateur malware spreaders think that spamming these links to as many people as possible would entice them into visting the sites, thus infecting themselves with malware.

It all started with Lonely Polina, than came lonely Ms. Polinka, and now we have Victoria. And despite that Polina and Polinka are both connected in terms of the malware served, and the natural RBN connection in face of HostFresh, as well as the site template used, Victoria is an exception. Some details on the recently spammed campaign :

voena.net (199.237.229.158) is also responding to prettyblondywoman.com, where the exploit (WebViewFolderIcon setSlice) and the malware (Trojan-Spy.Win32.Goldun) are served from voena.net/incoming.php and voena.net/get.php, both with a high detection rate 27/32 (84.38%).

Individual homepages are dead, and this is perhaps where the social engineering aspect of the attack fails, all these girls for sure have their MySpace profiles up and running already, in between taking advantage of a popular photo sharing service.
]]> Tue, 15 Apr 2008 04:14:56 +0000 malware lonely lonely polina girls natural rbn connection polina voena popular photo php Malware and Exploits Serving Girls <![CDATA[Embedded Malware at Bloggies Awards Site]]> http://securityratty.com/article/2d70cdf7c3222d6baa33fd53c95733f6 http://securityratty.com/article/2d70cdf7c3222d6baa33fd53c95733f6 The "window of opportunity" for traffic acquisition by taking advantage of a huge anticipated traffic is something malicious parties always find adaptive ways to take advantage of. Back in December, 2007, the same event based malware embedded attack appeared at a French government's site covering France/Libya relations right in the middle of Libya's leader visit in the country. My detailed analysis back then revealed details of the usual RBN connection, with IFRAME hosts switchng between HostFresh, Ukrtelegroup Ltd, and Turkey Abdallah Internet Hizmetleri, to surprisingly end up to the New Media Malware Gang original IP, futher confirming the existence of what's now a diverse ecosystem.

The same timely malware embedded attack happened at the top of the Annual Weblog Awards site - The Bloggies as TrendMicro assessed on Monday :

"The Web site of the Annual Weblogs Awards — more informally known as the Bloggies — was hacked recently, serving up a malicious Javascript to its visitors. This happened on the eve of the award ceremony, as reported in NEWS.com.au."

An embedded malware screenshot is worth a thousand words, so here it goes attached, and IcePack's now easily detectable module :

Scanner results : 47% Scanner(17/36) found malware!
File Size : 10666 byte
MD5 : 0860a1f5f1b27db14fedbfc979399fa4
SHA1 : 81c4ca763850fd3d675a0955ee6885ce83db53a5
HTML/Psyme.Gen; Trojan-Downloader.JS.Agent.et

Moreover, wilicenwww.biz/1/1/ice-pack/index.php is currently responding to 202.75.38.150, and besides the descriptive IcePack host, the IP also responds to the following domains :

bigsavingpharmacy.com
infosecurestatus.com
pharmacysuperdiscount.com
rspectrum.name
sicil.info
sicil256.info
superdiscountpills.com
mydnsweb.net
thegogosearch.com

So what? Historical CYBERINT untimately improves your situational awareness. Sicil.info was the main domain behind the Syrian Embassy in the U.K malware embedded attack. Back then, sicil.info was responding to 203.121.79.71, and now to 202.75.38.150, switching locations doesn't mean a clean domain reputation anyway.
]]> Wed, 12 Mar 2008 15:36:48 +0000 malware timely malware event based malware site malware screenshot icepack descriptive icepack host info bloggies Embedded Malware at Bloggies Awards Site <![CDATA[Loads.cc's DDoS for Hire Service]]> http://securityratty.com/article/3236554f7bd0cc2b7205d631bc8e47b1 http://securityratty.com/article/3236554f7bd0cc2b7205d631bc8e47b1 Snakes never whisper in one another's ear - it's supposed to tickle. In a blog post yesterday, Sunbelt Labs pointed out on the re-emergence of the Botnet on Demand Service that I covered last year. It's great to see we're on the same page, or wiki article as we can always expand the discussion. In need of more such fancy snakes admin panels courtesy of a web based malware C&C? Here are four more related :

legendarypornmovies.net/ts (88.85.81.211)
slutl.com/ts (88.85.78.7)
cwazo.net/ts (83.222.14.218)
oin.ru/ts (194.135.105.203)

Now the juicy details regarding loads.cc. During the time of posting this, the malicious domain is starting to redirect to a very descriptive one, which basically says "given up on ddos-ing", and a featured ad in between loads.cc's old interface is pitching the new service - contextual advertising consultations, as you can see in the attached screenshot. Apparently, a little more in-depth research acts as public pressure, especially when they're lazy enough to have a great deal of malware variants "phone back home" to their promotional domain. However, the current one responding to 67.228.69.191 is hosted by SoftLayer, and is using ns1.4wap.org as DNS server provided by Layered Technologies again confirming the Russian Business Network connection since, both, Layered Technologies and SoftLayer are known to have been and continue providing services to the RBN, knowingly or unknowingly. Moreover, the malware infected counter at the stats section continues reporting new additions.

Being one of the most venerable examples of DDoS for hire services, it's worth reposting its FAQ in an automatically translated fashion, so that a better perspective to the dynamics of offering such services is provided to the readers. Here's the FAQ on using the service, which is relatively easy to understand :

- All that is pure downloads nothing is loaded simultaneously

- The "mix" is not Buro countries on specified individual prices

- Loaded only those countries which are specified in the problem

- The country is determined to maxmind geoip

- When it ALL loaded all countries and the price of downloads is calculated separately for each country that is DE for the download you pay for a $ 0.2 PE 0.03

- Prices for downloads can sometimes vary slightly this watch themselves

- As such, the concept of mix does not exist, each country has its own price, and if the country is not clearly specified in the price is $ 30 price / 1k

- The money is withdrawn from the account in accordance with the facts and running leaps ekze by car users

- In the balance on deposit $ 5 or less stopped loading

- No minimum, it is possible to load even though 3 pc 10k limit pointing in the problem

- The claims, made by ALREADY download will not be accepted, DICOM small parties or do the test to check quality

- Following the establishment of tasks it must be activated by clicking on the link in the status, the same method could be suspended

- Pole challenge "received" shows how many bots believed assignment, it is usually little more than a "loaded" on the fabric sur somehow prichnam some boats were not able to download and run your ekze dolzhili or not yet know

Undercover DDoS in between contextual advertising, or "giving up on DDoS" entirely? Let's wait and see, without being naive enough to forget that this among the hundreds of other DDoS for hire services currently available in the wild.
]]> Tue, 11 Mar 2008 18:35:53 +0000 ddos service malware services hire services web based malware undercover ddos loads country Loads.cc's DDoS for Hire Service <![CDATA[Logs: Parsing, Tokenizing or Extracting?]]> http://securityratty.com/article/6d94e444ab1fab845f879bccd1b18989 http://securityratty.com/article/6d94e444ab1fab845f879bccd1b18989 As you know, I have long been on a quest to save the world from having to write long and ugly regular expressions (regexes) for log analysis. Back in 2005 (post, big discussion that ensued) and later in 2007 (post, another big discussion that again ensued), I have tried to poll people for approaches that convert logs into useful information without messing with massive quantities of regular expressions as well as performed some research on my own. In all honesty, I didn't notice a major breakthrough.

Until now? Here ("prequel" here and follow-up here) is what looks like an interesting and major development along that  line. Indeed, one can automate the processing of some "self-describing" log formats (name=value pairs, comma/tab delimited with descriptive header, sequential names and values [yuck!], XML, etc) to obtain a semblance of structured data (not just a flow of text logs)  from logs without any human involvement.

But is that an endgame, that "holy grail" of log analysis or yet another step towards it?  First, bad logs break it (e.g. with space in names or values with spaces and without quotes) and thus call for a return of a human logging expert to write an even fancier regex that can deal with it (then again, bad logs often break human-written rules as well). Second, there is a more important issue that I will bring up. So, if logs contain "user=jsmith" we can certainly learn a new piece of info (that the "user" was probably "jsmith"). But what if they contain "bla_bla=huh_huh" - and we don't know what "bla_bla" and "huh_huh" mean? Do we really have more information at hand if we tokenize it as "object called 'bla_bla' has the value of 'huh_huh'" compared to just having a single blurb of text "bla_bla=huh_huh." I personally don't think so - but I've been known to be wrong before :-)

So, let's review what we have: I decided to organize the current approaches to logs in the form of this table (hoping to start a discussion!)

  Text Indexing Field  Extraction (Algorithmic) Rule-based Parsing (Manual)
Pros Easy - no human effort needed: just collect the logs and go Easy - no per-log effort on behalf of the log analyst (but some creative code needs to be written) Hard - an expensive logging expert must first understand the logs and then write the rules; normalization across devices implies having a uniform data store for logs
Cons Output is low quality information; rather, a flow of raw data (needs more analysis) Mixed - some new information emerges, but not in all cases (and you can't predict when)
In general, no cross-device analysis is enabled ('user'  is not the same as 'usr' in other log)		 High-quality output: tables, graphics, summaries and easy correlation across diverse log sources (highly useful information!)

So, what can we conclude? It is too early to retire the human-written rules (so people will still have '\s' and '\w' coming up in bad dreams... :-)), but this automated approach should definitely be used on the logs that will "allow you to do it to them." :-) Personally, I am also very happy that somebody is thinking about such matters ...

Comment away!

About me: http://www.chuvakin.org
]]> Mon, 10 Mar 2008 22:54:00 +0000 logs log analyst log convert logs log management diverse log sources text logs log analysis bad logs Logs: Parsing, Tokenizing or Extracting?