This is part of a series of posts where I describe my workflow and OS setup.
I use email a lot both in work and my daily life, so I want/need to have a
lot of control on my mail. I use IMAP for getting my email for all my accounts
and SMTP to send mails.
My mail client of choice is Mutt, which is a fully
featured text based (terminal) MUA. Mutt has a nice interface (supports colors),
it can read the maildir mailbox format (more on that later), uses an
external editor for writing email (I use Vim), supports gpg/pgp, etc. In short,
it’s not lacking any features compared to a GUI client.
You can use Mutt to connect to an IMAP server and have Mutt fetch your mail,
but I prefer to use OfflineIMAP which is written in
Python. OfflineIMAP syncs my mails from multiple remote servers to the local
filesystem in maildir format. It also supports syncing between IMAP servers but
I don’t need that kind of functionality. The configuration file of OfflineIMAP
is simple, clean, powerful and intuitive if you’ve used Python before.
Depending on the machine I’m working on, I only sync specific IMAP folders.
Here is the part of my .offlineimaprc file responsible for selecting the
folders to be sync’ed.
There is one more piece of software involved on my email setup and that is
imapfilter, a utility to filter/sort
emails on the remote IMAP server. It’s written in a combination of C and Lua
and its configuration file is using Lua too. You can filter mails based on
a number of different fields like CC, To, From, Subject, etc. There is
not much more to say about it actually, it does one job and it does it well and
Here is a diagram of the above setup (created with asciio):
Mutt sends mail using SMTP
.-,( ),-. |
.-( )-. .-------------. .--------. .------.
( Mail Servers )<----->. OfflineIMAP .---->. ~/mail .<-----. Mutt .
'-( ).-' '-------------' '--------' '------'
'-.( ).-' Fetch mails on ~/mail Read mails
^ and sync their status from ~/mail
| with the remote server
. imapfilter .
imapfilter constantly filtering mails
I’ve been running some instances of Kippo for quite some while now with
great results. I recently wrote an Ansible playbook to automate the
process of deploying Kippo hosts and also make it scalable. You can find the
playbook on my GitHub page, specifically here.
In a nutshell, the playbook will deploy a central database for all the Kippo
hosts to log incoming attacks and then deploy a number of Kippo hosts. You can
specify which repo to clone Kippo from or do ad-hoc file modifications to files
in the repo. For example, I’ve modified some commands like wget.
A couple of weeks ago, GitHub announced its Student Pack, giving 100$ of
credit on DigitalOcean, which I promptly grabbed. Two nights ago, I
decided to use the credit on building a small cluster of SSH honeypots,
consisting of twelve Kippo hosts. Of course, the whole project was
orchestrated using Ansible.
I created thirteen VMs (droplets in DO terms) using the
Digital Ocean ansible module, twelve for the Kippo hosts and one for the
logging database. I, also, ran a couple of ad-hoc Ansible commands to further
configure some settings inside the VMs, and finally used ssh-multi
(which I’ve talked about in my tmux config post) to make sure everything
was configured properly.
It’s been a little over 48 hours since I set this up, so let’s see some
early statistics. I used an old script of mine to extract these.
Total login attempts: 212589
Total unique passwords tried: 17080
That means a little under 4.5k attacks per hour, or 74 attacks per minute, or
1.2 attacks per second with only twelve sensors online. The sensors were spread
across the DO network, so I would get different IP ranges and also geographical
Unfortunately, I didn’t get any new samples, just random variants of Elknot,
much like the one MalwareMustDie analyzed in the past. I’ll probably
increase the number of sensors soon enough, which brings me to my next point.
I love the simplicity of Ansible and the ease of adding new hosts to a
deployment, once you’ve written a playbook. All I have to do now to add more
hosts in my Kippo “cluster” is:
ansible-playbook -i new_hosts -t kippo site.yml
and only the Kippo tasks will run, installing and setting up Kippo, ready to
attract and log more attacks.
It’s been a little over a month since I started using tmux. Below, I’ll try
to explain most of my .tmux.conf, a bit of my current workflow using
awesome + tmux and various cool stuff you can
do with tmux. My latest .tmux.conf can be found on my
dotfiles repo on GitHub.
Tmux config file
set -g prefix C-a
As most people, I’m using C-a as my bind key.
bind-key a send-prefix
On nested tmux sessions, I use C-a a to send commands to the second level
tmux instance. Another popular choice is C-f, but it feels weird to me.
bind-key C-a last-window
This is an old habit from screen, using C-a C-a to go to last active window.
bind r source-file ~/.tmux.conf
Use C-a r to reload tmux configuration on the running session.
bind-key -r j select-pane -D
bind-key -r k select-pane -U
bind-key -r H select-pane -L
bind-key -r L select-pane -R
I’m using C-a j/k to move down/up in panes and C-a H/L to move left/right.
The -r flag means the key can be repeated multiple times without having to
press C-a again, e.g., C-a j j will move the cursor two panes down.
bind-key -r l next-window
bind-key -r h previous-window
Same as above C-a l/h for window navigation right/left.
bind-key m command-prompt -p "[ man page ]" "split-window 'exec man %%'"
This is one of my favorites that I picked up on #tmux on freenode. C-a m will
open a prompt and ask for a man page to open a new bottom pane.
This is it in action.
bind-key "'" split-window -h
I like to use C-a ' and C-a " for my horizontal/vertical splits.
bind-key v copy-mode
Tmux has an amazing copy mode to scroll back up or copy text. The default way
to enter said copy mode is C-a [, which I’ve remapped to C-a v.
bind-key -t vi-copy 'v' begin-selection
To start selecting text the default key is Space, which again I’ve remapped
to v to be in sync with vi.
bind -t vi-copy y copy-pipe 'xclip -in > /dev/null'
When text is yanked in copy mode, it only exists in the context of the current
session. The above remaps y to yank the selected text in copy mode and
also save it on my clipboard using xclip.
bind-key p paste-buffer
Remap C-a p to paste buffer instead of the default C-a ].
setw -g mode-keys vi
Enable vi mode-keys, highly useful when selecting text in copy mode.
Here’s a quick demo showcasing the above, using vi’s gg and $ to move the
cursor around, C-a v to enter copy mode and y/C-a p to yank and paste
set -g set-titles on
set -g set-titles-string '#(whoami)@#h -- #S'
Renames window titles on awesome’s status bar.
set -g status-utf8 on
set -g status-bg colour241
set -g status-fg white
set -g status-interval 60
set -g status-left-length 90
set -g status-right-length 60
set -g status-left "#[fg=Green]#(whoami)#[fg=white]::#[fg=yellow]#h"
set -g status-justify left
set -g status-right 'Session: #[fg=Cyan]#S - #[fg=white]Uptime:#[fg=Cyan]\
#(uptime | cut -d" " -f 4-5 | tr -d ,) - #[fg=white]Bat: [\
#[fg=Cyan]#(acpi | cut -d" " -f 4-5)#[fg=white]]'
This is my tmux status bar config. It’s pretty self-explanatory, the most
interesting part is the last line where I use acpi to get the charge level of
the battery and remaining charging time.
set -g default-terminal "screen-256color"
Set the default terminal to use.
set -g base-index 1
set -g pane-base-index 1
Start counting windows and panes from one and not zero.
set -g history-limit 10000
The default setting is to save 2000 lines of history per pane, I’ve changed
this to 10000.
Using tmux as a pdsh/clusterssh alternative
I normally use ansible to run ad-hoc commands in multiple
hosts, but there are times when I want a quick and dirty solution or want to
(cleanly) see the output of a command to a number of hosts. A lot of people use
clusterssh to achieve the above, but I don’t really like its use of xterm and
the way it arranges windows, plus it semi-conflicts with awesome.
What I do instead, is run a script that opens a new tmux pane for every host,
ssh to each host and set synchronize-panes on. With synchronize-panes,
everything that is typed on one pane, is automatically sent to all panes in
the same window. You can find the script here.
Here’s a gif of it in action. Or not, my netbook couldn’t handle
the gif creation, here’s a pic instead with 7 panes active and ssh’ed.
End of part 1 (??)
That’s all for now, hopefully there’s gonna be a part two where I explain how I
use tmux in conjunction with awesome.
PS. All the gifs in this page were created with ttygif.
I’ve been using tmux for a while, and even
though I didn’t like it at first, now I’m in love with it. I’m mostly
using it as a GNU Screen alternative, but I don’t use some of its fancy features
like tabs, mainly because my window manager
takes care of multiple terminal windows for me.
After a while, I got bored of starting a tmux session and configuring it
every time, so I decided to give tmuxinator
a try. The tmuxinator docs clearly stated that tmux >= 1.8 was needed, but I
was using tmux version 1.6. I downloaded the latest stable tmux version from
upstream, compiled it, installed it and tried to run it. I was greeted with
protocol version mismatch (client 8, server 6)
What happened is that I had some tmux sessions still running using the 1.6
version. The obvious, and only, solution that came to my mind was to kill all
running tmux sessions. Problem was, one of those sessions had my Irssi stuff open and, since I have yet to properly setup an
irssi config file, I would have to reconnect to all servers, re-authenticate,
rejoin all open channels, etc. Ain’t nobody got time for that.
reptyr is a utility for taking an existing running program and attaching it
to a new terminal. Started a long-running process over ssh, but have to
leave and don't want to interrupt it? Just start a screen, use reptyr to
grab it, and then kill the ssh session and head on home.
So, all I had to do was open a screen, detach the irssi processes from tmux,
reattach them to screen using reptyr, kill all running tmux processes, restart
the tmux server and, finally, reattach the irssi processes to tmux. Much to my
surprise, it worked out flawlessly.
Now all that’s left, is to populate my ~/.tmuxinator config files and push them
to my dotfiles.
A couple of months ago I wanted to experiment with the serial console of an old
router I had laying around. Not wanting to buy a UART to RS-232 adaptor, I
decided to make one myself. After all, I had some spare MAX3232
left over from a previous project (for which I still haven’t blogged).
I just followed the schematic provided by the datasheet and 15 minutes of
soldering later, this was the end result.
Gotta love these cute little perfboards!
I’ve tested it both with a RapPI and the aforementioned router and it works
great. I was able to get a serial console on the router using the serial
headers on the pcb. The manufacturer had even marked the TX/RX pin holes, so
there was no need for me to go serial hunting.
Now, I’m waiting for some FTDI FT232-RL chips to arrive to make a USB adaptor
instead of a RS-232 one. I know you can buy one on ebay for 3 bucks, but where
is the fun in that?
I decided to port my blog to Octopress and move away
from Wordpress after all these years. The reason for this is twofold:
I’ve really gotten used to working with vim, git, github and the
Static site generators are all the rage currently, so who am I to miss out?
Why Octopress and not something based on Python like Pelican or Nikola?
I simply decided to do something that will get me out of my comfort zone and
also teach me something new. I already know how to use venv, let’s see what
RVM has to offer.
A lot of people have combined a RasPi and a SDR dongle to get a low power
consumption ADS-B tracker. Tomasz Miklas
has created an image for the Raspberry Pi, that has everything that is needed
to run your own aircraft tracking “service” already set up. I’ve finally had a
chance to experiment with it and this will be my short review.
First of all, I have to say I’m really sorry to Tomasz, because he send me the
image at the 10th of October to test it out before releasing it publicly and
I’m posting this two months later. Sorry mate.
Tomasz, has a well written post explaining how the image works
, so I’ll skip the details. All tests were performed using a dongle with a
R820T chip and the stock omnidirectional antenna. Since I moved recently, I
didn’t have the time to construct a proper antenna, yet even with such an
antenna the result were pretty good.
So, you download the image, dd it to a SD card, plug your SDR dongle, power
it on, point your browser to the IP the RasPi obtained through DHCP and … and
everything simply works out of the box. At least it did for me.
I was really surprised by how lightweight the whole setup was. After one and a
half hours of uptime, two clients connected to the server and, receiving
messages from two planes, the RasPi reported that it only used 30 megs of RAM
and the CPU was pinned at 35% the whole time, with 4-5% of it being htop
itself. The process using the CPU was of course dump1090, which does all the
heavy lifting. Unfortunately, due to the time I tested the image (4 AM) and my
location, there weren’t many planes (two simultaneously at max), so I don’t
know how dump1090 behaves under a lot of load/traffic.
As mentioned above, I was using the stock antenna that came with the SDR
dongle, but I was still able to get a signal from planes that were 72km away
on average! On some of my previous tests under Windows and ADSB#, I only got
28km of range. A lot of things have changed since then though, mainly my new
house and my antenna placement, or perhaps the old one was a
Faraday cage? Either way, for the
time being, I’ll leave the RasPi running and further report on its performance
after a bit of testing.
If you own a RasPi and a SDR dongle, give the image a try. It may not be
something you haven’t seen or done already, but it certainly is the easiest
way to monitor ADS-B traffic, at least to my knowing. I know, I’ll be keeping
a copy of the image in a SD card because it’s so handy.
For the past two months I’ve been reading about SDR
and everything related to radio telecommunications. For those that don’t know
what SDR is (and are too bored to click the previous link), Software Defined
Radio is a system that implements hardware subsystems of a typical radio in
software. People have been designing their own SDRs with FPGAs
for quite some time now, but in the last year there has been a huge
“revolution”. It turns out that a lot of cheap USB digital TV tuners based on
the Realtek RTL2832U chip can be tuned at a wide range of frequencies.
For a list of supported devices you can check this page.
I’ve bought two devices to experiment with, one is an EzTV 645 using the FC0013 chip,
while the other one is using the Rafael Micro R820T chip (bought it from ebay
for about 8 euro). I mainly bought them to experiment with ADS-B
and NOAA weather satellites. Due to university assignments I didn’t have the
time for the latter, but I’ve spent some mornings watching airplanes taking on
and off from a nearby airport. Other interesting things to listen to are:
pager traffic, car keyfobs
and anything else that is above in your chip range. As mentioned earlier, due
to the lack of time, for the time being I’ve only experimented with ADS-B
I’ve done all my testing in Windows 7 using SDR# and
in conjunction with Virtual Radar Server.
So far, using the stock antenna with both dongles, the one with the R820T is
performing way better than the FC0013 one. There is less noise and it’s better
at picking signals from afar. Moreover, it has a better tuning range, although
it differs from dongle to dongle and it depends more or less on your luck.
I live fairly close to an airport so I get a good signal of any plane taking on
or off. The maximum range I’ve achieved with the R820T dongle and stock antenna
(omnidirectional) is 28km. I’ve checked the results I get against
flightradar24.com and they are spot on. One
feature of ADSB# I like is the ability to share your findings with servers that
accept ADS-B traffic, like contributing to flightradar24.com.
I won’t go in more details at the moment, since I’m tight on time, but for
those of you that are interested in getting a SDR capable dongle, do some
research first. Not all dongles have what is called an esd protection diode. As
its name implies, it’s a diode (a passive component allowing current to flow in
one direction only, like a check valve) that protects against electrostatic
discharge. A lot of people have “fried” their dongles because they didn’t have
aid diodes. By leaving the antenna outside, the wind can create static charge
on the antenna and fry the chip inside the dongle. Both of my dongles came with
those diodes, but if you plan on buying one, read some comments first or if
buying from ebay ask the seller for a picture of the dongle. The diodes are the
ittle black things I’ve circled in red near the antenna connector.
Three months ago I installed Kippo in a low end VPS of mine. About a month
after that, I got bored of manually checking kippo everyday so I made a small
script to automate the process. Fast forward another two months and here we’re.
In three months time, I had 122.487 bruteforce attempts from 339 different
IPs. Of said attempts, 130 were successful on finding the correct password(s).
I set up Kippo to accept two different easy-to-guess passwords for the root
account. People interacted with the honeypot (as in logged in and tried to
download files, etc) only 16 times out of those 130. The rest were just bots
logging in and logging out.
The first command every attacker runs after logging in is w, followed by
cat /proc/cpuinfo. Ten out of the sixteen attackers logged out after seeing
the results of /proc/cpuinfo. I guess people know about Kippo and recognize
it by /proc/cpuinfo. After noticing that, I changed mine – something I suggest
everyone to do as Kippo by default is easily identified. There were a few hits
where people thought it’s an actual server and not a honeypot and tried
downloading some of their tools. I disabled wget but made it look like it’s
there, so it was funny seeing them figuring out why they can’t download their
Unfortunately, I haven’t come across any new web shell; only some IRC bots,
so nothing interesting to post about there.
Of the 122.487 previously mentioned attempts, I’ve gathered 30.048 unique
passwords (around 29.500 if you don’t count extra whitespace) and 8.525
usernames. I run both of the lists containing passwords and usernames against
pipal. By far (49.12%) the most used username is root followed by test (0.8%).
For more details on both of the reports check my Kippo findings page.