On a Mac, apps you download—whether from the Mac App Store or from the web—are signed with a developer certificate. Whenever you launch an app, it checks the app to verify that it was signed by a legitimate developer and that it hasn’t been tampered with. This helps protect you from malware.

For example, when Mozilla creates Firefox, it compiles a Firefox application file and then signs it with Mozilla’s developer certificate. This is Mozilla’s way of proving that the file is legitimate and created by Mozilla. If the application file is tampered with afterward, your Mac will notice the difference.

These certificates are only valid for a certain interval of time—perhaps a few years—but they can be “revoked” early. For example, if Apple discovers that a developer is using its certificate to sign malicious apps, Apple then revokes the certificate. Macs won’t load apps with that revoked certificate.

OCSP Explained: Why Does Your Mac Phone Home?

But wait—how does your Mac know if Apple has revoked a certificate associated with an app on your Mac? To check, your Mac uses something called the Online Certificate Status Protocol, or OCSP; it’s also used by web browsers to check website certificates as you browse.

When you launch an app, your Mac sends information about its certificate to an Apple server at ocsp.apple.com. Your Mac asks this Apple server whether the certificate has been revoked. If it hasn’t, your Mac launches the app. If the certificate has been revoked, your Mac won’t launch the app.

Does This Happen Every Time You Launch an App?

Your Mac remembers these responses for a period of time. On November 12, 2020, responses were cached for five minutes; in other words, if you launched an app, closed it, and launched it again four minutes later, your Mac wouldn’t have to ask Apple about the certificate a second time. However, if you launched an app, closed it, and launched it six minutes later, your Mac would have to ask Apple’s servers again.

For whatever reason—perhaps due to changes in macOS Big Sur—Apple’s server was swamped and became very slow on November 12, 2020. Responses slowed down considerably, and apps took a long time to load as Macs patiently waited for a response from Apple’s slow server.

After that event, Apple’s OSCP server now tells Macs to remember certificate validity responses for 12 hours. Your Mac will phone home and ask about a certificate every time you launch an app—unless you’ve received a response in the last 12 hours, in which case it won’t need to. (The information about time periods here comes from independent app developer Jeff Johnson.)

What If a Mac Is Offline?

The OCSP check is designed to fail with grace. If you’re offline, your Mac will silently skip the check and launch apps normally.

The same is true if your Mac can’t reach the ocsp.apple.com server—perhaps because the server address has been blocked on your network at the router level. If your Mac can’t contact the server, it skips the check and immediately launches the app. The problem on November 12, 2020 was that while Macs could reach Apple’s server, the server itself was slow. But rather than silently failing and getting on with launching an app, Macs waited a long time for a response. If the server had been down completely, no one would have noticed.

What’s the Privacy Risk? What Does Apple Learn?

There are several privacy concerns people have brought up here. They are spelled out in hacker and security researcher Jeffrey Paul’s blistering take on the situation.

• Certificates Are Associated With Apps: When your Mac contacts the OCSP server, it asks about a certificate that’s likely associated with one app—or, perhaps, a handful of apps. Technically, your Mac does not tell Apple which app you’ve launched. For example, if you launch Firefox, Apple just learns that you’ve launched an app created by Mozilla. It could be Firefox or Thunderbird, but Apple doesn’t know which. However, if you launch an app signed by the Tor Project, Apple can get a pretty good idea that you’ve opened the Tor Browser.
• Requests Are Associated With IP Addresses and Times: These requests can, of course, be associated with a date and time and your IP address. That’s just how the internet works. Your IP address is associated with a certain city and state. Each OCSP request tells Apple the developer that created the app you’re launching, your general location, and the date and time on which you launched the app.
• Lack of Encryption Means Snooping Is Possible: The OCSP protocol is unencrypted. Not only does Apple get this information—anyone in the middle can also see this information. Your internet service provider, workplace network administrator, or even a spy agency monitoring internet traffic could eavesdrop on the OSCP traffic between you and Apple and learn all these details. These requests also go through a third-party content distribution network (CDN) named Akamai. This speeds them up—but adds another middleman that could technically snoop.

