Long Weekend Update

Email Integration

Aside from general work to improve the security posture of the public interface, my latest focus is standing up an email service for new registrations.

The working assumptions include that

  1. an individual will be enrolled via keycloak or a similar identity management package;
  2. on enrollment, several service will become immediately available to the user, including email;
  3. email will be accessed through a web interface; and,
  4. it would be pretty silly if we’re using an identity management platform if our web interface for email had yet another login interface, right?

I anticipate that we’ll be starting with an Ubuntu server 18.04 operating system running Postfix for SMTP and Dovecot for IMAP, where Dovecot provides the authentication functions for both SMTP & IMAP. For the web interface, I’m taking an initial stab with RoundCube, which itself rides on a LAMP stack.

There’s some additional discussion of the work in the article “Integrator Challenges, Email Edition” (link), but in summary:

  1. The operational test email stack that I had readily available is riding on Ubuntu 16.04, whose repository supports a Dovecot version that does not yet provide OpenID-Connect support.
  2. RoundCube has a plugin for handling OpenID-Connect, but it appears to add a bit too much complexity for what we’re after. Instead, I’m taking a look through the RoundCube source code (PHP) and examining how they handle Kerberos, which provides somewhat equivalent challenges.

All in all, it’s clear enough to see that it’s possible, but not too clear to see how long it’ll take to work through in my spare time.

Still, it looks promising and RoundCube does indeed look like a nicely designed project.

Fingers crossed!

WordPress Attack Aftermath?

Well, there’s no aftermath, thank goodness.

  1. I continue to block known foreign IP addresses during development as the log shows no sign of constant blind attacks relenting.
  2. Killing DigitalOcean access has made the logs so much quieter. That’s a shame. Since their CIDR blocks are scattered all over the place, I occasionally do spot another one sneaking through like roaches. Each new offender results in nuking the whole block.
  3. I’ve added two constraints on accessing the wp-login.php endpoint: (a) No POSTs, and (b) no GETs without referrals. Obviously the no POST rule is sufficient to quash a password guest, but that may be opened up again later. The second rule helps blunt scanners and helps help thwart some of the password guessers.

And now, since we’re mostly dealing with U.S. visitors, Happy Labor Day!

DigitalOcean #blocked

This website has been under fairly constant password guessing attacks for days, with the majority of traffic originating from Digital Ocean cloud-hosted assets.

Did I mention that anybody could simply sign up for an account if they wanted one?

There are a couple of things to think about here:

  • Providers that allow a user to do just about anything end up losing reputation. If you’re clients are up to no good, eventually your entire service will be blocked.
  • These paths are also the way your clients will reach you. These cheap nodes can be Tor, VPN, and other proxy endpoints that conceal the user’s origin and provide some security where they stand.

So, when you vouch for someone and give them free reign with your technologies, are you setting the stage for problems with people who will take advantage? How will that affect your other users if your service loses reputation? And where do you draw the line in protecting them?

I don’t know that there are any easy solutions. I’m happy to say that the constant barrage had no affect on the current servers, but I’m a bit sad to say that I added every Digital Ocean CIDR range I could find to the firewall’s blacklist — it was just too tedious sifting through their relentless noise.

We’ll see how it goes as things develop.