Prevent admin access on switchport interfaces.

[royh]

I am struggling on trying to prevent admin access (ssh and https) on switchport interfaces on a nv3448 rinning R10.5.3 f/w.  My SIP phones have data ports for PC connections and I want to provent the PCs from accessing the nc3448.  How would I set that up?

My current configuration for access and access control is:

=================

interface eth 0/1

  description WAN interface connection

  ip address dhcp

  ip access-policy PUBLIC-WAN

  media-gateway ip primary

  no awcp

  no shutdown

!

interface vlan 1

  ip address  10.10.1.1  255.255.255.0

  ip access-policy PRIVATE-LAN

  no awcp

  no shutdown

!

interface vlan 10

  description Polycom VLAN Interface

  ip address  10.10.10.1  255.255.255.0

  ip access-policy PRIVATE-LAN

  media-gateway ip primary

  no awcp

  no shutdown

!

ip access-list extended ADMIN-ACCESS

  remark Admin Access

  permit tcp 172.28.35.0 0.0.0.255  any eq https   log

  permit tcp 172.28.35.0 0.0.0.255  any eq ssh   log

  permit icmp 172.28.35.0 0.0.0.255  any  echo-reply   log

  permit tcp 172.28.37.0 0.0.0.255  any eq https   log

  permit tcp 172.28.37.0 0.0.0.255  any eq ssh   log

  permit icmp 172.28.37.0 0.0.0.255  any  echo-reply   log

!

ip access-list extended MATCHALL

  permit ip any  any     log

!

ip access-list extended SIP-INBOUND

  permit udp any  any eq 5060

!

ip policy-class PRIVATE-LAN

  nat source list MATCHALL interface eth 0/1 overload

  allow list MATCHALL self

!

ip policy-class PUBLIC-WAN

  allow list SIP-INBOUND self

  allow list ADMIN-ACCESS self

!

http secure-server

!

line ssh 0 4

  login local-userlist

  line-timeout 0

  no shutdown

=================

Message was edited by: royh I've tried creating an ACL and then applying it to the ssh and http config but to no avail.

=================

ip access-list standard MGT-ALLOW

  permit 172.28.35.0 0.0.0.255 log

  permit 172.28.37.0 0.0.0.255 log

  deny   10.10.10.0 0.0.0.255 log

  deny   10.10.1.0 0.0.0.255 log

line ssh 0 4

  login local-userlist

  line-timeout 0

  no shutdown

  ip access-class MGT-ALLOW in

http ip secure-access-class MGT-ALLOW in

=================

I have my PC plugged into switchport 0/7 and gets an IP address of 10.10.1.12.  When I ssh to the system interface of 10.10.1.1 the count against the access-list is counted against an external IP address range.

=================

Standard IP access list MGT-ALLOW

   permit 172.28.35.0 0.0.0.255 log (0 matches)

   permit 172.28.37.0 0.0.0.255 log (39 matches)

   deny   10.10.10.0 0.0.0.255 log (0 matches)

   deny   10.10.1.0 0.0.0.255 log (0 matches)

=================

[jayh]

You can't define layer-3 access privileges by layer-2 switch ports.  If your goal is that only the 172.28.35.0/24 and 172.28.35.0/24 subnets are allowed to administer the box, as defined in your MGT-ALLOW access list, add the following:

ip http access-class MGT-ALLOW in

ip http secure-access-class MGT-ALLOW in

line telnet 0 4

   ip access-class MGT-ALLOW  in

line ssh 0 4

  ip access-class MGT-ALLOW in

The first two lines above may need a bit of tweaking depending on your AOS version.  If the above doesn't parse, try:

http ip access-class MGT-ALLOW in

http ip secure-access-class MGT-ALLOW in

Also, you don't need to specifically deny the 10.x.x.x subnets unless you want to log or count attempts from them.  There's an implicit deny at the end of any non-empty access list.