Info: Your Mac isn’t telling Apple which app you’re launching. Instead, your Mac is just telling Apple which developer created the app you’re launching. Of course, many developers just create one app. This technical distinction often doesn’t mean much.

(Remember: With the change to caching behavior, your Mac is no longer asking Apple every time you launch an app. It’s only doing this every 12 hours instead of every 5 minutes.)

Why Is Your Mac Doing This?

As you might expect, this is all about security. The Mac is a more open platform than the iPad and iPhone. You can download apps from anywhere, even outside of Apple’s Mac App Store.

To protect the Mac from malware—and yes, Mac malware has become more common—Apple implemented this security check. If a certificate used to sign an app is revoked, your Mac can immediately spring into action and refuse to open that app. This gives Apple the power to stop Macs from launching known-malicious apps.

Can You Block the OCSP Checks?

These OCSP checks are designed to quickly and silently fail when a Mac is either offline or can’t contact the ocsp.apple.com server. That makes them simple to block: Just prevent your Mac from connecting to ocsp.apple.com. For example, you can often block this address on your router, preventing all devices on your network from connecting to it.

Unfortunately, it seems like Big Sur no longer lets software-level firewalls on the Mac block the Mac’s built-in trustd process from accessing remote servers like this.

Warning: If you block the ocsp.apple.com server, your Mac won’t notice when Apple has revoked an app’s developer certificate. You’re choosing to disable a security feature and this could put your Mac at risk.

Apple appears to have heard the criticism. On November 16, 2020, the company added information about “privacy protections” for Gatekeeper on its website. First, Apple says it has never combined data from these certificate or malware checks with any other data Apple knows about you. The company promises it doesn’t use this information to track which apps individuals are launching on their Macs.

Second, Apple insists that these certificate checks are not associated with your Apple ID or any device-specific information beyond your IP address. Apple says it has stopped logging IP addresses associated with these requests and will be removing them from Apple’s logs.

Over the next year—in other words, by the end of 2021—-Apple says it will make these changes:

• Replace OCSP With an Encrypted Protocol: Apple says it will create a new encrypted protocol to replace the unencrypted OCSP system for checking developer certificates. This will prevent anyone in the middle from snooping.
• Stop the Slowdowns: Apple also promises “strong protections against server failure”—in other words, apps won’t be slow to load because a server slowed down again.
• Provide Choice to Users: Apple says Mac users will be able to turn these security protections off and prevent their Mac from checking for revoked developer certificates.

Overall, these changes will eliminate various problems—third parties can no longer snoop in the middle. Macs will still send Apple information it can use to track which apps you open, but Apple promises not to associate that information with you. Slowdowns should be eliminated as Apple fixes the performance problem, too.

What will this better protocol be? Well, Apple hasn’t yet said what it will replace OCSP with. As security researcher Scott Helme notes, something like CRLite could help thread the needle here. Imagine if your Mac could download a single file from Apple and regularly update it. The file would contain a compressed list of all certificate revocations. Whenever you launch an app, your Mac could check the file, eliminating the network checks and privacy problems.

Your Mac Does Sometimes Send App Hashes to Apple

By the way, your Mac does sometimes send hashes of the apps you open to Apple’s servers. This is different from the OCSP signature checks. Instead, it has to do with Gatekeeper notarization.

Developers can upload apps to Apple, which checks them for malware and then “notarizes” them if they seem safe. This notarization ticket information can be “stapled” to the app. If a developer doesn’t staple the ticket information to the app file, your Mac will check with Apple’s servers the first time you launch that app. This only happens the first time you launch a given version of an app—not every time it opens. And the online check can be eliminated by the developer through stapling.

Macs aren’t unique here. For example, Windows 10 PCs often upload data about apps you download to Microsoft’s SmartScreen service to check for malware. Antivirus programs and other security applications may upload information about suspicious-looking apps to the security company, too.

[mai mult...]

If you use Safari on Mac and would like to quickly clear your browser history without digging through menus, you can take care of it with a keyboard shortcut and a click by creating a custom shortcut in System Preferences. Here’s how.

First, we’ll need to visit “System Preferences” to create the custom keyboard shortcut. On your Mac, click the “Apple” icon in the upper-left corner and select “System Preferences.”

In “System Preferences,” select “Keyboard.” In “Keyboard” preferences, click the “Shortcuts” tab.

In the sidebar menu, click “App Shortcuts.”

Click the plus sign (+) located near the bottom of the window to add a new shortcut.

A pop-up window will appear. First, click the drop-down menu labeled “Application” and select “Safari.app.”

In the “Menu Title” text box, enter “Clear History...” exactly. It must include the three dots at the end, as it must match the existing menu command in Safari under the “History” menu. Next, select the “Keyboard Shortcut” box and type the shortcut you want to use to clear Safari’s browser history. We chose Shift+Command+H, but you can enter any unused keyboard combination.

Then click the “Add” button, and the shortcut will be added to the list. You’re now clear to close System Preferences (unless you want to tweak the keyboard shortcut key combination after testing it out.)

Open “Safari” and press the keyboard shortcut you just defined. A small pop-over window will appear with a drop-down menu and two buttons. In the “Clear” menu, you can choose how much of your history is cleared. When you’re ready, click the “Clear History” button.

Your Safari browsing history will be cleared to whatever level you selected. Safari will remember the setting you chose in the “Clear” menu, so next time you call up the window with your custom shortcut, you can just click the “Clear History” button.

If you find yourself frequently clearing your browser history, consider trying Safari’s Private Browsing mode, which is a special mode that doesn’t keep track of your browsing history. You can even configure Safari to start with a Private window every time you open the app.

[mai mult...]

Port knocking is a way to secure a server by closing firewall ports—even those you know will be used. Those ports are opened on demand if—and only if—the connection request provides the secret knock.

In the 1920s, when prohibition was in full swing, if you wanted to get into a speakeasy, you had to know the secret knock and tap it out correctly to get inside.

Port knocking is a modern equivalent. If you want people to have access to services on your computer but don’t want to open your firewall to the internet, you can use port knocking. It allows you to close the ports on your firewall that allow incoming connections and have them open automatically when a prearranged pattern of connection attempts is made. The sequence of connection attempts acts as the secret knock. Another secret knock closes the port.

Port knocking is something of a novelty, but it’s important to know it’s an example of security through obscurity, and that concept is fundamentally flawed. The secret of how to access a system is safe because only those in a specific group know it. But once that secret is out—either because it’s revealed, observed, guessed, or worked out—your security is void. You’re better off securing your server in other, stronger ways, like requiring key-based logins for an SSH server.

The most robust approaches to cybersecurity are multilayered, so, perhaps port knocking should be one of those layers. The more layers, the better, right? However, you could argue that port knocking doesn’t add much (if anything) to a properly hardened, secure system.

Cybersecurity is a vast and complicated topic, but you shouldn’t use port knocking as your only form of defense.

Installing knockd

To demonstrate port knocking, we’re going to use it to control port 22, which is the SSH port. We’ll use a tool called knockd. Use apt-get to install this package onto your system if you use Ubuntu or another Debian-based distribution. On other Linux distributions, use your Linux distribution’s package management tool, instead.

Type the following:

sudo apt-get install knockd

You probably already have the iptables firewall installed on your system, but you might need to install the iptables-persistent package. It handles the automatic loading of saved iptable rules.

Type the following to install it:

sudo apt-get install iptables-persistent

When the IPV4 configuration screen appears, press the space bar to accept the “Yes” option.

Press the space bar again in IPv6 configuration screen to accept the “Yes” option and move on.

