1

I'm in the process of setting up a bunch of servers at the other end of the world (well, 8 hours travel time) in a co-location place.

The servers and firewall all have a remote management port (KVM, DRAC, you name it). I'm wondering what is the best practice how to access & secure that.

Obviously I could just put all those in a separate VLAN and put some filtering rules on the firewall (a Linux box). But then the accessibility of the firewall remote management depends on the firewall itself - I don't think this is a brilliant idea. One ifdown and you're out.

I could also just put the servers management ports into a separate net, and leave the firewall management port open on the internet, but this doesn't seem to be very elegant.

I could also leave everything on public internet, of course.

What are your recommended best practices?

2

I suggest you to use the bastion backdoor architecture.

  1. Install an hardened machine inside your remote network which will be used as a uniq entry point to access the inside of your remote network. For the clarity of this textual description I'll name it bastion. As a rule of thumb any protocol not used on bastion will have to be off. All allowed protocols will be logged (if possible on a syslog server within your remote network).

  2. Put all your managment interfaces in a dedicated closed VLAN: managment. managment won't be accessible from the WAN or from the remote LAN. It will only be accessible from bastion.

  3. Block any WAN direct access toward your firewall. Your firewall will only be accessible from bastion and through a very limited set of protocals (IPsec, ssh).

bastion will be a potential point of failure. In case of trouble on this system, your remote network won't be accessible. If an attack on bastion turn successfull, the attacker will have control on your firewall and on all your managed server. Hence all your OS hardening should be done to make this bastion as attack resistant and failure proof as possible. I advise you to build it on top of any Unix which have a good reputation to permit the building of hardened OSes.

  • In fact that creates two points of failure: Both my firewall and bastion. If my firewall fails, I can't get to bastian any more as well. I only allow protocolls that are needed anyway. – Alexander Dec 3 '13 at 19:49
  • Right. I detailed the bastion point of failure because it is one more relative to your 1st solution which was already a good approach. – dan Dec 4 '13 at 6:21
0

This is a trade-off between usability and security. Never put your KVM or DRAC modules on the WAN, not long ago a nice exploit was released which targets BMCs like DRAC.

Baseboard Management Controllers (BMCs) are a type of embedded computer used to provide out-of-band monitoring for desktops and servers. These products are sold under many brand names, including HP iLO, Dell DRAC, Sun ILOM, Fujitsu iRMC, IBM IMM, and Supermicro IPMI. BMCs are often implemented as embedded ARM systems, running Linux and connected directly to the southbridge of the host system's motherboard. Network access is obtained either via 'sideband' access to an existing network card or through a dedicated interface. In addition to being built-in to various motherboards, BMCs are also sold as pluggable modules and PCI cards. Nearly all servers and workstations ship with or support some form of BMC.

Considering DRAC access is the same as having physical access to the machine:

If I can physically access your device, it's not your device anymore

I would just go with making only the firewall accessible from the WAN and also protect it's login interface with IP filtering (your office only for instance) and add two-factor authentication to it.

The problem here is that you introduced a single point of failure. Normally you should at least have made the firewall redundant (which is not possible with Linux probably). So I would consider getting in some better hardware which can be placed in active-passive mode (or active-active if you want to load balance).

  • I must admit I fear user error more than failure. If the user send a wrong configuration to the firewall, usually the only option to get to it is via DRAC/KVM. One way around is to issue a reboot before changing stuff and only making transient changes until they have prooven to be ok, but people tend to get lazy. I see the point that all that DRAC stuff is probably not hardened enough, so I'll have to protect it behind a FW with some IP limiting...Damn ;) – Alexander Dec 3 '13 at 19:45
  • IP limiting will not do you any good as IPMI uses udp... – Lucas Kauffman Dec 3 '13 at 20:03
0

A locked down and isolated management LAN is the way to go. For OOB Access (Out Of Band Access, or getting into the admin network when the firewall is down) a hardened WAN-facing VPN server configured to ignore everything that isn't a secure VPN connection from a known IP (preferably the Disaster Recovery colo - you do have one of those, right?) is used to connect to the dead firewall and other infrastructure on the management network.

For instance - Your admins would use a VPN concentrator to connect to the DR site, and then access the Primary sites' management LAN over a site-to-site VPN connection. Depending on your budget, a private or MPLS circuit would be even more secure than WAN VPN access.

Without a DR site, direct access to the backup VPN server, such as admins on the road with an LTE connection or at home on a cable modem, is probably secure enough - for most purposes - with a suitably paranoid authentication scheme.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.