Connect to remote agent via reverse proxy? 🤔

Icinga 2
,
1

Hi everyone!

I’d like to connect a remote agent via a http(s) reverse proxy. It’s a http based API so that’s generally doable. I’m actually doing that locally with an Icinga2 client (aNag) and it works really well, so I suppose it should be feasible with an agent as well.
However, I couldn’t find how a possible connection would have to be configured in Icinga2. Could you even do that with the wizard? :man_shrugging:

Cheers
Bebef

2

Hi,

the connection between master and agent uses JSON-RPC internally, I don’t think that you can put a reverse proxy in between. Also keep in mind that there are strong certificate requirements, the master will close the connection if the agent answers with a self signed or a wrong certificate.

What would be your goal with such a setup, maybe there is a different approach to achieve the same?

Best regards
Michael

3

Hi Michael,

I don’t want to expose port 5665 publicly for security reasons, so I’m looking into alternate ways of connecting. Other approaches are ssh tunneling and VPN, but I would rather like to keep it as simple as possible.

Cheers

4

In what way is exposing 5665 via a reverse proxy, which then passes on to your
Icinga Master, more secure than just exposing 5665 on the Master itself?

Antony.

5

If you really don’t want to expose ports there is no way around VPN.

You can use a satellite in between your agents and your master to “bundle” the connections from your agents. The agents are connected to your satellite and the satellite is connected to your master. You only have to open the 5665 port on your master or your satellite, this depends on your connection direction. Have a look into the three level cluster setup in the documentation.

https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#three-levels-with-masters-satellites-and-agents

Best regards
Michael

1 Like
6

Hiding the API behind a reverse proxy is defenitively possible. I have already done this, but I have never tried to connect a satellite to it. If you do it this way you might get a little more security, because you don’t give a potential attacker any hint what is hiding behind the HTTPS port. But this scenario is not supported. By using port 443 it also gets easier to get a firewall enabling in many companies.

7

Hi,

I played around a bit and came up with a possible solution. You can use NGINX to create a proxy for TCP connections.

I just did this in two docker containers to test it, the master container connects to the agent container. On the agent I set up NGINX to proxy incoming TCP traffic on port 5667 to port 5665 locally.

# vim /etc/nginx/nginx.conf

[...]
stream {
	server {
		listen 5667;
		proxy_pass 127.0.0.1:5665;
	}
}
[...]

I configured the master to use the port 5667 when connecting to the agent.

# vim /etc/icinga2/zones.conf

object Endpoint "deb10i2a1s" {
	host = "172.17.0.3"
	port = 5667
}

object Zone "deb10i2a1s" {
	parent = "master"
	endpoints = [ "deb10i2a1s" ]
}

Starting both Icinga 2 daemons and NGINX on the agent you can see the incoming connection in the agents Icinga 2 log and verify that the connection is proxied (it is coming from localhost/127.0.0.1).

[2020-03-28 19:09:56 +0000] information/ApiListener: New client connection for identity 'deb10i2m1s' from [127.0.0.1]:47416

This is by far not a well tested solution and I don’t know which side effects may occur. I would consider this a technical concept, maybe this will help you with further investigations.

Best regards
Michael

1 Like
8

Why don’t you let just the agents connect to their parents? In this case agents do not need to have that port listening.

9

@Bebef there are many possible solutions (or workarounds), but to chosse the right one we need a full description of your use case.

10

Brilliant, I can work with the configuration snippet. I guess using this I’d be able to use an SSH tunnel for connecting.

Thanks!