RFprotect Distributed 5
Strengths: Very flexible; blocks dangerous and rogue access points.
Weaknesses: Difficult to get to grips with.
Verdict: Rather daunting when you first use it, but it is actually a highly flexible monitoring and prevention tool.
Standard network tools don’t work to detect and monitor your company’s wireless network policy, which is where this product steps in.
The system consists of a central console feeding into the open source Firebird SQL server, and distributed 802.11a/b/g wireless sensors. These have through-ports for PoE, so you can power the sensor and your access point without having to run new cabling.
The sensors and the information they report are configured from the central console, RFprotect. It has a useful Dashboard mode, a bit like on traffic sniffers, so you can get a quick overview of what’s happening on your network.
Getting your hands dirty and configuring the system isn’t for the faint-hearted, as there are lots of options and it is not the most intuitive application. However, it is very thorough and extremely well thought out. Once set up, you can use DHCP and DNS to automate deployment of new sensors, and the default policies are pretty good. You can import floor plans of your building, set the scale and tell it where the sensors are located. When a rogue access point or client is detected, you can triangulate its position using your sensors and have the results shown on your floor plan.
While you’ll only get a rough position, it’s enough that you can take a handheld tool and manually track the device down.
The sensors will detect every wireless device on your network, so you must choose whether they are authorised or not, so it will take a while to get the system running smoothly.
While you can define RFprotect so it just monitors and reports on the state of your network, you can also build-in protection by using UltraShield. This can be triggered by your policy to block rogue devices from communicating. The system is smart enough to track a device’s movements and will automatically reconfigure which sensor should block its transmissions.
A lot of your work will be done in PolicyEnforce, which describes what the system should do when it detects certain events. It’s quite a daunting application, and new rules are fairly difficult to build, so give yourself time to learn the system.
The five default policies cover the majority of what most organisations will want to achieve (such as blocking authorised users from unauthorised APs, and vice versa).