Sometimes, The Best Way to Help Is to Do Nothing

Have you ever been handed a task where your first thought is, "Why are we doing this?"

I'm not opposed to change - in fact, I welcome it. One of the first things I teach people who want to be involved in information technology and information security is that change happens on a daily basis. You've got to know what is happening and how to adapt to almost anything that comes your way. Look at all the ransomware articles going around as of late and you'll immediately understand how fast paced changes occur.

But this isn't about IT change. This is about providing services to those we believe need it.

I aspire to be in a position where I can think of the broader community and wonder, plan, and implement the idea of "What can we do as a company to ensure we're providing the best access to our services?". There's a hell of a lot of tape there that prevents this kind of thinking in my place of work, but due to an influx of monies, ideas float around that make absolutely no sense to implement.

There comes a point in planning for any project where the following questions are asked:

  • What do we need to get this project done?
  • How long will this project take to implement?
  • Who all needs to be involved in this project?

As of late, I wonder if anyone thinks of the last question:

  • Why do we need to complete this project?

"Why" is a subjective question no matter what follows it. You may be able to think of a hundred different technical or political reasons why something needs to be done, but ultimately the answer comes down to a general boilerplate response: "We need to assist [insert group]."

So you tell me: Why do we need to assist [insert group]?

Look, if you ask me to help, I'm going to help. I've written policies and procedures, I've automated countless systems, I've dived into job titles I never even thought I'd do in my life - and while I may have complained at the time, I absolutely enjoy the opportunity to learn how things work outside my personal scope. There are some times where I start to wonder what the scope of a said project is, and a job at a company is an ongoing, never-ending project.

