Server Admin won't connect

Is the firewall set so that all traffic from your computer to the server allowed? Does the Server Admin on the server work correctly when you fire it up?

=Tod

+Is there a firewall on the server I don't know about?+
There is a firewall which you should be running, but I can't say whether you are or not. In the Server Admin on the server does it say "firewall" by one of the green dots? If so you have a firewall running.

+Would a firewall stop me from connecting to my server locally?+
If it is configured to disallow the ports Server Admin needs then, yes. You can create sets of IP addresses and have different firewall settings - like allow all - for certain IPs or IP ranges.

Assuming your Server Admin programs are of the same version it definitely sounds like a connectivity problem rather than a server problem.

HTH,
=Tod

You want run with the firewall on, of course. Create a group in your firewall and put in either your admin IP machines or your IP space - whatever you're comfortable with - and either open all the ports you need or simply set the firewall to "Allow All Traffic". This will allow you to admin, ssh, etc from your machine but keep the firewall restrictive for outsiders.

You can also limit certain functions - like ssh - to certain users and groups and this is a good practice as well for security.

HTH,
=Tod

Hi, Derak
recently, I have the same problem. My Server Admin would sometimes be able to connected and find the local server, but sometimes not.

My root password was brutal forced and hacked 1.5 months ago but ever since that, my administrator password has some strange and peculiar problems. Symptoms include unable to change or enable root user passwords. Also, commands line like

server:~ xadmin$ su -
Password:
su: Sorry

su - will not work even though I typed in the correct password. I was not able to reset new root password because Directory Utility's enable root password would simply give no response when I click it (Change root password option becomes a gray icon, unable to be selected). Or you may find that next morning, your HDD is suddenly full with 0 byte left because the log file has grown so large overnight due to consecutive Denial of Service Attacks. My log file had grown to 40G just in one night. This also caused my Server Admin unable to connect and find local server. Ever since the hacking, my Server Admin has problem of connecting issue. So you may want to check your log file as well. Your system "might be" hacked and you just do not know it.

Open all the firewall ports can be dangerous; just do it carefully.

So if there is something wrong with your administrator password, you will not be able to connect to your Server Admin. But here is how I solved.

I deleted all the passwords used for Server Admin on the Keychain. Then I changed the administrator's password. Restart Xserve, connect to the Server Admin with my new password. Then it solves my problem.

Reinstall the server could also help.

Best regards.

Mr. Latte, if in fact your "root password was brutal forced and hacked 1.5 months ago"
then you should have posted about that in a separate thread.

And without a doubt, you should have backed up your data and wiped and reinstalled.
If a hacker had root access to your server, you do not know what they did and what's still there.
Including altering system binaries to hide their actions.

You should not allow root access nor enable it (it's not by default), use "sudo"
and you can accomplish all you need.

Standard security practices are to disallow root access, do not access your server over an unsecured connection - VPN remotely, and if you must have ssh access, restrict allowed external IPs/blocks at your firewall. Use a dedicated hardware firewall. Allow ssh access via ssh-key only.
See the "Create Authentication Keys" section of http://afp548.com/netboot/mactips/rsync.html

Mr Latte, your server may well remain breached, and the passwords aren't the only backdoor that an attacker can leave. Whether this behavior is a breach or a corruption is unclear; attackers can leave all manner of "presents" for themselves or for you.

The brute-force attacks target passwords from one of the commonly-lised lists (the usual attack dictionaries are 5000 or so passwords) or potentially a password that was too few characters.

And ssh can be further secured with certificates, as mentioned in davidh's reply.

Reinstallation from archives and distros is likely warranted.

Due to my web log file under /var/log/apache2 was blowing up like 40GB in one night, I had no way to open it. I had to delete it or Server Admin would be able to be connected. If I could not connect to Server Admin, then I would have trouble to shut down the Web Service, which in turn, would make attacker more easier to attack my server. Then I had to go to Terminal to do apache shut down manually. Mr. Hoffman, you mentioned SSH, that brought my attention because my SSH option was off but now it is on. That's spooky. And my created SSL certificate is gone from the Web list. It is just gone with only Default option left. Fortunately, I did not have major loss because all web content are moved. I do have caught some log file as following after the attack. What do you think about the following log file?

87.253.134.12 - - [27/Oct/2010:02:55:12 +0800] "GET //phpmyadmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:13 +0800] "GET //pma/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:14 +0800] "GET //admin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:14 +0800] "GET //dbadmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:15 +0800] "GET //mysql/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:15 +0800] "GET //php-my-admin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:16 +0800] "GET //myadmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:17 +0800] "GET //PHPMYADMIN/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:17 +0800] "GET //phpMyAdmin/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534
87.253.134.12 - - [27/Oct/2010:02:55:18 +0800] "GET //p/m/a/config/config.inc.php?p=phpinfo(); HTTP/1.1" 404 534

72.167.245.164 - - [27/Oct/2010:09:16:15 +0800] "GET /horde-3.0.5//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:15 +0800] "GET /horde-3.0.6//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:16 +0800] "GET /horde-3.0.7//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:17 +0800] "GET /horde-3.0.8//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:17 +0800] "GET //README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:17 +0800] "GET /horde-3.0.9//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:18 +0800] "GET /mail//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:18 +0800] "GET /email//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:18 +0800] "GET /webmail//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:19 +0800] "GET /newmail//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:19 +0800] "GET /mails//README HTTP/1.1" 404 534
72.167.245.164 - - [27/Oct/2010:09:16:20 +0800] "GET /mailz//README HTTP/1.1" 404 534


87.253.134.12 is from Universiteit Leiden locatie De Leeuwenhoek.
72.167.245.164 is from AZ Scottsdale, USA.

The short version: +reinstall from distro+.

The long version:

Without doubt, question, hesitation or further consideration, I would wipe the disks and reinstall this server from known-good backups and from distributions.

I would not attempt to troubleshoot anything here other than that immediately involving whatever specific data I didn't otherwise have an archive of. Specifically excluded from the migration are all passwords, all private keys, all content management system passwords, any file protection settings, and anything that's existing and executable.

That particular block of log chunder is the usual content management attacks running on the web. The disconcerting parts are the pieces that re-enable themselves, and the pieces that do not work. That implies server configuration changes, and the likelihood of one or more backdoor(s) existing here.

The immediate assumption here being that this server remains breached. This server is potentially already blacklisted (you can check your IP via the Spamhaus.org folks), but definitely get this box offline before it causes more damage and more problems, or before the apparent beachhead here extends through the local network. (If it hasn't already.)

In my opinion, this server is assumed to be breached.