Download the Mac client msi file to a Windows system; Run the msi and it will create a dmg file under the default location “C: Program Files Microsoft System Center Configuration Manager for Mac client ” on the Windows system; Copy the dmg file to a network share or a folder on a Mac computer. Network setup for Mac OS X. Last revision September 19, 2012. TCP/IP Configuration TCP/IP is the network protocol used on the Internet for email, web, file sharing, and other services. The default TCP/IP configuration in Mac OS X works correctly with Stanford's network self-registration system.

Starting from version 10.7 (Lion), Mac OS X includes 2 firewalls: PF & Application Firewall. Both are disabled by default.

PF

System configuration for mac os x 10.7

Mac OS X 10.6 (and earlier) came with IPFW, a port of FreeBSD’s stateful firewall. IPFW was deprecated in OS X 10.7, and was completely removed in OS X 10.10; it was replaced with PF. PF (Packet Filter) is OpenBSD’s system for filtering TCP/IP traffic and doing Network Address Translation. PF in OS X, however, appears to be based on the FreeBSD port of PF. Like FreeBSD 9.X and later, OS X appears to use the same version of PF as OpenBSD 4.5.

The latest OpenBSD version is 5.6 (as of January 2015); and the configuration syntax for PF changed around 4.6/4.7.

Apple has enhanced PF so that various system components might choose to enable and disable PF, as indicated by the following snippet in /etc/pf.conf:

These two flags, -E and -X, are absent from pfctl on other BSDs. Here’s how they are documented in pfctl(8):

The main PF configuration file is /etc/pf.conf, which defines the following main ruleset by default in OS X 10.9 & 10.10:

The main ruleset loads sub rulesets defined in /etc/pf.anchors/com.apple, using anchor:

The launchd configuration file for PF is /System/Library/LaunchDaemons/com.apple.pfctl.plist. PF is disabled by default:

Application Firewall

OS X v10.5.1 and later include Application Firewall that allow the users to control connections on a per-application basis (rather than a per-port basis). Application Firewall is disabled by default.

System Configuration For Mac Os X

After enabling the Application Firewall (System Preferences -> Security & Privacy -> Firewall -> Turn On Firewall), you’ll find PF is enabled too:

Apparently Application Firewall enables PF using pfctl -E. In addition to its own rules, Application Firewall generates a set of dynamic rules (sub ruleset) for PF through anchor point com.apple/250.ApplicationFirewall. At this stage, the sub ruleset is empty, which got someone really confused.

But if either “Enable stealth mode” or “Block all incoming connections” is checked in Firewall Options..., dynamic rules for PF will indeed be created:

Note there is a bug in Apple’s implementation of PF! According to pfctl(8):

If the anchor name is terminated with a ‘*’ character, the -s flag will recursively print all anchors in a brace delimited block.

But it produces an error instead:

We have to use the full anchor path:

As you can see, a set of dynamic PF rules is created for AirDrop too. I surmise they are still created by Application Firewall, because according to the output of pfctl -s References, PF has only been enabled once, by Application Firewall.

Besides using the Security & Privacy Preference pane, you can also configure the Application Firewall from the command line. The utilities for Application Firewall are located at /usr/libexec/ApplicationFirewall. The default configuration file is /usr/libexec/ApplicationFirewall/com.apple.alf.plist; and the running configuration file is /Library/Preferences/com.apple.alf.plist.

Stopping and starting Application Firewall is easy enough, using launchd. To stop:

To start:

We can configure the settings of Application Firewall using socketfilterfw:

pflog

Logging support for PF is provided by pflog. The pflog interface is a pseudo-device which makes visible all packets logged by PF. Logged packets can easily be monitored in real time by invoking tcpdump on the pflog interface.

Create a pflog interface:

Monitor all packets logged by PF:

Destroy the pflog interface when you are done with it:

Precedence

If two firewalls, Application Firewall & PF, are both running, you may wonder whose rules take precedence. Let’s find out.

The logs of Application Firewall are saved in /var/log/appfirewall.log. You’ll see a lot entries like the following, repeating roughly 2 times per minute on my iMac:

Add the following as the first rule of /etc/pf.conf:

Add the following 3 lines to /etc/pf.conf (to block incoming traffic but allow outgoing traffic):

The first rule is to allow incoming Bonjour traffic. In a hostile environment, e.g., a public WiFi, we’ll put the above 3 lines at the end of the file to block all incoming traffic, in which case, the sub rulesets in anchor “com.apple” will have no effect!

For each packet or connection evaluated by PF, the last matching rule in the ruleset is the one which is applied.

In work environment, you can put the 3 lines right above the line:

Reload /etc/pf.conf:

Show the currently loaded filter rules:

Check /var/log/appfirewall.log again. You’ll find no new log entry for Application Firewall appears in the file.

So one can conclude that PF rules are applied first, then the rules for Application Firewall.

SSH

To enable OpenSSH server on OS X, in the Sharing Preference pane of System Preferences, check “Remote Login”. Or from the command line:

