I am interested in remote out-of-bounds (OOB) access. I am looking for information from admins experienced with OOB remote access and configuration.

We have some Proxmox (Debian) and some CentOS servers. The servers are distributed across in three different remote locations. Firewall configs limit access to the local net range, but the systems do have public facing IP addresses. All of the Proxmox and one of the CentOS servers are refurbished Dell PowerEdge R710 and 2950. Two CentOS systems are old Supermicros (X7SBi and X8SIL).

Questions

1. Security. From what I have read, for example here, security is a significant concern with OOB management. How do experienced admins deal with OOB security? Should OOB never be enabled on public facing servers?

2. On the two Supermicros the IPMI kernel modules do not automatically load on boot. Manually loading them still does not allow ipmitool to access anything and there are no /dev/ipmi* device nodes. Any ideas how to resolve? Is there a special set of IPMI tools for these older Supermicros? I thought there was a BMC but perhaps I am mistaken.

3. Should we be using Dell OSMA or ipmitool or both? I am tinkering with both on a spare PowerEdge 2950 and I notice the Dell tools open port 1311 to provide access to the web interface. Is having that port open for the world to see a good idea or is that an open invitation to malicious people?

4. If I understand correctly the BMC creates different MACs and we should assign a different IP address for OOB access than the normal IP address used for OS access, such as with SSH. Should this separate OOB address be a private address? If private, how to configure routing to traverse to the system?

I am overwhelmed by the topic. All very new to me. I realize there is a lot of RTFM ahead of me. Just looking for pointers and general concepts to help me get started.

Thanks much!

If you're a sysadmin, you need to know this stuff, and you shouldn't be relying on the opinions of other sysadmins on such a (presumably) vital question.

Your post looks more like an exam question than a query, and I don't expect anyone to provide the detail you seek; You're getting the moneyfor your job; You earn it.

I thought the kosher approach to that area was
1. The first thing anything facing the outside world should face is a firewall.
2. Any OOB access should face a DMZ, where hopefully any hack attack would not be fatal. Perhaps run a BSD variant on one or both of these. Under no circumstances run X.
3. Your routers should be behind these with limited access purely to what they need and no more. Often instead of the lazy 0755 permissions on these for directories, you should think about it. users should have limited access.
4. The usual sane rules should apply: no user should be a 'superuser', e.g. sudo should not give him root privileges, he shouldn't be in every important group, have long cryptic passwords, etc. You should be up to date on all recent security threats, have the latest patches applied, backups and failovers tested & working, etc.
I bet a security check on the place you're sysadmin of tomorrow would catch you out on the basics. Being a sysadmin is a serious and difficult job. When you have your house in order, bring on OOB access.

There is a popular proverb about not assuming. You have done a great job of doing just that.

This is not an exam question. I am helping a person who is not currently using OOB and is interested in the idea. Even if I wanted to just set up a lab for personal use, everybody starts out fresh and needs to learn. Questions are a Good Thing to help learning.

Thanks for the tips. You can stop thumping your chest now.

I don't know the proverb you're referring to and it's probably better that way. I don't mean to thump my chest. I'm no sysadmin. I just answered what I read. If you knew about this, I am entitled to presume you wouldn't have asked. If you decide to help someone, great. But you do the explaining.

Right. I asked because I don't know. That is why people post questions here -- hoping for helpful replies to nudge them in the right direction.

My initial digging into the topic is OOB access is not worth the time and effort for most people. Security with OOB management is horrible. (Lack of meaningful security seems common with embedded software development.) Securing such systems requires layers that gets complicated and expensive for most people. ROI is nominal until scaling with many, many systems.

Well, what I set out in post #2 isn't a bad start. Neither the firewall or the DMZ need serious processing power on a small system; A raspberry Pi 3 might be sufficient for each if the site volume is low. The DMZ might also be put on a separate (private) IP known only to firmware. It might be that you are not really in a position to help someone if you don't know yourself.

I would take the approach of saying to your boss: To do <whatever> safely, I will need <list requirements>. If people are serious about what they want, they will provide the tools. Security training for yourself might be up there in that list. If they're not serious about it, you won't get your requirements. Inform them in a memo that as they're clearly not serious about security, you'll coomplete the job but the resulting system will be insecure. Keep a copy. It's called CYA: Cover Your A**