Since I have not found any specifics about this I wanted to ask about/compile a short list of things to-do or not..
Firstly in this message it would be good to clarify if setup.php, upgrade.php, etc. can go or should be left were they are. When I read "No, do go ahead and forget." in the context it sounds almost as if the setup.php should NOT be removed..
Many script authors apparently don't protect existing installations from being wiped when such installation files are re-run, and thusly reccomend removing such installation related files. So, like many I presume, I have been either deleting, renaming or setting their permissions to 000.
I never considered, until now, that maybe I have created a problem in the process.
Secondly, as mentioned in the referenced thread, there is some security by obscurity -- un-branding and so forth. Given that robots have a knack of digging up all sorts of things normal browsers are unlikely to find, I typically remove text files and informational html pages that are for the customer only.
The ramifications seem to be quite simple and obvious for the most part with the 'text' stuff. So I just replace the readme.txt with my own notes to keep the main CP page links alive.
Other tell-tale signs like "WSN Codes" references among the pages are a little more involved perhaps and I've not bothered with them so far.
The reason there are no instructions about it is there are no things that should be done. Do not think about it, you're just wasting time.
Many script authors apparently don't protect existing installations from being wiped when such installation files are re-run, and thusly reccomend removing such installation related files.
I know multi-step installs are easier that way. Notice that WSN is a single-step install, after typing the info the only page is the one result page.
I never considered, until now, that maybe I have created a problem in the process.
I don't see any possible problem, other than that you're wasting your time, which is your own affair.
Given that robots have a knack of digging up all sorts of things normal browsers are unlikely to find
If a spider is written which is smart enough to determine that a site is using WSN based on setup.php, it can also be written to simply test for the names of all the php files and match the pattern to tell that it's WSN. (As long as we're being paranoid.)
If a spider is written which is smart enough to determine that a site is using WSN based on setup.php, it can also be written to simply test for the names of all the php files and match the pattern to tell that it's WSN. (As long as we're being paranoid.)
Mainly I was thinking of the amount of odd stuff that I've had turn up in search engine / archive results from time to time. Things that the site owner I'd guess doesn't know or didn't intend to be served up.
Fair enough though. I'll consider it both okay to, and moot to bother with post installation worries. Mostly I just didn't want to break something by removing setup or upgrade.
Top right hand corner - has a link for free subsriptions to the magazine .. I have been on their initial mailing list for the first two issues - It is a good read.
I use a static robots.txt at some sites but resort to other techniques to keep most of them off my sites. There are way too many robots that don't obey robots.txt so I find the file only useful for the handful of search engines I allow to crawl my sites.
It's a loosing battle to try and keep all but x,y,z robots off sites with a static robots.txt file. However, I've been working with some techniques to deliver a dynamic robots.txt in conjuction with some shell scripting, apache and my firewall which I hope will allow me to forget about, for a while anyhow, the useless (to me) robots, bad robots that don't honor robots.txt and other bandwidth stealing trash bots that scours the internet.
0/5
1
2
3
4
5
This thread is closed, so you cannot post a reply.
Comments on Post Install check-list - Security
Forum Regular
Usergroup: Customer
Joined: Jan 11, 2006
Total Topics: 48
Total Comments: 166
Since I have not found any specifics about this I wanted to ask about/compile a short list of things to-do or not..
Firstly in this message it would be good to clarify if setup.php, upgrade.php, etc. can go or should be left were they are. When I read "No, do go ahead and forget." in the context it sounds almost as if the setup.php should NOT be removed..
Many script authors apparently don't protect existing installations from being wiped when such installation files are re-run, and thusly reccomend removing such installation related files. So, like many I presume, I have been either deleting, renaming or setting their permissions to 000.
I never considered, until now, that maybe I have created a problem in the process.
Secondly, as mentioned in the referenced thread, there is some security by obscurity -- un-branding and so forth. Given that robots have a knack of digging up all sorts of things normal browsers are unlikely to find, I typically remove text files and informational html pages that are for the customer only.
The ramifications seem to be quite simple and obvious for the most part with the 'text' stuff. So I just replace the readme.txt with my own notes to keep the main CP page links alive.
Other tell-tale signs like "WSN Codes" references among the pages are a little more involved perhaps and I've not bothered with them so far.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7868
The reason there are no instructions about it is there are no things that should be done. Do not think about it, you're just wasting time.
Many script authors apparently don't protect existing installations from being wiped when such installation files are re-run, and thusly reccomend removing such installation related files.
I know multi-step installs are easier that way. Notice that WSN is a single-step install, after typing the info the only page is the one result page.
I never considered, until now, that maybe I have created a problem in the process.
I don't see any possible problem, other than that you're wasting your time, which is your own affair.
Given that robots have a knack of digging up all sorts of things normal browsers are unlikely to find
If a spider is written which is smart enough to determine that a site is using WSN based on setup.php, it can also be written to simply test for the names of all the php files and match the pattern to tell that it's WSN. (As long as we're being paranoid.)
Forum Regular
Usergroup: Customer
Joined: Jan 11, 2006
Total Topics: 48
Total Comments: 166
Fair enough though. I'll consider it both okay to, and moot to bother with post installation worries. Mostly I just didn't want to break something by removing setup or upgrade.
Forum Regular
Usergroup: Customer
Joined: Nov 16, 2005
Location: Colorado
Total Topics: 41
Total Comments: 115
Interesting article on Robots.txt files - at least I found it interesting -
Read it online at: magazine.websiteservices.co...s/search.aspx?q=robots&p=1
Top right hand corner - has a link for free subsriptions to the magazine .. I have been on their initial mailing list for the first two issues - It is a good read.
-DR
Forum Regular
Usergroup: Customer
Joined: Jan 11, 2006
Total Topics: 48
Total Comments: 166
I use a static robots.txt at some sites but resort to other techniques to keep most of them off my sites. There are way too many robots that don't obey robots.txt so I find the file only useful for the handful of search engines I allow to crawl my sites.
It's a loosing battle to try and keep all but x,y,z robots off sites with a static robots.txt file. However, I've been working with some techniques to deliver a dynamic robots.txt in conjuction with some shell scripting, apache and my firewall which I hope will allow me to forget about, for a while anyhow, the useless (to me) robots, bad robots that don't honor robots.txt and other bandwidth stealing trash bots that scours the internet.