In my last post, I mentioned the Pimoroni Tiny 2040. While it probably won’t die by just dangling off it the end of a USB cable, or tossing the naked device it in your bag/pocket, I prefer to have a small case around it to have some protection and make handling easier.
This also has the benefit of looking more professional when using it at work, compared to the “uh, are you sure this is a good idea” look I get when plugging PCBs directly into USB ports.
The design itself is pretty basic:
as small as possible
a top and bottom half that snap together securely when assembled
a slight recession on the bottom to accommodate the parts on the underside of the PCB
holes for the two buttons
a thin layer above the LED so it is protected, but still can be seen/used
One reason I like using this case, is that I can print a few in different colors and switch them out based on the payload (e.g. red for dangerous, green/blue/yellow for safe, testing, informational).
Last year I bought a Pimoroni Tiny 2040 that I really enjoy playing around with. It’s a fun little device that runs Python. It’s about the size of a thumbnail, has an LED, and you can use the boot select button for user input.
I mainly use it as a cheap USB rubber ducky with a non-malicious script at work (if plugged into a PC, it registers as a keyboard and starts typing: open notepad, write some text about the importance of locking your PC, and then locks the PC). To do this, install CircuitPython, and follow the instructions of this repository: pico-ducky
Once installed, you can easily write your own rubber ducky scripts and drop them on the device or use existing scripts found here: hak5/usbrubberducky-payloads
I have a small git repository that I use as a template to start off with, it includes all the required libraries and a slimmed down and modified rubber ducky parser: ryanschulze/rubber-pico-duck
The LED on the pico 2040 will glow dim blue when it has completed initialization and is ready, if you press the boot select button, the LED will turn red and it will execute the payload, when complete it will flash green briefly before returning to the ready state (dim blue).
I’ve recently been moving a few of my services from bare metal installations over to docker containers. Normally I use ansible to deploy everything in the right place (and you should be doing that too), but I have a “playground” to try out stuff before promoting it to “properly deployed on a different VM with ansible”.
The following script came in handy to simplify the process of creating systemd service files for the docker services.
It assumes that you are in a directory with a docker-compose.yml and the directory name will be the service name, e.g. you are in /opt/watchtower/ and there is a docker-compose.yml here -> the service name will be watchtower .
echo"Switch into the directory with your docker-compose.yml file"
Paperless is a document management system that helps you manage digital scans of your documents. I’ve been using it for a while, but as with many projects the developer(s) lost motivation/time to keep the project up-to-date, a fork was made (paperless-ng) which after time also died off. Now a few developers got together, worked through the backlog of issues and forked the next generation as “paperless-ngx”.
Short version: I have my scanner set up to be able to store scans on a network share as PDFs, and paperless monitors the same share for new documents. If it finds a new file, it performs OCR on it (saves the PDF as well as the text) and runs user defined rules against it (e.g. detecting the date of the document, or correspondents, or what kind of document it is, …). It actually makes it very easy to manage physical documents. I just pop them in the scanner, select the destination share, and that’s it, everything else happens automatically. So if I need to search for documents needed to do my taxes. I can do it digitally and not have to go through folders with physical paper.
It can also ingest images or office documents, just toss them in the directory the application monitors for ingesting documents (or use the “Upload” button in the application).
I’m not a big fan of the default dark theme, but a normal light theme is still available.
All in all, it’s pretty nifty, so have a look if this is something that you might find useful.
I spent some time the last few days tweaking my mail server settings since there has been an annoying rise in spam lately. Nothing special, mostly spring-cleaning of the blocklists and Spam Assassin settings. But as I was going over my config, I realized I didn’t have any way to measure “success”. I don’t really know which Blocklists work well for me and which don’t.
I use Graylog to collect logs from my systems and applications. But as far as my Exim logs are concerned my setup was pretty barebones (i.e. not parsing any fields, just dumping them as they were into Graylog). So I spent some time setting up proper extractors for my Exim logs to store everything useful in fields. A lot of the Exim logs use a straightforward key=value structure, making them easy to parse.
(spoiler: I bundled up everything here as a Graylog Content pack in case anyone wants to use it. Link at the bottom of the post)
Once the logs were properly parsed, I moved on to Dashboards to visualize the data. I started out with a visualization of the score Spam Assassin assigns to incoming emails (negative is good, positiv is bad, it’s been years since I’ve seen anything above a score of 5.0 that wasn’t spam). This gives me an indication of the quality of the mail making it through filters to my mailbox. Then a little overview of incoming and outgoing mail, and how much is discarded by SPF and DNSBL.
This dashboard s the most interesting one when it comes to deciding which DNSBL lists are useful and which aren’t. It shows which lists are finding spambot globally as well as over time. All my dashboards also have a widget with the relevant logs from the dashboard underneath to have easy access to the raw logs.
Since I had the data anyway, I also create a dashboard to show transport encryption information. About 60% of mail servers seem to support transport encryption, which is a lot lower than I would have expected (since it is easy to configure). I didn’t dig deeper into this, but I wouldn’t be surprised if the 40% sending email using plain unencrypted methods are mostly spammers that have very simple bots running to send their email.
This dashboard is technically also not related to spam, it’s bots trying to brute force user accounts on my mail server to abuse them to send more spam. Fairly aggressive fail2ban settings take care of that though. It’s interesting to see, that the botnets aren’t used solely for sending spam, they are also used to try and compromise mail server accounts to increase the volume of mails they can send.