Wired Intelligent Edge

Hi!

I'm testing the MAS out here and getting stuck on what seems to be a pretty simple task, to put an ACL on incoming traffic of the switch to secure it. The switch has a VLAN interface with DHCP-client that gets an IP from my ISP. On the inside I have two client VLANs with open AAA profiles to put them in a role with a session ACL of allowall and NAT internet traffic out the uplink interface.

So the way I see it there's a couple of different ways to do this. I could either apply an extended ACL to the physical port that uplinks to the ISP or on the RVI that gets the DHCP address from the ISP. Either way I apply it (ingress on physical port for example) it messes up my connectivity from the clients to the internet. Shouldn't the session ACL on the role take care of return traffic?

My goal:

To allow only IKE and SSH to the public IP of the switch. Deny rest.

Maybe port forward something to the inside like an FTP server.

Allow all from my internal clients to the internet.

Any tips on how to accomplish this on the MAS?

Thanx,

Chris

Do you have bidirectional ACL entries? These are stateless ACLs. Here's an example of a management access ACL applied to the routed VLANs feeding the stack.

ip access-list stateless MANAGEMENT-SSH-ACL-STATELESS-B
  alias NET-MGT-IP-B   alias SWITCH-IPS-B any  permit
  alias SWITCH-IPS-B   alias NET-MGT-IP-B any  permit
  alias DHCP-SERVERS-DEST-B   alias SWITCH-IPS-B svc-dhcp  permit
  any   alias SWITCH-IPS-B any  deny
  any any any  permit
!

Hi!

Thank you for your quick reply, it made me understand abit more about how the ACL works on the VLAN interface. Allthough I don't think I'll be able to use an alias for the switch IP since it'll be dynamically assigned. Is there a way to make the alias dynamic?

I tried writing it without using the alias for the switch but then I get stuck on the deny rule:

ip access-list stateless UPLINK
   alias MGMT-NETS any any permit
   any any svc-dhcp permit
   any alias MGMT-NETS any permit
   any alias SWITCH? any deny
   any any any permit
!

The scenario is to be able to deploy this switch on a dynamically assigned IP from ISP and still protect it from the big bad internet. It'll be building IPSEC VPN to a centrally placed mobility controller.

Any ideas?

That's a great question. I haven't been presented with that situation (yet) so I'm not sure. We'll have to wait for Madani to chime in :)

Ok, thank you for your help :) (finally on my new account, yay)

Best regards,

Chris

Anyone have any ideas on this? It's quite an important issue if you want to be able to place the MAS directly facing the internet.

Chris,

Port ACLs (PACLs) and Router ACLs (RACLs) get applied in hardware prior to hitting software engine which handles session ACLs. Here is a simple configuration disabling inbound access to a number of services running in the MAS but then allow all other traffic in to be handled by the software engine.

!
netservice svc-snmp udp 161
!
ip access-list stateless BLOCK-EXTERNAL
  any any svc-dhcp  permit
# Allow inbound DHCP
  host 54.225.97.119 any svc-ssh permit
# Allow SSH from 54.255.97.119 (Aruba as an example. This would be your headend site where you would SSH from)
  any any svc-ssh  deny
# Block all other SSH traffic coming to port 22
  any any svc-ftp  deny
# Block FTP traffic to the switch due to a bug in AOS 7.3.1.0 and below where FTP port will be open
  any any svc-snmp  deny
# Block SNMP traffic to the switch
  any any svc-ntp  deny
# Block NTP requests to the switch
  any any any  permit
# Allow all other traffic which will then go to the software engine
!
web-server
   no mgmt-ui-ports
# Closes ports 80, 443 and 4343, effectively disabling the Web-UI
   no captive-portal-ports
# Closes ports 8080, 8081 and 8088 effectively disabling captive portal functionality
# If captive portal is needed, re-enable and add these ports to the 'BLOCK-EXTERNAL' ACL
!
interface-profile switching-profile "VLAN1"
!
interface-profile mstp-profile "PORTFAST"
   portfast
!
vlan "1"
   description "PUBLIC"
!
interface vlan "1"
   session-processing
   ip address dhcp-client
   ip access-group in "BLOCK-EXTERNAL"
!
interface gigabitethernet "0/0/23"
   mstp-profile "PORTFAST"
   switching-profile "VLAN1"
!

Thank you madjali! That worked out just the way I wanted to. :smileyhappy:

Another question I have is if it's possible to port forward services from the dynamic extarnal IP to a server on the inside. Say for example they use an FTP server that registers with DynDNS and they would like to port forward FTP ports to that server from the external interface. Is this possible?

Chris,

That is not possible today since we need session ACL support to handle the destination NAT. We are working on providing that solution in a forthcoming software release. I would recommend reaching out to your Aruba Partner or Aruba SE and we can provide more details on the roadmap and future capabilites we have planned.

Best regards,

Madani

Thank you for your quick answer! Have a nice day :)

Chris

Thanks very much for this - it's helped a lot.

