Db2 for z/OS & Db2ZAI

Have you tried -MODIFY DDF PORT(1.2.3.4) SECPORT(5.6.7.8)  ?

Hello Leo, 

I am not 100% sure and cannot test that, but I would give a try to stop just the DDF, not the member and try it with a MODIFY DDF as Mike told you. Did you try it?

I did something similar with the ALIAS at a Data Sharing, and for being able to do it I had to STOP the ALIAS first. These are my notes when I remove the nonsecure port from an alias and letting just the Secure one:

1.       DB2J DIS DDF DETAIL             

2.       DB2J modify ddf alias(D2TALIA1) STOP   

3.       DB2J modify ddf alias(D2TALIA1) NPORT          

4.       DB2J modify ddf alias(D2TALIA1) START

5.       DB2J DIS DDF DETAIL  

And this screenshot explaning to myself why I had to stop the ALIAS

DSNL313I - IBM Documentation

I know you were not asking this but just in case it helps.

Thanks,

Hi all

Thanks for all replies. 

Unfortunately the MODIFY DDF does work on the default (secure)port  in the BSDS.

But soledad's reply gave an idea. My fear was that when we disabled all the non-ssl ports with DSNJU003 during the weekend with a rolling stop/start and then on Monday there was this 'very important' application which was not SSL and we had to do the DB2's recylce again. 

But off course we can add the non-secure port as an ALIAS in this case.

So a bit of a solution.

That's great, Leo.

Happy to know you finally find the way!

hi Leo, just a thought, if you already on V13 (?): 

You can disable non-secure connections with system profiles with EXCEPTION* ATTRIBUTE1. Well, I know it is not equal to disabling non-SSL Db2 ports, and it is on authentication layer, but still something that would reject non-secure ones to enter Db2

https://www.ibm.com/docs/en/db2-for-zos/13.0.0?topic=support-discovering-controlling-secure-tcpip-connectivity-profile-tables#db2z_controlsecureconnectivityprofiles__d136e1620

Example1 listed there is for REST connection, which would be rejected with message if non-secure

Michal Bialecki

I agree with Michael. 

The new profile enhancement sounds like exactly what you need.

At least until you can identify and get everyone off of the unsecure port and finally remove it during a planned maintenance window. Keep in mind, removing it will solve the auditor's question but what about that one random app that lingers who is still remediating or may not even know to do so. Removing that port and finding out the hard way requires a second outage to add it back. 

With profiles, I recommend monitoring (warning) then blocking (exception).

Based on settings, I found I needed mainframe IP addresses to still allow Db2 to Db2 cross group traffic. 

I spoked on this topic at IDUG and will present on it at TechXchange.

https://www.ibm.com/docs/en/db2-for-zos/13.0.0?topic=support-discovering-controlling-secure-tcpip-connectivity-profile-tables

The topic is probably deeper than I can cover here. Read up on that page and perhaps you'll be at TechXchange. :) 

Scott Walker,
I see your concern about disabling the non-SSL port (quoting the key content: "...removing [the non-SSL port] will solve the auditor's question but what about that one random app that lingers who is still remediating or may not even know to do so. Removing that port and finding out the hard way requires a second outage to add it back. ")

At my site, there is a firewall server, which has the ability to block any port which exists in the enterprise network. I'm not read in at that level, so I don't know whether such a server is rare, common, or universal in the wild.  However: for us, the solution to the stated problem would be to change, not the mainframe/DB2 non-SSL port, but instead the firewall entry permitting traffic to reach it.  That change is dynamic and immediate, and so could be withdrawn within minutes of receiving a customer complaint.  

If Leo's customers (like the customers for most of us in this niche!) aren't able to fully identify uses of the old port, I recommend considering this method: ask your friendly local network manager (management team) whether they can do this, and plan the change that way.  Then you-all can remove the old port in a future outage, for example an RSU change or z/OS maintenance.

HTH (Hope This Helps)

/phil

Hi Phil, 

Yes, you have a valid point too and bring up a good topic. Your strategy would work as well and be a dynamic change as you mentioned. That's better than the double outage situation!

For me personally, I would like to have the visibility and control - within Db2 itself.

No matter what, having the end goal of TCPPORT = SECPORT then they could show a screenshot to the auditors to prove Db2 is in the clear and they can go bug someone else. :) 

Hi all,

I think that the use of profile table in this case is always the better one. 
If you "close" the non secure port this way and there shows up an application  that was not ready for it, you always can open the secure port for this 1 application/user.
When you have the way of BSDS/DSNJU003 or creation of an ALIAS  to "open" up again the non secure port it will be immediately open for all. And you are again where you have started.

Using the profile tables you can open de non secure port very specific for 1 application/user and leave it for the rest closed.

Greetz,
Andre