On 7 mai, 22:08, shimmyshack <matt.fa...@gmail.com> wrote:
> On May 7, 4:03 pm, geomet...@fastmail.fm wrote:
>

Thank you Shimmy. I commented your answer.

> > Hi,
>
> > I could configure Apache for testing my website offline, but is not
> > clear to me how to secure the folders before I connect the site to the
> > www.
>
> > In particular, I do not have the necessary knowledge to answer the
> > questions pasted below. (My Apache runs on Windows XP.)
>
> XP Home or PRO?

XP home for my offline tests. Should I absolutely consider XP Pro to
host the final site?
(I know that Unix-like OS would be better but decided to keep with
Windows for a while.)

>
> > It would also be very kind if some experienced Apache user could have
> > a look at the config file at the bottom of this post and points which
> > security lacks does he see.
>
> > Many thanks in advance.
>
> > -----------------------
>
> > 1) Do I have to secure the folders that are not public documents
> > using the operating system, giving them owner and password, or are
> > Apache directives sufficient?
>
> depends what you mean, I think the answer is no.
I also think so, but would rather be sure.

> however you should run apache as a service, and create a user for it.
> then you should set the user to only have access to the files it
> needs, php and apache and the doc root.
> If you have XP Pro you can do this easily

I did not installed Apache as a service as the installation program
proposed me to install the server for all computer users and I did not
want it. I just lauch it from the command line and with XP Home. Why
is this a problem?
>
>
> > 2) Can a hacker access the folders that are out of the main server
> > root (C:\Apache2)?
> > For instance, can he access a folder like "C:\thisIsNotPublic\" ?
>
> Not if the apache service has no access. However if you cannot secure
> apache in this way, then yes a hacker can potentially gain access if
> your code is bad, and leaves holes for him/her to do so.

I think my code well written (with many checks inside). My cgi-bin
folder has small compiled programs (.exe) that call a library. The
request on the library is different depending on the exe that calls
it. The library is out of the Apache root. I thought that if
unfortunately a hacker access the cgi-bin file and can get the
executables, he does not have the core of the program, that is the
dll. All runs fine on my PC. Is this good idea?

> > 3) Should I apply a 'Deny from all' to the logs folder?
>
> No it wont protect them. /logs is used by apache, and is outside the
> document root. The way a hacker would get to the logs folder would be
> through a hole in your script, if they already had the file system
> access then its game over no matter what apache thinks.
Good remark.
>
> > 4) Is there a risk that a user can write or delete files in the www
> > (i.e. htdocs), in the cgi-bin or the logs folder ?
> > If yes, how to prevent this to happen?
>
> yes, if your code is bad.
> patch apache/php to the latest version
> write good php code.
There is not any PHP on my whole site. I did not installed PHP, only
Apache.
I thought that the less components are to configure, the less the risk
of security holes is.

> dont allow user upload of files which can then be viewed through their
> browser.
You mean the files that are not in htdocs, I assume.
Compiling the HTML and JavaScripts could make harder to discover the
name of the called executables but will have no effect against a
motivated malevolent person. Is this however recommended to avoid
automatic calls of the executables?

> > 5) Should I put the cgi-bin folder totally out of the Apache root (C:
> > \Apache2\) and the same for the logs folder ?
>
> cgi-bin has to be in doc root or else cgis cannot be executed,

I hope you speak from the server root, not the root where documents
are!

> (a ScriptAlias is the same as having it in the doc root after all)
> logs folder is already outside htdocs.

Excepted that ScriptAlias avoid the user to see the name of the folder
where the executables are stored. I think that this kind of discretion
is not neglegible. Moreover a path like C:\Program Files\Apache2\cgi-
bin is a good choice for a hacker. A path like C:\randomstring1\cgi-
bin is less.

> > 6) Should I give the cgi-bin folder a sophisticated name so that one
> > cannot discover it easily ?
> > (I use the ScriptAlias directive.)
>
> no, it wont protect, as you NEED to be click on links to execute the
> cgi.

I meant for motivated hackers wanting to find where the cgi-bin folder
is.
The link shows only the ScriptAlias. But that's true that if a hacker
enters the system, he can read the httpd.conf file and see where are
the executables located.

> method="post" action="wibblestiltskin-crazy-name/script.cgi" is still
> a name which can be found and typed
> If you dont use CGI turn off ExecCGI for all directories and dont
> worry about it anymore!!
>
> > 7) The Apache docs security tips tell:
> > <<
> > # cd /; ln -s / public_html
> > Accessinghttp://localhost/~root/
> > This would allow clients to walk through the entire filesystem.
>
> > I testedhttp://localhost/~root/onmy PC but this did not let me
> > walk through the filesystem; a "document not found" error displayed.
>
> thats cos its not a windows XP vulneraility - there are many others.

Thanks for this info. One less think I have to worry about.

> Run mod security
What's this?

> and look at the cool rules project
What's this? I'll type in Google to see.

> if you are
> prepared to learn about possible threats and how to stop them at the
> door
>
> > Is it really necessary to add the following block as told in the
> > docs ?
> > <Directory />
> > Order Deny,Allow
> > Deny from all
> > </Directory>
>
> yes, it starts from the position of absolutely NO rights, standard
> practise in the *nix world, whereas Windows XP starts from the
> position of "Administrator" so its all downhill from there!!!

So, if I understand, a very good password is necessary for the
Administrator account on Windows XP.
>
>
> > 8) Currently, I want only MSIE 6 to be able to run the website and a
> > redirection for other browsers.
> > Is the BrowserMatch directive sufficiently reliable to test this?
> > I doubt.
>
> No, I can spoof the MSIE UserAgent with 2clicks in firefox, however it
> will stop non UA aware "users"
>
> > If yes, how to configure BrowserMatch? If no, how to test the
> > client broswer reliably?
>
> You cannot, you just cannot. Simple as that. Even if you match the
> MSIE string, then use javascript to feature detect for MSIE, you will
> still NOT prevent Firefox from coming along and viewing your website.
>
That's a problem. I made a sophisticated user-agent test from within
my library. But the problem is that most browsers do not understand
when I return them an error message telling that the program is not
available to them. So they block. Should I set a timeout in each link
calling a program and serversides exit the program as soon as an
incompatible browser is detected? I many times heard that JavaScript
detection is insufficient and serversides detection is really
recommended.
>
> > 9) Is there a way to limit the number of requests that come from a
> > IP address in a given amount of time?
> > (Avoiding automated password cracking, server overloading,
> > a.s.o.)
>
> yes, a decent firewall. Apache is not the place to be doing this,
> after all if apache can see the requests and connection attempts then
> it can see them, DOS will still occur. However there are modules which
> do this. mod_bw limited bandwidth, etc....
>
I'll see. Thank you for these infos.
>
> > 10) For secured folders, should I set 'AllowOverride none' to avoid
> > that an allowed user adds his own .htfiles
> > in subfolders in an attempt get additional rights ?
>
> yes, if you have httpd.conf access use it. do not use .htaccess files,
> they slow down the server slightly, they could reveal info if
> downloaded by accident after a server misconfiguration.

I plan few users at the beginning and not huge number in the future.
I'll start with .htaccess files. If I understood how Apache works, it
only checks the access files for the branch of the tree it want to
access. So, if the branch is not too long and with only a .htaccess
file at its bottom it should not slow down too much the server.

> > 11) Is there a way to make that the cgi-bin applications (which
> > are .exe in my case)
> > can be called from forms in the public documents but not another
> > way?
> > (I don't think so, but wonder however.)
>
> If your cgi scripts can be called in a browser they can be set off
> from anywhere, using the referer is not valid as browsers dont have to
> send them, and some privacy applications remove them.
>
> Done forget to remove the /manual as recommended in the apache docs.
Yes.
> My advice is that if you are concerned about security, don't be so
> quick to run exe's, until you have looked into their weaknesses. And
> in particular you say your server is to test "offline" but you appear
> to be letting the public see things.

I tested my program and the extensively offline. I consider it ready,
appart the Apache configuration that I am doing these days. One day,
it becomes necessary to stop home tests and to enter the dangerous
real world...

My advice, limit by IP who can
> see your server.

I wanted too. A friend that is much capable in computer science will
me to test the security. I just want to make him the task
hard :-)
I alwo won't advertise for the site.

But I see a problem : most people have dynamically attributed IP
addresses...
So, how to do?

A good think to reduce the risk could be to restrict the geographical
area of possible users.
I assume the IP numbers tell something about this, no?

IE. only you at work, and while youre on yuor loacl
> network. Until you have fully appreciated the risks you are exposed
> to.
This is why I'm asking so many questions...

> Also turn off all unneeded services on your computer, from UPnP, SNMP,
> netbios, etc.. etc.. or else your machine might be broadcasting info
> to the machines that come visiting.

This is much interesting. I disabled most services some days ago, but
will check to disable the ones you tell about.

> Ensure you are running a decent hardware firewall between the server
> and internet, and then grab yourself a few scanner and have fun
> testing your server like it will be probed by others.
>
> If you write any php, make sure you know what you are doing. This is
> the easiest way to open up your machine to attack.

I renounced to PHP. I'm really not an expert in security but heard
that it is a common way for intrusions.

If you have XP
> Home, then make sure you take regular backups onto a new disk, because
> you cant lock your machine down.
>
>
>
> > --------------------------------------
> > ServerRoot "C:/Apache2"
>
> > Listen 80
>
> > ### Loading modules ###
> > # (...)
>
> > #ServerAdmin srvAd...@mywebsite.com
>
> > #ErrorLog logs/error.log
>
> > #LogLevel warn
>
> > # The following line telling about the main server is necessary, but I
> > ignore why.
> > ServerName localhost
> > DocumentRoot "C:/Apache2"
>
> > <Directory "C:/Apache2/manual">
> > #Options MultiViews
> > </Directory>
>
> > # With *, it will work also if IP address is given dynamically.
> > NameVirtualHost *:80
>
> > # This virtual site has the Apache docs. It will be removed from the
> > conf file.
> > <VirtualHost *:80>
> > ServerName apachedoc
> > DocumentRoot "C:/Apache2/manual"
> > AddLanguage en .en
> > AddLanguage fr .fr
> > AddLanguage de .de
> > LanguagePriority fr en de
> > Options +MultiViews
> > </VirtualHost>
>
> > # This virtual site is my website.
> > <VirtualHost *:80>
> > ServerNamewww.mywebsite.com
> > DocumentRoot "C:/Apache2/mywebsite/www"
> > ErrorLog "mywebsite/logs/log.txt"
> > AddLanguage en .en
> > AddLanguage fr .fr
> > AddLanguage de .de
> > LanguagePriority en fr de
> > DirectoryIndex index
> > Options +MultiViews
> > IndexIgnore *
> > Alias /archive C:/Apache2/mywebsite/archive
> > ScriptAlias /cgi-bin C:/Apache2/mywebsite/cgi-bin
>
> > <Directory C:/Apache2/mywebsite/cgi-bin>
> > allow from all
> > Options +ExecCGI
> > </Directory>
>
> > <Directory C:/Apache2/mywebsite/www>
> > allow from all
> > </Directory>
>
> > </VirtualHost>
>
> > # Another web site
> > <VirtualHost *:80>
> > ServerNamewww.anothersite.net
> > (...)
> > </VirtualHost>- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -