Link to home
Start Free TrialLog in
Avatar of Panchux
PanchuxFlag for Argentina

asked on

AS400 Access Logs

We have an AS400 with a V5R3 OS at our company.
We think a former employee is accessing data from outside and we want to know if he is being helped from within the company or not. To know that I though that having the ip address of the terminal from wich he is accessing would be the solution. The problem is that I don't know how to do that.

Any idea would be much appreciated,

Pancho
ASKER CERTIFIED SOLUTION
Avatar of Gary Patterson, CISSP
Gary Patterson, CISSP
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Panchux

ASKER

Gary,

What makes you think he is gaining access?  Is data being viewed/stolen, or changed?  Do you have any way to know that it happens, or when?  Do you know what programs or tools are being used?

We know because he used old accounts only known by a few in late night hours. He used those accounts to modify a backup procedure twice. I think he is using a Client Access through a VPN connection.

Do you have database journaling implemented, where you can track what applications open particular files, and when?
No but I want to implement it. We have a CL program that logs every command type at the console but it is not a good reporting system.

If not, is there a VPN or other mechanism that might be used to gain access to the AS/400?

Yes we have a VPN setup with a Draytek Vigor Router.

If there is a firewall, does it log connection attempts to the AS/400, VPN connection attempts, etc?

Firewall might be, VPN log services where disabled.

It is possible that the former employee installed some software on one or more system in your network or had someone else install software that allows him to bypass or tunnel through a firewall (LogMeIn, VNC, etc., etc.).  If this is the case, then the IP address that he users to access the AS/400 will just be the IP address of the compromised system.
There is a chance, although small, he could use Teamviewer for accessing our network then the AS400. But we think he used the VPN.

Assuming he has a way to gain access to the AS/400 remotely, is his former user profile disabled?

Sure it is. He knew some else's user/password or they were given to him. He's user/password under the VPN Router was disabled too.


Have you forced your users to change their passwords, since he may have obtained someone else's password?Have you changed shared account passwords, and product passwords?

Now we have. We reset all passwords.
I just want to know if there is a command to match the terminal and the ip address from witch he connected.

Thanks a lot,

Pancho
 






SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Panchux

ASKER

Lewis, thank you for your response. As none of you point a solution to what I need to achieve (matching a terminal with it's ip address) I tend to think it's not possible without implementing db journaling.

If it is so I'll be glad to consider this question answered and post a new one about how to set up db journaling.

Pancho
Avatar of Panchux

ASKER

Both comments were helpful. Database journaling must be enabled to implement the access logs I'm willing to have.
Avatar of Member_2_276102
Member_2_276102

(matching a terminal with it's ip address)

It can be particularly difficult if the user profile has sufficient authority.

The device will take on the IP address of whatever remote system connects to it. If a different connection is made from somewhere else a few minutes after the previous connection ends, then the device will have a new IP address associated with it.

Assuming that the connection is telnet (and it doesn't have to be), then your history log will show the job start time as a CPF1124 message. The name of the job will contain the name of the device that was connected to. If that device was modified in order to assign an IP address for the connection, there should also be a CPC2613 message that notes a change to the device.

So, for example, you might run a command like: DSPLOG MSGID(CPC2613 CPF1124)

The result will probably be cluttered with a lot of CPF1124 messages since every job in the system started at some time. But the scattered CPC2613 messages can give an indication of whether or not the questionable device was later changed by someone else getting connected to it.

If a subsequent connection changed the device IP address, then the questionable IP address has already been removed from the device. But if not, you can do DSPDEVD for the device to see the most recent IP address.

You might run DSPLOG a few different ways to narrow the time-frame down. You might run it once just to review a list of the CPC2613 messages by themselves. If you know which device was used, you can use the DSPLOG JOB() parameter to isolate the CPF1124 messages for it; that might help establish the times for the DSPLOG PERIOD() parameter. (Technically, you can send DSPLOG output to a spooled file and do various searches through the text.)

But, if the device has been used since then, you'll need to go in a different direction.

Four general directions -- 1. a routing program that queries job IP address and logs it before allowing an interactive job to continue; 2. a program to process output from the QIBM_QWT_JOBNOTIFY exit point; 3. an exit program on the QIBM_QTG_DEVINIT exit point; or 4. a commercial solution. (Disclaimer: My employer sells exit point products.)

You should avoid #3 unless you're certain that you understand the risks. Option #2 might be simplest, but needs some management to keep it accurate -- you can't rely on expired data queue entries; you have to handle them in near real-time if you're going to extract the job IP address. Option #1 might be the best balance of simplicity and timeliness. Option #4... well, the vendor tends to shoulder responsibility.

Tom
This as said, is a major complex can of worms. But in my mind Tom has the right idea. My firm deals with  numerous companies with foreign operations. Most want to track what's coming in to the system from remote/outside of the country. Our standard recommendation is option 1 or 2 ... we also route jobs from remote operations (in particular China) for a few of these firms to a separate sub-system and assign them specific job id's so we can shut down remote operations w/o affecting the other users.  

You could also disable virtual device names and force every job to use a specific job name. It would make it much easier to id the particular terminal accessing items.. wouldn't really need an IP address then, just look for terminals being used outside of expected times.

But my real recommendation here is to abandon looking on the 400 and track where he's getting into the system, the 400 is not the only vulnerable location on your network. You need to be doing intrusion detection and logging.

Mike Cody