MacInTouch Amazon link...

security questions and advice

Channels
Security, Questions
I'm hoping this might help someone after having my own little security nightmare - installing an SSL certificate into Mojave and Apache. Note: I had zero experience with SSL certs other than clicking a button in OS X Server, which we know doesn't include Web serving on Mojave.

We purchased an SSL cert from GoDaddy and spent three painful days trying to get it installed and working. Apple's proclivity to hide things away (the certificates) didn't make life any easier, and a couple of hours with GoDaddy support wasn't helpful.

Eventually I gave up and investigated Let's Encrypt, the free verified certificate providers. It required installing Homebrew and the Certbot command-line utility, but one simple command got me most of the way there. (I had one error, which a Google search answered. Ran it again and got one more error - same deal: Google was able to answer and it involved commenting out one line.)

Five minutes later, I was up and running with SSL on my websites and auto-renew running.

If you have a need to make your site https and are hosting on a Mac with Apache, it is worth the effort to look into Certbot. It may just save your hair, your spirit and your sense of humour.

For those who are unaware, if your website doesn't use https, your site is flagged as insecure by Chrome and its derivatives. Given the popularity of Chrome this might be an important issue for you.
 


I'm hoping this might help someone after having my own little security nightmare - installing an SSL certificate into Mojave and Apache. Note: I had zero experience with SSL certs other than clicking a button in OS X Server, which we know doesn't include Web serving on Mojave.

We purchased an SSL cert from GoDaddy and spent three painful days trying to get it installed and working. Apple's proclivity to hide things away (the certificates) didn't make life any easier, and a couple of hours with GoDaddy support wasn't helpful.

Eventually I gave up and investigated Let's Encrypt, the free verified certificate providers. It required installing Homebrew and the Certbot command-line utility, but one simple command got me most of the way there. (I had one error, which a Google search answered. Ran it again and got one more error - same deal: Google was able to answer and it involved commenting out one line.)

Five minutes later, I was up and running with SSL on my websites and auto-renew running.

If you have a need to make your site https and are hosting on a Mac with Apache, it is worth the effort to look into Certbot. It may just save your hair, your spirit and your sense of humour.

For those who are unaware, if your website doesn't use https, your site is flagged as insecure by Chrome and its derivatives. Given the popularity of Chrome this might be an important issue for you.
See also my MacStrategy article and how-to guide:
 


To try to clarify my choice of a non-standard SSH port (i.e., non-port 22), my thinking process was that there appear to me to be three means to harden remote access to any [Unix]-based computer (including macOS):

1. Create usernames / passwords - hopefully not stupid ones - to permit access to the server.
2. Install the necessary SSH public and private keys, with the appropriate keys being distributed to clients to add to their authorized_keys file.
3. Change the access port from standard SSH Port 22 to something else.

These three means of security are non-exclusive, meaning a server might employ just one, two or all three methods. I happen to have chosen to employ all three, but my use case is strictly individual: Only I need remote access to my home server from several devices I control; no one else is involved.

The main point common to all of these methods is that something needs to be distributed to a client for access. It might be username/password, or a client certificate key (which then needs to be installed), or the SSH port number (if non-standard).

I can't see how the number of different clients who need access to the server can eliminate that need to communicate to a client one or more of these key pieces of information. (Oh wait, yes I can: a large-ish enterprise deploys already configured devices to the clients, who will use them to access the server.)

These are my own rationale, but the plan has practically eliminated (in my view) the chances of hack access to my server. (This assumes my remote devices themselves are not stolen and hacked, of course.) And as I mentioned, the use of a non-22 SSH port has yielded beautifully empty access logs.

I am sure there are other strategies which are more appropriate for other use cases, but this works for me.
 


I have access to view security logs for my company's servers. I cannot begin to tell you the number of login attempts we see. It's astronomical. If you use short, non-random passwords (anything in a dictionary) you're toast.
What you should do: configure SSHD so that it only allows certificate-based authentication, rejecting all password logins.

What actually happens: macOS updates downgrade the SSHD configuration back to accept password logins. This is Apple deliberately undermining the security of my machine.

I've even seen Security Updates wipe out the SSHD security settings and replace it with the insecure values, but leave remote logins enabled.
 


