Solved: Disabling unused services on NX-OS

stuartkendrick · ‎06-03-2022

I would like to disable unused (network-accessible) services on our flock of NX-OS gear. So I am running nmap scans against a few, to get a feel for the scope of the task

nmap -T4 -A -v {address of NX-OS switch}

I am seeing a remarkable range of responses. I say 'remarkable' because I would have predicted tcp port 22 and udp port 161 and nothing else. Here are a few:

EXAMPLE 1

EXAMPLE 2

PORT STATE SERVICE VERSION
21/tcp filtered ftp
22/tcp open ssh (protocol 2.0)
| fingerprint-strings:
| NULL:
|_ SSH-2.0-OpenSSH_8.0 PKIX[12.1]
| ssh-hostkey:
|_ 2048 [...] (RSA)
111/tcp filtered rpcbind
161/tcp open snmp?
512/tcp filtered exec
513/tcp filtered login
514/tcp filtered shell
2049/tcp filtered nfs
27000/tcp filtered flexlm0
32768/tcp filtered filenet-tms

EXAMPLE 3

I am consulting

https://tools.cisco.com/security/center/resources/securing_nx_os.html#_Toc303633196

and CIS_Cisco_NX-OS_Benchmark_v1.0.0 PDF and seeing a discussion of ssh and snmp ... but not of the other services

Would anyone have an explanation to offer? A pointer to how to shut off things like tcp/161 ... not to mention tcp/21, tcp/25, udp/53 ... tcp/8008 ...

--sk

Stuart Kendrick

stuartkendrick · ‎06-06-2022

Turns out that an intermediate device, a Firewall, is intefering and presenting the illusion of open ports to nmap. I plugged a host into a Layer 2 switch which also services EXAMPLE 1/2/3, ran nmap from it, and now the output shows only the expected open ports (161 and 22)

Thank you for your engagement and suggestions

--sk

View solution in original post

Sergiu.Daniluk · ‎06-03-2022

Hi @stuartkendrick

Do a "show feature" command, and see what features are enabled by default. If you want to stop one of the service, simply disable it using "no feature X" command.

Cheers,

Sergiu

stuartkendrick · ‎06-03-2022

How do I map features into open ports?

EXAMPLE 1
nxos-1# sh feature | include enab
bash-shell 1 enabled
evmed 1 enabled
icam 1 enabled
interface-vlan 1 enabled
lacp 1 enabled
lldp 1 enabled
scheduler 1 enabled
scpServer 1 enabled
sftpServer 1 enabled
sshServer 1 enabled
udld 1 enabled
nxos-1#
==> I can imagine that any of scpServer | sftpServer | sshServer result in tcp/22 being open ... but which feature is listenong in tcp/161?

EXAMPLE 2
nxos-2# sh feature | include enab
bash-shell 1 enabled
dhcp 1 enabled
hsrp_engine 1 enabled
icam 1 enabled
interface-vlan 1 enabled
lacp 1 enabled
lldp 1 enabled
ospf 1 enabled
ospf 2 enabled(not-running)
[...]
ospf 16 enabled(not-running)
scpServer 1 enabled
sftpServer 1 enabled
sshServer 1 enabled
udld 1 enabled
vpc 1 enabled
nxos-2#
==> Examining these features ... other than the scp/sftp/ssh ones, I don't see a feature which would listen on *any* tcp ports

EXAMPLE 3
nxos-3# show feature | include enab
bash-shell 1 enabled
bfd 1 enabled
bgp 1 enabled
evmed 1 enabled
hsrp_engine 1 enabled
icam 1 enabled
interface-vlan 1 enabled
lacp 1 enabled
lldp 1 enabled
netflow 1 enabled
scheduler 1 enabled
scpServer 1 enabled
sftpServer 1 enabled
sshServer 1 enabled
udld 1 enabled
nxos-3 #
==> Examining these features ... other than the scp/sftp/ssh and bgp ones, I don't see a feature which would listen on tcp ports

I suppose that not all listening tcp/udp ports are associated with a 'feature' ... how might I parse the config file, looking for lines which are opening tcp ports?

I have also tried:
nxos-2# run bash
bash-4-3$ sudo netstat -plnt
bash-4.3$ sudo netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 7920/portmap
tcp 0 0 127.1.2.1:7891 0.0.0.0:* LISTEN 29053/swtele
tcp 0 0 0.0.0.0:9075 0.0.0.0:* LISTEN 18635/in.tftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 25951/sshd
tcp 0 0 0.0.0.0:27000 0.0.0.0:* LISTEN 18697/lmgrd
tcp 0 0 127.0.0.1:7581 0.0.0.0:* LISTEN 18695/nginx
tcp 0 0 0.0.0.0:32765 0.0.0.0:* LISTEN 8108/rpc.statd
tcp 0 0 0.0.0.0:51774 0.0.0.0:* LISTEN 18746/cisco
tcp 0 0 0.0.0.0:32767 0.0.0.0:* LISTEN 8102/rpc.mountd
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp6 0 0 :::21 :::* LISTEN 18634/xinetd
tcp6 0 0 :::22 :::* LISTEN 25951/sshd
tcp6 0 0 :::512 :::* LISTEN 18634/xinetd
tcp6 0 0 :::513 :::* LISTEN 18634/xinetd
tcp6 0 0 :::514 :::* LISTEN 18634/xinetd
bash-4.3$

So, I see some correlation between nmap output and netstat output, e.g. the first line (111 < -- > portmap) and '27000 < -- > lmgrd) and so on. But where would I learn what these functions do, how to disable them (or at least prevent them from being accessible externally), and whether or not I would want to disable them? And, for that matter, why doesn't netatat report on 161/tcp, 512/tcp, 513/tcp, and 514/tcp?

--sk

stuartkendrick · ‎06-06-2022

Turns out that an intermediate device, a Firewall, is intefering and presenting the illusion of open ports to nmap. I plugged a host into a Layer 2 switch which also services EXAMPLE 1/2/3, ran nmap from it, and now the output shows only the expected open ports (161 and 22)

Thank you for your engagement and suggestions

--sk

ss1 · ‎06-04-2022

Hey,

port 161 is an open snmp server, obviously you may not want to expose your devices to risk of being attacked etc.
Let me give you a couple of suggestions:
- Use non-routable public IP addresses wherever possible, i.e. 10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 etc. For example you can use such blocks for your internal BGP peering between devices or perhaps your management network is behind a VPN, no reason to monitor or manage the switch through public IPs I suppose.
- Use ACLs wherever possible:

ip access-list mgmt
  10 permit ip 10.1.0.0/24 any 
  20 permit ip 10.2.0.0/24 any 
....................
  100 deny ip any any 

snmp-server community xxxxxxxxxxxxxx use-acl mgmt
line vty
  access-class mgmt in

- For any other services that don't allow any ACL then you may want to keep it simple - do not configure any default gateway on your switches, just configure routes towards the network that you access it from. For example I have a switch in a remote datacenter 3000km away and I have an out of band management over mgmt0, this is a public IP address with full internet access however I only have routes towards my home /24 where I'm managing the device from.

- Move the public routing i.e. Datacenter EBGP or external customers over a different VRF so that they can't get through your devices. You are urged to consider doing so especially if you are running an EVPN underlay together with customer-routed traffic, else they can reach your underlay OSPFs and do anything depending on whatever your ACL allows. On the other hand, if you move the customers and all public IPs over a different VRF then you would just perform different routing or ACL-based protection on the internal services hence the risk will be lowered down if not mitigated at all.