Recursive graylog license violation


(fjavier c.) #1

Hi folks,

Here Fco. Javier, searching some help.

We have been testing Graylog for a month with the free Enterprise license (5GB per day) but we are constantly receiving license violation messages (Graylog Enterprise License Violation).

Consulting the log file ‘server.log’ only shows us the following records:

2018-07-20T13: 42: 15.775 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 123, limit: 72
2018-07-20T13: 42: 15.777 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-20T13: 42: 15881 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 123, limit: 72
2018-07-20T13: 42: 15882 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-20T13: 46: 21.116 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 123, limit: 72
2018-07-20T13: 46: 21.117 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-20T13: 46: 22.006 + 02: 00 WARN [LicenseReportPeriodical] License server response is invalid.
2018-07-20T13: 50: 07.638 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 124, limit: 72
2018-07-20T13: 50: 07.639 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-20T13: 51: 21.118 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 124, limit: 72
2018-07-20T13: 51: 21.119 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-20T13: 56: 21.110 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 124, limit: 72
2018-07-20T13: 56: 21.111 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-20T13: 58: 27.993 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 124, limit: 72
2018-07-20T13: 58: 27.994 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-20T14: 01: 21.107 + 02: 00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 124, limit: 72
2018-07-20T14: 01: 21.108 + 02: 00 WARN [LicenseChecker] License violation - Detected irregular traffic records
[…]
2018-07-25T08:35:38.263+02:00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 96, limit: 72
2018-07-25T08:35:38.264+02:00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-25T08:36:07.352+02:00 WARN [LicenseChecker] License violation - Failed to report license status to Graylog, Inc. - consecutive failures: 96, limit: 72
2018-07-25T08:36:07.354+02:00 WARN [LicenseChecker] License violation - Detected irregular traffic records
2018-07-25T08:36:08.037+02:00 WARN [LicenseReportPeriodical] License server response is invalid.

In the Web console, the messages that appear are like:

  • Graylog Enterprise License Violation. At least one term of your Graylog Enterprise license has been violated. Go to the License page for more information or contact your Graylog account manager.

  • License is violated! Daily traffic limit: 5.0GB (allowed violations per 30 days: 5)

  • Remote checks have failed too many times. Requires remote checks: Yes (allowed consecutive check failures: 124 ). License expiration warning: 30 days before

Although our servers go to the Internet through proxy, we have allowed access to api.graylog.com so that the connection is direct, without going through proxy, and even then we have the same problems. From the Graylog server, from a console, we can connect without problems to hxxps://api.graylog.com. See attached file… ups… can not attach :yum:

root@SuperGrey:~# curl -v hxxps://api.graylog.com/releases/active

  • Trying 34.206.36.121…
  • TCP_NODELAY set
  • Connected to api(.)graylog(.)com (34.206.36.121) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.2 (OUT), TLS header, Certificate Status (22):
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS change cipher, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, server accepted to use http/1.1
  • Server certificate:
  • subject: CN=api(.)graylog(.)com
  • start date: Jun 22 23:25:22 2018 GMT
  • expire date: Sep 20 23:25:22 2018 GMT
  • subjectAltName: host “api(.)graylog(.)com” matched cert’s “api(.)graylog(.)com”
  • issuer: C=US; O=Let’s Encrypt; CN=Let’s Encrypt Authority X3
  • SSL certificate verify ok.

GET /releases/active HTTP/1.1
Host: api(.)graylog(.)com
User-Agent: curl/7.52.1
Accept: /

< HTTP/1.1 200 OK
< Server: Cowboy
< Connection: keep-alive
< Date: Fri, 20 Jul 2018 12:16:17 GMT
< Content-Type: application/json
< Vary: Accept-Encoding
< Content-Length: 227
< Via: 1.1 vegur
<

root@SuperGrey:~#

The last thing we have done has been to update to version 2.4.6 and try connecting through our proxy, configuring http_proxy_uri, http_non_proxy_hosts and increasing the timeout values ( http_read_timeout, http_connect_timeout ). It worked fine two days but again we have the license violation messages.

Ahh … and our log volume is 2GB/day

We no longer know what else to look at. We have consulted the forum and we have not been able to solve the problem either. Can someone help us or give us any hint ?

Regards,


(bernd) #2

@fjavier07 This still looks like a proxy issue. The message above indicates that something is either replaying a previous result from api.graylog.com or that something modifies the response in-flight.

All other warnings are the result of the failing license report requests.

Are there any transparent proxies in your network?


(fjavier c.) #3

Hi bernd;

During the last 4 days the license has been checked correctly but again we have the happy problem.

I have been able to confirm that the existing Internet access in the WAN is through a transparent proxy and we can do little about it.

Any possible idea or workaround is appreciated.


(bernd) #4

Not for the free license, sorry. Our paid license options include the possibility to disable the remote check requirements.


(fjavier c.) #5

Hello everybody!

Thanks Bernd for the information.

For all others, if it can help; comment that in the end I installed again the operating system, graylog, the other necessary software and applied the same configuration I had and since then, all correct, no error message regarding license violation (only sporadic warning).

It is very strange because we have not changed anything, I imagine that in the old installation of graylog something we could do wrong (although we have followed our same notes) or something could be corrupted.

PS: I hope it continues like this :slight_smile:


(bernd) #6

@fjavier07 We just found a possible cause for the error you have been seeing.

If your graylog server has a skewed clock, parsing the license report response failed. This issue has been corrected in our API server that receives the license report and it shouldn’t happen again in the future.

Reinstalling the OS probably helped in your case because the newly installed server had a correctly synced clock.