To try to clarify my choice of a non-standard SSH port (i.e., non-port 22), my thinking process was that there appear to me to be three means to harden remote access to any [Unix]-based computer (including macOS):
1. Create usernames / passwords - hopefully not stupid ones - to permit access to the server.​
2. Install the necessary SSH public and private keys, with the appropriate keys being distributed to clients to add to their authorized_keys file.​
3. Change the access port from standard SSH Port 22 to something else.​
... as I mentioned, the use of a non-22 SSH port has yielded beautifully empty access logs.
There's certainly no harm in doing this if it's workable for your use case, but it's important to realize that it doesn't protect you as much as many people think it does. It's trivially easy to port-scan a machine to identify SSH servers behind non-standard ports, then poke at those servers in all the same ways you can poke at a server on a standard port. The reason you don't see this happening much in your logs is because most of the same mindless brute-force script kiddie attackers that would never succeed in breaking into a well protected standard-port server anyway won't bother to do this either. It's the cleverer ones that are the real threat in any case.

By far the best thing you can do to lock down an SSH server is your option #2 (coupled, of course, with turning off password logins completely). It would really be best to never leave a password-authenticated SSH server connected to the open internet at all. If you do have to do that, something like fail2ban might be worth considering, although it's hard to set up if you're not a command-line Unix type and of somewhat reduced value in the age of distributed botnet attacks. But if you possibly can, just turn off passwords and use keys.
 


Another things you can do (if disabling password authentication is not an option) is to set up 2FA for accounts. For example, here's an article showing how to set up Google Authenticator with SSH in macOS.

With that set up, any user prompted to enter a password will need to use Google Authenticator as a second factor, while users using public key authentication will not.

It's a bit of a pain to set up, because you need to manually compile and install a few packages, but it's a good way to protect against a hacker that manages to crack a password.
 


Synology NAS have been mentioned often on MacInTouch. I saw this linked on XLR8YourMac:
StorageReview.com said:
Synology Urges User Action Against Potential Ransomware Attacks
... Synology has investigated the event and found that the cause of the attacks was due to dictionary attacks, not specific system vulnerabilities. The attacks appear to have started on July 19, 2019, were organized, and the culprits used botnet addresses to hide their source IP. Synology users are recommended to leverage their built-in network and account management settings to enhance their security.

Synology recommends the following for its users:
  • Use a complex and strong password, and Apply password strength rules to all users.
  • Create a new account in administrator group and disable the system default "admin" account.
  • Enable Auto Block in Control Panel to block IP addresses with too many failed login attempts.
  • Run Security Advisor to make sure there is no weak password in the system.
Synology users are recommended to enable their Firewall and 2-step verifications as well. Synology DSM also has a Snapshot feature that will make the NAS immune to encryption-based ransomware.
 


Thanks for posting the Synology ransomware security alert.

I believe "Snapshot" depends on the Btrfs file system. My understanding of a main benefit of snapshots is they can be transmitted to other connected Synologies or connected backup drives. That's fine, until the attack gets to those, too, as seems to have happened to connected backups, servers, and computers in the widely publicized ransomware attacks on US local governments.

The Synology page:
compares Btrfs and ext4, and lists advantages for both.

As one of the most important safeguards against ransomware is air-gapped backups, I create those by rotating USB-connected drives backed up with Synology's Hyperbackup. Since I know the ext4 format works and can be read on any Linux system, I chose that....
 


Ric Ford

MacInTouch
Does anyone here have a suggestion for an alternative app that can encrypt and hide folders?
That seems like a perfect use case for Disk Utility.
Apple Disk Utility Help said:
Create a secure disk image
If you have confidential documents that you don’t want others to see without your permission, you can put them in an encrypted disk image.
Here's a very simple alternative (with no encryption):
Brynjar Saunes Bye said:
Obscurity
Obscurity seems just like a generic Mac OS X folder. Simply place the 'folder' anywhere you want, and anyone snooping around your stuff deciding to double-click it will unknowingly arrive in an empty mock folder. However, if you right-click the 'folder' and choose 'Show Package Contents' from the contextual menu, a completely different folder will show up ready for you to hide all those intimate movies, pictures and old love letters in. It even hides all your secret documents from Spotlight and those pesky 'All Images', 'All Movies' and 'All Documents' Smart Folders in Finder.
 


