Jeremy,

I used to work for IBM and I worked on the Host On-Demand product. I no
longer work for IBM, so please let me say that all statements in this
response are my own opinions and not IBM's in any way.

Let me clear some things up. First off, I would suggest you read the
security chapters of the online manuals. Second, as with any IBM product, I
would suggest reading the redbooks which contain even more documentation
that the online manuals (http://www.ibm.com/redbooks). I don't think you
can argue that some of the "red-works" are the best documentation that any
software provider provides.

Let me say that first, I think most companies employ HoD internally. What I
mean by this, is that the HoD server sits on a intranet web server while the
hosts (mainframes) are definitely internal and the client are either
internal or connected via some type of VPN. You must understand that most
companies that have 390's or the such protect them to every extent. That
being said, it justifies why the initial security setup is as lax as you
have seen. Finally, if you read the documentation you will see that HoD is
also positioned to extend internet hosts to the Internet. HoD (v5.0) has
security features that makes even my mind spin when it comes to
understanding all the options, but it can definitely be secured. These are
then setup by the customer or (for a fee) an IBM rep. I guess you can liken
HoD's initial security policy to Red Hat shipping with telnet turned on --
you could run telnet if the network is under your control, or you could
additionally download ssh and turn off telnet if you are smart.

>1) Everything happens in the clear, starting with standard HTTP to
>authenticate to the web server and download the java applet that acts as
>the terminal emulator front-end for the user. The user's conversation
>with the target server of interest also happens in the clear, including
>the user's login name and password.

All I can say here, is this was your choice. What you are talking about is
the applet code. If you really want to protect applet code, you can put the
files on the HTTPS side of your web server. Also, as for the users
configuration data (host definitions) are not protected by default. As with
many older products, HoD started by starting to a unprivileged port before
everyone started piping everything across port 80. With V5, you can
configure HOD to talk to port 80 for user configurations. As with the java
code, you can force this port 80 access servlet to exist on the HTTPS side
of the web server, this securing the data. Talking to the unsecured port is
definitely a carry over to support existing customers.

>2) Outside of using HTTP to serve up the java client, the Host on Demand
>server seems to just act as a port forwarder. You wind up with the java
>terminal emulator establishing a TCP connection to an obscure port on the
>HoD server, which then simply forwards the connection to the target
>machine.

I'm not sure what you are seeing here (guessing you are using the
redirector), but this definitely isn't the default. In the default case,
when you configure the clients to connect to the host system, the flow is as
follows: client gets code from web server, client gets configuration from
web(HoD) server, client connects to host system. You could in the past use
a redirector part of the product to force connections through the hod server
from the client to the host, but it isn't recommended for standard use.
However, the redirector part of HoD does provide major security if you need
it. It can do client/server verification given the fact that it supports
both client side and server side certificates. Also note that it benefits
you to not use the redirector, as direct connections between the client and
host make HoD scale far better than other solutions on the market that use a
middle tier. Finally, there was some security work that went into some
version of HOD that provided end to end security between the client and host
without the redirector (remember that this takes some time as mainframes
weren't designed to support encrypted connections initially - that's why you
see middle tiers).

>3) After the authorized HoD user establishes the TCP connection to the
>HoD server, the HoD server continues to listen for additional connections
>on that same obscure port. It dutifully forwards those additional
>connections to the target server.

The continuous traffic you see here is most probably the license counting
mechanism. Note you can turn this off if you would like through the HoD
Administrator. If you are using the redirector, this is normal. Remember
that the redirector is similar to a IP redirect in a firewall. It can
effectively hide all but that port on the host.

>4) The HoD server doesn't seem to care where the TCP connections come
>from. Assuming the HoD server is at 12.34.56.78 and the obscure port is
>1234, I tried the following from a completely unrelated client machine
>elsewhere on the Internet: "telnet 12.34.56.78 1234" Not only did I
>connect, but I also immediately got the target machine's banner and login
>prompt.

This makes me assume you are using the redirector. In the same place where
you defined the redirector session, you can turn on security that makes the
client verify the server as well as makes the server verify the client.
Note, that this security stuff is only available on some of the supported
platforms as a large amount of the SSL code must be implemented in a
platform specific way.

>I'm not sure whether to call this a set of bugs or a serious design flaw.
>I don't see anything in the Bugtraq archives with the string "host on
>demand." Has anyone else had experience with this product who can shed
>light on whether this is just really poor configuration or a real
>brain-dead product when it comes to security?

I think it can be summed up as lack of knowledge of the product mixed with a
default security policy that doesn't fit your needs. Both can be fixed! If
you talk to IBM about it, I can assume their answer will be "talk to your
service rep and we'll help you out".

>Jeremy Charles
>circbwwoc.org

<legal statement="This is my own statement and not verified or supported by
any of my past employers" />

---
Andrew Spyker (aspykernc.rr.com)
Software Engineer
http://spyker.dyndns.org

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]