Go Premium for a chance to win a PS4. Enter to Win


Using cwbrxd without an AS/400

Posted on 2008-10-24
Medium Priority
Last Modified: 2013-12-06
I am developing a soluting using RUNRMTJOB command in conjunction with cwbrxd.  The question has arisen about where the cwbrxd service should be running.  My choices are either running it on a central Windows 2003 server OR running on the PC's that will actually be requesting the application.  

I have a concern about running it on a Windows 2003 server from a security perspective.  I think there is less chance of a security hole if the service is run on the workstation.  My manager is of the opinion that is more efficient to run it on the server as you only have to install it once instead of on several workstations.  In essence, I agree.  However, the security aspect concerns me.

Is it possible to send a command to the server running this service without using the AS/400 runrmtjob command.  Can any computer send a remote command to this service and if so, how?  I would like to do a benign test to show my manager the vulnerability of running it on the server.

I would like to send a command from a PC to that server without using the AS/400 (such as copying a file).  Can this be done?
Question by:cosmit
  • 2
LVL 35

Accepted Solution

Gary Patterson earned 2000 total points
ID: 22799723
Server or workstation?  

Well, my answer is "neither".

There is a reason that Microsoft doesn't supply a native Remote Execution Daemon (rexecd - that's what cwbrxd is) service.  It is an inherently insecure service.  I avoid designing it into my applications, flag it as a possible vulnerability when I find it in a security audit, and take it out when practical.  It is a prohibited service in many shops due to the exposure it creates.  

Can you send a command to the service without RUNRMTCMD?  


You can use any rexec client to send a command to the service.  Rexec clients exist for just about every OS you can imagine (Google "rexec client xxxx" where xxxx is your OS of choice.).  There are also lots of rexec components available, and of course you can always write a program that speaks rexec protocol (http://www.private.org.il/mini-tcpip.faq.html#3.%20Of%20the%20rexec%20protocol.)

Can any computer send a remote command to this service?  

Yes, unless you filter somehow, like with a firewall or Windows IP filtering.  Plus you need to maintain this on every system that runs the service, creating quite a bit of admin overhead.


Open a command prompt on your XP machine and type "rexec".  Every unix/linux derivative I've ever encountered has a rexec client.  Open up a 5250 session on any of your AS/400 / iSeries / System i systems and try "rexec" [F4].

If not rexecd, then what?

Ok, now that we know that rexecd is evil (ok that may be a bit harsh), what is a poor AS/400 technician to do when faced with the need to make Windows do something for you?

There are a lot of approaches that will work, but I'll confine myself to one suggestion here:  AS/400 Data Queue's

Use an AS/400 Data Queue (*DTAQ object) to pass command requests to a custom Windows (or Java) application that monitors the data queue, inspects the incoming request, and either executes it or rejects it based on whatever rules you choose to implement regarding "safe" commands.  If you want to get fancy, you can externalize the "rules", so that adding another permitted command or set of commands only requires a settings file change, and not a code change.  (I use regular expressions syntax for this, but that is another post.)  http://www.regular-expressions.info/

As long as you secure the AS/400 data queue object, and only allow specific processes to place entries on the queue, you can dramatically limit the exposure of unauthorized commands getting executed on your server or workstation.  The client-side code can provide significant further protection by stringently limiting the commands that can be executed to a "safe" subset.  

I select using a data queue for several reasons (although there are a plethora of other approaches that can be made to work just fine):

1) By securing access to write to the data queue, you can very strictly limit the AS/400 applications and user profiles that can cause remote commands to be executed on the Windows side.  This is much more difficult to do securely with Rexecd.

2) Reading and writing to and from data queues is very easy in native RPG, COBOL, and CL, .as well as on the client side in NET, legacy Microsoft languages, and Java.   Google "iseries data queue (language of your choice)" and you will find plenty of examples.  Here's one in .NET:


3) The receiving Windows application can inspect and validate incoming requests, and only execute those that it deems to be valid or permitted.  You can't do that with Rexecd, you have to trust the sender to only send permitted commands (or you have to run under a Windows profile that only has permission to certain commands, and that can be a real admin challenge, especially if you are running on a bunch of workstations).  There is also no easy way to inspect or filter commands based on parameters in Rexecd, where you can easily do this in your own application.

4) iSeries Data queue service can be (probably should be) configured to run over SSL, so messages are encrypted.  Rexec service can also do this, so it is not a specific advantage, but I mention it because it is a great practice, especially if there is any chance now or in the future that commands containing user id, passwords, or confidential data will be exchanged.

5) If you need to receive incoming requests from multiple systems, you can either monitor multiple queues, or you can set up remote data queues on the additional systems that feed the master data queue on the central system.

Again, there are many, many approaches that will work, but I like this one from a security, stability, and ease-of implementation standpoint.  You can deploy it to servers or to workstations without creating the exposure created with Rexecd.

- Gary Patterson


Author Comment

ID: 22799788

Thank you for your thoughtful answer.  You have answered several of my AS/400 questions in the past and without fail have been extraordinarily helpful.

LVL 35

Expert Comment

by:Gary Patterson
ID: 22800000
Recognize your handle.  Always happy to help.  Glad you find it useful.

- Gary
LVL 27

Expert Comment

ID: 22800827
5) If you need to receive incoming requests from multiple systems, you can either monitor multiple queues, or you can set up remote data queues on the additional systems that feed the master data queue on the central system.

Just a minor comment (Gary has it handled fine)... Keep in mind that data queues can be "keyed" also. This can be used to identify targets if necessary -- multiple PC clients could watch for entries directed at them. Or used to identify sources, although the SenderId attribute could also be handy.

Design of the format of the entries can make data queues very flexible. And once in place, the extensibility is great.



Featured Post

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this article we will discuss all things related to StageFright bug, the most vulnerable bug of android devices.
Restoring deleted objects in Active Directory has been a standard feature in Active Directory for many years, yet some admins may not know what is available.
This is used to tweak the memory usage for your computer, it is used for servers more so than workstations but just be careful editing registry settings as it may cause irreversible results. I hold no responsibility for anything you do to the regist…
Hi friends,  in this video  I'll show you how new windows 10 user can learn the using of windows 10. Thank you.

927 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question