Webinar 6/28: Securing Database Servers From External Attacks

securing database servers

securing database serversPlease join Percona’s Chief Evangelist Colin Charles on Thursday, June 28th, 2018, as he presents Securing Database Servers From External attacks at 7:00 AM PDT (UTC-7) / 10:00 AM EDT (UTC-4).


A critical piece of your infrastructure is the database tier, yet people don’t pay enough attention to it judging by how many are bitten via poorly chosen defaults, or just a lack understanding of running a secure database tier. In this talk, I’ll focus on MySQL/MariaDB, PostgreSQL, and MongoDB, and cover external authentication, auditing, encryption, SSL, firewalls, replication, and more gems from over a decade of consulting in this space from Percona’s 4,000+ customers.

Register Now


Colin Charles

Chief Evangelist

Colin Charles is the Chief Evangelist at Percona. He was previously on the founding team of MariaDB Server in 2009, and had worked at MySQL since 2005, and been a MySQL user since 2000. Before joining MySQL, he worked actively on the Fedora and OpenOffice.org projects. He’s well known within open source communities in APAC, and has spoken at many conferences. Experienced technologist, well known in the open source world for work that spans nearly two decades within the community. Pays attention to emerging technologies from an integration standpoint. Prolific speaker at many industry-wide conferences delivering talks and tutorials with ease. Interests: application development, systems administration, database development, migration, Web-based technologies. Considered expert in Linux and Mac OS X usage/administration/roll-out’s. Specialties: MariaDB, MySQL, Linux, Open Source, Community, speaking & writing to technical audiences as well as business stakeholders.

The post Webinar 6/28: Securing Database Servers From External Attacks appeared first on Percona Database Performance Blog.


Okta introduces ‘Sign in with Okta’ service

Consider that there are millions of Okta users out there using the service to sign into their company applications with a single set of credentials. Yet getting customers to work together using Okta authentication was an enormous task for developers. Okta wanted to simplify it, so they created a service they are calling it ‘Sign in with Okta.’

The new API allows developers to add a few lines code and give Okta customers the ability to sign into one another’s websites in a similar way that OAuth allows you to use your Google or Facebook credentials to sign onto consumer sites.

Frederic Kerrest, COO and co-founder at Okta, says the ‘Sign in with Okta’ uses an extension of OAuth called OpenID Connect, which his company has been supporting since 2016. He says the new service gives customers the ability to expand the use of their Okta credentials beyond their own set of internal applications to sign into customer and partner sites. This extends the Okta functionality and brand and helps to make it a kind of standard way of logging in (or that’s the hope).

When developers add this functionality, the user sees a “Sign in with Okta” button on the website or service they are accessing. They can then use their Okta login to get into these sites under whatever rules the site owner has defined.

Site with ‘Sign in with Okta’ button. Photo: Okta

While Okta has provided APIs for developers prior to today, they didn’t provide a package like this that simplifies the process. This forced developers to use the SAML standard to make it work. While there’s nothing wrong with this approach, it can be time-consuming and put a lot of burden on developers to write software and connectors, while updating and maintaining them, Kerrest explained. This removes all of that complexity from the process.

This means that when two businesses are on Okta, they can trust one another because they do business together, and instead of setting up the SAML connection, a process that could take days, they can do it an hour with the Okta API tool, according to Kerrest.

“[Sign in with Okta] is a much easier way for customers or partners to seamlessly integrate into our environment. They could do it before, but we are ‘widgetizing’ it now,” he said.


Auth0 snags $55M Series D, seeks international expansion

Auth0, a startup based in Seattle, has been helping developers with a set of APIs to build authentication into their applications for the last five years. It’s raised a fair bit of money along the way to help extend that mission, and today the company announced a $55 million Series D.

This round was led by led by Sapphire Ventures with help from World Innovation Lab, and existing investors Bessemer Venture Partners, Trinity Ventures, Meritech Capital and K9 Ventures. Today’s investment brings the total raised to $110 million. The company did not want to share its valuation.

