API for Troy Hunts passwords list

TL;DR version: https://github.com/ryanschulze/password-check-api

So NIST updated their recommendations on passwords/authentication a few weeks ago. And while a lot of the reporting was about how password complexity was removed in favor of password length, one point I found intriguing was the suggestion to check if a users password falls into one of these categories:

  • Passwords obtained from previous breach corpuses.
  • Dictionary words.
  • Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
  • Context-specific words, such as the name of the service, the username, and derivatives thereof.

Troy Hunt, the guy behind https://haveibeenpwned.com, deals with a lot of data breaches and made 320 Million passwords from breaches available (at the time of this posting) to help people with checking if passwords that were part of a data breach.

I threw together a small API that can make the data from Troy Hunt easily query-able (or any list of SHA1 hashes for that matter). This can be useful if you have multiple systems that want to query the data, or if you want the data on a separate system.

It’s nothing special, a MySQL backend, a Webserver and an API application using the Slim framework. It’s also stupid fast because there is nothing fancy or special about it. Since it uses a well documented framework it is also easy to change/extend/adjust to your specific requirements.

Running an OSSEC server with lots of agents

The default maximum amount of agents an OSSEC server supports is 256. That’s not very much. In order to increase that number, you need to recompile the source code. Instructions for that are in the official documentation

Depending on the defaults of your Linux Distribution, you may start noticing dropped UDP packets (depending on the amount of agents connecting and how much data they are sending to the server). An easy way to check is with  cat /proc/net/snmp | grep Udp\:|column -t  (check if RcvbufErrors or InErrors are increasing).

The following tweaks to the incoming network buffers resolved the situation for me, and can be a good starting point if you are having similar problems and looking at which settings to tweak. Focus on the rmem  buffers first.

 

Bash function to run commands against ansible hosts

I haven’t posted anything ansible related in a while, so here is a nifty little function I regularly use when I want to execute something on all (or a subset) of ansible hosts. It’s just a wrapper around ansible host -m script -a scriptname.sh  but adds –tree so that the output is stored and can easily be parsed by jq 

Usage example:

Keeping track of Jira issues

A Jira search that I find useful (show tickets you created and haven’t been updated in a while) since I often have to track tickets I created across different projects. You can subscribe to searches and get an email sent with the results.

reporter = currentUser() AND updated < -90d AND resolution = Unresolved ORDER BY updatedDate DESC 

Fixing Ubuntu 17.04 DNS problems

I recently upgraded my Ubuntu box to 17.04.

Much to my surprise DNS starting behaving strangely, so I checked my DNS server … worked fine if I queried it directly, so I checked if DHCP was giving out the wrong DNS IP … nope, that was fine too. I checked /etc/nsswitch.conf , and that looked fine too so I checked what was ending up in /etc/resolv.conf and was surprised that it contains nameserver 127.0.0.53  instead of the “real” DNS server.

After a bit of research I found out that Ubuntu switched over to using systemd-resolved, which shoves itself between user land and the DNS servers and (at least in Ubuntu 17.04) has problems with servers that support DNSSEC. Very frustrating when you know everything is OK and worked in the past, just systemd messing with stuff and breaking it.

My workaround was to turn of DNSSEC validation. Not pretty but better than no DNS at all, until Ubuntu get’s their problems sorted out.