Jim FUD!
There's quite a lot needs straightening out here! 1. It is very much in general inappropriate to associate "security" with only with VTAM. It is very likely to be more appropriate to use the term "SNA security". 2. If we are talking about "long ago", with respect to security at the session level as opposed to connections, there has been session encryption support since the dawn of SNA. With the development of LU 6.2, the usual userid and password security has been architected with a variety of levels of flexibility/exposure to apply at the level of the conversation/transaction. In addition, there are a variety of RACF definitions associated with potentially tight control of the VTAM APPC API. 3. If we are talking about security at the level of connections as opposed to sessions, then you have a point that the leased SNA line between subarea nodes was considered not to need security protocols to be imposed upon it. >From the time that switched support was introduced for subarea connections, a protocol was introduced - also within NCP - in order to assure that both sides of the connection knew a key value which did *not* pass over the link and could not be "sniffed". Note that, for SNI, which is, of course, a major concern - perhaps the *only* real concern as far as this post is concerned, the types of connections are subarea connections. No such security protocol exists for switched peripheral connections so I guess you could regard that as some sort of exposure although, in principle, peripheral connections operate within the control of one SNA subnetwork. 4. I take your point that SNA expertise is on the decline. It becomes evident from the following sentence that, by "attempt it", you mean to *apply* security to an SNA environment. Furthermore, you seem to be concerned particularly about session establishment within an SNI environment. Initially I thought that, by "attempt it", you might mean *break into* an SNA environment! 5. The VTAM Session Management Exit (SME) is fully documented in the Communications Server SNA Customization manual - even in the last year or two actually made available on IBM web pages. By scanning the control blocks, it is very easy to see what information is available to the SME and hence what can be formatted for presentation. As an aid to VTAM education, I wrote an extensive set of VTAM exits long ago which universally simply presented the information available to the exits on the system log. The SME was one of these but admittedly the biggest by far. I really can't see that you need have been surprised by what information an SME implementation could present you. You needed only a little research of the manual! I can't see what "scared you silly". Just having some familiarity with the content of the SNA requests used in session setup within an SNI environment would indicate what information was freely available to anyone succeeding in "tapping the line", a major subset of which is made available to the SME. 6. Jumping into an existing session is very unhelpful about the session endpoints, the identity of typically the two LUs involved - unless it's the transaction traffic you are after. If indeed, it is the latter and you are worried about "tapping into" the traffic, you should use the session encryption to which I have already referred. 7. You make a reference to session types - although I can't understand how you can equate "SNI" and "LU6/0/1/2", they have orthogonal significance: SNI provides the ability to transport a session of any type over subarea connections between subnetworks having different network identifiers (NetIDs). SNI and session types are not somehow mutually exclusive. This looks like some manifestation of the path to "extinct expertise"! On the other hand this may be some sort of shorthand within the customization of the particular "firewall" product you have in mind. Is there any reason why you haven't stated what it is? 8. Your point about company X with NetID X supporting companies A and B with NetIDs A and B is presumably that company A can "see" the session setup attempts with NetID B and vice versa. It is an awareness of definition facilities similar to those which the OP had forgotten about - if he ever knew them - which can be used to prevent "leakage" of "cross-domain initiate" (CDINIT) requests into inappropriate subnetworks. Again it looks like a case of the flexible approach involving least effort having become the one everyone uses to the extent that everyone has forgotten about the more troublesome to define but more restrictive approach - if it is not a case of the person who did know having been "let go". Note that, when company X was IBM, the folk in charge of the SNI configuration would have understood - because I used to teach a major subset of them! - the problem of irrelevant CDINIT traffic and I would have expected they made sure that attached customer networks were protected from "seeing" this traffic. In addition to what can be "seen" in inappropriate CDINIT requests, there is another similar problem with NetView Session Monitor (NLDM). Again, by actually imposing restrictions through definitions, it is possible to limit the extent to which NLDM uses can "see" attached subnetworks. 9. I don't know what sort of SNA "firewall" this is but I find it amazing that it intervenes only when the BIND request flows! There is actually one class of session setups which would indeed require that any check could be performed only when the BIND request flows. This is a pure "Low Entry Networking" (LEN) session and it is unusual - with a vanishingly small likelihood that LEN is used between different subnetworks belonging to different organisations. The request which first identifies a session setup request and which contains all the details which might be needed for authorisation is the CDINIT, there being different flavours for subarea of APPN. 10. I can see that a product which "sniffs" the BIND could comment on the parameters. It might query small request unit sizes, low pacing values or the imposition of definite responses, all of which could inhibit performance when the nature of the application is such that different choices might be more or equally suitable. Much the cleverer approach is to think about these choices when an application is installed - usually with a miserable level of support from application product documentation - rather than being prompted after the event by "suggestions" from a "firewall" product. Note however, that pacing can be less of a concern these days when adaptive pacing can be used in order to avoid the restrictions of fixed pacing. 11. Unless you have other aspects of SNA in mind, it would appear your "99% +" applies to SNI configurations. This, after all, corresponds to the IP configurations where "firewalls" are considered to be required. I would be interested to know what it is about SNI configuration definition that might in addition need protection through the agency of some sort of "firewall". It became clear that the OP of this thread was unaware of the definitions which could be used to impose the restrictions he needed to impose. I suspect that, if your "99%+" is right, it refers to similar ignorance of the limitations which can be imposed using SNI-related definitions. 12. There is a fundamental set of differences between SNA and IP and the protocols built upon it that means it is not really sensible to regard them in the same light. This leads to the false assumption that, given the perceived vital need for a "firewall" function with IP, this must obviously imply that there is a vital need for a "firewall" function in SNA. It is rather comic that the SNA implementation in VTAM can so long have suffered from initially deserved accusations of a lack of flexibility requiring extensive definition activity - with the reverse implication that whatever you wanted to do needed specific definition - and hence suffering unflattering comparison with the free and easy world of IP protocols, and, now that the "firewall" has compensated for the excessive freedom of IP protocols, it is considered vital that SNA networks need some sort of "firewall". How short some memories are! Or is this yet another manifestation of folk memory having been lost because those who would have remembered have been "let go" and those who supposedly took their place just haven't had the education in depth which harks back to the "bad old days" when you couldn't move in SNA terms without filing a definition - usually two - of some sort! It appears to me that, when you understand what you are doing, whatever level of security you desire can be imposed genuinely - that is, there need be no "falseness" at all! Chris Mason On Sat, 17 Jan 2009 20:06:38 -0600, Jim Marshall <[email protected]> wrote: >>CICS of organization "A" is connected (LU6.2 Connection) to CICS of >>organization "B". No problem with that. I looked into the CDRM and found >>some other application of organization "B" defined in VTAMLST of oranization >>"A". Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the >>default, I can travel in this CICS...). I also riched TSO logon etc. >> >>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". Is >>this possible? >>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? >>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? >> >In general, VTAM security has never been implemented because long ago >when it started everyone thought SNA Pt-to-Pt lines provided it all. Today >almost all the SNA expertise to even attempt it is extinct, education is even >lacking. But even for those who have done it, it is only a false sense of >security. > >Back a few years there was a free VTAM SME exit offered to show you what >was coming into your VTAM network from SNI connections. Installed it on the >fly and ran it for 2 hours believing little would show; Wrong-O smart one. It >scared us silly. Especially with Hercules and MVS 3.8 VTAM which works today >and can be on the other end, or jumps into the middle of a real connection, it >is truely frightful. > >So there are companies which offer a SNA Firewall (installs dynamically) to >truely secure the VTAM SNI connections and lets us sleep sound at night. It is >imperative the one chosen handles not only SNI but LU6/0/1/2, etc. Another >benefit is when you are connected to Company A and also Company B. If they >find out about each other, then A can connect to B using your network saving >each the expense of making a separate connection. With the Firewall one has >the ability to look at the BIND and even for connections which are approved, >it can see the parameters coded and let you know if they are inefficient >(working fine but eating your lunch). Yes, no one would ever run their TCP/IP >systems without a Firewall, except I am guessing 99%+ of those who have >SNA, it never even occurs to them they are highly exposed. > >jim > >---------------------------------------------------------------------- >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