CEO Eugenio Pace said the investment should help them expand further internationally. In fact, one of the investors, World Innovation Lab, is based in Japan and should help with their presence there. “Japan is an important market for us and they should help explain to us how the market works there,” he said.

The company offers an easy way for developers to build in authentication services into their applications, also known as Identification as a Service (IDaaS). It’s a lot like Stripe for payments or Twilio for messaging. Instead of building the authentication layer from scratch, they simply add a few lines of code and can take advantage of the services available on the Auth0 platform.

That platform includes a range of service such as single-sign on, two-factor identification, passwordless log-on and breached password detection.

They have a free tier, which doesn’t even require a credit card, and pay tiers based on the types of users — regular versus enterprise — along with the number of users. They also charge based on machine-to-machine authentication. Pace reports they have 3500 paying customers and tens of thousands of users on the free tier.

All of that has added up to a pretty decent business. While Pace would not share specific numbers, he did indicate the company doubled its revenue last year and expected to do so again this year.

With a cadence of getting funding every year for the last three years, Pace says this round may mark the end of that fundraising cycle for a time. He wasn’t ready to commit to the idea of an IPO, saying that is likely a couple of years away, but he says the company is close to profitability.

With the new influx of money, the company does plan to expand its workforce as moves into markets across the world . They currently have 300 employees, but within a year he expects to be between 400 and 450 worldwide.

The company’s last round was a $30 million Series C last June led by Meritech Capital Partners.


Relx acquires ThreatMetrix for $817M to ramp up in risk-based authentication

 Another startup in the area of cyber security has been snapped up as platform businesses serving enterprises look for more ways of securing their own networks and working with customers to secure theirs. Today, the RELX Group (formerly known as Reed Elsevier) announced that it would acquire ThreatMetrix for £580 million (about $817 million) in cash. This is a big exit for ThreatMetrix, which… Read More


Cloudflare Access aims to replace corporate VPNs

 If you’re part of a big company, chances are that there are resources that are only available via the internal network, or whatever your company calls it. The usual way to access these from outside company property is a VPN, but VPNs are a clumsy solution — one companies like Google and Amazon are leaving behind. Now Cloudflare wants you to do the same and use its new Access… Read More


Identity management startup ForgeRock snags $88 million Series D

 Used to be when we thought about identity as it relates to computers and software, it involved a person logging into an application or service. Increasingly though, you also have machines and sensors attempting to authenticate as they access your systems. That creates complications for identity management vendors because instead of managing thousands or tens of thousands of identities, it… Read More


MongoDB Authentication and Roles: Creating Your First Personalized Role

MongoDB Authentication and Roles

MongoDB Authentication and RolesIn this blog post, we’ll walk through the native MongoDB authentication and roles, and learn how to create personalized roles. It is a continuation of Securing MongoDB instances.

As said before, MongoDB features a few authentication methods and built-in roles that offer great control of both who is connecting to the database and what they are allowed to do. However, some companies have their own security policies that are often not covered by default roles. This blog post explains not only how to create personalized roles, but also how to grant minimum access to a user.

Authentication Methods

SCRAM-SHA-1 and MONGODB-CR are challenge-response protocols. All the users and passwords are saved encrypted in the MongoDB instance. Challenge-response authentication methods are widely used on the internet in several server-client software. These authentication methods do not send passwords as plain text to the server when the client is starting an authentication. Each new session has a different hash/code, which stops people from getting the password when sniffing the network.

The MONGODB-CR method was deprecated in version 3.0.

The x.509 authentication is an internal authentication that allows instances and clients to communicate to each other. All certificates are signed by the same Certificate Authority and must be valid. All the network traffic is encrypted by a given key, and it is only possible to read data with a valid certificate signed by such key.

MongoDB also offers external authentications such as LDAP and Kerberos. When using LDAP, users can log in to MongoDB using their centralized passwords. The LDAP application is commonly used to manage users and passwords in wide networks. Kerberos is a service that allows users to login only once, and then generates access tickets so that the users are allowed to access other services. Some configuration is necessary to use external authentication.