I believe "Snapshot" depends on the Btrfs file system. My understanding of a main benefit of snapshots is they can be transmitted to other connected Synologies or connected backup drives.
While transmitting snapshot deltas is an easy and efficient remote backup mechanism, it is by no means the only benefit of snapshots. A snapshot also allows you to revert all or part of a filesystem to the point in time when the snapshot was taken.

For example, if you take a snapshot of the filesystem at 1 PM, and at 5 PM a ransomware attack encrypts every file on the volume (or, say, someone does "rm -rf /"), then you can simply revert the entire filesystem to the 1 PM snapshot, and none of those changes will have ever happened.
 


While transmitting snapshot deltas is an easy and efficient remote backup mechanism, it is by no means the only benefit of snapshots. ... if you take a snapshot of the filesystem at 1 PM, and at 5 PM a ransomware attack encrypts every file on the volume ... none of those changes will have ever happened.
My personal experience with snapshots:
  • Windows "Restore Points" that didn't, after malware removal
  • Apple Time Machine "Restore" that wouldn't, after user inadvertently deleted applications and data (suspected cause: Time Machine had filled the backup drive, didn't delete old versions, and provided no user notification)
  • Apple "Versions" that complicate simple photo and text edits and weren't as useful (to me) as simply versioning file names using File > Save As...
As to Btrfs on a Synology, if all works as it should, I see the theoretical advantage. I'd think that advantage would be greater when multiple users are actively creating and editing large numbers of files, though that's when the faster peformance of ext4 might also matter.
ZDNet (Aug. 2014) said:
Ransomeware attacks Synology NAS devices
The attack replaces the DSM management software on the NAS, encrypts the files on the device and demands that the user pay 0.6 BitCoins to retrieve the files.
If that should happen, I don't think either Btrfs or ext4 is safe. I searched rather throughly for Internet reports comparing the vulnerability of Btrfs and ext4 NAS file systems to ransomware and just didn't find any. Back to that air-gapped backup.
 


My personal experience with snapshots:
  • Windows "Restore Points"
  • Apple Time Machine "Restore"
  • Apple "Versions"
None of those technologies is a Copy-on-Write filesystem (such as Btrfs, ZFS, ReFS, and APFS). CoW snapshots really are as magical as I described. It would allow you to recover from a volume completely encrypted by ransomware in a matter of minutes. Your recovery point would depend on how often you take snapshots. You could theoretically take snapshots every second. But, for example, on the ZFS servers I used to administer it was more practical to take snapshots every hour.

Since APFS is a CoW filesystem, you can actually test this out yourself. Just take a manual snapshot of your volume (do a quick Google search for how to create a snapshot from the command-line). Then, do something catastrophic to your files, like delete everything in the Applications folder.

Then, reboot in Recovery Mode and choose "Restore from Time Machine Backup". You'll be given a list of available APFS snapshots on the volume (we're not using Time Machine, that's just where Apple makes the snapshots available in Recovery Mode). Revert to the snapshot you took. When you reboot, you'll find that everything on your volume is magically exactly the same as it was at the point in time when you took the snapshot.
 


None of those technologies is a Copy-on-Write filesystem (such as Btrfs, ZFS, ReFS, and APFS). CoW snapshots really are as magical as I described. It would allow you to recover from a volume completely encrypted by ransomware in a matter of minutes. Your recovery point would depend on how often you take snapshots. You could theoretically take snapshots every second. But, for example, on the ZFS servers I used to administer it was more practical to take snapshots every hour.

Since APFS is a CoW filesystem, you can actually test this out yourself. Just take a manual snapshot of your volume (do a quick Google search for how to create a snapshot from the command-line). Then, do something catastrophic to your files, like delete everything in the Applications folder.

Then, reboot in Recovery Mode and choose "Restore from Time Machine Backup". You'll be given a list of available APFS snapshots on the volume (we're not using Time Machine, that's just where Apple makes the snapshots available in Recovery Mode). Revert to the snapshot you took. When you reboot, you'll find that everything on your volume is magically exactly the same as it was at the point in time when you took the snapshot.
Todd, after reading the linked Wikipedia page, I will agree to the magical assessment. I find the explanation of CoW there to be confusing and contradictory when compared to your description here on MacInTouch, but your example of an intentional sabotage followed by a snapshot recovery seems worthy of testing. I might sleep better if it succeeds. Thanks.
 


