smithvoice.com
 Y'herd thisun? 

“! could either watch it happen, or be part of it.”
-Elon Musk



MONO/Ubuntu part 15 - Managing files and folders

TaggedASP.Net, MONO, Linux

God Forbid

So far all of our examples have shown a pages-only webapp, no mentions of javascript files, css or images. What all these external resources have in common is that they're typically going to be held in subfolders off of the root.

6 specs out of 10 you're already golden, just create the folders and reference their files in your pages. Any such resource will be remotely accessible by a direct call (and has to be or the page won't work). However, supporting pages is different from exposing all your privates to the public for a clickfest. We'll protect sub folders from automatic directory listing with a couple more lines added to the Virtual Hosts file.

Related to forbidding folder browsing is forbidding remote access to private files. It's not uncommon to have some quick server-cached lookup data that you want to hold as a file and let the .Net/Mono service work with but not expose to the whole world. The default behaviour for Apache is to give any user any file that they ask for but you can protect files based on any common or custom file extensions you need.

Lastly, there's a small loophole in the default installation script for MonoAutoApplication based servers that allows *.master and *.master.cs files to be remotely viewed as straight text. Kiddies would have to know the name of your master pages to get at them but it is still a hole and it needs to be plugged (mod_speling's "Multiple Choices" feature makes it possible to get even forbidden file names, so I hope you've decided not to use that module). The fix is a one-liner that will be easy after taking care of the above two issues.

Shall we play the game?

Deny browser listing

Back in session 7 we added the DirectoryIndex setting to our virtual hosts file so that domain-only requests to a site would be gracefully directed to a default "index" page. You'll remember that without this setting an open ended request would show a directory listing of the whole root folder.

That was nice & easy, but what happens when a user looks at your page source, finds a path to images or stylesheets or whatever and makes a request for that path? They get a directory list.

If you don't want your deeper site content viewed en masse you can tell Apache that it should not allow "indexing" and also make it clear to requestors that the folder is forbidden by sending them an official 403 response message.

For testing, add two new subfolders to your site, call them what you like, I'm using "images" and "subfolder"

sudo mkdir /home/kilgore/sites/asdf/images
sudo mkdir /home/kilgore/sites/asdf/subfolder

Put some unique files in these folders (not the same files in both so that when you get a listing you'll know which folder you're looking at). And to set the baseline call up each folder in a browser by an open ended path request to see the folder listing ("http://www.asdf.com/images" and "http://www.asdf.com/subfolder").

Now to thwart that. Open your site's virtual hosts file for editing:

sudo nano /etc/apache2/sites-available/asdf

And add this block inside the <VirtualHost> "xml":

<Directory /home/kilgore/sites/asdf/images>
Options -Indexes -MultiViews
</Directory>

This xml-ish element says that you have some special settings related to a directory, in this case the images directory. Note that we have to use the full unix file spec path to the specific directory, not a relative path from the web site root.

The next line is for setting the options for the specified directory. Each option here is being preceded by a dash character and it's important to remember that that dash is not just a dash, it's a "minus sign" or a negation used to swtich Off any options that are on by default (like indexing is). Conversely. options that are Off by default can be added to the list preceded by a plus sign ("+") to turn them On.

"-Indexes" switches off the directory lists feature. I added the "-MultiViews" because it is on by default and normally not a useful feature for Mono developers. MultiViews are Apache's way to serve up language specific pages. When and if that's needed, you'll probably prefer to do it with the .Net system so explicitly remove it from Apache to save a cycle or two.

-Indexes and -MultiViews are biggies but they're not even the tip of the iceberg, there are a LOT of other <Directory > and general settings that you can use to tune and tweak and shield your Apache sites. Look to the Apache documentation and look for a good book that makes things clear.

And hey, if you find such a book tell me, because I think that every one of them is just trying to out-confuse the last ;-)

 

 

