CosmoDB Mongo Firewall not blocking unauthenticated connections

cpollfh 26 Reputation points

I've set up Firewall CIDRs in my-mongodb -> Firewall and virtual networks, as per

However, I'm seeing very strange behaviour:

If I try to connect from a whitelisted IP, the connection succeeds:
mongo -u my_username -p my_password --ssl --sslAllowInvalidCertificates
This results in a mongo prompt globaldb:PRIMARY> and full access to the database and collections.

And if I try connecting from a non-whitelisted IP, the connection fails:
2020-06-18T16:43:12.206-0400 I NETWORK [js] DBClientConnection failed to receive message from - SocketException: asio.ssl stream truncated
2020-06-18T16:43:12.207-0400 E QUERY [js] Error: network error while attempting to run command 'saslContinue' on host '' :
connect@Sérgio Carapinha /mongo/shell/mongo.js:341:17
2020-06-18T16:43:12.209-0400 F - [main] exception: connect failed
2020-06-18T16:43:12.209-0400 E - [main] exiting with code 1

However, if I try connecting without specifying the username and password, I'm able to access the mongo database. I get the mongo shell prompt and can do any unauthenticated commands, letting me do basic reconnaissance, like what the URLs are for the primary and secondaries, the name of the database, etc.

Expected behaviour: The firewall should drop all traffic not coming from a valid IP address. According to it should at least result in a 403.

Azure Cosmos DB
Azure Cosmos DB
An Azure NoSQL database service for app development.
1,539 questions
0 comments No comments
{count} votes

Accepted answer
  1. Mark Brown - MSFT 2,766 Reputation points Microsoft Employee

    These are not security issues for Cosmos DB. These commands only reveal information about Cosmos DB service gateway, which is publicly accessible, and not specific to to any account.

    As Mongo connections come in via TCP, the gateway must terminate the connection before knowing the identify of the account it will be routed to. The gateway must emulate pre-authentication Mongo commands so that the client is able to authenticate. Once the client is authenticated, the firewall will be encountered and will handle connections as configured.


    1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
  1. Mark Brown - MSFT 2,766 Reputation points Microsoft Employee

    While you may be able to get a connection you should not have any access to any customer specific database or collections or their data. The only thing that may be visible would be the Cosmos account name itself but that is in public DNS anyway and mirrored back as part of the connection string passed in anyway.

    Can you post some screen caps for what you are seeing?


    1 person found this answer helpful.
    0 comments No comments

  2. cpollfh 26 Reputation points

    Is it possible to set it up so that the connection times out from non-whitelisted IPs?

    Unauthenticated, I'm able to run commands such as db.isMaster(), db.getLastErrorObj(), and db.version(). These reveal significantly more than the Cosmos account name.

    db.isMaster() and db.version() reveal non-public information such as Mongo version and some configuration such as maxWriteBatchSize. This information can be used to create more specific attacks against the application using the Mongo database. db.getLastErrorObj() can be used to probe whether the attack payload is effective.

    What screen caps would you like me to post?

    0 comments No comments