Wednesday, May 24, 2017

Google Cloud Print and Web Filters

At work, I have three LANTronix XPrintServer systems to make printers available to our chromebooks -- one for each school's printers. Recently, two schools' printers were listed as "Offline" and one wasn't. I eventually realized that my web filter was interfering with the keep-alive traffic between the devices and Google. The working system was already exempted in the web filter, so I added the other two and their printers became available almost immediately.

In the past, we would restart the devices and complain about how unstable GCP seemed to be. Now I'm starting to wonder if this might be the root cause of that apparent instability. If the filter blocked even one keep-alive signal, it would make sense that it would knock things offline indefinitely.

So if you use GCP and some kind of server to control it (Google Cloud Print Service, PaperCut, uniFLOW, XPrintServer, etc.) you might want to exempt its traffic from your web filtering.

Sunday, March 12, 2017

G Suite and Social Security Numbers

A nearby school was hit with a spearphishing attack not long ago. As a result, their employee's personal information, including social security numbers, were stolen.

To protect my coworkers from a similar attack, I set up an email filter to catch messages with social security numbers in them. These messages are quarantined and reviewed by humans, who then visit the sender in person to review the situation. When I discussed this with my counterparts in other districts, they were very interested. So I decided to document the process here in case others could benefit.

At my job, we use G Suite for Education. It has a feature called "Content compliance" which uses regular expressions. So I went to, clicked on "Apps", clicked on "G Suite", and then clicked on "Gmail". From there, I clicked on "User Settings", selected the root OU, and scrolled down to "Content compliance".

In "Content compliance", I added a new rule. If you do this, make sure that rule affects outbound messages. I recommend also adding "Internal - sending" and "Internal - receiving", as well. This can help in the event of one coworker's account being compromised by a bad actor who then requests data from someone in Payroll. In my case, I enabled all three of those conditions. However, I didn't enable "Inbound". My thinking was that if the message already traveled across the Internet, it was already vulnerable and there was hardly a point. I recommend you consider your own case and make your own decision.

Then add the following regular expression (a.k.a. "regexp" or "regex") as a rule:


In step three, I set the action to "Quarantine message". Then I saved the settings.

Lastly, I ran some tests. I made a test account and sent several messages to it. Those included the fake social security number of "123-45-6789" in the subject, the body, and in an Excel file attached to a message. In each case, as the administrator, I was sent a message telling me a new message was delivered to the quarantine with a link to take me there. I had the chance to review the message and reject it or approve it. If rejected, the message is sent back to the original sender with a vague message about it violating the recipient's content policy.

One final note: Don't forget the human factors.

If you decide to implement this, I strongly recommend discussing quarantined messages with their senders prior to rejecting or approving them. In my experience, people have responded quite well to this approach. I always explain the events at our neighboring district (without naming them), explain that I took steps to protect us, and finally explain that their message was caught in this filter. Even in cases where they were sending their own tax forms to another account they control, they were sympathetic to my intent. I was also respectful of their right to make their own decisions -- even if it put them at risk.

I think of it this way: If Mrs. Smith sent her student loan paperwork to herself, then I gave her my advice. She may choose to accept it (and I reject the message) or to accept the risk (and I approve the message.) That is her choice, as she is only putting herself at risk. In cases where someone is putting someone else at risk (e.g. Payroll sending out W-2 paperwork for employees), I speak to them and confirm that it is legitimate. If it is, I try to help them find a safer way to get their work done. By taking this approach, people generally react well and are appreciative.

Tuesday, February 7, 2017

Email Security Presentation

I recently had the opportunity to offer email security training to my coworkers. A few days later, our payroll clerk received a spear phishing message and realized it was a scam. She is quite sharp and probably would have spotted it anyway, but it got me thinking that others might not be so lucky.

I've modified my initial presentation for more general use. A number of details that I discussed verbally have been added to the slides and/or speaker notes. I am publishing this under a Creative Commons license so others can use it in their organizations. I recommend customizing it to suit your organization's needs before using it, but it should save a lot of time compared to building a presentation from scratch.