The last line is a closer, ending the directory block. (Remember, these ini files are NOT XML, they can have some xml-ish stuff in them like that block closer but don't expect them to parse or to make any real xml-sense.)

Save the file and reload Apache. Then call up www.asdf.com/subfolder again to confirm that it still allows content lists, and then try calling up the www.asdf.com/images folder again to see that it does not. (you may have to clear your browser cache for a remote client to pick up the changed settings).

Now the user gets a clear message with an official 403, but an ugly Apache page. If that page isn't in line with your site style and you think it will make users doubt your professionalism then you can do a machine-wide change with the files in /usr/share/apache2/error OR do a site-specific error redirection as covered in session 8.

Here's a refreshser on redirection. Open your virtual host file and under the 404 error redirect, add a line for the ForbiddenResource 403 error to point to a special page that looks the way you want it to.

When you're happy with your forbidding, you may consider grouping 403's with 404's and sending the same page to users for both errors. To the user the bottom line is the same, they can't see what they specifically asked for, and making a big deal about something being "FORBIDDEN" is only asking a bored person who got the error accidentally to wonder what apples the tree has.

A lot of times you just want all subfolders turned off. Thanks to each Directory block defaulting to being a recursive setting, you can take care of all subfolders by specifying the website root as the directory for the block. Just alter the block to use the physical path to the site root, as in:

<Directory /home/kilgore/sites/asdf>
...

Forbid by file extension

By default if you have a file in your site folders and a user requests it by name, Apache will give it to them. So you may not want remote requestors to read your xml file "myprivatexml.xml" but they can IF they know the name (another great reason to make sure that you turn off mod_speling completely, its helpful 'did you mean this file?' feature make things too easy for bored pre-teens).

Depending on your needs, the fix is either all in Apache's virtual hosts files or there and a line or three in your ASP.Net web.config. First, the unmanaged way.

To protect that "myprivatexml.xml" file, add this block to your site's virtual hosts file:

<Files myprivatexml.xml>
order allow,deny
deny from all
</Files>

Save the nano and reload Apache. Try to get at that file and you'll see a 404.

What if you want to do the same but for all files of a type? Let's pretend that your company has uses the custom extention *.zyx for private data/ini files. You can protect them all at once by using a regex pattern:

<Files ~ "\.(zyx)$">
order allow,deny
deny from all
</Files>

Pretty neat. And the second one works down the subfolder chain too.

Here's a geekier way. What's cool about this is that it shows how to pass a file request off to Mono and with Mono you can generate a 403 (Forbidden) error instead of a 404 which can make finding request attempts easier when you're scanning custom .Net logs.

Open up the virtual hosts file again and remove the <Files... > blocks if you added them. Then copy this block in instead:

<Location />
AddHandler mono .zyx
</Location>

Unlike the Directory block, the Location block uses a relative path to the website. So the slash before the closing bracket in the first line means the root of the web site.

Save the file and restart/reload Apache. If you try to hit the file, it will load into the browser, but it is now Mono serving it to you, not Apache.

sudo nano the site's web.config and add an httpHandlers subnode to the configuration node. Within that node add a node that will invoke the .Net HttpForbiddenHandler if a file of that type is requested:

<configuration>
...
<httpHandlers>
<add verb="*" path ="*.zyx" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
...

Save the web.config and try calling up that *.zyx file again. This time the return is a 403 Forbidden which can stand out in your logs. (remember to add a managed customErrors redirect to your web.config for the 403 statuscode)

 

Close the *.master* loophole

This is a just a quickie. I noticed it when I was testing stuff out before writing this page up and didn't find it as an official bug in Mono.

Standard .Net file extensions like *.cs, *.config are protected by Mono just as they are protected by MS.Net. For MonoAutoApplication deployments, Mono does it with lines in the /etc/apache2/mods-available/mod_mono_auto.conf file. Problem is that the list doesn't include a line for ".master" so if someone happens to guess your master page name (you don't use the default from visual studio, right?) then they will see it all as text in their browser AND if they call up the matching code-behind *.master.cs file they'll actually see that too!

This isn't an optional thing, you really don't want to release with that hole open.

sudo nano the /etc/apache2/mods-available/mod_mono_auto.conf file and add a line to close that loophole. In the graphic below you see I did it just above the *.dll protection.


 Just one last biggie in this tute before we get a world-class database server up and running... logging Apache access and errors.


jump to:

  • 1: Why?
  • 2: Installation
  • 3: Update the OS with APT
  • 4: Remoting to the box with SSH
  • 5: NANO quickies for 95% of the jobs
  • 6: Firewalling Ubuntu 8.10 Server
  • 7: Installing Apache2 and MONO
  • 8: Test client host files
  • 9: Configure MONO on Apache2
  • 10: Apache default pages
  • 11: Handling Apache and Mono Errors
  • 12: Subdomains and Christian porn
  • 13: Virtual Host Tweak: unmanaged cAse sensitiviTy
  • 14: Managed cAse sensitiviTy
  • 15: Managing files and folders
  • 16: Logging Apache Accesses and Errors
  • 17: Ubuntu Task Managers
  • 18: Ubuntu Services and Service Managers
  • 19: Installing Oracle 10g XE Server
  • 20: Connecting Mono to Oracle


  • home     who is smith    contact smith     rss feed π
    Since 1997 a place for my stuff, and it if helps you too then all the better smithvoice.com