Re: Host Company web on SBS 2003
- From: "Andy" <andyj@xxxxxxxxxxxxxxxxxx>
- Date: 30 Mar 2007 10:14:13 -0700
Sorry for the late reply.
On Mar 5, 6:12 pm, "SuperGumby [SBS MVP]" <n...@xxxxxxxxxxx> wrote:
no. Attempting to twist logic to suit your argument is stupid. Your
statement is similar to 'You don't like bananas, therefore you don't like
oranges'.
No, I'm not twisting your logic at all. I'm trying to get at whether
you believe 1) IIS is insecure or 2) custom applications on IIS may be
insecure.
I trust hosting OWA and RWW because they are developed by a team with a
formal development process. The process includes security checks. _Most_ web
development is not.
That's not the advice you're giving with blank statements such as
"never run a public website on SBS." I asked if you trusted
static .htm pages to be served to the public over IIS, and still your
response was no. That leads me to believe you think IIS is just
insecure (which has nothing to do with how well OWA or RWW was
coded). If you believe you can't even host static web pages on SBS,
then you should also believe that you shouldn't host OWA or RWW. The
reason is simple; if you don't trust IIS to simply read a file and
send it over the network via HTTP (or HTTPS), you shouldn't trust it
to read a file, hand that file to an external process and EXECUTE it
then send the results over the network. .htm files aren't executed,
and hosting a static site is certainly more secure, because serving a
static file doesn't cause any non-IIS code to execute.
The security principle that one should use a dedicated server for any public
facing service, an accepted industry standard, is only one of the reasons
for not hosting on SBS.
The point of SBS though is that the same companies that cannot afford
multiple servers to control their internal network. It stands to
reason they can't afford decidated servers for public facing services
as well.
The fact that SBS breaks this rule in order to allow
OWA/RWW + SMTP, hosted on your DC, which is also your fileserver is, for
most SBS organisations, a compromise between necessity/desirability and
security. We do it this way because we do not have the resources to
implement a more acceptable solution.
Fair enough. But the blanket statement of 'do not host a public site
on SBS' isn't valid anymore. Hosting OWA or RWW is already more risky
than hosting a static site (plain old .htm file). Its really the
blanket statement that I'm having issue with.
Also, the cost of increasing speed of connection to be able to give WWW
viewers a comparable experience to that of a hosted service normally exceeds
hosting costs.
Also fair enough, but the blanket statement that many here 'do not
host public websites' isn't as helpful. If the speed of the website
isn't as important to the company, then some hosting on SBS may be
acceptable, especially for a small company that doesn't have the
traffic expectations of larger companies.
'The webserver needs a patch, everyone please shut down', has a cost. An
organisation using SBS to host their public web must be more vigilant in the
patching process. If not doing this you may look at a patch and say 'HTTP,
OK, we need it but it's not 'do it now', we can wait for our next scheduled
period.'.
I'd argue you're more likely to need to patch because of Exchange,
Sharepoint, Sql Server, ISA server or any of the other products
bundled with SBS than IIS, not to mention Windows 2003 itself. Its
likely that any patch on the system would have a cost and have to be
done on off hours. If you can show me that there are many times more
patches specifically for IIS than any of the other bundled
technologies on SBS, I'll concede your point... but I have a feeling
that the other bundled products have patches and service packs more
frequently.
I supported SBS when the 'badpage' (having a hard time remembering the full
name, someone (from China?) didn't like FBI/CIA) IIS exploit defaced
hundreds of thousands of NT systems, but only those with HTTP open, it did
not affect HTTPS only sites. As well as the IIS default page replacement any
system affected was considered 'owned', the payload could have taken
complete control of the system. Want to throw the baby away with the
bathwater?
Are you talking about the 'hacked by Chinese' exploit? That required
that Indexing service also be running, and that it was tied to IIS be
default. Neither of those are true of any of the server 2003 products
(and I imagine that will remain the case moving forward). It didn't
affect Https sites because the author of the virus only tried port 80,
but if he tried both port 80 and 443, it would have been just as
successful there as well, because the flaw was with Indexing service
and its interaction with IIS, not with the SSL protocol. Implementing
an SSL client (and server module, actually) is very easy. SSL just
encrypts normally plain-text http, it doesn't provide anything else,
especially not client authentication.
The nature of 'blackhat' activity is that an exploit will be found and there
will be a delay between discovery and cure. In today's permanenty connected
high bandwidth world the exponential rate of infection will ensure that a
large percentage of systems vulnerable to such an attack will be infected
and probably before the exploit is known publicly. If it wasn't for a
tendency for some blackhats to have started 'marking their territory' by
public advice of exploits incidents would be more common.
Not necessarly. Actually many exploits have known fixes available.
That was the case with the Code red worm; the patch was available
months before the virus was released. The problem was that people
didn't apply the patch.
And the same problem exists for any of the services; Exchange server
may have a vulnerability, but no one here says don't use exchange to
host your company mail server.
I'm all for reducing risks... but at the same time those with SBS need
to evaluate what the risks are and make their own choice. Blanket
statements such as 'never host a public website' aren't helpful to
those seeking advice. Instead, we should be explaining what the
risks and costs (such as bandwidth) are of their different options.
If you're already running Exchange, you have a public facing server.
If you're hosting OWA or RWW, you're not going to incur any additional
risk by hosting static pages for a public website. You'll use more
bandwidth, but again, those implementing SBS need to understand how
busy the site will be when making the choice to host or use a hosting
company. If they choose to run a public web application, they'll need
to understand the security risks there as well.
Sorry for the late response.
Andy
.
- References:
- Re: Host Company web on SBS 2003
- From: Andy
- Re: Host Company web on SBS 2003
- From: SuperGumby [SBS MVP]
- Re: Host Company web on SBS 2003
- Prev by Date: Re: Error encountered when running install of R2 Technology (CD #8)
- Next by Date: Re: Import Contacts into Sharepoint Does Work
- Previous by thread: Re: Host Company web on SBS 2003
- Next by thread: Re: Outlook Synchronization
- Index(es):
Relevant Pages
|
Loading
