Archive for November, 2011

Using Nagios MIBs with a SonicWALL

Wednesday, November 23rd, 2011

MIB (short for Management Information Base), is an index based on a network standard that categorizes data for a specific device so SNMP servers can read the data. SonicWALL MIBs are specific to device AND firmware.  Each can be downloaded from www.mysonicwall.com (you will need to have an account to download).  Click on Downloads, Download Center and then find the firmware that you are running.  Then click on “SNMP MIBs” to download.

Once downloaded, copy the MIB files to /usr/share/snmp/mibs to prepare them for loading into NetSNMP. Then run check_snmp with a -m option followed by ALL so that Nagios will detect the new MIBs:
check_snmp -m ALL
Once complete, determine the OID. OID’s are MIB variables that instruct an SNMP server monitor to look for information on the device. These variables can be determined by reading the MIBs.  One tool that assists with doing this is MIB Browser by iReasoning Networks http://tl1.ireasoning.com/mibbrowser.shtml  MIB Browser can run on Windows, Mac OS X, and Linux/UNIX.  To obtain the appropriate OID’s:
  1. Load the MIBs in MIB Browser by going to File > Load Mibs
  2. Manually comb through to find the OID you want (a string used in the SonicWALL Web Configuration).

To put this into use, let’s prepare an snmpwalk from a TZ100. First, download the SNMP MIBs from MySonicWALL.com for a TZ100 running firmware version (5.6.0.12-65o). Then let’s load the MIB for SONICWALL-FIREWALL-IP-STATISTICS-MIB into MIB Browser. Searching for “CPU” (Edit -> Find in MIB Tree) shows sonicCurrentCPUUtil, the OID for this fact is .1.3.6.1.4.1.8741.1.3.1.3.0. We used the OID shown in the drop-down near the menu in the MIB Browser. This shows the full OID, which sometimes includes a “0″ at the end (shown towards the bottom of the window). Next, add the OID into a switch.cfg file in nagios:

define service{
use                                       generic-service ; Inherit values from a template
host_name                       TZ100
service_description     CPU Utilization
check_command           check_snmp!-C public -o .1.3.6.1.4.1.8741.1.3.1.3.0 -m all
}

These settings include the following:

  • host_name: the name of the device (whatever you want to call it)
  • service_description: the name of the service you are monitoring (whatever you want to call it)
  • check_command: -C is to define the community SNMP string, -o is to define the OID to read, -m is to define which MIB files to load – to be more specific, for this example you can narrow “-m all” to “-m SONICWALL-FIREWALL-IP-STATISTICS-MIB.MIB”

Overall, setting up Nagios to be able to leverage MIBs from 3rd party vendors is an easy task, if not tedious when there are a lot of settings you’d like to walk through with SNMP.

Upgrading VMware ESX 3i to ESXi 4.1i

Friday, November 18th, 2011

Requirements:

a. Workstation – Windows or linux based, either real or VM.

b. The VMhost – Should be backed up, and running ESX 3i (3.5.0)

c. new serial number for ESXi 4

1. go to vmware.com and find the vSphere Hypervisor download area. download and the most current vsphere cli tools

2. download the appropriate upgrade package for the server. the file should be named something similar to “

3. stop all VMs on the hypervisor and place it in maintenance mode.

4. from your workstation, run the vSphere CLI.

5. in the CLI, run “cd bin”

6. in the CLI, run “vihostupgrade.pl –server -i -b path-to-your-upgrade.zip

Disable ApplePressAndHold in Lion

Wednesday, November 16th, 2011

When you type a letter and hold that letter down in Mac OS X Lion (10.7), a pop-up window appears allowing you to accent the letter you are holding down. This is one of the many features from Lion that Apple borrowed from iOS. But there are many, who need to be able to hold a letter down and have that letter repeat. To disable the ApplePressAndHold feature as I’ll call it, just run the following command:

defaults write -g ApplePressAndHoldEnabled -bool NO

Building a Mac and iOS App Store Software Update Service

Wednesday, November 9th, 2011

Let’s say you run a network with a large number of Mac OS X or iOS (or, more likely, both) devices. Software Update and the two App Stores (Mac App Store and iOS App Store) make keeping all those devices up-to-date a pretty straightforward process. They are a huge improvement compared with the rather old-fashioned practice of looking through applications, visiting the web site for each one and manually downloading updated versions. When updating two or more similar machines, of course, one only needed to download the updated version once, then copy it to each other machine. Better, but a process that when performed across a lot of machines requires a lot of work.

