Re: MGTOOLS may spoof IP addresses -- MIDRANGE-L

I've had an on-going PMR with IBM since we were on 7.1 regarding IP
addresses in the (application) journal. In the same job the IP address for
database updates would change or would actually disappear. DB Update 1
would should show an IP address of 10.2.2.2 (I'm making the IP up). DB
Update 2 would should no IP and DB update 3 could show 172.2.223.16 (again
I'm making the IP up). IBM told me that the IP address is taken from
socket data. As the job would make different sk=ocket connections the IP
would change. For example update a record would show IP address 1, FTP to
a partner, update another record and the journal will show the IP address
that the job just FTPed to.

They claimed it was working as designed. To which I told them their design
was flawed. They should be reporting the IP address of the session that is
actually doing the updates.

Gord

On Thu, 24 Oct 2019 at 15:43, Rob Berendt <rob@xxxxxxxxx> wrote:

I suggest after using MGTOOLS that you sign off and on again. I suspect
it spoofs being a particular IP address in order to send data to IBM. Then
again, if they can do that, why can't us muggles do that and royally mess
up the system audit journals?

<FromIBMTicket>
I logged into a 5250 session to test logging. This session:
Job . . . . . . . . : 202780/ROB/ROBHQ1
Earlier on that session I had sent some MGTOOLS data to IBM.

I ran this command
CHGUSRPRF USRPRF(ADOPT) SPCAUT(*JOBCTL *SECADM)
Followed by
CHGUSRPRF USRPRF(ADOPT) SPCAUT(*JOBCTL)

The first one created the entry:
Journal . . . . . . : QAUDJRN
Sequence . . . . . . : 342197716
Code . . . . . . . . : T - Audit trail entry
Type . . . . . . . . : CP - User profile changed
Date . . . . . . . . : 10/24/19
Time . . . . . . . . : 14:05:12.158000
Flag . . . . . . . . : 0
Count/RRN . . . . . : 0
Commit cycle ID . . : 0
Nested commit level : 0
Job . . . . . . . . : 202780/ROB/ROBHQ1
User profile . . . . : ROB
Ignore APY/RMV . . . : No
Ref constraint . . . : No
Trigger . . . . . . : No
Program . . . . . . : QCMD
Library . . . . . : QSYS
ASP device . . . . : *SYSBAS
System sequence . . : 11784359632253947905
Thread identifier . : 0000000000000854
Receiver . . . . . . : ZAUDJR2959
Library . . . . . : QGPL
ASP device . . . . : *SYSBAS
Journal identifier . : X'00000000000000000000'
Remote address . . . : 170.225.15.31
Address family . . . : IPv4
Remote port . . . . : 80
System name . . . . : GDIHQ
Arm number . . . . . : 21
Logical unit of work : *OMITTED
Transaction ID . . . : *OMITTED

Notice this line in particular:
Remote address . . . : 170.225.15.31

If you go to your PC and do the following
C:\Users\rob>nslookup 170.225.15.31
Server: localhost
Address: 127.0.0.1

Name: testcase.boulder.ibm.com<http://testcase.boulder.ibm.com/>
Address: 170.225.15.31

Now, I really doubt that IBM connected in from 'testcase', took control of
my job and issued a CHGUSRPRF.

Perhaps some really weird stuff in MGTOOLS told it to spoof being that IP
address in order to get data to IBM and that session should always be
signed off/on again after using MGTOOLS?

</FromIBMTicket>

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com