Hi, sorry to bump a thread from another forum but it's probably better off in here.

Does anyone have any insights into the core question that was being asked in this thread, particularly the need to site a .NET app across three servers containing:

1) ASPX 2) All components 3) Database

The 1/2 split was easy in DNA with ASP and DCOM but in .NET I cannot seem to find any configuration-level equivalent. Do I really need to go and re-architect the whole thing to disconnect layers with web services or remoting? Yikes.

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=754

Trust me, there is no scope for saying "you don't need to". This is the requirement from a highly security-aware customer.

Thanks in advance for any thoughts.

different machines mean remoting/webservices, there is nothing you can do about that. You could opt for COM+ but I dont think that's of any use here.

Though how would this be more secure? If I break into the asp.net app, I can reach the BL layer, so using separation is great on paper, but if the asp.net app can access the bl tier, a hacker inside that asp.net app can too.

The key thing for the security is that while the IIS server is public, there is a firewall between it and the application server where the app components are. This firewall can detect and stop malicious access. As only the application server will have the database connectivity, there is no way for the attacker, even with complete control of the IIS machine, to directly access the data source. If the data connection is just from the IIS server then potentially they can.

It's a real surprise that it is to easy to do machine separation in COM with DCOM just by configuring (no code changes) yet it doesn't seem possible with .NET.

With COM+ I'd have to actually code the .NET stuff differently right? I did the DCOM stuff for the COM components by putting them in a COM+ package and exporting it to the IIS machine as an application proxy but you can't seem to do that for assemblies.

rich wrote:

With COM+ I'd have to actually code the .NET stuff differently right? I did the DCOM stuff for the COM components by putting them in a COM+ package and exporting it to the IIS machine as an application proxy but you can't seem to do that for assemblies.

You can export client proxies from server applications that are built on top of managed code, but you really should have a good understanding of COM and Interop before attempting this at home otherwise your registry will get messy real fast.

rich wrote:

The key thing for the security is that while the IIS server is public, there is a firewall between it and the application server where the app components are. This firewall can detect and stop malicious access.

You think? read on.

As only the application server will have the database connectivity, there is no way for the attacker, even with complete control of the IIS machine, to directly access the data source. If the data connection is just from the IIS server then potentially they can.

True, if the BL server has DB access you made the attack surface somewhat smaller. With adapter you can perfectly establish this: the PL only uses the db generic project, the BL uses both projects.

However about your assumption that the firewall can stop an attacker: don't believe that. The reason for that is that the application on the webserver has code paths which lead to the deletion of data, modification of data through calling BL code, correct? So if an attacker starts such a codepath, or follows these codepaths, he can establish the same things. Perhaps not whiping out a complete database, but he can do a lot.

This is also the reason why for example stored procedures won't help you with security: if I can execute a delete procedure I can delete data. To prevent that you have to deny me access to the delete procedure, but if I can call a BL method which for example deletes a user, I still can delete that user by calling that method.

That's also the reason why the second security is breached by an attacker, a webserver should be completely repaved and every database indirectly reachable by the affected webserver should be restored from a save backup as well. You can't take any risks in this.

Not to scare you away, but I hope to be realistic in this. Mitigating factors are of course that your setup is a terrible situation for a hacker, he has to check a lot of code before he can even try to do something remotely useful. Mind you: most hackers break in and keep their mouth shut, and break in to get information, not to deface your website. So they'll likely download the code on the website and examine that throuroughly and will patch it with code to track things. That's also why for example using Win2k3 and IIS6 is preferred, and making it impossible for the user the website runs under to elevate privileges to a higher level (so no impersonation to a user which can do more) and thus even write the assemblies or code pages. This then makes it impossible for an attacker to patch the running assemblies.

It's a real surprise that it is to easy to do machine separation in COM with DCOM just by configuring (no code changes) yet it doesn't seem possible with .NET.

You mean with the proxys created by COM+? Yes that was a nice system.

Good points.

Some relevant MS info is here - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh13.asp

The diagram right at the top is exactly the scenario I am dealing with. Interesting document actually.

I have now managed to get the whole thing split into tiers using DCOM and after a lot of digging, remoting functionality which you can make happen just with config data. It seems quite cool. Basically I provide simple config data to the web app which tells it to call the objects remotely, giving it URLs for .rem/.soap files on the app server. On the app server side similar config files let me expose my classes (once they pass back serializable classes and inherit from MarshalByRefObject) so these web service calls get through and voila - it happily starts running all my business logic (and hence data access) from the app server. I've now been able to get rid of all connection strings etc from the web server which is what I needed.

Can't say I fully understand every detail yet and we have to see just how slow this might be but as long as the last few steps come off, this is worth big bucks and means we can support demands for a 3-tier architecture.