ILO 3 1.82

[Ravager1]

It seems that both powershell and rhloe scripting gets broken when you upgrade a ilo3 to 1.82.

I have the option of going back to 1.8 (which restores functionality) or waiting for a newer version to fix this.

Only problem is how can I automate several hundred blade firmware changes when scripting is broken?

Also anyone have any ideas of a workaround or a way to fix the broken functionality>?

[Oscar A. Perez]

What scripting tool are you using? 

We were forced to disable SSLv3 in all our iLO because, the lazy port scanners began flagging iLOs as vulnerable to POODLE.  (POODLE is a MITM vulnerability that can only be exploited on Web Browsers that support SSLv3, not webservers. And these port scanners cannot test web browsers so they turned their attention to the webservers).

If you are using the hponcfg from the OA CLI, you need to upgrade OA to version 4.30 or later.  The hponcfg in older OA versions only used SSLv3 to connect to iLO.

[Dennis Handly]

>We were forced to disable SSLv3 in all our iLO because, the lazy port scanners began flagging iLOs as vulnerable to POODLE.

That's NOT how the security mindset works.  If you provide telnet access to iLO and a customer uses it, who gets dinged as a security flaw?

So if you disallow SSLv3, problem is gone.

[Oscar A. Perez]

---

@Dennis Handly wrote:

>We were forced to disable SSLv3 in all our iLO because, the lazy port scanners began flagging iLOs as vulnerable to POODLE.

That's NOT how the security mindset works.  If you provide telnet access to iLO and a customer uses it, who gets dinged as a security flaw?

So if you disallow SSLv3, problem is gone.

---

Speaking of security mindset, how do you explain that these very same lazy port scanners that are making a big deal about POODLE won't even warn users with Self-Signed SSL Certificates that as long as they  have those Certs in place, they are vulnerable to MITM attacks regardless of POODLE?

Any adversary with 2 inches of forehead isn't going to waste one second trying to exploit any of these scary MITM attacks with All-CAPS letters we read on the news, if your webserver is presenting an "untrusted" SSL Certificate.  All the attacker needs to do is to create a fake Cert with your server info in the Subject and then, present that fake certificate to users who will gladly ignore the annoying browser warnings about untrusted websites. 

And yet, these scanners flag POODLE as high risk but, where in the scanner report do you find a warning that your users could be just one-click away from allowing MITM attackers to take over their SSL/TLS connections because of the use of "untrusted" SSL Certificates in their environment?

Sorry but, it is not the security mindset what drives these port scanner companies, it is the profit motive.  Reporting issues that require their own customer base to do painful configuration changes to their entire environment (setting up a PKI and issue certs for everything) does not sell.  What sells is to flag third party vendors as vulnerable, even when isn't true or, when there are simple configuration changes can take care of the problem without breaking backward compatability like in this case.  

[user5000]

Oscar, I know this is an old post, but how did you disable SSL3 on ILO3? We tried the "Enforce AES/3DES Encryption" option in the GUI, but SSL3 is still enabled after this.

From what I can tell, you have to disable SSL3 through the ILO command line, but I'm unable to find any information on how to do this.

If you remember the specific command or can point me in the right direction, that would be very helpful.

Thanks