-
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.
Read more… -
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. They don’t really call it that, but if you look at the options for a recent version of zpool you will see the following new option: -p Pause scrubbing. Scrub pause state and progress are periodically synced to disk. If the system is restarted or pool is exported during a paused scrub, even after import, scrub will remain paused until it is resumed.
Read more… -
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.
Read more… -
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 .
Read more… -
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.
Read more… -
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:
Read more… -
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
Read more… -
Syslog is terrible
I hate syslog. The protocol is terrible. The message format is terrible. The API is terrible. The protocol The proposed syslog RFC was updated in 2009. Despite being a recent standard, it is primary a formalization of current implementations and retains much of the baggage from the 1980s. There are alternatives, but nothing standardized. Most embedded devices or turn-key systems only support the bare minimum required. Facilities The syslog header has a few bytes reserved for the source of the log message.
Read more… -
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;
Read more… -
http_flood in docker
I built a (somewhat bloated) docker image for http_flood with a simple Dockerfile root@dovm1:~# docker run -p 7070:7070 justinazoff/http-flood Unable to find image 'justinazoff/http-flood' (tag: latest) locally Pulling repository justinazoff/http-flood 0d71f044c41f: Download complete 511136ea3c5a: Download complete adfd622eb223: Download complete 9a776d8a79dd: Download complete 1819c4b85615: Download complete 032f3d3190f6: Download complete 6c027abac266: Download complete f05032d12482: Download complete 11a10f000aca: Download complete 01df4a932bd2: Download complete 2013/12/01 02:33:20 Listening on :7070 There seems to be a severe performance impact of running through docker though, running across the loopback interface I get 434.
Read more…