Built in roles

  • read: collStats,dbHash,dbStats,find,killCursors,listIndexes,listCollections,
  • readWrite: all read privileges + convertToCapped, createCollection,dbStats, dropCollection, createIndex, dropIndex, emptycapped, insert, listIndexes,remove, renameCollectionSameDB, update.
  • readAnyDatabase: allows the user to perform read in any database except the local and the config databases.

And so on…

In this tutorial, we are going to give specific privileges to a user who is allowed to only read the database, although he is allowed to write in a specific collection.

For this tutorial, we are using MongoDB 3.4 with previously configured authentication.


  1. Create the database:
    mongo --authenticationDatbase admin -u superAdmin -p
    use percona
    db.foo.insert({x : 1})
    db.foo2.insert({x : 1})
  2. Create a new user:
    > db.createUser({user : 'client_read', pwd : '123', roles : ['read']})
    Successfully added user: { "user" : "client_read", "roles" : [ "read" ] }
  3. Log in with the user that has just been created and check the user access:
    ./mongo localhost/percona -u client_read -p
    MongoDB shell version v3.4.0-rc5
    Enter password:
    { "_id" : ObjectId("586bc2e9cac0bbb93f325d11"), "x" : 1 }
    // If user try to insert documents will receive an error:
    > db.foo.insert({x : 2})
                "writeError" : {
                "code" : 13,
                "errmsg" : "not authorized on percona to execute command
                     { insert: "foo", documents: [ { _id: ObjectId('586bc36e7b114fb2517462f3'), x: 2.0 } ], ordered: true }"
  4. Log out and log in again with administrator user to create a new role for this user:
    mongo --authenticationDatabase admin -u superAdmin -p
    role : 'write_foo2_Collection',
    privileges : [ {resource : {db : "percona", collection : "foo2"}, actions : ["insert","remove"]}
    roles : ["read"]
    db.updateUser('client_read', roles : ['write_foo2_Collection'])
  5. Check the new access:
    > show collections
    > db.foo.find()
    { "_id" : ObjectId("586bc2e9cac0bbb93f325d11"), "x" : 1 }
    > db.foo2.insert({y : 2})
    WriteResult({ "nInserted" : 1 })
    > db.foo.insert({y : 2}) //does not have permission.
          "writeError" : {
                "code" : 13,
                "errmsg" : "not authorized on percona to execute command { insert: "foo", documents: [ { _id: ObjectId('586bc5e26f05b3a5db849359'), y: 2.0 } ], ordered: true }"
  6. We can also add access to other database resources. Let’s suppose we would like to grant this just created user permission to execute a getLog command. This command is available in the clusterAdmin role, but we do not want to give all this role’s access to him. See https://docs.mongodb.com/v3.0/reference/privilege-actions/#authr.getLog.

    There is a caveat/detail/observation here. If we want to grant cluster privileges to a user, we should create the role in the admin database. Otherwise, the command will fail:

                      {resource : {cluster : true}, actions : ["getLog"] }
    Roles on the 'percona' database cannot be granted privileges that target other databases or the cluster :
  7. We are creating the same role in the admin database. This user only works properly if the admin database is present in a possible restore. Otherwise, the privileges fail:

    use admin
         role : 'write_foo2_Collection_getLogs',
         privileges : [
                           {resource : {db : "percona", collection : "foo2"}, actions : ["insert","remove"]},
                           {resource : {cluster : true}, actions : ["getLog"]}],  
         roles : [ {role : "read", db: "percona"}]
    use percona
    db.updateUser( "client_read",
         roles : [
              { role : "write_foo2_Collection_getLogs", db : "admin" }
  8. Now the user has the same privileges as before, plus the getLog permission. We can test this user new access with:

    mongo --authenticationDatabase percona -u read_user -p
    db.adminCommand({getLog : 'global'})
              "totalLinesWritten" : 287,
              "log" : [....

I hope you find this post useful. Please feel free to ping me on twitter @AdamoTonete or @percona and let us know your thoughts.


Webinar Thursday, February 23, 2017: Troubleshooting MySQL Access Privileges Issues

Troubleshooting MySQL Access Privileges

Troubleshooting MySQL Access PrivilegesPlease join Sveta Smirnova, Percona’s Principal Technical Services Engineer, as she presents Troubleshooting MySQL Access Privileges Issues on
February 23, 2017 at 11:00 am PST / 2:00 pm EST (UTC-8).

Do you have registered users who can’t connect to the MySQL server? Strangers modifying data to which they shouldn’t have access?

MySQL supports a rich set of user privilege options and allows you to fine tune access to every object in the server. The latest versions support authentication plugins that help to create more access patterns.

However, finding errors in such a big set of options can be problematic. This is especially true for environments with hundreds of users, all with different privileges on multiple objects. In this webinar, I will show you how to decipher error messages and unravel the complicated setups that can lead to access errors. We will also cover network errors that mimic access privileges errors.

In this webinar, we will discuss:

  • Which privileges MySQL supports
  • What GRANT statements are
  • How privileges are stored
  • How to find out why a privilege does not work properly
  • How authentication plugins make difference
  • What the best access control practices are

To register for this webinar please click here.

InnoDB TroubleshootingSveta Smirnova, Principal Technical Services Engineer

Sveta joined Percona in 2015. Her main professional interests are problem-solving, working with tricky issues, bugs, finding patterns that can solve typical issues quicker, and teaching others how to deal with MySQL issues, bugs and gotchas effectively. Before joining Percona, Sveta worked as Support Engineer in the MySQL Bugs Analysis Support Group at MySQL AB-Sun-Oracle. She is the author of book “MySQL Troubleshooting” and JSON UDF functions for MySQL.


Securing MongoDB Instances

securing MongoDB

In this blog post we’ll look at how to go about securing MongoDB instances.

Authentication is one of the most important features of a database, and MongoDB supports it in different ways. Although it allows you to work without any authentication, the best practice is to enable authentication and give users only the permissions they need.

Instances without authentication allow all users to perform all the operations they feel like, and that is not safe at all.

Securing MongoDBNative Authentication

The MongoDB community version features more than one authentication method: SCRAM-SHA-1, MONGODB-CR, and x.509 Certificate Authentication. The current default method is SCRAM-SHA-1. The version prior to 3.0 used to have MONGODB-CR as its default method.

Percona Server for MongoDB also offers LDAP authentication free of charge where this feature is only available in the MongoDB enterprise version.

SCRAM-SHA-1 and MONGODB-CR check whether the user/password exists against a specific database and use challenge response authentication to verify user’s authenticity.

The x.509 authentication is based on certificates. It does not run challenge response algorithms. This method instead validates a certificate to prove client’s authenticity. It depends on a certificate authority and each client must have a valid certificate.

LDAP Authentication

The LDAP authentication uses an external LDAP server to authenticate the user by using authsasld in Linux. LDAP is commonly used to manage users in a network. There are advantages and disadvantages when using LDAP. One advantage is that it centralizes users. However, it depends on network connectivity to check user credentials and sasld tries to help with caching but it does have limitations. Please see further details here.

There are two different internal authentication methods for replica-set and shadings, where instances need to prove that they are expected members of the deployment. The first method is using a shared keyfile for all instances, and the second one is using a different x.509 certificate for each instance. It is important to know x.509 forces proper SSL coverage or replication while a key will not, but we will cover this topic in a different blog post.

Authorization and Roles

Once authenticated, users must be allowed to perform commands against the instance/replica-set/sharding. There are a few built-in roles that are able to cover almost all the user cases, and creating a user defined role is possible.
The current built-in roles are:

read readWrite dbAdmin dbOwner
userAdmin clusterAdmin clusterManager clusterMonitor
hostManager backup/restore readAnyDatabase readWriteAnyDatabase
userAdminAnyDatabase dbAdminAnyDatabase root and many more…

There is also the __system role, which is solely used for internal purposes.

Customer user and role by example

This shows how to both enable MongoDB authentication and create a user-defined role, where the user will only be able to read a specific collection. We are using tarballs for testing only. To perform a production installation please follow our docs.

  1. Download Percona Server MongoDB:
    >wget https://www.percona.com/downloads/percona-server-mongodb-3.2/percona-server-mongodb-3.2.10-3.0/binary/tarball/percona-server-mongodb-3.2.10-3.0-trusty-x86_64.tar.gz
    >tar -xvzf percona-server-mongodb-3.2.10-3.0-trusty-x86_64.tar.gz
    >mv percona-server-mongodb-3.2.10-3.0/ perc-mongodb
    >cd perc-mongodb/
    >mkdir bin/data
  2. Start the service with authentication:
    cd bin
    ./mongod --dbpath data --smallfiles --logpath data/mongod.log --fork --auth
  3. Create root/admin user:

    We are able to create the first user without authentication. The next users must be created by an authenticated user.

    > use admin
    > db.createUser({user : 'administrator', pwd : '123', roles : ['root'] })
    > Successfully added user: { "user" : "administrator", "roles" : [ "root" ] }
  4. Login with the just created credentials:
    >mongo --authenticationDatabase admin -u administrator -p
  5. Create database and collection:
    > use percona
    > db.simple_collection.insert({ random_number : Math.random()})
    > db.secure_collection.insert({ name : 'John', annual_wage : NumberLong(130000.00), target_bonus : NumberLong(15000.00)})
  6. create a user that can read all the collections in the percona database:
    db.createUser( {
        user: "app_read",
        pwd: "123456",
        roles: [ { role: "read", db: "percona" }]})
    // testing
    ./mongo --authenticationDatabase admin -u app_read -p
    MongoDB shell version: 3.2.10-3.0
    Enter password:
    connecting to: test
    > use percona
    switched to db percona
    > show collections
    > db.employee_dependents.find()
        { "_id" : ObjectId("583c5afe38c4be98b24e86e6"), "emp_id" : DBRef(‘employees’,’583c5bea38c4be98b24e86e8’}
    > db.employees.find()
        { "_id" : ObjectId("583c5bea38c4be98b24e86e8"), "name" : "John", "annual_wage" : NumberLong(130000), "target_bonus" : NumberLong(15000) }
  7. Now we see that this user can read not only the

     but also the


    . We don’t want users to read the


    , so we are going to create a user-defined role.

    > db.createRole( {
        role : 'readOnly_nonPrivilegedCollections',
        roles : [],
        privileges: [
             resource: {
               db: "percona",
               collection: "foo"
             actions: [ "find"] }
  8. Assign created role to the user:
    db.createUser( {
         user: "app_non_secure",
         pwd: "123456",
         roles: [ { role: "readOnly_nonPrivilegedCollections", db: 'admin' }]
  9. Test access:
    ./mongo --authenticationDatabase admin -u app_non_secure -p
    > db.foo.find()
        { "_id" : ObjectId("583c5afe38c4be98b24e86e6"), "random_number" : 0.2878080930921183 }
    > db.secure_collection.find()
    Error: error: {
        "ok" : 0,
        "errmsg" : "not authorized on percona to execute command { find: "secure_collection", filter: {} }",
        "code" : 13

Please feel free to ping us on Twitter @percona with any questions and suggestions for securing MongoDB instances.


Authentication startup Auth0 raises $15M as it beefs up security features

auth0 “Identity-as-a-service” startup Auth0 (pronounced “auth zero”) has raised $15 million in Series B funding.
CEO Jon Gelsey said that for many website and mobile app developers, integrating with different login systems can turn into a big headache — and also create security risks. So the company helps those developers manage identity and authentication, whether… Read More

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com