Skip to main content ↑ ↓
Secure Logging Started by Joshua Dickerson · · Read 8204 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Secure Logging

There will always be a vulnerability that we can't account for. Right now, if the system is compromised, the admin will likely never know how. That also means we as developers will have a hard time figuring that out.

We can't exactly secure PHP. At least, it is complicated for us to do and even more complicated for the user to implement. It would require jails for files which we want the system to be able to read/write/execute but not outside of those directories, except when we want to do mods. Which pretty much means it's impossible for us to implement this.

We can do a better job at security on the database though. We can also implement this with ease and minimal effort for the administrator. I'm not talking about locking down the database for everything. For instance, there is no way we can keep a malicious script from accessing the user's password while still having it able to update it.

What we can do is log everything that happens in the admin panel and not allow that log to be destroyed. The admin_log table should contain every action, not just ones that do changes. Every page that is accessed and every thing that is changed would be logged. There would be no way to turn this off without modifying the code. The regular database user must not have permissions to do anything but INSERT/SELECT on this table. This table should be allowed to be in a separate database with a separate database connection using a separate database user. This separation should make it easier for admins to understand the separation and not make a mistake. We should also document it and even test it in the admin panel and installation.

You might be concerned about the size of this table. How often does an admin visit the admin panel? Maybe once a day? If that. If they do, how many pages do they access? A dozen or so? So, a few dozen bytes. We could normalize it like crazy to save space. That would require more tables though. The admin could still prune the log. Just not with Elkarte or with the Elk db user(s).

Re: Secure Logging

Reply #1 –

Quote from: Joshua Dickerson – The regular database user must not have permissions to do anything but INSERT/SELECT on this table.

I'd highly suggest creating a how-to guide for people who don't know how to set permissions properly on databases and just hit the "Select All" when it comes to assigning permissions. I'm not keen on a separate database, especially for those who have a limited number of databases available from their host.

I love this, though. I've always wanted a comprehensive admin action log. Will it be flexible enough to log user-created actions (by mod or otherwise)? Will it keep copies of old input (like admin1 changed Feature Option #12 from No to Yes)? How about access, would this be accessible from a page on the admin panel or download-only (to keep the number of times it gets queried to a minimum)?

EDIT: So I messaged Jade about this over at SMF, and she had a thought: keep only the last 30 days of actions, someone can download a backup after 30 days if they so desire, and it keeps your table lighter.
Last Edit: November 21, 2015, 03:57:46 am by Eliana Tamerin

Re: Secure Logging

Reply #2 –

Documentation would be a necessity but having another database is not. You just need to make sure your users don't have the grants for the whole database.

Yes, it would need to log what the setting is changed to. It doesn't need to log before though. You would just see it looking like that on the screen.

You can't "keep only the last" because the whole idea is that the user has no ability to remove data.

Re: Secure Logging

Reply #3 –

Can you elaborate?

Re: Secure Logging

Reply #4 –

Ultimately, the best way to do this is with a separate authentication service. The application would ask that service the question "does the password XyZ match the user 123?" This authentication service would run completely separate from the main application and would only be accessed via a HTTP request. It could run on a separate server or container or virtual machine or just a jailed Apache process. So long as the main application can't access the authentication service's code.

The service could also handle brute-force checking since it would live on its own. It could handle logging the attempts, but that should only happen as another call to another service. It needs to handle authentication very quickly and without giving the user the ability to make changes.

Not sure it makes sense to be RESTful because you'd be GETting a confirmation of authentication by putting the password and id in the GET request. Then again... it does.

The database would be simple: id, password_hash, salt. Then another table for brute force checks which would be: id, request_ip, request_time.

Once you create a user (POST) it would create a salt for the user's password. Once the user is created, you cannot change the salt. The salt is only to store the user's password in the database. If the database gets compromised, the attacker would need to get past this layer in order to find the user's password. GET requests should also salt the passwords in the request string. A settings file would contain that salt and it would be per site/application.

Re: Secure Logging

Reply #5 –

I'm not sure if I got everything or I missed something.

If I understood what you are saying, we should have:
the forum (actually the forum's admin panel)
 an authentication service (jailed or "somewhere else")
* another database for logging admin actions

the forum sends the data to log to the authentication service, that one takes care to do the database authentication, and then the data are inserted?

...hmm... I like the idea to log everything, but that's far from being easy to set up for the "casual" user. I don't think I would be able to do have it working... :-\

Though, as I said, I like the idea, so, a slightly simpler and easier to implement solution could be... emails!
Actually, I'm thinking about something along the lines of what I did for backups: integrate gmail and gdrive using google apps script.
Roughly: the forums sends a formatted email to gmail [1], an Apps Script cronjob reads newly received emails, parses them and extract the relevant informations and stores them "somewhere" [2] for storaging and potential future usage.
Providing a good tutorial and the few lines of code for the Apps Script, anyone could implement such a system without the need to even have shell access.

In fact, this is exactly what you are describing (the authentication service is the gmail account, the database is the gdocs/fusion table), so I guess, writing a proper "layer" and a proper implementation it would be quite easy to switch from emails to any kind of logging mechanism. :D
1 Optionally with a token to verify the source, but that's a possibility, because a broken token could make things more difficult to track↵
2 Either a GDocs spreadsheet or a fusion table that I just discovered.↵
Bugs creator.
Features destroyer.
Template killer.

Re: Secure Logging

Reply #6 –

Disregard reply #5. The topic is about logging all admin actions and making them unremovable. So, you can't delete the table/rows other than with another user with more privileges.

That is easy to do with MySQL users. Just don't GRANT ALL to your users. Instead. Only give them per-table access to every table except the log table. On the log table, the user can only INSERT and SELECT but not REPLACE/DELETE/TRUNCATE/UPDATE etc.
 

Re: Secure Logging

Reply #7 –

Okay, I thought you were talking about logging in reply #5 as well. O:-)

Anyway, rely on an external service wouldn't be a bad thing (mostly): most people on shared hosting are not allowed to create database users, let alone control the permissions on the created databases (at least in my experience), so they would be cut out of this feature in any case.
My email-based-loggin could be a "low-cost" alternative for those that don't want or don't need to use a VSP or a dedicated.
Bugs creator.
Features destroyer.
Template killer.

Re: Secure Logging

Reply #9 –

Interesting tool.
I guess it technically could be integrated. But of course that's just my guts feeling based on what they have public on their website.
Bugs creator.
Features destroyer.
Template killer.

Re: Secure Logging

Reply #10 –

Other secure way except sms-authentication is to have own email provider, but is more slower option than sms, and mostly usefull for hiden boards, altho if the new members are registering directly to new email address through the forum register tab, and after redirected to the email platform for password maybe it would be also atractive way for avoiding spammers or spam bots, still i'll prefer the sms option coz in that way I can narrow the membership just to certain country, which as things stand now with ElkArte could be done just by secure question through the regeristering page, which eventualy would be obstacle for those that want to participate on the board but are not so motivated for ...

https://github.com/atech/postal/wiki

I am thinking also how to open room for guests but in parallel thread to the main, that would ease the pain of registering for those that want to jump in but dont have will to stick around, which would be ideal also as testing ground for new members to prove themselves that are not ordinary spammers, having also ability to quote but not to like/dislike posts, only question is how such parallel forum threads will make the forum code heavy and slow ...
Last Edit: December 29, 2017, 07:56:33 am by omBre

Re: Secure Logging

Reply #11 –

I think we are talking about two different things here: you about "log in" (i.e. the authentication), and the topic about "logging" (i.e. write logs of (admin) actions).

And please, try to open new topics to ask/suggest different things (like the guests one).
Bugs creator.
Features destroyer.
Template killer.