Ensuring zero allocations in Go tests

A common goal in Go is wanting to ensure that calling a function results in a small number of allocations. Often you want to go even further and ensure that calling a function results in zero allocations. There are guides on how to write benchmarks that can tell you how many allocations a function is making. However, once you have such a benchmark, it’s up to you to notice if the allocation amount ever changes.

Incremental zpool scrub

Similar to how continuous incremental scanning is a good thing for security tools, zfs supports a way to do incremental pool scrubbing.

Acquiring a large SMTP pcap for testing

Recently I needed a large PCAP of SMTP traffic for testing zeek scripts. Obtaining a capture from a production network would be a straightforward process. However, I needed a file that could be included in test suites, or copied to other hosts without having to worry about leaking sensitive data. I could have taken an archived MBOX file and replayed it into a server. This would have worked, but wouldn’t have included any variability due to client differences.

Continuous incremental scanning

Many security tools could be better. The problem isn’t that they are buggy or don’t work properly, but that they are designed to work in a way that is not as useful to defenders as they could be. The primary example I’m going to use is ssh server weak credential scanning. There are many existing tools that do this, such as ncrack or hydra, but I wrote my own called ssh-auditor .

bpf_map_get_next_key pitfalls

Background eBPF maps are a core component of most XDP programs. I am working on a library called libflowbypass that uses some code and ideas from Suricata to implement flow cutoff inside the kernel using eBPF and XDP in a reusable way for any network monitoring tool. The core of this is 2 maps (one for v4 and one for v6) whose keys are the 5 tuple (proto, src, sport, dst, dstport) of each flow to be dropped in the kernel.

Home Network - Part 1 - Bulk Cable

Wiring an existing home for Ethernet is a fun project. There is a lot of information out there on how to accomplish this, unfortunately much of it is vague or outdated. It’s not uncommon to find guides that talk about using Cat5 cable or show pictures of ancient 10mbit networking devices. Other guides are more modern, but they gloss over specific details and fail to mention various pitfalls. This will be part one in a seven part series:

Implementing pluggable backends in go

When writing a component like a storage backend you often want a way to switch between different implementations like memory, sqlite, or redis. Another common example is authentication backends for LDAP or Kerberos. With interfaces in go you can have multiple implementations of a common API, but it takes a little more work to make them pluggable.1 The goal is that we want to be able to have a configuration file with a section like

Syslog is terrible

I hate syslog.

The protocol is terrible.
The message format is terrible.
The API is terrible.

http_flood in docker revisited

My last post (over 2 years ago) was my initial tests of running my http_flood project under docker. At the time, there was a huge performance impact running through docker. Performance dropped by almost 90%. Two years later, things are a bit different. Bare metal: duration=3.364873568s megabytes=10000.0 speed=2971.9MB/s Inside docker: duration=7.283130136s megabytes=10000.0 speed=1373.0MB/s There is still some overhead, but that is still over 10 gigabit. What is very interesting, is that running inside docker using –net=host, gives;