krypted.com

Tiny Deathstars of Foulness

The tools to automate OS X firewall events from the command line are still stored in /usr/libexec/ApplicationFirewall. And you will still use socketfilterfw there for much of the heavy lifting. However, now there are much more helpful and functional options in socketfilterfw that will allow you to more easily script the firewall.

Some tricks I’ve picked up with the Mac Firewall/alf scripting:

  • Configure the firewall fully before turning it on (especially if you’re doing so through something like Casper, FileWave, Munki, or Absolute Manage where you might kick yourself out of your session otherwise).
  • Whatever you do, you can always reset things back to defaults by removing the com.apple.alf.plist file from /Library/Preferences replacing it with the default plist from /usr/libexec/ApplicationFirewall/com.apple.alf.plist.
  • Configure global settings, then per-application settings, then enable the firewall. If a remote system, do ;wait; and then enable the first time to make sure everything works before enabling the firewall for good.
  • To debug, use the following command: “/usr/libexec/ApplicationFirewall/socketfilterfw -d”

In /usr/libexec/ApplicationFirewall is the Firewall command, the binary of the actual application layer firewall and socketfilterfw, which configures the firewall. To configure the firewall to block all incoming traffic:

/usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on

To see if block all is enabled:

/usr/libexec/ApplicationFirewall/socketfilterfw --getblockall

The output would be as follows, if successful:

Firewall is set to block all non-essential incoming connections

A couple of global options that can be set. Stealth Mode:

/usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on

To check if stealth mode is enabled:

/usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode

Firewall logging:

/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on

You can also control the verbosity of logs, using throttled, brief or detail. For example, if you need to troubleshoot some issues, you might set the logging to detail using the following command:

/usr/libexec/ApplicationFirewall/socketfilterfw --setloggingopt: detail

To start the firewall:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

While it would be nice to think that that was going to be everything for everyone, it just so happens that some environments actually need to allow traffic. Therefore, traffic can be allowed per signed binary. To allow signed applications:

/usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned on

To check if you allow signed apps:

/usr/libexec/ApplicationFirewall/socketfilterfw --getallowsigned

This will allow all TRUSTEDAPPS. The –listapps option shows the status of each filtered application:

/usr/libexec/ApplicationFirewall/socketfilterfw --listapps

To check if an app is blocked:

/usr/libexec/ApplicationFirewall/socketfilterfw –getappblocked /Applications/MyApp.app/Contents/MacOS/myapp

This shows the number of exceptions, explicitly allowed apps and signed exceptions as well as process names and allowed app statuses. There is also a list of TRUSTEDAPPS, which will initially be populated by Apple tools with sharing capabilities (e.g. httpd & smbd). If you are enabling the firewall using a script, first sign your applications that need to allow sharing but are not in the TRUSTEDAPPS section by using the -s option along with the application binary (not the .app bundle):

/usr/libexec/ApplicationFirewall/socketfilterfw -s /Applications/MyApp.app/Contents/MacOS/myapp

Once signed, verify the signature:

/usr/libexec/ApplicationFirewall/socketfilterfw -v /Applications/MyApp.app/Contents/MacOS/myapp

Once signed, trust the application using the –add option:

/usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/MyApp.app/Contents/MacOS/myapp

To see a list of trusted applications. You can do so by using the -l option as follows (the output is pretty ugly and needs to be parsed better):

/usr/libexec/ApplicationFirewall/socketfilterfw -l

If, in the course of your testing, you determine the firewall just isn’t for you, disable it:

/usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off

To sanity check whether it’s started:

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Or to manually stop it using launchctl (should start again with a reboot):

launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist

If you disable the firewalll using launchctl, you may need to restart services for them to work again.

July 16th, 2015

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , ,

After writing up the presentation for MacSysAdmin in Sweden, I decided to go ahead and throw these into a quick cheat sheet for anyone who’d like to have them all in one place. Good luck out there, and stay salty.

Get an ip address for en0:

ipconfig getifaddr en0

Same thing, but setting and echoing a variable:

ip=`ipconfig getifaddr en0` ; echo $ip

View the subnet mask of en0:

ipconfig getoption en0 subnet_mask

View the dns server for en0:

ipconfig getoption en0 domain_name_server

Get information about how en0 got its dhcp on:

ipconfig getpacket en1

View some network info:

ifconfig en0

Set en0 to have an ip address of 10.10.10.10 and a subnet mask of 255.255.255.0:

ifconfig en0 inet 10.10.10.10 netmask 255.255.255.0

Show a list of locations on the computer:

networksetup -listlocations

Obtain the active location the system is using:

networksetup -getcurrentlocation

Create a network location called Work and populate it with information from the active network connection:

networksetup -createlocation Work populate

Delete a network location called Work:

networksetup -deletelocation Work

Switch the active location to a location called Work:

networksetup -switchlocation Work

Switch the active location to a location called Work, but also show the GUID of that location so we can make scripties with it laters:

scselect Work

List all of the network interfaces on the system:

networksetup -listallnetworkservices

Rename the network service called Ethernet to the word Wired:

networksetup -renamenetworkservice Ethernet Wired

Disable a network interface:

networksetup -setnetworkserviceenabled off

Change the order of your network services:

networksetup -ordernetworkservices “Wi-Fi” “USB Ethernet”

Set the interface called Wi-Fi to obtain it if it isn’t already

networksetup -setdhcp Wi-Fi

Renew dhcp leases:

ipconfig set en1 BOOTP && ipconfig set en1 DHCP
ifconfig en1 down && ifconfig en1 up

Renew a dhcp lease in a script:

echo "add State:/Network/Interface/en0/RefreshConfiguration temporary" | sudo scutil

Configure a manual static ip address:

networksetup -setmanual Wi-Fi 10.0.0.2 255.255.255.0 10.0.0.1

Configure the dns servers for a given network interface:

networksetup -setdnsservers Wi-Fi 10.0.0.2 10.0.0.3

Obtain the dns servers used on the Wi-Fi interface:

networksetup -getdnsservers Wi-Fi

Stop the application layer firewall:

launchctl unload /System/Library/LaunchAgents/com.apple.alf.useragent.plist
launchctl unload /System/Library/LaunchDaemons/com.apple.alf.agent.plist

Start the application layer firewall:

launchctl load /System/Library/LaunchDaemons/com.apple.alf.agent.plist
launchctl load /System/Library/LaunchAgents/com.apple.alf.useragent.plist

Allow an app to communicate outside the system through the application layer firewall:

socketfilterfw -t
“/Applications/FileMaker Pro/FileMaker Pro.app/Contents/MacOS/FileMaker Pro”

See the routing table of a Mac:

netstat -nr

Add a route so that traffic for 10.0.0.0/32 communicates over the 10.0.9.2 network interface:

route -n add 10.0.0.0/32 10.0.9.2

Log bonjour traffic at the packet level:

sudo killall -USR2 mDNSResponder

Stop Bonjour:

launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist


Start Bojour:

launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Put a delay in your pings:

ping -i 5 192.168.210.1

Ping the hostname 5 times and then stop the ping:

ping -c 5 google.com

Flood ping the host:

ping -f localhost

Set the packet size during your ping:

ping -s 100 google.com

Customize the source IP during your ping:

ping -S 10.10.10.11 google.com

View disk performance:

iostat -d disk0

Get information about the airport connection on your system:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I

Scan the available Wireless networks:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s

Trace the path packets go through:

traceroute google.com

Trace the routes without looking up names:

traceroute -n google.com

Trace a route in debug mode:

traceroute -d google.com

View information on all sockets:

netstat -at

View network information for ipv6:

netstat -lt

View per protocol network statistics:

netstat -s

View the statistics for a specific network protocol:

netstat -p igmp

Show statistics for network interfaces:

netstat -i

View network information as it happens (requires ntop to be installed):

ntop

Scan port 80 of www.google.com

/System/Library/CoreServices/Applications/Network\ Utility.app/Contents/Resources/stroke www.google.com 80 80

Port scan krypted.com stealthily:

nmap -sS -O krypted.com/24

Establish a network connection with www.apple.com:

nc -v www.apple.com 80

Establish a network connection with gateway.push.apple.com over port 2195

/usr/bin/nc -v -w 15 gateway.push.apple.com 2195

Establish a network connection with feedback.push.apple.com only allowing ipv4

/usr/bin/nc -v -4 feedback.push.apple.com 2196

Setup a network listener on port 2196 for testing:

/usr/bin/nc -l 2196

Capture some packets:

tcpdump -nS

Capture all the packets:

tcpdump -nnvvXS

Capture the packets for a given port:

tcpdump -nnvvXs 548

Capture all the packets for a given port going to a given destination of 10.0.0.48:

tcpdump -nnvvXs 548 dst 10.0.0.48

Capture the packets as above but dump to a pcap file:

tcpdump -nnvvXs 548 dst 10.0.0.48 -w /tmp/myfile.pcap

Read tcpdump (cap) files and try to make them human readable:

tcpdump -qns 0 -A -r /var/tmp/capture.pcap

What binaries have what ports and in what states are those ports:

lsof -n -i4TCP

Make an alias for looking at what has a listener open, called ports:

alias ports='lsof -n -i4TCP | grep LISTEN'

Report back the name of the system:

hostname

Flush the dns cache:

dscacheutil -flushcache

Clear your arp cache:

arp -ad

View how the Server app interprets your network settings:

serveradmin settings network

Whitelist the ip address 10.10.10.2:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -w 10.10.10.2

Finally, the script network_info.sh shows information about a Macs network configuration. Both active and inactive network interfaces are listed, in the order that they are used by the OS and with a lot of details (MAC-address, interface name, router, subnet mask etc.).

September 25th, 2014

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Network Infrastructure

Tags: , , , , , , , , , , , , , , ,

Meraki has a syslog option. To configure a Meraki to push logs to a syslog server, open your Meraki Dashboard and click on a device. From there, click on “Alerts & administration”.

Screen Shot 2014-04-12 at 8.29.16 PM

At the “Alerts & administration” page scroll down to the Logging section. Click on the “Add a syslog server” link and type the IP address of your syslog servers name or IP. Put the port number into the Port field. Choose what types of events to export. This could be Event Log, Flows or URLs, where:

  • Event Log: The messages from the dashboard under Monitor > Event log.
  • Flows: Inbound and outbound traffic flows generate syslog messages that include the source and destination and port numbers.
  • URL: HTTP GET requests generate syslog entries.

Note that you can direct each type of traffic to a different syslog server.

April 16th, 2014

Posted In: cloud, Mac Security, Network Infrastructure

Tags: , , , , , , , , ,

Now that we’ve looked at what you get and what you don’t get in Mountain Lion Server, let’s take a little while to look at what the upgrade path itself looks like. Before we start, let’s just say that upgrading to Mountain Lion Server is probably one of the fastest, easiest and most boring upgrades you’ll ever get to do. And I say this more to the credit of the engineers that made the process so simple. Apparently there are bonuses to your Server just being an app. There is a catch, some of the services are gone. Another catch, you’re gonna’ need to have a system that meets the following specs:

  • Capable of booting a 64-bit kernel, means a 64-bit Intel Core 2 Duo or better
  • The graphics just keep getting better, so you’ll need an Advanced GPU chipset
  • The more memory the better, although 2GB is the bare minimum
  • The more CPU the better, although 8GB of space is required
  • An Internet connection, or a cached Install Mac OS X Mountain Lion, Server app and Server package – much easier to just have a connection to the Internet…
  • You should plan on using an Apple ID, although if you don’t supply it at install time, the server can still run
  • The source computer needs 10.6.8 or 10.7.x

Apple’s official specs are here, outlining the models that Mountain Lion can run on. If Mountain Lion can run, OS X Server can run on it. Next, make a clone of your computer. I use Carbon Copy Cloner, like most sane people, but YMMV with other tools that you may be in love with. Once your clone is done, I personally like to do both an archive and an export of user accounts from Workgroup Manager as a final safety net. You should also have a book. Preferably one of mine, although given that the merging of two such boring topics can create a black hole of boringness (which is similar to turning a bag of holding inside out, btw), you might choose to bring something a bit livelier than either of the two, like some Dostoyevsky or the Chem 111 textbook I used in college.

Next, let’s go to the App Store. Search for Mountain Lion or OS X and then click the Install button for the Mountain Lion app. The button will then say Downloading, as follows:

Buy OS X Mountain Lion from the App Store

Buy OS X Mountain Lion from the App Store

Once downloaded, make sure your users won’t chase after you with pitchforks for being down for a couple of hours and then run the installer, following the defaults until the download begins and the system reboots. The installation will take a little while. From the time you start the download to the time that the files are unpacked and replaced on the system can be about an hour or two. This is a good time to grab that book, a bag of Doritos and a Dr. Pepper. Once the Doritos are gone, wash your hands and check the progress of the installation. Read some more. Once that’s done, check the progress again. If you think about a second bag of Doritos, stop – it’s not worth it… A second Dr. Pepper is fine though, I hear it helps you write articles about upgrading to Mountain Lion Server in a way that makes optimal sense.

Once the system reboots again, you should be ready to open Server app. Except for the fact that it isn’t there, which is obvious by the fact that it’s got a big annoying white circle over it in the Dock. Remove the Server app (and Workgroup Manager or Server Admin if they’re in there) and then it’s time to install Server itself.

Go back to the App Store and search for & buy Mountain Lion Server (or install these from Purchases if you’ve already purchased them). Once installed, Server appears in the Dock. Use the following command to verify that the IP address and hostname match:

sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/changeip -checkhostname

Provided that the name of the server checks out clean, click on the Server app in the Dock to be guided through the installation process.

Set Up Your Server Screen When Installing Mountain Lion Server

Set Up Your Server Screen When Installing Mountain Lion Server

At the Setup Your Server screen, click on Continue.

Agree to the Mountain Lion Server Licensing Agreement

Agree to the Mountain Lion Server Licensing Agreement

Agree to the licensing terms (assuming you do agree) by clicking on the Agree button.

Provide Administrative Credentials When Installing Mountain Lion Server

Provide Administrative Credentials When Installing Mountain Lion Server

Provide the administrative username and password to give Server and services permission upon installation and then click on the Allow button.

Configure The AppleID for Push Notifications

Configure The AppleID for Push Notifications

At the Apple Push Notifications screen, provide the Apple ID and password for a valid Apple ID and then click on the Continue button.

Congrats, You're A SysAdmin!

Congrats, You’re A SysAdmin!

After a time, you should see a Congratulations screen. Click on Finish and the Server app should automatically open (or the process fails but Server opens anyway, just without some of the stuff working out of the gate).

At this point, you should see the services that were running prior to the upgrade running. Check the logs to verify that there’s nothing out of the ordinary. If you were running a firewall then the rules will be migrated and continue running. To disable if you’re going to move your rules to pf, then use the following command to disable the rules and reboot:

sudo mv /etc/ipfilter /etc/ipfilter.OLD

You don’t need to disable these immediately, although a lack of control over them might cause you to want to… Next, install Workgroup Manager, available at http://support.apple.com/kb/DL1567. You’ve now got a functional server, provided that the entire process went smoothly. In my experience so far (there hasn’t been a ton of this at this point), the service migration is far smoother than from within the Lion Server point releases (e.g. 10.7.2 to 10.7.3, etc). Profile Manager, for example, worked like a charm on upgrade, as did Calendar and Contacts services, which had been a bit persnickety at times previously.

Now, you can get back to that book and instead of a 3rd Dr. Pepper, switch to Jägermeister!

July 28th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , ,

Mountain Lion Server is now available on the OS X App Store and as with the last few updates there are some things missing that you might be expecting and depending on. First up, three major services are gone: Podcast Producer, RADIUS and dhcp. You can still do dhcp as you always did with OS X client as those features work on OS X Server, but the more granular controls available in OS X Server are now gone. The biggest impact of dhcp is probably in testing NetBoot services when there are network issues and you need to prove to network admins that it’s the network and not your server…

I had written an article before about FTP still being in OS X Server from the command line, but now it’s back in the GUI, which should make many an administrator happy. NAT is also gone from the GUI, but natd and natutil are still available from the command line. Might as well just use the Sharing System Preference pane for such things though… Server Admin is now gone (long live Server Admin!) and Workgroup Manager is now a download to be performed and installed following installation. Support for Managed Preferences is gone, even though most manifests technically still work.

Many services also got some pretty nice updates. These include:

  • Calendar – There are a few updates on the client side, but not on the server side. Most notably, the option to publish calendars is now gone. If you used that, it’s time to get used to manually exporting, copying to a share and then distributing links. This is going to likely cause more use of the Calendar server itself, to some degree. Also, it’s not iCal or iCal Server, it’s now Calendar and Calendar server. Seems to me that this isn’t obviously an Apple-centric naming structure as with most other things they do, but sometimes you’re gonna’ have that…
  • Contacts – Nope, it’s not called Address Book server, it’s the Contacts service. Same with the client side application.
  • DNS – DNS management is moved into the Server application. You can also now restrict who you do lookups for in the GUI. Under the hood very little changes.
  • File Sharing – Nothing really changes with file sharing, except the wiki integration described in the Wiki section in a little bit.
  • Firewall – The firewall option is gone, as is the ipfilter at the command line, but pf is easy to configure from the command line.
  • FTP – It’s a quick and easy single share solution from the GUI. Using the sharing command there’s still tons available to administrators.
  • Mail – Authentication mechanisms and domains are in the GUI, but very little changes otherwise.
  • Messages – The service name has changed from iChat to Messages in the GUI but is still jabber from the command line. The big change with this service is that the client side is now able to leverage iCloud to instant message mobile devices as well. Therefore, the text messaging component is client-side and has no impact on the jabber service itself.
  • NetInstall – The “NetInstall” service is NetBoot. It can host NetRestore or NetInstall images, but the heavy lifting for that stuff is done in System Image Utility. And the output of the SIU commands are now more scriptable through the automator command line interface. The NetInstall screen is now in Server app and is a good port from Server Admin in that it’s similar in look and feel to the NetBoot screen in Server Admin. A feature that isn’t in the GUI is diskless NetBoot, which is fine because I documented how to do it when I realized it would be an issue for a few customers.
  • Open Directory – Given that Server Admin is gone, something had to happen with Open Directory. The Open Directory screens have been moved to Server app where it’s fast to setup and tear down Open Directory. Open Directory based Users and Groups are also created through the Server App, although Workgroup Manager can be downloaded and used still. Immediately following upgrades, the add and remove users buttons are gone for previously stand-alone hosts. Also the Manage Network Accounts option is now gone from Server app, replaced with the traditional ON button supplied by Apple for other services.
  • Profile Manager – This deserves its own post, which is in the queue, but suffice it to say that while you can’t tell when looking in Server app, there are a number of upgrades to Profile Manager.
  • Software Update – Management of the service is moved from Server Admin to Server app. There are now fewer options in the GUI, but the same in the command line. Cascading is a little different.
  • Time Machine – Time Machine server is the same… The versions option from the Time Machine Server preference pane is gone and the layout is a little changed, but the server component is identical in functionality as well as look and feel.
  • VPN – Unless you add another supported VPN protocol there’s not much to do after fixing most issues in 10.7.4. Except fixing the last issue with search bases, seemingly resolved as it’s working for me pretty well.
  • Websites – There are more options in the GUI for new sites. The default site appears twice (once for 80 and once for 443), but there are more options, such as the Web App functionality that comes with a default Python “Hello World” app. Also the server is still called web from the serveradmin command line, but is now called Websites through the GUI.
  • Wiki – The wiki has themes again, although they’re just color schemes. And you can create your own custom banners and upload, which brings back two of the most common feature requests from people that hack the look and feel of the wiki in versions previous to Lion. But the most substantial aspect of the Wiki to change to me is the document management options, available to users in WebDAV or through the portal. This allows for a very mobile-friendly file management tool. Blogs and wikis for the most part stay the same and have a very clean upgrade process from Lion. The command line tools also feature some new options for indexing, etc., which many will find helpful.
  • Xsan – cvadmin, cvlabel, cvversions, etc are now stored in /System/Library/Filesystems/acfs.fs/Contents/bin/ and Xsan has its own entry in the Server app. Despite hearing people question its future, I’ve never seen as many questions flying around about how to do things with Xsan than I do now. Storage sales are up, monkey chatter on the web is up, deployments are being booked and Xsan looks here to stay. The Server app only really shows you a status of things, but the Xsan Admin app is now embedded in the Server app and available through the Server app Tools directory.

Configuring Websites in Server app

The Alerts options are much more robust in Mountain Lion than they were previously. You  can now get alerts on a myriad of things, incuding certs, disks, space, storage quotas, virus detection, network changes and software updates.

Configuring Alerts in Mountain Lion Server

The Server commands also moved and in fact the whole file and folder structure mostly fit nicely inside of the Server app. There are certain things that haven’t been dealt with in this regard such as NetBoot’s library, but for the most part Apple is getting Server to the point where it’s very self-contained. The ramification of which is that upgrades for future releases (and from Lion to Mountain Lion for that matter) are much simpler. Simply downloading a new version informs administrators that the app has been replaced and is good to go, service data in tact. In real world, this has been a little hit or miss but should prove to make our lives much easier in the future.

Reducing scope, aligning with better development practices and all the work to merge all of the remaining services into Server app are huge undertakings. I would fully expect no further support or updates to Workgroup Manager, no more testing of managed preferences in deference to profiles and a few other culture shifts that still need to shake themselves out. Most of us are going to seem underwhelmed (if that’s a word, no it’s not ’cause I looked it up -> awesome video below –> ’cause affection has 2 fs, especially when you’re dealin’ with me). But here’s the thing, with an incremental update, you’re not going to get massive changes. Instead we will get slow and steady updates hopefully continuing to build faster towards a better end goal. What’s important is that the foundation is actually better now, given changes to other parts of OS X and so Server is likely now better positioned than ever for great new features in subsequent releases.

Oh, and did I forget to mention that Xgrid is gone. I guess no one really noticed anyway…

July 26th, 2012

Posted In: Mac OS X Server

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

I’ve done plenty of writing on the Application Layer Firewall (ALF) and the IP FireWall (IPFW) in OS X over the years. There will be more on ALF coming in “July” but in the meantime, there’s something I hadn’t written much about in Lion and that’s the pf implementation.

To get started, let’s look at the /etc/pf.conf configuration file that comprises pf:

scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"

Here, you can see that pf is configured with a number of anchors. An anchor is a collection of rules and tables. Basically, the anchor file being loaded is /etc/pf.anchors/com.apple. In here, we see some rules (without comments):

scrub-anchor "100.InternetSharing/*"
scrub-anchor "300.NetworkLinkConditioner/*"
nat-anchor "100.InternetSharing/*"
rdr-anchor "100.InternetSharing/*"
anchor "100.InternetSharing/*"
anchor "200.AirDrop/*"
anchor "250.ApplicationFirewall/*"
dummynet-anchor "300.NetworkLinkConditioner/*"
anchor "300.NetworkLinkConditioner/*"
anchor "400.AdaptiveFirewall/*"
load anchor "400.AdaptiveFirewall/" from "/Applications/Server.app/Contents/ServerRoot/private/etc/pf.anchors/400.AdaptiveFirewall"

These are mostly just allowing the Apple services to work with services enabled in the Sharing system preference pane, etc. The scrub options are pretty cool as it cleans dirty packets prior to passing them to their destination. To see how the rules are interpreted, let’s run pfctl with the -sa option, which shows all information/stats:

sudo pfctl -sa

Here we see information like stats on timeouts, limits to rules, etc. Let’s look at the rules specifically:

sudo pfctl -sr

Now let’s load a line below the previously called anchors in the first file:

pass in quick on lo0 all
pass out quick on lo0 all

This is going to always allow local traffic, which we need for a few internal processes. Then let’s block some stuff (after all, if we’re not filtering, why use a packet filter). First add the following to the pf.conf file to block all otherwise allowed incoming sockets:

block in all

And this one for outbound traffic:

block out all

Or to knock the two above lines out with one:

block all

Then to do something pretty straight forward, like allow incoming icmp traffic for en0:

pass in quick on en0 proto icmp

One more rule, to show how we’re going to pass and log data for data coming into en0 for both tcp and udp from anyone to the IP on that interface running 192.168.210.10 for port 548:

pass in log quick on en0 proto { tcp, udp } from any to 192.168.210.10 port 548 keep state

Of the above, tables allow you to define ranges and basically alias IPs. Anything in this section of pf.conf in angled (<>) brackets is a table that has been defined. You can also build a list, which allows multiple criteria to be defined for a given rule and macros, which are essentially arrays of IPs, ports, etc, designed to reduce the amount of typing you have to do if you’re building out a big configuration file. Once we’ve edited our configuration file, let’s run a quick sanity check on it:

sudo pfctl -v -n -f /etc/pf.conf

Now, provided we don’t get any crazy errors, let’s load pf with our rules (which also loads the anchors):

sudo pfctl -f /etc/pf.conf

Then let’s set pf to be verbose while we’re testing (we’ll turn it off later):

sudo pfctl -v

Then let’s enable pf:

sudo pfctl -e

The return code should be something along the lines of the following:

pf enabled

You can also add information on the fly. For example, to add a table of 127.0.0.0/24 call localsub:

sudo pfctl -t localsub -T add 127.0.0.0/24

If you want to flush your rules later:

sudo pfctl -Fa -f /etc/pf.conf

To clear your stats:

sudo pfctl -z ; pfctl -si

Once we feel good about the pf configuration, set it to be quiet to keep the logs small and make it a little quicker:

sudo pfctl -q

And to disable pfctl when you’re done tinkeratin’:

sudo pfctl -d

And to watch what it’s doing:

ifconfig pflog0

Followed by

sudo tcpdump -v -n -e -ttt -i pflog0

Overall, pfctl is pretty straight forward to use. There is a really good post (thanks to @sacrilicious for pointing it out) at http://ikawnoclast.com/2012/04/using-the-lion-pf-firewall-with-the-emerging-threats-list.html for syncing the Emerging Threats anchor from emergingthreats.net. And of course, OpenBSDs pf page is the best source of information on the project, available here. There are a few limitations. The pf command is limited to one processor, so running a dedicated pf host on an 8 core machine is pretty much overkill. RAM is important as pf doesn’t use swap space. The more you pay for a card, the better a card you get, for the most part. Check out the Small Tree cards as they’re pretty efficient…

A few things I haven’t gotten working, the logging is kinda’ wonky. The antispoof protection seems odd (see the antispoof docs on the pf page), osfp (which might be other devices in my walled garden) and dummynet integration (which I have working w/ ipfw)… If I can get them working I’ll put together another post for that in my infinite amounts of free time. I also didn’t end up figuring out the upper limit for packets/rule lookups/table lookups per second… As I write more efficient tables I do more lookups and can therefore process packets faster. It’s annoying when I realize ***I*** am the bottleneck…

July 2nd, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , ,

The ESX firewall can be managed from the command line. If you login over SSH you can then use the following command to view (query) all of the active firewall entries (for those BSD/OS X folks, this command is similar to the ipfw command):

esxcfg-firewall –q

