ColdFusion hosting question (possible Hostile Takeover)

[BZ]

I am the new developer replacing the old developers for a coldfusion (4.5?) / sql server (2000) website

The client is worried that the old developers will sabotage the site when they learn they are being canned. Neither of us are sure whether this is a realistic concern.

I currently have access to webroot with FTP and to SQL server via enterprise manager, but the client doesn't have any more information. I don't have access to the web admin panel, the coldfusion administrator or the cf_root directory. I think I can contact the host to get that stuff, but they MIGHT be connected to the developer in some way.

I'm trying to develop a strategy so that I can get as much access as possible first without raising suspicions, and then start to ask the old developers questions and get as much help from them as possible in the transition. If they cooperate it will be very valuable because the site is a mess. If they don't, I want to be in a position to take control of the site - i.e. change all the passwords and lock them out.

So my questions:
* What do I need to get from the host aside from what I list above?
*Once I have full access, what steps can I take to prepare to lock them out if necessary?
* Should I just preemptively lock them out now?
* If they cooperate, what should be my priorities in asking them for help? My list so far is
1)info on all installed components and custom tags
2)current procedures
* and finally, is there a forum where this post would be more on-topic?


Thanks for reading this far and any responses!

 

[Hammer]

hold their last paycheck until the turn over everything. problem solved.

 

[dquan97]

I think it's very important to get ownership of the domain, because the owner can change the DNS and other info. With control of the DNS, you can point it to another host in case of trouble by the existing host.

 

[kt]

Unless those old developers are planning to quit the field or are extremely stupid, they wouldn't sabotage an old client even though they are being replaced.

When I used to work for a web development firm, we replaced a couple of old developers before and they were really helpful in making the transition. The vice versa is also true where we got replaced and I had to help the new developers understand our codes and setup.

 

[rh71]

From a CF standpoint:

- You are hosting elsewhere and shouldn't have access to the CF Administrator or CF root directory anyway. Or are you on a dedicated box that MAY have provided you this access ? If you do have CF Administrator access for whatever reason, make sure you know the password for both the admin and RDS connections.

- custom tags are important. Make sure that, if they were indeed developed in-house, that it's well documented. It could be the lifeline of the web app. If they are readily available via Macromedia's site, then all you have to worry about is backing them up from the custom_tags directory. Be careful - sometimes they have associated .dll's.

- Macromedia CF link --> http://www.macromedia.com/cfusion/webforums/forum/index.cfm?forumid=1 .. I'd suggest the Webhostingtalk forum --> http://www.webhostingtalk.com/ ... most of the other stuff is not CF-related.

 

[BZ]

it is a shared host. I didn't know if it was typical to be able to install custom tags in cfroot on a shared server. I know they use at least 2 commercial tags. There are a lot of custom tags that they did in house, but so far most of them look like they are not compiled, so I should be able to figure them out. (I know they don't have any valuable documentation.)

thanks for the macromedia link too

 

[Xede]

Here's the things I can think of that you would want to secure or at least make backups of so that you could restore it correctly if the old devs tried to mess something up:

1) FTP. Create a backup of everything below webroot. Also see if there are any other directories involved with the web site that are not actually beneath webroot on the server.
2) Database definitions. In Enterprise Manager, generate a script all the tables, views, stored procedures, and any other objects in the database (right click on database, All Tasks, Generate SQL Script, etc).
3) Create a reliable backup of your actual database data.
4) CF Admin. Copy all current settings.
5) any custom tags and CFX tags installed
6) any application-specific data they could mess up via your web admin panel

To answer your questions:

* What do I need to get from the host aside from what I list above?

You need access to the CF Administrator, and I assume you'd need access to your own web admin panel (if you can't get that yourself since you already have database access and access to the site's CF pages). Will you be installing/managing custom tags and any other add-ons yourself, or does your host do that for you? If you'll be doing that you'd need remote access to the server itself, not just FTP access to webroot.

*Once I have full access, what steps can I take to prepare to lock them out if necessary?

First, I would find out exactly what kinds of access the old developers have (can they access the server itself, or only FTP to webroot?) If you're genuinely concerned about sabotage, the safest option would be to start from scratch and reinstall and rebuild the site (using a backup of the old site as a reference) rather than hoping/guessing that you've changed all the right passwords. Depending on your resources, and since you're a new dev coming in on a messy application, that might not be a realistic choice. If you just want to lock them out by changing passwords, the ones I can think of to change are: remote server login (both web server and DB server), FTP (both servers), Enterprise Manager, Cold Fusion Administrator, Cold Fusion Studio (this password can be changed from within Cold Fusion Administrator), and any administrator passwords in your application's web admin panel.

* Should I just preemptively lock them out now?

If all you have is FTP and Enterprise Manager access and are suspicious of the host, it doesn't sound like you're capable of locking them out now. Why would you have reason to believe that the host has connection to the old developer (rather than loyalty to the site's owner)? If you need to lock out the old developer, you need to be able to trust the host. If you don't trust the host, you need to change hosts.

* If they cooperate, what should be my priorities in asking them for help? My list so far is
1)info on all installed components and custom tags
2)current procedures

I'd start with:
1) application security - how does your site's log-in system work? How is the web admin panel protected?
2) Web admin panel - as a developer, what functionality within the web admin panel do you need to know about, if any?
3) error handling - does the application have any kind of site-wide error handling and reporting? If so, how does that work?
4) Scheduled tasks - does the application use them (You can see any scheduled tasks from within CF Administrator), what do they do?

 

[rh71]

Originally posted by: BZ
it is a shared host. I didn't know if it was typical to be able to install custom tags in cfroot on a shared server. I know they use at least 2 commercial tags. There are a lot of custom tags that they did in house, but so far most of them look like they are not compiled, so I should be able to figure them out. (I know they don't have any valuable documentation.)

thanks for the macromedia link too

There's no chance you can have access to the CF Administrator if it's a shared server. And you make a good point about custom tags as well. Depending on the host, they will "install" the custom tags for you, but you shouldn't have access to that directory either via FTP. Looks like even less for you to worry about. Just backup all the files you have access to via FTP and there shouldn't be anything further they can "sabotage"... unless they put in a reference to something on another server (to check for up/down) and encrypted the .cfm. Can't watch everything.

 

[BZ]

you guys are great! thanks