After over eight years of using primarily Linux as my OS of choice, today was the first time that my system has locked me out for failed password attempts. It wasn’t that I had forgotten by password. I was simply in a hurry and made a typo three times in row, and, apparently, the pam_faillock.so PAM module is configured to lockout the user for fifteen minutes after three failed login attempts. At least on Arch Linux (btw) anyway.

If you’re like me, and think that lockout policy is just a little aggressive, then look no further. I’ll get you sorted. The default location for the pam_faillock.so module config is /etc/security/faillock.conf, and in that file you’ll find an entry titled deny set to 3.

# Deny access if the number of consecutive authentication failures
# for this user during the recent interval exceeds n tries.
# The default is 3.
deny = 3

Swap that sucker to a more agreeable number. I picked 10. The next time you restart your system, the new default will be set! If you’ve somehow locked a user session, but you still have access on the system as a root user then you can reset the lockout with the following command without needing to restart.

faillock --user YourUsername --reset

Happy hacking!

Today I needed to setup pip in a python virtual environment inside a Docker container to quickly install a couple dependencies for testing without doing a full rebuild. Unfortunately, pip wasn’t included as a dependency for the docker container because additional python dependencies didn’t normally need to be installed during regular operation. But, luckily for us there’s a python package for that. Enter stage left, ensurepip.

Activate your virtual environment wherever it resides e.g. source ./.venv/bin/active and make a call to the ensurepip module with python -m ensurepip. You should get output that looks something like this:

Looking in links: /tmp/tmpznyyt9jn
Processing /tmp/tmpznyyt9jn/pip-26.0.1-py3-none-any.whl
Installing collected packages: pip
Successfully installed pip-26.0.1

There you go, pip ready and rarin’ to go

If you’ve ever found yourself browsing through RFCs published by the IETF, you know it can be a bit of a chore if you’re just researching some tag name or error code. You shouldn’t need to read through the entire spec for a protocol just to do some troubleshooting. Right? Well, here comes IANA to the rescue. IANA has conveniently compiled a central repository for the many codes and numbers contained in Internet protocols. You can find it at their protocol registry.

Personally I was just looking for a simple breakdown of all the tags available for DMARC. Of course, there’s also a DMARC tag registry table embedded in the DMARC RFC (RFC 7489). But I was having trouble wading through all 73 pages of the spec. So, in this case, it wasn’t really necessary. However, for something like the SMTP service extensions, it can be much more useful as the service extensions are spread across many different RFCs.

I’ve recently been trying to get a better handle on how email works and how it’s secured. If you want to do the same. Go try out the exercises at https://www.learndmarc.com.

It’s a great resource for visualizing how DMARC works in conjuction with Sender Policy Framework (SPF) and Domain Keys Identified mail (DKIM) to secure email and catch spam and phishing attempts.

There’s even a quiz you can try to see how well you can analyze email traffic and determine the DMARC results.