In order to bring it up to some semblance of modernity and allow it to print to their shop printers, which were IP-driven, they had to get a third-party to procure and install (or build?) an ethernet interface for the machine, and fired up the TCP/IP stack. It kept crashing when they put it on the network, until they finally figured out that the issue was that the TCP/IP stack didn't understand multicast packets, and so whenever a stray multicast packet hit the interface, the whole thing threw up its hands and gave up.
The solution was to keep the mainframe on a private network segment behind a firewall, not for security's sake, but because it was the only way to insure no multicast packets would hit it and halt production in three different factories
I managed to crash the TCP/IP stack on z/OS during my training with a runaway Perl script that inadvertently had turned into a fork bomb. Luckily, it was just a testing/development system, and SNA kept working, so the only person to notice was the monitoring guy. And that system was IPL'ed on a regular basis (with the next one scheduled one or two days from that incident), so it was no biggie. I was really freaking out, though, until the others assured me that it was not a problem - "This is exactly why we don't let trainees on the production systems", as my supervisor put it.
Since that day, I only use fork() very, very cautiously. :)
https://isc.sans.edu/forums/diary/The+80s+called+They+Want+T...
With today's complex stack of multiple platforms in most enterprises, a good security researcher, IMHO, should be fluent with both worlds. Mainframes are where some of our most critical data is stored. When you pull up your account balance through your bank's website, there's a good chance that value was read off a mainframe.
Mainframers are old-school. They don't believe in public disclosure or open security models or public audits. If you go through the DEFCON and BlackHat archives, there's not much mainframe research out there. There's just a small community of mainframers on the Internet, but it's a significant part of the world's infrastructure. The mainframe world is a crazy alternate reality. (I know, because it's my day job.)
Phillip Young, the guy who owns this Tumblr project, has made some waves in this community. His talks are a great place to start. Here's a few resources to get you started:
[0]: http://mainframed767.tumblr.com/
[1]: http://bigendiansmalls.tumblr.com/
[2]: https://media.blackhat.com/us-13/US-13-Young-Mainframes-The-...
[3]: http://www.slideshare.net/bigendiansmalls/security-necromanc...
[4]: https://defcon.org/images/defcon-22/dc-22-presentations/Youn...
[5]: https://www.youtube.com/watch?v=Xfl4spvM5DI
[6]: https://www.youtube.com/watch?v=5Ra4Ehmifh4
Also, IBM.com has a wealth of documentation. (They have terrible SEO though.) Checkout the z/OS RedBooks and manauls there.
Up until a few years ago, there was no legal way to run z/OS on hardware that wasn't a million dollar hunk of iron from IBM. IBM has since made a product called Rational Developer and Test Suite [0] available. With it, you get an emulator and a licensed copy of z/OS that you can run on x86. Except it's $9,500 / year.
The only saving grace is an open source project called Hercules [1] which emulates the z/Architecture. If you don't mind breaking some copyright laws, there is no technical reason why you can't download a copy of z/OS and run it under Hercules. But good luck finding the latest version. Want to test your research against the latest maintenance levels? Good luck.
[0]: http://www-03.ibm.com/software/products/en/ratideveandtesten...
[1]: http://www.hercules-390.eu/
[2]: http://mainframed767.tumblr.com/post/40836059586/instruction...
So, it all adds up to a platform that should be very easy to smash and have literally decades worth of vulnerabilities built in. Should be some horrid design decisions in there, too, which might not be just a patch job. Mainframe hacking is literally a goldmine people should get into. Plus, those that prefer a boring, 8a-5p job with good pay and excellent job security will benefit from learning mainframe (or COBOL). Do the daily grind, play with shit on the test/dev partitions (LPARS?), and have fun hacking after work.
And you're right that the Redbooks are good. My only disagreement is that, if looking for mainframe, the SEO actually is too good in that all I get are Redbooks and IBM articles. That's when I'm looking for independent assessments of it. It's like Google wanted to drown me in their shit while I was actually looking for an independent assessment of Channel I/O, TCO, etc. Found some of it but it was work.
EDIT: Only thing that confused me was when the presentation said he bought a mainframe. How the hell did he buy a mainframe? I thought you had to be rolling in cash to even get an entry-level model with z/OS and z/VM. Re-edit, I found two answers to that question for people with some cash and who want to hack mainframes. See below:
http://www.informationweek.com/ibm-debuts-lower-cost-$75000-...?
http://www.eweek.com/servers/new-ibm-zenterprise-bc12-entry-... (Says you can get one as low as $1,965 a month. Bet it can't do shit but that's affordable.)
I suspect it has to do with the price tag. For Windows/Linux, I can just install the system on a random PC I have lying around, or at least buy a PC for very little money (in the grand scheme of things). With mainframes, few companies have one just standing around for you to tinker with. If IBM were willing to license z/OS (and their other mainframe OSes) to run on Hercules for such purposes, that might go a long way. But so far they seem to have no interest in that.
Casual exploration of the platform becomes very hard when a small mainframe is... what? $/€ 100,000?
And the complexity of the platform encourages specialization. (Try asking a competent Windows/Linux guy a mainframe question, they will probably give you a blank stare as well. FWIW, I am a Windows/Linux guy, too, I just was lucky enough to have a brief stint in a mainframe team during my training.)
Most of them seem to be interfaces to network switches.
$ telnet 212.221.26.7 23