In this blog post I’d like to present the recent progress made for Eewids. This time, our main focus was the performance of the current setup. Besides we did some minor improvements, mostly adding some more dashboards to Grafana to visualize the data captured. This blog post focuses the results regarding Kismet as a component of Eewids. For an introduction of Eewids see here and for the first update here.
802.11 Frame Types and Their Influence on Bandwidth
Eewids is supposed to be a highly distributed WIDS which is easily scalable and manageable. To make this possible, it is important to mind the amount of data sent by the AP to the RabbitMQ server. A too high amount of data could simply exceed the typically available bandwidth and thus make using Eewids unfeasible.
We analyzed two example data sets and the distribution of frames in these sets to evaluate the necessity to change the setup of Eewids. The first set was captured in the reading room of a public library and the second in an apartment building. Both sets have in common that only a few frame types take up most of the data. The main difference is the distribution of these frames within the data sets.
As the library is a crowded place where a lot of data is transferred, most of the data is used up by Data frames and RTS/CTS frames. Beacon, Probe Request and Probe Response frames have a notably proportion in both data sets, but are the most often seen frames for the apartment building. This is not surprising as in the apartment environment is less data sent in general, thus less RTS/CTS frames and less Data frames are seen.
One lesson is that it may be necessary to filter specific frames to reduce the needed bandwidth notably. In crowded areas the Data frames take up a huge amount of space. One way to address this fact would be to drop all Data frames. This can be done independently of Kismet’s remote capture by setting the corresponding type for the monitor device. In this case the meta information of the Data frames is lost as well though.
Therefore, we recommend to capture the Data frames, but cut off the payload only. It should be encrypted in most cases anyway and therefore is of no use. Cutting off the payload would save a great amount of bandwidth and at the same time keeps the information of how many Data frames where send by which STA etc. Furthermore, it should be possible to change filter setting in runtime, e.g. only capture Management frames, if this sounds reasonable for a user.
As Kismet’s remote capture is not able to do any of this, we can not simply proceed as before. We may *could* expand the capabilities of Kismet’s remote capture. We had realized some other issues with the Kismet setup though.
Disadvantages of Kismet
Kismet’s objective is not to serve the needs of a distributed and highly scalable WIDS. Because of this we identified some disadvantages of Kismet for our approach which are, among others:
- There is no possibility to filter for specific frames
- Data payload can not be cut off (both points as discussed above)
- There is no authentication method available which suits microservice approach (e.g. no API tokens etc.), but only webauth with a single user account
- There is no secure channel for the communication between Kismet remote capture and Kismet server (one shall use SSH instead)
- It is not possible to control the remote capture via REST API or alike
- At least it is overblown for our specific use case (what we had accepted before)
- Eewids needs to keep up with version changes of Kismet and compile the whole project, although we need only some features
Towards a Straightforward Capture Tool
We consequently plan to replace Kismet as a component of Eewids with a simple capture tool which serves our needs. We identified the following necessities:
- Ability to filter for frames/exclude frames from capture
- Ability to cut off payload of Data frames
- Ability for remote configuration, during runtime if feasible
- Authentication methods via API tokens for configuration
The main objective is to have a simple capture software (probably on basis of board tools like tcpdump) which just sends the packets directly to RabbitMQ server and thus uses its authentication methods and secure channel option right away. The captured data will be parsed by services in the data center afterwards which is then used by the detection methods as before.
Thus, we’d like to concentrate on building such a capture tool based on existing tool sets for the next period and further improve the existing components.
