Failed logon does not state where user is from (REMOTE_IP)

Bug #1461266 reported by David M. Zendzian
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Expired
Wishlist
Unassigned

Bug Description

When a user logs on to horizon the status of their logon is logged to the apache error.log file. However this log data does not provide anything useful for the configuration of monitoring or security controls because it does not provide the REMOTE_IP.

Since some configurations use ha_proxy and some don't the logging will need to be able to determine if the user is accessing via a proxy or not. There are several issues with this as pointed out in this article: http://esd.io/blog/flask-apps-heroku-real-ip-spoofing.html. I would recommend using a function similar to what is in that post, however to get things working I have used the following code to get the log to display the end-user IP address:

/usr/lib/python2.7/dist-packages/openstack_auth/forms.py

27a28,34
> def get_client_ip(request):
> x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR')
> if x_forwarded_for:
> ip = x_forwarded_for
> else:
> ip = request.META.get('REMOTE_ADDR')
> return ip
94,95c101,102
< msg = 'Login successful for user "%(username)s".' % \
< {'username': username}
---
> msg = '$(remote_ip)s - Login successful for user "%(username)s".' % \
> {'username': username, 'remote_ip': get_client_ip(self.request) }
98,99c105,106
< msg = 'Login failed for user "%(username)s".' % \
< {'username': username}
---
> msg = '%(remote_ip)s - Login failed for user "%(username)s".' % \
> {'username': username, 'remote_ip': get_client_ip(self.request) }

It's defiantly not the best answer, in fact it may not even be fully functional :), but something is needed to be able to monitor invalid attempts; unless something in django can be used to have some logic (beyond locking accounts) where it is able to send a user to a sink hole or something based on # of exceptions per session or something. But that's beyond the scope of this request :)

Revision history for this message
Rob Cresswell (robcresswell-deactivatedaccount) wrote :

May have interpreted it wrong, but this seems more like a feature request? Marked as wishlist, for now :)

Changed in django-openstack-auth:
importance: Undecided → Wishlist
Revision history for this message
David M. Zendzian (dmz-r) wrote :

Yes it is a wishlist, I didn't know how to submit a wishlist; although it could almost be considered a security issue. :)

Revision history for this message
Lin Hua Cheng (lin-hua-cheng) wrote :

The fix has to be made to the horizon logger.

The application of the feature is not limited to login, for examples: user trying to access resources that they don't have privileges on.

Closing on DOA, and moving to Horizon

Changed in horizon:
importance: Undecided → Wishlist
Changed in django-openstack-auth:
status: New → Won't Fix
Matthias Runge (mrunge)
Changed in horizon:
status: New → Confirmed
no longer affects: django-openstack-auth
tags: added: low-hanging-fruit
Revision history for this message
Helber Maciel Guerra (helbermg) wrote :

I am submitting a possible solution for this.

The messages i change to:
"Login successful for user "%(username)s", remote address %(remote_ip)s."
and
"Login failed for user "%(username)s", remote address %(remote_ip)s."

The main variables involved with this information are HTTP_X_REAL_IP, HTTP_X_FORWARDED_FOR and REMOTE_ADDR, at this specific order.
To test this function i did a configuration.

The first one is using haproxy, and the specific configuration was set "option forwardfor except 127.0.0.1". The documentation can be found here: http://cbonte.github.io/haproxy-dconv/configuration-1.7.html#4-option%20forwardfor

The second one i did with nginx reverse proxy. The documentation can e found here: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header

Changed in horizon:
assignee: nobody → Helber Maciel Guerra (helbermg)
Revision history for this message
Julie Pichon (jpichon) wrote :
Changed in horizon:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

Fix proposed to branch: master
Review: https://review.openstack.org/372514

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/django_openstack_auth 3.1.0

This issue was fixed in the openstack/django_openstack_auth 3.1.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on horizon (master)

Change abandoned by Rob Cresswell (<email address hidden>) on branch: master
Review: https://review.openstack.org/372514
Reason: Abandoned due to inactivity

Revision history for this message
Rob Cresswell (robcresswell-deactivatedaccount) wrote :

Marking incomplete; its not really clear to me what is needed on the Horizon side at this point, and the patch wasn't maintained.

Changed in horizon:
status: In Progress → Incomplete
assignee: Helber Maciel Guerra (helbermg) → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.]

Changed in horizon:
status: Incomplete → Expired
Revision history for this message
George (lmihaiescu) wrote :

This patch works fine against python-django-openstack-auth (4.1-2) as packaged by Ubuntu 16.04 (Newton).

We find these changes VERY useful because they allow us to see the IP address behind successful or failed dashboard logins.

The info can be further be used by security tools like fail2ban that can block the IP address from further login attempts.

Is it possible for this patch to be merged into master and later back-ported to Newton?

Thank you.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Change abandoned by Rob Cresswell (<email address hidden>) on branch: master
Review: https://review.openstack.org/372514
Reason: Restored by accident, this has already been documented

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.