I would like to know what kind of things in IIS are really important to you on a day to day basis? And what should I look into initially to get started? Any articles/books/tutorials are welcome.
Have you thought about getting into some Virtual Lab, such as:
http://virtuallabs.iis.net/
This link is full of resources also: http://learn.iis.net/
The labs are a good place to start. Philosophically, the biggest thing to remember about IIS is it really is just a "phone switch" of sorts--it patches requests through to the appropriate handlers.
The other big thing to understand, IMHO, is the underlying windows security model. IIS rides on it and most folks who get into trouble are actually having trouble with windows security, not IIS. But the problems manifest themselves through IIS which can lead to some confusion.
Related
I am learning SharePoint and the different kind of solutions you can deploy. From the training I am watching it seems like you should try your best to use a Sandbox Solution when ever possible. This is because Farm Solutions can mess things up too much.
However, two of the main things I would do with WebParts are not supported in Sandbox Solutions. Those are Visual WebParts and WebPart communication. (The first is not allowed because it needs to hit the file system and the second is disallowed because it uses reflection).
It seems to me that my WebParts will always want to do at least one of those things. (WebParts that don't communicate are not really that modular are they?)
Am I missing the point or are Sandbox Solutions a "nice idea" that are not really used in actual code?
Yes, I agree with you that Sandbox solutions are very restrictive.
But, it is that restriction that gives them their value. Due to the restrictions a Sandboxed solution cannot bring down a farm (atleast that is the theory, someone may find a way to do it).
This means that you can open up to many more users to deploy things on the farm. It is also a requirement to deploy things to SharePoint Online.
That Sandbox solutions are more restrictive, means that development is more cumbersome, you have to program your way around the restrictions. This makes solutions more expensive. Therefore, the default should be farm unless you have a good reason not to use it.
I think some of the comments here are missing the entire point of a Sandbox solution, they have been deliberately given a reduced set of privileges for many reasons:
a) A site collection administrator can add a SB solution hence they need not be farm admins therefore better security of the farm.
b) You can trust that an SB will NOT bring down the farm, they don't even run under the normal SharePoint worker process, instead they are hosted under their own process that acts as a host to check to see if the resources accessed are allowed for an SB solution.
c) The cloud is coming, there’s no getting away from that fact, when somebody else is hosting your SharePoint solution do you really think you'll get access to the farm?
I think understanding the impact of running as a Sandbox Solution from a non-developer perspective is important, after all you wouldn't create a custom solution of any kind and expect the customer to grant you domain level accounts to run it, therefore when creating SharePoint solutions, think running your solution with the minimal amount of permissions by default, if there is really no other way then explore farm solutions.
Here's a useful guide from MS:
http://msdn.microsoft.com/en-us/library/ff798382.aspx
If your environment allows you to install farm solutions, then yes, sandboxed solutions are restrictive and stop you doing what you want.
However, if your environment does not allow regular solution deployment, as is the case with shared hosting and some large corporates then they are not restrictive because without them you wouldn't be able to use custom code at all.
Sandbox is horrible, i totally disagree with the statement "it is that restriction that gives them their value". you cannot do a many thing in sandbox.
1. no session
2. no web-part communication
3. no file upload controls
4. no redirect...
and it just makes things painful as hell. we are in the midst of developing an enterprise application facing outside users, my advice, if you considering Sandbox for these purposes, i would say add 150% more time for your project just to deal with sandbox issues.
most people talk about benefits, but all the benefits are not really benefits.. for example, if even a single sandbox application code raises exception which is unhandled... good luck, it will crash the entire farm, and tracking the issue is real nightmare.
if you can stay out of sandbox
What is the limit of IIS 6.0? like for example if i need to host 100,000 or 200,000 websites on IIS 6.0, how many machines would i need? or is IIS7 would be a better choice in this case for some reason?
As mentioned in the comments above the scale isn't so much the number of websites you create in IIS, but how complex and how busy those sites are.
In IIS6 one website does not necessarily equate to one executing process on the server. Application pools can group multiple websites into a single executing process to group and/or isolate applications. Alternately a single app pool can spawn multiple executing processes to make better use of server hardware.
It might help if you were to provide more detail in your question about what exactly you're trying to accomplish. If you're going to be serving hundreds of thousands of sites it would probably be a good idea to partner with a hosting company, or get some assistance from someone who knows the ins and outs of IIS, or another platform in detail and has operational experience with working through large-scale hosting scenarios.
IIS7 is not radically different from IIS6 in any performance-related way; with one exception: you can run ASP.NET in a "native" pipeline mode that bypasses some processing steps. I prefer IIS7 (if I can choose) because of its manageability advantages. But like everyone else said here: the question is impossible to answer without more information.
Hosting that many websites with IIS will be cost-prohibitive in licensing fees. Most large scale web hosting is done on Linux using Apache.
Are there any tools that go beyond requiring deep and intimate knowledge of every configuration option and nuance and will just setup an application with a minimum of inputs. Something like a wizard that produces the XML configuration based on those simple inputs. I don't care about security I just need the service to work. Ideally the tool would be able to setup IIS6 as well or at least with a given set of options it would produce a list of steps I needed to complete in IIS.
The Microsoft Service Configuration Editor is no better than direct editing of the XMl. I did find a web site that has the right idea but it wasn't able to solve my simple installation. (http://www.noemax.com/support/wcf_binding_configuration_wizard.html).
Is there anything out there that puts some convention into play over this mountain of configuration?
WCF configuration can look very daunting at first, indeed! I like that configuration wizard you linked to - why wasn't it good enough for you?
I don't know of any tool right now, that would solve your problem and help you figure out the proper configuration - it really boils down to learning the ropes and getting to know the ins and outs of it, I'm afraid.
Basically, what I've learned is : don't even start to imagine all the things you could do - try to focus on what you should do (and what you need).
Really, it boils down to about five scenarios as outlined in the excellent book "Programming WCF" by Juval Lowy:
intranet apps (use the NetTcp binding, Windows security)
internet apps (use the wsHttp binding if ever possible, username/pwd or certificates for security)
business-to-business apps (use whatever binding makes sense, secure by certificates)
queue message delivery (MSMQ)
no-security apps (legacy ASMX support, interop with "dumb" webservice clients)
Basically, pick the one you need, and from there, you're pretty much set as to what to do and how to do it. I would definitely recommend checking out Juval's book - excellent excellent resource!
So the question is: which category does your app fit in? Based on that, you can pretty much determine all that's needed from there.
Also, I watched two screencasts that really helped me get over the heaps of configuration options in WCF, and focus on what's really important:
Extreme WCF with Miguel Castro
Demystifying WCF with Keith Elder
Both gave me a good feel for what configuration is really needed - and what is just fluff.
Hope that helps some!
Marc
as can be seen from two other question I had I am looking for a secure webserver as there where discussion at work how safe tomcat really is.
But basically what I found on the net regarding how safe it is is greek to me. So I was hoping, someone could explain to me how safe tomcat really is? Like, is it possible to mess with java-code on the server or something like this?
I know this is probabaly a dumb question, but I really can't seem to find an answer that helps me to argument that writing an own server is not more safe than using tomcat or how it might be better to use tomcat.
Maybe someone knows a good way to secure tomcat and to minimize certain functions of tomcat? (I really dunno how to else explain it ...)
I hope you can help me.
Thnx in advance!
... dg
Writing your own server? As opposed to using Tomcat? That is a classic case of reinventing the wheel and (unless you are the NSA) likely to result in a less secure server. Rhetorical question: Why not write your own OS to go with it!
Tomcat 6 is a very mature, stable, current, well understood code base that has had zillions of very, very smart people reviewing, testing it, and operating it in production for years and years.
Tomcat is very secure.
maybe before, Tomcat was pretty unsecure, but nowadays... just anything having Apache under its name is enough for me to trust it. Anyway, security was ALWAYS imagination, there is not such thing existing in real life, so there would always be factor of (in)security.
Problem with Tomcat is like problem with Windows, no matter how 'secure' they built it, if there are millions of people out using it, hackers will have interest to invest their energy (and eventually, they will success) in finding way to break into it. So maybe to feel more secure, you can consider using something not wide used, but this will not help if hacker is intentionally hacking your site for some special reason, he will find out technology you are using and in this moment - it would be better it was Tomcat..
That is why is very important to 'get married' with open-source technologies like tomcat, since there is not big chance for a hole in system to live long, people have chance to fix things, you can always do the job yourself, do not have to wait for a new version etc.
Look at the changelog and count the security issues fixed;
Look at the CVE entries for Tomcat and see how the seem to you.
But all in all, it's a really bad idea to write your own Servlet Container, especially if the Tomcat security arguments are not clear to you.
If you need boss-convincing arguments, show him the serlvet spec you need to implement, and estimate time in the order of man-years ( not kidding! ), contrasting this with the 'download,unzip,start' option of using Tomcat.
I know this is probabaly a dumb
question, but I really can't seem to
find an answer that helps me to
argument that writing an own server is
not more safe than using tomcat or how
it might be better to use tomcat.
What you have to remember is that Tomcat has 1000s of hours of people looking at code and fixing bugs and holes. Thinking about writing secure code is easy. Doing it is extremely hard. There are lots of little things that can be overlooked which can contribute to a massive hole.
Tomcat is a secure server. However, it is even more secure to use Apache Web Server to proxy it. You can use mod_proxy to connect Apache with Tomcat using AJP or HTTP protocol. This is the safest configuration and you can leverage the many plug-in modules available for Apache Http Server.
Some tips for a secure installation:
Create a user to run Tomcat. Do not use the root user.
Uninstall the example applications.
Uninstall the manager application. If you use Apache to proxy Tomcat, you can safely keep the manager and make it available only through your local network.
While I'm no hacker, I'd find it hard to imagine how Tomcat would be your first port of call if you were trying to attack a system - after all it's running your code and is presumably behind a firewall and fronting servers. If this isn't that case, then it should be!
Once the network is as secure as possible remember Tomcat is just a Servlet engine - you're gonna have trouble exploiting with http requests. I'd focus on your application code, things like user authentication and avoiding the various injection attacks - this in my mind is the highest risk to your system and will exist whatever server you're running on.
As others have already mentioned, Tomcat is ready for production use and security of Tomcat itself is certainly better than what any small team could achieve while writing their own servlet server.
That said, the probably weakest point in a Tomcat setup is commonly the setup of the underlying OS.
I'm setting up an Internet-facing ASP.NET MVC application, on Windows 2008. It uses SQL Server 2008 for its database. I'm looking for best-practices for securing it.
I found this article, but it's a bit dated now. How much of that advice is still valuable?
Some background -- it's a personal site, behind my home NAT/firewall box; and I'll only forward ports 80 and 443 to it. The IIS server itself is a Windows 2008 host running on HyperV (I only have one physical box to spare).
One useful thing that's mentioned in that article (which had occurred to me already) is that the IIS box shouldn't be a member of the domain, so that an intruder can't easily get off the box. I'll be removing it from the domain in a moment :)
What other tips should I (and anyone deploying to a bigger environment) bear in mind?
I know that this isn't strictly a programming-related question (there's no source code in it!), but I guess that most programmers have to dabble in operations stuff when it comes to deployment recommendations.
You might take a look at these two tools:
Best Practices Analyzer for ASP.NET
SQL Server 2005 Best Practices Analyzer (even though you are using 2008, still might be of help)
I don't know about removing it from the domain, but I'd certainly disable LanMan hashes, keep the system fully patched, and use good password security. Make sure that any processes running in IIS run from least privileged accounts, i.e., don't run the worker processes under IDs that are in Local Administrators.
This will be of great help, certainly:
Microsoft Web Application Configuration Analyzer v2.0