So we’re going to step through opening ports 3389 and 25 UDP and TCP into and out of our VM. We’re going to continue using the esxcfg-firewall command, as it’s the primary interface into the ESX servers/clusters firewall engine. We’re also going to use the -o option to open the port and then follow that up with a comma delimited set of parameters for the port (port # followed by whether it’s tcp or udp followed by whether it’s incoming or outgoing followed by a friendly name, which is just for us to be able to find our rules later):

esxcfg-firewall -o 3389,udp,in,LDAPUDPIN
esxcfg-firewall -o 3389,udp,out,LDAPUDPOUT
esxcfg-firewall -o 3389,tcp,in,LDAPTCPIN
esxcfg-firewall -o 3389,tcp,out,LDAPTCPOUT
esxcfg-firewall -o 25,tcp,in,SMTPTCPIN
esxcfg-firewall -o 25,tcp,out,SMTPTCPOUT
esxcfg-firewall -o 25,udp,out,SMTPUDPOUT
esxcfg-firewall -o 25,udp,in,SMTPUDPIN

April 14th, 2009

Posted In: VMware

Tags: , ,

There are certain aspects of Mac OS X Server that it just isn’t that great at.  One of them is acting as a router.  It’s just a fact that an appliance by SonicWALL, Cisco, Watchguard and sometimes LinkSys will run circles around the speed and feature set of Mac OS X Server.  So with that in mind, let’s look at how you would go about configuring a basic port forward on OS X Server if you decided not to listen to me on this point…  😉

You can use the /etc/net/natd.plist.  The key you’ll want to edit is the redirect_port, one per port or a range of all in one key…  Basically the array would look something like this assuming you were trying to forward afp traffic to 192.168.0.2 from a WAN IP of 4.2.2.2:

<key>redirect_port</key>

<array>

    <dict>

    <key>proto</key>

        <string>TCP</string>

    <key>targetIP</key>

        <string>192.168.0.2</string>

    <key>TargetPortRange</key>

        <string>548</string>

    <key>aliasIP</key>

        <string>4.2.2.2</string>

    <key>aliasPortRange</key>

        <string>548</string>

    </dict>

</array>

 

You could also use the route command or ipfw depending on exactly what you’re trying to do with this thing.  Route is going to be useful if you’re trying to respond to network traffic over a different interface than the default interface.

August 12th, 2008

Posted In: Mac OS X, Mac Security

Tags: , , , , , , ,

Kerio leverages the OWA aspect of Entourage so if you open up OWA on the firewall then Entourage will be able to work over port 80 (or 443).

September 22nd, 2007

Posted In: Kerio, Mac OS X

Tags: , , , ,

I originally posted this at http://www.318.com/TechJournal

Introduction

Xsan requires a dedicated ethernet network in the supported architecture by Apple. For systems that are obtaining directory information or need to be wired into the corporate network of many organizations this can cause issues. Namely that Xsan will attempt to use the corporate network for connectivity with clients. We see this in many configurations and it can cause dropped packets, unmountable volumes and other intermittent issues.

One way to fix this for metadata controllers is to choose the network adapter that you would like to use on the metadata network in Server Admin. This can be done by:

Open Xsan Admin
Click on the Xsan listed under SAN Components
Clicking on Setup
Click on Computers
Click on the metadata controller
Choose the network controller you would like to connect using
This doesn’t always work, and selecting a network controller to use is not an available option with Xsan clients and older versions of the Xsan software. A fix to get around this issue for these systems is to block metadata traffic on the production network interface. Here is an example of how to do this using ipfw. This example assumes that you are using Tiger Server for your metadata controller. Once we step through this using Server Admin we will explain the same thing using the configuration files which should help users of old versions of Mac OS X Server or of Mac OS X Workstation.

Through this entire article we are going to assume that the IP address of our metadata controllers production IP is 192.168.50.5. The IP address of our metadata controllers metadata IP is 10.0.0.5. If metadata goes over the 192.168.50.x network then it will likely cause issues, so our goal throughout is going to be blocking metadata traffic on 192.168.50.5. There are also many ways to do this. We are going to focus on blocking outgoing traffic for Xsan on the production IP. Another way to accomplish this might be to block all traffic for metadata for the network range of 192.168.50.x. There are many different ways to do this (including using managed switches) but this way has been working for us.

DISCLAIMER : Be very careful playing with the firewall on a headless server. The last thing you want to do is block yourself from being able to ARD or SSH into a system you are trying to administer. Also try to make sure that you do this stuff while you have the opportunity for a little down-time as you might need a little time to troubleshoot. Also, be sure to backup the service settings before making any changes. To do this, drag the small icon in the lower right-hand corner of the firewall service screen to the desktoop. When you see the + icon let go of the icon and it will save the service settings. If you need to restore this later you can drag the file back over to the Server Admin screen.

Using Firewall in Server Admin

First we’re going to enable Firewall (ipfw):

Open Server Admin from /Applications/Server
Authenticate to the server you are configuring
Click on Firewall under the Computers and Servers List
Click on Settings
Click on Services
Click on the Start Service button in the toolbar of Server Admin
Now we’re going to define the ports to block (see Figure 1):

Click on the + sign to add a service
Enter Xsan under the Name field
Enter “536, 537” (without the quotes) under the Port field
Leave the Protocol set to TCP
Click on OK

Figure 1 – Defining Ports

Now we’re going to define the addresses to block this port for (see Figure 2):
Click on Address Groups
Click on the + sign to add an address group
Name the address group Production IP
Click on the + sign beside Addresses in group
Remove Any if it is present
Type the IP address of your internal IP for the production network
Click OK

Figure 2 – Creating the Address Group

Now we’re going to create the rule for blocking the Xsan ports (see Figure 3):
Click on the Advanced tab
Uncheck all of the rules that deny if you want to first test your base config (you can always go back and add rules once you’ve become more familiar with the Firewall service)
Click on the + button
In the Action drop-down choose the Deny option
In the Protocol drop-down choose the TCP option
In the Service drop-down choose the newly created Xsan service
In the Address drop-down choose the newly created Production IP address
In the Destination drop-down select Any
The Ports should read 536, 537 as this is what we defined earlier
In the Interface drop-down choose Out
Click OK

Figure 3 – Configuring the Rule

Using the IPFW from the Command Line
Personally I find it much easier to do most of this using the command line. For systems not running Mac OS X Server you will need to use the command-line. To do this you would use the ipfw.conf file that is created to define what types of traffic are allowed. The ipfw.conf file is located at /private/etc/ipfilter/ipfw.conf.

The default ipfw.conf file looks like something like this:

# ipfw.conf.default – Installed by Apple, never modified by Server Admin app
#
# ipfw.conf – The servermgrd process (the back end of Server Admin app)
# creates this from ipfw.conf.default if it’s absent, but does not modify it.
#
# Administrators can place custom ipfw rules in ipfw.conf.
#
# Whenever a change is made to the ipfw rules by the Server Admin application and saved:
# 1. All ipfw rules are flushed
# 2. The rules defined by the Server Admin app (stored as plists) are exported to
# /etc/ipfilter/ipfw.conf.apple and loaded into the firewall via ipfw.
# 3. The rules in /etc/ipfilter/ipfw.conf are loaded into the firewall via ipfw.
# Note that the rules loaded into the firewall are not applied unless the firewall is enabled.
#
# The rules resulting from the Server Admin app’s IPFirewall and NAT panels are numbered:
# 10 – from the NAT Service – this is the NAT divert rule, present only
# when he NAT service is started via the Server Admin app.
# 1000 – from the “Advanced” panel – the modifiable rules, ordered by their
# relative position in the drag-sortable rule list
# 12300 – from the “General” panel – “allow”” rules that punch specific holes
# in the firewall for specific services
# 63200 – from the “Advanced” panel – the non-modifiable rules at the bottom
# of the panel’s rule list
#
# Refer to the man page for ipfw(8) for more information.
#
# The following rules are already added by default:
# #add 01000 allow all from any to any via en0
#add 01010 deny all from any to 127.0.0.0/8
#add 01020 deny ip from 224.0.0.0/4 to any in
#add 01030 deny tcp from any to 224.0.0.0/4 in
#add 12300 (”allow” rules from the “General” panel)
#…
#add 65534 deny ip from any to any
First, we’re going to allow all traffic for both controllers. For this example doing this will make sure that we don’t have any problems with connecting to Xsan Admin (port 311) or ARD. To do this, take out the # for the line that reads:

#add 01000 allow all from any to any via en0
By removing a # from the beginning of a line you are uncommenting the line or enabling the rule. I like to go through and put a commented line for some rules that are complicated so that other techs at my company can figure out what they do if they need to troubleshoot something that I’ve done. To do this you just begin the line with a #.

Also the en0 here might be en1 or lo1 for some metadata controllers. You can use the Network Utility to determine which adapter is using which ethernet port name.

Next you will create another rule that adds a line that denies outgoing traffic for ports 536 and 537 (Sun Grid Engine Qmaster) over the ethernet adapter being used for the metadata network. This adapter can easily be identified using the Network System Preference. This rule looks something like this assuming that 192.168.50.5 is the IP address the server is using for its metadata network interface:

add 65534 deny tcp from 192.168.50.1 to any dst-port 536, 537 out
Reading from left to right we are telling ipfw to add a rule with a unique ID that denies TCP traffic from the IP address of the metadata network interface that is running on ports 536 or 537 for outgoing traffic. The unique ID number also acts as a priority that rules should be run in. A full sample file could be as short as:

#The following line enables network traffic on the Production Network
add 01000 allow all from any to any via en0
#The following line enables network traffic on the Metadata Network
add 01000 allow all from any to any via en1
#The following line disables Xsan Traffic for the Production Network
add 65534 deny tcp from 192.168.50.5 to any dst-port 536, 537 out
Finally, once you are sure that your configuration is good, use Server Admin to enable the Firewall service as we described at the beginning of this article. Remember not to block port 311 or you will not be able to use Xsan Admin to administer the client.

Just in case you use Linux clients

For Linux clients of Xsan I find that using iptables is a great way to accomplish this same task. The two commands to create the deny rule using iptables would be something like this assuming that eth0 is your production network:

Iptables –A PREROUTING –o eth0 -s any –p tcp –dport 536 -j DROP
Iptables –A PREROUTING –o eth0 -s any –p tcp –dport 537 -j DROP
If iptables is not already started you can type:

Service iptables start
The command to view active rules for iptables is:

Chkconfig –list iptables
Saving Windows for Last

Windows XP and Server 2003 have equally as robust firewall features. To limit traffic over ports you would use Windows Firewall for Windows XP and Routing and Remote Access for Windows Server 2003. While Windows Server 2003 is a little beyond the scope of this document, I can help you get started. For Windows XP:

Click on Start
Click on Connect To
Click on Show All Network Connections
Click on Change Windows Firewall Settings (see Figure 4)

Figure 4 – Network Connections

Once you have your Windows Firewall control panel open, click On and make sure that the Don’t allow exceptions check-box is unchecked (see Figure 5)

Click on Advanced
Use the check-boxes under Network Connection Settings to disable the Firewall for the Metadata Controller (see Figure 6)

Figure 5 – Enabling Windows Firewall

Figure 6 – Windows Firewall Advanced Settings

October 16th, 2006

Posted In: Xsan

Tags: , ,