"duncan gray" <[EMAIL PROTECTED]> wrote: > Ive recently just had one of my websites hacked on my > server I have know Idea how as I thought my server was > pretty secure, As I've kept up to date with all the > latest patches, switched my tellnet over to SSH, and > so forth
"And so forth" is pretty vague. It might be useful for you to elaborate. Every day, new security vulnerabilities are discovered for software that you may be running on the server. Do you have a firewall in place with appropriate rules, something in place for intrusion detection, checking for weak passwords, checking logs for suspicious activity, etc.? If not you probably have a false sense of security. Security is relative. And improving your security requires technology, procedures and design and is not a one-time thing. > my bigest guess is that you have to pass the > root password to the machine while logging in over the > Web admin pages, this scare me some what. But raises > some questions in my mind. Yes, that's true. As someone pointed out, you can change the root password to be different from admin's using passwd from the shell. And as they pointed out, that will do little good to prevent anyone who learns the admin password from gaining access to the GUI and changing the admin password, which will also change the root password. There are some steps you can take. Setup your GUI to run under SSL. Edit srm.conf or httpd.conf (depends on your server) and change the URL directory for the GUI admin site. Make edits so it runs on a different port. Setup an IPCHAINS rule (if you haven't installed IPCHAINS you should consider doing so) that limits access to the GUI to your IP. Of course, it's more complicated if you need customers to be able to access the site admin and user GUI, but it's not much more difficult. The point is you have some options. > A. is there a way to make the main admin pages work > off a different user account, If not why not as it > seems like a huge security hole to me. That's not possible. The scripts need to have root user privileges b/c they modify some files that are owned by root. That's not to say that Cobalt couldn't have done it differently, but I don't think customers would have been happy. They could have made the GUI run as an unprivileged user and have it write all of its actions as pending actions to a file or db and then have a root-owned set of cron jobs check the pending files or db records and take the appropriate action. The problem is that this would require a process that ran pretty frequently in the background and would likely result in delays between the admin's desired action and when it was put into effect and would result in higher server load. And that's just the simple explanation. > B. Secondly I dont know much about certificates, but > Is it possible to issue a client certificate or some > sort of certificate so you can limit only certain > browsers/users to access that site? and making sure > that the link between the server and the client is > secure? You can use SSL, then the data sent will be encrypted. You can use IPCHAINS or .htaccess to limit access by IP. There are other tools you can use as well and other ways to control access depending on your needs. Keep in mind that even if you have great technology in place for security, there are other areas you should address. For example, I personally wouldn't give any customers shell access unless you/they have a very good reason and you trust them, though gut feeling isn't always a good indicator of honesty and intentions. You can also disallow user access to the GUI and set passwords for users yourself and/or force them to be changed on a regular basis. You want strong passwords - ones containing a mix of meaningless upper and lower case letters, numbers and non-alphanumeric characters. Keep in mind that even if you take all of the main typical security measures, your server is still vulnerable. Fortunately, unless someone has targeted your server specifically, making your server much more secure than other servers out there will go a long ways. But keep in mind that there may be things that are difficult for you to control. For example, I've dealt with hosting companies that don't check ID of a person wanting physical access to "their" server. And I've had a number of data centers give me a client's login info. over the phone without verifying that I'm actually authorized by the client to login to the box. Scary, but true. Security is a constant job. You need to periodically check your server, read about new vulnerabilities and be prepared to take the necessary security steps or hire someone who can do it for you. -- Steve Werby President, Befriend Internet Services LLC http://www.befriend.com/ _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