I agree that snapshots are a fantastic technology, and ZFS allows you to replicate one server to another securely using snapshots. However, they are not completely foolproof, as once the recipient server starts to fill up, the oldest snapshot images (usually) start getting deleted.

Thus, unless the server you're backing up to is capable of holding several complete copies of the machine it is replicating from, the system may literally iterate / snapshot / backup its way out of a "working", i.e. non-corrupted, backup.

Some of the past ransomware takeovers did exactly that, wait until everything was encrypted, locally and 'abroad', before locking down the NAS.

That aside, the real question in my mind is how to deal with a system takeover in the first place. Todays malware / viruses / etc. are not like the primitive stuff I first encountered on a Mac SE. Between the BIOS, EFI, and all the other management chips with flash memories, etc., there is ample opportunity for stuff to stay behind where the OS can't find it, only to "own" the machine again later. (Never mind that the flash drive in most portables is now soldered in, i.e. not replaceable either.)

So, once malware is in the the system, would you ever trust it again? Barring a better technology, I air-gap my backups... Granted, there are risks with that approach also, but I'd rather lose a few days of data than the whole set.
 


There's a thorough discussion of APFS Snapshots here, from which I extract a warning pertinent to the direction this thread has taken:
Bombich said:
The Role of Snapshots in a Comprehensive Data Protection Strategy
If your startup disk fails, all the snapshots in the world aren't going to help you restore your startup disk and data. Having a bootable backup on an external disk will get you back to work immediately.
 



ICQ is still being updated by a Russian firm. [See ICQ on Wikipedia]. Along with others, I've written to the popular "Macupdate" site asking them not to post this application and to clear releases off with a warning about the very real probability you are compromised the second you initiate it.

What are others' thoughts about trying to get the word out about this 'product', once a pretty good chat program before it was acquired?
 


I've used both. I liked Hands Off and found it friendly, but I've been using Little Snitch lately. ... You can also try out Hands Off free of charge....
I decided to email One Periodic, the developers of Hands Off, to ask them some questions before considering a trial. I emailed their support address and received no reply – not even an automated reply that would expend no human effort. A week later, I figured that perhaps they didn't appreciate sales questions being emailed to the support department, so I forwarded it to their "info" address. Days later, still crickets. I understand if they are busy – just tell me and I would understand – even an auto-reply goes a long way towards customer relations.

So as I await a reply that may never come, and the lack of even a simple reply makes me question whether I personally want to give them my money in the event that a search of my email archives should reveal that I do not already hold a license, I figured I would ask... the MacInTouch community.

My questions were the following:
  1. Does Hands Off protect against connections before/during login?
  2. Does it include a throughput meter in the menu bar? This is a feature that I would want even if I didn't care about a firewall. I could find the answer to that question by installing a free trial, but I am hesitant to do so without first having the answer to question 1.
  3. Bonus question for MacInTouch: If the answer to question 2 is no, is there a good menu bar utility that can provide that information, with regard to throughput and direction of traffic?
Thank you, all!
 


Ric Ford

MacInTouch
Does it include a throughput meter in the menu bar? This is a feature that I would want even if I didn't care about a firewall.
I don't know about Hands Off (which I'm not currently running), but that's very definitely a feature provided by Little Snitch.

You could also take a look at the Vallum and Murus firewall siblings.
 


I recently installed an Eyez-On Envisalink EVL-4EZR on my home security system in place of the phone lines that were used for monitoring by the previous owner. I then connected the Envisalink to a small travel router via ethernet. The router is in client mode and connected to my guest WiFi network (provided by Apple AirPort routers). I created an account on the Eyes-ON web site and can monitor the security system from there or on a companion iPhone app.

However, I am puzzled how the Eyez-ON apps are able to communicate with the Envisalink. I did not implement port forwarding on the AirPort. My Eyez-ON account password is pretty secure (I think), but the password to login to the Envisalink device directly is only six characters (and the default login password was "user" and there is no login name).

How vulnerable is this setup? Can I do more to secure the system? The apps know the WAN and LAN IP numbers, as they are listed on the status page. I am concerned I am getting protection from one kind of threat (burglars) but am now susceptible to another (hackers).
 


So, just found out a family member installed something called "Netflix party extension" on their computer ,,, um with my account 8-\

Anybody heard of this app? It seems to have big name corporate news agency coverage but does not appear to be a Netflix sponsored piece of software.

