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)
=================
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
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.
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.
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.
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
that was it. thanks.
roy