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.
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.
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
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
In addition I will suggest multiple paths (oobm) to the network. IE VPN via
second provider network.
[..]
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)
Multiple points of entry into the VPN mesh? When you need to muck with concentratorA's ipmi, use b, c, or d.
True, excellent point as well.
Multiple openvpn/ipsec entry points on a internal network is probably the best way to go.
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.
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 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
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.
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
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
My IPMI (super micro) you can put v6 and v4 filters into for
protecting the ip space from trusted sources.
cool. can i put in "star alliance?"
randy
restfulwhois look up for gogoinflight ... done.
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?
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:
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