I am advising said family member to uninstall, or at the very least run this sort of thing on a user account not used for personal business that should remain secure.

My concerns still lie with the notion that these extensiond (apps?) are engineered to have full access to all data transferred through a browser, not just generic data like browsing history and the like, but all activity in the browser including transmission of passwords ... I have no idea whether a browser's encryption protocol protects this data... I assume not, as keystrokes are keystrokes.

Advice would be appreciated
 


So, just found out a family member installed something called "Netflix party extension" on their computer ,,, um with my account 8-\
Anybody heard of this app? It seems to have big name corporate news agency coverage but does not appear to be a Netflix sponsored piece of software.
I am advising said family member to uninstall, or at the very least run this sort of thing on a user account not used for personal business that should remain secure.

My concerns still lie with the notion that these extensiond (apps?) are engineered to have full access to all data transferred through a browser, not just generic data like browsing history and the like, but all activity in the browser including transmission of passwords ... I have no idea whether a browser's encryption protocol protects this data... I assume not, as keystrokes are keystrokes.
Advice would be appreciated
Yes. There was recently an article about this:
CNN said:
 


Two followups:

It does not appear to be a Netflix-sponsored app.

Does it make sense to utilize this extension in a user account dedicated for installs like this, separate from your more important account and important navigational activities ... or am I being overly concerned?
 


Two followups:
  • It does not appear to be a Netflix-sponsored app.
  • Does it make sense to utilize this extension in a user account dedicated for installs like this, separate from your more important account and important navigational activities ... or am I being overly concerned?
Up to you. If you give/gave the other person your credentials?
 


Up to you. If you give/gave the other person your credentials?
Right, the account credentials not so much at issue, permission granted (no credit card on file in the account) ,with the exception of the particular issue of using browser extensions. I would have preferred prior knowledge of that, and would have advised other options. Like advising... "Perhaps, it's time for you to get your own account." ;-)
 


MacWorld.com has been automatically redirecting to suspicious sites (“Adobe” updates, etc.) since last night. Don’t really know how to safely contact them.
 


Ric Ford

MacInTouch
MacWorld.com has been automatically redirecting to suspicious sites (“Adobe” updates, etc.) since last night. Don’t really know how to safely contact them.
It may be your own system that's infected rather than macworld.com. A few quick checks here didn't turn up an obvious problem with macworld.com, but I also have extra security mechanisms in place.

Unfortunately, I wasn't able to quickly find a security contact and didn't have any luck trying the security.txt mechanism.

Macworld.com is hosted by Fastly.

Netcraft site report:
Securi site check:

Domain registration:
[server: whois.verisign-grs.com]
Domain Name: MACWORLD.COM
Registry Domain ID: 681577_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: MarkMonitor - Clarivate Analytics | Brand Protection, Domain Management, Anti Piracy, Anti Fraud
Updated Date: 2019-10-22T09:03:21Z
Creation Date: 1997-11-24T05:00:00Z
Registry Expiry Date: 2020-11-23T05:00:00Z
Registrar: MarkMonitor Inc.
Registrar IANA ID: 292
Registrar Abuse Contact Email: abusecomplaints@markmonitor.com
Registrar Abuse Contact Phone: +1.2083895740
Domain Status: clientDeleteProhibited EPP Status Codes | What Do They Mean, and Why Should I Know? - ICANN
Domain Status: clientTransferProhibited EPP Status Codes | What Do They Mean, and Why Should I Know? - ICANN
Domain Status: clientUpdateProhibited EPP Status Codes | What Do They Mean, and Why Should I Know? - ICANN
Name Server: NS-A.PNAP.NET
Name Server: NS-B.PNAP.NET
Name Server: NS-C.PNAP.NET
Name Server: NS-D.PNAP.NET
Name Server: NS0.PCWORLD.COM
Name Server: NS1.PCWORLD.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: Whois Inaccuracy Complaint Form | ICANN
>>> Last update of whois database: 2020-04-07T17:54:56Z <<<
 


It may be your own system that's infected rather than macworld.com....
I’m afraid you could be right, Ric. No else seems to be having this problem. Both my iPad and Mac Pro are, but only at MacWorld? I thought it might be my local DNS server, so switched to Comcast’s, but it's still redirecting MacWorld.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts