Page 1 of 1

Security Focused Methodology: Remote Server Management

Posted: Thu Feb 12, 2004 5:00 pm
by jason
Okay, so here is the deal.

The idea is to have customers install software on their server. However, I want the management of said software done from a central location, basically their control panel hosted on my servers. So basically, my server would remotely connect to the customers server, tell them what commands to run, and the server would run those commands.

Obviously, there is a potential for security problems should someone "spoof" my server. Obviously, the software will check IP, etc.

However, I want to assume the user can spoof that IP, and can fool the software into thinking it's my server where the user is managing their software from. Assume that.

Also, while my server is located under HTTPS, the remote server isn't. I have no control over this. Obviously, if it has SSL, that's great, but I can't assume that.

So here is the idea behind this whole thing.
My server = SERVER
Application installed on the customers server = APP
Client = USER
Command SERVER sends to APP to run = COMMAND

USER logs into SERVER.
USER wants to perform COMMAND.
SERVER records the COMMAND in the database on SERVER.
SERVER then sends COMMAND to APP.
APP receives command.
APP connects to SERVER.
APP verifies COMMAND with SERVER.
SERVER verifies COMMAND FOR APP by checking various things (IP, Timing, making sure someone is actually logged into SERVER, the database to make sure the request was made, and hasn't been performed).
SERVER denies or approves COMMAND.
APP receives response from SERVER.

If the COMMAND was denied, APP denies COMMAND.
APP returns to SERVER a warning message.

If the COMMAND was approved, APP performs COMMAND.
APP returns data to SERVER.

Fin.

Does this set of transactions seem resonably secure? Do you need any more information regarding this?

I want the adminstration done on my server end for various good reasons, so I am hoping that either this method will work, or you can present another method.

Note: Assume I can easily setup hashing/encryption between the two without a problem, so all transactions will be encrypted during a session. A session would be when a customer logs into my server to performs the commands. When the user logs out, the session would end (or it would time out after a period of time).

Posted: Fri Feb 13, 2004 12:12 am
by jaxn
Maybe I am missing something, but this sounds like web services to me. Can you not just use SOAP or REST or something?

I don't really see the advantage of storing the command in the DB, running the command, and then checking the DB again and again. It seems like your database/command layer would only be adding some security between SERVER and APP, which from my understanding is already a secure connection.


-Jackson

Posted: Fri Feb 13, 2004 10:08 am
by McGruff
If encrypted messages use private keys to decode I think that's it.

AFAIK network sniffing could allow a hacker to obtain copies of legitimate messages - encrypted or not - and so attempt to spoof SERVER or APP but, even if they did manage to trick APP or SERVER into replying, they can't decode the message payload without the private key.

The strength of the system depends on the chosen encryption method - and private keys staying private.

How about a retinal scan of the Chief Exec as the private key? Hmmm. Hackers wll be setting up passport photo booths all over the country. ;)

Posted: Sat Feb 14, 2004 11:46 pm
by Tanus
I ended up doing something very similar and as far as I can imagine it's hard to get around because your APP verifies that the SERVER wanted to perform xxx command in the session for USER. So even if someone was to send a command from a non-SERVER IP address, it would still have to check with SERVER to see if it really did send COMMAND.

Posted: Thu Feb 19, 2004 5:11 pm
by cybaf
As Tanus said above, when APP connects to SERVER to verify the COMMAND, this check will continue to some stage and could thus be used in a DOS (Denial of Service) attack.

I'm thinking that a possible way to work around this would be to block all incoming connections to SERVER (that ofcourse have to do with this particular system) whenever a USER is not logged into SERVER.

maybe use dedicated ports for incoming connections to tighten it up even more.

//cybaf