The one thing I ask in return is that you include a link back to this blog. Other than that, it is my earnest hope that you find this tool useful.

Options: Play in full screen | Make your own copy | License

Tuesday, December 20, 2016

GCRmanager, Part 2

If you run G Suite for Education (formerly Google Apps for Education), you probably use Google Classroom. If you read my article on the GCRmanager add-on for Google Sheets, then you know that you can pull data from G Suite about your school's usage of Google Classroom. Getting insight from that data can sometimes be challenging. So I decided I needed to write a follow-up to that article.

First, read my previous article. Once you have the data in Sheets and it finished filling in all the data, do this:

  1. Click on "Data" in the menu bar and then on "Pivot Table..."
  2. You'll be dropped into a new environment. On the bottom of the screen are tabs that you can use to flip between the full data you saw a moment ago and this new pivot table environment. For now, stay on the pivot table.
  3. On the right side, click on "Add field" next to "Rows" and select "OwnerEmail".
  4. On the right side, click on "Add field" next to "Columns" and select "courseState".
  5. On the right side, click on "Add field" next to "Values" and select "id". Set "Summarize by:" to "COUNTA".

At this point, you should have a list of teachers' email addresses. Next to each address, are three fields. The first is how many Classroom instances they created and haven't archived. This should be the number that they're actually using, but it is possible that they abandoned Classroom all together (and didn't clean up first) or that they're leaving old things active for their own reasons. The second field is the number that they've archived. The difference between these numbers is useful for seeing how they've shaped up over time. The third field is just the total of the first two.

If you want to "zoom in" on a school, there is a way to do that. On the right side, click on "Add field" next to "Filter" and select "OwnerEmail". Then click next to "Show:" to bring up a menu. Inside that menu, click on "Clear" to make the table show no one at all. Then click next to each name to put a check mark there and add them back to the table. This will allow you to see just the school, department, or team that you want to know about.

That is basically it. Pivot tables are a great tool once you learn how they work. They only work with certain kinds of data -- what is called "transactional data." Fortunately, that is exactly what GCRmanager makes. So feel free to tinker with the settings in order to see what you can do with it. There is probably a lot of interesting stuff you can figure out.

Tuesday, December 13, 2016

NTP Server Testing

If you run an NTP server, you should try this site. It is good for checking if your NTP server is available to your users when they're not on your internal network. It can also be helpful for running some security testing.

Tuesday, December 6, 2016

SSHguard & IPFW

It seems that SSHguard 1.7 dropped support for the "hosts.allow" file. Since I already wrote about how to setup SSHguard 1.6.x on FreeBSD using TCP Wrappers, I thought I should offer a quick update for SSHguard 1.7.x.

Please note that the process shown here assumes FreeBSD 10.x and SSHguard 1.7.x. The directions will go through five major steps: (1) Install SSHguard, (2) get SSHguard configured, (3) get IPFW started, (4) restart to bring it all together and make sure it works. Lastly, I'll cover (5) how to look at what is happening.

First, install SSHguard from the ports collection or upgrade it with portmaster, as needed. For example, to install it for the first time, you could:

cd /usr/ports/security/sshguard
make install