If you are coming from VLAN 1 or VLAN 10, your PRIVATE-LAN class will allow you to reach the Adtran itself based on the MATCHALL allow list in the PRIVATE-LAN policy class.  That's why you need to lock down management by using the MGT-ALLOW list applied to HTTP, HTTPS, Telnet and SSH as an access class.

You have:

ip policy-class PRIVATE-LAN

  nat source list MATCHALL interface eth 0/1 overload

  allow list MATCHALL self ! <------  This allows hosts to reach the Adtran itself.

[royh]

But as indicated at the bottom of my initial post and I have re-created this, I can still log in from a switchport but the system seems to think that I am connecting via eth 01 and not from the switch port.

=================

NV3448(config)#do show runn | beg ip access-list

ip access-list standard MGT-ALLOW

  permit 172.28.35.0 0.0.0.255 log

  permit 172.28.37.0 0.0.0.255 log

!

...

NV3448#show ip interfaces brief

Interface                        IP Address      Status      Protocol

eth 0/1                          172.28.37.14    DOWN        DOWN

vlan 1                           10.10.1.1       UP          UP

vlan 10                          10.10.10.1      UP          UP

NV3448#sho users

- CONSOLE 0 'password-only' logged in and enabled

  Idle for 00:00:00

- SSH 0 (172.28.37.14:63266) 'admin' logged in (not enabled)

  Idle for 00:00:05

=================

And when I remove the "permit 172.28.37.0 0.0.0.255" statement, I can not log in from a switchport.

[jayh]

royh wrote:

But as indicated at the bottom of my initial post and I have re-created this, I can still log in from a switchport but the system seems to think that I am connecting via eth 01 and not from the switch port.

The physical interface from which you are connected doesn't matter.  The access list governs from what source IP addresses management will be allowed.

NV3448#sho users

- CONSOLE 0 'password-only' logged in and enabled

  Idle for 00:00:00

- SSH 0 (172.28.37.14:63266) 'admin' logged in (not enabled)

  Idle for 00:00:05

=================

And when I remove the "permit 172.28.37.0 0.0.0.255" statement, I can not log in from a switchport.

Something really strange is going on.  Eth 0/1 is shown as down/down with the IP that is the source of your SSH session.  It seems like the box is NATting your private IP to the (down) outside IP and then allowing that IP to SSH to the box.  I'd see if someone from Adtran chimes in here, but you may need to open a trouble case.  It could be something as simple as swapping the order of statements in a policy-class but it looks like a bug.

[Anonymous · Accepted solution]

:

The results you are experiencing are expected, based on the configuration.  The reason the source address is from the eth 0/1 interface is because the SSH and HTTPS traffic from the PC is arriving ingress on the switchport and reaching the VLAN 1 interface, which has the "PRIVATE-LAN" policy class assigned to it.  ACPs are order-dependent; therefore, when a packet is evaluated, the matching engine begins with the first entry in the list and progresses through the entries until it finds a match.  In this case, the first match and corresponding action taken by the firewall is to NAT the source IP address to the IP address assigned on the eth 0/1 interface.  Next, the traffic is routed to the SSH/HTTPs engine, and since the source IP address (which is now the NAT'ed IP address) is allowed in the access-group applied to the SSH and HTTPS interface, the traffic is permitted. 

You can resolve this by switching the order of the entries in the "PRIVATE-LAN" policy class (as suggested), which would allow the traffic (as is) instead of NAT’ing the administrative traffic; however, this will not block the administrative traffic. You would then need to use an access-class for SSH / HTTPS (see response). Another option would be to use a discard statement in the "PRIVATE-LAN" policy class that references an ACL that is configured to match source traffic from the PC LAN destined to self.  Finally, another option would be to develop an access-group that blocked the unwanted traffic, and apply it ingress to the VLAN 1 interface, which would take action before it reached the ACP.

I hope that makes sense, but please do not hesitate to reply to this post with any additional questions or information.  I will be happy to help in any way I can.

Levi

[royh]

that was it.  thanks.

roy