We have two backend applications, one that is reponsible for acquiring data from the internet and storing it in a database, and the other that is effectively a COMET server, accepting connections from the internet, hooked into the http pipeline via the HttpListener API.
In development, both these items have been created as console applications that are started manually under an admin account. Obviously, this is unsatisfactory from a security POV.
When we move to production, both these applications will be ported to run as Windows services using ServiceBase.Run and provided as installers for installation on the deployment platform.
As somebody who knows very little about Windows security, ACLs and the like, I would like to know what steps I can take to secure these applications (such as have them run in an account of lowest necessary privilege) and how one would create an installer that sets up the necessary service accounts and privileges for these accounts.
To be clear, I am not asking how to make a service installer - we have this already, but rather what steps are required to make the service installer actually install the service under a low privilege account with rights only to the minimum resources required to get the job done. Part of the answer would be how to allow the service account access to the Http pipeline.
EDIT: We can probably use a custom action with code from here for the http pipeline reservation.
Are there any other steps one might take to shore up the security of such applications?
TIA
I hope these articles will help you :
Designing Applications to Run at a Low Integrity Level
Defend Your Code with Top Ten Security Tips Every Developer Must Know
CLR security
Security Fundamentals
Managing Directory Security Principals in the .NET Framework 3.5
Building A Custom Security Token Service
Related
I have a project I am working on where I need to create an app and service package for Windows. I would like the service process to run as SYSTEM or LOCALSYSTEM so that credentials are irrelevant. The application frontend will be installed and executable by any user on the machine. Data from the frontend application will be passed to the service - most likely paths to directories selected by users. Once started the service will listen for a command to do some action while accepting the aforementioned paths.
I'm using C# on the .NET platform and I've looked into creating a standalone service and a standalone application separately as well as creating a WCF service library and host application - that's as far as I've gotten.
All of these methods seem overly complex for what I am trying to achieve. What is modern convention when attempting something like this? I'm willing and able to learn the best method for moving forward.
Edit: This was flagged duplicate. I'm not looking for information on HOW to communicate with a Windows service. That's remedial and not at all what I'm asking. I'm looking for validation that I'm on the right track and if I'm not, I'm looking for suggestions. I've been told that I'm on the right track and pointed towards named pipe binding.
Windows Service is certainly an option for hosting WCF, although it kind of is a deployment nightmare. It really depends on your environment and the capability and support of your system admins as I've had many clients where deploying a windows service, as you need admin rights to install and update it, was simply not practical.
Console applications may sound like a terrible idea but the practicality of being able to drop them on a share and run a powershell script to start them is very compelling.
But frankly IIS hosting has the most advantages in my mind as the product is designed for ease of deployment and up time. And you can use any transport binding in IIS that you can use in a Windows Service or Console.
As for the binding itself named pipe is not really a popular option in many enterprise scenarios as it is incompatible with anything but .NET. Although the same can be said for binary which is one of the more performant bindings. The WSHttpBinding is probably the most popular binding in scenarios that require unknown callers. WebHttpBinding is an interesting option as its HTTP/REST based, although that requires further decoration of your operations and honestly if your going that route you should really be using Web API.
I have a windows network (not connected to domain) and I need to provide some automation on each PC at certain time of the day. There are several tasks - launch executables, managing FS, transfering files. All this actions must be implemented via RDP, using C#. What is common approach to achieve this? I don't have experience using RDP within software. So are there .NET classes or free libraries I can use to get RDP functionality in my software. Thank you!
All the tasks you have listed relyed much more on security issues for machines within your network and a user logged-in priveledges a rather than a usage of RPD.
Within a windows domain the tasks like yours are usually delegated to ActiveDirectory administration and policies.
In case of a not Windows Domain Network you will need to use a mechanism that will be presented in following configuration:
a client installed on each particular machine under proper permissions. The client should implement a subscriber pattern.
a server installed on a "commander" machine. the server should inplement a publisher pattern.
There should be a lot of ready solution that should implement the concept of content disribution and starting specific scripts. I think that your investment in such tools research and evaluation will be much more time- and cost- effective rather than writing an app that "uses RPD functionality"
But if there is a reason that prevents usage of 3rd parties, I would go for implementaion of WCF service that will be installed on all clients. This service should be "trained" to do all your suff on client. Server side you will need an appliaction or a service that will publish events for clients or trigger known clients methods.
I have a web application that i would like it to check for updates, download and install them.
i know there are already some updater frameworks that works for windows applications, but is it possible for web applications ?
The first thing came to my mind when thinking of this is:
File permissions (i might not be able to replace all my application files due to file permissions)
Also touching the web.config or the bin folder will cause the application to restart.
I also thought about executing an exe from my web application that does the job, but i dont know if it could get shutdown because of a restart to the web application.
I would appreciate any ideas or solution to that case.
Thanks
Take a look at WebDeploy
It is meant to ease such tasks. Where you want to deploy a publish to a production server.
Rather than having your server check for updates and update itself, it would be simpler to just push updates to it when you have them.
Web Deploy allows you to efficiently synchronize sites, applications
or servers across your IIS 7.0 server farm by detecting differences
between the source and destination content and transferring only those
changes which need synchronization. The tool simplifies the
synchronization process by automatically determining the
configuration, content and certificates to be synchronized for a
specific site. In addition to the default behavior, you still have the
option to specify additional providers for the synchronization,
including databases, COM objects, GAC assemblies and registry
settings.
Administrative privileges are not required in order to deploy Web
applications.
Server administrators have granular control over the operations that can be performed and can delegate tasks to non-administrators.
This needs you to be running IIS7 though.
i want to deploy our official asp.net web application (Enterprise Resource Plan ) which mostly contain critical data. currently we have deployed it on internal machine on intranet now we want to open it for public i.e on web
what would be the best deploying strategy so that application remain fast,data secure and prevent unauthorized access.
we have also a public ip and also have a server machine.
It's not a deployment strategy you need, but really a check that your application has been properly architected and written with security in mind.
What sort of authentication do you use, how is your database secured, have you surveyed your code for possible security issues?
Microsoft do some good material on this - there's a lot to it and it depends on what domain you work in: http://msdn.microsoft.com/en-us/library/ff649874.aspx
Paddy is correct in that you need to make sure you application was securely written rather than do anything with your deploy strategy.
I did a quick search and found these sites which would be a good place to start:
http://www.symantec.com/connect/articles/five-common-web-application-vulnerabilities
http://www.owasp.org/index.php/Top_10_2007
Personally the most common things I see are:
SQL Injection
Cross Server Scripting (XSS)
I would make sure you don't have any of these vulnerabilities first.
I am going to be coding up a windows service to add users to a computer (users with no rights, ie just for authentication). (As a side note, I plan to use this method.)
I want to be able to call this windows service from another computer.
How is this done? Is this a tall order? Would I be better off just creating a Web Service and hosting it in IIS?
I have some WCF services hosted in IIS on the calling computer (they will do the calling to the proposed windows service). I have found that Hosting in IIS is somewhat problematic, so I would rather not have a second IIS instance to manage unless I need to.
(I will be using Visual Studio 2008 SP1, C# and Windows Server 2003 (for both caller and service host).
Thanks for the help
If you are thinking of hosting a web service in IIS just to communicate with an NT-service on that same machine, that is definitely more trouble than it is worth in this case.
As other answers have indicated you can make a WCF service with the operations you need and host that within the same NT-service that you want to interact with. You can easily secure this with certificates, or user accounts to make sure it is only controlled by the right people/machines.
If you need to control the NT-service itself, there are existing programs such as sc.exe to start, stop, configure, or query the status of your NT-service remotely.
However, you may want to consider seeking a solution without the overhead of creating an custom NT-service and a custom WCF service to interact with it. If you do, the Net User commands (sorry no link - new user limitation) or the AddUsers (see kb 199878/en-us) utility may be sufficient. If your remote "controller" can invoke these commands directly against the target machine you may not have to create any custom software address this need. Additionally you would have less software to maintain and administer on the target machine. You would just be using the built-in OS capabilities and admin utilities.
Finally, you will need to think about the security aspect, NT-services and IIS are usually run under very restricted accounts, many auditors would flip-out over any service running with sufficient permission to create or modify users locally, and especially on other machines. You'll want to make sure that the service could never be used to create users that do have more than the "authenticate" permission you indicated.
Edit: The net user command may not work against another machine's local users, but check out. pspasswd that along with PsExec to create users, should do what you need remotely.
Simply host a WCF service in the Windows Service. You'll then be able to call it remotely.
You can host a WCF service inside a Windows service. Take a look at the TCP binding (NetTcpBinding class). Both client and server will have to use WCF, but that doesn't sound like it will be an issue with your implementation.
Also, the section entitled "Hosting in Windows Services" in this MSDN article provides a walk-through of the process
If the windows service publishes a remoting interface then it can be accessed via that remoting interface.
Otherwise it's the same as accessing any other process running on a remote machine except that there may be some tools (e.g., sc) with built in support for executing against a remote machine (barring firewall complications).
Any IPC mechanisms applies; sockets, web services, remoting, etc...
You could expose a WCF service directly from your windows service. When you start up your windows service, in addition to spinning up any other background processes, you could create an instance of ServiceHost<T> for your service implementation. This would allow you to not only provide WCF access, but also avoid the extra instance of IIS like you requested, and provide TCP, Named Pipes, and WsHttp endpoints. This should give you some nice flexibility in the performance tuning arena, since it sounds like this service will be consumed internally on your network, rather than externally.
You could create a WCF service which will talk to your Windows service on the remote box. Host the WCF component in IIS (or however you'd like so that you can communicate with it) and then call the WCF component from your remote machine.