Archive for the ‘visualization’ tag

X-Forwarded-For DDoS  

Posted at 10:55 pm in Uncategorized

A discussion forum of one of Redpill Linpro‘s customers has been under attack lately, through a number of DoS and DDoS variants. Today’s attack strain was of the rather interesting kind, as one of its very distinctive identifiers was a suspicious, not to say ridiculous, amount of IP addresses in the incoming X-Forwarded-For HTTP header. The X-Forwarded-For IP addresses included both IPv4 and IPv6 addresses.

The longest X-F-F header observed contained no less than 20 IP addresses that the HTTP request had allegedly been forwarded through on its way to the forum. If we are to believe the headers, this particular request has been following this route: United States → United States → South Africa → United States → United States → Mexico → Uruguay → China → Germany → United States → United States → South Africa → United States → United States → Mexico → Uruguay → China → Germany → Costa Rica → Norway.

This short animation (click to play) illustrates a few of the the alleged routes:

Whether the HTTP requests have indeed been proxied through all these relays is difficult to confirm. By their reverse DNS lookup, quite a few of the IP addresses identify themselves as proxy servers. Checking a sample of the listed IP addresses did not reveal any open proxies or other kinds of relays, neither were they listed on random open relay blacklists. The HTTP headers included the “Via:” header as well, indicating that the request did pass through some HTTP proxies. But as we know, incoming headers can’t be trusted and should never be treated as if they could.

For the purpose of blocking the DDoS attack, it’s not really interesting whether the intermediate IP addresses are real or just faked. We simply reconfigured Varnish to check each incoming HTTP request for two things:

  • Does the X-Forwarded-For header have more than five IP addresses?
  • Is the request destined for the forum currently under siege?

All requests matching the above criteria were then efficiently rejected with the well-known, all-purpose 418 I’m a teapot HTTP response. After a minute or two of serving 418 responses, the attack stopped abruptly.

Written by bjorn on March 19th, 2018

Tagged with , , , ,

How to produce AfterGlow diagrams from Cowrie  

Posted at 9:34 am in Uncategorized

I’ve been receiving a few questions on how to produce the AfterGlow diagrams from Cowrie logs, described in an earlier blog post. Instead of repeating myself through email requests, an explanation here will be better.

First of all, you will need to decide what you want to visualize. Showing the different attackers targeting a Cowrie honeypot has limited value (and can be visualized with something much simpler than AfterGlow). Showing the next steps of the intruders, however, is a job well suited for AfterGlow.

Based on the intruders’ behaviour in Cowrie, where a few intruders use a limited number of ports to try to connect to multiple target IPs, the CSV input to AfterGlow should reflect this, so we’ll need the following format:



Below is a Cowrie log line showing that the intruder from IP attempts to contact the target IP on port 443 (formatted for readability):

2017-01-16 15:32:30+0100 [SSHService ssh-connection on
HoneyPotSSHTransport,9704,] direct-tcp connection
request to from localhost:5556


To convert this into CSV that AfterGlow will accept, I wrote a short parser script. This can be done in most languages, I used Perl:


use strict;
use warnings;

while (<>) {
 if ($_ =~ /HoneyPotSSHTransport,\d+,(.*?)\].* to (.*?):(\d+) /) {
  print "$1,$3,$2\n"


The Perl code was saved as /usr/local/bin/ on the host running Cowrie.

Since I’m creating the graphs on a different server that where Cowrie is running, I wrote a bash wrapper to tie it all together. Note the quotes that separate what’s run locally and what’s run on the Cowrie server.


MYDATE=$(date +%Y-%m-%d)
if [ "$1" = "yesterday" ]; then
 MYDATE=$(date +%Y-%m-%d -d yesterday)

ssh honeypot "grep '${MYDATE}.*direct-tcp connection request' \
 /home/cowrie/log/cowrie.log* | \
 /usr/local/bin/" | \
 /usr/local/bin/ \
 -c /usr/local/etc/afterglow/ | \
 /usr/bin/neato -T png > \


The file contains my AfterGlow preferences for this kind of diagrams, and contains the following:




Now everything can be added to Cron for continuously updated graphs. I’m running the bash script once an hour through the day, and then just after midnight with the “yesterday” argument so that yesterday’s graphs are completed. These are the contents of /etc/cron.d/cowrie-afterglow:

15  * * * * root /usr/local/bin/
10 00 * * * root /usr/local/bin/ yesterday



Now, depending on the popularity of your honeypot, you may or may not get useful graphs. Below is a graph showing 24 hours of outbound connection attempts from my honeypot, in which case it could make sense to limit the input data.

AfterGlow diagram of Cowrie outbound activity

AfterGlow diagram of Cowrie outbound activity

Written by bjorn on January 17th, 2017

Tagged with , , , , , ,

A different kind of Christmas scan  

Posted at 11:54 am in Uncategorized

Those familiar with port scanning tools (like nmap), have probably heard of the Xmas scan option. This scanning strategy sets some unusual TCP flags, as the man page describes it:

Sets the FIN, PSH, and URG flags, lighting the packet up like a Christmas tree.

Yesterday, my firewall was systematically scanned with a combination of IPv4/IPv6 and TCP/UDP  — not in Xmas scan mode — but the resulting Fireplot sure set the Christmas mood anyway!

Merry Christmas!

Merry Christmas!

Written by bjorn on December 15th, 2016

Tagged with , , , , , ,