Security, WIDS/WIPS and Aruba ECS

Contributor II

Using ACL's to enforce user behavior. - Knocking Domain machines off the Guest SSID

I have a few clients who have content control enforcement (such as Websense) on their "corporate" SSID/net, but use a separate DSL/Cable modem without content controls for Guest Services. (Mostly for plausible deniability, as well as to avoid having the corporate network domain/ip block blacklisted or exposed due to Guest usage).

The problem with this scenario is that the if the user's have administrative control to change WLAN profiles on clients, they will quickly learn that they can surf the undesirable sites via the "Guest WLAN", with the associated impact to productivity, etc.

So we want a way to ensure that we can detect and stop this behavior.

Since domain member machines will always attempt to send udp-netbios name service requests to the domain controllers for the domain to which their joined, we define a network-dest of the DC, and a policy which will blacklist clients sourcing traffic to the DC on dest port udp-137.

We add that to the Role assigned to guests, such as our aptly named Guest-Services-Policy, and then we have a method to kick a user off of the Guest network if their client is a domain-member. The first few times you show up at the blacklisted client to find out why they attempted to use the Guest network, it's amazing how quickly word spreads....

Leverage social engineering to solve user behavioral problems.
Aruba Employee

Re: Using ACL's to enforce user behavior. - Knocking Domain machines off the Guest SSID

There was a post about methods to keep employees off of guest networks, and the solution you posted was exactly what someone else did as well. As long as there is something that every employee's laptop does in common, you can nail 'em! :D

Useful also to protect against people trying to 'spoof' PDAs

I use this technique often to prevent employee assets from connecting to the Guest network.

You can also re-use similar policies effectively if you have user derivation rules for devices such as PDAs (iPhone, Blackberry, Nokia, HTC for instance) to give those users http access. I have several sites doing this to 'skip' the captive portal on the small keyboards and just let guest internet straight out on PDAs.

The challenge being to verify if it is _really_ a PDA.

Enter the rules discussed in this thread! Once the "PDA"s start talking to the domain controller you can pretty much conclude you have a crafty user spoofing on the network to blend in with the PDAs and can blacklist his laptop turned PDA. :)
Frequent Contributor II

Re: Using ACL's to enforce user behavior. - Knocking Domain machines off the Guest SSID

We use AD to control it. Any AD user not in the Guest group is denied by the radius server. Our helpdesk/AD team can reset passwords for our guest accounts as needed (the accounts auto disable after 8 hours). If you use a radius server which can go through a list of groups in AD (or eDirectory) then this will work. Microsoft IAS is what we use to do this.
Occasional Contributor II

Restricting Domain Computers from Guest Network

I've been over various threads here, and there is no cure all so far.

A few complicatations/limitations.
1 You can only deny the SSID by group policy on Vista and newer domain clients. Nothing is availble for XP ie: netsh wlan
2 You need to be proactive in trapping this type of activity realime, addressing clients by corporate policy never gets the job done and its easily forgotten. No IT person wants to be the policy police.
3 Locking down the SSID list so users can't add thier own is not practical to support, so you do need to keep that flexible.

A You can user Group policy on Domain member Vista clients and up, to DENY the SSID
B Bill's suggestion above is a good one, I think it is close, but no cigar. I've tested it and used a packet sniffer to watch for the patterns. A domain computer does a broadcast looking for "MYDOMAIN" or "MYWORKGROUP" NOT by IP. If there is no internal DNS available on the VLAN, the public DNS will not resolve it and there will be no local IP's to trap. The VLAN is supposed to be isolated from the internal DNS servers etc.
You can trap events like: printer configuration (tcp/ip printers) phones home, or some drive mapping by IP is done from the client you might catch the IP in use.

1 Can the controller do packet sniffing for the UPD 137/138 MYDOMAIN/MYWORKGROUP request values?
2 Its not practical to use resources for a keep alive ping script or other. What other tricks are out there to do an occassional phone home?

Meanwhile, any feedback welcome :cool:
Occasional Contributor II

A solution for domain computers

One of the posts mentioned an approach triggering on a specific port.

After deep review of many packet sniffs, I've found my easter egg.
All my domain clients have microsoft firewall client. It always looks for the proxy server on tcp port 1745. I added this to the blacklist, and it works like a charm.

So my policy has a combination of any connections to the internal network of 172.x.x.x and the tcp port 1745 is a sure set to catch and blacklist the domain computers.
Occasional Contributor I

Re: Using ACL's to enforce user behavior. - Knocking Domain machines off the Guest SSID

I like this idea and would like to set this up. I put a rule to blacklist a client if they try to access a couple of our servers and it works as it should.

Is there a way I can blacklist them on only the guest SSID? As it is now the client gets blacklisted and then they are not able to connect to any SSID on the AP. I would like to just kick them off the guest and then let them back on to the employee SSID
Guru Elite

Virtual AP Blacklist Timer

On the Virtual AP for that Wireless Network, there is a Blacklist Timer. Change that blacklist timer to something short, like 1 minute and that will allow the user back on after that time. No, they will not be able to connect to any SSID, but after 60 seconds they should be able to.

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Video Knowledge Base
Remote Access Point Solution Guide
ArubaOS Consolidated Release Notes
ArubaOS 8 ViA VPN Solution Guide
Search Airheads
Showing results for 
Search instead for 
Did you mean: