Thread: Security considerations for setting up hosting

A client of mine are considering setting up hosting on one of their servers for a client, so that customers of theirs can log in and access their hosted system, which is basically an Oracle RDBMS with frontend, which will be sitting on either a Windows 2000 or Windows 2003 server.

The client network is a couple of 2003 domain controllers and several 2000 member servers. This is a single office with single broadband WAN connection.

I've made the usual recommendations such as ensuring servers are up to date with regards service packs and updates, checking all open ports with a tool to see if said ports need to be open, and also checking the router configuration to make sure this is secure.

I've recommended that their customers' systems are hosted on a 2003 server rather than 2000 if possible (for obvious security reasons). I've also suggested that for customer access, ew set up two levels of security- a VPN login for their customer, and a login to the customer's actual "system" / web portal. I thought this would be more secure than having a publicly accessible URL / interface.

I just need to know what other security / server-level considerations need to be discussed to make sure we have a viable solution in place.

We expect to have maybe a total of 2500 registered users within each customer system (so there may be multiple web portals set up), but unlikely to have more than 10 concurrent connections required.

Does anyone have any recommendations / ideas / items that we should be checking / verifying?

Hello
This is intended to be a brief overview of some things you should keep in mind when installing Nagios, so as set it up in a secure manner.
Your monitoring box should be viewed as a backdoor into your other systems. In many cases, the Nagios server might be allowed access through firewalls in order to monitor remote servers. In most all cases, it is allowed to query those remote servers for various information. Monitoring servers are always given a certain level of trust in order to query remote systems. This presents a potential attacker with an attractive backdoor to your systems. An attacker might have an easier time getting into your other systems if they compromise the monitoring server first. This is particularly true if you are making use of shared SSH keys in order to monitor remote systems.
If an intruder has the ability to submit check results or external commands to the Nagios daemon, they have the potential to submit bogus monitoring data, drive you nuts you with bogus notifications, or cause event handler scripts to be triggered. If you have event handler scripts that restart services, cycle power, etc. this could be particularly problematic.
Another area of concern is the ability for intruders to sniff monitoring data (status information) as it comes across the wire. If communication channels are not encrypted, attackers can gain valuable information by watching your monitoring information. Take as an example the following situation: An attacker captures monitoring data on the wire over a period of time and analyzes the typical CPU and disk load usage of your systems, along with the number of users that are typically logged into them. The attacker is then able to determine the best time to compromise a system and use its resources (CPU, etc.) without being noticed.

Nice information.

I have also heard that if we host our email services also in shared hosting due to other users in same server sending Spam email out server Ip or our email can get banned in some companies.
So i suggest peoples to use Google apps to host email instead of in shared servers of hosting companies.

This seems like an excellent idea (using Google for email services).

Completely agree, you review goes into this stuff!