PCI and Auditors perceptions thereof
Hal Merritt
Many seem to be saying that all FTP traffic has to be encrypted to meet PCI standards. And yet I cannot find any such statement in the PCI standards. But I did find a requirement for firewall packet inspection which, I am told, is impossible if the traffic is encrypted. Did I read that right?
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Rob Schramm
Try 1.1.5, 2.2.2 and 6.5.9 PCI DSS Requirement coupled with
http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security
Most of the PCI stuff is done generally to allow for as much as possible
instead of documenting each specific protocol and remediation. Although
if you have engaged a PCI Qualified Security Assessor .. they should be
able to point to everything the PCI folks care about.
-Rob Schramm
Sirius Computer Solutions
Scott
You can, with FTPS, open up the control channel so the Firewall can monitor
the control connection (port 21), which lets it dynamically assign ports
that the server/client negotiate for the data connection (aka port 20).
SFTP (SSH) is entirely encrypted and cannot have its activity monitored.
Scott
Donald Russell
then it broke.
Apparently somebody (re)configured a firewall so it now stops the AUTH
TLS portion of the negotiation or something.... the symptom is the
authentication negotiation fails... I'm told it's because the firewall
mangles the digital certificate.
SFTP works fine using USS... but I don't have USS on all the MVS
systems I need to send data from...
Is there a way to run SFTP (FTP/SSH) from MVS without USS?
(If I can do that, I can avoid tracking down the firewall people to
get the FTP/TLS thing working.... I PREFER to use SFTP, but FTPS is
acceptable... and I want the process to be the same on all the MVS
systems, not sftp here, ftps there...)
Cheers
Scott
through the issues, as there's a few solutions/workarounds for you to try.
I've worked through our own firewall issue and even some instances where two
firewalls were at play. It's not mangling the Digital Certificate. Rather,
it cannot monitor the control channel and the client/server connection drops
after negotiation.
Scott
Donald Russell
prog. I developed a TSO clist (REXX) that runs as a batch process
(PGM=IKJEFT1A) to send files to a zLinux system. It was all working
fine, I saw the messages about "successful negotiation", and the
transfer continued successfully.
A few weeks ago, that changed... now I get "negotiation failed", and
the "required" authentication causes FTP to exit.
(At first I thought my cert had expired... I went through all that...)
In reporting this to our MVS people, they did a trace and determined
the cause to be a firewall issue. They say the cert is being
mangled... you say it's due to not being able to monitor the control
channel.
FTP fails with "TLS negotion Failed".
Now that the holidays are past, I hope to get to the correct people to
find out when things changed. As I mentioned, this was working fine at
one point.
I'm told the firewall has to be specifically configured for FTP/SSL...
and those requests were never done... (So, why did it ever work? hmmm)
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Donald Russell
> Sent: Monday, January 04, 2010 4:54 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: PCI and Auditors perceptions thereof
>
> Until recently, I was using FTPS to send data from MVS to zLinux....
> then it broke.
> Apparently somebody (re)configured a firewall so it now stops the AUTH
> TLS portion of the negotiation or something.... the symptom is the
> authentication negotiation fails... I'm told it's because the firewall
> mangles the digital certificate.
>
> SFTP works fine using USS... but I don't have USS on all the MVS
> systems I need to send data from...
>
> Is there a way to run SFTP (FTP/SSH) from MVS without USS?
>
> (If I can do that, I can avoid tracking down the firewall people to
> get the FTP/TLS thing working.... I PREFER to use SFTP, but FTPS is
> acceptable... and I want the process to be the same on all the MVS
> systems, not sftp here, ftps there...)
>
> Cheers
>
Try Dovetailed Technology's sftp. ref: http://dovetail.com/products/sftp.html
It costs $0.00 with no support. You can purchase support, if you want.
Of course, I don't know how you could run z/OS today without UNIX System Services. If you run IBM's TCP stack, you run UNIX System Services.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Hal Merritt
Only TLS/SSL is mentioned in the PCI DSS (albeit in a context applicable only to PAN's, not data in general).
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Scott
Sent: Monday, January 04, 2010 3:50 PM
To: IBM-...@bama.ua.edu
Subject: Re: PCI and Auditors perceptions thereof
Packet inspection? Weird.
You can, with FTPS, open up the control channel so the Firewall can monitor
the control connection (port 21), which lets it dynamically assign ports
that the server/client negotiate for the data connection (aka port 20).
SFTP (SSH) is entirely encrypted and cannot have its activity monitored.
Scott
On Mon, Jan 4, 2010 at 1:01 PM, Hal Merritt <HMer...@jackhenry.com> wrote:
> Trying to do some due diligence in planning some data transfers and getting
> really confused.
>
> Many seem to be saying that all FTP traffic has to be encrypted to meet PCI
> standards. And yet I cannot find any such statement in the PCI standards.
> But I did find a requirement for firewall packet inspection which, I am
> told, is impossible if the traffic is encrypted. Did I read that right?
>
>
----------------------------------------------------------------------
Scott
Is your z/OS system the client or the server? There's a few approaches to
take...
1.) In the "SYSFTPD" configuration, ensure that a line specifies:
"TLSRFCLEVEL CCCNONOTIFY"
http://www-01.ibm.com/support/docview.wss?uid=isg1PK67193
2.) You may also try enabling EPSV4 in the "SYSFTPD" configuration:
"EPSV4 true"
3.) If neither of the above work, ask the network administrators to open up
ports 1024 and above or, if they complain about it, a range of ports. In
the configuration for the ftpd server on whichever end, enter that port
range so the server will always allow those to pass through.
Did they change the networking hardware? Or did they just make some
arbitrary decision that they were going to "harden" things up?
Scott
Scott
pins, yadda). I should really take the time to read the PCI-DSS, but I have
the attention span of a newborn puppy. The only requirement is really for
"strong cryptography" which, in the context of PKI, is 1024 bit or greater.
Mostly I think these standards are written in a way that is just vague
enough to make my life a living hell. I really wish "when in doubt,
encrypt" would be codified in everything so I could recover a measurable
portion of my lifespan from all the meetings.
Generally, I really like TLS. However, FTPS is (by far) the worst mechanism
to come out of the last decade. If you don't care about providing your own
certificate, it's pretty simple. But when you depend on FTP+TLS, life
becomes miserable because it's neither trivial nor commonplace.
</Rant>
Yours,
Scott
Jerry Whitteridge
As both FTP and Telnet send credentials in clear their protocols have to be encrypted to satisfy 2) thereby requiring ALL FTP and Telnet to be encrypted. (Or at least that has been how our varying QSA's have explained it to me).
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Scott
> Sent: Tuesday, January 05, 2010 9:48 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: PCI and Auditors perceptions thereof
>
> Well, it makes sense to me that it specifies PAN data (and
> probably CVV2, pins, yadda). I should really take the time
> to read the PCI-DSS, but I have the attention span of a
> newborn puppy. The only requirement is really for "strong
> cryptography" which, in the context of PKI, is 1024 bit or greater.
>
> Mostly I think these standards are written in a way that is
> just vague enough to make my life a living hell. I really
> wish "when in doubt, encrypt" would be codified in everything
> so I could recover a measurable portion of my lifespan from
> all the meetings.
>
> Generally, I really like TLS. However, FTPS is (by far) the
> worst mechanism to come out of the last decade. If you don't
> care about providing your own certificate, it's pretty
> simple. But when you depend on FTP+TLS, life becomes
> miserable because it's neither trivial nor commonplace.
>
> </Rant>
>
> Yours,
> Scott
"Email Firewall" made the following annotations.
------------------------------------------------------------------------------
Warning:
All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately.
==============================================================================
Scott
"STARTTLS" command (or some such). You then perform your handshake over an
encrypted channel.
FTP requires the use of ports 20 (data) and 21 (control). Though, in
practice, 21 is the important port as the one used for data is often
negotiated to something above 1024, as well as the new port used by the
control channel.
From that point, you may issue commands to increase or decrease the level of
encryption as you see fit. If you experience firewall issues, you often
need to have your control channel transmit "in the clear" so your firewall
can observe it and dynamically open ports on demand.
You may also drop out of encryption for the data channel, which will
increase the speed of transmission and reduce the load on your CPU. The
unfortunate side effect, however, is that I will kill you in your sleep for
doing that.
I haven't bothered to look into the TELNET side of things because I only use
it for 3270 and within our private network.
- Scott
Hal Merritt
But Wait! There's More! PCI DSS also requires NAT'ing. To do that, the firewall has to inspect the data packet. Now what?
Another question: does anyone know the PCI DSS definition of an '..open, public network" ? The context seems to be a web server connected to the Internet, so a private, local network should not qualify. Thoughts?
Curious that TN3270 does not seem to present these issues. Could it be that FTP's use of two ports/channels vs TN3270's one may be its saving grace?
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Scott
Sent: Tuesday, January 05, 2010 12:09 PM
To: IBM-...@bama.ua.edu
Subject: Re: PCI and Auditors perceptions thereof
The way FTPS (FTP+TLS) works is that you connect on port 21, issuing the
"STARTTLS" command (or some such). You then perform your handshake over an
encrypted channel.
FTP requires the use of ports 20 (data) and 21 (control). Though, in
practice, 21 is the important port as the one used for data is often
negotiated to something above 1024, as well as the new port used by the
control channel.
From that point, you may issue commands to increase or decrease the level of
encryption as you see fit. If you experience firewall issues, you often
need to have your control channel transmit "in the clear" so your firewall
can observe it and dynamically open ports on demand.
You may also drop out of encryption for the data channel, which will
increase the speed of transmission and reduce the load on your CPU. The
unfortunate side effect, however, is that I will kill you in your sleep for
doing that.
I haven't bothered to look into the TELNET side of things because I only use
it for 3270 and within our private network.
- Scott
NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
----------------------------------------------------------------------
Scott
without encryption. Generally, you perform whatever authentication and then
you drop the control channel into the clear, if the firewall demands it.
It's not really a risk, as the only thing someone can see are your "PUT/GET
<file>" commands. That's only a risk if you're dumb enough to name a file
after an account number (for example). If you do an "LS" command, the
directory contents are actually sent over the data channel.
It turns out that the FTP control channel is really just a telnet session:
http://en.kioskea.net/contents/internet/ftp.php3
That's a pretty easy to understand reference on regular FTP.
The encryption has no effect on NAT. NAT simply operates on the IP packet's
header.
IP diagram/explanation: http://www.freesoft.org/CIE/Course/Section3/7.htm
NAT really just swaps out the source IP address from your computer's
private, internal IP to the NAT hosts externally routable IP address. Once
it receives the IP packet from the outside world, it then inserts your
private IP address into the "destination" field and sends it back.
I'm horrible at explaining things.
TN3270 does not have this issue because it does not have to worry about two
separate port assignments. Telnet uses port 23. You connect to the server
on port 23, the server says "let's use port XYZ instead!" and the firewall
opens that up. Then you establish encryption and perform authentication
(etc).
This is also how it happens on FTP. You say "Hi!" on port 21 and then you
and the server free up port 21 for others to use. Authentication and other
things happen somewhere above port 1024.
The problem for FTP is that you establish the data channel after the control
channel has, itself, been established. Many firewalls listen to the control
channel and open up a port for your data channel. This is why FTPS is such
a nightmare.
SFTP is different. An SSH tunnel is established and, within that tunnel, a
proprietary file-transfer mechanism is used. There's no real way to tell if
FTP is happening within that SSH tunnel, or HTTP, etc.
Scott
Kirk Wolf
> <snip>
> SFTP is different. �An SSH tunnel is established and, within that tunnel, a
> proprietary file-transfer mechanism is used. �There's no real way to tell if
> FTP is happening within that SSH tunnel, or HTTP, etc.
> Scott
>
Scott -
I don't think that you actually meant *proprietary*....
It is of course very different from FTP and uses an open packet
protocol within the SSH tunnel, rather than a telnet-sh command
language like FTP.
see http://en.wikipedia.org/wiki/SSH_file_transfer_protocol
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
PS: Links to the slides or a recording of our recent Webinar "Using
SFTP on the z/OS Platform" can be found on our homepage above, and
contains more information on SSH/SFTP vs FTP.
Scott
annoyed that sftp had to be called "sftp"? It makes explanations that much
more painful. :(
Scott
Donald Russell
have USS (OMVS) access on one of them. I'm told USS is not available on the
others. Maybe there's some terminology issues...
What I'd like to do is invoke sftp from a rexx clist... right now I "address
mvs FTP ..." trying to use FTPS.
If I can do something similar but invoked SFTP, and that works on all my MVS
systems, I'm a happy camper. :-)
(The reason I do this from a clist is because some logic there determines
what the remote name should be, and whether an additional file should also
be transferred)
Where can I read about invoking sftp as a batch process?
Cheers,
On Tue, Jan 5, 2010 at 06:00, McKown, John <John....@healthmarkets.com>wrote:
>
>
> Of course, I don't know how you could run z/OS today without UNIX System
> Services. If you run IBM's TCP stack, you run UNIX System Services.
>
>
----------------------------------------------------------------------
P S
> Is USS the same thing as "OMVS"? We have multiple MVS systems but I only
> have USS (OMVS) access on one of them. I'm told USS is not available on the
> others. Maybe there's some terminology issues...
>
Indeed. If you're running something IBM-supported, USS is there. That
doesn't mean your ID is enabled to use it, however -- but that's an internal
issue.
Does this help?
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Donald Russell
> Sent: Tuesday, January 05, 2010 5:05 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: PCI and Auditors perceptions thereof
>
> but I only
> have USS (OMVS) access on one of them. I'm told USS is not
> available on the
> others. Maybe there's some terminology issues...
>
> What I'd like to do is invoke sftp from a rexx clist... right
> now I "address
> mvs FTP ..." trying to use FTPS.
> If I can do something similar but invoked SFTP, and that
> works on all my MVS
> systems, I'm a happy camper. :-)
>
> (The reason I do this from a clist is because some logic
> there determines
> what the remote name should be, and whether an additional
> file should also
> be transferred)
>
> Where can I read about invoking sftp as a batch process?
>
> Cheers,
Many people use USS to mean "z/OS UNIX System Services". It is an unapproved acronym.
Why not use BPXWUNIX to run a UNIX command in REXX?
/* REXX */
RC=SYSCALLS('ON')
SAY RC
stdin.0=0
stdout.0=0
stderr.0=0
call bpxwunix 'ls -l',,stdout.
DO I=1 TO STDOUT.0
SAY STDOUT.I
END
In your case, put the sftp command in the stdin. variables. I don't know them myself, but something like:
stdin.1='first command'
stdin.2='second command'
stdin.3='some other command with operands'
stdin.4='last command'
stdin.0=4
call bpxwunix 'sftp ..options..',stdin.,stdout.,stderr.
DO I=1 TO STDOUT.0
SAY STDOUT.I
END
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Donald Russell
> On Tue, Jan 5, 2010 at 6:05 PM, Donald Russell <russe...@gmail.com
> >wrote:
>
> > Is USS the same thing as "OMVS"? We have multiple MVS systems but I only
> > have USS (OMVS) access on one of them. I'm told USS is not available on
> the
> > others. Maybe there's some terminology issues...
> >
>
> Indeed. If you're running something IBM-supported, USS is there. That
> doesn't mean your ID is enabled to use it, however -- but that's an
> internal
> issue.
>
> Does this help?
>
>
Yes, but I think that means I won't be able to use sftp on those "other" MVS
systems to which I don't have OMVS permission.
That means I'm back to using FTPS, and getting the firewall issue resolved.
Oh well, that seems to be in the works now...
Thanks,
Kirk Wolf
Here's an example of running a shell script in-line in a batch z/OS
job which invokes sftp:
http://dovetail.com/docs/sftp/client.html#client-batch
I know that we have some users that also use REXX, but a Unix shell
script might work as well for your requirements.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Kirk Wolf
RE: USS requirement for SFTP
You can use IBM's sftp or our free Co:Z sftp if the z/OS userid has a
valid OMVS segment. That's likely what is missing when you say
that "USS is not enabled", since z/OS has required USS for TCP/IP
support for a long time.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
----------------------------------------------------------------------
Donald Russell
Yes, that's what I'm looking for... a way to run sftp from a clist (I still
call them clists even though they're written in rexx these days. Just like I
still call them EXECs on VM...)
Thanks.
Ted MacNEIL
So, we don't work for IBM.
Meaning we don't need their approval.
Plus, a lot of IBM'r's in Canada use it.
So, instead of being pedantic, why not help the OP?
Especially, since you know what their talking about?
Approved or not, it's become common usage.
-
Too busy driving to stop for gas!
Paul Gilmartin
>> >
>> > RE: USS requirement for SFTP
>> >
>> learned: It's not that OMVS isn't there, it's just we don't grant access to
>> it regularly except on one of our MVS systems. I wonder why that is.... I'm
>> guessing it's money. :-)
>>
Too many four-letter words. It's not the way we did things
30 years ago. Can't demonstrate "need to know". Don't
want users to be smarter than administrators. Yadda yadda...
>
>Not money (I know you're kidding). Possibly it is because of user's home
>directories. If your systems are not in a sysplex, there is no way to
>
We share outside sysplex with NFS. But we don't use the newer
sharing mechanisms even within sysplex because that's not the
way we did it before they were available. Sound familiar?
>share them. If you are in a sysplex, perhaps your sysprogs don't want to
>bother setting up the facility to share them. In either case, a normal
>user would like complain like a graft-less politician about not being
>able to share.
>
-- gil
Peter Vander Woude
If your firewall folks just recently upgraded the firewall, it could be that the
upgrade "defaulted", or reset some configuration settings. For FTPS, the
firewall cannot do what's referred to as "stateful checking". I know ours does
that, and if it does that on the control connection (and/or data connection),
you will see the error you've been getting.
On another note, someone mentioned earlier in the thread about PCI-DSS
and it's requirements for NATing, but also asked about what PCI-DSS means
by "public network". PCI-DSS uses that term to indicate any network where
someone from outside your company might gain access to your internal
network, and be able access the credit/debit card information, as in the case
of a company setting up a wireless network. In the wireless network example,
that initially means setting up firewalls between that wireless router and the
systems that process the credti/debit transactions.
Also, I believe someone mentioned that PCI-DSS requires that the credit card
information (i.e. PAN) be encrypted inflight. Unless I'm mistaken, PCI-DSS only
deals with data at rest (i.e. in databases, or flat files). Encryption of this data
inflight is not part of the PCI-DSS standard, yet. If it were, then some of the
breaches in recent time, where transactions were caught inflight, even while a
company may have passed a PCI audit, should not have happened. If PCI-
DSS does require the PAN to be encrypted, it would also have to require that
the track-2 data also be encrypted.
Peter
Donald Russell
> Don,
>
> If your firewall folks just recently upgraded the firewall, it could be
> that the
> upgrade "defaulted", or reset some configuration settings. For FTPS, the
> firewall cannot do what's referred to as "stateful checking". I know ours
> does
> that, and if it does that on the control connection (and/or data
> connection),
> you will see the error you've been getting.
>
>
That appears to be what happened.... I'll know for sure next week when the
firewall people make the change to allow FTPS.
For me, the red herring was that regular FTP works fine, which, to me, begs
the question: What's the point of blocking FTPS without blocking FTP?
Thanks for all the discussion and feedback...
Shmuel Metz , Seymour J.
01/05/2010
at 05:57 PM, "McKown, John" <John....@HEALTHMARKETS.COM> said:
>Why not use BPXWUNIX to run a UNIX command in REXX?
That should work if he has an OMVS segement; my best guess is that he only
has it on one of his systems.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
01/05/2010
at 03:05 PM, Donald Russell <russe...@GMAIL.COM> said:
>Is USS the same thing as "OMVS"?
Officially USS is Unformatted System Services, but many people
unofficially misuse the acronym to refer to Unix System Services. There's
also a distinction between using Unix System Services and logging on to
the Unix System Services shell.
The acronym OMVS is a bit confusing because it refers both to Unix System
Services and to a specific address space.
>I'm told USS is not available on the others.
These days a lot of MVS software depends on Unix System Services, so I
suspect that what they mean is that you can't telnet to a Unix System
Services shell on those systems. However, they might mean that the
security data base doesn't have OMVS segments for normal users except on
one system.
>What I'd like to do is invoke sftp from a rexx clist
Rexx and CLIST are completely different animals.
In <d9d0c4681001051612v6e7...@mail.gmail.com>, on
01/05/2010
at 04:12 PM, Donald Russell <russe...@GMAIL.COM> said:
>It's not that OMVS isn't there, it's just we don't grant access to it
>regularly except on one of our MVS systems. I wonder why that is....
>I'm guessing it's money. :-)
There's no charge for enabling access to Unix System Services; my guess is
that they're not configured to share Unix file systems and don't want to
allocate separate home directories for each system.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Paul Gilmartin
>
>>What I'd like to do is invoke sftp from a rexx clist
>
>Rexx and CLIST are completely different animals.
>
SYSPROC library. Magic Numbers.
-- gil
Donald Russell
shmuel+...@patriot.net <shmuel%2Bibm...@patriot.net>> wrote:
> In <d9d0c4681001051505w592...@mail.gmail.com>, on
> 01/05/2010
> at 03:05 PM, Donald Russell <russe...@GMAIL.COM> said:
>
> >Is USS the same thing as "OMVS"?
>
> Officially USS is Unformatted System Services, but many people
> unofficially misuse the acronym to refer to Unix System Services. There's
> also a distinction between using Unix System Services and logging on to
> the Unix System Services shell.
>
> The acronym OMVS is a bit confusing because it refers both to Unix System
> Services and to a specific address space.
>
> >I'm told USS is not available on the others.
>
> These days a lot of MVS software depends on Unix System Services, so I
> suspect that what they mean is that you can't telnet to a Unix System
> Services shell on those systems. However, they might mean that the
> security data base doesn't have OMVS segments for normal users except on
> one system.
>
> >What I'd like to do is invoke sftp from a rexx clist
>
> Rexx and CLIST are completely different animals.
>
The idea I was trying to convey is I wanted to invoke an sftp file transfer
from a program invoked as if it were a TSO command. I figured everybody is
familiar with "clist" as a concept, rather than a specific language, and I
specified REXX because I don't write clist language code any more.
Which is the correct noun to refer to a program, read from SYSEXEC in a TSO
address space? In TSO land I generally refer to them as "clists" though
they're written in REXX. In VM/CMS land I call them "EXECs" even though they
are written in REXX, or EXEC 2 or EXEC. On zLinux I call them "scripts" or
"shell scripts" even though they may be written in REXX, php, bash shell,
korn shell, etc...
>
>
> In <d9d0c4681001051612v6e7...@mail.gmail.com>, on
> 01/05/2010
> at 04:12 PM, Donald Russell <russe...@GMAIL.COM> said:
>
> >It's not that OMVS isn't there, it's just we don't grant access to it
> >regularly except on one of our MVS systems. I wonder why that is....
> >I'm guessing it's money. :-)
>
> There's no charge for enabling access to Unix System Services; my guess is
> that they're not configured to share Unix file systems and don't want to
> allocate separate home directories for each system.
>
>
I suspect that's the reason...
I have a TSO ID on each of these different MVS systems, no sharing of files
between them, so I manually copy my rexx tools from one system to the others
with TSO TRANSMIT/RECEIVE... *I* wouldn't mind if I could access Unix System
Services even if the home directories were not shared... that's not much
different than what we do now with TSO access. (And if it really mattered I
could probably do something with rsync or similar)
I'll poke around and see what the response is like...
Kirk Wolf
that has an OMVS segment, but has a read-only home directory shared by
multiple userids. It seems unlikely to me that the Unix shell will
work this way, but I haven't tried it.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
----------------------------------------------------------------------
Peter Vander Woude
It's not so much as blocking ftps and allowing normal ftp. The normal ftp's
go thru such that the firewall can do it's stateful checking and not cause a
problem. With FTPS, the datastream is encrypted by the time it hits the
firewall, and does not conform to what the firewall thinks about "stateful",
thus it drops the connection. For our firewall, that means that if the command
string coming across, does not end with an end of line character (I don't recall
which one), it considers it a bad record, and terminates the session.
Peter
On Wed, 6 Jan 2010 08:04:36 -0800, Donald Russell
<russe...@GMAIL.COM> wrote:
>On Wed, Jan 6, 2010 at 06:15, Peter Vander Woude
<pwo...@harristeeter.com>wrote:
>
>> Don,
>>
>> If your firewall folks just recently upgraded the firewall, it could be
>> that the
>> upgrade "defaulted", or reset some configuration settings. For FTPS, the
>> firewall cannot do what's referred to as "stateful checking". I know ours
>> does
>> that, and if it does that on the control connection (and/or data
>> connection),
>> you will see the error you've been getting.
>>
>>
>That appears to be what happened.... I'll know for sure next week when the
>firewall people make the change to allow FTPS.
>
>For me, the red herring was that regular FTP works fine, which, to me, begs
>the question: What's the point of blocking FTPS without blocking FTP?
>
>Thanks for all the discussion and feedback...
>
Donald Russell
admittedly I don't know)...
Yes, I understand the technical part of your explanation... but the overall
effect is that FTPS is blocked while FTP is not.... if their intent is to
block file transfers, or selectively permit file transfers, then something
is misconfigured. Either the firewall should also deny FTP, or it should
allow FTPS. (Deny both or permit both, or I suppose it makes sense to deby
FTP but allow FTPS)
It seems odd to me that we may "FTP to anywhere[1]", but "FTPS is
effectively blocked". I need to fill out paper work to get FTPS working, yet
I don't have to do anything to use FTP. Yes, that's obviously an internal
issue.
[1] I haven't tested to see where the bounds of "anywhere" are... in my
case, all these transfers are internal.
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Donald Russell
> Sent: Wednesday, January 06, 2010 12:03 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: PCI and Auditors perceptions thereof
>
>
>
> The idea I was trying to convey is I wanted to invoke an sftp
> file transfer
> from a program invoked as if it were a TSO command. I figured
> everybody is
> familiar with "clist" as a concept, rather than a specific
> language, and I
> specified REXX because I don't write clist language code any more.
>
> Which is the correct noun to refer to a program, read from
> SYSEXEC in a TSO
> address space? In TSO land I generally refer to them as
> "clists" though
> they're written in REXX. In VM/CMS land I call them "EXECs"
> even though they
> are written in REXX, or EXEC 2 or EXEC. On zLinux I call them
> "scripts" or
> "shell scripts" even though they may be written in REXX, php,
> bash shell,
> korn shell, etc...
>
>
I'm usually as exact as possible. That is, I tend to say "REXX program" or maybe even "ISPF EDIT REXX". For UNIX, I tend to say "BASH script", "Perl script", "awk script", ... . The only time when I normally leave that off is when the subject basically specifies the environment. I.e. "Does anybody have a Perl program to ..." will like get a response like "yes, I have a script to do that." If I want to switch languages, I'll reply like: "No, but I have such a script in REXX".
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
01/06/2010
at 10:03 AM, Donald Russell <russe...@GMAIL.COM> said:
>Which is the correct noun to refer to a program, read from SYSEXEC in a
>TSO address space?
Command[1] procedure, optionally preceded by an expletive. But see below.
>In VM/CMS land I call them "EXECs" even though they
>are written in REXX, or EXEC 2 or EXEC.
In CMS the file type for all three is EXEC.
>On zLinux I call them "scripts"
That's appropriate nomenclature in CMS and TSO as well. Not just for
command procedures, but also for, e.g., XEDIT macros.
>I have a TSO ID on each of these different MVS systems, no sharing of
>files between them,
Supporting my guess that they won't or can't share the Unix files in their
current configuration.
Do you have an NFS server accessible to all of your systems?
[1] Unless they're, e.g., ISPF macros.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 10:43 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>Except that Rexx EXECs and CLISTs may be mingled in a single SYSPROC
>library. Magic Numbers.
Well, magic comments. If it makes you feel better, in CMS there are three
script languages sharing a common file type, and the system has to read
the file to determine which interpreter to run. In *ix there's a generic
mechanism[1] for a script to specify the proper interpreter.
[1] Google for shebang
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
P S
> Trying to do some due diligence in planning some data transfers and getting really confused.
>
> Many seem to be saying that all FTP traffic has to be encrypted to meet PCI standards. And yet I cannot find any such statement in the PCI standards. �But I did find a requirement for firewall packet inspection which, I am told, is impossible if the traffic is encrypted. �Did I read that right?
It occurs to me (perhaps a bit late) that if the requirement is to do
stateful inspection and the packets are encrypted, you can probably
still pass if you do stateful inspection. Just because it's useless
doesn't mean it's not compliant. cf. "Origins of red tape":
Take a cage with five apes.
Hang a banana on a string in the cage, with stairs under the banana.
Before long, an ape will go to the stairs and start to climb towards
the banana. As soon as he touches the stairs, spray all of the apes
with cold water.
Before long, another ape will make an attempt, but the result will be
the same: all the apes are sprayed with cold water. This should
continue through several more attempts. Pretty soon, when another ape
tries to climb the stairs, the other apes will all try to prevent it.
Now remove one ape from the cage and replace it with a new one. The
new ape will see the banana and want to climb the stairs. To his
horror, all the other apes will attack him. After another attempt and
attack, he'll know that if he tries to climb the stairs, he will be
assaulted.
Next, remove another of the original five apes and replace it with a
new one. The newcomer will go to the stairs and be attacked. The
previous newcomer will take part in the punishment.
Replace a third original ape with a new one. The new one will make it
to the stairs and be attacked as well. Two of the four apes that
assault him will have no idea why they were not permitted to climb the
stairs, or why they are joining in the attack on the newest ape.
After replacing the fourth and fifth original apes, all those which
were originally sprayed with cold water will have been replaced.
Nevertheless, no ape will ever again approach the stairs. Why not?
"Because that's the way we've always done it, and that's how it's
always been around here."