Discussion:
TCPIP IP inbound/outbound connection filtering?
(too old to reply)
Jousma, David
2017-05-15 13:30:52 UTC
Permalink
Raw Message
All,

Sorry if this is an over-simplistic question, coming from a z/OS guy that doesn't have a lot of IP depth of knowledge. We recently had our annual site Disaster test, which for us is done locally, at one of our own datacenters. Data is replicated, and we simply IPL one of our systems onto the PPRC'd data with some highlevel config changes to IP/VTAM so that the system can exist on our PROD network. We do take some of what I consider rudimentary measures to avoid "data leakage" from the disaster environment to the prod environment in terms of TWS, FTP, MQ, etc.

At my prior employer, we had a similar process, but the DR system(s) were all placed onto their own D/R VLAN to with no access off of it. I'd love to get to that point here, but at least for now that is not a possibility.

What I want to explore is whether or not, we can take steps at the IP stack level to maybe initially disallow ALL outbound connections, and then secondarily, even conditionally allow outbound connections to a known list of "disaster recovery" nodes elsewhere in the network? Can this be done in Comm Mgr? Our annual DR test encompasses many non-mainframe servers too. I don't want to create an administrative nightmare either. If I were to describe what I'd like in non-mainframe terms, it would like the firewall on my MAC, popping up a prompt for new outbound connections on the console, with the ability to respond yes/no to allow. Like I said, sorry, if I am over-simplifying, just looking to add some safeguards to help avoid a problem that occurred.

Thanks, Dave

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be privileged.
It is intended only for the addressee(s) named above. If you receive this e-mail in error,
please do not read, copy or disseminate it in any manner. If you are not the intended
recipient, any disclosure, copying, distribution or use of the contents of this information
is prohibited. Please reply to the message immediately by informing the sender that the
message was misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Wawiorko
2017-05-15 13:38:13 UTC
Permalink
Raw Message
Yes - you can do all that in z/OS with an IPSEC filter policy.

You need a way of automatically using the correct policy in PAGENT - DR Test or Live. One way is to use a system symbol ultimately picked up from the LOADPARM.

These days, realistically, you need zOSMF Communications Server Configuration Assistant. You can edit filter policy files manually if they are very simple. If they get complex you'll soon need Configuration Assistant.

Then configure PAGENT and the IP stack to use IPSECURITY.

Mike Wawiorko

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jousma, David
Sent: 15 May 2017 14:31
To: IBM-***@LISTSERV.UA.EDU
Subject: TCPIP IP inbound/outbound connection filtering?

All,

Sorry if this is an over-simplistic question, coming from a z/OS guy that doesn't have a lot of IP depth of knowledge. We recently had our annual site Disaster test, which for us is done locally, at one of our own datacenters. Data is replicated, and we simply IPL one of our systems onto the PPRC'd data with some highlevel config changes to IP/VTAM so that the system can exist on our PROD network. We do take some of what I consider rudimentary measures to avoid "data leakage" from the disaster environment to the prod environment in terms of TWS, FTP, MQ, etc.

At my prior employer, we had a similar process, but the DR system(s) were all placed onto their own D/R VLAN to with no access off of it. I'd love to get to that point here, but at least for now that is not a possibility.

What I want to explore is whether or not, we can take steps at the IP stack level to maybe initially disallow ALL outbound connections, and then secondarily, even conditionally allow outbound connections to a known list of "disaster recovery" nodes elsewhere in the network? Can this be done in Comm Mgr? Our annual DR test encompasses many non-mainframe servers too. I don't want to create an administrative nightmare either. If I were to describe what I'd like in non-mainframe terms, it would like the firewall on my MAC, popping up a prompt for new outbound connections on the console, with the ability to respond yes/no to allow. Like I said, sorry, if I am over-simplifying, just looking to add some safeguards to help avoid a problem that occurred.

Thanks, Dave

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President ***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be privileged.
It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons.

Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.

Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702).

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jousma, David
2017-05-15 13:54:38 UTC
Permalink
Raw Message
Thanks Mike. We do have z/OSMF active mostly for the use of the new configuration assistant.

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Mike Wawiorko
Sent: Monday, May 15, 2017 9:39 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: TCPIP IP inbound/outbound connection filtering?

Yes - you can do all that in z/OS with an IPSEC filter policy.

You need a way of automatically using the correct policy in PAGENT - DR Test or Live. One way is to use a system symbol ultimately picked up from the LOADPARM.

These days, realistically, you need zOSMF Communications Server Configuration Assistant. You can edit filter policy files manually if they are very simple. If they get complex you'll soon need Configuration Assistant.

Then configure PAGENT and the IP stack to use IPSECURITY.

Mike Wawiorko

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jousma, David
Sent: 15 May 2017 14:31
To: IBM-***@LISTSERV.UA.EDU
Subject: TCPIP IP inbound/outbound connection filtering?

All,

Sorry if this is an over-simplistic question, coming from a z/OS guy that doesn't have a lot of IP depth of knowledge. We recently had our annual site Disaster test, which for us is done locally, at one of our own datacenters. Data is replicated, and we simply IPL one of our systems onto the PPRC'd data with some highlevel config changes to IP/VTAM so that the system can exist on our PROD network. We do take some of what I consider rudimentary measures to avoid "data leakage" from the disaster environment to the prod environment in terms of TWS, FTP, MQ, etc.

At my prior employer, we had a similar process, but the DR system(s) were all placed onto their own D/R VLAN to with no access off of it. I'd love to get to that point here, but at least for now that is not a possibility.

What I want to explore is whether or not, we can take steps at the IP stack level to maybe initially disallow ALL outbound connections, and then secondarily, even conditionally allow outbound connections to a known list of "disaster recovery" nodes elsewhere in the network? Can this be done in Comm Mgr? Our annual DR test encompasses many non-mainframe servers too. I don't want to create an administrative nightmare either. If I were to describe what I'd like in non-mainframe terms, it would like the firewall on my MAC, popping up a prompt for new outbound connections on the console, with the ability to respond yes/no to allow. Like I said, sorry, if I am over-simplifying, just looking to add some safeguards to help avoid a problem that occurred.

Thanks, Dave

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President ***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be privileged.
It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons.

Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom.

Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702).

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN


This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...