However, even though the App Store and Software Update Server in Mac OS X Server make things easier, there’s no simple way to download things once and distribute the downloaded files to multiple machines for items purchased on the App Store. When large updates come out (such as a new version of iOS), you’re essentially downloading huge amounts of data to each and every machine, and if machines are set to automatically download updates, you could even have a large number of them downloading simultaneously.

Of course you can run your own Software Update service in Mac OS X Server, but this requires that every client machine be configured to use the local server. This works well for machines under your control, but for all those people who bring in their own laptops this doesn’t help.

What’s worse is that there’s currently no way whatsoever to run a Software Update-like service for App Store purchases. Imagine if you have a lab of dozens or hundreds of Macs with Final Cut X or iPads (or iPhones, iPod Touches, whatever comes out next with iMovie or ). Any time there’s an update you’re potentially downloading over a gigabyte per machine in the case of Final Cut X or 70 megabytes or so in the case of iMovie. That can easily add up to a tremendous amount of traffic and the congestion, complaints and headaches which go with it..

What’s needed is an easy way to cache App Store downloads. While we’re at it, it would also be nice to transparently have machines use our own Software Update server. Let’s be even a little more ambitious and do this without needing Mac OS X Server. Aw, heck – let’s make it work on any reasonably Unix-like OS.

So how do we do this? The App Stores and Software Update services use http for fetching files. So what we need to do is to capture those http requests and either redirect them to a local store of Software Update files or locally cached App Store files.

Just as an aside, it’d be tremendously difficult to create a local store of App Store files if for no other reason than the fact that there are currently more than half a million applications. Add to this the rate at which updates become available and your machine would probably never be finished attempting to download all of the applications! Considering this, we’re looking at running Apache and squid on our Unix-like machine and doing a little redirection magic on whatever device does NAT or routes for us.

Note: There’s no reason that the same machine can’t do both NAT/routing and Apache/squid, although in most environments we are assuming that the machine would simply be a proxy for Mac or iOS-based devices. To make this example end-to-end though, we’ll run the router on the host.

Our example uses a Mac OS X (non-Server) machine running Leopard which is doing both NAT and running our Apache and squid software. We’re simply using the Internet Sharing service, the public network interface is en0 (which we don’t use anywhere) and the interface which will serve our iOS and Apple clients is en1 and has the address 10.0.2.1.

