topic how to relate unsuccessful login id and public ip address of horizon login for openstack log? in Security

how to relate unsuccessful login id and public ip address of horizon login for openstack log?

cyberportnoc — Fri, 29 Jul 2016 07:04:01 GMT

“err=49” is the OpenLDAP error code for unauthorized login.

Mar 21 14:43:51 icns01 slapd[2344]: conn=255737 op=0 RESULT tag=97 err=49 text=

Mar 21 14:43:52 iccontroller01 keystone-pub-api: 192.168.1.2, 192.168.1.1 - - [21/Mar/2016:14:43:51 +0800] "POST /v2.0/tokens HTTP/1.1" 401 114 "-" "python-keystoneclient"

Mar 21 14:43:51 iccontroller02 horizon: 203.120.232.223 - - [21/Mar/2016:14:43:51 +0800] "POST /auth/login/ HTTP/1.1" 200 1239 "https://hello.hk/auth/login/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0

i use datetime to join that there is one second difference lead join unsuccessful,
after exclude seconds to join , it succeed to join,

however, if i argue that there is difference account and log in the same minute, then the join result will have problem

Re: how to relate unsuccessful login id and public ip address of horizon login for openstack log?

woodcock — Sun, 31 Jul 2016 13:26:40 GMT

You need to explain which data is from which index/sourcetype and also share the search(es) that you are using.

Re: how to relate unsuccessful login id and public ip address of horizon login for openstack log?

acharlieh — Sun, 31 Jul 2016 18:48:48 GMT

Instead of attempting to join, you may want to try your hand with the transaction command. All fields from all events grouped together would then be on the grouped event. You have finer control over the length of a transaction for example using maxspan=2s instead of 1 second or 1 minute resolution. You can also use startswith= and endswith= and maxevents= to help with shaping how the events should be grouped together.

If you have control over the log formats and data being passed between systems, you may want to alter logging to include more information at each layer (possibly adding username at more layers, or possibly even a generated correlation id)... this will help your transaction (or stats or join) results be more accurate as you correlate disparate logs, but obviously that's a function of the level of control you have over the source systems and their interactions.