An automated security scan was performed on my WSS 3.0 site and it came up with some warnings based on the apparent presence of FrontPage Extensions. Namely it found files like /_vti_pvt/service.cnf, /_vti_pvt/services.cnf, and /_vti_bin/_vti_aut/author.dll by appending those locations to the site's main URL over the web. These are apparently related to FrontPage Extensions. I have confirmed that the files exist and can be accessed over the web.
What exactly are these files for? Are they, indeed, related to FrontPage Extensions (which apparently has suffered from many security shortcomings in the past)? Can they be removed or disabled somehow?
Update:
I have removed read permissions to those directories under my SharePoint web site in IIS. They no longer serve over the web, but the site seems to function normally. So if anyone has an apparent security vulnerability from these files, a possible option is to remove the read permissions.
I have not tried to connect with SharePoint designer.
I think what you're seeing are the files that support SharePoint designer, which essentially evolved out of Frontpage.
Yes, it does. See this:
http://www.sharepoint2007security.com/guidance/firewall_rules
The WSS SDK describes the RPC extensions available in WSSv3. For more information see the WSS SDK FrontPage Server Extensions RPC # http://msdn.microsoft.com/en-us/library/ms443099.aspx
Related
I am new to SharePoint, I am using SP 2010. I am asp.net developer but I don't understand if I have web.config under 80, so what are those web.config files under 14 folder, can you briefly discuss it?
I found two so far, There is one under 14\Templates\Layouts and under 14\CONFIG
Thanks
SharePoint development is similar to ASP.NET development but there are some major differences you need to be aware of. One is the use of Web.config to store application settings.
I wrote a blog post with links to several resources to help new SharePoint developers get started: Getting Started with SharePoint 2010 Development–Links and Resources
I suggest you start by watching the SharePoint for ASP.NET Developers talk to get an idea of the SharePoint architecture and development/deployment model.
You will find a lot more in 14 hive :) They are there because they are web.config files for different parts of the entire sharepoint application pages. For example the one in "14\layouts\" is for general application pages, site settings, regional settings, ... for instance. the one in the 14\layouts\admin is for centeral administration pages.
I'm not sure if this should be posted here or over superuser, but how does one go about mirroring a Sharepoint 2007 site? I have admin access, and the mirror doesn't need to be nice and pretty; it just needs to be presentable and readable. Also, I need all the shared docs to be copied as well.
We use to have WinHTTrack to mirror the Sharepoint, but that broke a few months ago due to some of our recent security changes. I tried the username#password:domain method but that resulted no luck.
It depends a little bit on how and where you want to mirror it.
If you have a separate SharePoint farm (even a single server - one tier - farm), you can rely on backup / restore, export / import or content deployment to have another copy up and running that will be a mirror of the existing one.
If you want an offline version, depends on what kind of content you need (collaboration stuff ?) you can use Microsoft Groove 2007 that offers an offline mode for some of the targeted data.
I've found this great tool that can mirror the SP site for cheap: http://www.metaproducts.com/OEPR.html
If WinHTTrack did satisfy you, why not just fix it?
There are solutions around the web to have WinHTTrack work with NTLM authentication: http://forum.httrack.com/readmsg/7513/index.html
However the download link seems to be broken (geocities..), but you could try to search for NTML proxy solutions and try to setup your own.
I have configured by using this link.
However the URL is changing as http://server/EN/Pages/default.aspx for the default page.
I want the URL not to change, still I need to have my site displayed for multiple languages.
Any Suggestions?
The solution for Multiple languages in the current version of SharePoint (WSS3/MOSS2007) is to use variations as you've already configured. But this works by having seperate Site hierarchies which require diffenrent URLs
From the SDK documentation for the next version (WSS4/SP2010) it seems as if SharePoint will support different languages for the same Site
Not possible, variations in SharePoint are basically copies of each other under a different path.
I am using WSS 3.0 in a hosted/shared (read: can make no server-side changes) environment. Unfortunately, between SP and IIS, almost nothing is getting cached, so page loads can be terribly slow.
We have a bunch of custom image, JS, CSS, etc files that are currently just in a /img, /js, and /css directories, all of which are grabbed each and every time the page loads (server is returning "Cache-Control private,max-age=0").
Since I can't do anything with IIS, and can't enable any caching server-side on SP, do I have any other options? I've read in a few places that if your files are located in the layouts directory that they will be cached, but using SP Designer I don't seem to have access to the /___layouts directory, unless I'm missing something....
Thoughts?? Thank you!
Since you are running in a hosted/shared environment I would work directly with the ISP on this one. There are many ways to cache things and the ISP could very well prevent you from doing most of them.
Ask them the following questions...
Have you set output caching on the Page Layouts directory for anon and or authenticated profiles, or at the Site level or at the Site Collection level (overview on how to here)? If not, can you?
Do you have IIS set to compress static files (its not caching, but, will help)?
How much RAM is available to me in this shared environment?
If you have enough RAM, look into caching your custom web parts.
You could also host your custom images, css, javascript etc on a 3rd party CDN (Akami, Amazon Web Services), that doesn't help with your theme and core js/css files.
_layouts is the "repository" for application pages, i.e. pages deployed by sharepoint for performing maintenance etc. through the web UI. It is very well possilbe you don't have access to that folder, it will also not show up in SharePoint designer. You have a couple of options:
If you have a Publishing site, you can enable caching through the site settings.
What you could also do is add the #OutputCache directive to a page you create through SharePoint Designer (Outputcache on MSDN
deploy your site through a solution, which does allow deploying in the _layouts folder
Is it best practice to not use C:\Inetpub\wwwroot\wss\ for SharePoint? My concern is that the configuration wizard seems to look for this C: path and it may be too complicated to not use the default path(s),
What would be the reason for using an alternate location?
You should not be changing anything in the sharepoint IIS sites through IIS Manager, except through the sharepoint Central Admin site. There are dependencies in the sharepoint configuration that are not just stored in IIS, especially around the users that are applied for app pools etc. This website does most of the things you need to do (i.e. host headers etc)
So best practice is to create a folder in the C:\Inetpub\wwwroot\wss\ that is easy to map to the web application and then leave the folder as is.
Although it is hard to find stuff in the Central Admin site, the Infrastructure Update for SharePoint helps.
Having failed miserably in the past merely trying to change machine names on a VM after Sharepoint was installed, it is hard to imagine a goal more likely to frustrate than this idea!
The only arguments I've heard for not running IIS websites out of the Inetpub directory is that it's a commonly known location for evildoers to look at when attacking a system, but if security is your concern you're far past screwing the pooch if an attacker has file system access.
We've always let the configuration wizard pick that location for us. There's a lot of aspects of the underlying configuration that rely on that location and it's never seemed worthwhile to explore changing the home directory.