Everyone has their own favorite way of installing software on Unix-like OSes and a discussion about which is best and why would certainly be outside the scope of this article. In these examples we’re using NetBSD’s pkgsrc for no other reason than the fact that it will compile packages from source with a base directory which is easily configurable (feel free to use ports or some other automated tool according to what platform you are using). Get pkgsrc (usually via cvs; we’ll assume it’s put into /usr which can be as simple as:

cd /usr ; setenv CVSROOT :pserver:anoncvs@anoncvs.netbsd.org:/cvsroot ; cvs checkout -P pkgsrc

And then run /usr/pkgsrc/bootstrap/bootstrap like so:

cd /usr/pkgsrc/bootstrap/
./bootstrap --prefix /usr/local --pkgdbdir /usr/local/var/db/pkg --sysconfdir /usr/local/etc --varbase /usr/local/var --ignore-case-check

This puts all files into /usr/local including logs and configuration files, so keeping your system clean is simple and keeping track of the differences between built-in and pkgsrc software is easy. Next, install pkgsrc’s www/squid and www/apache (and net/wget if your Unix doesn’t already have it):

cd /usr/pkgsrc/www/squid
bmake update
cd /usr/pkgsrc/www/apache22
bmake update
cd /usr/pkgsrc/net/wget
bmake update

Note that on systems like Mac OS X which come with GNU make by default, that pkgsrc uses bmake; if you have BSD make already, just use make. Another note is that /usr/local/sbin is not in Mac OS X’s path by default, so add /usr/local/sbin to /etc/paths if you’re going to use it.

Now that the software is installed in consistent locations we can configure it. The squid.conf file only needs one line to be changed; everything else is added. Find the line which says:

http_port 3128

And change it to:

http_port 3128 intercept

Then add the following lines:

maximum_object_size_in_memory 4096 KB
cache_replacement_policy heap LFUDA
cache_dir ufs /usr/local/var/squid/cache 16384 16 256
maximum_object_size 2097152 KB
refresh_pattern -i .ipa$ 360 90% 10800 override-expire ignore-no-cache ignore-no-store ignore-private ignore-reload ignore-must-revalidate
refresh_pattern -i .pkg$ 360 90% 10080 override-expire ignore-no-cache ignore-no-store ignore-private ignore-reload ignore-must-revalidate
acl no_cache_local dstdomain 10.0.2.1
cache deny no_cache_local
redirect_program /usr/local/bin/rewrite.pl

These settings are chosen to cache large files up to 2 gigabytes in size in a 16 gig cache on disk and to ignore cache directives with regards to .pkg and .ipa files. Adjust to your own liking. Of course, replace 10.0.2.1 with the private IP of your machine. The cache deny with that address is used to make sure that redirected Software Update files are not cached in squid which would just take up room which better used for App Store files.

The URL rewriting script (create /usr/local/bin/rewrite.pl) just changes Apple Software Update URLs to point to our server:

#!/usr/bin/env perl
$|=1;
while (<>) {
s@http://swscan.apple.com@http://10.0.2.1/swscan.apple.com@;
s@http://swcdn.apple.com@http://10.0.2.1/swcdn.apple.com@;
s@http://swquery.apple.com@http://10.0.2.1/swquery.apple.com@;
print;
}

Next we configure Apache. The location you choose for the Software Update files can be anywhere (in our example, they’re on a FireWire attached drive mounted at /Volumes/sw_updates/) which needs to be allowed in the Apache configuration.

Add to /usr/local/etc/httpd/httpd.conf:

<Directory “/Volumes/sw_updates/”>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<VirtualHost *:80>
ServerAdmin hostmaster@318.com
DocumentRoot “/Volumes/sw_updates”
ErrorLog “/usr/local/var/log/httpd/swupdate_error_log”
CustomLog “/usr/local/var/log/httpd/swupdate_access_log” common
</VirtualHost>

The log lines are purely optional. If you don’t add them, logs will still be written at /usr/local/var/log/httpd/access_log and error_log.

Next, we configure ipfw (in the case of Mac OS X or FreeBSD) to redirect all port 80 traffic transparently to our squid instance. If you’re using a different device for NAT/routing or different firewalling software such as ipfilter, see the examples listed below.

ipfw add 333 fwd 10.0.2.1,3128 tcp from any to any 80 recv en1

Note that on Snow Leopard and Lion you’ll need to make this change, too:

sysctl -w net.inet.ip.scopedroute=0

ipfilter would look like this for the same ipfw task from above (if you’re using Linux):

rdr en1 0.0.0.0/0 port 80 -> 10.0.2.1 port 3128 tcp

Again, the local private IP is 10.0.2.1 and the local private interface is en1; substitute your IP and interface.

Finally, we need to mirror all Apple Software Updates. A simple shell script can do this. Save this file somewhere (named mirror_swupdate.sh, for instance) and run it from cron now and then, perhaps once a night:

#!/bin/sh

 

location=$1 # This is the root of our Software Update tree
mkdir -p $1
cd $1

for index in index-leopard-snowleopard.merged-1.sucatalog index-leopard.merged-1.sucatalog index-lion-snowleopard-leopard.merged-1.sucatalog
do
wget --mirror http://swscan.apple.com/content/catalogs/others/$index

 

for swfile in `cat swscan.apple.com/content/catalogs/others/$index | grep "http://" | awk -F">" '{ print $2 }' | awk -F"<" '{ print $1 }'`
do
echo $swfile
wget --mirror "$swfile"
done
done

Invoke this with the top of the tree of your Software Update files as you’ve used in the Apache config, like so:

./mirror_swupdate.sh /Volumes/sw_updates

Expect this to run for a long time the first time you run this because you’ll be downloading around 60 gigabytes of updates. Every time it runs afterwards, though, files won’t be downloaded again unless they change (which they won’t; new updates will show up as new files).

Start squid and Apache, then tail your Apache log and run Software Update to test:

/usr/local/share/examples/rc.d/apache start
/usr/local/share/examples/rc.d/squid start
tail -f /usr/local/var/log/httpd/swupdate_access_log

At this point, you can redirect your software updates to the host. Updates for both the Mac App Store and iOS are also now cached. In the next article we’ll look at using some squid extensions to enable you to block applications from the App Stores or block updates in the event that an update is problematic.

Creating an Access List on a Cisco ASA

Tuesday, November 8th, 2011

Cisco provides basic traffic filtering capabilities with access control lists (also referred to as access lists). Access lists can be configured for all routed network protocols (IP, AppleTalk, and so on) to filter the packets of those protocols as the packets pass through a router. You can configure access lists on your ASA router to control access to a network: access lists can prevent certain traffic from entering or exiting a network. You can do this by port or IP address.

The access control list (ACL) methodology on the Cisco ASA is interface-based. Therefore, each interface must have a specified security level (0-100), with 100 being most secure and 0 being least secure. Once configurations are in place, traffic from a more secure interface is allowed to access less secure interfaces by default. Conversely, less secure interfaces are blocked from accessing more secure interfaces.

Some common commands used to configure Cisco ASA interfaces include:

  • nameif – used to name the interface
  • security-level – used to configure the interface’s security level
  • access-list – used to permit or deny traffic
  • access-group – applies an ACL to an interface

We can configure an access list to permit or deny traffic, based on a specific port or protocol. With deny-by-default, everything is automatically blocked and must be explicitly allowed (on Routers it is the opposite where everything is allowed and you have to deny ports or protocols to block them).

Let’s say we want to configure an ACL on an ASA to permit all FTP traffic from any host to 192.168.1.10. To do this, we must input the following ACL:

ASA(config)# access-list OUTBOUND permit tcp any host 192.168.1.10 eq ftp

Now let’s say we want to configure an ACL on an ASA to deny all FTP traffic from any host to 192.168.1.10. To do this, we must input the following ACL:

ASA(config)# access-list OUTBOUND deny tcp any host 192.168.1.10 eq ftp

Access lists are also used in defining rate limit’s when defining QOS settings. Here is a helpful guide to assist in choosing the right number to associate to an ACL:

Protocols with Access Lists Specified by Numbers

  • Protocol                                                                          Range
  • IP                                                                                      1-99, 1300-1999
  • Extended IP                                                                   100-199, 2000-2699
  • Ethernet type code                                                       200-299
  • Ethernet address                                                          700-799
  • Transparent bridging (protocol type)                    200-299
  • Transparent bridging (vendor code)                      700-799
  • Extended transparent bridging                               1100-1199
  • DECnet and extended DECnet                                 300-399
  • XNS                                                                                 400-499
  • Extended XNS                                                               500-599
  • AppleTalk                                                                      600-699
  • Source-route bridging (protocol type)                   200-299
  • Source-route bridging (vendor code)                     700-799
  • IPX                                                                                  800-899
  • Extended IPX                                                               900-999
  • IPX SAP                                                                        1000-1099
  • Standard VINES                                                           1-100
  • Extended VINES                                                          101-200
  • Simple VINES                                                               201-300

Sandbox in Mac OS X Lion and Apple’s App Store Submissions

Monday, November 7th, 2011

Note: For more information about the information contained in this article, contact us for a professional consultation.

In our previous tech journal article, we touched on the history of sandboxing, from its evolution out of the POSIX model to the more granular controls provided by the ACL model and how they are both derived from a concept called Discretionary Access Controls. For this discussion, please check out out previous article “A brief introduction to Mac OS X SandBox Technology.”

New Sandboxing & Privilege Separation in Lion

This article will attempt to clarify and explain the changes in Lion and iOS sandboxing and the upcoming change in requirements for App Store submissions.  Apple has decreed that all applications submitted to the App Store MUST be sandboxed, originally the deadline was November 2011, but the deadline has recently been moved back to March 1, 2012.

iOS sandboxing has been in place for a while now.  iOS applications can only see their own data and documents, cannot alter your devices underlying settings, and generally appear to be isolated from other apps on your iOS device.  Apple has brought this methodology to Macs with 10.7 Lion.

Compared to previous Mac OS security models, Lion has made leaps and bounds in terms of sandbox security, with Apple finally promoting the technology for use by third party developers.  The 2 ways of Apple has increased security is through Sandboxing and Privilege Separation.  Sandboxing refers to the process whereby a developer specifies a list of expected operations an application will perform, while Privilege Separation refers to splitting an application or daemon into more granular pieces where each piece is only given rights to its particular task.  Every sandbox application must include a set of “entitlements,” or a list of resources the application needs to perform its tasks.  Lion has around 30 entitlements ranging from low-level operations (e.g. creating or listening to network connections), to higher level operations (e.g. printing or accessing the camera).

Application Sandboxing

App Sandboxing can help prevent flaws or oversights in programming from becoming security threats via privilege escalation.  By specifying a set of entitlements, a developer tells the OS which operations are allowed and expected.  This way if a user process tries to perform a task that is not entitled, the OS will not allow the task.  This makes executing arbitrary code from a problem like a buffer overflow much less likely.  Listing entitlements also lets the system know to create a container directory for the application itself and runs it inside a sandbox configured for that particular application. If a developer creates an internet browser application and didn’t grant the entitlements to the camera and microphone, a website with malicious code trying to access the camera would be thwarted by the OS.

The container directory is where your sandboxed application can read and write its private files and data, including preferences, autosave info and other information needed by the application itself.  The sandboxed application is prevented from accessing data and files from outside the sandbox with a few exceptions, like the systems Open and Save dialog boxes, which require user intervention to explicitly work outside the sandbox. Upon first launch, the OS creates a container directory in ~/Library/Containers with the application bundle identifier as the directory name (e.g. com.apple.TextEdit).

Sandboxing an application is not a replacement for good coding practices or testing.  Indeed, sandboxing actually will increase the requirements for testing as each entitlement will need to be verified and tested, but it will provide a valuable line of defense against unanticipated malware or other nefarious activity.

App Store Sandboxing

While not being privy to behind the scenes discussions at Apple, the benefits of requiring Application sandboxing for App Store submissions are fairly intuitive. By requiring sandboxing, Apple will simplify its audit process and can more easily provide security assurances for App Store purchases.  Ars Technica seems to confirm this as well.   By sandboxing all Apps, Apple will greatly reduce the potential for rogue code coming out of the App Store, thereby reducing their potential liability.

Adding Sandboxing to your applications in Xcode

To sandbox an application in Xcode, you will need a couple of things. One is a valid code signing certificate issued by a trusted third certification authority (think Verisign, Thawt or Digicert).  Self-signed certificates won’t work as your Certificate Authority (CA) credentials are not included in either the Mac OS or iOS.  The CA root certificate allows a chain of trust to be built to your code signing certificate. Apple has more info on their Root Certificate program here.

An entitlements .plist, named Info.plist.  You will add this file in your project in Xcode.  The Info.plist must have the following Keys:  CFBundleIndentifier, CFBundleName.  The identifier MUST be globally unique.  To help ensure this, please include your company’s name in the indentifier (e.g. com.318.OurLatestApp).  Apple recommends that the identifer be in reverse DNS notation as well.  Your Info.plist must include all the entitlements your application needs.

In Xcode, please add the following linker flags:

-sectcreate __TEXT __info_plist Info.plist_path

where Info.plist_path is the complete path of the Info.plist file in your project.

These flags should be added to the OTHER_LDFLAGS build variable in Xcode.  Please refer to the documentation for other development environments.

You will also need to go into the summary tab for your Xcode project and check

  • Enable Entitlements
  • Enable App Sandboxing

A comprehensive guide to code signing and entitlements is available from Apple here.

Wrapup

Apple’s new paradigm for security will provide additional protection from malicious code.  This new paradigm will necessitate some additional planning and testing.  It will allow Apple to better ensure that any App from the App Store will not harm your computing experience. Apple has a list of entitlements that must be used, but you must be a developer to access this content. In the writing of this article we have attempted to be cognizant of what is and is not under non-disclosure, so if you need access to that, then please grab a free account at the Apple Developer Connection.

Office 2004 Not Responding or Starting Up

Wednesday, November 2nd, 2011

Office 2004 hangs during the Project Gallery pop up window portion of the application starting, or during the Entourage splash page. Here are items to try to do when you run into this:

1. Check for Updates
2. Re-run last large update (this got me from Office 2004 not starting at all, just beach balling, to getting to splash screens)
3. Check disk health and repair disk permissions.
4. Delete Office Prefs Plists (move them to desktop so if it doesn’t work you can put them back)
a. ~/LIbrary/Preferences/Microsoft/com.microsoft.Entourage.prefs.plist
com.microsoft.Excel.prefs.plist
com.microsoft.Office.prefs.plist
com.microsoft.PowerPoint.prefs.plist
com.microsoft.Word.prefs.plist
b. If that doesn’t work, try removing these plists
~/Library/Prefences/com.microsoft.Entourage.plist
com.microsoft.Excel.plist
com.microsoft.PowerPoint.plist
com.microsoft.Word.plist
5. Delete, Move, or Rename “Microsoft User Data”
~/Documents/Microsoft User Data
This will allow Microsoft to recreate Microsoft User Data. In my case, it was OK since:
a. I don’t use templates
b. I have no problem recreating my signature
c. I don’t use POP access to my e-mail