I have a sudo account (not root) on several CentOS servers. We would like to share the cluster with other uses who do not have an account for research purpose. (By share I mean users can reserve a time slot to use the cluster exclusively.) But setup an account in the OS for each user is too annoying. Is there a good way to grant them authority to read/write/execute their own files during a certain period of time? I am thinking something like temporary username and password that they can use to login through some interface (like a webserver) I offered. And the username and password will expire after when their reservation. Any idea?
You can share your unix user account among several users, by using SSH key authentication.
In a nutshell, each user generates a public/private key combination. The allowed public keys are then listed in the following file on the shared unix acount:
$HOME/.ssh/authorized_keys
I'm not aware of a mechanism to control when users are allowed to login. Presumably one could have a cronjob that swaps different versions of the authorized_keys file, dependent on the time of day. (Seems like over engineering the solution, users can easily over-ride this kind of restriction).
Articles:
http://wiki.centos.org/HowTos/Network/SecuringSSH
http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html
Related
I have an EC2 instance, where the backend for my Mobile App is hosted.
My developer needs access to my server, in order to upload the new code and I guess test it also.
Now, I do not want to give him FTP details, so here is what I did:
Created a new Linux User
Created a new Key pair from the EC2 Console
Created a .ssh directory
Change the file permission to 700 (so only file owner can read/write/open the dir)
Created authorised_keys with the touch command in the .ssh directory
Changed the file permission to 600 (so only file owner can read/write the dir)
Retrieved the public key for the keypair
Add the public key in the authorised_keys
Now I can share the new generated PEM file with my Developer along with the username and my EC2 host IP address.
But I don't understand why not I can directly to this by creating an IAM User from the AWS Console and set his permission accordingly?
I am really confused because I first wanted to do it the IAM way but everyone suggested I go with Linux user - isn't it the same thing?
Also, I shall delete this user entirely once he is done with the work - right?
Furthermore, I don't understand something... after doing all this and setting up the new Linux user, I am able to connect to my server using the Linux Username and Unix Password only - without using the PEM file that I have created - how is that?
Also, technically that new Linux user can simply delete my main Linux user... I mean I can simply right-click on the User and press delete via Filezilla for e.g. How can I prevent this from happening? Even though that wouldn't matter, as he could also simply delete my entire backend?
I have the following on my server now:
Home Folder
Home Folder > appBackend
Home Folder > mainLinuxUser
Home Folder > newLinuxUser
And last but not least, why is everyone always saying to never share the Private PEM file with anyone.. at the end of the day, if I only allowed specific IP address to connect to my EC2, then I should never be worried about anything? Same as I have done for my MongoDB - only if I add the IP address, only then that person can connect and view my Database. So with all the previous developers, I had shared my DB Configuration, it won't matter since their IP is not in my Security Group anymore - am I right?
Sorry, I am new to all this and I am trying to get my head around it all. I appreciate any help!
Creating Linux user vs IAM user :
IAM Users are for users who can access AWS resources based on permissions you provide. That means if you create IAM user with full access to EC2 and provide the details to your developer, he/she can login to AWS and have full access to EC2. He/She can create,start/stop, reboot, terminate your EC2 servers etc.
IAM Users/Groups are created to restrict access to AWS resources such as EC2, S3, VPC etc. and not for OS which runs inside EC2.
Yes, delete the user and keys once the work is done.
For login to linux sever, you can use either username-password or username-key. Check your user settings if you have set login with password. Use "--disabled-password" or similar when creating new user. Refer it here : https://aws.amazon.com/premiumsupport/knowledge-center/new-user-accounts-linux-instance/
Check if you new user has root or sudo access. If you have provided sudo or root access, new linux user can execute such actions.
Note that, it is a best practice to delete the default root user on EC2 once server is up and running. ec2-user or ubuntu. Reason being, if your pem key which you had used when creating EC2 is compromised, your server is compromised. These default root users are known to everyone unlike specific users you'll create. Hence better to delete them.
Also follow the least access principle and provide only the least required access to new user. This means, you should create user as per the need or activity and restrict access to only that activity. Eg, if your user needs to only copy the files to/from within specific folders, set your user with a group and assign permissions to required folders. Do not provide any sudo access to it.
Similarly, you can create an admin user with access to sudo, however, make sure this user is not shared to other developers.
Our Perforce server is set to security level 0, meaning that most users don't require passwords. This is fine (and necessary for our legacy tools). However I recently discovered to my horror that some admin user accounts don't have passwords set. This is obviously very bad.
How can we configure Perforce to require passwords for superuser accounts, but not for regular accounts?
I seem to remember this was the case by default, but someone seems to have defeated it, and now I can't find any mention of it in the Perforce manual.
We cannot change the server to require passwords from all users without breaking the whole company. Setting the server security level to >1 globally is not a workable answer.
Nope, this was never a feature.
My solution to this has historically been to have a script that tries to run a command as each user. In your case you want to only look at users with admin-level permissions, so have the script run a command that only admins should be able to run:
p4 -u $USER protect -o
If this succeeds (despite the lack of any password being provided), deal with them as you like. In my case I wasn't targeting admin users specifically so I just had my script set a random password and email it to them with instructions for changing it.
Given your scenario, my recommendation would be to just revoke admin access, since someone who's not savvy enough to secure their own account probably shouldn't be trusted with the ability to grant access to others, install triggers, permanently delete data, etc...
My campus runs a gitlab server. I am a user, not an admin. Campus policy forbids giving LDAP access to off-campus collaborators/co-authors, but has no problem in principle with allowing such folks to have "Developer" level access to non-public repositories on an invitational basis. Is it possible to have my off-campus colleagues send me an SSH key, and have the gitlab admin create a no-login user with that key who I could then add as a "Developer" member to selected projects? If it's do-able, what's the magic process so I can pass it along to the IT support folks?
Ask your IT support team to create Gitlab account with specific permissions for those developers without LDAP account. And then simply add them to the repositories and ask them to upload ssh keys.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'd like to know what people consider best practice for securing the Admin sections of websites, specifically from an authentication/access point of view.
Of course there are obvious things, such as using SSL and logging all access, but I'm wondering just where above these basic steps people consider the bar to be set.
For example:
Are you just relying on the same authentication mechanism that you use for normal users? If not, what?
Are you running the Admin section in the same 'application domain'?
What steps do you take to make the admin section undiscovered? (or do you reject the whole 'obscurity' thing)
So far, suggestions from answerers include:
Introduce an artificial server-side pause into each admin password check to prevent brute force attacks [Developer Art]
Use separate login pages for users and admin using the same DB table (to stop XSRF and session-stealing granting access to admin areas) [Thief Master]
Consider also adding webserver native authentication to the admin area (e.g. via .htaccess) [Thief Master]
Consider blocking users IP after a number of failed admin login attempts [Thief Master]
Add captcha after failed admin login attempts [Thief Master]
Provide equally strong mechanisms (using the above techniques) for users as well as admins (e.g. don't treat admins specially) [Lo'oris]
Consider Second level authentication (e.g. client certificates, smart cards, cardspace, etc.) [JoeGeeky]
Only allow access from trusted IPs/Domains, add check to basic HTTP pipeline (via e.g. HttpModules) if possible. [JoeGeeky]
[ASP.NET] Lock down IPrincipal & Principal (make them immutable and non-enumerable) [JoeGeeky]
Federate Rights Elevation - e.g. email other admins when any admin's rights are upgraded.
[JoeGeeky]
Consider fine-grained rights for admins - e.g. rather than roles based rights, define rights for indicidual actions per admin [JoeGeeky]
Restrict creation of admins - e.g. Admins cannot change or create other admin accounts. Use a locked-down 'superadmin' client for this. [JoeGeeky]
Consider Client Side SSL Certificates, or RSA type keyfobs (electronic tokens) [Daniel Papasian]
If using cookies for Authentication, use separate cookies for admin and normal pages, by e.g. putting the admin section on a different domain. [Daniel Papasian]
If practical, consider keeping the admin site on a private subnet, off the public internet. [John Hartsock]
Reissue auth/session tickets when moving between admin/normal usage contexts of the website [Richard JP Le Guen]
These are all good answers... I generally like to add a couple additional layers for my administrative sections. Although I've used a few variations on a theme, they generally include one of the following:
Second level authentication: This could include client certificates (Ex. x509 certs), smart cards, cardspace, etc...
Domain/IP restrictions: In this case, only clients coming from trusted/verifiable domains; such as internal subnets; are allowed into the admin area. Remote admins often go through trusted VPN entrypoints so their session would be verifiable and is often protected with RSA keys as well. If you're using ASP.NET you can easily perform these checks in the HTTP Pipeline via HTTP Modules which will prevent your application from ever receiving any requests if security checks are not satisfied.
Locked down IPrincipal & Principal-based Authorization: Creating custom Principles is a common practice, although a common mistake is making them modifiable and/or rights enumerable. Although its not just an admin issue, it's more important since here is where users are likely to have elevated rights. Be sure they're immutable and not enumerable. Additionally, make sure all assessments for Authorization are made based on the Principal.
Federate Rights Elevation: When any account receives a select number of rights, all the admins and the security officer are immediately notified via email. This makes sure that if an attacker elevates rights we know right away. These rights generally revolve around priviledged rights, rights to see privacy protected information, and/or financial information (e.g. credit cards).
Issue rights sparingly, even to Admins: Finally, and this can be a bit more advanced for some shops. Authorization rights should be as discreet as possible and should surround real functional behaviours. Typical Role-Based Security (RBS) approaches tend to have a Group mentality. From a security perspective this is not the best pattern. Instead of 'Groups' like 'User Manager', try breaking it down further (Ex. Create User, Authorize User, Elevate/Revoke access rights, etc...). This can have a little more overhead in terms of administration, but this gives you the flexibility to only assign rights that are actually needed by the larger admin group. If access is compromised at least they may not get all rights. I like to wrap this in Code Access Security (CAS) permissions supported by .NET and Java, but that is beyond the scope of this answer. One more thing... in one app, admins cannot manage change other admin accounts, or make a users an admin. That can only be done via a locked down client which only a couple people can access.
If the website requires a login for both regular activities and admins, e.g. a forum, I'd use separate logins which use the same user database. This ensures that XSRF and session-stealing won't allow the attacker to access administrative areas.
Additionally, if the admin section is in a separate subdirectory, securing that one with the webserver's authentication (.htaccess in Apache for example) might be a good idea - then someone needs both that password and the user password.
Obscuring the admin path yields almost no security gain - if someone knows valid login data he's most likely also able to find out the path of the admin tool since he either phished it or keylogged you or got it via social engineering (which would probably reveal the path, too).
A brute-force protection like blocking the user's IP after 3 failed logins or requiring a CAPTCHA after a failed login (not for the first login as that's just extremely annoying for legit users) might also be useful.
I reject obscurity
Using two authentication systems instead of one is overkill
The artificial pause between attempts should be done for users too
Blocking IPs of failed attempts should be done for users too
Strong passwords should be used by users too
If you consider captchas ok, guess what, you could use them for users too
Yes, after writing it, I realize that this answer could be summarized as a "nothing special for the admin login, they are all security features that should be used for any login".
If you do use only a single login for users who have both normal-user privileges and admin privileges, regenerate their session identifier (be it in a cookie or a GET parameter or whatever...) when there is a change in the level of priviledge... at the very least.
So if I log in, do a bunch of normal user stuff and then visit an admin page, regenerate my session ID. If I then navigate away from an admin page(s) to a normal user page, regenerate my ID again.
Have a good admin password.
Not "123456" but a sequence of letters, digits and special characters long enough, say, 15-20 characters. Like "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".
Add a pause for each password check to prevent brute force attack.
Here are some other things to consider:
One option to consider, especially if you manage the admin's computers or they are technically competent, is to use something based on SSL certificates for client authentication. RSA keyfobs and whatnot can also be used for added security.
If you're using cookies at all - perhaps for an authentication/session token - you probably want to ensure that the cookies are only sent to the admin pages. This helps mitigate the risks posed to your site by stealing cookies, by either layer 1/2 compromise or XSS. This can be done easily by having the admin portion being on a different hostname or domain as well as setting the secure flag with the cookie.
Restricting by IP can be smart as well, and if you have users throughout the internet you can still do this, if there is a trusted VPN that they can join.
We use Windows Authentication for admin access. This is most practical way of protecting admin areas while keeping the authentication seperate from what applies to general end-users. The system admin manages the Admin user access credentials and enforces password policies on the domain user account.
The strict way is to have two complete different "farms" including databases, servers and all and move the data from one farm to the other. Most modern, large scale, systems use this approach (Vignette, SharePoint, etc.). It's normally refered to as having different stages "editing stage" -> "preview stage" -> "delivery stage". This method lets you treat content/config the same way you treat code (dev->qa->prod).
If you are less paranoid you can have a single database but only have your admin section available on the "editing" servers. I mean, only have the editing scripts/files placed on the editing server.
Naturally the editing stage should only be available on a local intranet and/or using a VPN.
This may seem a bit of an overkill and may not be the easiest solution for all usage cases, but it is definetly the most robust way of doing things.
Note that things like "have strong admin passwords" are nice, but still leave your admin open to smart attacts of all sorts.
It very much depends on what kind of data you want to protect (legal requirements and such).
Alot of suggestions is about authentication.. I think you just should consider using OpenId / Facebook authentication as login. (They will most likely spend more resources on authentication security then you)
Save changes as well as updating values in the database. That way you can rollback changes from user X or between date X and Y.
I didn't notice anyone mention storage/validation of the admin password. Please please please do not store the PW in plain text, and preferably not even something that can be reversed - use something like a salted MD5 hash so that at the very least if someone happens to retrieve the stored "password" they don't have anything terribly useful, unless they also have your salt scheme.
Add a password field and a security question that the Administrator will know, e.g. what was your first girlfriend name, or randomize the questions everytime viewing the admin panel.
Perhaps you could always put the administration section in a big directory, e.g.
http://domain.com/sub/sub/sub/sub/sub/index.php
But that's not really good hah.
Perhaps you could include a query string in the home page, like:
http://domain.com/index.php?display=true
When it does, the username and password field will appear.
When supporting a new web app in an enterprise environment, it is often necessary to log in as a specific user in order to diagnose a real or perceived problem they are having. Two opposing issues apply here:
Best practice is to use hashed or encrypted passwords, not clear text. Sometimes, there is a third-party SSO (single sign-on) in the middle. There is no way to retrieve the user's password. Unless the user provides it (not encouraged), there is no way to log in as that user.
Many web app's have personalization and complex authorization. Different users have different roles (admin, manager, user) with different permissions. Sometimes users can only see their data -- their customers or tasks. Some users have read-only access, while others can edit. So, each user's view of the web app is unique.
Assume that in an enterprise environment, it isn't feasible to go to the user's desk, or to connect directly to their machine.
How do you handle this situation?
Edit: I want to reiterate that in a large financial institution or typical Fortune 500 company with hundreds of thousands of employees all of the country, and around the world, it is not possible for a mere developer in some IT unit to be able to directly access a user's machine. Some of those are public-facing web apps used by customers (such as online banking and stock trading). And, many of those are intranet applications rely on Active Directory or an SSO, meaning that user credentials are the same for many applications. I do thank you all for your suggestions; some may be highly useful in other kinds of environments.
A number of these ideas inconvenience the user, either by forcing them to change their password, or by occupying their desktop for your debugging session.
Markc's idea is the best: augment your authentication logic to allow superusers to log in as a particular user by supplying not the user's credentials, but the user's name plus their superuser credentials.
I've done it like this in the past (pseudo-ish python):
if is_user_authenticated(username, userpassword):
login the user
else if ':' in userpassword:
supername, superpassword = userpassword.split(':')
if is_superuser_authenticated(supername, superpassword):
login the user
In other words, if the username and password don't authenticate, if the password has a colon, then it's actually the admin username and admin password joined by a colon, so login as the username if they are the right admin username and password.
This means you can login as the user without knowing their secrets, and without inconveniencing them.
For our web applications we use a process that for lack of a better term is defined as 'hijacking' a user's account.
Basically, administrators can 'hijack' a user's account with a simple button click. In the code, you simply use a unique identifier (user id works in a less secure environment) that then establishes the necessary credentials in the session so that they can then work within that user's profile. For a more secure environment you could use a unique hash for each user.
In order to ensure that this hijack method is secure, it always first verifies that the request is being made by an authenticated administrator with the appropriate rights. Because of this it becomes necessary for either the administrator's session to be hijacked or for their authentication credentials to be captured in order for someone to ever exploit the hijack function within the application.
I had 4 ideas. While I was typing 3 of them were already suggested (so I upvoted them)
Variant on idea 3 - impersonation:
To make this as "identical as possible" to a normal login with minimal code changes, you might add the ability to impersonate directly at login by supplying Admin credentials plus an alternate username, e.g. login as Admin:user, adminpassword. The system would treat this exactly as logging in as user with userpassword.
Idea 4: Can you access the password store? If so, temporarily replace the user's hash with the hash of a known password. (the passwords are often stored online in a database. A SQL Query tool can do the swaps )
An administrator should be able to change a user's password. Change the password for the user to something you know. You can then log in as that user.
Tell the user to reset his/her password after you are done debugging.
Usually by some sort of remote control software that can be used to view their desktop. If they're on a Windows terminal server, then the built in admin tools can be used for that. Otherwise I'd use something like VNC across an internal network, or an external service like LogMeIn (http://www.logmein.com/).
Could you have a testing environment where there is a regular cut of live data copied to (obviously sanitised to meet any security or data protection issues). A user similar in setup to the one having trouble could be used to troubleshoot or indeed the very user if this is allowed.
Use a remote desktop client as mentioned in other answers, but again this may not be practical for you. If you have these rights within the domain, I have heard of error handling even doing a screenscrape and including this in logs! but this sounds a little odd to me.
Could you have an admin tool to clone a user into a demo account?
The solution we have used in our web apps is to have the authN/authZ return the desired user as the effective user. We do this by having an admin feature to setup a masquerade, and then when we ask for the currently logged in user (current_user), we handle the masquerade:
def current_user_with_effective_user
if masked?
current_user_without_effective_user.masquerade_as
else
current_user_without_effective_user
end
end
alias_method_chain, :current_user, :effective_user