Set ip on http monitors like curl resolve command

Elastic Stack Beats
1

I want to monitor https service. (domain - VIP - webserver)
testing domain(VIP) is clear. just call "https://domain".

but testing webserver has a problem, guessing from SNI(Server Name Indication).
Calling "https://webserver" returned "unexpected EOF"

in curl command, there is a option, "--resolve domain:ip" for chaning ip for domain.
so how to set .yml like "curl --resovle" command?

2

Hi @oofbird,

There are a few alternatives, depending on the setup:

  • First I'd make sure it's a SNI problem, does curl <IP> --resolve <domain> work as expected?
  • What's the response from VIP like, cached content or redirections? If it's a redirect, you could configure max_redirects and heartbeat will follow them to the end server.

Hearbeat does not support custom SNI negotiation at the moment, it uses provided host for the request. I know it's not ideal but, if you don't need to perform tls verification on the webserver, you can skip SNI by setting ssl.verification_mode: none and setting request Host headers . Something like this:

urls: ["https://<my server ip>"]
  check.request:
    method: GET
    headers:
      Host: "<my domain>"
      X-Forwarded-Host: "<my domain>"
  ssl.verification_mode: none
3

Thx with reply.

curl -X GET https://test.domain.com:1443 --resolve test.domain.com:1443:123.123.123.123 retured 'HTTP 200 OK'

But, curl -X GET https://123.123.123.123:1443 returned 'OpenSSL SSL_connect: SSL_ERROR_SYSCALL'.
ignore option in curl was same. (curl version 7.64.0)
(in curl Version 7.29.0, it returned 'Encountered end of file)

I`m not sure, but there is a problem with TLS handshake...

running curl --resovle with verbose, it said

Added test.domain.com:1443:123.123.123.123 to DNS cache
Hostname test.domain.com was found in DNS cache
   Trying 123.123.123.123...

is there a function liked this?

4

Hi @oofbird,

I'd say curl output confirms it's SNI.

Unfortunately, heartbeat does not have a simil --resolve option atm. If you'd like to see this feature added to heartbeat, I'd like to ecourage you to open an enhancement request over our beats repo and we will be able to analyze it internally.

In the mean time,there might be ways to work around this limitation, with some caveats. For one, you could disable tls verification in heartbeat.yml for that specific monitor. This is an example:

- type: http
  id: my-monitor
  name: My Monitor
  schedule: '@every 10s'
  urls: ["https://<my webserver ip>"]
  ssl.verification_mode: none
  check.request:
    method: GET
    headers:
      Host: "<my SNI domain>"
      X-Forwarded-Host: "<my SNI domain>"

With ssl.verification_mode: none and check.request.headers, heartbeat will bypass SNI and request the correct domain from the end server. On the other hand, it won't verify server's certificate validity, so that information won't be attached to the monitor result.

5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.