| 10:56 am on Aug 4, 2014 (gmt 0)|
FWIW (and not to confuse the directory delete issue), when I added the blank index files above the root?
It could not be done via FTP and was done through the HTTP CP.
| 3:46 pm on Aug 4, 2014 (gmt 0)|
Anything involving CP is host-specific. Mine, for example, rolls their own Control Panel. Business involving files outside your own userspace-- such as the /icons/ (if it existed) or /stats/ directories-- requires a support request. Different set of clickbuttons.
|The server directives are fixed by the shared-hosting provider; cannot be changed by a tenant site, and over-ride all attempts to alter the behaviour using local htaccess. |
Yes, that was my point. If it's your own server, all you have to do is glance at the config file to find any references to /icons/ so the question would never arise.
In the specific case of aliasing, the directive simply cannot be used in htaccess. No way, nohow.
:: further detour to MAMP config file ::
These are the listed Alias directives, in addition to favicon.ico and /icons/:
Alias /phpMyAdmin "/Applications/MAMP/bin/phpMyAdmin"
Alias /SQLiteManager "/Applications/MAMP/bin/SQLiteManager"
ScriptAlias /cgi-bin/ "/Applications/MAMP/cgi-bin/"
There's also an
but that's obviously installation-specific.
Heaven knows we all get plenty of requests for /phpMyAdmin/ ;) but it doesn't seem to exist on my server, because my IP-based lockouts work. I think there are designated servers for WP sites and I'm not on one.
| 12:00 am on Aug 6, 2014 (gmt 0)|
Since setting the hare a-running Bill's been quiet.
My host shrugs and can't see the reason for any fuss.
Most people on a shared server, who choose to 403 hackers/nasty bots discover that such blocked visitors may still access their site and get a 200 via urls such as;
My host concludes; giving such malicious visitors a 200, plus the server OS version, is perfectly safe, and a waste of their neurone power.
Is that naive, Bill?
| 12:11 am on Aug 6, 2014 (gmt 0)|
|My host concludes; giving such malicious visitors a 200, plus the server OS version, is perfectly safe, and a waste of their neurone power. |
Is that naive, Bill?
I'm not Bill ;)
It was my experience that the host was using those images to advertise their services on my dime.
Why would they object and bite the hand that feeds them?
| 2:23 am on Aug 6, 2014 (gmt 0)|
my host also responded to my inquiry, stating "This was a default set up by the installation of Apache. Really no harm in it that I know of." but the host also provided me with instructions for altering config file (similar to dstiles suggestion) via the host's provided control program. worked great- nasty bots now receiving 403.
once again, i want to say that i am so appreciative of all of you willing to share your expertise and experience. thank you very much.
| 11:47 am on Aug 6, 2014 (gmt 0)|
Don, you touch upon the ethics of a hosting service displaying images on a customer's domain url without the customer's consent, approval, or indeed, knowledge.
Surely, it is reasonable to give fee-paying clients a free opt-out option.
As Lucy mentioned, any reputable hosting service would readily fix this on request.
| 12:55 pm on Aug 6, 2014 (gmt 0)|
|Surely, it is reasonable to give fee-paying clients a free opt-out option. |
In my instance, it was possible to change the configuartion (Error Docs & Blank indexes), however the host never offered a solution and/or option. Rather, I just poked around ;)
| 1:44 pm on Aug 11, 2014 (gmt 0)|
Update: My host kindly changed the server config file to automatically remove the Alias /icons/ lines from the Apache httpd.conf file on the server for my domains.
So now all calls for /icons/ through my domain get either my custom 404 or custom 403 :)
Check what your shared server host does. Point them to this thread if they foot-drag.
| 3:16 pm on Aug 11, 2014 (gmt 0)|
Follow-up observation: With the proliferation of apple-touch-icons and whatnot, it's becoming more likely that a user might legitimately want to create a directory called /icons/. Even though you can't use Alias on shared hosting, you can easily rewrite, achieving the same result within your own space. And specialized directories reduce clutter for the site administrator. So a host does need to allow for the possibility.
| 3:27 pm on Aug 11, 2014 (gmt 0)|
He just got his host straightened-out and here you come filing an appeal :)
| 9:12 pm on Aug 11, 2014 (gmt 0)|
On the contrary, I'm filling him up with more arguments :) If you need to have your own personal /icons/ directory, then the config-level Alias has to be switched off.
| 11:16 pm on Aug 11, 2014 (gmt 0)|
|...Receiving a 200, plus the server OS version, is perfectly safe, and a waste of their neurone power. |
(As my host concludes.)
Or is that naive?
Your host is a lazy fool.
The same mentality that allows headers like "Powered by PHP" that hackkers scan to find sites to attack.
I don't have a clue why they're looking for this file, it could be as simple as someone building a map of domains running Apache vs Windows.
Could be completely benign but so are all things until they turn malignant.
Just because you're not vulnerable today doesn't mean they aren't cataloging in advance so they can infect as rapidly as possible before the patches are installed when the next big opening presents itself.
IMO no site should indicate what server, OS, software, or language they're using and do as much as they can to mask it all to avoid being on the next list of targets when the next vulnerability comes out.
However, with all that said, worrying about this file alone is really kind of silly because if there was any Apache vulnerability, I wouldn't even bother checking this file, I'd just attempt to infect the site because the bulk of the web is all Apache in the first place.
It's an interesting puzzle but not really worth all the effort to stop it unless your headers also don't day Apache, another clue.
Plus, if they know the default server IP they can probably get the default Apache page, or that icon, by totally bypassing your .htaccess file.
Therefore, unless you have a dedicated server this is all just a big exercise in futility as you'll be a target one way of the other. Mostly because none of the other sites on your server care about security so if you site protects itself the others on the shared server are still allowing all sorts of things that put the server at risk.
Unless the hosts make it a site-wide uniform security policy that cleans up all TELLS used by hackers, then its a waste of time.
There are more security conscious hosts that will be happy to take your money ;)
| 12:45 am on Aug 12, 2014 (gmt 0)|
|if they know the default server IP they can probably get ... that icon, by totally bypassing your .htaccess file. |
If the config file has the specified Alias directive, the request will never get near your htaccess file anyway. Unless, that is, your personal htaccess file is located in the /icons/ directory-- wherever it happens to be ;)
| 4:46 am on Aug 12, 2014 (gmt 0)|
"On the contrary, I'm filling him up with more arguments :) If you need to have your own personal /icons/ directory, then the config-level Alias has to be switched off."
Wouldn't dream of it Lucy, my custom Apple icons are all in my root directory and sub-domains.
"Unless the hosts make it a site-wide uniform security policy that cleans up all TELLS used by hackers, then its a waste of time.
There are more security conscious hosts that will be happy to take your money ;)"
Thanks Bill. Their server default does send the Apache header.
So your comments are filed, and my ears pricked up.
| This 44 message thread spans 2 pages: < < 44 ( 1  ) |