Re: MGTOOLS may spoof IP addresses

Do you have that case number available?

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


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Gord Hutchinson
Sent: Friday, October 25, 2019 7:51 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: MGTOOLS may spoof IP addresses

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.


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

--
Gord Hutchinson
TST Overland Express
--
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
--
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