2

I just replaced our network gears with Aruba 2930f. I had gone through all basic security such as DHCP snooping, DHCP trusted port and BDPU. One thing I don't know if I am able to shut down the sw port if someone uses wireless routers or rogue routers to connect our network? For now, when I plugged in my WAN port from wireless router to the 2930f switch port; wireless router did not create any network problem. But when I connected my laptop to wireless router and got IP from the router; I'm still able to ping or routing to corporate subnets. Is there any way to avoid that? I can create access list but I want to see if there is any Aruba CLI would solve this problem.

Thanks guys

  • Short of MACsec (802.1x), there's not a lot you can do to control what gets plugged in. How do you know there's a router at the end of the wire? You. Don't. (hint: linux, windows, and mac can all act as a router) – Ricky Nov 21 '17 at 0:23
  • 1
    @RickyBeam I think you mean NAC. MACsec is 802.1ae – Ron Trunk Nov 21 '17 at 4:01
  • Yeah, macsec is link-level encryption. (that'd do it too :-)) – Ricky Nov 21 '17 at 6:35
2

One thing I don't know if I am able to shut down the sw port if someone uses wireless routers or rouge routers to connect our network? ... I want to see if there is any Aruba CLI would solve this problem.

The simple answer is no, there is no "silver bullet" CLI command that will resolve this issue. Using port security and 802.1X will help to prevent such devices from getting connected in the first place, however even these can be worked around. So to be thorough you also need to take some steps to detect when they are connected.

To begin, there is a difference if the AP/router connected to the network is running as a gateway or if it is running as a bridge.

Dealing with the latter first as it is relatively easy to detect by simply locating ports to which multiple MAC address are connected. These ports will either have an AP (in bridge mode) or another switch connected and you won't be able to tell the difference, but neither are something you want end users to be connecting to the network without your knowledge. The quick fix is to limit the number of allowed MAC addresses on an access port to a reasonable number using port security.

Also, most enterprise class wireless rogue detection will be able to correlate rogue clients in the air and on your wired network. If they are connected to a wireless network other than yours and also appear on your wired network, then the system should be able to find them (and possibly take action).

Moving on, if the AP/router connected to your network is functioning as a gateway device (i.e. NAT, running it's own DHCP service behind the device, etc), things become a bit more complicated. The entire purpose of such a device is to allow multiple devices to connect to a network and appear as one device.

This doesn't mean you can't locate them, it just means you (or a tool you use) needs to take further action or analysis, and quite possibly more than one. Here are some of the methods of which I am familiar:

  • TTL based detection methods are my personal favorite as they tend to be fairly quick and reliable (especially on simple networks). Every router that an IP packet passes through decrements the TTL by 1. How you actually perform such detection can range from simple packet captures to using management platforms with features for this type of detection. Here is a decent write up on using sFlow to detect NAT devices based on TTL detection.
  • Network scans (especially with OS detection) can locate a number of these devices reliably based on the OS and/or services available on the outside of the device.
  • OS fingerprinting methods (Passive, DHCP, etc) can use various characteristics of captured traffic to determine the nature of devices connected to your network. With this you would look for traffic that gives conflicting results (some traffic matches OSX and other matches Windows) or that can identify a rogue network device.
  • Analysis of traffic (volume, type, nature, etc) may also indicate where such devices are connected when compared to "normal" clients on your network. For instance, you can compare user-agent strings in HTTP requests for discrepancies (i.e. mobile device traffic appearing on the wired network or two different versions of Chrome/Safari both making requests from the same IP, etc). Or if there is a server everyone logs into, you may be able to identify IP addresses where more than one user connects from at the same time.
  • If the wireless network is open (no WEP/WPA/WPA2), simply connecting to the wireless network and determining if you have an IP on the local network should give you enough information to locate it on the switch.

Neither prevention methods nor detection methods are perfect. Ultimately you need to decide what level of protection is considered acceptable for your organization/environment. In some environments, this may be simply implementing one or the other. In other environments, it may require a range of actions to both prevent and detect such rogue devices. Obviously the more involved the solution, the more the organization has to be committed to providing time and resources to implementing and maintaining the solutions.

| improve this answer | |
  • Thank you YLearn... This is very informative. I understand that it's very hard to detect who use what in a corporate environment but it worth a shot to ask :). – Will Nov 27 '17 at 20:19
  • TTL can also be used to block those roque devices, just configure your own network to set the TTL of packets to 1 if its larger, then the wireless router will drop the packet, because the TTL has become too low – Ferrybig Mar 14 '19 at 21:12
  • @Ferrybig, I mention TTL detection. As for your suggestion, first it won't do anything for bridged connections and second I am not aware of any current enterprise network devices that will allow you to modify the TTL of an IP packet in transit to a fixed value. This can cause problems and won't work with IPv6 hop count (which can only decrement by one). I do know of a number of platforms that allow you to configure the TTL for IP traffic generated by the platform, but not for IP traffic in transit through it (aside from the normal TTL decrement process). – YLearn Mar 14 '19 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.