SessionCheckRemoteIP ("Turns on the remote ip address check") can be disabled through SysConfig, but I remember someone from the WMF saying this shouldn't be toggled off for security reasons.

Does IP-affinity really provide a lot of security benefits? Or are
there other problems with OTRS that make this problematic... :(

I want to added that on my laptop (OS X 10.10.2/ Safari 8.0.3(, the log-out happens far more frequent than my IP address changes.

For example, I will fail to log in three to four times in a roll and once logged in I will be logged out again as soon as I click on any tickets.

Certain ISPs apparently have a habit of systematically switching IPv6 addresses around as well. This causes loss of data.

@Krenair: I'm not sure why you reverted the priority to "Needs Triage" instead of deciding (or who you expect to set it instead)?

One of the OTRS admins, Operations team members, or maybe @csteipp, should set the priority on this. I get the impression that it's not Low.

In T87217#989866, @Krenair wrote:

One of the OTRS admins, Operations team members, or maybe @csteipp, should set the priority on this. I get the impression that it's not Low.

As an OTRS admin, I personally feel that this is a feature, not a bug that needs to be fixed. That being said, I do understand the inconvenience caused to the users this is effecting.

I would leave it up to operations (Jeff/Chris) to make the determination.

This sounds like it's an upstream issue with OTRS itself and a feature request more than an Ops thing. ?

Second Rjd0060's comment here. OTRS can be configured to stop constantly comparing your current ip with your 'login ip' (see my first comment), and, of course, technically, we could change that setting, but since I/we have no idea about the potential security implications, ops has to make that call IMHO.

Looks to me like we already have SessionCSRFProtection and SessionCSRFProtection enabled; both are set to 1 in Kernel/Config/Files/ZZZAAuto.pm and I confirmed that my browser has a cookie when looked in. I don't have any objection to disabling SessionCheckRemoteIP, but I'd like CSteipp's opinion too.

In T87217#998789, @lfaraone wrote:

Oh, wait, I just looked at our OTRS installation to remind myself. The session ID is in the URL. https://ticket.wikimedia.org/otrs/index.pl?OTRSAgentInterface=<hex-encoded>. This means if we disabled IP-binding, agents following HTTPS links from OTRS would be subject to referer leaking. A malicious party could use this to take over an agent's session.

Correct. With that session id it's trivial to impersonate the user until they logout. OTRS did get password changing right and requires the old password, so it would be hard for an attacker to take over the account after the victim clicks the logout button.

It looks like the session id is only added to the redirect on the initial login, and it doesn't look like there are many links off-site from there (from the default dashboard). I'm guessing the initial login page isn't one of the urls that people are likely to cut-and-paste into public places either? Under those assumptions, the security risk we're opening up by not checking the IP restriction shouldn't be too significant. It's unfortunate it's a site-wide config instead of per user-- I can certainly understand that some users would want the extra protection.

So I'd say the risk is low, but you are increasing your risk by disabling the IP checking. If any of the users are uncomfortable, it might be good to add some extra documentation/training to make sure users know they types of things that would put themselves at risk (clicking an external link as soon as they login, or cut-and-paste'ing that url), and how to mitigate it (always logout as soon as you're done, etc).

In T87217#1012875, @csteipp wrote:

It looks like the session id is only added to the redirect on the initial login, and it doesn't look like there are many links off-site from there (from the default dashboard). I'm guessing the initial login page isn't one of the urls that people are likely to cut-and-paste into public places either? Under those assumptions, the security risk we're opening up by not checking the IP restriction shouldn't be too significant. It's unfortunate it's a site-wide config instead of per user-- I can certainly understand that some users would want the extra protection.

The session ID is added rarely, but it's not only added on the initial login. It's also added when an agent logs out (although it's highly likely that he'd publish a link to that), or sometimes when they perform a search using a search template (I haven't been able to re-produce that, but I've seen it before, not sure what you need to do to see it). You're right that "the initial login page isn't one of the urls that people are likely to cut-and-paste into public places either." On the other hand, if you click a link to a particular ticket (tickets are frequently linked to from public discussions, and tens of thousands of file descriptions), and an agent clicks that link without having logged in prior to that, then the session ID will also added to the ticket URL to which the agent is forwarded upon login.

I don't really have an opinion on that, and I also lack the technical understanding of how OTRS handles this all, but do I get this right that if an OTRS agent posted a link with the sessionID on a public page, this would immediately enable another user, by just clicking that link, to take over his session? Or does it take additional efforts?

In T87217#1036962, @pajz wrote:

I don't really have an opinion on that, and I also lack the technical understanding of how OTRS handles this all, but do I get this right that if an OTRS agent posted a link with the sessionID on a public page, this would immediately enable another user, by just clicking that link, to take over his session? Or does it take additional efforts?

Yes. You demo this by logging in, then open a different browser, paste the full url in, and you're logged as the original user.

I just would like to say that some of us have not been able to work in OTRS at all, including myself. I keep being logged out after some minutes, on some occasions after a few clicks, while the scenarios you are discussing are rather hypothetical, if I may say so.

I would like to ask you to please keep this in mind while seeking a solution to this issue. Thanks.

If I understand the documentation correctly, I would suggest, by the way, that, should we decide to implement this, we do not disable SessionCheckRemoteIP but only SessionDeleteIfNotRemoteID (both are enabled atm). As I understand it, that would also solve the problem, but OTRS would still keep track of IP address in the log, so we'd at least be able to invesitgate potential issues.

From just a quick look at their code, it looks to me like as long as SessionCheckRemoteIP is enabled, then when the user requests a page from the site and their IP has changed, they won't have a valid session, so they won't be able to use the site until their ISP randomly sends them back to the IP that they logged in from.

https://github.com/OTRS/otrs/blob/rel-4_0/Kernel/System/AuthSession/DB.pm#L84

If SessionDeleteIfNotRemoteID is also true, otrs will also destroy the session server side, so even if they get back to the same IP that they logged in from, they won't be able to continue until they login again.

We can test just setting SessionDeleteIfNotRemoteID to false, but I don't think that's going to be enough. But maybe it's worth a try in case?

If one is using tethered mobile broadband from Three (a UK mobile operator) using an Android handset to provide a personal hotspot, every slight jolt in mobile connectivity led to a new IPv4 address being granted. When I used to commute by train, the loss of an OTRS session every time one went through a tunnel for a second or two was fatal to my ability to handle any tickets.

I am also having issues remaining logged in to OTRS, and I often see, but not always, an "invalid session" message. I have a stable AT&T U-verse connection, which began allowing IPv6 just a few months ago, but it also seems that I sometimes connect via v4.

*update* I have the "SixOrNot" (http://timothy.baldock.me/sixornot/) extension installed in Firefox, and sometimes it tells me that I'm seeing the IPv6 address of OTRS, and other times I'm seeing the IPv4 address.

In T87217#1041222, @tommorris wrote:

If one is using tethered mobile broadband from Three (a UK mobile operator) using an Android handset to provide a personal hotspot, every slight jolt in mobile connectivity led to a new IPv4 address being granted. When I used to commute by train, the loss of an OTRS session every time one went through a tunnel for a second or two was fatal to my ability to handle any tickets.

Because your have a new ip when reconnecting.

I think the IP checking is a useful security measure and should not be disabled.

Please note that we have tried this out in

https://phabricator.wikimedia.org/T88224

and there are many DSL connections you just cannot work in OTRS from. Mine is one. You please should seek a solution for this.

In T87217#1043145, @Steinsplitter wrote:

In T87217#1041222, @tommorris wrote:

If one is using tethered mobile broadband from Three (a UK mobile operator) using an Android handset to provide a personal hotspot, every slight jolt in mobile connectivity led to a new IPv4 address being granted. When I used to commute by train, the loss of an OTRS session every time one went through a tunnel for a second or two was fatal to my ability to handle any tickets.

Because your have a new ip when reconnecting.

I think the IP checking is a useful security measure and should not be disabled.

Can you expand further?

If IP-bound sessions are a meaningful security enhancement to OTRS, then that means that the session model is so mindbogglingly broken that the entire system should be nuked from orbit.

@Steinsplitter: I know I have a new IP address when reconnecting. The fact that every other web service I use manages to persist connections over IP changes except OTRS kind of led me to realise that.

I'd like to add another problematic use case: if you have a connection which has both an IPv4 and IPv6 address, sometimes you get disconnected when ticket.wikimedia.org detects you have shifted from IPv4 to IPv6.

IP-bound sessions cause more annoyance for agents than it adds security. If we want better security, something like two-factor authentication would be preferable.

Please note that the case of dual IPv4/IPv6 addresses is indeed one main problem we reproduced some weeks ago in issue T88224 which was soon closed and marked as a duplicate to this ticket. Such broadband connections are provided per default in this country.

Today, I have got the advice to set network.dns.disableIPv6 in Firefox about:config to "true".

I have tested this, and I have not been logged out for about half an hour. It seems that you can use OTRS again with only this minor change.

I hope this can solve the problem, but I would like to keep the bug open for further testing and at least until more agents can confirm that it works for them, too.

In T87217#1114431, @Aschmidt wrote:

Today, I have got the advice to set network.dns.disableIPv6 in Firefox about:config to "true".

I have tested this, and I have not been logged out for about half an hour. It seems that you can use OTRS again with only this minor change.

Woo! Thanks, Aschmidt.

I hope this can solve the problem, but I would like to keep the bug open for further testing and at least until more agents can confirm that it works for them, too.

Agreed. I haven't personally had this problem so I cannot confirm.

This is just to let you know that I can confirm that—for the time being, at least—I have been able to use OTRS with IPv6 disabled in Firefox, or in OS X Mavericks, for that matter.

In T87217#1036962, @pajz wrote:

In T87217#1012875, @csteipp wrote:

It looks like the session id is only added to the redirect on the initial login, and it doesn't look like there are many links off-site from there (from the default dashboard).

This has been fixed upstream (OTRS Bug 8008) and the fix is part of the 4.0 release, which we are trialing. We'll be able to turn off SessionCheckRemoteIP soon.

Change 242789 had a related patch set uploaded (by Faidon Liambotis):
otrs: disable SessionCheckRemoteIP

https://gerrit.wikimedia.org/r/242789

Change 242789 abandoned by Faidon Liambotis:
otrs: disable SessionCheckRemoteIP

Reason:
Fair enough.

https://gerrit.wikimedia.org/r/242789

Change 242789 restored by Alexandros Kosiaris:
otrs: disable SessionCheckRemoteIP

Reason:
@Jgreen, yes you are right. https://otrs.github.io/doc/manual/admin/4.0/en/html/configuration.html

"Lastly, the file Kernel/Config.pm that contains your individual settings and manually changed configuration parameters, will be parsed."

I did not read this line. restoring

https://gerrit.wikimedia.org/r/242789

Change 242789 merged by Alexandros Kosiaris:
otrs: disable SessionCheckRemoteIP

https://gerrit.wikimedia.org/r/242789