Interface Access List needs Multicast Address for SSH to work

[knakke]

Hi,

As part of security, we are putting inbound access-lists on our routers to allow only specific traffic into a router interface.

We observed that this access-list rule allows some users to access (users configured for "secret 5") the device while other users cannot log in (users configured for "secret 8") from the same computer:

ip access-list  extended 150

     permit tcp 192.168.10.0 0.0.0.255 192.168.88.0 0.0.0.255 eq ssh

We were able to identify that some communications were responding to the multicast address range, so we added the following rule to acl 150:

"permit ip 192.168.88.0 0.0.0.255 224.0.0.0 0.0.0.255"

This rule seemed to fix the problem, and I would like to understand why that is.  Has anyone else noticed this behavior? 

Would I be able to get help to point me to the Cisco Documentation on "secret 8" using the multicast addresses?  Just a note, the show multicast command shows it is disabled.

My thanks and appreciation in advance,

Khanin

[marce1000]

 - It would probably be advisable to allow source and or valid  specific ip ranges only for which you can now that they need access. Multicast address can be used a security attack, or someone has misconfigured a managerial device. So let's not allow them by default. Once those how come forward, using this. They can be informed to use correct addresses.

 M.

[pieterh]

i suggest to check the routing within your network
the packet should first be routed from 192.168.10.0/24 to 192.168.88.0/24,
if this is not routed properly, the packet is not processed as incoming on the  management interface/ IP-address, but as received as multicast on on another interface.

The ARP request for the default gateway may not be resolved properly?

as for the privilege level , you need to explain your config more, do you use a radius or tacacs+ server for authentication?

[Richard Burts]

It is interesting that there is a difference in behavior for secret 5 and secret 8. I find it difficult to come up with a reason why a multi cast address might be involved in this and suspect that there is some other reason for this behavior. If we knew more about this situation we might be able to offer better advice about it. I wonder if the issue is an authentication issue, or perhaps an authorization issue? I wonder if the issue might be related to whether there is an external aaa server and if so is the server reachable? A good next step would be to post a current copy of running config (with public IPs and passwords disguised).

[knakke]

Thank you for the quick responses.

I'm seeking documentation on this issue on the cisco site, and have been unlucky. At this point in time, I'm looking for documentation to include with my change documentation.

Any help with the location of the documentation on the Multicast requirements for SSH authentication is appreciated.

To summarize the information on the setup:

• Source Network: 192.168.10.0/24
• Destination Network: 192.168.88.0/24
• ISR-4431 is configured for port-channeling and connected to an L3 Switch A and an L3 Switch B (192.168.88.100/24). Default gateway 192.168.88.1
• L3 Switch A and L3 Switch B are connected
• Routing is EIGRP 192.168.10.0 & 192.168.88.0
• DNS is disabled
• The device configured for local accounts using AAA, no TACACS
• Authorization: "commands 15 default local"
• Accounting is disabled
• An ACL is configured on the Port Channel as "Access-Group In 150"
• SSH is from a local machine (192.168.10.100/24, Default gateway 192.168.10.1) to the ISR-4431 (192.168.88.100/24)
• show multicast command shows multicast is disabled on the L3 Switches and the ISR-4431
• user accounts are configured for privilege 0 and use the enable command
• SSH is configured for V2
• line vty 0 4 is configured for preferred ssh, transport input ssh

Results:

• No Access-list limiting inbound access to the port-channel :
  • SSH using a username abc with secret 5: SSH Login Successful
  • SSH using a username def with secret 8: SSH Login Successful
• Access-list limiting inbound access to the port-channel not allowing communications between ISR-4431 to Multicast addresses:
  • SSH using a username abc with secret 5: SSH Login Successful
  • SSH using a username def with secret 8: SSH Login Failed
• Access-list limiting inbound access to the port-channel allowing communications between ISR-4431 to Multicast addresses:
  • SSH using a username abc with secret 5: SSH Login Successful
  • SSH using a username def with secret 8: SSH Login Successful

Let me know if this additional information helps with pointing in the right direction.

Thanks,

Khanin

[Richard Burts]

Khanin

Thank you for the additional information. I believe that it does help to explain at least part of your problem. You describe a 4431 and 2 L3 switches. It might be helpful if we had a better understanding of which subnets were active on which devices, and which subnets connect the devices. You have described networks 192.168.10.0 and 192.168.88.0 but it is not clear which subnet is on which device and what subnet(s) provide connectivity (and EIGRP neighbor relationships) between devices.

One significant thing that you told us is that routing uses EIGRP. And that is significant when you talk about using an access list applied inbound. (an access list applied outbound would not be as significant because an outbound acl does not evaluate traffic originated by the device itself. but an inbound access list does evaluate all received packets and so can have an effect.). You have described 3 conditions and here is what I believe is happening in each condition:

1) no inbound acl on the port channel. EIGRP multicast packets are received, EIGRP neighbor relationship established, EIGRP routes are learned.

2) inbound acl which does not allow multicast on the port channel. EIGRP multicast packets are denied, EIGRP neighbor relationship is not formed, EIGRP routes are not learned. 

3) inbound acl does permit multicast on the port channel. EIGRP multicast packets are received, EIGRP neighbor relationship established, EIGRP routes are learned.

Your description of what happens does not match this. In condition 2 you tell us that 

• SSH using a username abc with secret 5: SSH Login Successful

• SSH using a username def with secret 8: SSH Login Failed

I can not think of any logical reason why this would be the behavior. There is not anything about SSH that requires use of multicast addressing. I am not aware of anything about secret 5 and secret 8 that would depend on multicast. They are simply different ways of protecting the password. If the same device is the source of the SSH request and the same address is used for the destination and the only difference in the SSH request was the user name then I can not think of any reason why one would fail but the other would succeed.