Using the Proxy

The SSH and Telnet proxies can be used to provide a fully-fledged environment, in contrast to the emulated shell traditionally provided by Cowrie. With a real backend environment where attackers can execute any Unix command, Cowrie becomes a high-interaction honeypot.

To use the proxy, start by changing the backend option to proxy in the [honeypot] section. In the remainder of this guide we will refer to the [proxy] section of the config file.

Choosing a Backend

Cowrie supports two kinds of backend. A simple backend is a real or virtual machine that you provide yourself. Alternatively, Cowrie’s backend pool manages a set of VMs for you: it boots and cleans them up, gives each attacker (by IP) a fresh environment, and serves repeated connections from the same IP with the same VM.

VERY IMPORTANT NOTE: some attacks consist of downloading malicious software or accessing illegal content through insecure machines (such as your honeypot). If you are using your own backend, be sure to restrict networking to the Internet on your backend, and ensure other machines on your local network are isolated from the backend machine. The backend pool restricts networking and does its best to ensure total isolation, to the best of Qemu/libvirt (and our own) capabilities. Be very careful to protect your network and devices!

Configuring the Proxy

Backend configs

If you choose the simple backend, configure the hosts and ports for your backend. For the backend pool, configure the variables starting with pool\_. You’ll also need to deal with the [backend_pool] section, which we detail in the Backend Pool’s own documentation.

The backend pool can run on the same machine as Cowrie, or on a remote one (e.g. Cowrie on a Raspberry Pi, and the pool on a larger machine). When the pool runs on the same machine, set pool to local. When it runs remotely, set pool to remote and specify its host and port, matching the listen_endpoints of the [backend_pool] section. Further configurations sent by the client are explained in Backend Pool’s own documentation.

Authentication

Whichever backend type you use, Cowrie needs credentials to access the machine. Any account on it works, as long as it supports password authentication.

Note that these are totally independent of the credentials attackers can use (as set in userdb). userdb credentials are the ones attackers may use to connect to Cowrie, while backend_user and backend_pass are used to connect Cowrie to the backend.

Telnet prompt detection

Due to the different implementations of Telnet, there is not a single reliable way of catching the authentication phase of the protocol as in SSH. Therefore, we rely on regular expressions to detect authentication prompts, allowing us to identify the credentials supplied by the attacker and check if they are accepted by userdb. If they are, we send the backend_user and backend_pass to the backend (spoofing the authentication); if not, we send backend_pass appended with the word fake to force a login failed prompt (and fail authentication overall).

If you don’t want to spoof authentication, set telnet_spoof_authentication to false. In this mode, only the backend real details will be accepted to authenticate, thus bypassing userdb.

The expressions to detect authentication prompts are telnet_username_prompt_regex and telnet_password_prompt_regex. A further expression we use is defined in telnet_username_in_negotiation_regex. Some clients send their username in the first phases of the protocol negotiation, which some systems (the backend) use to only show the password prompt the first time authentication is tried (thus assuming the client’s username as the username they’ll use to login into the system). Cowrie tries to capture this username and use it when comparing the auth details with the userdb.

Analyzing traffic

Analyzing raw traffic can be interesting when setting up Cowrie, in particular to set up Telnet prompt detection. For this, you can set log_raw to true.