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.
This change removes the `CustomThreatsPath` setting from the threat feed configuration. The default configuration files are updated with this setting removed.
- 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.
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.
This change configures the honeypot loggers to use the internal `logrotate` package. This enables automatic log file rotation. The maximum log size is set to 50 MB.
This change adjusts logger initialization to ensure only 1 file handle and 1 logger is created per unique log path.
Each honeypot server may have its own log path specified, which may be unique or may be shared with other honeypot servers.
Previously, each honeypot server would open a separate file handle and logger, even if the file was already opened by another server.
This change adjusts the default SSH server version string to `SSH-2.0-OpenSSH_9.6`. This makes SSH honeypots appear as OpenSSH 9.6.
The change is applied both to default configuration files and as an application default when no configuration is provided.
- Added a new `<errorPagePath>` configuration option. This lets you specify a custom error page for HTTP and HTTPS honeypot servers. Only a single static HTML file may be specified.
- Renamed `<htmlPath>` to `<homePagePath>` in the configuration.
- Changed the default threat expiry hours from 168 (one week) to 336 (two weeks).
- Changed minimum threat score from `1` to `0` for honeypot servers.
This change modifies the configuration for HTTP honeypot servers. Previously, custom headers were defined using the `<banner>` element, which was shared with SSH and TCP honeypot servers. Now there is a dedicated `<headers>` element allowing any number of `<header>` elements to be defined for custom HTTP response headers.
Before (old configuration):
```xml
<server type="http">
<banner>Server: Microsoft-IIS/8.5, X-Powered-By: ASP.NET</banner>
</server>
```
After (new configuration):
```xml
<server type="http">
<headers>
<header>Server: Microsoft-IIS/8.5</header>
<header>X-Powered-By: ASP.NET</header>
</headers>
</server>
```
This change revises the configuration for custom prompts in the TCP honeypot server. Previously, `<prompt>` elements were defined directly within the `<server>` element. In the new configuration, a `<prompts>` element is used to enclose any number of `<prompt>` elements.
Before (old configuration):
```xml
<server type="tcp">
<prompt>Username:</prompt>
<prompt>Password:</prompt>
</server>
```
After (new configuration):
```xml
<server type="tcp">
<prompts>
<prompt>Username:</prompt>
<prompt>Password:</prompt>
</prompts>
</server>
```
This change adds a new `<sourceIpHeader>` element to the HTTP/HTTPS honeypot server configuration. It allows you to specify an HTTP header to use as the source IP address when updating the threat feed.
You would set this option if the HTTP honeypot server is behind a proxy server. Typically a proxy would set an HTTP header, such as `X-Forwarded-For`, that records the source IP of the originating client.
Example configuration:
```xml
<sourceIpHeader>X-Forwarded-For</sourceIpHeader>
```
This change introduces a `negate` attribute to `<include>` and `<exclude>` rules in the configuration. When `negate` is set to `true`, the rule applies when the regex pattern does not match.
For example, the following _include_ rule matches when the HTTP request does not equal "GET", "HEAD", or "OPTIONS":
```xml
<include target="method" negate="true">(?i)^(GET|HEAD|OPTIONS)$</include>
```
This change adds Rule and Rules structs for HTTP honeypot configurations. The rules are regex patterns that define when an HTTP request should trigger an update the threat feed.
The Rule struct allows you specify a target that defines which part of the HTTP request should match your pattern.
Example configuration:
```
<server type="http">
<rules>
<match target="path">\.php$</match>
</rules>
</server>
```
This example triggers an update to the threat feed only if the HTTP request path ends with `.php`. Any other request will not trigger an update.
This commit introduces a MinimumThreatScore setting to the threat feed server. This setting allows users to filter IP addresses based on their threat score. Only IP addresses that meet or exceed the specified threshold are included in the threat feed.
This change introduces a ConfidenceLevel configuration setting for honeypot servers and the IoC struct in the threat feed database. Each IP in the database now maintains a confidence level. Whenever a honeypot calls UpdateIoC, the confidence level of the IP is incremented by the configued amount for the honeypot.
This change sets the Unix file permissions to `0600` for generated private keys saved to disk, ensuring that ownly the owner can access the keys. While private keys for the honeypot servers are mostly insignificant, this change aligns with typical private key permissions.
This change adds a new XML element, sendToThreatFeed, to the configuration for servers to control whether interactions with the server should update the threat feed.
This change adds a new option in the threat feed configuration for specifying a file path for an exclude list. If this path is provided, IPs in the file will be excluded from the threat feed.
This change moves the slog.Logger from the Config struct to the Server struct, allowing each honeypot server to have its own logger. Each server can now specify a custom log file path, defaulting to the main log path in the Config if none is provided.
This change modifies the XML schema for the configuration file. The top-level `logPath` element is renamed to `defaultLogPath`. This adjustment prepares for a future change to allow each server to specify its own log path.
This change adds a new threat feed configuration option `customThreatFile`. The option allows you to specify a text file containing additional content for the threat feed. The contents of the custom threat file are appended to the output of the threat feed. This could be IP addresses or any other type of text.