The following command tells iptables to allow established and ongoing connections to continue. We’ll now issue another command to close the SSH port.

If someone is connected by SSH when we issue this command, we don’t want them to be cut off:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

This command adds a rule to the firewall, that says:

• -A: Append the rule to the firewall rules table. That is, add it to the bottom.
• INPUT: This is a rule about incoming connections.
• -m conntrack: Firewall rules act upon network traffic (packets) that match criteria in the rule. The -m parameter causes iptables to use extra packet matching modules—in this case, the one called conntrack works with the network connection tracking capabilities of the kernel.
• –cstate ESTABLISHED,RELATED: This specifies the type of connection to which the rule will apply, namely ESTABLISHED and RELATED connections. An established connection is one that’s already in progress. A related connection is one that’s made due to an action from an established connection. Perhaps someone who is connected wants to download a file; that might happen over a new connection initiated by the host.
• -j ACCEPT: If the traffic matches the rule, jump to the ACCEPT target in the firewall. In other words, the traffic is accepted and allowed to pass through the firewall.

Now we can issue the command to close the port:

sudo iptables -A INPUT -p tcp --dport 22 -j REJECT

This command adds a rule to the firewall, that says:

• -A: Append the rule to the firewall rules table, i.e., add it to the bottom.
• INPUT: This rule is about incoming connections.
• -p tcp: This rule applies to traffic that uses the Transmission Control Protocol.
• –dport 22: This rule specifically applies to TCP traffic that targets port 22 (the SSH port).
• -j REJECT: If the traffic matches the rule, jump to the REJECT target in the firewall. So, if the traffic is rejected, it’s not permitted through the firewall.

We must start the netfilter-persistent daemon. We can do so with this command:

sudo systemctl start netfilter-persistent

We want netfilter-persistent to go through a save and reload cycle, so it loads and controls the iptable rules.

Type the following commands:

sudo netfilter-persistent save

sudo netfilter-persistent reload

You’ve now installed the utilities, and the SSH port is closed (hopefully, without terminating anyone’s connection). Now, it’s time to configure the secret knock.

Configuring knockd

There are two files you edit to configure knockd. The first is the following knockd configuration file:

sudo gedit /etc/knockd.conf

The gedit editor opens with the knockd configuration file loaded.

We’ll edit this file to suit our needs. The sections we’re interested in are “openSSH” and “closeSSH.” The following four entries are in each section:

• sequence: The sequence of ports someone must access to open or close port 22. The default ports are 7000, 8000, and 9000 to open it, and 9000, 8000, and 7000 to close it. You can change these or add more ports to the list. For our purposes, we’ll stick with the defaults.
• seq_timeout: The time period within which someone has to access the ports to trigger it to open or close.
• command: The command sent to the iptables firewall when the open or close action is triggered. These commands either add a rule to the firewall (to open the port) or take it out (to close the port).
• tcpflags: The type of packet each port must receive in the secret sequence. A SYN (synchronize) packet is the first in a TCP connection request, called a three-way handshake.

The “openSSH” section can be read as “a TCP connection request must be made to ports 7000, 8000, and 9000—in that order and within 5 seconds—for the command to open port 22 to be sent to the firewall.”

The “closeSSH” section can be read as “a TCP connection request must be made to ports 9000, 8000, and 7000—in that order and within 5 seconds—for the command to close port 22 to be sent to the firewall.”

The Firewall Rules

The “command” entries in the openSSH and closeSSH sections remain the same, except for one parameter. This is how they’re comprised:

• -A: Append the rule to the bottom of the firewall rules list (for the openSSH command).
• -D: Delete the command from the firewall rules list (for the closeSSH command).
• INPUT: This rule is concerned with incoming network traffic.
• -s %IP%: The IP address of the device requesting a connection.
• -p: Network protocol; in this case, it’s TCP.
• –dport: The destination port; in our example, it’s port 22.
• -j ACCEPT: Jump to the accept target within the firewall. In other words, let the packet drop through the rest of the rules without acting on it.

