As stated in the 5.6.6 release notes, the default value of –bind-address has changed from IPv4-specific “0.0.0.0″ to “*” – the latter value which allows MySQL to bind to IPv6 interfaces by default.  There are a few implications to this change.

First, make sure you’ve hardened both your IPv4 and your IPv6 access points to your MySQL server.  If you are running IPv4 interfaces only, you can also change the –bind-address value back to the previous default value of “0.0.0.0″.  Because MySQL now listens by default on both IPv4 and IPv6 interfaces, an installation that has only hardened IPv4 interfaces may find unaddressed vulnerabilities exposed via the IPv6 interface that is now used …

In cloud environments or other secure environments, you may want to lock your database down, allowing or disallowing certain grants or capabilities outside the database. One potential security issue is the use of LOAD DATA INFO and SELECT INTO OUTFILE, depending on what files that exist in directories the MySQL server has access to, or even if you have concerns with any database user ever having any access to the file system outside of the database. A few months ago, with version 5.5-25a-27.1, Percona extended this security feature so that you can disable LOAD DATA INFILE and SELECT INTO OUTFILE, simply called "secure-file-priv". This feature is extremely easy to use-- simply specify it in your my.cnf. You can set it a number of ways:

For instance, if you wanted to limit LOAD DATA INFILE or SELECT INTO OUTFILE to /var/tmp:

secure-file-priv = /var/tmp

Or if you wanted to disable it completely, specify no …

I got a few questions like the ones below that I’d like to address to avoid further confusion.
How exactly secure is ClouSE for MySQL, the first secure database in the cloud? Am I protected against standard application level security attacks or even accidental admin mistakes?
With the help of ClouSE I get instantaneous backup for my database on the highly durable cloud storage. But how would I protect my data in case a malicious attack or an accident did occur?

Re: security

I’ve got a comment pointing out that data encryption on the storage level doesn’t protect from SQL injections.  Of course, data encryption does not protect from SQL injections (as long as there is SQL involved, there will be a risk of a SQL injection).  Neither does it protect from the infinite number …

I feel a sense of pride when I think that I was involved in the development and maintenance of what was probably the first piece of software accepted into Debian which then had and still has direct up-stream support from Microsoft. The world is a better place for having Microsoft in it. The first operating system I ever ran on an 08086-based CPU was MS-DOS 2.x. I remember how thrilled I was when we got to see how my friend’s 80286 system ran BBS software that would cause a modem to dial a local system and display the application as if it were running on a local machine. Totally sweet.

When we were living at 6162 NE Middle in the nine-eight 292, we got an 80386 which ran Doom. Yeah, the original one, not the fancy new one with the double barrel shotgun, but it would probably run that one, too. It was also …

Transparently encrypted storage of *any* kind (storage engine based data encryption, truecrypt volume encryption, bitkeeper, etc) is *just as insecure* to most types of attack as non-encrypted data.  SQL injection or security escalation vulnerabilities, operating system vulnerabilities and cross site scripting attacks could give attackers access to the database data.  It doesn't matter if you encrypt the database's physical storage in the database itself (in the storage engine layer) or on disk (at the filesystem level) since either way the data is presented unencrypted through the SQL interface. 

Transparent encryption is great for protecting your laptop data from theft by stealing your laptop.  It is very unlikely someone will attack your server by stealing it.

It doesn't protect you from a malicious SQL injection which drops all your tables or reads all your data.

If you are …

Transparently encrypted storage of *any* kind (storage engine based data encryption, truecrypt volume encryption, bitkeeper, etc) is *just as insecure* to most types of attack as non-encrypted data.  SQL injection or security escalation vulnerabilities, operating system vulnerabilities and cross site scripting attacks could give attackers access to the database data.  It doesn't matter if you encrypt the database's physical storage in the database itself (in the storage engine layer) or on disk (at the filesystem level) since either way the data is presented unencrypted through the SQL interface. 

Transparent encryption is great for protecting your laptop data from theft by stealing your laptop.  It is very unlikely someone will attack your server by stealing it.

It doesn't protect you from a malicious SQL injection which drops all your tables or reads all your data.

If you are …

Want to learn how you can store your sensitive data in the cloud storage? Take a look at the thorough and honest security analysis of the approach you can take to deploy your existing MySQL workloads to cloud.

keep reading in August issue of Hackin9 security magazine.

The brief outage was due to a scheduled move of the servers to a separate rack and subnet dedicated to our work with the Center for Information Assurance & Cybersecurity (ciac) at the University of Washington Bothell (uwb), and a11y.com

I am currently exercising the new (to us) equipment and hope to winnow the less than awesome equipment over the next quarter. I spent the last six months finding the best in breed of the surplussed DL385 and DL380 chassis we (work) were going to have recycled. The team and I were able to find enough equipment to bring up one of each with eight and six gigs of memory, respectively. These will make excellent hypervisors for provisioning embedded instances of Slackware, Fedora, RHEL, CentOS, Debian, FreeBSD, OpenSolaris, OpenIndiana, FreeDOS, etc.

When I initially configured this xen paravirt environment, I failed to plan for integration with libvirt, so I am now re-jiggering the software bridges so …

This is the third time MySQL has made an entry into the Oracle Critical Patch Update Advisory service. The first time, we at Team MariaDB came up with an analysis: Oracle’s 27 MySQL security fixes and MariaDB.

Security is important to a DBA. Having vague explanations does no one any good. Even Oracle ACE Director Ronald Bradford chooses to ask some tough questions on this issue. Recently we found a bug in MySQL & MariaDB and did some …

It’s been released. Use this with NIST::NVD 1.00.00 and you will be able to perform immediate look-ups of CVE and CWE data given a CPE URN. For instance:

cjac@foxtrot:/usr/src/git/f5/NIST-NVD-Store-SQLite3$ perl Makefile.PL ; make ; make test ; cjac@foxtrot:/usr/src/git/f5/NIST-NVD-Store-SQLite3$ perl -MNIST::NVD::Query -MData::Dumper -e '
$q = NIST::NVD::Query->new(store    => q{SQLite3},database => q{t/data/nvdcve-2.0.db});
$cve_list = $q->cve_for_cpe( cpe => q{cpe:/a:microsoft:ie:7.0.5730.11} );
print Data::Dumper::Dumper { cve_list => $cve_list, first_cvss => $q->cve( cve_id => $cve_list->[0] )->{q{vuln:cvss}} }
'
$VAR1 = {
          'cve_list' => [
                          'CVE-2002-2435',
                          'CVE-2010-5071'
                        ],
          'first_cvss' => {
                            'cvss:base_metrics' => { …