Internal IP logging for agents

[RBecker]

Would it be possible to also log the internal/private IP address for agent logins in the same way we log public IPs? We have clients using the system who are swearing that they're not reusing logins between PCs in their office, but when we actually connect and investigate we find multiple agents under the same ID. If we could log the private IP at the same time it would make it easy to tell if this reuse was happening. This could even be something that is only available to level 9's under the admin utilities.

[mflorell]

You can only get the local LAN IP through a web browser with user intervention, either by the user installing something on the workstation that can gather it and pass it to the browser, or by disabling the WebRTC local IP Anonymizer flag in Chrome and allowing media access when a local WebRTC stream is initiated. Neither way is optimal for regular users, but they do supposedly still work.

[martinch]

Hey,

I had a think about this...there's not enough unique things in JavaScript to help out here...but I do have some ideas;

• We could maybe use a cookie on the local machine with a fingerprint. That way, you'll know if they're using the same computer or not. The caveat is incognito mode or they have disabled cookies on their browser.
• Using nslookup on your web server. I've used nslookup in the past to reverse lookup hostnames from IPs. Essentially that would be fetched on login to ViCi and stored probably in `vicidial_user_log.hostname`.
  

Any thoughts on these ideas @mflorell? Happy to provide the code if any of these ideas have any merit.

Thanks.

[RBecker]

Unfortunately the nslookup route won't be viable, as our cluster has no clients connecting internally, they are all external connections. This is why I was curious about a way to log local IPs for the users, because when trying to troubleshoot a login issue, all that gets logged is the public IP of the office they are connecting from.

[martinch]

Unfortunately the nslookup route won't be viable, as our cluster has no clients connecting internally, they are all external connections. This is why I was curious about a way to log local IPs for the users, because when trying to troubleshoot a login issue, all that gets logged is the public IP of the office they are connecting from.

Ah I see. My apologies. Thanks for clearing that up. I mean, Matt was suggesting user actions...but that's problematic. Would a unique fingerprint in a cookie be of any use?

[RBecker]

Would a unique fingerprint in a cookie be of any use?

Possibly, if that could be stored for each session and logged and visible in the UI somewhere. I have my web servers in front of HAProxy currently which stores a cookie that locks the session to whatever backend server it assigned, and I'm sure I could probably have it set another one for a unique ID. Though, if we wanted this to be viable for any user of Vici, then a Vici script itself would have to set that cookie.

[martinch]

Would a unique fingerprint in a cookie be of any use?

Possibly, if that could be stored for each session and logged and visible in the UI somewhere. I have my web servers in front of HAProxy currently which stores a cookie that locks the session to whatever backend server it assigned, and I'm sure I could probably have it set another one for a unique ID. Though, if we wanted this to be viable for any user of Vici, then a Vici script itself would have to set that cookie.

Understood thank you RBecker

I had some time today and I thought I'd provide a solution for you here. So here's what I have for you;

Without making any changes to Chrome / other browser settings to perform the WebRTC hack to get the local LAN IP (a unique fingerprint is on the extreme right);

I login to ViCiDial…as normal (user 1234);



Then, Dick Jones logs into the same machine with a different account (101);



If you do as Matt suggested and toggle this special flag;



We do the same again (1234);



And Dick Jones makes a return (user 101);



Both using the same box…tut tut. So the admin / provider asks us to use our own workstations. Here is me 1234 logging into my own box;



So there it is. Would this be useful to you? If so, I can submit the code changes on Mantis for Matt and team to review and possibly publish

Cheers.

[RBecker]

So you're saying that these changes would make the GUID/fingerprint appear even without that anonymizer disabled, but with disabled that would show the actual IP? I'd definitely be interested in testing this out, I think submitting it to Mantis would be a great idea.

[martinch]

So you're saying that these changes would make the GUID/fingerprint appear even without that anonymizer disabled, but with disabled that would show the actual IP? I'd definitely be interested in testing this out, I think submitting it to Mantis would be a great idea.

Indeed yes. GUID with the flag enabled and LAN IP with the flag disabled. Both should allow you to uniquely identify the machine in some capacity. The cookie will be bound to the machine for 24 hours...which seemed like a sensible threshold to me but Matt and the team may want to change that.

Also, just a few caveats I think I should mention here;

• Cookies must be enabled on the agent browser to enable this functionality.
• If the agent clears their cookies during the day, this feature may report a different GUID and may not be as effective. However, for LAN IPs it will persist.
• If the agent PCs are running on networks using DHCP, it's possible the LAN IP may change due unplugging network cables and stuff. GUID address will persist if this happens.

Not bulletproof but should suffice for your needs. I'll prepare patches for Mantis. Cheers!

[RBecker]

Sounds good to me! Obviously cookies must be enabled for agent login in the first place, as well as for my webserver pinning that my load balancer is doing as I said. We do have full access to all of our client machines where we have this issue so disabling the Chrome flag shouldn't be a big deal. Appreciate it!

[martinch]

Awesome, thanks RBecker

A patch will be submitted at some point this week. Thanks again.

[martinch]

@RBecker

Ticket logged on Mantis -> https://www.vicidial.org/VICIDIALmantis/view.php?id=1472

Here is how it looks on the User Stats report;

Code: Select all

=============================================
Logging Local IP Addresses of Agents.
=============================================
Ticket Type: Add Feature.
Reporter: RBecker.
Impacted Users: ViCiDial Agents Outside LAN.
Priority: Low.
Product(s) Affected: ViCiDial.
Deadline: No firm deadline in place.
Time / Effort Estimate: 4 hours of development / 1-2 hours of QA testing.

=============================================
Description
=============================================
RBecker reported that some users on his ViCiDial cluster were logging in from the same PC with different accounts. This can cause confusion / issues for the operation.

Devise a way to record the local IP address of the machine and log it in the database.

Tasks;

- Create a new column in vicidial_user_log (something like local_lan_ip).
- Grab local LAN IP using known methods in JavaScript.
- Log the value to the new column.

=============================================
End
=============================================