I do reserve the right to ask "Why", and I have quite a few times. It's not to be condescending or as disrespect, I genuinely want to learn why you think the way you do. I may not agree with your answer, I may not agree with the project, I may not agree with your work ethic, but I'm entitled to any opinion I want to form and share (thus, I'm also entitled to the consequences of doing so).

Sometimes it's better to slow down on everything, take a breath, and look around at what everyone is doing. Listen in, hear thoughts, share concerns, actively take a role in everyone you interact with - learn what they do, ask what they need, how can you help, etc. Instead, we have individuals who want to assist everyone outside of their scope without focusing in, without input from those who have to make the project come alive, without repercussion on when a project fails or stalls...

Sometimes, the best way to help is to do nothing. Rather than take action on what you perceive as an issue, offer an ear and just listen.

docker-oclc-exproxy Released

Over the past several weeks, I've been finally able to sit down and learn about Docker. It's taken me honestly several years to actually understand what Docker does, how it all works, and the advantages and disadvantages of using Docker containers versus running VMs for each individual service. I'm glad to be able to say not only have I started the process of learning advanced deployment of Docker containers for both my home servers and my work, but I've written a Dockerfile for a software used by my work that could be useful in other educational institutions.

For those who use EZproxy by OCLC, this Docker container is a really safe way of running the EZproxy service for your campus. I've based it on the slim build of Debian, and the container only downloads the EZproxy BIN file to run within the container. I've been able to separate the config from the base BIN file, allowing it to run very smooth within a Docker container.

Feel free to check it out here!

The file contains just about everything needed to not only get the container up-and-running, but it also includes some helpful snippets regarding getting Let's Encrypt SSL working within the EZproxy service.

Adding Separator Spaces to the Dock in Mac OS X

I'm a fan of organization... most of the time. Using my Mac provided by work is definitely one of those times where being organized is key. Sometimes there's some applications you can't live without, but they may not be related to the overall use of the machine (personal apps on a work machine, for example), so having a quick visual way to separate the apps is very useful. Below is how you can add separator block to your dock.

  • Open a Terminal window on your Mac.
  • Input the following line, then press Enter: defaults write persistent-apps -array-add '{tile-data={}; tile-type="spacer-tile";}'
  • Input the following line, then press Enter: killall Dock

This will add a new blank space to the right-side of your Dock that you are able to drag and drop wherever is needed. You can run this as many times as needed to add multiple spacers as well!

Disabling Yammer, StaffHub, and Delve from Your Office 365 Tenant

Earlier today, I had a request to look into Microsoft’s Delve to see what it could do for my place of work… well, kind of. Delve seems like a nice product to see what everyone may be working on, but unfortunately, it’s a little misleading and it looks like files can be accessed by anyone on there. While the above statement isn’t actually true, certain aspects when browsing Delve really make you think that some of these documents shouldn’t be listed “publicly,” even though odds are that you were emailed the document and Delve just happened to place it there since it found it.

Admittedly, seeing this at the bottom of Delve doesn’t help matters too much, but it does lead to knowing how Delve actually works.

Now, this doesn’t mean that Delve is bad. It’s actually a pretty useful tool to see what documents are actively being worked on, and it’s a great tool to see items such as organizational charts, contact info, and more. However, there’s many other tools that do just that without the perceived risk of losing control of your data. Note that I said perceived risk – your data is not at risk, as Delve does not change file permissions nor actually store files, it just finds them in various areas like OneDrive, Outlook, Skype, Teams, etc.

This got me to looking around and see what else we don’t use, so I’ve looked and noticed we don’t use Yammer or StaffHub as well, so let’s disable these apps.

Disabling Delve

Disabling Delve isn’t really disabling Delve, but this disables Office Graph. Disabling Office Graph prevents Delve from showing any working files, but keeps access to other features such as the profile page with contact info, org. chart, etc.

You’ll need to log into your Office 365 Admin Center, then navigate to the SharePoint Admin Center. From there, click on Settings and look for the Office Graph setting. Set that to Don’t allow access to the Office Graph and you’re good to go.

Disabling StaffHub

Disabling StaffHub is probably the easiest of all of these as it’s just a toggle. To disable, head to and login with an account that has administrative capabilities. From there, switch that toggle on Enable Microsoft StaffHub to Off, and you’re golden.

If you want to revoke the license from the accounts as well, you can run the following PowerShell code to quickly remove it from all users in your organization:

$LO = New-MsolLicenseOptions -AccountSkuId <AccountSkuId> -DisabledPlans "<UndesirableService>"
$AllLicensed = Get-MsolUser -All | Where {$_.isLicensed -eq $true -and $_.licenses[0].AccountSku.SkuPartNumber -eq ($acctSKU).Substring($acctSKU.IndexOf(":")+1, $acctSKU.Length-$acctSKU.IndexOf(":")-1)}
$AllLicensed | ForEach {Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LO}
  • <AccountSkuId> will be the license assigned to the users. For example, one of my AccountSkuIds is org:STANDARDWOFFPACK_IW_FACULTY.
  • <UndesirableService> is the service that you want disabled. For StaffHub, this would be Deskless.

Disabling Yammer

Alright, get ready to be annoyed. There is no easy toggle for Yammer unless you’re a small organization. To disable it, you need to revoke the Yammer license from every licensed user in your tenant. If you’re like me, you’re going to want to PowerShell this. You’ll want to use the same code as above for disabling StaffHub, but with one notable change.

$LO = New-MsolLicenseOptions -AccountSkuId <AccountSkuId> -DisabledPlans "<UndesirableService>"
$AllLicensed = Get-MsolUser -All | Where {$_.isLicensed -eq $true -and $_.licenses[0].AccountSku.SkuPartNumber -eq ($acctSKU).Substring($acctSKU.IndexOf(":")+1, $acctSKU.Length-$acctSKU.IndexOf(":")-1)}
$AllLicensed | ForEach {Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LO}
  • <AccountSkuId> will be the license assigned to the users. For example, one of my AccountSkuIds is org:STANDARDWOFFPACK_IW_FACULTY.
  • <UndesirableService> is the service that you want disabled. For Yammer, this can be YAMMER_EDU or YAMMER_ENTERPRISE, depending on your licenses.


Here’s hoping this helps some Office 365 administrators on disabling services that they may not be using and do not want to use in the organization.

Locking Down a Linux Server - The Entryways

So my main goal for this week was to lock down my Linux servers at home. For the moment, I run two: A Raspberry Pi 3 running Raspbian, and my Synology DS418play which runs DSM. I’ll try to go over security basics that can apply to a wide range of Linux servers, but the bulk of my experience is with Debian-based distros, so if you’re not running Ubuntu, Debian, Linux Mint, or any other Debian derivative, your mileage may vary. These can also apply to other operating systems like Windows and Mac, it just depends on what you do with them.

Depending on what all you run on your servers, you may have various entryways to get in, including a web-based authentication (common on NAS appliances), GUI (whether it be GNOME, KDE, Cinnamon, etc.), SSH, Telnet (please don’t use Telnet), and other items you may not be thinking. It’s wise to think of all the possible ways to access data and secure them.


So I’ll start with Telnet, and this one’s simple: Do not use Telnet. Seriously, if you still rely on Telnet in 2019, something’s wrong. You should never use Telnet if at all possible. By default everything under it is plaintext, including authentication. Disable it when possible.


SSH is the preferred CLI method, so here’s a couple of pointers for securing your SSH environment.

  • Disable password-based authentication and switch to a key-based authentication. Is it annoying as hell sometimes? Yes. Does it really increase your security? Yes. If you’re securing systems that include a lot of data, this should be a standard.
    • To accomplish this, edit the /etc/ssh/sshd_config file on your installation and set PasswordAuthentication no. You’ll also need to add your public key to ~/.ssh/authorized_keys, otherwise you’ll lock yourself out of SSH! Once all of that is set, a restart of your machine or a restart of the ssh daemon is needed (systemctl restart sshd).
  • Disable the root account and do not use it. It’s another one of those annoying things, but it’s much safer to add your account as a sudoer and sudo your commands. This also prevents you from being an idiot and accidentally running rm -rf / on your machine. At least then you’ll have to actually type in sudo rm -rf / for that to work. Also, don’t do that.
    • A quick-and-easy command to disable the root account would be passwd -l root. This will prevent the root account from being able to log in.
  • Change the default port of SSH. Yes, this is more of security-through-obscurity than anything else, but you’d be surprised how many common port scanners will check that port 22 to see if anything happens to run on it. Why not run your SSH on port 23, or port 21, or any other port? You do have 65535 options to choose from, might as well choose your favorite number… unless it’s 22.
    • To change this, you’ll be back in the /etc/ssh/sshd_config file on your system. Find the line that states # Port 22, remove the #, and change the number to what you’d like it to be. Restart your ssh daemon and you’ll be good to go.


So GUI methods sound a little weird, but this includes any way you see a system with more than just text. This can include accessing it through your favorite X server, through a web interface, and other means. Here’s some things to take a look at to help secure this side of your systems.

  • Enable two-factor authentication. This is by far the most common thing you can do to help secure these areas. Whether you use an app on your phone that supports TOTP codes, a hardware token like a Yubikey, or you print out a giant list of one-time-use codes (don’t do that), these methods add the extra step of “what you have” to your “what you know”.
    • Need some recommended apps to hold those TOTP keys? I personally use Authy as it syncs with my phone number. Want something that doesn’t sync and always stays local? Take your pick of Google Authenticator, Microsoft Authenticator, or go the open source route with FreeOTP.
  • Change the default port of your administration console. It’s another one of those security-through-obscurity things, but if you run a web interface admin console, it’d be a good idea to change the port from the default setting, as the default settings are likely a quick search away from being found.
    • A good example of this is setting up my Synology server, default ports for admin are 5000 and 5001 (HTTP and HTTPS, respectively). Did I change those? You’re damn right I did.

Other Quick Things to Note

So these are just a few things to think about when securing the so-called entryways to your systems, but here’s a couple of other general items to keep in mind.

  • Never expose your SSH port to the Internet. Seriously. If you want to see what it’s like to be port-scanned and potentially DDoS’d, then by all means, but this is a practice that is never recommended.
  • Never expose your admin console to the Internet. This is deja vu, really. Insert what I said above here.


So this is just a first port in securing your Linux systems. Later on I may decide to publish more advanced things to think about when securing these systems, as there are many things to think of when making sure your data stays where you want it.