Who cares about SyslogD on a mainframe?

Unix System Services (USS) on a mainframe basically allows Unix applications to run and communicate. Running under USS is Syslog Daemon or SyslogD. This is an important system component because it’s part of z/OS’s Intrusion Detection and prevention Services (IDS). SyslogD receives detailed event messages, such as security violations, as well as messages from many other communications services such as FTP and AT-TLS, plus messages from routers, switches, and other network-based devices.

So, in the event of a hacker trying to log-on to your mainframe, how would you know? And when would you know? Surprisingly, many sites appear to ignore the information written to SyslogD completely! While other sites look at what has happened, perhaps a minute ago, perhaps an hour ago, perhaps yesterday!

What you probably need is some way to be alerted about what’s happening now. And, as this is 2010, you probably want the alert to come through to your mobile phone. And you then want to be able to jump on any browser, see where the trouble lies, and fix it. What are the chances of there being software that does that?

Well, let me confirm that it does exist and I’ve seen it.
WDS (www.willdata.com) has rather nice mainframe-based HTTP server software that front-ends their mainframe monitoring products. It’s called ZEN and it allows users of their products to access information through a browser – almost any browser. Their products are called ZEN EE Security, ZEN IP Monitor, or similar, but are perhaps better known by their old names of Ferret, Implex, etc. The products can monitor APPN, EE, FTP, IP, SNA, OSA, and USS. Each of these programs effectively has a DLL that allows them to plug in to the HTTP server. This can then respond to messages by ignoring them, sending a command, running a REXX EXEC, or sending an e-mail. It’s completely automated and configurable to what the users want. ZEN can also run utilities such as PING, TRACEROUTE, and NSLOOKUP commands. And, in addition to input from WDS’s programs and SyslogD, it also receives network messages and ECMS console contents.

For the end user, working from a browser, windows can be opened and closed, resized, refreshed, whatever. The windows can show number data and regularly-updated graphical displays. In fact, a variety of different graphs can be monitored in different windows at the same time, allowing end-users to monitor what’s going on in real-time. The drawing of the graphs is all handled in JavaScript (JSON, in fact), and AJAX is used so only the parts of the display that change are sent from the server to the browser, which speeds up communication considerably. It’s possible to drill-down through the alert information on screen, for example, to one particular type of alert, on a particular day, during a particular time range.

Now, the type of display I want on, say, a 17 inch laptop screen is not the same as on a 3 inch smart phone screen. You might think this would be a bit of a fly in the ointment. The truth is that WDS has a solution to even this problem.

Looking to the future, what else could we ask them to do with their excellent end-user interface? Might it not make sense to automate the monitoring of other things and use the browser-based interface to see what’s going on? Is there a way this could be done for, say, other Linux boxes? We’ll have to wait and see.

But whatever software monitor you choose, and however you choose to display it, it makes sense to ensure that SyslogD is not being ignored.