Hi Skip, Believe this is what you mean - https://github.com/zedsec390/NJElib
The script that dose this is iNJEctor.py – Vignesh Mainframe Infrastructure -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Styles, Andy (ITS zPlatform Services) Sent: 23 March 2018 06:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Health Check JES_NJE_SECURITY This is a real possibility - I've seen it in action; a connection via NJE was established and an unauthenticated user was able to submit a batch job under the id of someone in the Security area with RACF SPECIAL access. At that time, our NJE network was using unsecured IP connections over port 175. Andy Styles z/Series System Programmer -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: 22 March 2018 23:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Health Check JES_NJE_SECURITY -- This email has reached the Bank via an external source -- I chatted up Tom Wasik at SHARE in Sacramento. We have a robust internal NJE network but no longer any outside connections. Tom raised the possibility of someone using a mechanism (like Python) to spoof an NJE node from within the closed network. I know nothing about Python, but just the prospect is unnerving. I think we'll pursue this (remote?) exposure to minimize the risk. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert S. Hansel (RSH) Sent: Friday, March 02, 2018 6:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Health Check JES_NJE_SECURITY Hi Skip, If you define &RACLNDE and add the name of a node to it, JES will 'trust' and accept any job coming from that node and propagate the submitter's ID and group as is. Adding a node to &RACLNDE is the equivalent of creating NODES profiles of node.USERJ.* UACC(UPDATE), node.GROUPJ.* UACC(READ), and node.SECLJ.* UACC(READ). Note that NODES profiles are ignored for nodes listed in &RACLNDE, so you can't do any submitting user or group translations using NODES profiles. &RACLNDE is very powerful, and nodes should only be defined to it that are under your control. If a job is received from an &RACLNDE trusted node, and on the receiving system (a) the submitting user isn't defined, (b) the submitter's group isn't defined, or (c) the submitting user isn't connected to the group, the submitter is treated as an undefined user and the job may fail. This is why, as Walt indicated, you should only define nodes to &RACLNDE whose RACF databases are aligned for users, groups, and connects. For systems that aren't so aligned, don't include their nodes in &RACLNDE and use NODES profiles instead. I recommend you define &RACLNDE in each of your RACF databases and in each such profile include only the nodes for the systems sharing that particular database. Do so even on standalone systems or Multi-Access Spool configurations. This will facilitate spool reloads. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. *** Celebrating our 25th Year *** 617-969-8211 www.linkedin.com/in/roberthansel https://twitter.com/RSH_RACF www.rshconsulting.com -------------------------------------------------------------------------------- Upcoming RSH RACF Training - WebEx - RACF Audit & Compliance Roadmap - SEPT 10-14, 2018 - RACF Level I Administration - APR 10-13, 2018 ** Date Change ** - RACF Level II Administration - JUN 4-8, 2018 - RACF Level III Admin, Audit, & Compliance - OCT 1-5, 2018 - RACF - Securing z/OS UNIX - APR 23-27, 2018 -------------------------------------------------------------------------------- -----Original Message----- Date: Wed, 28 Feb 2018 19:38:33 +0000 From: Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Health Check JES_NJE_SECURITY APAR OA49171 introduces a new health check called Date: Thu, 1 Mar 2018 03:14:36 +0000 From: Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: Health Check JES_NJE_SECURITY Ouch. I never saw Walt's proviso mentioned in the doc. Yes, these nodes are all totally under our control. However each node (sysplex) constitutes a different business environment supported by a different RACF data base. A person may have the same userid on sandbox and on production, but they do not necessarily have the same authority on both. Both represent the same person but not necessarily the same role. We need to reassess our goal here. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Wednesday, February 28, 2018 5:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Health Check JES_NJE_SECURITY On Wed, 28 Feb 2018 18:21:03 -0500, Tom Conley <pinnc...@rochester.rr.com> wrote: >I ran these on 1/5/18 to fix this check: > >RDEFINE RACFVARS &RACLNDE UACC(NONE) OWNER(<sysprog group>) RALTER >RACFVARS &RACLNDE ADDMEM(<your JES node>) (add one for each >node) >SETROPTS CLASSACT(RACFVARS) RACLIST(RACFVARS) You should be careful with that, Tom. &RACLNDE should only contain the names of nodes whose RACF databases are identical to each other, at least with respect to the users, groups, and user-group connections that are defined. Having a node listed in &RACLNDE will have a strong effect on security processing (mainly the propagation of submitter identity) for jobs submitted from that node to other nodes in your JES2 network. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0207 626 1500. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207 626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 0207 626 1500. Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM ________________________________ Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN