Tuesday Jan 09, 2007

Trusted Extensions in Parallels on Mac OS X

What I did over my winter vacation... Check out the pics (Flickr Photo Set)! Gotta love it when things just work! Thanks to Glenn Faden and Daniel Zhu for their postings and ideas that helped show me the way.

Take care,

Glenn Technorati Tag:

Tuesday Sep 26, 2006

Treo 700p on Nevada

Will wonders never cease? Today, I decided to plug my Treo 700p smart phone into my newly upgraded Solaris laptop. Honestly, I was not sure what would happen as this was the first time that I had tried to connect up a Palm device.

My goal for doing this was simple. I wanted to synchronize my calendar to my phone so that I would have a list of my appointments while I was on the road. I had wanted to use something more direct like SyncML, but that option was not available to me. Oh, well... I have been using Evolution lately to manage my appointments. What is interesting about my configuration is that my calendar is hosted on Sun's EdgeCal service which allows me to easily access and share my calendar from the Internet or within Sun. EdgeCal is basically a Sun Java System Calendar Server environment and I use the JESCS Evolution Connector to access EdgeCal. By the way, this all worked out of the box too!

So, back to today's experiment... Since Evolution already has an ability to synchronize with devices such as Palm Pilots, I decided to give that a try. The process was completely painless. I simply connected up the 700p via a USB port (actually on a USB hub since I am also using a USB keyboard and mouse), provided some basic settings information to Evolution (Pilot Synchronization Dialog) and hit the HotSync button. Evolution was able to not only find my device but also push the calendar information from EdgeCal to my phone in a matter of seconds. Way cool.

What is really nice is that I can also use the pilot-xfer command to also back up your device (to a ZFS partition in my case). You really have to love it when things just work.

Take care,


Technorati Tag:

Tuesday Sep 05, 2006

Laptop Upgrade to Nevada - b47 - Security Settings

Today, I would like to go over a few of the changes that I made to my laptop in order to improve upon its overall security configuration. It should be noted that the list of changes made is relatively small (from the default) and is based upon how I plan to actually use the system. As a result, you may need more or different changes than those listed here based upon your specific needs. With that said, let's get into the details.

Nevada by default enforces the settings specified by the Secure by Default project. As a result, there were no network services listening on my laptop for external connections (with the exception of Secure Shell). This is a great start and significantly simplifies getting a desktop or laptop secured and ready for the network. Since I generally do not permit inbound access to my laptop, I also disabled Secure Shell:

blackhole$ pfexec svcadm disable ssh
blackhole$ svcs ssh
STATE          STIME    FMRI
disabled       21:30:12 svc:/network/ssh:default

At this point, there are literally no local services listening that an external person could access. As there is a need, I will temporarily enable services such as SSH or perhaps VNC (x11vnc), but the default is to leave them in a disabled state until they are required.

Next, I configured IP Filter - the firewall software built into Solaris. I have been a huge fan of IP Filter for years and was absolutely thrilled to see it integrated into Solaris 10. The configuration that I use is based upon a version for laptops that was developed by Darren Moffat. To be completely honest, I have a few different firewall policies that are automatically installed based on the network profile that I have selected. This allows me, for example, to have one firewall policy when I am connected via Ethernet on my home network and a different one when I am travelling.

Before installing the firewall policy, I needed to configure the file /etc/ipf/pfil.ap. Since I am working from a Toshiba Tecra M2, I had to uncomment the entry for the e1000g driver and add an entry for the ath driver as follows:

# egrep "e1000g|ath" /etc/ipf/pfil.ap
e1000g  -1      0       pfil
ath     -1      0       pfil

Next, I installed Darren's firewall configuration, /etc/ipf/ipf.conf. I will not provide my specific settings - leaving the firewall configuration as an exercise for the reader.

# ipf.conf
# IP Filter rules to be loaded during startup
# See ipf(4) manpage for more information on
# IP Filter rules syntax.

pass out quick all keep state keep frags

# Drop all NETBIOS traffic but don't log it.

block in quick from any to any port = 137 #netbios-ns
block in quick from any to any port = 138 #netbios-dgm
block in quick from any to any port = 139 #netbios-ssn

# Allow incoming IKE/IPsec

pass in quick proto udp from any to any port = ike
pass in quick proto udp from any to any port = 4500
pass in proto esp from any to any

# Allow ping

# pass in quick proto icmp from any to any icmp-type echo

# Allow routing info

# pass in quick proto udp from any to port = route
# pass in quick proto icmp from any to any icmp-type 9 # routeradvert
# pass in quick proto igmp from any to any

# Block and log everything else that comes in

block in log all
block in from any to
block in from any to

For the first time IP Filter configuration, there are a few other steps that I will not cover here now. Check out the documentation for the specifics.

With this complete, I turned my attention inward for a few additional configuration changes. You can read more about them in the Solaris 10 Benchmark published by the Center for Internet Security.

First, I modified the /etc/security/policy.conf file to set my default crypt(3C) algorithm to Sun MD5:

# The Solaris default is the traditional UNIX algorithm.  This is not
# listed in crypt.conf(4) since it is internal to libc.  The reserved
# name __unix__ is used to refer to it.

This is useful for a variety of reasons most notibly because it would freak out any script kiddy running stock versions of Crack and john in an attack to guess passwords. In their stock configurations (just download, compile and run), neither of these tools can successfully deal with the Sun MD5 password format. See the crypt_sunmd5(5) manual page:

     This module is designed to make it difficult to crack  pass-
     words  that  use brute force attacks based on high speed MD5
     implementations that use code inlining, unrolled loops,  and
     table lookup.

Moving on, I enabled the following coreadm configuration:

# coreadm
     global core file pattern: /var/core/core_%n_%f_%u_%g_%t_%p
     global core file content: default
       init core file pattern: core
       init core file content: default
            global core dumps: enabled
       per-process core dumps: disabled
      global setid core dumps: enabled
 per-process setid core dumps: disabled
     global core dump logging: enabled

This is nice in that the system will notify me (via syslog) of core dumps:

Sep  5 15:01:16 blackhole genunix: [ID 603404 kern.notice] NOTICE: core_log: sleep[5691] core dumped: /var/core/core_blackhole_sleep_101_101_1157482876_5691

and will store the core files in a protected directory, /var/core:

$ ls -ld /var/core
drwx------   2 root     root         512 Sep  3 21:13 /var/core

Moving along, I also set the following parameters:

# grep "noexec_user_stack" /etc/system
set noexec_user_stack = 1
set noexec_user_stack_log = 1

# grep nfs_portmon /etc/system
set nfssrv:nfs_portmon = 1

# grep TCP_STRONG_ISS= /etc/default/inetinit

These are typical changes and are discussed in older Sun BluePrints as well as the CIS Benchmark. Next, I also created the loginlog file:

# ls -l /var/adm/loginlog
-rw-------   1 root     sys            0 Sep  3 21:16 /var/adm/loginlog

and enabled debug logging in syslog:

# grep '\*.debug' /etc/syslog.conf
\*.debug                                         /var/adm/debug

Be sure to create the /var/adm/debug file before restarting syslog. In addition, I also disabled login access on the laptop's serial ports:

# pmadm -d -p zsmon -s ttya
# pmadm -d -p zsmon -s ttyb
After installing a few basic warning banners in the typical places (see the CIS guide), I also changed root's home directory, converted root to be a Solaris role, and assigned the rights to assume root to only my local account:

$ getent passwd root

$ grep "\^root:" /etc/user_attr

$ roles

Lastly, using the normal methods, I also enabled and configured Solaris auditing and BART so that I can keep tabs on what is going on. Of course, this is also in addition to BIOS and GRUB security changes that I will not cover in this post.

Is this all you need to do? Well, unfortunately - it depends. There are certainly lots of other things that I could do.

For example, I could disable rhosts authentication for the rsh and rlogin services. Recall however that each of those services is (1) disabled by default and (2) subject to the firewall policy in place. So, to successfully exploit this path, an attacker would need to change both of these settings - which require administrative privileges - enough to add rhosts entries back into /etc/pam.conf. So for me, it was about maximizing security while minimizing change. In this specific case, changes to those states or configuration files would be detected by BART and Solaris Auditing. Similarly, there is not much point (except as a reminder) for me to enable password aging, history or complexity rules when I am the only user on the system (and the system does not accept remote incoming connections - except in very limited cases).

You get the point... For another perspective, check out how John Clingan approached this problem.

My longer term hope is that we can further reduce the changes required out of the box by making many of the most common settings default Solaris values. That way, everyone could benefit from a stronger out of the box installation posture. SBD was a great step forward down this path. Let's look at a few examples of RFEs that are outstanding right now:

Would you like to see these implemented? If so, let us know! If you have a valid Solaris support contract, you can also contact support to have you added as a customer call record for one or more of these RFEs. Just as important - are there other security changes that you would like to see made by default in future versions of Solaris! If so, be sure to tell us! File bugs or RFEs! Talk with us! and (if you are so included) participate and help us make the changes!

Before I sign off, you may be wondering why not just use the Solaris Security Toolkit and be done with it? Certainly, I could have used the (currently unreleased) version that supports SBD and implemented these changes. In fact, most companies may want to go that route since SBD alone (as demonstrated above) covers just part of the problem space. The reason however is simple. I wanted to demonstrate what it would take for you to quickly and easily secure a new OpenSolaris or Nevada laptop from an out of the box state. All too often the tools and guides make people think that it is harder than it really is. Certainly, the Toolkit is essential for building repeatable, auditable configurations, but in the case of my one off - the time difference to implement is negligible.

Take care,


Technorati Tag:

Saturday Sep 02, 2006

Laptop Upgrade to Nevada b47 - A Few More Things

[Read More]

Friday Sep 01, 2006

Laptop Upgrade to Nevada b47 - The Next Day

Several hours into day 1 of the upgraded laptop and no significant issues to report. The complete installation went smoothly and all of my productivity tools appear to have retained their settings and are working as expected including:

This is in addition to the other tools I mentioned in my previous post, including: frkit, Nvidia drivers, punchin, pkg_get, and inetmenu. The Nvidia drivers are correctly pushing my screen image (by default) to both the laptop LCD and my external flatscreen. What more count I ask for?

During the course of my new installation, I set aside enough space to install Trusted Extensions, so that will be my next big step, but before I do that, I am going to put the laptop through its paces for a few days to make ensure everything continues to work as expected.

You really have to love it when things just work!

Take care,


Technorati Tag:


This area of cyberspace is dedicated the goal of raising cybersecurity awareness. This blog will discuss cybersecurity risks, trends, news and best practices with a focus on improving mission assurance.


« February 2017