┌──────────────────────────────────────────────────────┤ Configuring kismet-capture-common ├──────────────────────────────────────────────────────┐ │ │ │ Kismet needs root privileges for some of its functions. However, running it as root ("sudo kismet") is not recommended, since running all of │ │ the code with elevated privileges increases the risk of bugs doing system-wide damage. Instead Kismet can be installed with the "setuid" bit │ │ set, which will allow it to grant these privileges automatically to the processes that need them, excluding the user interface and packet │ │ decoding parts. │ │ │ │ Enabling this feature allows users in the "kismet" group to run Kismet (and capture packets, change wireless card state, etc), so only │ │ thoroughly trusted users should be granted membership of the group. │ │ │ │ For more detailed information, see the Kismet 010-suid.md, which can be found at "/usr/share/doc/kismet-doc/readme/010-suid.md" in kismet-doc │ │ package or "https://www.kismetwireless.net/docs/readme/suid/". │ │ │ │ Install Kismet "setuid root"? │ │ │ │ <Yes> <No> │ │ │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌───────────────────┤ Configuring kismet-capture-common ├───────────────────┐ │ Only users in the kismet group are able to use kismet under the setuid │ │ model. │ │ │ │ Please specify the users to be added to the group, as a space-separated │ │ list. │ │ │ │ Note that currently logged-in users who are added to a group will │ │ typically need to log out and log in again before it is recognized. │ │ │ │ Users to add to the kismet group: │ │ │ │ | │ | │ │ │ <Ok> │ │ │ └───────────────────────────────────────────────────────────────────────────┘
1 2 3 4
Dumpcap can be installed in a way that allows members of the "wireshark" │ │ system group to capture packets. This is recommended over the │ │ alternative of running Wireshark/Tshark directly as root, because less │ │ of the code will run with elevated privileges.
┌──────────────────────────┤ sslh configuration ├───────────────────────────┐
│ sslh can be run either as a service from inetd, or as a standalone │
│ server. Each choice has its own benefits. With only a few connection per │
│ day, it is probably better to run sslh from inetd in order to save │
│ resources. │
│ │
│ On the other hand, with many connections, sslh should run as a │
│ standalone server to avoid spawning a new process for each incoming │
│ connection. │
│ │
│ Run sslh: │
│ │
│ --from inetd-- │
│ standalone │
│ │
│ │
│ <Ok> │
│ │
└───────────────────────────────────────────────────────────────────────────┘
