Secure connection to the server via ipmi

[Whattteva]

I don't want to have access to my entire local network. I only want to access the server's ipmi interface and be able to open a kvm or java console.
This is a single connection between my PC2 (outside the local network) to the server's IPMI interface via PC1 (in the local network). There are no other client (PC1 and PC2).

In that case, you can probably do:

Code:

AllowedIPs =
 10.0.0.1/32, 192.168.0.30/32, 192.168.0.40/32

Honestly, I don't know why you'd want to use the IPMI interface instead of just using SSH directly to the NAS itself.... it's much more comfortable working in a terminal than an IPMI interface and you'd probably get better support for copy/paste as well.

Actually, you may be able to get away with just

Code:

AllowedIPs = 192.168.0.40/32

But really, if I were you, I'd just pass the entire networks like my previous post and be done with it.

 

[danb35]

Honestly, I don't know why you'd want to use the IPMI interface instead of just using SSH directly to the NAS itself

Power control? Making networking changes? Access to the console if there's a network issue?

 

[Whattteva]

Power control? Making networking changes? Access to the console if there's a network issue?

Ok, I guess I wasn't thinking outside the box. I was thinking more along the lines, he just wants access to the console. Power control makes sense, but network issue? I would think he would want access to the router also, but he's not interested in accessing other IP's but just the IPMI? If it were me, I would want all the tools available to troubleshoot things like network issues.

In any case, SSH access would still be the first thing I'd think of for remote access, IPMI second because you'd be using SSH way way more often, but again, he's not interested in the NAS IP itself. Somehow I have an inkling that the shell for regular access is all he's trying to use... but of course, I could be dead wrong.

 

[danb35]

Somehow I have an inkling that the shell for regular access is all he's trying to use

...and it could be, and in that case I'd agree with you that SSH is a much better way to do it, whether on the LAN or remotely. But knowing how I use IPMI on my systems, there's definitely more to it.

 

[Nico052020]

Thank you for your feedback.

Power control? Making networking changes? Access to the console if there's a network issue?

@danb35 is right. It's to have access to the server before the OS start (power control, bios, sensor...), in case I need to intervene at that level.

You will find this strange, but there is a practical reason for it.
I access my shares and SSH via wireguard integrated in Truenas.
The problem I have is that in the time I have, I just have a laptop to create a connection to access the IPMI.
This laptop will one moment, go to sleep, be turned off, no battery... The person who will be in my house has no computer skills.
And me not much in the way of networking ;)
It's really a backup connection just in case.

 

[Nico052020]

@Whattteva

I would think he would want access to the router also,

actually, I hadn't thought to access the router. It's good idea. In my idea, it was to limit the access to the bare minimum, it is for this reason that I left like that.

 

[Nico052020]

I put in writing how I understand the thing:
You have to declare all IP addresses (or subnet) that will be connected to the PC2 (external local network) (in the [peer] section of the wireguard configuration file).
Initially, I thought that the two subnets (10.0.0.0 and 192.168.0.0) were distinct from each other.
And it is precisely the PC1 that transfer the data (up/down) in its "name" (10.0.0.1 within the VPN)
Now as I understand things, it is that we can directly address 192.168.0.40 (IPMI) as if PC1 did not exist.

 

[Whattteva]

I put in writing how I understand the thing:
You have to declare all IP addresses (or subnet) that will be connected to the PC2 (external local network) (in the [peer] section of the wireguard configuration file).
Initially, I thought that the two subnets (10.0.0.0 and 192.168.0.0) were distinct from each other.
And it is precisely the PC1 that transfer the data (up/down) in its "name" (10.0.0.1 within the VPN)
Now as I understand things, it is that we can directly address 192.168.0.40 (IPMI) as if PC1 did not exist.

AllowedIPs is just a way to tell Wireguard which packets to route and which ones to drop. If you leave 10.0.0.1/32, most likely you will not be able to access/ping the VPN gateway, but packets to other destinations should (theoretically) still be forwarded.

Disclaimer: I said theoretically there, because I have never actually tried that configuration as I typically always just pass subnets. In my opinion, the IP access restrictions are a bit silly. If someone already cracked your Wireguard auth, you have much bigger problems to worry about quite frankly, and cracking the routing is likely much easier for someone with that kind of skill.

 

[Patrick M. Hausen]

@Whattteva the "allowed_ips" wording is simply misleading. It's a routing statement. If you watch WireGuard start up, you can see that it adds exactly the networks in your "allowed_ips" into an interface route.

Why the named the parameter that way I don't know.

 

[Whattteva]

@Whattteva the "allowed_ips" wording is simply misleading. It's a routing statement. If you watch WireGuard start up, you can see that it adds exactly the networks in your "allowed_ips" into an interface route.

Why the named the parameter that way I don't know.

Yes, that's exactly what I said in my first sentence. I'm just trying to explain it in a way that is easier to digest.

 

[Patrick M. Hausen]

Sure. That was not a correction but what I thought was another attempt at a clarification. All good. WireGuard does not drop the other packets, though. It just installs the proper routes in the OS's routing table. The OS then decides which packets are handed off to WG and which ones go in some other direction, e.g. the default gateway.

 