When prompted, select IPFW. To clean up unnecessary files, you can type "make clean", but this step is optional. If you already have it installed, check the FreeBSD Handbook for directions on using portsnap (section 4.5) and portmaster (section to upgrade the port. Just be careful to avoid breaking any other ports in the process.

Once you have SSHguard 1.7.x installed, you'll need to configure it. Start by whitelisting any necessary IP addresses by adding them to the file "/usr/local/etc/sshguard.whitelist". Only add one IP address per line. I recommend preceding those lines with a comment to help you remember why you added them. Comments are lines that begin with a ”#”. So you might have something like this:

# Don't block the VPN server.

The last step in configuring SSHguard is to tell your system to run it at boot time. Do this by adding these lines to "/etc/rc.conf":

# Start SSHGuard

Now we should be ready to move on to the IPFW system. This replaces the much easier to manage TCP Wrappers system we used in SSHguard 1.6, a.k.a. the "/etc/hosts.allow" file. The first step is to enable the IPFW firewall at boot time by adding these lines to /etc/rc.conf:


If you don't want to reboot the system, you can manually start the firewall by running "service ipfw start" as root. This is a great way to make sure that all your settings are right so far. However, don't do this unless you have physical access to the server. Changing firewall settings when you only have a network connection to the system is a quick way to get locked out of it by accident. The steps I've listed here won't do that, but I don't know what other changes you've made before reading this article, so I'm including this warning just in case.

Now that we have IPFW running, SSHguard will report suspicious activity to what IPFW calls "table 22." We need to tell IPFW to block everything listed in table 22. To do this, edit /etc/rc.local and add the following lines. If the file already exists, skip the first line and add the rest to the end of the file.

echo Adding sshguard to IPFW settings
/sbin/ipfw -q add 55000 deny all from 'table(22)' to any

Next, allow the /etc/rc.local script to run during system startup. To do that, run this command as root:

chmod 0755 /etc/rc.local

Restart the system with "shutdown -r now" to confirm that this script runs properly at startup. Watch for it when the startup messages scroll by on console and also check the settings by logging in as root and typing "ipfw list".

That is basically it. I encourage you to review these steps and try to learn what they do and why they work that way. You'll probably find ways to adjust this process to fit your system a little better. However, this should get you started.

If you ever want to know what the IPFW firewall is doing, you can check its rules by running "ipfw list" as root.

If you want to see the SSHguard rules, specifically, you need to look at table 22. SSHguard keeps these rules isolated in their own table, so they don't accidentally overwrite anything else nor create any other unpredictable outcomes. To look at table 22, just run "ipfw table 22 list" as root.

Lastly, if you're setting up SSHguard for the first time, please read the end of my older article as well. It includes some advice that is still relevant. Also, remember that SSHguard should only a piece of your risk mitigation strategy. No single product or trick will ever cover you completely. Even if you're not an expert in Information Security, you should always strive for defense in depth as a way to reduce your risks.

Tuesday, November 29, 2016

Google Drive and a Second Chromebook

When you buy a Chromebook, it usually comes with a two year upgrade of an extra 100GB on your Google account. What I didn't know, was if you could use the promotion again after the two years ended.

For example, I signed up for a free preview of YouTube Red a while back. When the preview was over, I happened to have a Chromecast and there was a promotion for a free month of YouTube Red for Chromecast owners. Unfortunately, I couldn't sign up for that, because I was no longer considered a "new" subscriber.

In 2014, I received a chromebook that had a bonus 1TB upgrade for Google Drive for two years. I gave it a try and the two years ran out very recently. Before it ran out, I bought a new chromebook. I'll skip the story of why I did this. What matters is this: It also had a bonus 100GB on Google Drive for two years. So when my two years of the 1TB upgrade ran out, I went to the Chromebook Goodies website from the new chromebook to see if I could redeem the offer. At worst, it would only be for new users, like the YouTube Red promotion mentioned above.

Fortunately, I was able to redeem the offer. It seems that Google doesn't care if you're a new user or an existing one -- only that you bought a chromebook.

So if you're the kind of person who would pay $2 each month for the 100GB of extra storage, then this is like an extra $48 off the cost of the chromebook every two years. I've seen decent chromebooks for as little as $200, so this can be a significant fraction of the cost. Even some of the nicer chromebooks are in the $300-$400 range, which would make this a 12% - 16% discount.

Side note #1: Keep an eye open for a "security checkup" deal with Google in February. In February 2015 and 2016, they offered an extra 2GB of storage for anyone who did this. I did it both times and I now have 19GB of free space in my account, in addition to the 100GB promotion from my chromebook. (Yes, a total of 119GB of storage for things I was going to do anyway.) The security checkup was a series of questions that you should probably check on anyway, so I highly recommend doing this if they offer it again in February of 2017.

Side note #2: If you have an old G Suite account from when they were free (back when it was just called "Google Apps" and they gave you 100 free accounts), this promotion will work. I'm using it with my account, which I registered in 2008.