The previous section introduced the importance of proxy servers and the ways in which they are exploited. This section describes how KFSensor's proxy emulation works in detail and how to configure it.
Proxy honeypot deployment is more difficult than other types of honeypot, as the goal of an attack is not to compromise the honeypot system itself but to use the honeypot to attack other systems on the Internet. The emulation approach used throughout KFSensor is limited in its effectiveness, as it is not possible to accurately emulate other machines, especially one under the control of the attacker. It is straightforward for an attacker to run tests to ensure the proxy server is working as expected.
It is easy to deploy a fully functional proxy that records the traffic used by an attacker. This is extremely effective and is very difficult to detect. However this exposes the honeypot owner to great danger as they will be blamed for the resulting damage caused.
To meet the goals of preventing attacks causing damage to other systems and to make the honeypot convincing to the attacker requires a mix of the two approaches described above.
KFSensor has a number of different approaches to tackling this issue.
| Approach | Description |
| Deny access | The most conservative approach is to inform an attacker that their request has failed. This accurately emulates a secured proxy system. This will halt an attack, but some useful information can still be gathered, such as the location of the attacker and the system they are trying to compromise. |
| Read only | This approach responds to positively to a relay request and
then reads subsequent data sent by the attacker without responding. This can show the first part of an attack sequence, providing the
attacker is not expecting a banner. An event will have Record input only as its description if this approach is used. |
| Reflect to internal emulation | Many of the attacks using proxies are made to standard services notable SMTP and HTTP and other proxy servers. There are two special cases; HTTP and SMTP, where KFSensor runs a custom emulation inside the proxy connection without redirecting the attacker to another port. These custom emulations are described below. |
| Banner grab | Interactions to SMTP servers start with the server sending a banner to the client, which identifies the SMTP server. There is no standard format for this banner and many attackers use this to check that they have connected to the correct SMTP server. To improve the chances of a successful deception KFSensor can connect to the target SMTP server to obtain the correct banner, which is then returned to the attacker. The connection to the target server is then closed and all subsequent communication is between the attacker and the KFSensor SMTP emulation server. This requires that KFSensor be allowed to make an outgoing connection to an external SMTP server, which may be considered to be unacceptable in some deployments. A frequent consequence of this is for KFSensor to detect an incoming connection to ident on port 113 from the SMTP server, which is harmless. To avoid an excessive number of these banner grabbing connections KFSensor caches the banners for one hour. |
| Limited relay | The only way to pass the more complex the proxy tests employed by hackers is to enable full proxy relay functionality. One of most common tests involves a client asking for a relay
to be opened to their own machine. It can then check for the presence of this connection and compare the responses it returns. KFSensor can allow
proxy connections to be relayed back to the clients machine, which is almost always safe to do so.
This is referred to a loop back operation. There are a number of other methods for identifying a proxy test and hence allowing a connection to be relayed. KFSensor uses Proxy Rules to make these judgments. The are described in more details in the next section; Proxy Rule Configuration |
| Full relay | The final and most risky approach is to allow full unrestricted proxy relaying functionality. This provides the maximum possible level of deception and full logging of all attacks. It is recommended that this is used for research purposes only. |
The HTTP internal emulation is used to simulate a remote HTTP server being used through a HTTP proxy server. Without returning the correct content it will be very obvious to a human that the proxy is not working and it is not possibly to do so. However many hackers use HTTP proxies to run automated attacks on HTTP servers, such as HEAD requests which look for the presence of vulnerable web script pages and dictionary attacks on HTTP authentication. Against these attacks the KFSensor HTTP internal emulation can be effective.
The following special rules are used to determine the response.| Request | Response |
| GET, POST | Either a blank HTML page or a 1x1 GIF image is returned depending on the URL type |
| HEAD | Returns OK |
| Request includes authentication | Returns 401 Unauthorized |
| Request includes If-Modified | Returns 304 Not Modified |
If the grab banner is enabled then the target servers banner is used.
If the banner grabbing connection to the target server fails then a cannot connect / bad gateway error is returned.
If the grab banner is not enabled then a banner will be created using the domain name of the target server, obtained via a reverse DNS request.
The internal SMTP configuration can relay emails if allowed by the Proxy Rules
One of the main benefits of running a proxy honeypot is to enable spammers to make thousands of connections to the honeypot in order to waste their time and dispose of the spam.
The default DOS Attack Settings will lock out the spammer as this case will be interpreted as a DOS attack.
To allow for a continuous attack and to prevent an unacceptable number of events from being generated set the
Action on max concurrent option to Close and the Action on max connections per IP option to Ignore in
the DOS Attack Settings dialog box.
There are three main methods to provide a proxy connection; HTTP Proxy, HTTP CONNECT and SOCKS.
The protocols are different, but the way that they are handled internally is very similar.
All three are controlled by a combo box selections. Each option in the list provides a different level of emulation.
These are the options of the CONNECT proxy option in the Edit Sim Std Server - HTTP dialog box and the Proxy emulation option in the Edit Sim Std Server - SOCKS dialog box.
| Option | Description | |
| 1 | Disabled | A HTTP sim server returns an unsupported error. With a SOCKS sim server, the visitor will be asked for a username/password which will not be accepted. |
| 2 | Cannot connect | A HTTP sim server will return 502 Bad Gateway. A SOCKS sim server will return a fail code. |
| 3 | Read only | The sim server will return a success code for the response and then read the input from the visitor |
| 4 | Reflect only | The sim server will reflect a request to its own emulations of the requested target port. If KFSensor does not have the requested port open then a read only operation will be performed. |
| 5 | Reflect and loopback | The sim server will allow a relay connection back to an visitor's own IP and reflect all other requests |
| 6 | Reflect, loopback and banner grab | This is the same as the previous option, with the addition of enabling banner grabbing. |
| 7 | Reflect, loopback, banner grab and limited relay | This option allows for a limited number of proxy and smtp emails to be relayed if allowed by the Proxy Rules |
| 8 | Unrestricted full proxy | A fully functional proxy server. Use with care. |
A HTTP Proxy refers to the proxying of HTTP requests as part of the HTTP protocol and is therefore limited to other HTTP servers.
This is controlled by the HTTP proxy option in the Edit Sim Std Server - HTTP dialog box.
A sub-set of the options described above are supported.
The options Read only and Reflect, loopback and banner grab do not make sense in this context and are not available.
A honeypot proxy server exposed on the Internet can attack a lot of attention.
KFSensor can cope with high volumes of proxy traffic but a number of changes should be made to the configuration to optimize it for the task.
| Field | Value |
| Max Relays | 10 |
| Lock Out For | 120 |
The default DOS Attack Settings are too low for the volume of work required.
The following settings should be made. These can be further increased if desired.
| Field | Value |
| Max clients | 200 |
| Max receive size (bytes) | 10240 |
| Max receive log size (bytes) | 10240 |
| Max concurrent connections per IP | 30 |
| Action on max concurrent | Close |
| Max connections per IP | 100 |
| Action on max connections per IP | Ignore |
| Lock out for (minutes) | 1440 |
| Do not ignore every X connection | 50 |
| Max TCP connections | 100000 |
| Max UDP connections | 1000 |
| Reset lock up after (hours) | 6 |
Next Read: Proxy Rule Configuration