Question - is there a way to close of web access on the WAN side (in my case VLAN 99 on port 18) but allow it via the internal management VLAN and ports?

It seems like:

!

web-server

   no mgmt-ui-ports

# Closes ports 80, 443 and 4343, effectively disabling the Web-UI

   no captive-portal-ports

# Closes ports 8080, 8081 and 8088 effectively disabling captive portal functionality

# If captive portal is needed, re-enable and add these ports to the 'BLOCK-EXTERNAL' ACL

!

would shut down all web-ui across the whole switch.

AOS 7.4 added support for session ACLs on L3 interfaces. Here is an example that should meet your needs. You could also modify the ACL to allow web-ui access from specific hosts.

!
interface vlan "1"
   description "INTERNET-RVI"
   ip nat outside
   ip address dhcp-client
   ip access-group session "PROTECT-WAN"
!

ip access-list session PROTECT-WAN
  any any svc-dhcp  permit
!

"any any svc-dhcp  permit" stops HTTP/HTTPS traffic?

I have a hardcoded public IP on my WAN interfaces, so don't think I need to do anything with NAT or DHCP.

Based on the OP and response, I added this:

ip access-list stateless BLOCK-EXTERNAL
any any svc-ssh deny
any any svc-ftp deny
any any svc-ntp deny
any any any permit
!

interface-profile switching-profile "WANProfle"
access-vlan 99
native-vlan 99
!

interface vlan "99"
ip access-group in "BLOCK-EXTERNAL"
ip address xx.xx.xx.xx 255.255.255.252

!

and that has indeed blocked SSH. But my syslogs are showing httpd attempts from external addresses. Is there a svc-http, svc-https that could be added to the service deny list? Or would that block all web traffic through the switch? I certainly don't want that!

Thanks for your help!

So you want to be using a session ACL for the WAN facing side instead of a stateless ACL. The reason being that return traffic sourced from the LAN side will be allowed while traffic originated from the WAN side is dropped. Additionally there is an implicit deny at the end of any ACL. With the following:

any any svc-ssh deny
any any svc-ftp deny
any any svc-ntp deny
any any any permit

You are blocking specific inbound protocols but allowing everything else which may not be what you want. The original post was from pre-7.4 when we didn't have session ACL support on L3 interfaces so it made it somewhat complicated. For 7.4, you really want to use session ACLs. It makes life much easier.

And yes the only reason I had the DHCP ACL was because my MAS is connected behind a cable modem handing out DHCP.

Best regards,

Madani

Thanks for the rapidity of reply, and sorry for my ignorance on this. I'm still unclear on what to code my WAN interface VLAN to deny web-ui connections, but allow web traffic to otherwise flow through the switch.

I'm on 7.4.0.2  I could turn off web-ui in general, but I'm pretty weak on the CLI end of things, so would rather not.

I am recording this sort of notice in syslog:

 4/29/2015 15:45 10.110.138.13 Error Apr 29 14:46:03 Aruba-S1500-Admin-WIFI.138:PRI-0 httpd: [cgid:error] [pid 9602:tid 98311] [client 203.157.45.75:52554] AH01264: script not found or unable to stat: /mswitch/apache/cgi-bin/php-cgi, referer:

Which I am assuming means some unwanted http traffic was presented to the switch.

Thanks again.

Ah okay, so you don't really want it to act like a firewall then. Got it. This ACL should work for you, just replace the IP address with your static IP.

!

ip access-list extended BLOCK-WEBUI-ALLOW-ALL
  deny tcp any host 1.1.1.1 eq 443
  deny tcp any host 1.1.1.1 eq 4343
  permit any any any
!

Then apply it to your L3 interface with "ip access-group in BLOCK-WEBUI-ALLOW-ALL". I'm using an extended ACL so that A) I'm doing hardware filtering and B) I'm being specific that it is traffic destined to the switch and not through the switch.

Hope we got it this time.

Best regards,

Madani

Thanks madani. I put that in my config and applied the ip access-group in BLOCK-WEBUI-ALLOW-ALL to the interface gigabitethernet 0/0/18.

I am still able to web into the public address, although at the moment I am inside my network. I will try later from home.

Is a reboot necessary? And speaking of which, is there anyway to schedule a reboot? It would be awesome to tell the switch to reboot after hours

No, you need to apply it to the L3 interface (aka RVI), like "interface vlan 10", which ever is your public L3 interface. I just ran a quick test on a switch to make sure I didn't typo the original ACL so it should work. For good measure you can also block port 80 but we just use that as a redirect to 443 and 4343 so if the latter are blocked, you still should NOT get the UI.

Regarding the reload ability, it isn't supported today but I think there is an idea portal entry for it so I would submit a vote.

Best regards,

Madani

Got it, and thanks again!

Now I am seeing a slew of [aaa] Authentication failed for user... messages, trying to connect to port 22 . I suppose I'm just seeing everybody testing the door?

Yup. You might want to lock that down too. :)

deny port 22 or is there a svc-aaa that I should block?

Just deny port 22.

OK, done and thanks. You're quite awesome.