I am trying to get a mongoDB working with authentication, using both Java and PHP drivers. I've added user roles to the mongoDB but haven't yet turned on authentication (so clients can login with usernames and passwords, but they don't have to, and user roles are not yet enforced).
To check that everything is working, before actually turning authentication on, I've been looking at the mongod.log file. I see things like:
2015-11-17T08:47:19.052+0000 I NETWORK [initandlisten] connection accepted from ###:### #158126 (46 connections now open)
2015-11-17T08:47:19.960+0000 I ACCESS [conn158126] Successfully authenticated as ### on ###
But.... I also see quite a few connections without the "ACCESS" line. However, when cross referencing with logs of the clients, it seems they are trying to connect with authentication.
What can be going on?
Is it perhaps the case that the ACCESS log only occurs if some database action is taken? So, e.g. if a client connects but doesn't try to read or write, would I not see the 2nd line?
Is it perhaps the case that the ACCESS log only occurs if some database action is taken?
At least for the JAVA driver I'm using, "yes" is the answer. I ran a test, connecting, requesting a DB and collection, but doing nothing more, and no authentication check is triggered. It's only when you try to read/write that the authentication happens.
Related
I wrote a simple finance tracking application in 2017 that uses a Heroku backend with a Postgres db. The application suddenly stopped working, and I traced the problem to the database.
I was unable to connect to the database, seeing this error:
psql: FATAL: too many connections for role
I thought maybe the app had a connection leak so I shut the frontend down (Im the only one that uses it) and reset all the db connections. I was then able to login to the db, and noticed all these strange roles (hundreds?) that I dont recognize.
When I logged out of psql, I tried logging back in and again was denied with the "too many connections" error. The only way I can log back in is if I kill all connections again and immediately login. If I wait 2-3 minutes the error comes back. I don't think my heroku app is establishing all these connections with the db, because Im tailing the logs and it's just sitting there.
Does anyone have any theories about what might be going on here? Have I been hacked maybe? How would you debug this further, and how might I fix the problem?
Thanks!
The database has obviously been hacked.
Shut it down and delete it right away.
Restore to a different cluster from a known good backup.
From now on, choose good passwords and use a restrictive pg_hba.conf that for example doesn't allow remote access for superusers.
Never, ever, operate your application with a superuser.
Examine your application for SQL injection vulnerabilities.
this may be because of a bot(made by hackers) that is scanning the internet and trying CVE exploit (N-day exploit) to see if it is vulnerable, and then launching that type of attack or it may be because someone on the VNAT with you trying to something weird, but one thing for sure it is a bot because you can not launch that many connections by hand.
I know that using Firebird 2.5+ I can check if there are users accessing my database using SQL, but unfortunately, Firebird 2.0 doesn't have this feature. Yes, I know it's an old version, but it's a legacy software and I'm not allowed to upgrade this in a short time... :(
I need to know if someone is connected to my 2.0 Firebird database, due to a process I'll run:
Block connections to DB (but ONLY if no one is connected)
Run my process
Allow users to reconnect again
I can start my process only when there are no users connected.
My database is part of a client/server system (no Web).
Any hints?
-at[tach] : this parameter prevents any new connections to the database from being made with the exception of the SYSDBA and the database owner. The shutdown will fail if there are any sessions connected after the timeout period has expired. It makes no difference if those connected sessions belong to the SYSDBA, the database owner or any other user. Any connections remaining will terminate the shutdown with the following details:
https://firebirdsql.org/manual/gfix-dbstartstop.html
There is also Services API to do it so your database access library should expose the shutdown function. Specify a short shutdown, and if it failed - then there were some users. If it succeeded - now you can go on with maintenance, having a warranty client applications will not be able to connect.
Alternatively you can upgrade Firebird 2.0 -> 2.1 which is more close to 2.0 than 2.5 but already have Monitoring Tables implemented.
However this your approach has one weak point - race conditions. Using M.T. you envision your work as following:
Keep querying M.T. (which slows down server work significantly) until there are no other connections.
start maintenance work, that would fail if other connections are active
complete maintenance work
Problem is, that even after at step 1 you gained "no other connection" state, it does not mean that between steps 1 and 2, and especially between steps 2 and 3 now new connections would be made.
Even if you made your checks and ensure #1 condition, when you would go on with maintenance there would be some new user connected back and working now. Not every time of course, but as time goes by it will eventually happen one day.
But there is yet one more good thing in FB 2.1 - database-level triggers.
c:\Program Files\Firebird\Firebird_2_1\doc\sql.extensions\README.db_triggers.txt
You can create a regular "all_current_connections" table, using on connect and on disconnect triggers to keep it up to date.
You perhaps would also have to add some logic to your applications, so they would update that table with your internal application ID, to tell main workflow apps/connections from servicing utilities. However it is also possible that mere CURRENT_USER and CURRENT_CONNECTION pair, which the trigger knows and can store to the table, would be enough for that table, if you can infer kind of application from mere user name.
Then on disconnect trigger might be checking whether all "main workflow" apps disconnected and POST_EVENT to notify servicing utilities. However those utilities would still have to shutdown the database first, anyway.
You can shut down the database using gfix. The gfix tool will try to shutdown the database and if connections still exist after a timeout, the shutdown will fail.
For example, use:
gfix -shut -attach 5 <your-database>
This will:
prevent new connection being created,
wait 5 seconds for the existing connections to end,
if after 5 seconds there are still active connections the shutdown will abort,
otherwise, after 5 seconds the database will be shut down.
After shutdown, only SYSDBA or the database owner can create a connection to the database. This is only a viable option if your application it self doesn't use SYSDBA or the database owner account.
You bring the database back online using:
gfix -online <your-database>
For more information, see also Gfix - Database Housekeeping: Database Startup and Shutdown
Well, not an elegant way, but works...
I try to rename the database file.
If there is someone accessing the database, the rename operation will give me
an exception, saying that the file is in use by some process.
If rename succeeds, new users will not be able to access the database
anymore (the connection string used by my systems is not changed).
I run the exclusive process I have to.
Rename the database file to its original name, allowing new users to
connect again.
I post my solution in the hope that helps someone facing a similar problem.
Our new version of the product will probably a Web application and the database was not choosen yet, but certainly will no be Firebird.
Thanks to all that tried to give me an answer.
I try to setup an OpenLDAP-Server that I can use as backend for a WebSSO (LemonLDAP::NG). This specific WebSSO allows to store the sessions inside the LDAP backend.
My problem is that it seems that whenever I connect to the LDAP backend to store session data ~1 out of 10 times it works, the other times LDAP rejects the authentication.
Logs for failed attempts and for successful attempts can be found here
As you can see the maker of LemonLDAP::NG thinks the error is within OpenLDAP (or my configuration of OpenLDAP). I'm out of ideas and open to suggestions.
Looks like someone changes OpenLDAP DB during your session. Don't you have any processes with access to MDB file except this instance of OpenLDAP?
It may be slapadd/slapmodify/2nd slapd instance with the same directory value in config.
If not, could you show your slapd.conf (don't forget to change rootpw)
I am working on Mongodb authorization.
I added users and am using mongod --auth while connecting to the database so that only authorized users are able to see the database.
Right now, mongo db can only be able to access throught vpn.
Suppose if a hacker breaks into the server machine, he can close the existing mongod connection(which was running with security using --auth) and can start a new connection without authentication mode after which he can see all the data of the database.
How can we secure database so that everytime it asks for the username/password to be provided.
Or some other ways to prevent this.
Thanks.
If he breaks into the server machine, he won't restart mongo. He would simply copy the mongo database and open it on his own machine, without using mongo at all.
If the attacker has the control of a server running process P1, P2, ... each Pi has to be considered breached, including theirs data.
The exception is strong isolation (i.e. virtual machines) and crypto; if the application crypts all its data with a key whose generation is not fully automated (i.e. a passphrase to be inserted on the startup, a challenge/response the administrator needs to pass during the boot, etc ...) this may prevent the attacker from getting all the bits to decrypt it. Otherwise, if the application is able to encrypt and decrypt without any human help, the attacker is able to do it as well.
Those things do not apply to mongo, that does not have support for stuff like that. Good old SQLs have it but they are not trendy any more ;)
On the specific user: are you afraid they will break into as mongodb or as another user? Because if they get the user foo, they still may have problems in accessing mongodb (data or process) if local permissions are well set. But again, people tend to consider the local privilege escalation (i.e. moving from foo to root and then to mongodb) something that happens when someone breaches. In roughly 100 pentests I managed to get access to a machine, probably just once or twice I could not escalate.
I'm trying out MonjaDB (eclipse plugin) to access a remote sharded MongoDB database, but for every command I try to execute it keep asking the username and password, which makes the plugin baregly useful in this scenario.
The MonjaDB preferences page and connection wizard does not contain any information about how to persist credentials.
Sounds like a connectivity issue where you lose the connection very so often that you need to input your credentials every time you try to run a command. I've never had this issue and have been using MonjaDB for quite some time.
You may try connecting to a database on a different host, or from a different machine to see if you can reproduce this issue.
Alternatively, there are many non-eclipse GUI MongoDB clients for various platforms that you may have to resort to.