Changed all commands that use long arguments to short arguments in the installation script and Makefile. This improves compatibility, as short arguments are more universally supported.
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 forces the `WWW-Authenticate` casing for the default HTTP response header on the HTTP/HTTPS honeypot servers. Previously, Go automatically converted it to `Www-Authenticate`. This update matches the casing used by most other web servers. The change is intended to reduce the risk of fingerprinting the honeypot server by making it behave more like a typical web server.
This changes modifies the HTTP/HTTPS honeypot servers to return an empty response body by default. While status codes remain intact, the body content is now empty. This change is intended to minimize the risk of fingerprinting the honeypot 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 removes the logging of source ports for connecting clients in the honeypot servers. The source port does not provide value for this type of honeypot and only clutters the logs.
This change adds a 30-second deadline to SSH connections. Client connections are forced closed after the deadline.
Additionally, a 2-second delay is added prior to rejecting authentication requests. This mimics the `pam_faildelay` PAM module found on modern Linux systems.
This change adds a public key authentication callback function to the SSH honeypot server. All requests are rejected, and currently, no data is logged.
This change removes unnecessary channel handling code from the SSH honeypot server. Since authentication requests are always rejected, `ssh.NewServerConn` will consistently return an error, making the channel handling redundant.
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.
Previously, setting `expiryHours` to `0` did not prevent IP addresses from expiring in the threat feed. This has been corrected. Now, when `expiryHours` is set to `0`, IP addresses never expire from the threat feed.
* Add `-y` and `--yes` command-line arguments to the installation script. Setting this argument sets the `auto_confirm_prompts` variable to `true`. When a confirmation is needed, the variable is checked to determine whether to show a prompt or to auto-confirm.
* Add `print_usage` function to print basic help and usage information. It is shown if an unsupported argument is supplied (including `-h` and --`help`).
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 commit improves performance for handling large threat feeds by adjusting the timing of CSV file saves. Previously, any changes to the IoC map triggered an immediate write to disk. Now, the IoC map is saved in a separate goroutine using a timer that triggers every 10 seconds.
This change adds an HTTP middleware to the threat feed server, restricting access to private IP addresses. This enforces a secure default, as the threat feed is not intended for public sharing. A separate HTTP proxy server can be used to implement public sharing.
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 custom logger to the HTTPS honeypot to discard error output. Without it, TLS handshake errors would generate unwanted error messages from the application. Since this is a honeypot server, we have no interest in seeing those types of errors.
