so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% of the time i want it blocked off. but that other 1%, i want kvm console, remote media, and dim sum. currently, i just block the ip address chunk into which i put ipmi at the border of the rack. when i want access, i reconfig the acl. bit of a pita. anyone care to share better idea(s)? thanks. randy
I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi. On Jun 2, 2014 7:13 AM, "Randy Bush" <randy@psg.com> wrote:
so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% of the time i want it blocked off. but that other 1%, i want kvm console, remote media, and dim sum.
currently, i just block the ip address chunk into which i put ipmi at the border of the rack. when i want access, i reconfig the acl. bit of a pita.
anyone care to share better idea(s)? thanks.
randy
On 6/2/2014 午後 09:19, Andrew Latham wrote:
I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi. On Jun 2, 2014 7:13 AM, "Randy Bush" <randy@psg.com> wrote:
so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% of the time i want it blocked off. but that other 1%, i want kvm console, remote media, and dim sum.
currently, i just block the ip address chunk into which i put ipmi at the border of the rack. when i want access, i reconfig the acl. bit of a pita.
anyone care to share better idea(s)? thanks.
randy
Depends. On most ATEN chip based BMC boards from Supermicro, it includes a UI to iptables that works in the same way. You could put it on a public net, allow your stuff and DROP 0.0.0.0/0. But unless you have servers with those, I think the best way to go is putting them on internal IPs and then using some sort of a VPN.
On 2014-06-02 14:23, Paul S. wrote: [..]
On most ATEN chip based BMC boards from Supermicro, it includes a UI to iptables that works in the same way.
You could put it on a public net, allow your stuff and DROP 0.0.0.0/0.
But unless you have servers with those, I think the best way to go is putting them on internal IPs and then using some sort of a VPN.
While you are typing the iptables command, do a check of the software versions, typically they are running a decade old kernel and a lot of unpatched software that is exposed. You really do not want to run that on the Interwebs, just the idea of any packet arriving to such a kernel is scary. Relevant good reads: http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn https://plus.google.com/+TobiasDiedrich/posts/Bq44KkBT3vK The first URL references 2.6.17, yes... *2.6.17* is the CURRENT version of the kernel running on most IPMIs out there. http://kernelnewbies.org/Linux_2_6_17 - Released 17 June, 2006 8 years... ouch, yeah, no way that is going to be attached to a public network... Thus please, don't shoot yourself in the foot with that and more importantly don't shoot the rest of the Internet in the foot as they'll receive the packets. Note: the IPMI that Michael describes is on a unrouted VLAN, the access to the OpenVPN port that he runs on the IPMI happens through SSH on a jumpbox which is ACLd away. Greets, Jeroen (who is still awaiting for Zeus4IPMI)
True, excellent point as well. Multiple openvpn/ipsec entry points on a internal network is probably the best way to go. On 6/2/2014 午後 09:33, Jeroen Massar wrote:
On 2014-06-02 14:23, Paul S. wrote: [..]
On most ATEN chip based BMC boards from Supermicro, it includes a UI to iptables that works in the same way.
You could put it on a public net, allow your stuff and DROP 0.0.0.0/0.
But unless you have servers with those, I think the best way to go is putting them on internal IPs and then using some sort of a VPN. While you are typing the iptables command, do a check of the software versions, typically they are running a decade old kernel and a lot of unpatched software that is exposed. You really do not want to run that on the Interwebs, just the idea of any packet arriving to such a kernel is scary.
Relevant good reads: http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn https://plus.google.com/+TobiasDiedrich/posts/Bq44KkBT3vK
The first URL references 2.6.17, yes... *2.6.17* is the CURRENT version of the kernel running on most IPMIs out there.
http://kernelnewbies.org/Linux_2_6_17 - Released 17 June, 2006
8 years... ouch, yeah, no way that is going to be attached to a public network...
Thus please, don't shoot yourself in the foot with that and more importantly don't shoot the rest of the Internet in the foot as they'll receive the packets.
Note: the IPMI that Michael describes is on a unrouted VLAN, the access to the OpenVPN port that he runs on the IPMI happens through SSH on a jumpbox which is ACLd away.
Greets, Jeroen
(who is still awaiting for Zeus4IPMI)
The kernel is the least of your worries here. This is what you can expect from the Supermicro controllers: Linux Kernel 2.6.17.13 Lighttpd 1.4.32 pcre 8.31 pcre 8.33 msmtp 1.4.16 tree 1.5.2.2 flex 2.5.35 readline 5.2 termcap 1.3.1 BIND 9.8.1-P1 busybox 1.12.0 ntp 4.2.4p4 openssl 0.9.8h openlldp 0.3alpha wide-dhcpv6 20080615 openldap 2.4.11 zlib 1.2.3 glibc 2.3.5 gcc 3.4.4 libxml2 2.6.32 On 6/2/2014 8:33 AM, Jeroen Massar wrote:
On 2014-06-02 14:23, Paul S. wrote: [..]
On most ATEN chip based BMC boards from Supermicro, it includes a UI to iptables that works in the same way.
You could put it on a public net, allow your stuff and DROP 0.0.0.0/0.
But unless you have servers with those, I think the best way to go is putting them on internal IPs and then using some sort of a VPN. While you are typing the iptables command, do a check of the software versions, typically they are running a decade old kernel and a lot of unpatched software that is exposed. You really do not want to run that on the Interwebs, just the idea of any packet arriving to such a kernel is scary.
Relevant good reads: http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn https://plus.google.com/+TobiasDiedrich/posts/Bq44KkBT3vK
The first URL references 2.6.17, yes... *2.6.17* is the CURRENT version of the kernel running on most IPMIs out there.
http://kernelnewbies.org/Linux_2_6_17 - Released 17 June, 2006
8 years... ouch, yeah, no way that is going to be attached to a public network...
Thus please, don't shoot yourself in the foot with that and more importantly don't shoot the rest of the Internet in the foot as they'll receive the packets.
Note: the IPMI that Michael describes is on a unrouted VLAN, the access to the OpenVPN port that he runs on the IPMI happens through SSH on a jumpbox which is ACLd away.
Greets, Jeroen
(who is still awaiting for Zeus4IPMI)
In addition I will suggest multiple paths (oobm) to the network. IE VPN via second provider network. On Jun 2, 2014 7:26 AM, "Randy Bush" <randy@psg.com> wrote:
I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi.
hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i may use it, as i already do openvpn. thanks.
randy
Multiple points of entry into the VPN mesh? When you need to muck with concentratorA's ipmi, use b, c, or d. Sent from my iPhone On Jun 2, 2014, at 8:26, Randy Bush <randy@psg.com> wrote:
I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi.
hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i may use it, as i already do openvpn. thanks.
randy
On Mon, Jun 2, 2014 at 8:26 AM, Randy Bush <randy@psg.com> wrote:
I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi.
hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i may use it, as i already do openvpn. thanks.
So, kinda the same idea - just put IPMI on another network and use ssh forwards to it. You can have multiple boxes connected in this fashion but the point is to keep it simple and as secure as possible (and IPMI security doesn't really count here :) ). Kinda funny though - I've all of the findings have been for newer IPMI. So, I had (have) an HP DL380g5 and didn't feel like resetting the iLo2 password manually. Well, everything I could find for dumping info from iLo was for iLo3... go figure. (I still wouldn't put it on the net)
Once upon a time, shawn wilson <ag4ve.us@gmail.com> said:
So, kinda the same idea - just put IPMI on another network and use ssh forwards to it. You can have multiple boxes connected in this fashion but the point is to keep it simple and as secure as possible (and IPMI security doesn't really count here :) ).
For basic IPMI, SSH forwards will work, but some of the web/Java based KVM-over-IP on IPMI BMCs tend to not work well with that. For IPMI things like power control and serial-over-LAN, I put the IPMI on a separate VLAN (most semi-recent BMCs can handle a VLAN tag) and then just use "ipmitool" on a Linux system connected to the same VLAN (no port-forwarding or VPN required). I only use a VPN-type setup when I need to use a KVM console. -- Chris Adams <cma@cmadams.net>
On Mon, Jun 2, 2014 at 8:21 AM, shawn wilson <ag4ve.us@gmail.com> wrote: [snip]
So, kinda the same idea - just put IPMI on another network and use ssh forwards to it. You can have multiple boxes connected in this fashion but the point is to keep it simple and as secure as possible (and IPMI security doesn't really count here :) ).
About that "as secure as possible" bit. If just one server gets compromised that happens to have its IPMI port plugged into this private network; the attacker may be able to pivot into the IPMI network and start unloading IPMI exploits. So caution is definitely advised, about security boundaries: in case a shared IPMI network is used, and this is a case where a Private VLAN (PVLAN-Isolated) could be considered, to ensure devices on the IPMI LAN cannot communicate with one another --- and only devices on a separate dedicated IPMI Management station subnet can interact with the IPMI LAN. -- -JH
On Mon, Jun 2, 2014 at 7:42 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On Mon, Jun 2, 2014 at 8:21 AM, shawn wilson <ag4ve.us@gmail.com> wrote: [snip]
So, kinda the same idea - just put IPMI on another network and use ssh forwards to it. You can have multiple boxes connected in this fashion but the point is to keep it simple and as secure as possible (and IPMI security doesn't really count here :) ).
About that "as secure as possible" bit. If just one server gets compromised that happens to have its IPMI port plugged into this private network; the attacker may be able to pivot into the IPMI network and start unloading IPMI exploits.
Generally, I worry about workstations with access being compromised more than I do about a server running sshd and routing traffic. But obviously, if someone gets access, they can cause play foosball with your stuff.
So caution is definitely advised, about security boundaries: in case a shared IPMI network is used, and this is a case where a Private VLAN (PVLAN-Isolated) could be considered, to ensure devices on the IPMI LAN cannot communicate with one another --- and only devices on a separate dedicated IPMI Management station subnet can interact with the IPMI LAN.
I can't really argue against the proper use of vlans (and that surely wasn't my point). I was merely saying that you can use ssh as a simpler solution (and possibly a more secure one since there's not a conduit to broadcast to/from) than a vpn. That's it.
I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi. hmmmm. 'cept when it is the openvpn server's ipmi. but good hack. i may use it, as i already do openvpn. thanks.
randy What you can also do if you want to remove the dependence on the OpenVPN server (e.g. smaller networks where the overhead would be high, or to mitigate failures of the OpenVPN server) is to use your existing pattern of whitelisting IPs using ACLs, but instead of modifying the rules all
On 06/02/2014 08:26 AM, Randy Bush wrote: the time, just run a small external server with a static IP, and allow that IP access through all of your ACLs. Amazon EC2 instances are great for this. Assign an Elastic IP (i.e. static IP), and turn the instance on when you need it, shut it down when you're done. If there happens to be a failure at Amazon right at the same time you have a failure... spin up a new instance in a different zone and give it the Elastic IP. No mucking about with ACLs, etc. Costs a few cents to run for whatever length of time it takes to fix your issue, and is reasonably secure (especially if you shut the box off when you're not using it). - Peter
On 2014-06-02 07:19, Andrew Latham wrote:
I use OpenVPN to access an Admin/sandboxed network with insecure portals, wiki, and ipmi.
Same here. My entire in band management plane (DRAC (disk/cpu/temperature etc telemetry to my OpenManage/Zenoss server), OpenSSH and 80/443 for backend stuffs) is all behind OpenVPN. Zero outside exposure. Out of band, is a cyclades (acs48) directly on the internet with all my consoles hooked up and it controls daisy chained Cyclades PDUs. I have fairly strong passwords on it, everything is SSH. How important is it to setup ACLs on it? Like say some VPS that's outside my infra and lock the Cyclades down to that? Is that really a much higher level of security?
On 2014-06-02 14:10, Randy Bush wrote:
so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% of the time i want it blocked off. but that other 1%, i want kvm console, remote media, and dim sum.
currently, i just block the ip address chunk into which i put ipmi at the border of the rack. when i want access, i reconfig the acl. bit of a pita.
Depends on how many boxes you have at the same location. If you only have one, that is likely the way to go, if you have a few more, use one or multiple (backup :) VMs on the boxes as management access, properly ACL that away, put OpenVPN on it, route the IPMI network on that presto. Of course, the IPMI boxes should always live in their own VLAN where possible, and those VLAN addresses should never be routed publicly or NATted to anything public. With the OpenVPN trick or whatever your VPN tool of choice is, you don't have to NAT mind you. Do note that if you have multiple mgmt/access boxes you should have a floating gateway IP and/or bridge that network onto your VPN. Bridging is typically easier also as it avoids having to configure a default gateway which again avoids all kinds of accidental typos. Do note that the above does not allow you access if the datacenter's switching or routing is borked too heavily, hence a GSM/4G backup USB stick in the management box to allow 'dial in'[*] can be useful too ;) That is of course if there is signal in the datacenter... Greets, Jeroen [*] Cheap variant: get a 4G USB stick with a pre-paid number, set it up so that you can SMS to it, and that based on the SMS (src-number verify etc) it connects to the network and contacts a remote OpenVPN, configures that VPN and voila, you are in. [*] If you don't want extra services like OpenVPN, keep in mind that ACLs keeps baddies out and that one can alternatively do tunneling in a similar method with sshd (and key restrictions to not allow them anything else ;)
My IPMI (super micro) you can put v6 and v4 filters into for protecting the ip space from trusted sources. Has my home static ip ranges and a few intermediary ranges that I also have access to.
On Jun 2, 2014, at 5:10 AM, Randy Bush <randy@psg.com> wrote:
so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% of the time i want it blocked off. but that other 1%, i want kvm console, remote media, and dim sum.
currently, i just block the ip address chunk into which i put ipmi at the border of the rack. when i want access, i reconfig the acl. bit of a pita.
anyone care to share better idea(s)? thanks.
randy
On Mon, Jun 2, 2014 at 10:14 AM, Jared Mauch <jared@puck.nether.net> wrote:
My IPMI (super micro) you can put v6 and v4 filters into for protecting the ip space from trusted sources. Has my home static ip ranges and a few intermediary ranges that I also have access to.
Mmmm, and an ip has never been spoofed and no arp poisoned. And I wonder how good these filters are in their TCP stack implementation - not something I'd trust :)
shawn wilson wrote the following on 6/2/2014 11:06 AM:
On Mon, Jun 2, 2014 at 10:14 AM, Jared Mauch <jared@puck.nether.net> wrote:
My IPMI (super micro) you can put v6 and v4 filters into for protecting the ip space from trusted sources. Has my home static ip ranges and a few intermediary ranges that I also have access to.
Mmmm, and an ip has never been spoofed and no arp poisoned. And I wonder how good these filters are in their TCP stack implementation - not something I'd trust :)
We just reported a bug to Dell regarding their last 2 generations of remote access controllers where the firewall rules only apply to TCP and not to ICMP or UDP. Their first response was to replace the motherboard. Second response was that this is just how they work. Not looking good. We run our IPMI interfaces behind stateless ACLs, accessible from VPN or trusted ranges. --Blake
On Mon, Jun 2, 2014 at 12:14 PM, Blake Hudson <blake@ispn.net> wrote:
We just reported a bug to Dell regarding their last 2 generations of remote access controllers where the firewall rules only apply to TCP and not to ICMP or UDP. Their first response was to replace the motherboard. Second response was that this is just how they work. Not looking good. We run our IPMI interfaces behind stateless ACLs, accessible from VPN or trusted ranges.
so... as per usual: 1) embedded devices suck rocks 2) no updates or sanity expected anytime soon in same 3) protect yourself, or suffer the consequences seems normal.
On 02/06/14 20:56, Christopher Morrow wrote:
so... as per usual: 1) embedded devices suck rocks 2) no updates or sanity expected anytime soon in same 3) protect yourself, or suffer the consequences
seems normal.
So I wonder why vendors don't publish source code of these ipmi firmware in first place? Like supermicro from what we know its 99% is open source stuff.
On 2014-06-02 19:32, Nikolay Shopik wrote:
On 02/06/14 20:56, Christopher Morrow wrote:
so... as per usual: 1) embedded devices suck rocks 2) no updates or sanity expected anytime soon in same 3) protect yourself, or suffer the consequences
seems normal.
So I wonder why vendors don't publish source code of these ipmi firmware in first place? Like supermicro from what we know its 99% is open source stuff.
Source won't help too much, as upgrading the kernel will require a lot more magic than just that. Also, do you have time to support all the different IPMI boxes out there while your vendor should be doing that work? For the toolchain, see amongst others: http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn Note that the big problem with "embedded" devices (be that an Android phone, your TV set, your dishwasher, an IPMI device, your car or one of thousand "media players") is: they get popped in a box and they will rarely if ever get an update after that. The market has to change to support that, and it likely won't unless the prices for toys are going to go up sky high to be able to pay for somebody doing that work. The Open Source portion only means that you are more aware that you are running some software with horrible bugs in there. Hence: never route them, never make them remotely publicly available. And then start thinking about all the fun new "Cloud Connected" devices... Greets, Jeroen
On 02.06.2014 21:39, Jeroen Massar wrote:
Source won't help too much, as upgrading the kernel will require a lot more magic than just that.
Also, do you have time to support all the different IPMI boxes out there while your vendor should be doing that work?
Agree, but most IPMI cards we get recently doesn't increase cost of Motherboards (well it does, but not that much as vendor would like to get from you). Especially if you compare prices of MB of 5-7 years ago w/o onboard IPMI.
For the toolchain, see amongst others: http://michael.stapelberg.de/Artikel/supermicro_ipmi_openvpn
Note that the big problem with "embedded" devices (be that an Android phone, your TV set, your dishwasher, an IPMI device, your car or one of thousand "media players") is: they get popped in a box and they will rarely if ever get an update after that.
As long its not mass product and have different types of all kinds hw, it will be fragmented and will be unsupported right after release.
The market has to change to support that, and it likely won't unless the prices for toys are going to go up sky high to be able to pay for somebody doing that work.
Well Dell/HP users pay premium for IPMI, it doesn't change that.
On Mon, Jun 2, 2014 at 1:32 PM, Nikolay Shopik <shopik@inblock.ru> wrote:
On 02/06/14 20:56, Christopher Morrow wrote:
so... as per usual: 1) embedded devices suck rocks 2) no updates or sanity expected anytime soon in same 3) protect yourself, or suffer the consequences
seems normal.
So I wonder why vendors don't publish source code of these ipmi firmware in first place? Like supermicro from what we know its 99% is open source stuff.
From poking around some at my limited set of examplar IPMI-like
it seems that pretty much no one (who pays them money, and complains to them, who does that?) cares? also, supermicro doesn't use something they built for this, they get an outsourced solution. things, there are like 3 vendors. (I'm sure there are more, but... it LOOKS like a very small set is just being sold out as parts to motherboard manufacturers)
They do publish it. The problem is, it's not documented, and it takes a bunch of work to get into a usable state. See ftp://ftp.supermicro.com/GPL/SMT/SDK_SMT_X9_317.tar.gz Plus, the firmware environment is pretty hostile. If you flash some bad firmware, your only option is to desolder the IPMI flash chip and program it externally. It cannot be reprogrammed in circuit, and there's no recovery method. On 6/2/2014 1:32 PM, Nikolay Shopik wrote:
On 02/06/14 20:56, Christopher Morrow wrote:
so... as per usual: 1) embedded devices suck rocks 2) no updates or sanity expected anytime soon in same 3) protect yourself, or suffer the consequences
seems normal.
So I wonder why vendors don't publish source code of these ipmi firmware in first place? Like supermicro from what we know its 99% is open source stuff.
On 6/2/2014 1:42 PM, Brian Rak wrote:
They do publish it. The problem is, it's not documented, and it takes a bunch of work to get into a usable state. See ftp://ftp.supermicro.com/GPL/SMT/SDK_SMT_X9_317.tar.gz
Plus, the firmware environment is pretty hostile. If you flash some bad firmware, your only option is to desolder the IPMI flash chip and program it externally. It cannot be reprogrammed in circuit, and there's no recovery method.
There is a market here for first or third parties to make money, or for open source people to hack a new firmware into existence. Since HP charges a yearly license fee for their ILO, it should remain secured until they stop support for that platform. People would probably revolt if supermicro started charging for something that has been free though. The ideal situation would be if they continued to provide what they do for free and upsold some extra features. Maybe the ability to group manage thousands of boxes, but you can already pretty much do that with the CLI impi tools. It's unfortunate that free means complete security nightmare.
iLo is a value add to HP. DRAC sucks (so I'd replace it and then Dell would have hardware under support with some unknown IPMI). Supermicro, Tyan, etc - idk. Really, it would be nice to have an open card that does this. Even if the card were limited to what you could do with DMA and some serial (i2c and whatnot) cables. I'd use that instead of something else (in this case, mainly because I'd replace the Java console for some VNC solution - but also because of trust). On Mon, Jun 2, 2014 at 1:32 PM, Nikolay Shopik <shopik@inblock.ru> wrote:
On 02/06/14 20:56, Christopher Morrow wrote:
so... as per usual: 1) embedded devices suck rocks 2) no updates or sanity expected anytime soon in same 3) protect yourself, or suffer the consequences
seems normal.
So I wonder why vendors don't publish source code of these ipmi firmware in first place? Like supermicro from what we know its 99% is open source stuff.
On 02.06.2014 21:52, shawn wilson wrote:
Really, it would be nice to have an open card that does this. Even if the card were limited to what you could do with DMA and some serial (i2c and whatnot) cables. I'd use that instead of something else (in this case, mainly because I'd replace the Java console for some VNC solution - but also because of trust).
I believe most people need from IPMI is KVM (sometimes serial), and (rarely?) need to mount remote ISO images. Java only used for mouting images. KVM is transfered via VNC protocol iirc.
On Mon, Jun 2, 2014 at 3:19 PM, Nikolay Shopik <shopik@inblock.ru> wrote:
Java only used for mouting images. KVM is transfered via VNC protocol iirc.
They're not re-inventing the wheel, but I think KVM is generally some VNC stream embedded in http(s) which VNC clients can't seem to understand (at least, at a glance, I haven't been able to connect to iLo, DRAC, Spider, or Tyan IPMI from outside the Java app).
On 6/2/2014 3:47 PM, shawn wilson wrote:
On Mon, Jun 2, 2014 at 3:19 PM, Nikolay Shopik <shopik@inblock.ru> wrote:
Java only used for mouting images. KVM is transfered via VNC protocol iirc. They're not re-inventing the wheel, but I think KVM is generally some VNC stream embedded in http(s) which VNC clients can't seem to understand (at least, at a glance, I haven't been able to connect to iLo, DRAC, Spider, or Tyan IPMI from outside the Java app). No, at least on SuperMicro it's a hacked up VNC protocol. It's not embedded in HTTP/HTTPS, it just uses HTTP/HTTPS to fetch the Java app.
I say hacked up because it's got a custom auth method, and a whole bunch of undocumented extensions. I looked into implementing support in noVNC for it, but reverse engineering a binary protocol is a bit beyond me. It's also annoying because it claims to be a TightVNC server (and uses TightVNC auth/tunneling)... I was so hopeful that would just work. It looks like they took the TightVNC code, and just made a bunch of changes with no regard for the specification.
On 2014-06-02 21:54, Brian Rak wrote:
On 6/2/2014 3:47 PM, shawn wilson wrote:
On Mon, Jun 2, 2014 at 3:19 PM, Nikolay Shopik <shopik@inblock.ru> wrote:
Java only used for mouting images. KVM is transfered via VNC protocol iirc. They're not re-inventing the wheel, but I think KVM is generally some VNC stream embedded in http(s) which VNC clients can't seem to understand (at least, at a glance, I haven't been able to connect to iLo, DRAC, Spider, or Tyan IPMI from outside the Java app). No, at least on SuperMicro it's a hacked up VNC protocol. It's not embedded in HTTP/HTTPS, it just uses HTTP/HTTPS to fetch the Java app.
I say hacked up because it's got a custom auth method, and a whole bunch of undocumented extensions. I looked into implementing support in noVNC for it, but reverse engineering a binary protocol is a bit beyond me.
While there is no spec, there are people who have reversed it: https://github.com/thefloweringash/chicken-aten-ikvm Greets, Jeroen
Once upon a time, Nikolay Shopik <shopik@inblock.ru> said:
I believe most people need from IPMI is KVM (sometimes serial), and (rarely?) need to mount remote ISO images.
Java only used for mouting images. KVM is transfered via VNC protocol iirc.
In my experience, KVM requires their "special" client (Java), because the protocol isn't _exactly_ VNC. -- Chris Adams <cma@cmadams.net>
I keep 2 vpn servers. ACL's at router to ipmi vlan, plus whatever additional security ipmi happens to have. I'm of the belief that vpn servers should be redundant. Kinda silly to lose one and not have access to your network. :) Jack On 6/2/2014 7:10 AM, Randy Bush wrote:
so how to folk protect yet access ipmi? it is pretty vulnerable, so 99% of the time i want it blocked off. but that other 1%, i want kvm console, remote media, and dim sum.
currently, i just block the ip address chunk into which i put ipmi at the border of the rack. when i want access, i reconfig the acl. bit of a pita.
anyone care to share better idea(s)? thanks.
randy
participants (17)
-
Andrew Latham -
Blake Hudson -
Brian Rak -
charles＠thefnf.org -
Chris Adams -
Christopher Morrow -
coy.hile＠coyhile.com -
Jack Bates -
Jared Mauch -
Jeroen Massar -
Jimmy Hess -
Nikolay Shopik -
Paul S. -
Peter Kristolaitis -
Randy Bush -
Robert Drake -
shawn wilson