A couple of weeks ago I posted this little ditty about how to cold boot your Mac remotely, and one of the options nestled in the screenshot I included with that post was the intriguing “Wake for network access” checkbox.
It’s an option that I’ve mostly avoided paying any attention to over the years, because the computers I mostly tend to deal with are ones that are seldom (if ever) actually turned off. There are lots of reasons why this is the case, but they tend to fall into the two general buckets of This Computer Needs To Stay On Because People Are Getting Files From It, and the equally capitalized This Computer Needs To Stay On Because People Are Getting Services On It. The idea of needing to wake a computer remotely seemed a fringe issue at best, but oh how the wheel turns and time makes fools of us all etc etc.
We’re living in a world where remotely tinkering with non-servers is starting to be more of a pressing issue and a requirement than a suggestion. And there are ways of dealing with those kinds of requirements that aren’t immediately obvious. If you put the average, intelligent person in front of a screen with a checkbox marked “Wake for network access” then chances are they’d look up at the fact that the preference pane that the option is nestled in, note that it’s the Energy Saver pane, and come to the logical conclusion that if this is a place that controls when your computer goes to sleep and there’s an option there for something to do with waking over a network then it’s not a huge or illogical conceptual jump to decide that that if their computer was asleep and you tried to connect to it over the network then the computer would wake up.
This, it turns out, is absolutely true. And – in a more precise and accurate sense – an utter, utter lie. It’s entirely possible to wake your computer remotely, but there’s a specific way of doing it that isn’t immediately obvious and that isn’t ever really called out, and that way is by the implementation and use of a Magic Packet.
Okay, I should probably explain what a Magic Packet is. I could also call it a magic packet, sans capitalization, but that’s less fun, and if you’re going to reference supernatural capabilities in your IT doublespeak then you might as well lean into it. A Magic Packet is a specially-crafted network packet that contains the MAC address of the computer that it’s intended to reach, sent out over UDP to port 0, 7 or 9. It’s a highly targeted, highly specific finger prod to the sleeping computer that only that computer will respond to, and if you want to make one on your Mac then you have to jump through a hoop or two.
Firstly, you need a way to make a Magic Packet. This is probably unsurprising for anyone who’s read more than half a dozen of my posts, but I’m going to use homebrew to install a package to create and send said Magic Packet, thus:
brew install wakeonlan
Secondly, you’ll need some information about the computer you’re crafting the Magic Packet for – notably its IP address, the port number you’re aiming for, and its MAC address. The port number is 9 on macOS (at least, it is in every case I’ve seen so far, and if that doesn’t work you can try ports 0 and 7), and the command should be formatted something like this:
wakeonlan -i 10.0.0.1 -p 9 12:34:56:78:ab:cd
Plug that into the Terminal on the computer you’re trying to connect from, and all things being equal it’ll find its way to the targeted computer and raise it from it’s slumbers…
While IT consulting (where the particular scope and method of execution I tend to pursue is as a sort of Freelance Sysadmin For Hire) is an essential service, I’m finding that things are… quiet on the job front. When your business is largely composed of helping other businesses design, implement and maintain their Apple IT infrastructure and those businesses are either on hiatus or just plain twiddling their thumbs, then you find your workload substantially reduced.
Which, actually, is fine by me; like most people in my particular nook and cranny of the industry I work by appointment and very flexible hours, and have been doing it long enough and well enough that work is always there. That’s great, but the downside is that one rarely has time to go and do new things, or branch out and try something new. Still, now I have more free time while the world descends deeper into lockdown, so I’m using that time to learn something more about Swift via the miracle of Swift Playgrounds.
Swift Playgrounds is squarely pitched at kids, but as a forty-six year old it’s not insulting or too dreadful, and if you have nothing else to do and a passing interest then I urge you to take a look. I’ve spent the last week or so working through a lot of lessons that require you to guide a weird little cartoon guy through mazes and picking up jewels and toggling switches, and once that’s done I’m going to have a crack at the 100 Days of Swift thing. I’m great at knocking out some quick and dirty bash scripts, but I have an Anthropology degree and plunged straight out of college into working in 1994 and have never really stopped since; ergo I have zero formal coding experience and have had to kind of reverse-engineer things and self-teach in odd trajectories as I’ve gone along.
So far it’s been a bit of an eye-opener for exactly how rusty I am in all kinds of areas. I’ve managed to get through the first module with moderate ease, but the second module is a mite more challenging because it falls squarely into the trap of all Coding-For-Idiots type things; that it’s clearly written by people who know what they’re doing.
I’m sure you know what I’m talking about. You want to learn about a thing, so you buy a book that purports to teach you about it in thirty days, or twenty-four hours or something equivalent. The subject matter is immaterial; it could be C++, brain surgery, or washing machine repair. Let’s say it’s washing machine repair because that’s more fun. At any rate, the first couple of lessons are helpful and practical; they explain the broad strokes of what a washing machine is and a high-level view of its operation and fundamental purpose (ergo, dirty pants and hot water and soap go in one end and clean pants come out of the other), and then they detail the major bits of the washing machine – the drum, hoses, knobs and switches and whatnot.
And then they blindfold you and throw you into the deep end of a swimming pool with chains and weights around your feet by launching into, I don’t know, spindle torque ratio and foot-pounds per inch of water filtration, because it doesn’t occur to the jerk who wrote the thing that you have at best a passing level of experience at the operation of the WashMatic 9000™, didn’t do much physics or math in school, and that the little you remember about those things is buried beneath the better part of thirty years’ worth of other stuff that turns out to be considerably more pressing on a day-to-day basis. You’re a moron, is what I’m trying to get across here. You’re a moron and the book is probably written for what an expert thinks constitutes a moron, which is in actuality a person who is a less-qualified expert.
Anyway, a lot of the bits of the second module so far are in the mold of “This is an open-ended challenge that you can address any way you like using the things you’ve learned,” and you look at that little cartoon chap and his gems and switches and profound lack of spatial awareness and elementary common sense and shake your head wearily.
Further, it’s clear that whoever wrote this thing subsists on a diet of lies, and does in fact have a very particular way that they want you to solve the puzzle, despite their protestations to the contrary. You can feel the silent judgment.
Still. I have a very good friend from back in the UK who has taken to calling this current moment an “Unexpected Holiday,” which I think is a wonderfully optimistic way of looking at things. This is time out from our regularly scheduled lives, and it’s best to look at it as an opportunity and not a curse. We can’t go to the gym (because gyms are plague houses) and we can’t see our friends except as tiny, blocky images on Zoom, and staring at the walls – while fun – has a definite shelf life, so we might as well try and do something useful with the time. If anyone needs me then you’ll know where to find me, but until then I’ll be trying to work out why none of my code works while a little cartoon man on my screen glares at me, radiating mild disappointment.
In this period of ongoing peril and, well, frankly terrifyingly uncertain business environment, I’ve talked to a lot of folks who are having to radically adjust the equipment they use and the way that they use that equipment; i.e., not being in the same room as some of the computers that they’re used to being in the same room with.
This is, let’s face it, mostly servers. Entirely servers, actually, and as seems to be the spirit of the age right now it’s clear that things were easier back in the Good Old Days. Of course, I’m not talking about the Good Old Days pre-pandemic; I’m talking about the days when you could pick up the telephone, break out your credit card, and talk to a nice person at Apple and give them a lot of money in exchange for an Xserve.
Xserves were fabulous. Yes, they weren’t price or feature comparable to some of the offerings you’d get from a good PC server vendor, and they lacked a lot of things like expandability and were sorely limited by their 2U standard height and the number of drives you could throw in one, but if you wanted a macOS (Sorry, “Mac OS X”) server then they were the only game in town and they did an excellent job. I’ve talked in the past about how loud they were, but they included such niceties as redundant power supplies and Lights Out Management (LOM) unit, which allowed you to do all kinds of hardware management that included remote-booting the thing.
You can’t do that with a Mac today. If the box on your desk or in your server room down the hall or (as seems to be the case of late) forty miles down the road in a locked, sealed building is off then there’s ostensibly no way of turning it on unless you’re willing to lean over and push a button, walk down the hall and push a button, or get in your car, drive through the proto-apocalyptic wasteland that we apparently now all live in, break into a building, and push a button. If your Mac suffers a power outage then you can absolutely check this box:
…and the thing will obligingly fire up once power is restored, and that’s great, but it’s not the same thing as being able to shut a computer down and then fire it up again.
However, as is often the case with this kind of thing, there’s a way of doing it through the command-line if you don’t mind getting a little dirty, and by dirty I mean performing a dirty shutdown. What’s a dirty shutdown, you ask? Well, I’m glad you brought it up, because it’s a neat little trick that’s built into the OS that allows you to combine all the convenience of a nice, orderly shutdown with the exciting thrill of suddenly yanking the power cable out of the back of the thing like some kind of foaming maniac.
If you look at the man page for shutdown, you’ll see the following options:
The one to pay attention to there is the -u flag, which normally comes into play when you have your computer attached to a UPS. When the power goes out and your UPS kicks in then the computer will struggle on for as long as possible, but providing your UPS has a management port and a USB cable that you have plugged into your Mac then when it in turn realizes that it’s about to run out of juice it’ll send a command to your Mac to shutdown, but instead of just sitting there once power is restored the UPS simulates a power cut so that your Mac automatically boots.
It’s ingenious, and also allows you to shutdown your Mac in a nice, orderly fashion and then once you’re ready to reapply power it’ll automatically fire up instead of sitting there like a big metal lump.
So, if you just shut your Mac down from the command line by typing in sudo shutdown -h now then it’d halt the system, quit everything that needed quitting, and turn itself off in a neat, orderly fashion. Whether you manually disconnect power or not, the computer will require you to physically power it on by hitting the power button.
But if you invoke the -u flag and type in sudo shutdown -h -u now then the computer will do all the sensible, practical, good-housekeeping things you’d expect from a proper shutdown, and then tell itself that the power was unexpectedly disconnected so that when power is restored the computer will just fire right up.
“That’s great,” I hear you say. “But what good is it if, as you mentioned earlier, I’m stuck at home in glorious self-isolation with a year’s worth of bathroom tissue while the End of the World rages around me?”
Well, firstly that’s a little hysterical of you, but I’ll skate over that bit because you make a decent point. Where this option is useful is if you have a UPS with a network connection and remote on/off capabilities. There are options out there; just because there’s no LOM still extant on the Mac doesn’t mean that you can’t effectively outsource that component – just remote into the Mac, issue the dirty shutdown, then hop onto the UPS and turn it off or (if it’s possible with your model) turn off the power to the Mac. When you want to cold boot your Mac you just remote into the UPS, power it on, and that in turn supplies power to the Mac which – because it thinks it was unexpectedly shut down – automatically boots from cold, leaving you at the login screen.
This was a fun little project I poked around in recently while helping another ACN member with a data recovery project.
Back when Apple started shipping computers with Fusion drives, said Fusion drives were wonderful things. Essentially what they did was pair a 128GB SSD with a 1TB+ rotational hard drive and use CoreStorage to create a LUN that packed the two together and gave you the best of both worlds; a fast drive that held data for immediate use and a slower drive that was substantially larger and fed data to the fast drive. What you ended up with was what appeared to be a 1TB+ hard drive that was somewhat slower than a (greatly more expensive) SSD, but a lot faster than a regular 7200 rpm hard drive.
The trade off was that – at least in the Mac mini – that reduced the number of available drive slots to one, which was frustrating because the prior generation of Mac mini had two drive slots, thus allowing you to make a mirrored RAID of the boot drive. Which was very handy if you were using said Mac mini as a server, which a lot of people were doing. To get around the issue I’d break the Fusion drive into it’s constituent elements – a 128GB SSD and a larger hard drive – and then create a RAID mirror of the two. It wasn’t ideal (because the mirrored RAID would take the size of the lowest element – i.e., you’d only be able to use 128GB out of that 1TB+ hard drive), but if you were really just looking to use the internal drives for boot data and some caching then it was just fine. After all, actual user data would usually sit on a fast external RAID anyway.
Breaking the Fusion drive was pretty straightforward, and worked thus:
• First, boot from an external drive or put the Mac mini in Target Disk Mode, connected to another Mac.
• Second, open the Terminal and plug in diskutil coreStorage list to get a list of all the connected coreStorage volumes.
• Third, make a note of the logical volume group universal unique identifier (or lvgUUID if you don’t want to have to say that all the time). It’s a 32-digit number expressed in five groups, and it looks something like 1234a678-1a23-1b23-1c23-1234567890ab
• Finally, append that lvgUUID to the end of a diskutil command to delete the LUN, thus: diskutil coreStorage delete 1234a678-1a23-1b23-1c23-1234567890ab
Lo and behold, you’d now have a plain, regular, basic SSD and hard drive available for your RAIDing pleasure.
But what if you want to go the other way? If you have a small SSD and a large hard drive and you don’t really want two drives clogging the joint up and would prefer one faster drive? Well, it turns out that rolling your own Fusion drive requires a couple more steps than breaking one, but isn’t that difficult.
• First, get a list of disks connected to your Mac by typing diskutil list
• Choose the disks you want to use for your new Fusion drive. Let’s say they’re /dev/disk1 and /dev/disk2
Note: Exercise caution and take a moment over that last step. Where things go from this point on involve erasing and breaking things in your computer. Make absolutely sure that you’ve chosen the correct disks because otherwise Very Bad Things can happen.
• Type diskutil coresStorage create MyNewFusionDrive /dev/disk1 /dev/disk2
• You’ll be shown another lvgUUID. Make a note of that, as you’ll need it in the next step.
• Use that lvgUUID to create a new volume, stipulating the name, type, and amount of the drive you want to use. For example: diskutil coreStorage createVolume 1234a678-1a23-1b23-1c23-1234567890ab "NewFusionDrive" jhfs+ 100%
…and that’s about it. You should now have a new Fusion drive on your desktop.
Scams like this are nothing new. They’re pure, unadulterated opportunism, and they’re uniformly shoddy (in both purpose and execution) attempts to exploit people who are too stressed, ill-informed, or just plain busy to be able to filter information to the fullest extent.
Fortunately there are a few simple rules that you can adhere to that will protect you against the vast bulk of email/text/phone scams.
Consider the source of the information. Where is it purportedly coming from? What government agency is communicating with you, and does it sound legitimate?
A few years ago a common scam was to scare people into handing over bitcoin under threat of exposure of their browsing habits. Based on the idea that either guilt or the perception of guilt was a powerful motivator, scammers peeled email addresses and paired passwords from info dumps taken from large commercial hacks (e.g., the Target and Zappos customer database hacks) and would send threatening emails to folks with their passwords in plain text as proof that the scammer had legitimate access to the victim’s computer. It was moderately ingenious, but rather hampered by the fact that the fiction that surrounded a lot of the examples that we received panicky communications about revolved around the sender being a CIA or FBI agent.
The CIA or FBI don’t care a hoot about domestic malfeasance, and certainly not about what you look at on the internet provided that something isn’t state secrets that you’re sending to a foreign power. Likewise, the IRS isn’t telling you that there’s been a COVID-19 outbreak in your area and that you should immediately send them a $29 evacuation fee. And Government agencies will always send email from a .gov email address; never a .com/.net/.whatever-else.
Anything that sounds too good to be true is always too good to be true. There are no miracle drugs available to treat Coronavirus/COVID-19. Essential Oils and Lemon Soap do not help. Solicitations to buy equipment or treatments or sanitizing products that are an easy sell, but they’re a scam.
The Government knows who you are already. There’s been a spate of fake “verification request” emails going around – telling folks that they’re eligible for emergency assistance and funds, but that before the federal government can cut a check they just need a little information first. Trivial things, like name, age, address, social security number. Maybe even banking details. Things that the Federal Government has already (or has no reason to ask for). If the only vector that the Federal Government has to communicate with you is your email address then that should send up some red flags.
Don’t give anyone your personal details – not your address, date of birth, banking information, usernames or passwords. Not ever, not under any circumstance. The people or organizations who need to contact you will have that already.
Scammers can’t spell. This applies to almost all scams on the internet, and again, it’s moderately ingenious. People who are too rushed or impaired to notice typos, serious grammatical errors, incorrect punctuation or flat out spelling mistakes are the target audience for scammers. It’s sort of reverse filtering; the people who’d notice those errors aren’t the target audience and are less likely to fall for a scam, whereas people who skate over those errors are more likely to be vulnerable and go along with what they’re being sold.
When in doubt, ask someone else. It doesn’t have to be your IT guy, or your boss – if something comes across your desk and you have concerns about legitimacy then talk to a co-worker or family member and have a second pair of eyes look at it before acting on it. This is something that I wish more folks would do; there’s an ego hit that you might take if you ask someone if the thing you’re looking at is fake and it is, and you might feel like an idiot. But we’ve seen powerful, intelligent, organized people get pulled in by scams and phishing attacks because nobody can be 100% attentive and execute perfect judgment 100% of the time. Running something past someone else is a remarkably efficient way of mitigating the issue.
Stay safe, stay healthy, and stay indoors for a while. These are trying times, and this current unpleasantness is tough on all of us; individuals, families and businesses both large and small. And – speaking as a small business – I’d very much like as many of you as possible to be here once this all blows over…
Not a terribly catchy title, but then again it’s not a terribly catchy subject. Still, a useful thing to have up your sleeve and incorporate into your regularly-scheduled maintenance. You are doing regularly-scheduled maintenance on your computer, right? Not just letting it be and then being surprised when it transpires that your sole copy of The Great American Novel™ disappears one day and you discover that the last backup took place sometime last June? Thought so. We’re all terribly responsible.
I’m a big fan of homebrew because I’m a sucker for package managers and small, superb little tools that make your life easier in a million ways (provided that you’re passably comfortable with using the Terminal.app). However, now and again I have to switch machines or upgrade/reinstall, and it’s a drag to have to remember all the stuff I’ve installed onto one machine and then go and find it all and reinstall it again on another machine. Yes, it’s not what you might call an everyday occurrence, but it happens from time to time and is – for lack of a better catchy epithet – a total bummer
Fortunately, you can mitigate some (if not all) of that by using a brewfile to go and build a list of everything you have on your computer and then format that in a file that homebrew can read and use to reinstall everything. And it’s ludicrously simple to do, thus:
• Install the Homebrew bundle tap: brew tap Homebrew/bundle
• Run the bundle command to dump a formatted list of all your homebrew packages into a brewfile: brew bundle dump
This will go and create a file called “brewfile” at the root of your home directory, and opening that file will reveal something like this:
There are many like it, but this brewfile is mine.
Now, having that brewfile on your computer is great, but in the case where you’d want to restore that onto a new computer then there’s no guarantee that your older computer will be accessible (or even functional), so having the file somewhere else seems like a good idea. If you run the brew bundle dump command a second time it’ll error out because the file already exists, so I like to combine it with a mv command to create the file where it expects it to be (in my home folder) and then move it to my Dropbox, thus:
brew bundle dump; mv ~/Brewfile ~/Dropbox/
Because the mv command is moderately intelligent it will overwrite any existing file with a new copy, thus saving a lot of tiresome hunting and deleting every time you want to save a new copy.
Finally, I automate the process by creating an alias in my .zprofile to do a lot of the tedious typing for me:
alias brewfile='brew bundle dump; mv ~/Brewfile ~/Dropbox/'
Great! But what if I want to also put a copy of my .zprofile to Dropbox as well? I can’t use the mv command for that because, well, I need my .zprofile where it is and not solely living in Dropbox where it can’t do me any good. All things are fixable through the mercy of hideously clunky shell commands, so I cobbled together this monstrosity that seems to do the job nicely:
Using the brewfile to restore your packages onto a new machine is trivially simple; just install homebrew, then brew tap Homebrew/bundle again to get the bundle package onto your machine, then finally put your saved brewfile into the root of your home folder (where bundle expects it to be) and run brew bundle install – depending on all the stuff you have on there it can take a while (and if it’s trying to pull down Xcode and a bunch of Apple productivity apps then I mean a while).
This approach isn’t what you’d call pretty, but it’ll get the job done. And if that’s not the definition of using UNIX packages then I don’t know what is.
Yes, this is going to be a tiresome shell script post, but the thing about tiresome shell script posts tend to be actually useful things if you’re looking for a quick way of reminding yourself about the quickest, easiest and most efficient way of performing some simple but crucial task without a lot of pointing and clicking (and, better yet, without having to actually do any of that at all). After all, this blog is squarely pitched at people like me who enjoy shell scripting but got their degrees in Anthropology and had to pick this stuff as they went along so there’s probably some value in it.
I greatly enjoy Jamf Pro, and if you’re looking for a solution to implement or administer a whole raft of computer and devices then you could a) do far worse than use what is essentially the premier product for doing that, and b) give me a call. Rates are reasonable, operators standing by etc etc.
One of the fun things about Jamf Pro is that there are a couple of different ways of sending a script to a client machine without much (if any) input from the user, who probably has better things to do with his/her/their time. The best way is by setting an Extension Attribute – you write a script (or use/customize one of the hundreds of scripts or templates built into Jamf Pro or posted on Jamf Nation) to run a script against a macOS computer on check-in. In plain English, the Jamf Binary that gets installed on your client computer when you setup Jamf sits quietly in the background and occasionally phones home to the Jamf Server to let the server know that all is well, and to ask if there are any messages for it to look at. When it checks in then the Jamf Server can send down policies and profiles to restrict or allow the client computer to do all kinds of things, and in addition can run a shell script on the computer as root.
Which is very, very handy, because when you’re trying to administer computers and you need to do something substantive to those computers via the command line then you need to be able to do so as root, and chances are that a good number of your end users are either going to look askance at plugging in their passwords into odd screens or are running non-admin accounts and just plain don’t have useful passwords to plug in there. And also very handy because you can take the output of those scripts and put them into Jamf Pro by setting an Extension Attribute and throwing the result into a Smart Computer Group and in turn putting that onto your Dashboard.
In plain English – this is a thing that Jamf Pro puts on your computer that can report back all kinds of custom, non-standard but highly useful information, such as whether your laptop battery health has dipped below acceptable levels, whether your hard drive has been throwing up errors, or if your computer hasn’t backed up in a week; all useful things that someone should know about, and all indicative of a need for urgent attention and service. Further, all things that you – as the end user – might just plain not notice until it’s far, far too late.
Extension Attributes can handle full-size, complex, heavy duty scripts. You can see some examples here. The other place you can use shell scripts in Jamf Pro is in the Files and Processes field in Policies, and that’s where the operators come into play.
See, the idea is that you throw simple, single-command one-shot scripts into that field so that you can accomplish quick, basic tasks – with root permissions – on the destination Mac. Which is great if you want to, say, set the NTP time server or point the computer at an alternate Software Update Server.
But what if you want to put something a little more complex in there and string a couple of commands together? Well, it’s not widely and loudly talked about but you are able to do that by stringing your commands together using an operator like &&, || or ;.
A very quick word or two about && and || follows:
&& works as a logical AND statement – requiring all conditions to be true. An example of this would be something like:
echo 'Hello World' && echo 'Goodbye Cruel World'
Which would give you an output of
Hello World
Goodbye Cruel World
|| works as a logical OR statement – requiring only one condition to be true, thus:
echo 'Hello World' || echo 'Goodbye Cruel World'
Which would give you an output of
Hello World
Back to the good stuff! Let’s say that I wanted to be able to construct a policy that would change the hostname of a client computer to match it’s hardware serial number. There are reasons not to do that (chiefly that it looks messy and that end users might find it confusing and impersonal), but equally if you’re working in a lab with a lot of identical workstations then using that as a demarcator might be practical. There are two steps to making this happen.
First, you have to find the serial number of the computer. This part is relatively straightforward because all you really need to do is to go talk to the I/O Kit Registry (ioreg) command and tell it to go search through the million billion things it can look at and pull out the entry for the computer’s serial number, thus:
Go ahead and drop that into your Terminal and hit return, and it’ll throw your serial number back at you. Great. Next you’ll need a command to go and set the hostname of the computer. We’ll hit up the System Configuration Utility command (scutil), thus:
Finally, we’ll need to stick these two crazy kids together by getting ioreg to return the serial number, setting that as a variable, and then passing that variable over to scutil, like so:
What we’ve done here is glue those two commands together with a ; – but if the first command errored out or failed or some new update renamed or borked something in ioreg then the latter command would simply fail without giving you much indication that anything had gone wrong. The good news is that with this particular command the worst that could happen would be inaction; without relevant input from the first command to the second then the computer would just sit there with it’s original hostname until told otherwise, and thanks to the magical healing powers of Jamf Pro you’d be able to make a nice, neat, very visible smart computer group on its dashboard so that you’d know which computers had the command failed and required additional work or laying on of hands…
Don’t get me wrong; I love my MacBook Pro and I love my Apple Watch. I was a first-adopter of the original Series 0 watch and wore it religiously until the battery life dropped to an hour or two and then the battery itself decided that after four years of service it was going to swell to the point that it popped the screen off of the thing, forcing me to go out and buy a new one. And by “forcing” I mean enabling, and by “enabling” I mean giving me the slight excuse I needed to go buy another thing.
My current Apple Watch is a Series 3 Space Grey Aluminum. I also have a stainless steel Series 3 that’s sitting in a drawer and that I’ll be trading in when I get round to it; it looks great and feels very solid, but that sucker is heavy to the point that when I put the aluminum one on I wonder if I’ve suddenly become a lot stronger than I thought I was because everything weighs half as much. I love my Apple Watch and it’s basically become indispensable in a world where I shove my phone in my bag most of the time and rely on the thing on my wrist to tell me what time it is, who’s calling me, and how little I’m working out. It’s an amazing gadget, and one of the things it does best is be a proxy for an iPhone. Which is a curse and a blessing when it comes to things like, say, authentication.
The idea goes something like this: if your iPhone can be unlocked by biometric data that positively identifies you as the owner of the device (TouchID or FaceID), then your watch talks to your iPhone and decides that it’s okay for it to unlock itself based off of that lower tier of authentication. And then, if your watch knows that you’re you because your iPhone tells it that’s the case, then can’t the watch itself then act as a proxy form of authentication for your computer?
I mean, it makes sense in a very practical way. Apple puts reasonable protections in place – the iCloud account you’re using has to have two-factor authentication set up – and it all seems pretty clever – once you get past the idea that your computer identifies you from your watch which identifies you from your iPhone which identifies you from your face or fingerprint, that is. It smacks of a bunch of kids standing on each others’ shoulders wearing an enormous overcoat to get into an R-rated movie, but nonetheless you can’t really fault the basic core of the idea. And really, it works well in reality too; Bluetooth Low Energy (BLE) does its job the way you expect it will.
This might be a good time and place to dip – in a very cursory fashion – into what Bluetooth actually is. Which is, confusingly, two entirely different things that don’t talk to each other. What we’ve traditionally considered as Bluetooth is Bluetooth “Classic”. It enjoys a robust data rate that allows you to transmit and receive data at a high rate, which makes it perfect for applications like media streaming to speakers – it ensures a constant flow of data between source and destination at distances up to 100 meters on the 2.4GHz spectrum. The other technology is Bluetooth Low Energy (or BLE for those of us who don’t want to type that out every time), which while it uses the same frequency and enjoys the same (if not greater range) isn’t designed for the kind of throughput you get from Bluetooth Classic. BLE is used in industries and applications where connectivity and small data transfers are preferred, which at the moment mostly means wearables and thus mostly means Apple Watches. While BLE technically enjoys the same range as Bluetooth Classic the proximity-sensing function of it is active within a much shorter range (about 1-2 meters).
In the case of my 16″ MacBook Pro and my Series 3 watch, it’s exactly 60″. I know this because I spent an enjoyable afternoon with a tape measure, a watch, a laptop, and a cat who tried to sit on all three at some point. With the “Unlock with Apple Watch” option checked in the Security Preference Pane I was able to unlock the laptop with the watch reliably at that distance before hitting the proverbial wall. That’s five feet from the laptop, and common sense would dictate that if you’re five feet’s worth of lunging distance from your computer then you’re probably going to be able to stop some miscreant from getting on there and causing much havoc.
In fact, it’s almost a certainty that you’ll be able to do that. Especially if your Mac is a desktop, as desktops are notoriously difficult to pick up with one hand and walk away with. You can probably see where I’m going with this; while you can bring your Apple Watch into close proximity with your laptop and unlock your way in you can also bring your laptop into close proximity with your watch and achieve the same result. And I know this because I’ve done it.
Just so we’re clear: I didn’t steal anyone’s laptop. In fact, I asked a friend of mine who works in a coffee shop to wait for me to go to the restroom, pick up my MacBook Pro, walk up to the restroom door and then see if it would unlock. He did, and it did, and if I’d been sans pants in a locked room then he could have escaped out of the back door with my unlocked laptop containing a ton of privileged data. As it is he charged me five dollars for two shots of espresso, so it’s not like the man is a saint.
Which brings me to the crux of the matter; you have to exhibit a little common sense when it comes to matters of authentication and access. The use case of a laptop wielding maniac loitering outside a restroom is a statistical long shot, but in an office with a ton of people wandering around it’s not improbable that this kind of attack could be carried off pretty efficiently…
As a person who fires up the Speedtest site and/or app somewhere between three and about eight hundred times a week, it is incalculably negligent of me not to have know that there’s a way of doing this from the Terminal.
“Fine,” I hear you ask. “That’s great, but why should anyone have to go tinkering around with the Terminal when there’s a browser right there that they probably have open already?
That’s an excellent question, and the answer is that using Speedtest from the browser is pretty awful. I mean it looks like this for goodness sakes:
Actual IP address obscured via VPN. Nice try, h@XXors!
I don’t need to see a lot of adverts, and I also don’t want to be mucking around with ad blocking software and tweaking hosts files and whatnot. Yes, there are ways to deal with this kind of annoyance, but you often end up with a different set of annoyances that are really no better in terms of your general mental health and not-grinding-your-molars-into-powder. This is much better, though:
100% improved by green text and fewer mortgage refinancing adverts.
It’s fabulously easy to do, and huge kudos to the good people at Ookla for not only building a tool to do this but also making it downloadable as a binary and also installable via homebrew using these three, simple commands:
$ brew tap teamookla/speedtest
$ brew update
$ brew install speedtest --force
When you first run it you’ll have to agree to their licensing terms, but on the assumption that those are acceptable to you then I encourage you to go ahead and install the thing. Your blood pressure levels will probably thank you.
Update: It gets better! Hitting speedtest -help gets you all manner of goodies that you don’t get with the regular, boring web version. Being able to specify the interface you want to test on is pretty huge, and probably extremely useful for network troubleshooting…
I – as I’ve probably noted elsewhere on this blog – am rapidly becoming terribly old. Well, not terribly old; it seems to be a convention of the human condition that we shift the goalposts on a rolling basis, and while I felt like the weight of adulthood had settled firmly on my shoulders in my late-twenties I’m now willing to accommodate a world view where forty-seven doesn’t seem so bad.
Still, age is all in the mind. And the knees. Well, actually it’s more tangibly a knee-based phenomenon; you can feel as vigorous and sharp as you ever did but then you stand up and your joints make alarming gronking sounds and you start to wonder how long before the reaper starts pencilling you in on his rounds.
All this homespun wisdom is a preamble to the meat of this piece, which is about the state of malware on macOS. Oh, you didn’t get that from all the blathering about knees? That’s fair, I suppose; the occasion of my impending decrepitude is more about being old enough to remember when Macs got viruses, which was a very, very long time ago.
It’s worth spending a moment digging into what viruses actually are and the difference between viruses and malware. These seem to be used interchangeably, but they’re distinct and very different animals and the methods in which they’re employed and protected against are also distinct.
Viruses are computer programs that self-replicate when executed, modifying other pieces of code (executables and files/data) to incorporate themselves so that they can spread and infect other computers. If you make an exception for Microsoft Word macro viruses (which I do because they don’t do code-injection into anything and your Mac can only be a carrier) then there are no macOS viruses. That’s right, I’m planting my flag squarely in “none” and I’m holding that ground. If you disagree then, well, you and I are going to have to go outside and fight. And I’m going to take off my shirt and fight and nobody wants to see that.
(Sidebar: I wear glasses and have bad knees and a doctors note that stipulates no brawling in the street.)
The Mac used to have viruses, back pre-OS X. Some nasty ones, too, but virus software is just that – software – and if your modus operandi was to write code to infect the maximum number of machines in the 1990’s and 2000’s then your best bet was to go and write viruses for Windows. The irony that developers wouldn’t write viruses for Macs for the same reason that they wouldn’t write a lot of other software for Macs is not lost on me.
Malware is a wider net, and were it not for the specific mechanic of viruses (and the fact that people were talking about computer viruses decades before anyone coined the phrase “Malware”) then I’d be including viruses in that net. Most people do, and I agree that while that’s technically accurate in that a virus is a piece of software that runs on your computer and does Something Bad what we think of as Malware (or Adware, which is basically just a flavor of Malware) in this day and age tends to require human input. Generally speaking you have to perform an action to enable it; it’s the modern-day equivalent of having to invite the Vampire into your home before it can eat you.
Fortunately, Apple has done a lot to protect macOS. So much, in fact, that if we take a step out of the world of breathless hand-wringing and pause for a brief moment of sanity it becomes apparent that macOS malware is a fringe problem. A couple of weeks back the nice folks at Malwarebytes got a lot of press by pointing out that macOS Malware attacks are up disproportionately compared with Windows/Android attacks, and this is in fact broadly accurate. What a lot of people seem to have conveniently side-stepped is that you can shoot arrows at a brick wall all day long and not manage to do a lot of damage. Yes, macOS Malware attacks are up, but actual, real-world damage? Not a lot of significant difference there.
Why? My theory is that the point where macOS was insignificant enough to not merit attention and the point in which Apple introduced protections like GateKeeper (and now code notarization) was less a point and more an overlap. Further, it’s worth pointing out that with some elementary training and an ounce of common sense you can probably roll around in Malware all day long and come away smelling of roses. Let’s use the miracle of educational jpegs to illustrate this, shall we?
This looks scary, no?
The fine folks at Kaspersky published this graphic back in January, showing that the Shlayer Trojan has an astonishing 29.28% share of attacks against macOS users. That’s clearly a bad thing and makes for great copy if you’re a company that makes anti-virus/anti-malware software, but the one thing that Shlayer has in common with every single other item on that list (and in fact every single other piece of malware for the Mac) is that it requires the following three things:
First, it requires you to download a piece of software from a suspicious website.
Second, it requires you to ignore the warnings that Apple gives you about installing unsigned software from an unknown source.
Third, it requires you to install that software by giving it your username and password – effectively authorizing the code to run on your computer.
That’s three break points that you’re required to sail through without considering your actions. It’s easy to point fingers at end-users and decide that that kind of negligence is inexcusable, but that’s childish behavior, lazy, reductive thinking and a quick and easy way to pass blame around; while finding who is to blame for something is always fun and enjoyable it’s ultimately not as important or useful as figuring out the explanation for the process of what went wrong.
So, let’s talk about process and education and best practices for not infecting your computer with Coronavirus, burning your house down and generally ruining your life. Those three break points are great places to start, and we’ll hit them with three actions; Evaluation, Execution and Consideration
Evaluation – Why do you need that piece of software? That browser extension? That utility that will make your Mac Run Faster And Better And Free Up Memory? What issue are you trying to correct? Recognizing that bad actors are perfectly willing to push solutions to problems that may (or may not) exist is a solid first step, and one that I encourage people to undertake.
I’ll go one further: pretty much every “Utility” “designed” to “make your Mac Faster” is either a con or outright lie. The vast bulk of them do nothing, and the few that actually do anything at all just run shell scripts to do the kind of periodic self-maintenance that your Mac does by itself without requiring stupid, shoddily-designed third party nonsense. A lot of these are malware, and the ones that aren’t are dumb and bad and designed to prey on the fears and concerns of people who don’t have the time or inclination to think about things like how your computer does periodic self-maintenance. You don’t need an app to free up memory or defrag your drive. Those are things that your computer does all by itself, or else there are sensible, grown-up reasons why it doesn’t do them at all. “Clearing Virtual Memory” sounds great, but when it means that your computer has to go and rebuild the caches it has in place and you’ve actually made your computer slower and less responsive then it doesn’t sound so great after all.
As a person who makes their living charging people for the privilege of having me help them with their macOS/iOS/network issues it may sound self-serving, but if you’re having an issue with your computer then call someone professional and ask their opinion. Or at least do a little research, and recognize that you’re not alone in figuring this stuff out. Not to be too pay-no-attention-to-the-man-behind-the-curtain about this, but malware authors don’t issue press releases and when a new piece of malware hits. We IT professionals are not notified in advance. We have groups and bulletin boards and mailing lists that we subscribe to where other professionals find weird things and report them and we figure stuff out. We ask questions and raise concerns and identify threats as a group. The second that some new, weird utility called “FixMyMacProFast” pops up you can bet someone’s looking at it with a long, critical eye, and if it’s problematic then word gets out fast. At the very least, google things before you download them and consider your sources.
So, call your IT person. There’s a decent chance that he/she/they won’t bill you for it, and they’ll be a lot happier about nipping something in the bud for free than dealing with a roiling nightmare and sleepless nights on the company dime.
Execution – This is your second break point. The moment that you’ve downloaded the new thing™ and you’re at the precipice of installing it. Before you go ahead, Gatekeeper will step in and your Mac will throw up a warning if the thing isn’t signed by a developer certificate, thus:
Names blanked out to protect the innocent.
Your computer is literally telling you “Hey, I can’t guarantee that this isn’t going to do something really, really bad. Are you completely sure that you want to do this? I mean, really?”
At this point you can’t open the thing, except by hitting “OK” and then either adjusting your Gatekeeper preferences or by right clicking on the installer and explicitly telling your Mac to open it. Depending on how you look at it that’s either one or two break points at which you should be considering the provenance of what you’re about to put on your computer.
Consideration – This is your last chance. Before the executable runs it will probably want your username and password, so take a breath and think about what that means. This is a potentially unknown actor on your computer that Apple has specifically warned you isn’t necessarily legitimate, and that you’ve had to undertake extra steps to allow in, and now it wants your credentials – the same credentials used for, say, your Keychain. Where you probably keep a lot of encrypted data that you wouldn’t necessarily want accessed by anyone else. Passwords for email. Web pages. Encrypted notes. Banking information. Apple has included all kinds of security in the OS and in the hardware of the device itself, but that’s largely for naught if you’re going to hold the door open and freely hand out your private information. Consider this move very carefully.
The only thing that I really took away from my long-ago degree in Anthropology was the lesson that people – by and large – aren’t dumb. We may not understand why our fellow man believes something or acts in a certain way, but it’s a solid bet that they’re doing it for what they believe to be a damn good reason. Cargo cultists only look misguided and ill-informed from the outside; step in their shoes and look at their perspective and it’s very difficult to announce that their actions are illogical.
People tend to act in ways that make sense to them and seem the most logical and beneficial using the information on hand, and that’s the only vector that malware authors have to exploit. Further, anti-Malware/anti-Virus companies have a vested interest in building a little healthy hysteria up because they have targets and sales goals and costs, and if you’re a fire-extinguisher salesman then yelling “Fire” in a crowded theater makes good sense if you have a stall set up in the lobby. The middle line between actual and perceived threat is something that should be clearly identified and kept in perspective; if you want to protect yourself or your organization against attack then it’s vital to stay abreast of the dangers, enact reasonable protections and educate users on the threats that they’re going to face. There are great tools built into macOS, but tools are only as good as the hands that wield them…
