Adds Proxy Protocol support to the SSH honeypot server. When enabled, the honeypot looks for a Proxy Protocol header on client connections and extracts the client IP from the header. This IP is used as the "source IP" for threat feed updates and logging.
To accommodate this change, the SSH password callback function is now set when a client connects. Previously, it was defined during server startup.
Adds Proxy Protocol support to the TCP honeypot server. When enabled, the honeypot looks for a Proxy Protocol header on client connections and extracts the client IP from the header. This IP is used as the "source IP" for threat feed updates and logging.
This change adds a configuration option to enable Proxy Protocol (not yet implemented). Planned for TCP and SSH honeypot types. Use `<useProxyProtocol>true</useProxyProtocol>` in the XML config.
This change adds a new proxyproto package to support Proxy Protocol versions 1 and 2. This package allows extraction of the original source IP address from Proxy Protocol headers.
This change switches net.IP to netip.Addr added in Go 1.18. This results in slightly better performance and memory utilization for very large threat feeds (over 500,000 entries).
This change updates the logging behavior of the HTTP honeypot. If a custom custom source IP header is configured:
- The actual connecting IP is logged as `remote_ip`.
- The IP extracted from the header is logged as `source_ip`.
- Any problems extracting an IP from the header results in `source_ip` falling back to the actual connecting IP.
- A new `source_ip_parsed` field indicates whether an IP was extrracted from the header.
- If parsing fails, a `source_ip_error` field is included with the error message.
If no custom header is configured, logging behavior remains unchanged.
This change improves usability of the threat feed web interface when you have HTTP honeypots behind a proxy. By logging the original client IP as `source_ip`, the application now correctly displays the actual source of the connection, rather than your proxy's IP address.
This change adds optional support for running the threat feed server over HTTPS. This is controlled via the configuration file. Depending on the confgiuration, the threat feed may operate over either HTTP or HTTPS, but not both.
The following configuration options are added to the threat feed (the `<threatFeed>` section in the conffguration file):
- `<enableTLS>` - If `true`, the threat feed uses TLS. If `false` or if this is missing, use HTTP.
- `<certPath>` - Path to TLS cert in PEM format.
- `<keyPath>` - Path to private key in PEM format.
Default configuration files are updated to include the new settings. The TLS feature is off by default. Existing user configuration files only need to be updated if this feature is needed. Otherwise, existing configuration files start the threat feed using HTTP as before.
When the threat feed server starts in TLS mode, it automatically generates a self-signed cert if the cert and key files aen't found.
Add `withCustomError` middleware that intercepts HTTP error responses and replaces them with a custom error response.
This is used when the HTTP honeypot is configured to serve content from a directory. It ensures that all error responses from http.FileServerFS are controlled and predicatable.
Add noDirectoryFS wrapper to disable directory listings from http.FileServerFS. This is used when the HTTP honeypot is configured to serve custom content from a specified directory.
Add support for serving static files from a directory specified via the existing `homePagePath` setting. When this setting points to a directory, the honeypot serves files rooted at that directory. The original behavior of serving a single file is still supported.
When serving from a directory, the honeypot may serve files from the directory root and from any subdirectories. Symbolic links are followed, provided they don't lead outside the specified root directory.
Main changes:
- Add `responseMode` type to represent how the honeypot serves content (built-in default, specific file, files from a directory).
- Add `responseConfig` struct to store the responseMode and related configuration.
- Add `determineConfig` function to construct a responseConfig when the honeypot starts.
- Update the honeypot request handler to serve content based on the response mode.
- Add `serveErrorPage` function to serve error responses as needed.
This change pre-parses all html templates from the `templates` directory and stores the results globally. With this change, http handlers no longer need to re-parse templates on every request.
This change adds the ability to view various statistics for honeypot log data. This includes views such as unique SSH usernames, unique HTTP paths, unique HTTP host headers, etc.
A new `/logs/{logtype}/{subtype}` route is added for rendering stats.
This change moves the nav bar for the threat feed web interface to a dedicated template defined in `nav.html`. HTTP handlers and existing HTML templates are updated to utilize the new template.
This change adds tooltips to the live logs for HTTP log data. Hovering over an HTTP even reveals the full HTTP request details.
Updated style.css to support the new tooltips.
Other changes:
- Minor color changes applied to the web feed.
- Minor text revisions in `home.html` and `docs.html`.
This change adjusts the webfeed.html template to return timestamps in ISO 8601 format in UTC and instead uses JavaScript to format and display using the user's local time.
JavaScript is also used to add a thousands seprator to values in the 'Observations' column.
When formatting the 'Added' column, the time is dropped and now displays as YYYY-MM-DD.
This change adds support for WebSockets using Google's WebSocket package.
When the threat feed server is starting, a Go function is created to monitor honeypot log data via a channel. When log data is received on the channel, it is broadcast to all connected WebSocket clients.
A /live endpoint and handler is added for serving the live.html template. This page displays the log data in real time by utilizing WebSockets.
Updated the nav bar on all html pages to include the new 'Live' icon for accessing the realtime log.
The Monitor type is an io.Writer that sends data to a channel. It is meant for use with the honeypot logging system. This will allow the threat feed to provide real-time monitoring of the logging system while simultaneously logging the data to disk.
This change adds a /config handler for displaying the Deceptifeed configuration. An icon is added to the nav bar for accessing the page.
- Add config.html template for displaying the Deceptifeed configuration.
- Add config.html supporting styles to style.css.
- Add /config http handler to render the config.html template.
- Add icon to nav bar for accessing /config page.
This change removes the `CustomThreatsPath` setting from the threat feed configuration. The default configuration files are updated with this setting removed.
This change allows for comments in the exclude list using the `#` symbol. The `#` symbol on a line and everything after it is ignored when parsing the exclude list.
- Add `Version` string var to config package for storing version information.
- Update Makefile to set the `Version` variable at build time using the latest Git tag.
- Add `-version` flag to main package to print version information and exit.
- Remove setting the GO111MODULE environment variable from Makefile when building. It's not needed.
This change removes the 'threat score' feature which allowed users to configure each honeypot server with a variable 'score' when updating the threat feed.
It is replaced with a fixed observation count that is incremented by 1 for each honeypot interaction.
The field `threat_score` has been replaced with `observations` in all API call parameters and threat feed data.
The `threat_score` field in the CSV file has been renamed to `observations`. Existing threat feed CSV files will be automatically updated on the next threat feed save.
This change explicitly sets the default SSH banner in the running configuration when the application starts.
If starting without a configuration file, the global default banner is always used.
If starting with a configuration file, the global default banner is used when no banner is specified.
Adjust the html templates for web feed and log viewers to check if there's any data to display. If no data, a message is shown informing the user that there's no data.
Previously:
When no log path was specified for a server, it would fall back to the global/default log path during logger initialization. However, the `LogPath` field didn't update and would not reflect the actual path used by the logger.
Now:
Log path determination is handled while the configuration is loading. If a server falls back to the default log path, the `LogPath` field is updated to reflect the actual path used by the logger.
