Getting spam on log : Invalid 'Authorization' header, send 401 and 'WWW-Authenticate Basic'

Security
1

Hi everyone. I’m getting spam log in elasticsearch log

[2021-05-11T16:52:01,532][WARN ][c.a.o.s.h.HTTPBasicAuthenticator] [master-node] Invalid 'Authorization' header, send 401 and 'WWW-Authenticate Basic'

Do you guys have any idea about this? :frowning:

2

Could you share your config.yml file?
My guess is that you have setup multiple authentication backends, including basic_auth (internal db) with order 0 and openid/saml/kerberos/? with order 1,2…

The way authentication works is trying to authenticate with each of the ways you have defined, in the order you have defined them. So it will first try basic_auth and fail (as per your log message) then try e.g. openid and succeed.

The plugin supports chaining backends in securityconfig/config.yml . If more than one backend is present, the plugin tries to authenticate the user sequentially against each until one succeeds. A common use case is to combine the internal user database of the security plugin with LDAP/Active Directory.

More on authentication flow.

1 Like
3

Yes. Here is my config.yml ( mostly it is default since i remember i haven’t touch to this file xD )

---
_meta:
  type: "config"
  config_version: 2
config:
  dynamic:
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: "192\\.168\\.0\\.10|192\\.168\\.0\\.11"
    authc:
      kerberos_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 6
        http_authenticator:
          type: "kerberos"
          challenge: true
          config:
            krb_debug: false
            strip_realm_from_principal: true
        authentication_backend:
          type: "noop"
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          type: "basic"
          challenge: true
        authentication_backend:
          type: "intern"
      proxy_auth_domain:
        description: "Authenticate via proxy"
        http_enabled: false
        transport_enabled: false
        order: 3
        http_authenticator:
          type: "proxy"
          challenge: false
          config:
            user_header: "x-proxy-user"
            roles_header: "x-proxy-roles"
        authentication_backend:
          type: "noop"
      jwt_auth_domain:
        description: "Authenticate via Json Web Token"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: "jwt"
          challenge: false
          config:
            signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
            jwt_header: "Authorization"
            jwt_url_parameter: null
            roles_key: null
            subject_key: null
        authentication_backend:
          type: "noop"
      clientcert_auth_domain:
        description: "Authenticate via SSL client certificates"
        http_enabled: false
        transport_enabled: false
        order: 2
        http_authenticator:
          type: "clientcert"
          config:
            username_attribute: "cn"
          challenge: false
        authentication_backend:
          type: "noop"
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: false
        transport_enabled: false
        order: 5
        http_authenticator:
          type: "basic"
          challenge: false
        authentication_backend:
          type: "ldap"
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - "localhost:8389"
            bind_dn: null
            password: null
            userbase: "ou=people,dc=example,dc=com"
            usersearch: "(sAMAccountName={0})"
            username_attribute: null
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: "ldap"
          config:
            enable_ssl: false
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
            - "localhost:8389"
            bind_dn: null
            password: null
            rolebase: "ou=groups,dc=example,dc=com"
            rolesearch: "(member={0})"
            userroleattribute: null
            userrolename: "disabled"
            rolename: "cn"
            resolve_nested_roles: true
            userbase: "ou=people,dc=example,dc=com"
            usersearch: "(uid={0})"
      roles_from_another_ldap:
        description: "Authorize via another Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: "ldap"

I’m thinking about disable all of them since i only used auth from user created by api :smiley:

4

Yes, it’s better if you disable (or actually just delete) all the config entries you don’t use (both from authc and authz). Remember to run securityadmin.sh script to reflect the config in the cluster, once you modify it.

So, you don’t use Kibana at all and only create users in the internal database (through API) and authenticate through that with user/pass on your ‘curl’ calls?

1 Like
5

I used kibana too, but with the only user create by API or via kibana dashboard :smiley:

Yes, I’m gonna test it carefully before runs:smiley:

I will give feedback soon if error above still appear
Thank you :smiley:

6

Hmm i just look again, it all already disable by http_enabled: false :frowning: