Archive for the ‘Mikrotik’ tag

Live visualizing Mikrotik firewall traffic with Logstalgia  

Posted at 9:54 pm in Uncategorized

Previously I’ve written about visualizing firewall activity. Revitalizing a fireplot graphing tool gives a nice day-to-day overview, but after being reminded of Logstalgia in this Imgur post I wanted to give live visualization a shot.

Logstalgia is a neat tool for visualizing activity, by feeding it log files or live feeds. It’s originally designed for parsing web server logs, but it also accepts a generic format that allows for other purposes as well. By writing a short Perl script that acts like a syslog server (receiver) and converting the input to a format that Logstalgia accepts, my Mikrotik router is now live reporting any connection attempt to or through the firewall. For the visualization below I triggered a portscan to create some activity, or the video would be rather boring.

To make this work, the firewall must somehow identify traffic that’s being denied (unless you only log blocked traffic). The script will then pass only these log records to Logstalgia. I’ve been testing this with a Mikrotik device, but any firewall able to log to or through syslog will work fine.

Original syslog input

Feb 6 21:42:36 BLOCK: in:ether1 out:(none), src-mac 00:00:00:6a:f3:9c,
proto ICMP (type 8, code 0),>, len 28


Logstalgia formatted output:



I’m starting the perl script and Logstalgia like this:

./syslog2logstalgia | logstalgia -800x640 --disable-progress -x \
--no-bounce --hide-response-code --sync \
-g "TCP,URI=TCP,45" -g "UDP,URI=UDP,45" -g "ICMP,URI=ICMP,10" \


Note that visualizing firewall logs with Logstalgia has been done by a lot of other people. Howtos for other firewall products may be available via your favourite search engine.

Written by bjorn on February 6th, 2016

Tagged with , , , , ,

Geomapping network traffic  

Posted at 11:28 pm in Uncategorized

Did you ever wonder where your network traffic goes (and originates from)? With the SiLK suite and optionally some JavaScript map classes it’s quite easy to find out.

SiLK is a tool quite equal to Cisco‘s NetFlow, and SiLK does indeed accept NetFlow output from a router. Just like NetFlow tools, SiLK stores network traffic metadata (like “when” and “where”, but not “what”), so as opposed to capturing the complete network traffic SiLK can store a lot of information over a long time without eating too much disk space. In my setup I’ve configured my Mikrotik router to transmit traffic flow data to a Linux server running SiLK.

With GeoIP mapping, SiLK can identify the country of source and destination IP addresses. Combined with a “top 20” construct, it turned out easier than expected to create a world map like this:

Network traffic world map

For the map I’ve been using the very useful JavaScript interactive Highchart maps (Highmaps) from the Norwegian company Highsoft. To feed the map with data I wrote a small piece of code that converts the output from SiLK’s rwfilter/rwstats output to JSON, which makes the map dynamically update itself upon refresh.

World map percentage from SwitzerlandAs shown on the screenshot to the left, when hovering the mouse over each bubble the JavaScript map code will show the percentage value of the traffic associated with the different countries. When identifying traffic from unexpected sources you can use the command line based SiLK tools to drill down in order to find out what’s really going on, like in this case when I was wondering what was being transferred from Switzerland (it turned out to be some Flash movies the kids were watching). In addition to the command line tools there are also GUI and web based interfaces for querying SiLK data. The command used to find the source IP and port for the traffic originating from Switzerland (.ch) is shown below:

# rwfilter --start-date=2015/10/09 --end-date=2015/10/09 \
 --proto=0-255 --type=all --pass=stdout --scc='ch' | rwstats --top \
 --count=5 --fields=sip,sport --value=bytes
INPUT: 327 Records for 19 Bins and 39783096 Total Bytes
OUTPUT: Top 5 Bins by Bytes
          sIP|sPort|               Bytes|    %Bytes|   cumul_%|| 1935|            38839614| 97.628435| 97.628435||   80|              476083|  1.196697| 98.825132|| 1935|              402414|  1.011520| 99.836652||   80|               15276|  0.038398| 99.875050||  443|                9328|  0.023447| 99.898497|


There’s a few snags with my setup, but with some tweaking it gives a general idea and I think I’ve handled the corner cases. These are the knows issues – so far:

  • This setup is a NATed IPv4 network environment. In order to detect inbound traffic I have to enter my router’s outside address as the destination. This address might change now and again, breaking historical data.
  • I’m also running an IPv6 network provided by ( My allocated IPv6 ranges are consequently registered as physically located in the US, so SiLK will register any internal-only IPv6 network traffic as based in the US, increasing that percentage.

Written by admin on October 9th, 2015

Tagged with , , , , , ,

VIsualizing firewall activity  

Posted at 7:35 am in Uncategorized

Inspired by the efforts of a previous Redpill Linpro colleague, Espen Grøndahl, I’ve revived (or rather re-invented) his project “Fireplot”. By analyzing and filtering firewall logs, Fireplot graphs attempts to access blocked firewall ports, visualizing unexpected and unwanted activity towards my network.


Firewall activity visualization – click image for original size

The Y axis is logarithmic, since activity towards lower ports is often more interesting. Over 24 hours, one graph per day, TCP activity is plotted in green and UDP activity in light blue. Note the horizontal line showing SSH (TCP port 22) and telnet (TCP port 23) probes. The graph also shows a very regular probing for UDP port 7.

I’m currently parsing logs from a Mikrotik firewall/router, but since the data gathering is merely a matter of an appropriate regular expression it shouldn’t be difficult to make it graph iptables logs or other firewall-ish log data.

The Perl code is very much in beta state at the moment, so I won’t publish any code just yet. Stay tuned for updates. Meanwhile, visit Lars Strand’s inspiring article on the original project!

Written by bjorn on October 8th, 2015

Tagged with , , , , ,

Streaming pcap to a dummy interface  

Posted at 10:09 pm in Uncategorized

In an earlier article, I described how to stream captured network traffic to a remote host for IDS analysis with Snort. Mikrotik units can stream captured traffic elsewhere using the TaZmen Sniffer Protocol (TZSP). tcpdump and Wireshark natively decode this protocol, but unfortunately it doesn’t seem to be supported by any other of the large amount of useful network analysis tool.

The main usage for streaming the network capture is feeding it to the Snort IDS, and for this single purpose (and since Snort can read from STDIN) piping the traffic directly from tzsp2pcap to Snort works very well. However, now and again I need to look at the network traffic without having to detach Snort from the live stream.

This was solved by making the network traffic stream available over a dummy interface with the brilliant tool tcpreplay, to which I can attach any tool that understands pcap. These are the required incantations:

/sbin/modprobe dummy
/sbin/ip link set name eth10 dev dummy0
/sbin/ifconfig eth10
/usr/bin/screen -dm -S tzsp2pcap \
bash -c "/usr/local/sbin/tzsp2pcap -f | \
/usr/bin/tcpreplay --topspeed -i eth10 -"
/etc/init.d/snort start # configured to listen to eth10

The tzsp2pcap process must be run in a screen. Involving bash is required because of the pipe. With tcpreplay --topspeed is useful to avoid delays in the feed.

At this stage, I can point any network tool at eth10 without disrupting Snort.

Written by bjorn on October 5th, 2015

Tagged with , , , , , ,

Mobile entertainment center  

Posted at 8:25 pm in Uncategorized

Our three kids very seldom agree which TV program or movie to watch. Allowing for less discussion when screen time is granted, I’ve set up a mobile entertainment center where each kid may watch the movie of their choice – this may be used during long drives, on trains or buses, and everywhere else where there’s low or no voltage and a need to grant the kids some screen time.

The setup is simple, using a Raspberry Pi B+ running Raspbian and a Mikrotik mAP2n. The RPi is directly connected to the mAP2n with an Ethernet cable. Both are/can be powered by microUSB voltage and cable. The RPi is also equipped with a USB WiFi adapter, configured as a WiFi client, so when the unit is within range of the wireless network at home I can update it and transfer media files to it.


The two units tied together with velcro. When finalizing the project I will need to find a better case.

Packages installed on the RPi

After having slimmed down the RPi by removing any package not needed, I installed minidlna. While the minidlna project was recently renamed to ReadyMedia, in Debian/Raspbian it still goes by its former name. To administer the mAP2n from the RPi I also installed mactelnet, and to make sure both units logged with useful timestamps I added an ntp server. Finally, it seems the mAP2n does not support running a DHCP server, so I left that to the RPi (isc-dhcp-server). The DHCP server listens only on eth0, to which the mAP2n is connected.

Configuring the tablets

On each kid’s tablet, I installed a DLNA controller (I chose the Ginkgo DLNA player, but I assume any kind of DLNA/UPnP controller will do). Note that the Ginkgo DLNA player is simply streaming from the media center to the device, but not rendering the content – you will need something else for that. I’m very fond of VLC for Android and it works excellent in this use case.

Setting up the mAP2n

Configuring the mAP2n as an AP/bridge, a separate SSID was configured. The mAP2n synchronizes its clock to the RPi. The interfaces wlan1 and ether2 are bridged, and the bridge holds the unit’s IP address.


In essence:

  1. Install Raspbian on a Raspberry Pi.
  2. Install minidlna and isc-dhcp-server.
  3. Configure wlan0, supplying SSID and credentials, for being a WiFi client.
  4. Make sure you can SSH to the RPi over the wlan0 interface. When successful, configure static IP on eth0.
  5. Connect ether2 on mAP2n to eth0 on the RPi.
  6. Configure the mAP2n as an AP/bridge. Set up SSID and credentials for the AP.
  7. Set up the tablets for DNLA streaming.
Note the USB WiFi adapter, providing wireless update of the RPi unit when within range of the home network.

Note the USB WiFi adapter, providing wireless update of the RPi unit when within range of the home network.

Configuration snippets

Configuration for RPi network /etc/network/interfaces:

auto lo
iface lo inet loopback
auto wlan0
iface wlan0 inet dhcp
    wpa-ssid YourSSID
    wpa-psk SomeSecretPassword
auto eth0
iface eth0 inet static


DHCP server configuration file /etc/dhcp/dhcpd.conf:

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
subnet netmask {


DHCP server configuration file /etc/default/isc-dhcp-server:



Minidlna configuration file /etc/minidlna/minidlna.conf:

# These are all defaults


mAP2n configuration (sensitive data removed):

[admin@YourAP] > /export
/interface bridge
add name=bridge
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk \
    mode=dynamic-keys supplicant-identity=MikroTik \
add authentication-types=wpa2-psk mode=dynamic-keys \
    name=YourAP supplicant-identity=YourAP \
    wpa-pre-shared-key=SecretPassword \
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n \
    country=norway disabled=no frequency=auto \
    l2mtu=1600 mode=ap-bridge security-profile=YourAP \
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=wlan1
/ip address
add address= interface=bridge network=
/system clock
set time-zone-name=Europe/Oslo
/system identity
set name=YourAP
/system leds
set 3 interface=wlan1
/system ntp client
set enabled=yes primary-ntp=



Throughput with three concurrent players showing .mkv movies (720×576 px, 25fps, H264 MPEG-4 AVC, MPEG AAC) sometimes peaks at around 22 Mb/s, and the RPi doesn’t break a sweat when serving at that speed. Obviously different formats would affect the RPi load and WiFi throughput.

Attaching a 4 x AA portable battery pack as shown below, the two units (mAP2n USB powered from the RPi) were running for more than three and a half hour, and during this period they streamed movies to one tablet for two and a half hour.

Exibel battery pack bought from Clas Ohlson.

Exibel battery pack bought from Clas Ohlson.

And for those who might ask: Yes, a Raspberry Pi could simply be equipped with two WiFi adapters, one for client access and for for AP. There are lots of different approaches to this. In my case, I had a spare mAP2n just lying there…

Written by bjorn on May 3rd, 2015

Tagged with , , , ,

CRS serial console with kermit  

Posted at 10:57 am in Uncategorized

For those still inclined to use kermit for serial console access, these are the commands for connecting to a MikroTik CRS125 with default settings:

# kermit
C-Kermit 8.0.211, 10 Apr 2004, for Linux
Copyright (C) 1985, 2004,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
(/root/) C-Kermit>set line /dev/ttyUSB0
(/root/) C-Kermit>set speed 115200
/dev/ttyUSB0, 115200 bps
(/root/) C-Kermit>set carrier-watch off
(/root/) C-Kermit>connect

Written by bjorn on April 10th, 2015

Tagged with , , ,

IDS with MikroTik and Snort  

Posted at 7:07 pm in Uncategorized

UPDATE: For more flexible streaming, and for not having to hack your Snort init scripts, you might want to consider this article as well. Now back to the scheduled program.

Port mirroring on a strategically positioned switch can be the best setup for an IDS sensor. If that’s not an option, RouterOS-based MikroTik devices support capturing network traffic, streaming it to a remote target using the TZSP protocol. This functionality is available in RouterOS and extended support is provided by the calea package.

Configuring a remote IDS device with MikroTik has been described elsewhere, for instance here and here, but since my plan involved an ARM based Raspberry Pi, MikroTik’s trafr mentioned in those articles could not be used since it’s for x86 only and the source code does not seem to be available. Luckily I found tzsp2pcap which converts the TZSP stream from the MikroTik device into a pcap stream readable by Snort.

My setup

The setup used for this project consists of an RB2011UAS-RM (model is now EOL, replaced by RB2011UiAS-RM) acting as NAT firewall/router, and a Raspberry Pi B+ unit on which I installed Raspbian. The firewall connects to my ISP over a dedicated VLAN, so the outside interface with an official IP address is a bridge VLAN interface named bridge-vlan02-untagged. This will also be the capturing interface.

Note that the traffic capture takes place after NAT, so with this setup Snort will see traffic initiated from the inside as having the official IP address. In other words, you will not see the origin IP address of any suspicious outbound activity.

Compiling tzsp2pcap

Building tzsp2pcap requires the packages git, build-essential and libpcap0.8-dev. Now git clone or download the tzsp2pcap source code. To make tzsp2pcap compile on Raspbian I also had to modify the Makefile somewhat, from

cc -std=c99 -o $@ $(CFLAGS) $(LDFLAGS) -lpcap $<


cc -std=gnu99 -o $@ $(CFLAGS) $(LDFLAGS) -lpcap $<


After this modification, compile the code:

$ make
cc -std=gnu99 -o tzsp2pcap -Wall -Wextra -pedantic -O2 -lpcap tzsp2pcap.c
tzsp2pcap.c: In function ‘main’:
tzsp2pcap.c:355:12: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘int’ [-Wformat]
tzsp2pcap.c:355:12: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘int’ [-Wformat]

You should end up with a binary file named tzsp2pcap. Move it to /usr/local/sbin/ or similar.

IPv6 requirement

Note that tzsp2pcap seems to have been programmed to require IPv6 support even if IPv6 is not necessarily in use. If you get this message:

# tzsp2pcap
socket(): Address family not supported by protocol
Could not setup tzsp listener

…you’ll need to modprobe ipv6 or otherwise enable IPv6.

Verifying the capture

Now it’s time to test the reception of the traffic capture stream. First, start the tzsp2pcap listener, piping the result into tcpdump for making sense of it:

# tzsp2pcap -f | tcpdump -n -q -c 10 -r -

Then start the traffic capture on the MikroTik device. The IP address is where you run tzsp2pcap.

/tool sniffer
set file-limit=0KiB filter-interface=bridge-vlan02-untagged memory-limit=0KiB streaming-enabled=yes streaming-server=

In your tcpdump session, you should now see something like this:

IP [ip].49386 > tcp 51
IP > [ip].49386: tcp 85
IP [ip].49386 > tcp 0
IP [ip].4100 > UDP, length 419
IP > [ip].4100: UDP, length 547
IP > igmp

When started as shown above, tcpdump will stop by itself after having received 10 packets. If you see something similar to this, that means that both your MikroTik device and your tzsp2pcap listener are working correctly and you should give yourself a pat on the back!

Installing and testing Snort

Installing Snort is the easiest part: aptitude install snort. After answering the questions during the installation, allow Snort to start. Find out how the process is run:

# ps -ef | grep snort

You should see something like this:

snort 5628 1 1 12:22 ? 00:00:00 /usr/sbin/snort -m 027 -D -d -l /var/log/snort -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[] -i eth0

The above is required since we will not be running Snort in a normal fashion. Now stop Snort, and make sure it doesn’t start by itself at boot:

# update-rc.d -f snort remove

Based on the above findings and your own preferences, including what’s defined in snort.conf and any related config files, you should now be ready to forward the stream from the listener and into Snort. Note the ‘-r -‘ at the end, that’s what makes Snort analyze traffic received on STDIN.

# tzsp2pcap -f | snort -m 027 -d -u snort -g snort \
-c /etc/snort/snort.conf -r -

If everything runs as it should, you should start seeing some alerts trickling in. The default log file seems to be /var/log/snort/alert which is nice for debugging and testing. For those somewhat serious about running an IDS, storing alerts to a database will be the better approach.

Some sample output from /var/log/snort/alert:

[**] [1:553:7] POLICY FTP anonymous login attempt [**]
[Classification: Misc activity] [Priority: 3] 
03/14-15:11:12.287084 [ip]:43920 -> [ip]:21
TCP TTL:63 TOS:0x0 ID:0 IpLen:40 DgmLen:88
***AP*** Seq: 0xD87294F5  Ack: 0x7105DEA6  Win: 0xDA  TcpLen: 32
TCP Options (3) => NOP NOP TS: 313122335 3732452130

[**] [1:1321:8] BAD-TRAFFIC 0 ttl [**]
[Classification: Misc activity] [Priority: 3] 
03/14-15:54:18.504939 [ip] -> [ip]
IPV6-FRAG TTL:119 TOS:0x0 ID:625848831 IpLen:40 DgmLen:1096
Frag Offset: 0x016A   Frag Size: 0x0420
[Xref =>]

[**] [1:1417:9] SNMP request udp [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/14-16:08:20.293852 -> [ip]:161
UDP TTL:245 TOS:0x0 ID:54321 IpLen:20 DgmLen:61
Len: 33
[Xref =>]
[Xref =>]
[Xref =>]
[Xref =>]
[Xref =>]

[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/14-16:52:10.022351 [ip] -> [ip]
ICMP TTL:37 TOS:0x0 ID:64264 IpLen:20 DgmLen:28
Type:8  Code:0  ID:46546   Seq:0  ECHO
[Xref =>]

[**] [1:524:8] BAD-TRAFFIC tcp port 0 traffic [**]
[Classification: Misc activity] [Priority: 3] 
03/14-17:15:57.591933 -> [ip]:0
TCP TTL:50 TOS:0x0 ID:0 IpLen:20 DgmLen:40 DF
******S* Seq: 0x6F024630  Ack: 0x0  Win: 0x2000  TcpLen: 20


Maintaining and tuning Snort

Configuring, maintaining and tuning Snort further is a (large) job in itself, and should be customized according to your own requirements. See the excellent Snort documentation for more on this topic.

System loads

With a network usage at around 7-8 Mb/s, the RB2011 uses about 40-45% CPU with traffic capture enabled, as opposed to 10-15% without traffic capture.

The Raspberry Pi B+ running Snort uses almost no CPU in regular use, but about 90-100% CPU with a load average between 1 and 2 analyzing the network traffic during the download. For this purpose a Raspberry Pi 2 would probably be better suited.

UPDATE: A new test with other hardware shows the following loads:

With 7-8 Mb/s throughput, an RB450G performs at about the same load as the RB2011. Replacing the Snort sensor with a Raspberry Pi 2 shows quite an improvement: Where the regular RPi B+ spent all its CPU resources on traffic analysis (load values between 1 and 3), the RPi2 has a load of 10-15% (load values between 0.10 and 0.15).

Written by bjorn on March 14th, 2015

Tagged with , , , , , ,

MikroTik configuration revision control with rancid  

Posted at 10:28 pm in Uncategorized

The config revision control tool rancid (Really Awesome New Cisco confIg Differ, but not at all limited to Cisco devices) has proven extremely useful. Rancid notifies you if there’s been some changes to a device, and since it’s Subversion backed it’s easy to extract full configurations in case you need it. Rancid has been supporting MikroTik devices for some time now.

Rancid exists in a lot of Linux repositories, or it could be installed from source – how to do that is documented elsewhere. After installing rancid, here’s what was needed for rancid to keep an eye on my MikroTik devices.

First I created a readonly user across all MikroTik units, intuitively named rancid. To mass create this account, I used dsh – described in an earlier article. Make sure your Linux system’s rancid user is able to log in to your devices using SSH keys and not passwords.

Next step is configuring rancid’s authentication file, ~/.cloginrc. Even though a password is required in the file, setting the identity will make rancid use key based SSH logins. Here’s my .cloginrc for reference:

add user * rancid
add password * SomeGarbledPasswordThatWon'tBeUsedAnyway
add method * ssh
add identity id_dsa

To verify that rancid may log in to the MikroTik devices, try a manual login as the rancid user:

~$ ~rancid/bin/mtlogin

You should be logged in to the device, and in the device’s log you should see

publickey accepted for user: rancid+ct

Now that the rancid user is able to log in to your units, it’s time to move on with configuring rancid. Most rancid.conf settings work out of the box, I only had to change these to convince rancid to use Debian’s standard svn repo directory. Make sure the “rancid” user or group has the necessary permissions to create a new repo. I also created a group called “devices”.

CVSROOT=/var/lib/svn/rancid; export CVSROOT
RCSSYS=svn; export RCSSYS

After running rancid for the first time, a new repo has been created. Under ~rancid/var/ a “devices” directory has been created. In here you will find a file named “router.db”. Here you need to add your devices, like this:

When all this is in place, it’s time to allow rancid to run from cron.

Written by bjorn on February 2nd, 2014

Tagged with , , ,

Securely managing multiple Mikrotik units with dsh  

Posted at 9:01 pm in Uncategorized

dsh is a nice Unix/Linux tool for managing multiple systems efficiently, and I’m using it both at home and at work. In some distributions dsh has been replaced by pdsh, but no worries, pdsh is dsh compatible. Since all MikroTik devices running RouterOS might be managed over SSH, why not use dsh to manage these as well? Here’s a quick howto.

  1. Install ssh and dsh.
  2. If you don’t have one already, create an SSH DSA key pair:
    ssh-keygen -t dsa
    Do this with the Unix/Linux user account you’re managing the devices from. I strongly recommend securing the key pair with a password.
  3. Distribute the public part of the key pair ( to each MikroTik unit, using an existing account (e.g. admin). I used ncftpput for efficient distribution. The public key should now be visible in the “Files” folder on each MikroTik device.
  4. Now attach the public SSH key to a user account. I’ll use the admin account in this example. In cli, this is done with
    /user ssh-keys import user=admin
  5. Create a dsh group file, let’s call the group mikrotik (either /etc/dsh/group/mikrotik or ~/.dsh/group/mikrotik). Add the IP address or hostname of each MikroTik devices to this file, one unit per line. Specify the user name if required.

Sample group file:


You should confirm that SSH works fine with each device before expecting dsh to work. Example command:

~$ ssh admin@

When this works fine, you’re now ready to mass manage your MikroTik devices. A few useful commands are shown below.

Check for and download the newest RouterOS version to all devices:

~$ dsh -g mikrotik '/system package update check-for-updates'
~$ dsh -g mikrotik '/system package update download'
~$ dsh -g mikrotik '/system package update print'

Change admin’s password (note that this will leave the new password in your user’s shell history):

~$ dsh -g mikrotik '/user set password=ThisIsTheNewPassword admin'

Check if any device needs a firmware upgrade:

~$ dsh -g mikrotik '/system routerboard print'

Add a new user:

~$ dsh -g mikrotik '/user add name=NewUser disabled=no group=full'

Written by bjorn on February 2nd, 2014

Tagged with , ,