The knockd Configuration File Edits

The edits we’ll make to the file are highlighted in red below:

We extend the “seq_timeout” to 15 seconds. This is generous, but if someone’s manually firing in connection requests, he might need this much time.

In the “openSSH” section, we change the -A (append) option in the command to -I (insert). This command inserts a new firewall rule at the top of the firewall rule list. If you leave the -A option, it appends the firewall rule list and puts it at the bottom.

Incoming traffic is tested against each firewall rule in the list from the top down. We already have a rule that closes port 22. So, if incoming traffic is tested against that rule before it sees the rule that allows the traffic, the connection is refused; if it sees this new rule first, the connection is allowed.

The close command removes the rule added by openSSH from the firewall rules. SSH traffic is once more handled by the pre-existing “port 22 is closed” rule.

After you make these edits, save the configuration file.

The knockd Control File Edits

The knockd control file is altogether simpler. Before we dive in and edit that, though, we need to know the internal name for our network connection; to find it, type this command:

ip addr

The connection this machine uses to research this article is called enp0s3. Make a note of the name of your connection.

The following command edits the knockd control file:

sudo gedit /etc/default/knockd

Here’s the knockd file in gedit.

The few edits we need to make are highlighted in red:

We changed the “START_KNOCKD=” entry to from 0 to 1.

We also removed the hash # from the start of the “KNOCKD_OPTS=” entry, and replaced “eth1” with the name of our network connection, enp0s3. Of course, if your network connection is eth1, you won’t change it.

The Proof Is in the Pudding

It’s time to see if this works. We’ll start the knockd daemon with this command:

sudo systemctrl start knockd

Now, we’ll jump on another machine and try to connect. We installed the knockd tool on that computer, too, not because we want to set up port knocking, but because the knockd package provides another tool called knock. We’ll use this machine to fire in our secret sequence and do the knocking for us.

Use the following command to send your secret sequence of connection requests to the ports on the port knocking host computer with the IP address 192.168.4.24:

knock 192.168.4.24 7000 8000 9000 -d 500

This tells knock to target the computer at IP address 192.168.4.24 and fire a connection request to ports 7000, 8000, and 9000, in turn, with a -d (delay) of 500 milliseconds between them.

A user called “dave” then makes an SSH request to 192.168.4.24:

ssh dave@192.168.4.24

His connection is accepted, he enters his password, and his remote session begins. His command prompt changes from dave@nostromo to dave@howtogeek. To log out of the remote computer, he types:

exit

His command prompt returns to his local computer. He uses knock once more, and this time, it targets the ports in reverse order to close the SSH port on the remote computer.

knock 192.168.4.24 9000 8000 7000 -d 500

Admittedly, this wasn’t a particularly fruitful remote session, but it demonstrates the opening and closing of the port via port knocking and fits in a single screenshot.

So, what did this look like from the other side? The system administrator on the port knocking host uses the following command to view new entries that arrive in the system log:

tail -f /var/log/syslog

• You see three openSSH entries. These are raised as each port is targeted by the remote knock utility.
• When all three stages of the trigger sequence are met, an entry that says “OPEN SESAME,” is logged
• The command to insert the rule into the iptables rules list is sent. It permits access via SSH on port 22 from the specific IP address of the PC that gave the correct secret knock (192.168.4.23).
• The user “dave” connects for a few seconds only, and then disconnects.
• You see three closeSSH entries. These are raised as each port is targeted by the remote knock utility—it tells the port knocking host to close port 22.
• After all three stages are triggered, we get the “OPEN SESAME” message again. The command is sent to the firewall to remove the rule. (Why not “CLOSE SESAME” when it’s closing the port? Who knows?)

Now the only rule in the iptables rules list regarding port 22 is the one we typed at the beginning to close that port. So, port 22 is now closed again.

[mai mult...]