phpMiX.org aggregator

Microsoft Security Response Center: Microsoft security updates and the Common Vulnerability Reporting Framework

Fri, 18 May 2012 00:09:00 +0200

As a part of the Industry Consortium for Advancement of Security on the Internet (ICASI), Microsoft is pleased to present an initial set of monthly security updates – originally released on May 8 – in the consortium’s newly established Common Vulnerability Reporting Framework (CVRF) format, for your examination and feedback. Today, ICASI released version 1.1 of its CVRF – a markup system designed to make security bulletins and advisories machine readable in an industry-standard fashion.

Even though many vendors have followed Microsoft’s lead in providing comprehensive security updates to customers, the formats vendors use vary. CVRF provides the entire industry with a way to share and present data in a coordinated and structured manner.

CVRF is free for anyone to examine and use. The goal is to build a data-markup framework that can be used by anyone publishing or examining security update information on the Internet.

CVRF is a work in process. For many customers, a machine-readable markup framework for security releases might not be a pressing need. For instance, home-computer users or small businesses may choose to install security updates automatically. However, many business customers spend time “copying and pasting” our security bulletin content into their risk management systems, spreadsheets and corporate notification emails manually as part of their IT security compliance and remediation task list.

For these customers, this machine-readable format may enable more efficiency and automation. Faster and more efficient guidance for these customers means they can more quickly ensure protection, which is always our goal. For those that do not require automation, we will continue to offer our bulletins in the current format. For those customers looking to automate and streamline their security-management process, or for those who are simply curious to see what happens when vendors from around the industry roll up their sleeves and work to make the update process better, visit the Connect portal to read more about CVRF, and to examine CVRF-formatted bulletins. Visit https://connect.microsoft.com/ and click SIGN IN in the upper right-hand corner to sign in with your Windows Live ID. Once you are signed in and are looking at the home page, use the invitation code “cvrf-9BK8-6W2T” (without quotes) to join the program, or visit https://connect.microsoft.com/site1098/InvitationUse.aspx?ProgramID=7665&InvitationID=cvrf-9BK8-6W2T directly.

Your feedback will be relayed to the ICASI working group of which Microsoft is a member. Together we’ll continue to make CVRF a truly robust, collaborative standard throughout the Internet ecosystem.

Mike Reavey

Senior Director, MSRC

WordPress Planet: Alex King: Social 2.5 beta 2

Thu, 17 May 2012 23:44:01 +0200

We’re just about ready to put a bow on version 2.5 of Social. If you’d like to test the second beta release, grab it from GitHub.

Social is a plugin that allows you to maintain a centralized conversation on your site, while also participating in conversations on Facebook and Twitter.

WordPress Planet: Weblog Tools Collection: WordPress Plugin Releases for 5/17

Thu, 17 May 2012 16:00:57 +0200

New plugins

Monster Widget provides a quick and easy method of adding all core widgets to a sidebar for testing purposes.

Updated plugins

Bad Behavior complements other link spam solutions by acting as a gatekeeper, preventing spammers from ever delivering their junk, and in many cases, from ever reading your site in the first place.

Yepty is yet another pay per click advertising plugin.

SANS Internet Storm Center: Avira Antivirus false positives http://forum.avira.com/wbb/index.php?page=Thread&threadID=144875, (Wed, May 16th)

Wed, 16 May 2012 19:02:51 +0200

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

MySQL Performance Blog: Training in London next week

Wed, 16 May 2012 18:24:37 +0200

I’m going to deliver MySQL Training next week (May 21-24) in London.
This is a rare opportunity as I do not personally deliver a lot of Training, especially outside of US. There are still some places left if you want to sign up.

You will also get a signed copy of High Performance MySQL 3rd edition as an attendee.

High Scalability: Big List of 20 Common Bottlenecks

Wed, 16 May 2012 18:15:51 +0200

In Zen And The Art Of Scaling - A Koan And Epigram Approach, Russell Sullivan offered an interesting conjecture: there are 20 classic bottlenecks. This sounds suspiciously like the idea that there only 20 basic story plots. And depending on how you chunkify things, it may be true, but in practice we all know bottlenecks come in infinite flavors, all tasting of sour and ash.

One day Aurelien Broszniowski from Terracotta emailed me his list of bottlenecks, we cc’ed Russell in on the conversation, he gave me his list, I have a list, and here’s the resulting stone soup.

Russell said this is his “I wish I knew when I was younger" list and I think that’s an enriching way to look at it. The more experience you have, the more different types of projects you tackle, the more lessons you’ll be able add to a list like this. So when you read this list, and when you make your own, you are stepping through years of accumulated experience and more than a little frustration, but in each there is a story worth grokking.

Database:

MySQL Performance Blog: Benchmarking single-row insert performance on Amazon EC2

Wed, 16 May 2012 17:55:52 +0200