launchctl(1) says such about the -w flag:

-w Overrides the Disabled key and sets it to false. In previous versions, this option would modify the configuration file. Now the state of the Disabled key is stored elsewhere on-disk.

but where exactly is the ‘elsewhere’? After some digging, I find it is /private/var/db/launchd.db/com.apple.launchd/overrides.plist.

However, I don’t like the default configuration for sshd. I prefer to have password authentication disabled. Add the following options to /etc/ssh/sshd_config:

Restart sshd:

Note to allow incoming traffics to the OpenSSH server through Application Firewall, you must allow incoming connections for /usr/libexec/sshd-keygen-wrapper, either in System Preferences -> Security & Privacy -> Firewall -> Firewall Options..., or from the command line:

Configuring PF

The Application Firewall’s rule of allowing all incoming incoming traffics to the OpenSSH server offers no defense against brute force attack. Leaving the ssh port open on the internet, the server will get thousands of brute force login attempts each day. PF provides an elegant solution to this problem.

Append the following lines to /etc/pf.conf (see Section 30.3.3.5 - Using Overload Tables to Protect SSH of FreeBSD Handbook for an explanation):

System Configuration For Mac Os X 10.10

Reload /etc/pf.conf:

Over time, the table bruteforce will be filled by overload rules and its size will grow incrementally, taking up more memory. We can expire table entries using pfctl. For example, this command will remove bruteforce table entries which have not been referenced for a day (86400 seconds):

To automate the process, let’s create a timed job using launchd that runs the above command once per day (see Timed Jobs Using launchd).

System Configuration For Mac Os X

Os Configuration Management

Create a launchd configuration file /Library/LaunchDaemons/edu.ucsc.manjusri.pfctl-expire.plist, with the following content:

Start the timed job:

P.S. There are a few articles on the Internet on using PF on Mac OS X, but they often bypass the configuration file /etc/pf.conf (e.g. , Using pf on OS X Mountain Lion). If one takes that route, one must disable the Application Firewall. Otherwise Application Firewall will enable PF using the ruleset in /etc/pf.conf. Only one ruleset will get loaded at last and become effective; but which one wins will probably be indeterministic or at least could be a surprise. I choose the approach described in this article, because:

  1. I always like to try something different
  2. I prefer layered defense. In this case, I have 2 firewalls running on the Mac.

Important:This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid.

The following sections discuss the file systems supported by OS X and the impact they can have on application performance.

Supported File Systems

OS X supports a variety of file systems and volume formats, including those listed in Table 1. Although the primary volume format is HFS Plus, OS X can also boot from a disk formatted with the UFS file system. Future versions of OS X may be bootable with other volume formats as well.

Table 1 File systems supported by OS X

File System

Description

HFS

Mac OS Standard file system. Standard Macintosh file system for older versions of Mac OS.

HFS Plus

Mac OS Extended file system. Standard Macintosh file system for OS X.

UFS

Unix File System. A variant of the BSD “Fast File System.”

WebDAV

Used for directly accessing files on the web. For example, iDisk uses WebDAV for accessing files.

UDF

Universal Disk Format. The standard file system for all forms of DVD media (video, ROM, RAM and RW) and some writable CD formats.

FAT

The MS-DOS file system, with 16- and 32-bit variants.

SMB/CIFS

Used for sharing files with Microsoft Windows SMB file servers.

AFP

AppleTalk Filing Protocol. The primary network file system for all versions of Mac OS.

NFS

Network File System. A commonly-used BSD file sharing standard. OS X supports NFSv2 and NFSv3 over TCP and UDP.

FTP

A file system wrapper for the standard Internet File Transfer Protocol.

System Configuration For Mac Os X

Accessing File-System Data

Windows Os Configuration

Every file system stores metadata about the files in the file system. This metadata describes the file but is not part of the file itself. The metadata for a file can include attributes such as Mac OS file type information, BSD-style file access permissions, and creation and modification dates. Because of the differences in how file systems store this data, accessing metadata can be a potentially expensive operation on some file systems.

It’s important to realize that if a piece of data is not immediately present in the file system, that information might have to be calculated. Retrieving file-system information is a time-consuming operation as it is, but if the information must be calculated or read separately from disk, it becomes even more time-consuming. The valence of a directory—the number of items in that directory—is a typical example of information that must be calculated on most file systems.

When calling file-system routines, you should always carefully consider what information you actually need and request only that information. For example, a single call to PBGetCatInfoSync returns Finder file type information from a file or folder. On HFS and HFS Plus file systems, the penalty for retrieving this metadata is minimal because it is stored in the file’s catalog node and read into memory along with the file name. However, on other file systems, this data may have to be read separately, incurring another read operation. Instead of PBGetCatInfoSync, you should have used FSGetCatalogInfo or PBGetCatalogInfoSync and specified exactly which pieces of information you wanted.



Copyright © 2003, 2014 Apple Inc. All Rights Reserved. Terms of Use Privacy Policy Updated: 2014-03-10