Skip to Main Content
IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Workspace IBM i
Created by Guest
Created on Oct 6, 2021

IBM i - Retrieving the Client IP from an Exit Point program for QIBM_QPWFS_FILE_SERV

The File Server exit point is used to identify the source of requests, and to be able to block them. Current situation is that the only the User profile is reported. According to IBM answer for Case TS005529571 there is no way to get the correct IP of the current request.
There are multiple situations where the same user profile is used by several machines (e.g. PC and Cell) each carrying a different IP. Such machines may be located in different places and may vary in their accessibility to foreigners, which also influences their security risk.
It is a well-known procedure to store credentials in machines. Trying to block a lost Cell will block the PC that is at work.
Today security is not only by USER. It must be also by the IP, and preferably by the Mac Address and machine name/type.

Request:
1. Add to either:
a. QIBM_QPWFS_FILE_SERV PWFS0200
b. An API that can be run in the exit program
The following information:
c. IP
d. Workstation name/type
e. Mac Address

Reasons for the request:
2. Consider a ransomware that runs on one PC, and the user is working also with another machine. The lack of the IP will prevent selective risk handling (this is our case).
3. It is common to report activities by IP.
4. In the current situation there seems to exist possibilities to attack the IBM i.
5. The IBM i is considered one of the most secured platforms. IMHO not to provide the IP (at least) is a disadvantage that can be considered a vulnerability.


Regards
Shmuel Zailer
RAZLEE CTO


Use Case:

The File Server exit point is used to identify the source of requests, and to be able to block them. Current situation is that the only the User profile is reported. According to IBM answer for Case TS005529571 there is no way to get the correct IP of the current request.
There are multiple situations where the same user profile is used by several machines (e.g. PC and Cell) each carrying a different IP. Such machines may be located in different places and may vary in their accessibility to foreigners, which also influences their security risk.
It is a well-known procedure to store credentials in machines. Trying to block a lost Cell will block the PC that is at work.
Today security is not only by USER. It must be also by the IP, and preferably by the Mac Address and machine name/type.

Request:
1. Add to either:
a. QIBM_QPWFS_FILE_SERV PWFS0200
b. An API that can be run in the exit program
The following information:
c. IP
d. Workstation name/type
e. Mac Address

Reasons for the request:
2. Consider a ransomware that runs on one PC, and the user is working also with another machine. The lack of the IP will prevent selective risk handling (this is our case).
3. It is common to report activities by IP.
4. In the current situation there seems to exist possibilities to attack the IBM i.
5. The IBM i is considered one of the most secured platforms. IMHO not to provide the IP (at least) is a disadvantage that can be considered a vulnerability.


Idea priority High
  • Guest
    Reply
    |
    Jun 14, 2022

    Euh... high priority for functionality that already exists ???

    Once again, in the exit program you can call the API QUSRJOBI with format JOBI0600 that has the client IP-address at offset 307.

  • Guest
    Reply
    |
    Jun 14, 2022

    The CAAC has reviewed this Idea and recommends that IBM view this as a high priority requirement that is important to be addressed. Ransomware is a significant issue for the SMB market, and this would help with that, so this should be high priority for IBM to address...

    Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual Ideas on the broader IBM i community, and has therefore reviewed your Idea.

    For more information about CAAC, see www.common.org/caac

    Nancy Uthke-Schmucki - CAAC Program Manager

  • Guest
    Reply
    |
    Apr 7, 2022

    Dear IBM new service

    in the last case from today we do saw ip address in QZLSFILE * USER job joblog.

    but still cant get the ip from API

    It's necessary to distinguish between native IPs that come as Exit point parameter like FTP, Telnet ..

    and IPs that we try to extract by API cause there are not Exit point parameter - like SQL, DBOPEN, Rmt Command , DDM, FileServer...

    For File Server IP is not parameter supplied by Exit point - we try to extract it by API

    But sometimes API cannot retrieve original IP , simply does not return it



  • Guest
    Reply
    |
    Jan 27, 2022

    Dear service

    please update the status

    Alex
    RAZLEE

  • Guest
    Reply
    |
    Dec 16, 2021

    The CEAC has reviewed this requirement and recommends that IBM view this as a MEDIUM priority requirement that should be addressed.

    Background: The COMMON Europe Advisory Council (CEAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CEAC has a crucial role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community and has therefore reviewed your RFE.

    To find out how CEAC help to shape the future of IBM i, see CEAC @ ibm.biz/BdYSYj and the article "The Five Hottest IBM i RFEs Of The Quarter" at ibm.biz/BdYSZT

    Therese Eaton – CEAC Program Manager, IBM

  • Guest
    Reply
    |
    Nov 4, 2021

    Thank you for submitting this request. We do understand the request that knowing the IP address may be important to some users in their restricting of the various access through the server.

    It is important to note that the server does not know the OS or MAC of the client. We only know that it is the server. The QIBM_QPWFS_FILE_SERV exit point services both the File server (QPWFSERVSO and QPWFSERVSS) jobs, and NetServer (QZLSFILE and QZLSFILET) jobs. The exit point program can make a determination as to which server it is based on the job name. Also, the server, when calling the exit point is not aware of the share being accessed for NetServer.

    We will need to do a more thorough investigation of the possibilities for this request.

  • Guest
    Reply
    |
    Oct 25, 2021

    @Alex

    1. Every system can be attacked
    2. The API is available via the API provided in my initial comment

  • Guest
    Reply
    |
    Oct 18, 2021

    Business justification of the change request:

    1. In the current situation there seems to exist possibilities to attack the IBM i.
    2. The IBM i is considered one of the most secured platforms. IMHO not to provide the IP (at least) is a disadvantage that can be considered a vulnerability.

  • Guest
    Reply
    |
    Oct 8, 2021

    Having a MAC address is close to useless as it is only valid on the same subnet or simple networks (once you have a router in the picture it will be replaced by his MAC address).

    As for the OS information... this is not provided by a client, so there's no method to implement this (some tools exist to perform OS fingerprinting but those are just attempts and a decent firewall on the client will even block it). The workstation name can be retrieved by doing a reverse name lookup (API's exist for that as well) but it all depends on the fact if you've a proper DNS setup.

    The IP-address is therefore the only valuable information you should concentrate on.

    PS. Please see my RFE about implementing share level authority which would avoid already a lot of potential issues... http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=107575

  • Guest
    Reply
    |
    Oct 7, 2021

    Can I vote for this one 5,000 times? We have the exact same predicament and we have had several ransomware attacks all coming through the [Deleted] file server. Fortunately none of the attacks were serious (yet), just a nuisance, but we are frustrated, not only by the inability to provide proper protection, but the inability to track down the culprit.

    OK, JOBI0600 provides the IP address, but none of the other information we need. In addition to the information this user requested, we also want to know the type of connection, i.e. is it a share via Netserver, and which share, or did it come in via some other avenue? I am not even sure what exactly the possible routes into the file server are. We want the ability to allow only known and approved types of connections, if the file server supports any connections over and above Netserver shares.

    Since the IP address is known, can you not reverse query the source system on first connection to determine the OS information, and that type of information? Every piece of information you can provide about the source will help us identify the culprit in a sea of thousands of workstations.

    I assume the MAC address is part of the TCP packet and you should be able to retrieve that? The IP address is useless for PCI long term compliance requirements, or even weekly "suspect traffic/activity investigations", because it is usually DHCP issued, and it is a royal pain to try and identify the actual source box.

    BTW: The majority of your TCP exit points need similar enhancements.

  • Guest
    Reply
    |
    Oct 7, 2021

    You can use QUSRJOBI with format JOBI0600 to obtain the IP-address.