Webserver

Kismet integrates a webserver which serves the web-based UI and data to external clients.

Kismet does not have a default username or password. The first time Kismet is run the web UI will require the creation of a user and password.

The password is stored in ~/.kismet/kismet_httpd.conf which is in the home directory of the user which started Kismet.

You will need this password to log into Kismet in the future, and to give scripts and tools which need administrative access to Kismet the login.

The webserver is configured via the kismet_httpd.conf file. These options may be included in the base kismet.conf file, but are broken out for clarity. We recommend you use kismet_site.conf to make changes to the configuration.

HTTP configuration options:

The web UI #

After 2026-10-R1, Kismet serves a new web UI at / (for instance http://localhost:2501/), and the previous UI at /legacy/ (http://localhost:2501/legacy/). The Legacy UI item in the new UI’s top bar opens the previous UI.

Plugins which add pages to the previous UI keep working in it from /legacy/; the new UI lists plugins which don’t have a page for it yet.

Both UIs use the same login, and settings in one don’t change the other.

Other parts of the new UI:

• Packet rates, in the menu or from the packets count in the top bar, graphs the packet rate of each data source, with dropped packets, errors, and events such as sources opening, and links to the channel heat map.
• Settings, Units picks how speeds (km/h, mph, or knots) and lengths (meters and kilometers, or feet and miles) are shown, including the map’s range rings.
• Channel coverage, in the menu, shows what the data sources are hearing on each frequency, in three views. Live has a bar for each frequency, labeled with its channels and frequency, and a waterfall of the last minute. Heat map shows activity on each frequency over the last minute, hour, or day. Time estimates how much of the time each frequency is listened to, from each source’s channel list and hop rate: a hopping source gives each channel in its list an equal share, and sources which split a channel list share it. It shows the time each source spends in each band, how long each visit to a frequency lasts and how often it comes back, and highlights frequencies with traffic which are heard less than a quarter of the time. A wide Wi-Fi channel counts at its primary frequency; an SDR source counts across its whole range. The estimate leaves out the time taken to change channels and sources which have stalled. 802.15.4 and Zigbee sources are shown on their real frequencies, labeled with their own channel numbers.
• Settings, Device Highlights colors rows in the device list by device rule tag, by the type of radio (phy), and by other phy-specific highlights. Tags and other highlights can be dragged into priority order; picking a color turns its highlight on.
• The device list has a Tags column, which can be searched and sorted, and the device details list a device’s tags first, with the rules that set them.
• The device list’s Search or filter box searches for plain words as before, and takes device filters.

The new UI’s map can draw the receiver range for each kind of device on it: the furthest distance devices were heard at in each direction over all time, over the last day, or by altitude, with range rings. Without Kismet’s own location, it draws the area the devices were heard over.

Map backgrounds #

After 2026-10-R1, the new UI’s map draws its background from a tile server: OpenStreetMap, unless the Kismet server or the browser sets another. Loading tiles tells the tile server what area is being looked at, so a browser never loads them without asking first. The map asks Load the map background from the internet?, with Load the map and Use a blank map, and asks again whenever the tile server changes from the one agreed to. Don’t ask me again for this server remembers the answer for that tile server only; Don’t ask for any tile server remembers it for any server.

Under Settings, Map, a browser can set its own tile server. Fetch map tiles from a remote server turns the background on, agreeing to the tile server shown, or off for a blank map, and Ask before using a different tile server can be cleared to stop asking when the tile server changes.

The previous UI’s ADS-B map also asks before loading tiles, and not asking again covers only the tile server it names.

The Kismet server sets the tile server for browsers which haven’t set their own, in kismet_httpd.conf (or kismet_site.conf):

The UI reads these from /ui/map_tiles.json.

Installing the web UI as an app #

After 2026-10-R1, the web UI can be installed on a phone or desktop as an app, with its own icon and window. Browsers only allow this over HTTPS they trust, so the Kismet server must either use Kismet’s own HTTPS, with the Kismet CA installed on the phone, or be behind an HTTPS proxy with a trusted certificate. The Install as an app settings in the web UI walk through it, and the installed app can switch between Kismet servers.

Runtime censorship #

Kismet can censor aspects of the UI to make it easier to share screenshots or demos without revealing your location via MAC addresses, SSIDs, or location data.

Censorship mode can be enabled by adding ?censor=1 to the Kismet URL, for instance http://localhost:2501?censor=1. After 2026-10-R1, censorship is available in the legacy UI, for instance http://localhost:2501/legacy/?censor=1.

After 2026-10-R1, the new UI has censor mode under Settings, Censor mode, and also takes it from the page address, which wins over the settings for that page:

Partly hidden, a MAC address keeps its manufacturer half, a name its first and last two characters, and a location its whole degrees.

Kismet and SSL #

The best way to provide SSL support for a Kismet server reached over the Internet is to wrap it with a HTTP proxy such as nginx. This simplifies the process of obtaining public certificates from services like letsencrypt, which typically expect the webserver to be able to answer dynamic challenges.

After 2026-10-R1, Kismet can also serve HTTPS itself, on its own port alongside the plain HTTP port. This is meant for a local network, such as reaching Kismet from a phone, and especially for installing the web UI as an app.

When should I use SSL? #

SSL provides encryption between the Kismet server and the web browser, and between the Kismet server and remote capture sources.

SSL is usually not considered necessary when using Kismet exclusively locally (such as on a laptop or on a dedicated capture device connected to your laptop), however if you plan to use Kismet remotely over a public network or over the Internet, enabling SSL is a must.

Using proxies and forwarding #

Kismet supports being proxied through a HTTP/HTTPS proxy such as nginx. This allows using standard configuration of certs on the public server, instead of moving the configuration to Kismet.

1. Set up Kismet to support a proxy URI. By setting the httpd_uri_prefix variable, Kismet can handle a proxied URI directory:

   httpd_uri_prefix=/kismet
   

2. Set up the nginx proxy

   nginx proxy can connect HTTPS and HTTP endpoints. In /etc/nginx/sites-enabled/default, a location stanza similar to:

   location /kismet/ {
       proxy_pass http://localhost:2501;
       proxy_set_header Host $http_host;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Scheme $scheme;
       proxy_set_header X-Proxy-Dir kismet/;
       add_header X-Proxy-Dir kismet/;
       proxy_http_version 1.1;
       client_max_body_size 0;
   }
   

   Note the trailing slash on the proxy_set_header and add_header lines!

3. Tunnel the Kismet server over SSH

   SSH supports port forwarding/tunneling; We can use this to bring a connection to the Kismet server to the proxy system:

   $ ssh -R *:2501:localhost:2501 user@host
   

Using LetsEncrypt certificates #

LetsEncrypt (https://letsencrypt.org) provides free, signed SSL certificates which are accepted by most browsers. These certificates can be used with Kismet and may offer a simpler and more secure option than self-signed certificates.

LetsEncrypt currently uses a set of python (or third-party) clients to automatically generate certificates. In order to verify that you control the domain the certificate is issued for, you must run these scripts on the webserver with that domain.

The LetsEncrypt software can automatically configure Apache and nginx.