Management of 5800 Series Switches

[L1nklight]

Hey everyone,

I have some security concerns about the 5800 series switches I am using. Specifically I want to talk about managing them. I have a few different models of 5800 in my environment. The most prevelant being the JG225A models (48 port, 19" deep, with a management port). 

I am currently using the management port to ssh to these devices. A few of the devices are designated as DMZ switches. In my mind, a management port is a port that's dedicated to only management traffic. Since these are designated as "management" ports in the event they are compromised in the DMZ, would it be possible for an attacker to gain access to the management interface to piggy back into my production network from said port?

In my network topology, if one did compromise the DMZ switches, without the management port, the attacker would have to circumvent both my firewall system and my IPS to gain access to my internal network. 

I can't seem to find much documentation about the management ports. My googlefu is weak on this subject. I guess my real questions are: Is the management port on the 5800AF-48G (JG225A) an out of band management port? Does it create a security concern if I have this management port plugged into my core internal network, while the 48 ports manage the DMZ (assume DMZ is partitions from the internal network via a Firewall and IPS but the management port plugs directly into the core)?

[Apachez-]

If your DMZ-switches has L3-interfaces available for the DMZ itself (that is for example an int vlan-interface xxx with ip set) and you didnt protect it (with an ACL along with passwords to gain command-prompt, dont forget snmp) so the DMZ-switch itself got compromised - then yes, the attacker would be able to bounce further into your mgmt network using the management-interface of your 5800 switch.

It seems that the management-interface on the 5800 switches is just an hardcoded "port link-mode route". It doesnt seem to provide any more segmentation than that.

Any service (like telnet client etc) can use the management-interface as source interface:

#telnet client source management-interface 0

I think a good advice would be to use a dedicated mgmt-firewall along with Private VLAN on the mgmt-network itself to segment the various devices from each other.

This way, even if one device gets compromised, the attacker would still need to bypass your mgmt-firewall before getting anywhere (and thanks to private vlan, if properly setup, the attacker would only be able to reach the mgmt-firewall from the compromised device and not the other devices attached to your mgmt-network).

Sadly Comware doesnt seem to offer a "default disabled" state regarding management capabilities which gives that as soon as you set an ip address either on an routed interface or on a vlan you have the risk of getting compromised unless you set a proper ACL on this interface at the same time.

Personally I would prefer if Comware would offer "default disabled" so I as admin could select which interface(s) should respond to incoming telnet, ssh, snmp etc requests (insead of as today all ip interfaces will respond to this).

It seems that most firewalls applies to this behaviour while most routers and switches dont.

[Michael Peus]

Hi,

another option is to use an VPN-Instance for management and bind the Mgmt.IF to it. So your management traffic does not use the global routing table. Some form of FW/ACL for protecting the inbound and outbound traffic is still needed.

It would be nice if the management services could be bound to a specific IP, unfortunately that is not possible AFAIK.

Br,

Michael

[Apachez-]

I wonder how much that would help because the switch will still reply on all interfaces which has an ip set (that is if you have enabled ssh-server then this ssh-server will be available on all ip addresses any routed or vlan interface is using).

However using vpn-interface for the physical mgmt-int should block the possibility of accidently route traffic towards the mgmt-network.

In order to somewhat secure the ssh-server you can set an acl for the vty-interfaces like so:

#
acl number 2001 name ACL-MGMT
 rule 0 permit source <IP> <NETMASK>
#

user-interface vty 0 15
acl 2001 inbound

Dont forget to do the equal for snmp if you have that running:

snmp-agent
snmp-agent community read <ROCOMMUNITY> acl 2001

snmp-agent community write <RWCOMMUNITY> acl 2001