Hi Chris, You answers are just exectly what I was looking for. I RTFMed a little as well and have my ideas. For example, I looked into the USS TAB code and found that a I can force some input rules, ;like blocking LOG APPLID. I didn't respond as I am still learning your answer, BTW, I want to thanks all those who responded, I learened from all, even from those that delt with my wrong wording.
Many thanks, Itschak On Wed, Jan 14, 2009 at 7:01 PM, Chris Mason <[email protected]>wrote: > Itschak > > I see you are there and able to respond. Since we haven't heard a "Thanks > Chris that exactly meets my requirements." I must assume that my purely > VTAM solution using CDRM statement operands and CDRSC statements where > necessary didn't somehow answer your needs. I'd rather like to know why > since it's so straightforward. > > And, of course, I'm still trying to have you avoid any unnecessary expense! > > So let's try again from the beginning. > > > CICS of organization "A" is connected (LU6.2 Connection) to CICS of > organization "B". No problem with that. > > Translation: There is a CICSA-CICSB set of sessions. (being LU 6.2 it will > be a > set of sessions rather than a single session.). Whatever measures are taken > to prevent other sessions being established need to allow this set of > sessions > to be established. > > > I looked into the CDRM and found some other application (probably > plural "applications") of organization "B" defined in VTAMLST of > oranization "A". > > Translation: I browsed the CDRSC (CDRM was corrected in a following post to > CDRSC) major node VTAMLST member or members in the VTAMA VTAMLST > library and found other CDRSC statements presumably corresponding to other > applications, some of them other CICS applications. (The fact some were > other CICS applications is mentioned in a following post.) > > > Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the > default, I can travel in this CICS...). > > Translation: I succeeded in logging onto one or more CICS applications in > VTAMB, CICSB, CICSB1 ..., using the names I found in the CDRSC statements > and I was presented with the "Good Morning" messages. Assuming there is no > CICS-level security imposed, I can enter transactions in these CICS > applications. > > > I also riched TSO logon etc. > > Translation: I also succeeded in logging onto the TSO application in VTAMB, > TSOB, as far as the logon panel. And I succeeded in logging onto other > applications. > > > Now, I want to block (at) org "b" ability to get to org "a" applications > other > then the CICS connection that was agreed between Org "A" and "B". > > Translation: Having seen what I can do as a user associated with VTAMA in > accessing applications in VTAMB, I am concerned that a user associated with > VTAMB can access applications in VTAMA, the VTAM with which I am working. > I want to prevent a user associated with VTAMB accessing applications in > VTAMA. > > > Is this possible? > > Translation: None needed! > > Answer: Assuming you have the authority to change VTAM definitions, in the > VBUILD TYPE=CDRM member in VTAMA VTAMLST, change the VTAMB CDRM > statement to specify CDRSC=REQ and do *not* define any of the end-user > LUs associated with, "owned by", VTAMB as CDRSCs. That way none of the > VTAMB end-users can initiate a session with any of the VTAMA applications - > exactly what I think you want to achieve. In order still to be able to set > up > the CICSA-CICSB sessions, you will need to define a CDRSC in VTAMA for > CICSB as CICSB CDRSC CDRM=VTAMB within a VBUILD TYPE=CDRSC member. > Hitherto, I expect this CDRSC will have been defined dynamically because > you > specified CDRSC=OPT for VTAMB and CDRDYN=YES is in effect for your local > CDRM. > > Walt, these are not just pointers, this is chapter and verse! > > To continue: > > > I also want to block the ability to enter logon applid command (may be by > userid, even of the solution will require entering userid & password). How > to > achive that? > > Answer: Presumably you are talking about blocking the use of LOGON APPLID > (xxx) at VTAMB for the VTAMA applications. When stated like that, this is > clearly undesirable since it would prevent end-users in VTAMB accessing > applications in VTAMB! Also, unless that "trick" of using SSCPFM=FSS works > and that value can be applied to the VTAM definition, there is no way > actually > to prevent the use of the default USS LOGON and LOGOFF commands. > > If the end-users in VTAMB access SNA by means of a TN3270 server, then > use of RESTRICTAPPL can impose use of a userid and password as described in > the Communications Server IP Configuration Guide. > > > What other alternatives are offered to connect to vtam applications when > USS tab is displaied, other then LOG APPLID and selecting from the uss tab? > I > mean, is there any bypass to LOG APPLID if blocked? > > Translation: What other alternatives are offered to connect to VTAM > applications when USS message 10 is displayed other then LOGON APPLID(xxx) > *or* selecting from LOGON command aliases defined in the USS table? I mean, > is there any bypass to LOGON APPLID(xxx) if blocked? > > Answer: Use of the interpret table can, in effect, bypass the use of > commands defined in the USS table. > > The usual alternative to use of USS LOGON commands in order to initiate > sessions from end-user LUs is to use a session manager with which a session > is established by means of a LOGAPPL operand on the LU (or LOCAL) > statement definition. > > - > > > Now, there is no way to stop some one in org "A" to simply logon to org > "B" > CICS. > > Answer: Oh yes there is - see above. > > > Believe me, I tried it and accessed many vtam applications. few of them > where no protected well. Some of them uses default ACB names. the ability > to > finally logon into is depend on the level of security implemented at org > "B". In > many cases I tested, it was not a problem to enter in. I am sure I can do > it > with some success at any site. There are always holes in security. > > Translation: Believe me, I tried it and accessed many VTAM applications. A > few of them were not well protected. Some of them use default ACB names, > that is, the names in the installation samples. The ability to logon to the > application is dependent on the level of security implemented at org "B". > In > many cases I tested, it was not a problem to enter into the application. I > am > sure I can do it with some success at any site. There are always holes in > security. > > Question: Are your organisations A and B using different network > identifiers? If > so that would explain how you were able to log onto applications which had > not had the default APPL names changed. > > Response: You will not be able to get near the application if you adopt the > CDRM definition operand values I mentioned. However, as the VTAM > administrator at VTAMA and with no influence over the VTAM definitions in > VTAMB, there is unavoidably one application logon you cannot block: that of > end-users in VTAMA accessing - via the USS LOGON command - CICSB, the > CICS for which you were obliged to define a CDRSC. In order to cover that > you will be obliged to persuade the VTAM administrator at VTAMB to specify > CDRSC=REQ on the CDRM statement for VTAMA and to create a CDRSC > statement for CICSA. > > > Now that I found the door, I am looking to see how to limit Access from A > to > B by LU 6.2 from CICS and not from any terminal at "A". > > Translation: Now that I have found the door, I am looking to see how to > allow > access from A to B by means of the LU 6.2 connection from CICSA to CICSB > but to forbid access from A to B by direct logon using the USS LOGON > command from an end-user in VTAMA. > > > I think that the two organization agrred to connect their CICS systems on > a > limited services. Not to open a door to any terminal and to any vtam > application. Assume that LOG APPL will accept netname.applid as P1... > > Translation: I believe that the two organizations want to connect their > CICS > systems for limited functions. I believe that they do not want to allow any > end-user LU to logon to any application LU where the USS command is of the > form LOGON APPLID(netname.applid). > > - > > Am I getting closer? > > Chris Mason > > On Wed, 14 Jan 2009 16:51:31 +0200, Itschak Mugzach > <[email protected]> wrote: > > >Walt, I might used worng wording, but when I said LOGON to CICS (or any > >other VTAM application on partner sight, I ment it. The only limit I > >have when Pentesting is the partner company to agree for the signon. > >I have seen few sites using no GMTRAN at all, so you signon to CICS with > no > >password and get the default user auth! There are also few other VTAM > >applications that uses internal userid and passowrd that is stored in a > >file. NDM is a sumple for super user that is described in a parameter > >library. > > > >ITschak > > > >On Wed, Jan 14, 2009 at 4:42 PM, Walt Farrell <[email protected]> > wrote: > > > >> In response to a Wed, 14 Jan 2009 08:00:36 +0200 message from Itschak > >> Mugzach <[email protected]>: > >> > >> You seem to be mixing terminology, and possibly causing confusion, > Itschak. > >> (Though I think Chris understands what you've said and has provided > some > >> good pointers.) > >> > >> You start out by saying > >> > Now, there is no way to stop some one in org "A" to simply logon to > org > >> "B" > >> > CICS. > >> > >> Logging on to CICS is controlled by the user ID and password provided > >> during > >> the CICS signon processing. > >> > >> You go on to say: > >> >Believe me, I tried it and accessed many vtam applications. few of > >> >them where no protected well. Some of them uses default ACB names. the > >> >ability to finally logon into is depend on the level of security > >> implemented > >> >at org "B". > >> > >> What you're talking about there is NOT "logging on to CICS" but > connecting > >> to org B's system, via VTAM, and logging on to other VTAM applications > they > >> have, not CICS. > >> > >> I'm not disputing that you were able to do that, but I feel it's > important > >> to properly express what has happened and thus, perhaps, avoid > confusion. > >> > >> And yes, the ability to logon to B's applications, if you can reach B > via > >> an > >> LU2 connection, is dependent on the security implemented at B and in its > >> applications. > >> > >> -- > >> Walt Farrell, CISSP > >> IBM STSM, z/OS Security Design > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
