sal88 Posted August 6, 2019 Posted August 6, 2019 (edited) We're about to migrate our filemaker server to the cloud, and have it open, so it can be reached by any public IP. We will switch to external authentication via Azure AD for all our users, which I understand will allow us to use MFA. However, aside from the externally authenticated users, there will be the one admin user within our database, which is of the usual 'filemaker user' type. Is it not possible that this could be subject to a brute force password attack? Would the workaround be to remove this user and have an externally authenticated admin user? Is this safe? Thanks Edited August 6, 2019 by sal88
Josh Ormond Posted August 6, 2019 Posted August 6, 2019 There are various thoughts regarding whether to leave the admin account intact or not. Here are some general thoughts for you to do some additional research into. 'admin' is a pretty common username, and definitely makes it easier for someone to use that to try and login. It's a good idea to, at the very least, change the user name to something else not as easily guessed. Obviously, makes sure it has a strong password. And don't lose it, or store it on a sticky note. Newer versions of FileMaker ( 17+ ) have an Account Lockout feature that slows down brute force attacks. Encryption At Rest ( EAR ) prevents someone from replacing part of the file to remove the password. Also, don't lose this password, or there is no way to retrieve the data. Full Access Accounts through External Authentication. Well, there are some dangers here. Somewhat mitigated by EAR, but you should at least recognize what the danger is. Someone could replicate your authentication groups that you use in the FileMaker file, in their own environment, and give themselves access to the file with Full Access privileges.
sal88 Posted August 6, 2019 Author Posted August 6, 2019 Thank you for your advice Josh. Re someone being able to replicate our authentication groups, can this only occur if they actually have the file? Or can they access a hosted file in such a way? Would it work for Azure AD authentication? From the configuration it looks as though in this instance FMS would actually be conferring with the Azure server that the user is really from that genuine Azure AD group. I suppose we would want to remove the risk of any unauthorised access to the file even if it was non-admin. From the sounds of it we'll change the admin username, and utilise the account lockout (I take it this is automatically in place), as well as keep track of access logs should such an attack be attempted. Thank you!
OlgerDiekstra Posted August 6, 2019 Posted August 6, 2019 44 minutes ago, Josh Ormond said: Full Access Accounts through External Authentication. Well, there are some dangers here. Somewhat mitigated by EAR, but you should at least recognize what the danger is. Someone could replicate your authentication groups that you use in the FileMaker file, in their own environment, and give themselves access to the file with Full Access privileges. In theory it would be possible for someone to compromise either (in the OP's case) Azure AD and redirect the authentication requests to another server with the same usergroups/usernames. The problem for the attacker is firstly to know what usergroups are used, but compromising Azure? That's a big ask. While in theory possible, I think practically the chances of this happening are pretty slim to nil. It would probably have to be a state actor. The other way (which is what Josh is referencing) is when someone has a copy of the DB and uses their own AD to authenticate. Again, they would have to know what usergroups need to be used, along with a few other details to convince FM to connect to their AD. With EAR, they can't look into the DB to see what usergroups are used, and if your usergroup names are non-standard, guessing them will end up being too time consuming. On top of that, with EAR they can't even mount the DB without knowing the EAR password. I think it's pretty save to say that the likely hood of your database being compromised (taking all the above into account) is pretty slim. Even if this were a database with very valuable info.
sal88 Posted September 10, 2019 Author Posted September 10, 2019 Thanks all. One more query: Are there any security concerns when saving the encryption password in FileMaker Server? So admins do not have to type in the encryption password each time they open a database. Thanks
Wim Decorte Posted September 13, 2019 Posted September 13, 2019 Of course. Having to know the encryption key before being able to open the files protects against an unauthorized person opening the file. By then you'd be several layers in already, but it is a good extra line of defense. On 8/6/2019 at 6:22 PM, sal88 said: Thank you for your advice Josh. Re someone being able to replicate our authentication groups, can this only occur if they actually have the file? Yes, they would have to have a copy of the files. The most likely source is from a backup. Protect your backups 1
sal88 Posted September 18, 2019 Author Posted September 18, 2019 Thanks Wim. This is a slightly silly question but is the saved encryption password itself encrypted? i.e. if someone gained access to the server (the host of FMS, not FMS itself), would they be able to extract the encryption password, were it saved in FMS?
Wim Decorte Posted September 18, 2019 Posted September 18, 2019 Yes, IIRC it is stored as a one-way hash. Just like FM passwords in a FM file.
Recommended Posts
This topic is 1891 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now