Public IP for Server remote management
-
@jaredbusch said in Public IP for Server remote management:
@ccwtech said in Public IP for Server remote management:
Would you ever put a public IP on remote server management (such as HP ILO, Dell DRAC, Lenovo Xclarity, etc.)
What level of security risk is that?
Huge security risk. I cannot imagine that those things are actually patched and current.
That's my take on it as well. I was so taken back that I wanted to make sure I wasn't up in the night.
-
@ccwtech said in Public IP for Server remote management:
I should have explained, I'm not trying to do it... I just had a conversation with an I.T. guy who does it that way and it made me thing about the insecurity of doing it and wanted a 'sounding board'.
Very big risk. Those systems are not just highly targetted, but almost impossible to secure and almost never patched or well maintained.
If it was behind a proxy, and locked to a single IP address, maybe. But even then, it is pushing it.
-
@jaredbusch said in Public IP for Server remote management:
@ccwtech said in Public IP for Server remote management:
Would you ever put a public IP on remote server management (such as HP ILO, Dell DRAC, Lenovo Xclarity, etc.)
What level of security risk is that?
Huge security risk. I cannot imagine that those things are actually patched and current.
Java client? Not current
-
@scottalanmiller This one doesn't use java, but still an issue.
-
@ccwtech said in Public IP for Server remote management:
@scottalanmiller This one doesn't use java, but still an issue.
Yeah, SuperMicro IPMI is better than most, but still not okay to expose in that way (other than for a lab.)
-
I suppose a solution to this could be setup a VM as a jump box, put it behind reverse proxy and NAT, and lock it down as much as you can (SSH keys, etc.). From that jump box, access your servers. I do something similar with my colo lab server, except I just have Zero Tier on said VM, and connect to it via SSH over Zero Tier.
The above won't solve the problem of somehow having out-of-band management capability / console access, which you could have with IPMI.
-
@eddiejennings said in Public IP for Server remote management:
I suppose a solution to this could be setup a VM as a jump box, put it behind reverse proxy and NAT, and lock it down as much as you can (SSH keys, etc.). From that jump box, access your servers. I do something similar with my colo lab server, except I just have Zero Tier on said VM, and connect to it via SSH over Zero Tier.
The above won't solve the problem of somehow having out-of-band management capability / console access, which you could have with IPMI.
Yes plenty of ways to do this the 'right way' but the I.T. company I was talking to doesn't get the risk of doing it the wrong way.
I was just running it by folks here to see if I was way off base by thinking they are nuts for making it public without any extra security.
-
@ccwtech said in Public IP for Server remote management:
@eddiejennings said in Public IP for Server remote management:
I suppose a solution to this could be setup a VM as a jump box, put it behind reverse proxy and NAT, and lock it down as much as you can (SSH keys, etc.). From that jump box, access your servers. I do something similar with my colo lab server, except I just have Zero Tier on said VM, and connect to it via SSH over Zero Tier.
The above won't solve the problem of somehow having out-of-band management capability / console access, which you could have with IPMI.
Yes plenty of ways to do this the 'right way' but the I.T. company I was talking to doesn't get the risk of doing it the wrong way.
I was just running it by folks here to see if I was way off base by thinking they are nuts for making it public without any extra security.
For my colo lab the thought of doing it the "wrong way" crossed my mind, but after a few moments of thinking it through (and trying to treat my colo lab server as much like a production system as I could), I came to the same conclusions as everyone else about it being a bad idea. -
HP used to say it was OK way back in the days because of authentication, encryption etc. What they say today I don't know.
But this is what the security researches says:
https://www.synacktiv.com/posts/exploit/rce-vulnerability-in-hp-ilo.htmlHP iLO is an administration tool, and as such should only be accessible from an isolated VLAN, different from the users' VLAN.
More specifically:- Do not connect iLO to your network if the interface is not actually used;
- Do not expose any iLO interface to any untrusted network;
- Use strong, randomly generated passwords for each server instance.
As a reminder, HP iLO 4 also exposes the IPMI interface on port 623. The IPMI v2 authentication protocol is affected by a design weakness that allows an attacker to retrieve a hash of the password, provided only the username is known. The hash can later be brute-forced off-line. This can not be patched or mitigated, except by proper network isolation.
Finally, as for every service running on a corporate network, iLO event logs should be centralized and monitored to detect unauthorized connections.
This is how easy it is to hack the iLO 4 if the server is running version < 2.54.
Version 2.54 was released September 2017. How many keep their ILO firmware up to date?
iLO 4 runs on G8 and G9 servers. -
I wouldn't place it on a Public IP, I would just manage it over Firewall Access Rules to locked down to few IP addresses or VPN.
-
@dbeato said in Public IP for Server remote management:
I wouldn't place it on a Public IP, I would just manage it over Firewall Access Rules to locked down to few IP addresses or VPN.
Agreed. This is how I handle was well.
