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

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.

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

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

Dear service

please update the status

Alex
RAZLEE

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

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.

@Alex

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

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.

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

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.

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