[Whattteva]

Sure. That was not a correction but what I thought was another attempt at a clarification. All good. WireGuard does not drop the other packets, though. It just installs the proper routes in the OS's routing table. The OS then decides which packets are handed off to WG and which ones go in some other direction, e.g. the default gateway.

Yes, I understand the nuance, but for someone that doesn't understand the inner workings of networking, it's just much easier to say the non-routed packets as dropped. After all, the packet never reaches its intended destination. The end result is the same.

 

[Nico052020]

Hello,

AllowedIPs is just a way to tell Wireguard which packets to route and which ones to drop. If you leave 10.0.0.1/32, most likely you will not be able to access/ping the VPN gateway, but packets to other destinations should (theoretically) still be forwarded.

If you don't want to see the "AllowedIP" field as the allowed ip or ip range. How should it be understood?
Should this be seen as a data packet toll?
If it comes from this or that ip range, the packets pass the toll, if the IPs are not declared, the packets are "forgotten".

 

[Nico052020]

Hello,
I have a side question:
While browsing the tabs of the IPMI interface, I saw that you can put an SSL certificate in order to go through a secure https connection.
Does this solution provide as much security as a VPN connection? Would it be enough to ensure a secure connection to the remote IPMI interface?

I am currently testing everything we have discussed. I will keep you informed.

Regards

 

[Patrick M. Hausen]

Definitely no. SSL will encrypt the connection between the browser and the IPMI interface but just as well the connection between an adversary and the IPMI interface. You can still hammer on the IPMI web application 24x7 and I seriously doubt there will be no remotely exploitable flaws in that piece of software.

Think of how much computing power these BMCs have, how much effort goes into keeping the software current (ever installed an update?), how much public scrutinity is applied to these interfaces ... that's why in a commercial production environment you keep management interfaces in a completely separate network.

 

[Whattteva]

If you don't want to see the "AllowedIP" field as the allowed ip or ip range. How should it be understood?
Should this be seen as a data packet toll?
If it comes from this or that ip range, the packets pass the toll, if the IPs are not declared, the packets are "forgotten".

You can see it that way. Bottom line is, your packets don't get delivered if you don't specify its intended recipient there.

Hello,
I have a side question:
While browsing the tabs of the IPMI interface, I saw that you can put an SSL certificate in order to go through a secure https connection.
Does this solution provide as much security as a VPN connection? Would it be enough to ensure a secure connection to the remote IPMI interface?

I definitely wouldn't ever expose IPMI directly especially given the history of it. It's had some very bad vulnerabilities in the past.

 

[Nico052020]

Hello,

If you don't want to see the "AllowedIP" field as the allowed ip or ip range. How should it be understood?
Should this be seen as a data packet toll?
If it comes from this or that ip range, the packets pass the toll, if the IPs are not declared, the packets are "forgotten".

You can see it that way. Bottom line is, your packets don't get delivered if you don't specify its intended recipient there.

edit: @Patrick M. Hausen

Definitely no. SSL will encrypt the connection between the browser and the IPMI interface but just as well the connection between an adversary and the IPMI interface. You can still hammer on the IPMI web application 24x7 and I seriously doubt there will be no remotely exploitable flaws in that piece of software.

Sorry my question was not about the application but about the version accessible via the web browser. But maybe the answer is the same



Is there any point in making an "https" connection within the VPN tunnel? (or totally superfluous)

ps: I have started to configure my nas and the network, I will soon move to the vpn part.

 

[Whattteva]

Sorry my question was not about the application but about the version accessible via the web browser. But maybe the answer is the same.

Sorry, not really sure what youre asking here. What exactly are you referring to by "version"?

Is there any point in making an "https" connection within the VPN tunnel? (or totally superfluous)

Some people here may disagree, but i don't bother with https because I implicitly trust my LAN.

And honestly, if some bad actor manages to get through my VPN handshake, they probably have enough technical know how to do anything they want probably, and I have other far bigger problems to worry about.

 

[Nico052020]

Sorry my question was not about the application but about the version accessible via the web browser. But maybe the answer is the same.

Sorry, not really sure what youre asking here. What exactly are you referring to by "version"?

it's my fault, I made a bad copy-paste. (post #37)

 

[Patrick M. Hausen]

Sorry my question was not about the application but about the version accessible via the web browser. But maybe the answer is the same
Is there any point in making an "https" connection within the VPN tunnel? (or totally superfluous)

I was referring to the web application that is part of the IPMI firmware. And common sense dictates that is inherently insecure. HTTPS is only transport encryption, no authentication. If you open the web application via HTTPS to the Internet you have no protection at all. What does it change that the attackers attempts are encrypted?

Second, as always - it depends. So if HTTPS is cumbersome to set up because of quirky IPMI firmware and you have a VPN connection, you are mostly fine. If you have an adversary in your home network they can probably steal your login credentials for the IPMI. So in a corporate environment I would use HTTPS even with a VPN.