I am trying to set up a web application to work in IIS.
Among other things, I have created an "application" node pointing to my directory with binaries.
That application node uses pass-through-authentication, and it uses an AppPool for which my current user is set as the identity.
For some reason, IIS thinks it cannot access those files, as evidenced by the "Test Connection" output:
The user name + password combination is definitely correct, as IIS checks the validity of the credentials already upon input.
Note that this is by far not the first time this is happening: I have set up this web application on many, many machines already over the past five years, and yet, every single time a new developer joins the team, or we have to set up a new machine, we keep struggling with these access rights issues for multiple hours, or even days.
In the end (just like I have started in this case), all kinds of users (<machine name>\User, <machine name>\Benutzer, "Everyone", authenticated users, administrators, anonymous user, IIS_IUSRS, ...) have been granted full access to all files on the disk. Usually, at some point (after so much trying, configuring, switching forth and back, that no-one knows what actually solved the issue), the problem is gone.
What is a more systematic and minimal approach to troubleshooting (or, better yet, avoid) this issue when setting up a web application in IIS?
For file access issues, use Process Monitor will be fine.
Set the filter as "Process Name is w3wp.exe" "Result is not SUCCESS"
Add "user" column. Then you can check at which step, user access files unsuccessfully.
Related
Recently we implemented a feature which dynamically generates a LESS file in our App_Themes folder. This is done on application start.
This requires us to give the #ApplicationPoolIdentity# write access to the App_Themes folder.
Our system administrator, however, does not want us to give the #ApplicationPoolIdentity# that write access. For security reasons.
Is it insecure to do that? What are the security risks?
If there were any remote code execution vulnerabilities in your application, or within ASP.NET or IIS itself, anyone compromising your system through your application or web server will likely get a command shell, and be logged in as e.g. DefaultAppPool on your server.
If there is write access to a folder, then the attacker could write to this folder themselves.
For example, they could host their own content on your site at example.com/App_Themes/index.html, or they could upload an exploit that allowed priveledge escalation to that of administrator. In the latter case they would probably need executable permissions too, unless they could in someway make the webserver execute it, for example by requesting the URL of the dropped exploit.
Of course, the vulnerability has to be there in the first place for this to happen. Preventing write access too can be viewed as "defence in depth", however if this is needed by your application then it may be an acceptable risk. An alternative is to find another way to implement your desired functionality.
In the Azure Management Portal, you can configure your website. As an example, you can change the PHP version your website is using. When you have edited a configuration option, you have to click “Save”.
So far, so good. But you also have the option to restart your site (by clicking “Restart“ next to “Save”).
My question is, when should you restart your website? Are there some configuration changes that require a restart, and others that don't? I haven't found any hints in the user interface.
Are there other situations that require a restart? Say, the website has been running for a given time without a restart?
Also, what are the consequences of restarting a website? Does it affect cookies/sessions in any way (i.e. delete a user's shopping cart or log them out)? Are there any other consequences I should be aware of?
Generally speaking, you may want to restart your website because of application performance issues. For example, you may have a memory leak in your application, connections not getting closed, or other things that would degrade the performance of the application over time. As you monitor your website and observe conditions like this you may make a decision to restart it. Even better, you may even automate the task of restarting when these conditions occurr. Anyway, these kinds of things are not unique to Azure Websites. You would take similar actions for a website running on-premises.
As for configuration changes, if you make a change to your web.config file, this change is detected and your website would be restarted automatically for you. Similarily, if you were to make configuration changes in the CONFIG page of your website in the Azure Management Portal such as application settings, connection strings, etc., then Azure Websites will detect this change to your environment and automatically restart it.
Indeed, restarting a website will result in any session data kept in memory being lost for that instance. Additionally, if you have startup/initialization code that takes time to complete then that will have to be rerun. Again, this is not anything unique to Azure Websites though.
We're using vlad the deployer for deploying rails apps to production and test servers. All our servers are Ubuntu servers.
We have a problem related with linux permissions.
Vlad uses ssh to put files on any server, be it production or test. My company has several people, and each one has a different account on each server.
On the other hand, the way our Apache server is configured, it uses the "owner" of a website directory for reading files on that directory.
As a result, the user that makes the first deployment becomes the "owner" of the site; other users can't make deployments - Apache will not be able to read the modified files, since the owner has changed.
Normally this isn't much of an issue, but now holidays are approaching and we'd like to solve this as cleanly as possible - for example, we'd like to avoid sharing passwords/ssh keys.
Ideally I would need one vlad task that does something to the permissions of the deployed files so they could be completely modified by other users. I don't know enough about unix commands in order to do this.
I would do it with group permissions.
have the web root be /var/www/your-app/current
/var/www/your-app/ should be group writable by the group that all persons doing deploys belong to.
set up the deploy scripts so that they write to a directory called /var/www/your-app/>timestamp< where timestamp is the current timestamp.
/var/www/your-app/current is a symlink, and when you have sucessfully copied all files to the new directory you update the target of the symlink, so that it points to the directory you created.
This way everyone can deploy, and you can see who deployed what version.
This also makes the deploy atomic, so nothing will break if you lose your network connection in the middle of the deploy.
Since you won't delete the old catalogs, you can easy do a rollback to a "last good" state, if you manage to introduce some bug.
Why don't you make all the files publicly readable? In the ~/.bashrc of each user put the line
umask o=r
http://en.wikipedia.org/wiki/Umask
BTW I have never heard of such an Apache option; are you saying when Apache reads a file from /home/USER it runs with the UID of USER, instead of "nobody" or "apache"? That sounds wonky.
I've been fighting with it for a couple months now and I've only found a couple ways to do it:
Use a single shared account for all the users deploying to the server (boo!)
Use different accounts, but make a chown to a common user account (www-data, rails, or similar) before performing account-dependant tasks (such as the svn update). This might work, but I haven't tested it.
Use access control lists. Someone has hinted at me that this might be the right solution. However, I don't have the knowledge or time to make this work properly.
For now, we are just continuing using one single user per project, and chowning everything manually when needed. It's a bit of a pain, but it works.
Usually we define iis web sites which allow anonymous authentication to run under the IUSR_ComputerName account which has very limited privileges. For example we may decide it cannot access the file system. How does that make our web site any more secured? The user cannot run code on it anyway - only our website code runs and we make sure it does not cause any harm.
Edit: I understand why it is good to be on the safe side (e.g. iis exploit). My question is if there is any direct reason. For example, if I would never give a guest account full privileges on a sql server as it would immediately allow him full control over my server. This does not seem to be the case with iis.
we make sure it does not cause any
harm
You can be never sure about it doesn't cause any harm. One day, it might be exploited, and probably the less privileged user would save your data. No offense, but no one writes perfect code, therefore no code is vulnerability free.
If you have any network service you should assume that some random person on the internet has a command prompt on your machine running as that services's owner.
Now ask what damage that user good do?
Typically, you may need to run your web site in a way that is a little less hardened from a security standpoint than, say, a domain server or exchange. For example, you may need to permit FTP access. Obviously, Internet web sites need to be accessed from the Internet so you cannot simply block all access with your firewall.
Because of the higher vulnerability, it is prudent to run your service with an account that has limited permissions. In the case where a malicious user does succeed in copying their own programs to be run on your server, those programs will have severe limitations as to what they can do.
You can run code on the server, for example you can delete files in a directory if the permissions are not set.
In our administration team everyone has root passwords for all client servers.
But what should we do if one of the team members is not longer working with us?
He still has our passwords and we have to change them all, every time someone leave us.
Now we are using ssh keys instead of passwords, but this is not helpful if we have to use something other than ssh.
The systems I run have a sudo-only policy. i.e., the root password is * (disabled), and people have to use sudo to get root access. You can then edit your sudoers file to grant/revoke people's access. It's very granular, and has lots of configurability---but has sensible defaults, so it won't take you long to set up.
I would normally suggest the following:
Use a blank root password.
Disable telnet
Set ssh for no-root-login (or root login by public key only)
Disable su to root by adding this to the top of /etc/suauth: 'root:ALL:DENY'
Enable secure tty for root login on console only (tty1-tty8)
Use sudo for normal root access
Now then, with this setting, all users must use sudo for remote admin,
but when the system is seriously messed up, there is no hunting for
the root password to unlock the console.
EDIT: other system administration tools that provide their own logins will also need adjusting.
While it is a good idea to use a sudo only policy like Chris suggested depending on the the size of your system an ldap approach may also be helpful. We complement that by a file that contains all the root passwords but the root passwords are really long and unmemorable. While that may be considered a security flaw it allows us to still log in if the ldap server is down.
Aside from the sudo policy, which is probably better, there is no reason why each admin couldn't have their own account with UID 0, but named differently, with a different password and even different home directory. Just remove their account when they're gone.
We just made it really easy to change the root passwords on every machine we admininster so when people left we just ran the script. I know not very savvy but it worked. Before my time, everyone in the company had access to root on all server. luckily we moved away from that.
Generally speaking, if someone leaves our team, we don't bother changing root passwords. Either they left the company (and have no way to access the machines anymore as their VPN has been revoked, as has their badge access to the building, and their wireless access to the network), or they're in another department inside the company and have the professionalism to not screw with our environment.
Is it a security hole? Maybe. But, really, if they wanted to screw with our environment, they would have done so prior to moving on.
So far, anyone leaving the team who wants to gain access to our machines again has always asked permission, even though they could get on without the permission. I don't see any reason to impede our ability to get work done, i.e., no reason to believe anyone else moving onwards and upwards would do differently.
Reasonably strong root password. Different on each box. No remote root logins, and no passwords for logins, only keys.
If you have ssh access via your certificates, can't you log in via ssh and change the root password via passwd or sudo passwd when you need to do something else that requires the password?
We use the sudo only policy where I work, but root passwords are still kept. The root passwords are only available to a select few employees. We have a program called Password Manager Pro that stores all of our passwords, and can provide password audits as well. This allows us to go back and see what passwords have been accessed by which users. Thus, we're able to only change the passwords that actually need to be changed.
SSH keys have no real alternative.
For management of many authorized_keys files on many servers you have to implement your own solution, if you do not want the same file on every server. Either via an own tool, or with some configuration management solution like puppet, ansible or something like that.
Else a for loop in bash or some clush action will suffice.
Anything besides SSH logins:
For services you run that are login-based, use some sort of authentication with a central backend. Keep in mind that noone will do any work if this backend is unavailable!
Run the service clustered.
Don't do hacks with a super-duper-service backdoor account, to always have access in case something breaks (like admin access is broken due to a misconfiguration). No matter how much you monitor access or configuration changes affecting this account, this is 'just bad'(TM).
Instead of getting this backdoor right, you might as well just cluster the application, or at the very least have a spare system periodically mirroring the setup at hand if the main box dies, which then can be activated easily through routing changes in the network. If this sounds too complicated, your business is either too small and you can live with half a day to two days downtime. Or you really hate clusters due to lacking knowledge and are just saving on the wrong things.
In general: If you do use software unusable with some sort of Active Directory or LDAP integration you have to jump the shark and change passwords for these manually.
Also a dedicated password management database that can only be accessed by a very selected few directly, and is read-only to all the others, is very nice. Don't bother with excel files, these lack proper rights management. Working with version control on .csv files doesn't really cut it either after a certain treshold.