I have been working for a customer benchmarking insert performance on Amazon EC2, and I have some interesting results that I wanted to share. I used a nice and effective tool iiBench which has been developed by Tokutek. Though the “1 billion row insert challenge” for which this tool was originally built is long over, but still the tool serves well for benchmark purposes.

OK, let’s start off with the configuration details.

Configuration

First of all let me describe the EC2 instance type that I used.

EC2 Configuration

I chose m2.4xlarge instance as that’s the instance type with highest memory available, and memory is what really really matters.

High-Memory Quadruple Extra Large Instance
68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.4xlarge

As for the IO configuration I chose 8 x 200G EBS volumes in software RAID 10.

Now let’s come to the MySQL configuration.

MySQL Configuration

I used Percona Server 5.5.22-55 for the tests. Following is the configuration that I used:

## InnoDB options
innodb_buffer_pool_size         = 55G
innodb_log_file_size            = 1G
innodb_log_files_in_group       = 4
innodb_buffer_pool_instances    = 4
innodb_adaptive_flushing        = 1
innodb_adaptive_flushing_method = estimate
innodb_flush_log_at_trx_commit  = 2
innodb_flush_method             = O_DIRECT
innodb_max_dirty_pages_pct      = 50
innodb_io_capacity              = 800
innodb_read_io_threads          = 8
innodb_write_io_threads         = 4
innodb_file_per_table           = 1

## Disabling query cache
query_cache_size                = 0
query_cache_type                = 0

You can see that the buffer pool is sized at 55G and I am using 4 buffer pool instances to reduce the contention caused by buffer pool mutexes. Another important configuration that I am using is that I am using “estimate” flushing method available only on Percona Server. The “estimate” method reduces the impact of traditional InnoDB log flushing, which can cause downward spikes in performance. Other then that, I have also disabled query cache to avoid contention caused by query cache on write heavy workload.

OK, so that was all about the configuration of the EC2 instance and MySQL.

Now as far as the benchmark itself is concerned, I made no code changes to iiBench, and used the version available here. But I changed the table to use range partitioning. I defined a partitioning scheme such that every partition would hold 100 million rows.

Table Structure

The table structure of the table with no secondary indexes is as follows:

CREATE TABLE `purchases_noindex` (
  `transactionid` int(11) NOT NULL AUTO_INCREMENT,
  `dateandtime` datetime DEFAULT NULL,
  `cashregisterid` int(11) NOT NULL,
  `customerid` int(11) NOT NULL,
  `productid` int(11) NOT NULL,
  `price` float NOT NULL,
  PRIMARY KEY (`transactionid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (transactionid)
(PARTITION p0 VALUES LESS THAN (100000000) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (200000000) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (300000000) ENGINE = InnoDB,
 PARTITION p3 VALUES LESS THAN (400000000) ENGINE = InnoDB,
 PARTITION p4 VALUES LESS THAN (500000000) ENGINE = InnoDB,
 PARTITION p5 VALUES LESS THAN (600000000) ENGINE = InnoDB,
 PARTITION p6 VALUES LESS THAN (700000000) ENGINE = InnoDB,
 PARTITION p7 VALUES LESS THAN (800000000) ENGINE = InnoDB,
 PARTITION p8 VALUES LESS THAN (900000000) ENGINE = InnoDB,
 PARTITION p9 VALUES LESS THAN (1000000000) ENGINE = InnoDB,
 PARTITION p10 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

While the structure of the table with secondary indexes is as follows:

CREATE TABLE `purchases_index` (
  `transactionid` int(11) NOT NULL AUTO_INCREMENT,
  `dateandtime` datetime DEFAULT NULL,
  `cashregisterid` int(11) NOT NULL,
  `customerid` int(11) NOT NULL,
  `productid` int(11) NOT NULL,
  `price` float NOT NULL,
  PRIMARY KEY (`transactionid`),
  KEY `marketsegment` (`price`,`customerid`),
  KEY `registersegment` (`cashregisterid`,`price`,`customerid`),
  KEY `pdc` (`price`,`dateandtime`,`customerid`)
) ENGINE=InnoDB AUTO_INCREMENT=11073789 DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (transactionid)
(PARTITION p0 VALUES LESS THAN (100000000) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (200000000) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (300000000) ENGINE = InnoDB,
 PARTITION p3 VALUES LESS THAN (400000000) ENGINE = InnoDB,
 PARTITION p4 VALUES LESS THAN (500000000) ENGINE = InnoDB,
 PARTITION p5 VALUES LESS THAN (600000000) ENGINE = InnoDB,
 PARTITION p6 VALUES LESS THAN (700000000) ENGINE = InnoDB,
 PARTITION p7 VALUES LESS THAN (800000000) ENGINE = InnoDB,
 PARTITION p8 VALUES LESS THAN (900000000) ENGINE = InnoDB,
 PARTITION p9 VALUES LESS THAN (1000000000) ENGINE = InnoDB,
 PARTITION p10 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

Also, I ran 5 instances of iiBench simultaneously to simulate 5 concurrent connections writing to the table, with each instance of iiBench writing 200 million single row inserts, for a total of 1 billion rows. I ran the test both with the table purchases_noindex which has no secondary index and only a primary index, and against the table purchases_index which has 3 secondary indexes. Another thing I would like to share is that, the size of the table without secondary indexes is 56G while the size of the table with secondary indexes is 181G.

Now let’s come down to the interesting part.

Results

With the table purchases_noindex, that has no secondary indexes, I was able to achieve an avg. insert rate of ~25k INSERTs Per Second, while with the table purchases_index, the avg. insert rate reduced to ~9k INSERTs Per Second. Let’s take a look at the graphs have a better view of the whole picture.

Note, in the above graph, we have “millions of rows” on the x-axis and “INSERTs Per Second” on the y-axis.
The reason why I have chosen to show “millions of rows” on the x-axis so that we can see the impact of growth in data-set on the insert rate.

We can see that adding the secondary indexes to the table has decreased the insert rate by 3x, and its not even consistent. While with the table having no secondary indexes, you can see that the insert rate is pretty much constant remaining between ~25k to ~26k INSERTs Per Second. But on the other hand, with the table having secondary indexes, we can see that there are regular spikes in the insert rate, and the variation in the rate can be classified as large, because it varies between ~6.5k to ~12.5k INSERTs per second, with noticeable spikes after every 100 million rows inserted.

I noticed that the insert rate drop was mainly caused by IO pressure caused by increase in flushing and checkpointing activity. This caused spikes in write activity to the point that the insert rate was decreased.

Conclusion

As we all now there are pros and cons to using secondary indexes. While secondary indexes cause read performance to improve, but they have an impact on the write performance. Well most of the apps rely on read performance and hence having secondary indexes is an obvious choice. But for those applications that are write mostly or that rely a lot on write performance, reducing the no. of secondary indexes or even going away with secondary indexes causes a write throughput increase of 2x to 3x. In this particular case, since I was mostly concerned with write performance, so I went ahead to choose a table structure with no secondary indexes. Other important things to consider when you are concerned with write performance is using partitioning to reduce the size of the B+tree, having multiple buffer pool instances to reduce contention problems caused by buffer pool mutexes, using “estimate” checkpoint method to reduce chances of log flush storms and disabling the query cache.

SANS Internet Storm Center: New Version of Google Chrome released (19.0.1084.46) , (Wed, May 16th)

Wed, 16 May 2012 17:00:23 +0200

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

SANS Internet Storm Center: Reserved IP Address Space Reminder, (Wed, May 16th)

Wed, 16 May 2012 16:25:29 +0200

As we are running out of IPv4 address space, many networks, instead of embracing IPv6, stretch existing IPv4 space via multiple levels of NAT. NAT then uses reserved IP address space. However, there are more address ranges reserved then listed in RFC1918, and not all of them should be used in internal networks. Here is a (probably incomplete) list of address ranges that are reserved, and which once are usable inside your network behind a NAT gateway.

List of Reserved IPv4 Address ranges

Address Range
RFC
Suitable for Internal Network

0.0.0.0/8
RFC1122
no (any address)

10.0.0.0/8
RFC1918
yes

100.64.0.0/10
RFC6598
yes (with caution: If you are a carrier)

127.0.0.0/8
RFC1122
no (localhost)

169.254.0.0/16
RFC3927
yes (with caution: zero configuration)

172.16.0.0/12
RFC1918
yes

192.0.0.0/24
RFC5736
no (not used now, may be used later)

192.0.2.0/24
RFC5737
yes (with caution: for use in examples)

192.88.99.0/24
RFC3068
no (6-to-4 anycast)

192.168.0.0/16
RFC1918
yes

198.18.0.0/15
RFC2544
yes (with caution: for use in benchmark tests)

198.51.100.0/24
RFC5737
yes (with caution: test-net used in examples)

203.0.113.0/24
RFC5737
yes (with caution: test-net used in examples)

224.0.0.0/4
RFC3171
no (Multicast)

Most interesting in this context is RFC6598 (100.64.0.0/10), which was recently assigned to provide ISPs with a range for NAT that is not going to conflict with their customers NAT networks. It has been a more and more common problem that NAT'ed networks once connected with each other via for example a VPN tunnel, have conflicting assignments.
Which networks did I forget? I will update the table for a couple days as comments come in.
------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Opera Desktop Team: New Opera 12 snapshot

Wed, 16 May 2012 16:21:47 +0200

Here's yet another Opera 12 snapshot with a number of fixes, including several common crashes. It contains Out Of Process Plugin fixes, Hardware Acceleration fixes and Skin fixes.

For Hardware Acceleration fans we have font bugs fixed and new Renderer preference which the user can set to 1 to prefer the DirectX back-end, or 0 to chose OpenGL. Make sure to turn on Hardware Acceleration in opera:config, to check this out (Hardware Acceleration is turned off by default in Opera 12, and the new preference has no effect).

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

...