home: http://starling.us/tet
by Ĝan Ŭesli Starling
copyright 2005-2006
Purpose: My own reason for writing these scripts is so that I might, with reasonable security, remotely trigger routine tasks on a group of PCs running servo-hydraulic machines in an automotive test lab. On weekdays those PCs are often attended by operators whom I should interupt but seldom during their tasks. Neither RAdmin nor VNC fill this particular need since they both wrest away control over the mouse and keyboard.
The scripts which I remotely trigger on those PCs do harmless, routine things like back up the latest configuration and tuning data, transfer current status logs back to me, etc. In short, an array of mundane little tasks best fulfilled unobtrusively in the background. Some I might relegate to a fixed schedule. But others not, hence the origin of the Perl scripts presented here. I wrote them for me and you get them free but wholly without any guarantee. The same deal as always...
How they work is by XML-RPC. And what is that? In short it’s a simple protocol for sending remote procedure calls over the Internet using XML and HTTP. For a closer look into this ultra-simple protocol, read here: XML-RPC
With this XML-RPC Server/Client pair you can trigger remote PCs to do almost anything. Anything, at least, for which you have written a script in advance. Some example scripts (for testing & backup) are herewith provided.
Description: Whatever tasks you need to have remote PCs perform routinely, script them in your language of choice: CSh, MS-DOS Batch, Perl, Python, Ruby, TCL, or whatever. Then propagate however many such scripts you like among those PCs which run this server. Whenever the client so requests, the server shall be run. As easy as that.
Stable: Last modified 2006-06-20, lines of code 1351, comment lines 358.
Info:
POD as HTML
Download:
Perl *.pl
Description: Run this client from any PC. On demand it will connect to one or more of the servers, requesting each one in turn to execute your script of choice. Be sure to peruse the pull-down Help and Examples menus for setup info.
Extras: Built-in SQL-client relay functioinality to access your favorite DB from behind most firewalls.
Stable: Last modified 2006-06-20, lines of code 3361, comment lines 708.
Info:
POD as HTML
Screenshot 1
Screenshot 2
Download:
Perl *.pl
For use with the execute_script method of the XML-RPC client/server pair.
Description: Three utterly harmless example scripts purely for purposes of testing the execute_script method with multiple server/client pairs. Rightmost is an ASCII text file listing the three scripts (used as config by client/server pair).
Stable: Last modified 2005-09-05
Download:
DOS *.bat
Perl *.pl
Unix *.csh
Text *.txt
Description: When placed same directory as other scripts on the server, allows client to remotely reboot selected servers. Principally useful only after transfering an update of the server script itself via the add_new_script method. Tested successfully on Win2K OS and UNIX OS NetBSD 2.0.2.
Stable: Last modified 2005-09-05, lines of code 43, comment lines 36.
Download:
Perl *.pl
Initial installation and configuration is simple enough. The client and server scripts are designed to fire up and work even without configuration. Create a new directory anywhere you like and copy the client and server there. Do whatever is usual for your own OS make them executable: chmod 755 on Unix; map to C:\Perl\bin\wperl.exe on Win32. Then execute them in place.
The best way to execute them the first few times is via command line. On Win32 this means a DOS screen. The reason is so that any startup errors will remain up long enough for you to read them. Else they may flash and disappear in an instant. If you should happen to get such an error, the most likely cause is that your installation of Perl lacks for this or that module: Crypt::CBC, Crypt::Blowfish, etc. These will have to be installed in whatever way is usual for your own OS: perl -e shell -MCPAN on Unix (see this link: MCPAN ); PPM on Win32.
Unconfigured, the client/server pair will fall back to built-in defaults for the crypto key and password. This would ordinarily be an unsafe condition. But for the initial trial, you’ll not have any other scripts available for execution. So all you’ll be able to do are maintenance tasks: query status, changing passwords and cipher keys, reboot and/or kill the server.
Before putting to any real use, edit the head of both the server and client scripts for your own, unique cipher key and password. This will set your startup conditions to be unique. But don’t rely upon that, of course. Change both yet again via the client to something not anywhere written down.
Thas done, you may next copy down into that same directory the three harmless executable Perl scripts herewith provided...the *.txt list also. I trust that you examined their contents before copying them down, did you not? Tell me you did. If not, Bad user! No bisquet! Bad user! Always, always examine a script most carefully before copying it into the XML-RPC server’s directory of executable scripts. Doing so is and shall ever remain at your hazard!
But not to worry about which catagory of scripts they might be. The server knows which OS it is on and will not try to run a *.csh script on Win32 nor a *.bat on Unix.
That done, now query the server’s status again via the client. Note that the server fails to acknowledge any scripts yet exist. You will first have to add them via the client’s pull-down menu. This is appropriately titled: At your hazard!. Alternately you may kill and restart the server. The reason is that the server will not admit the existence of any scripts which were not there at startup unless they were more recently added via the client. It will also refuse to execute scripts which were modified either since startup or additon via the client. Nor will it run any binary files at all. Scripts only, composed in pure ASCII text, so that you might examine them first. This is the most important thing. I cannot stress it highly enough.
Once any of the three harmless scripts are successfully executed by the server at request of the client, then you’ll know the system is working. Any further scripts you add, or any updates to the server, will similarly be: At your hazard. Enough said...
Fairly strong security is provided for via passwords and Blowfish encryption which may be different for every server and changed on the fly. Do take note, however, that only the content data are encrypted...not the TCP/IP socket nor yet the container XML nodes. It is not therefor equal to SSL or a VPN. More like sending strongly coded messages on postcards like so...
The client sends a postcard which says: To: X, From: Y, Subj: 32-chars-of-gibberish. Request: random-string-of-gibberish. Then the server fires back its own postcard saying: To: Y, Fm: X, Reply: random-string-of-gibberish.
Just like that, each and every single time. Given enough exchanges (all encrypted by the same key) an expert could possibly make something of it. But such an effort is onerous, even futile should the user change their key periodically.
Below is a captured example of an actual XML-RPC client call. As is evident, the XML structure is in exposed as cleartext. The method name and parameters, however, are strongly encrypted.
<?xml version="1.0"?>
<methodCall>
<methodName>da32UcqEoHQd40YzATcustVZeMhMiEgP</methodName>
<params>
<param><value><string>
UmFuZG9tSVZDOHY+MzBRciRXPFRun5amoX4evLusiHjXV7Uv2ZRcqSdUdKlvk6CR+6c7IoLukCNN
SvgSEk/9/A==
</string></value></param>
<param><value><string>UmFuZG9tSVZDOHY+MzBRcv/vqdXt3n+F
</string></value></param>
</params>
</methodCall>
Below is a captured example of the actual XML-RPC server response to the client call above. Again the actual data parameters are strongly encrypted, but with their surrounding shell of XML structure exposed.
<?xml version="1.0"?>
<methodResponse>
<params>
<param><value><string>
UmFuZG9tSVZDOHY+MzBRcgsS90/x1/BRmZ/hCsCk2p0gIPBhbtCU8KleOnfOP/EuI9TUZFfkR5fw
+HXjy9ycmQFSC1Q4Z0YcpqdWL8rlM7OFlbwj2hsVR0xgK7VITdPteUfqGskRtRe1MBtFgagDL60c
N0VxF0MNRCiTHdjGfjlsFlqnq9dMg1xs41Lo6xLyb4DW3/n2EkBqXmVFZqN7fmkzVi3hGsIxv2Pg
kmkx/wHdYJfVmuZGs3YlFnUrxDIAQo1tFNzEY1mYpTVPW72ZK1JTz024ncrXsGXmNQr+S25Ek+qk
zzsehYmFKCnxBU8hVuun2w2B+3njgbuUFeXOmexNd5pnK5QHjB7x31VbUkwne0jZ/03jQ9ny0J2l
zD6W261ex8lzGWDE56NY9lGK9c/KPtEb4rfkSvFFO9bZoHYQJQFmfypFapOrXPsd57hpQBcc7xnt
Q9qo6LnKZmhXOjfPT0zXZ9xASNh3QgwOWmoAiO7qeIzEyy3aaCOyVJ/L/mShAWW1uH8Q1Yu/ostq
S2gfEzlvKZo4H4C7laTItHGvA+kZ1JAQp7lwqGCNfxyf7QGLCb+TdX7eriYc1NFXRMP3jwiOt2pW
5opYE6VodGoqzZVi5xMU7D1rvwZ5a7He1A/ST1+CXll5h/OTkVUXEDSUKVHu9GFh2xN3AjdpiwkV
mqWmJysHpmtMuQFDtgqqpiuaS5YQjoGYCA5PX0XgGszAg5OX+4GtYyxwhZsu04nGRDaLy3JMMzcO
pO9aRgKJn/RSPqbKXhZ01wDXKf5dtz5I/TSRI6SqaC/CMct6qlt1I3aBMvvVe/OMLmqQd/fi2e1i
0cPd1o6+BBqjchHKTVDlE/hTODgMrv1+bzerJ2pgDvkS2Y/Zqj7YG8/dCFme
</string></value></param>
</params>
</methodResponse>
The scenario described above is clearly open to derrogation as something of a half measure. I admit this. But know that it was done that way for a couple of reasons.
Firstly, my own purposes, as detailed at the top of this page, do not really envision a host of dedicated adversaries from the government alphabet agencies. This degree of security is more than adequate to my purposes. More security than this would impede them.
More highly secure, wholly encrypted virtual private networks must of course use a different port and wholly other protocols. Thus the automatic advantages of an already-open protocol and port in nearly every coporate firewall would be lost. This way is simpler by far in terms of both cost and politics. Yet still the security is very good. Add to this the consideration of how little encrypted traffic you are likely to generate during your very occasioinal use. Surely insufficient for crypto-analysis...even if you change the key but rarely.
And as an aside, the XML structure of these exchanges is always the same. It never changes in the slightest. While no cryptographer myself, what little reading I have done on the topic does inform that professional code breakers love few things better than to obtain a large sample of exchanges which all begin identically. It simplifies their analysis...or so I have read. Thus it follows that in a way, this poor half-measure quite incidentally denies our theoretical adversary a small advantage.
Worse than the dread of foreign intruders, beware even more what you yourself may write into scripts for remote execution. In the realm of networking tools, an XML-RPC Client/Server pair such as mine are hammer and tongs. Simple tools, but ones having great utility and power. Deftly employed, nothing else compares for versatility. Flail about clumsily, however, and the potential for wholly accidental disaster is manifest. So always test new scripts thoroughly before you propagate them. Enough said? Not by half...but I trust you get the idea.
This refers to pure ASCII text files which are executed by languages such as Perl, Python, Ruby, DOS Batch, etc. The main advantage of a script is that you can always be certain what sort of instructions it contains. When asked to execute a script, the XML-RPC server takes these few precautions only: 1) The filename is stripped of its path, if any; 2) This filename must then match a list; 3) Lastly, the server’s own copy is verified against modification. Passing these, and only these, the script will execute quite as if you had typed it on the command line.
The server will, on its own accord, refuse to directly execute any binary files. This for the aforementioned reason of not being able to easily verify them. Nevertheless, some few among you might still hazard to do so. In that case, you will have to call that out in an ASCII script of your own devising: *.bat, *.csh, *.pl, or whatever. In my own example script (safe_script.bat) I perform the least dangerous of such feats: calling up the MSIE browser and opening it to a pair of web pages.
So it is possible. How you will verify the safety of binary files thus executed by script is entirely up to you. You might check the modification date at minimum. But know that this is easily spoofed. It is child’s play to pre-date a file ex-post-facto, provided you own it. I therfor suggest that you first insure they be owned at the highest level (root or admin) and not writable by any lesser user whatever. That at a minimum. Actually executing any such remains, as always, at your own hazard!
I also have occasional need to keep tabs on those same PCs when they are left to run unattended overnight and on weekends. Not a pressing regular need, but only an occasional one. Ordinarily to facilitate this a political accomodation would have to be made with one’s IT department, a long, tedious, uphill affair. For such an occasional need, hardly worth the headaches and exapsiration. Nor would it likely succeed to best result. Experience fortells of an almost-certain probability of my own very modest proposal being set aside in favor of some extravagantly expensive commercial software by you-know-who which overshot my every requirement and would further prove utterly useless on my UNIX box at home.
A more skillful approach from every standpoint is to first demonstrate a cost-free, IT-maintenance-free, already-working solution. Then seek corporate gratitude for a fait acompli. All quite easily achieved, as happens, because the way already lay open. How so? XML-RPC routes its own traffic using the same protocol as the World Wide Web. Thus any part of the Internet which a desktop web browser can see, an XML-RPC client can see it too. This is a deliberate feature of XML-RPC...an intentional dual use which some few experts deride on various grounds. Yet it works most admirably.
Thus an XML-RPC server resident somewhere, out there on the Internet, can be communicated with by an XML-RPC client safely ensconsed behind a firewall...provided they do it using port 80. In my own case I already had an Apache server sitting astride port 80 on my home PC. But even that is not a problem as easy workarounds exist. What I did was to write a CGI script in Perl (gus_xml-rpc_bridge.pl) to forward XML-RPC calls incoming on port 80 out to port 8080 on the same PC where my XML-RPC server usually listens.
Nothing is thereby forced open or breached, nothing infected, impeded or in any way harmed. All that happens is a very slightly different kind of traffic shares an existing, wide-open pathway which everyone, the IT department most of all, is fully aware of. This is an opportunity to be exploited only with the greatest of care, lest it and another privilege besides be taken away. All the IT department need do is close port 80 to your PC alone and no more Internet for you. Hence the need of presenting your little fait accompli as soon as it is demonstrable to powers-that-be which your IT department must respect. Don’t you just utterly lothe corporate politics? All of that out of the way, here is a solution which works. I wrote it for me and you get it free. And, as always, quite without any guarantee.
Description: Used to bridge firewalls where only port 80 is open to the Internet. When installed in the cgi-bin of an Apache web server, XML-RPC calls arriving via the Internet as HTTP on port 80 are forwarded to a designated URL and port on the LAN. The latter’s response is passed back to the originating XML-RPC client.
Stable: Last modified 2005-09-10, lines of code 77, comment lines 20.
Info:
POD as HTML
Download:
Perl *.pl
The security of bridging firewalls can be increased dramatically. This has to do, not with XML-RPC, but with the Apache server and with Perl. Chances are very good that port 443 is every bit as open as port 80, and for the same reason. Thus you may equip your web server with SSL and thereby obtain a fully encrypted tunnel for every XML-RPC call.
In your configuration file httpd.conf for Apache, version 2, include one or more of the very slight modifications shown below. At the very tail end of mine, I have tacked on the following...
# Custom changes by GUS
DirectoryIndex index.html index.xml index.html.var
ScriptAlias /cgi-bin/ "/usr/pkg/libexec/cgi-bin/"
ScriptAlias /RPC2 "/usr/pkg/libexec/cgi-bin/gus_xml-rpc_bridge.pl"
AddType text/xml *.xml
AddType text/xml *.xsl
AddType text/plain *.log
AddType text/plain *.dat
Strictly speaking, only the second ScriptAlias line directly pertains, but the others are generally useful also, so that I like to recommend them. Those two ScriptAlias lines are path redirections. They serve to translate elements of the URL to directories on the web server. The paths shown are right and proper for NetBSD OS. For Linux, Mac OS X or Win32 they will vary. So edit as appropriate for your own OS.
So that your XML-RPC client will not reject a URL which has https: for its protocol and :443 for its port, install one further Perl module Crypt::SSLeay in the same way as you did for all the other Perl modules. Then restart your client and it should work!
When need arose to create a database for tracking sensor calibration, I wanted to do it the best way possible...which, of course, meant employing PostgreSQL. But, as expected, my first attempt to access the server from my desktop PC at work was blocked by the corporate firewall.
Rather than beg and plead my case with the powers that be, it was easier by far to add yet a further method into my already working XML-RPC CGI bridge. And, so...violla! Look to the pull-down menu Relays in versions later than 2005-10-15 to enjoy this feature.
Now I can happily slave away from my home on nights and weekends to prototype the ideal SQL table structure. My time at work can then be devoted to parsing records and tweaking experimental search queries. When at long last these prove satisfactory, then I can put together a GUI exactly suited to the purpose whereupon I shall enjoy a free, open source, fait accompli for presentation to management. Joy!
Updates to this suite of programs and their reasons are described below.
The subroutine brew_cipher in embeded module GUS::Crypt modified by the addition of pass-through argument head => 'randomiv' to accomodate change in default behavior of Perl module Crypt::CBC versions 2.17 and later.